SREのドキュメントが重要な理由 パート2

みなさんこんばんは！



そのため、DevOps Practices and Toolsコースストリームの開始前（つまり1日）に何も残っていません。つまり、この期間中に記事「SREドキュメントが重要な理由」の残りを完了する時間が必要です。



続けます。



新サービスの登録に関するドキュメント



SREはPRR（生産準備レビュー）を実施して、サービスが運用準備基準に準拠していることを確認し、サービス所有者がSRE知識を使用して大規模システムを管理する方法を確実に理解できるようにします。



サービスは、実稼働を開始する前にこのテストに合格する必要があります。 （発売前は、SREではなく、開発チーム自身によってサポートされています。）この段階でのPRRの目標は、サービスが発売時の信頼性の最低基準を確実に満たすようにすることです。







次のPRRは、SREサービスの転送前に発生します。つまり、起動後、多くの時間が経過する可能性があります。 また、SREチームが新しいサービスを利用することを決定すると、生産の状態と使用されたサービスプラクティスの徹底的な分析が行われます。 目標は、サービスの移行プロセスを信頼性と運用の安定性の観点から簡素化し、SREがより適切に対処できるようにすることです。



サービスの移転前にPRRを実施することにより、SREは、打ち上げ前にPRRを実施する場合よりも多くの質問をし、信頼性と使いやすさのより高い基準を設定できます。 開発チームの速度を落とさないように、発売前のPRRは「軽量」にすることができます。



Zoeのストーリーでは、チームには標準化されたプロセスやPRRチェックリストがありませんでした。つまり、サービスを移行するときに非常に重要な問題を見逃す可能性があります。 したがって、サービスを管理する責任を負う前であっても、容易に予測および解決できる多数の問題と衝突するリスクがあります。



PRR /サービス転送には、PRRテンプレートの作成と、SREチームが新しいサービスを使用してPRRテンプレートを使用する方法を説明するプロセスドキュメント（プロセスドキュメント）が必要です。 転送プロセスで使用されるパターンは、起動時に使用されるパターンよりも包括的です。



PRRテンプレートはいくつかの領域をカバーしており、重要な質問への回答を確認するために必要です。 表1は、テンプレートがカバーするいくつかの領域と関連する問題を示しています。

面積	ご質問
アーキテクチャと依存関係	クライアントからフロントエンド、そしてバックエンドへのリクエストパスは何ですか？ 異なるレイテンシー要件を持つ異なるタイプのリクエストがありますか？
キャパシティプランニング	発売中および発売後のトラフィック量と成長率に対する期待はどうですか？ このトラフィックをサポートするために必要な計算能力はありますか？
障害の種類	アーキテクチャに単一障害点がありますか？ 依存関係が利用できないことをどのように排除しますか？
プロセスと自動化	サービスをサポートするために必要な手動プロセスはありますか？
外部依存関係	どのサードパーティのデータ、コード、サービス、またはイベントがサービスと起動に依存していますか？ パートナーのいずれかがサービスに依存していますか？ もしそうなら、彼らは打ち上げの通知を受ける必要がありますか？

表1. PRRテンプレートエリアの例



プロセス文書には、SREが転送の前提条件として製品開発チームに要求する文書も示す必要があります。 たとえば、開発チームに一般的な問題のプレイブックを作成するよう依頼する場合があります。



さらに、SRE組織は、SREの役割と責任範囲を開発チームに簡単に説明するレビュードキュメントを作成する必要があります。 これは現実的な期待を形成するために必要です。 最初のドキュメントでは、SREとは何かを説明し、主な機能、サービスライフサイクル、サポート/メンテナンスの責任など、この記事の最後と最初の部分で取り上げたすべてのトピックを取り上げます。 このドキュメントの主な目的は、開発者がSREとOPSチームを混同しないようにし、ページャーへの回答をSREの唯一の義務と見なさないようにすることです。 前述のストーリーで示したように、サービスの移行時に開発者がSREの動作を完全に理解していなかった場合、これは通信の問題と誤解につながります。



さらに、エンゲージメントモデルドキュメントを作成して、期待を明確にし、サービスの移行中および移行後のSREチームと製品開発チーム間のやり取りのプロセスを説明する必要があります。 ドキュメントに含まれるトピックには、次のものが含まれます。

• サービス転送基準とPRRプロセス。
• サービスレベル目標（簡単に言うとSLO）とエラー計算のレポートを議論するプロセス。
• 新しい起動条件と起動フリーズポリシー（可能な場合）。
• SREチームからのサービスステータスレポートの内容と頻度。
• SREスタッフの要件。
• 新機能のロードマップと、新製品の機能よりも信頼性を高める機能の優先順位（SREで必要）を計画するプロセス。

サービス運用ドキュメント



サービスをサポートするために、SREチームは主に、サービスの一般的な説明（インタビュー）、プレイブックと手順、事後分析、指令、およびSLAという主要な運用ドキュメントに依存しています。 （注：このセクションは、SREの検索の「ドキュメントの改善」の章にありました。）



サービスの見落とし



サービスの一般的な説明は、SREがサポートするサービスの種類を理解するために重要です。 SREは、システムのアーキテクチャ、そのコンポーネントと依存関係、サービスの連絡先とその所有者を知る必要があります。 サービスの一般的な説明は、開発チームとSREチームの共同作業の結果であり、SREタスクをガイドおよび優先順位付けして、さらなる研究のための領域を識別するために作成されます。 このようなインタビューは通常PRRの結果として取得され、サービスの変更に応じて更新する必要があります（たとえば、新しい依存関係が表示される場合）。



簡単なインタビューは、SREがサービスをさらに調査するのに十分な情報を提供します。 完全なインタビューでは、サービスの詳細な説明と、サービスが周囲の世界とどのように相互作用するか、ダッシュボード、メトリック、予期しない問題を解決するためにSREが必要とするすべての情報へのリンクを提供します。



プレイブック



Runbookとも呼ばれることがあり、エンジニアがシフト中にサービス監視システムの通知に応答できるようにする基本的なドキュメントです。 たとえば、ゾーイのチームが「ジョブラグナロクが身をかがめた」というアラートの意味と、受信した状況で何をする必要があるかを説明したプレイブックを持っている場合、インシデントは数分で解決されます。 プレイブックは、インシデントの復旧時間を短縮し、コンソールと手順への便利なリンクを提供します。



プレイブックには、ネットワーク監視プロセスの生成された通知を確認、削除、エスカレーションするための指示が含まれています。 プレイブックの通知の名前は通常、システムが生成するものと一致します。 これらには、精度をテストする必要があるコマンドと手順が含まれています。 問題を解決する新しい方法が発見されたとき、および新しいタイプの障害が特定され、依存関係が追加されたときは、定期的に更新する必要があります。



プレイブックは通知専用に作成されるわけではありません。 また、リリースのリリース、監視、トラブルシューティングのための生産手順が含まれている場合があります。 生産手順の他の例には、サービスのオン/オフ、サービスのメンテナンス、および事故/エスカレーションが含まれます。



死後



SREは、大規模で複雑な分散システムで動作し、新しい機能と新しいシステムの追加により、サービスを改善します。 したがって、変化の規模と速度を考えると、インシデントと混乱は避けられません。 事後分析は重要なSREツールであり、私たちの間違いから学ぶプロセスを形式化します。 ゾーイの仮説的なストーリーでは、チームには正式な事後処理手順がなかったため、再発を防ぐようなインシデントの結果を記録する正式なプロセスはありませんでした。 そのため、チームは同じ間違いを何度も繰り返す運命にあります。



SREチームは、障害に関する重要な情報を収集するセクションを含む標準化された事後分析テンプレートを作成する必要があります。 理想的には、テンプレートは、データ分析ツールで簡単に解析できるように構成する必要があります。 データソースとして事後分析を使用して、クラッシュダイナミクスレポートを送信します。 このテンプレートを使用して作成された各事後分析では、次の情報（最小限）を含む生産の失敗について説明します。

• イベントの年表（タイムライン）。
• ユーザーへの影響の説明。
• 根本原因
• アクションポイント/学んだ教訓。

事後分析は、障害に遭遇したチームメンバによって書かれます。理想的には、その削除に参加し、改善に責任を負うことができる人が対象です。 検死は無邪気に書かれるべきです。 何が起こったのかを理解するために必要な情報と、再発の可能性を減らし、結果を減らし、および/または回復を簡素化するために取らなければならない決定のリストを含める必要があります。



指令



ポリシー文書は、特定の技術的および非技術的ルールと生産指示を指定します。 技術ルールは、たとえば、本番環境での変更のロギング、ログの保持、内部サービスの命名（サービスを実装するときにエンジニアが従わなければならない命名規則）、および緊急識別データの使用と可用性に適用されます。



ディレクティブをプロセスに向けることもできます。 エスカレーションルールは、エンジニアが障害を緊急および非緊急として分類し、特定の状況で実行するアクションを理解するのに役立ちます。 シフト期待ディレクティブは、チームの構造と各メンバーの責任範囲を記述します。



サービスレベル契約



サービスレベルアグリーメント（サービスレベルアグリーメント、略して-SLA）-提供されたサービス作業とデフォルトの場合にとられるアクションに関するクライアントとの正式な合意。 SREチームは、サービスの可用性と遅延を文書化し、SLAに関連するサービスパフォーマンスを監視します。



SLAのドキュメンテーションと公開、およびユーザーエクスペリエンスの徹底的な分析とSLAとの比較により、SREチームはUXの品質を損なうことなく、より迅速に革新することができます。 明確なSLAを持つサービスをサポートするSREは、障害をより迅速に通知し、したがってより迅速に修正します。 SLAは、SREチームとSWEチーム（ソフトウェア開発者）間の摩擦を減らし、チームが目標と結果を客観的に議論できるようにし、リスクに関する主観的な判断を回避します。



外部の法的に有効な契約がほとんどのSREチームに適用されない可能性があることに注意してください。 このような場合、SREチームはサービスレベルの目標（略してSLO）に制限される場合があります。 SLO-可用性や遅延など、特定のメトリックに必要なサービスレベルを決定します。



製品ドキュメント



SREチームは、時間の50％をプロジェクトに費やし、手作業を自動化するソフトウェアの開発、またはサービスの信頼性の向上に努めています。 このセクションでは、SREが開発する製品およびツールに関連するドキュメントについて説明します。



これらのドキュメントは、この製品が自分に適しているかどうか、使用方法、サポートを受ける方法をユーザーが理解できるため、重要です。 また、正しいユーザーエクスペリエンスを提供し、製品の採用を促進します。



製品情報ページ



説明ページは、SREと製品開発エンジニアが製品またはツールとは何か、それが何をするのか、どのように使用するのかを理解するのに役立ちます。



コンセプトマニュアル



コンセプトガイドまたは用語集は、製品に固有のすべてのコンセプトを定義します。 概念の定義により、ユーザーインターフェイス、API、およびCLI（コマンドラインインターフェイス）のドキュメントと要素の一貫性を維持できます。



入門ガイド



スタートガイドの目標は、最小限の遅延でエンジニアを迅速に最新の状態にすることです。 これは、製品を試してみたい新規ユーザーにとって便利です。



Codelab



エンジニアは、これらのチュートリアルを使用して、理論的な説明、コード例、および演習を組み合わせて、製品をすぐに理解できます。 Codelabsは、エンジニアが一連のタスクを段階的に進めるための詳細なスクリプトも提供します。 これらのチュートリアルは通常、入門ガイドよりも長くなります。 何かに関連している場合、複数の製品またはツールをカバーできます。



実用ガイド



このようなガイダンスは、特定の問題を解決したいユーザーに必要です。 これらのガイドは通常、従わなければならない段階的なガイドです。

よくある質問



FAQページでは、ユーザーは最も一般的な質問への回答を得ることができ、遭遇する可能性のある困難と制限について調べ、ドキュメントや他のページへのリンクを見つけて詳細情報を得ることができます。



サポート



サポートページで、エンジニアは直面している問題を解決する方法を学ぶことができます。 エスカレーションプラン、トラブルシューティング情報、グループリンク、ダッシュボード、SLO、シフト情報も見つけることができます。



APIの説明



このガイドでは、関数、クラス、およびメソッドについて説明しますが、通常は最小限のテキストを添付しています。 このようなドキュメントは、ほとんどの場合、コード内のコメントに基づいて作成され、テクニカルライターによって作成されることもあります。



開発者ガイド



このガイドから、開発者は製品APIを使用してプログラミングする方法を学ぶことができます。 通常、このようなガイドは、SREが開発者にAPIを提供する製品を作成する場合に必要です。これにより、相互のAPIを呼び出してより複雑なタスクを実行する混合ツールを作成できます。



サービスステータスを報告するためのドキュメント



このセクションでは、サポートされているサービスのステータスを説明するためにSREチームが作成するドキュメントについて説明します。



四半期ごとのサービスレビュー



サービスのステータスに関する情報は、SREの組織全体に配布されるSREリーダーが同意する四半期レポートと、製品開発およびチームのリーダー向けのプレゼンテーションの2つの形式で表示されます。



SREのリーダーは、次の事項に関する情報を提供するため、四半期レポートに関心があります。

• サポートの問題（シフト、チケット、事後分析）。 SREのリーダーは、サポートの問題がSREチームのリソースの50％以上を占めるようになった場合、対応し、優先順位を変更する必要があることを知っています。 目標は、初期段階ですでに問題を特定することです。
• SLAの実行。 SREリーダーは、SLAですべてが問題ないかどうか、エコシステム内に脅威をもたらす不健康なコンポーネントがあるかどうかを知りたいと考えています。
• リスク SLAのリーダーは、製品およびビジネスの目標を妨げる可能性のあるSREに知られているリスクについて知りたいと思っています。

四半期レポートは、SREチームに次の機会を提供します。

• 製品開発チームにとってのSREの利点と、SREチームの仕事そのものを強調します。
• SRE（回復力）コマンドを妨げる問題を解決するには、優先度を要求します。
• SREチームの優先順位に関するフィードバックをリクエストします。
• チームのより広範な貢献を強調する。

成功するテクニックの概要



このレビューは、成功するテクニックを採用し、操作に最小限の時間を必要とする安定した状態になるのに役立ちます。 このようなレポートを準備するために、SREチームは、サイトとチームのチャーター、シフトステータスの詳細、プロジェクトvs. 中断、容量計画など



成功したテクニックのレビューは、SREチームが他のSRE組織と比較し、シフトステータス、プロジェクトvs中断、SLO、キャパシティプランニングなどの主要な領域でパフォーマンスを向上させるのに役立ちます。



2番目の部分の終わり。



次のパートを読んでください。



いつものようにあなたの質問やコメントを待っています。