デプロイ後もサービスに責任を持つ

利用者が依存するサービスを定める

デプロイによってソフトウェアを利用できるようになります。運用は、利用者、依存先、トラフィック、要件が変わっても、有用な状態を保ちます。コード生成ツールを使っても、この継続的な仕事はなくなりません。

架空の顧客エクスポートで、利用者が必要とするのは、アクセスできるページだけではありません。許可されたレコードを、必要な形式で、許容できる時間内に得る必要があります。また、他の組織のデータへのアクセスを防ぐ必要があります。

リリース前に責任者を決めます。サービスの約束に含まれるなら、通常の勤務時間外に誰が対応するか記録します。提供者が一部の仕事を行っても、組織には判断と連絡の明確な経路が必要です。

サービスレベル指標（SLI）は、定めたサービス動作の性質を測ります。サービスレベル目標（SLO）は、その指標について、指定した期間の目標を設定します。利用者の要求と運用能力から目標を選びます。

GoogleのSREガイドは、この方法と、信頼性の判断に使うエラーバジェットを説明しています。意味を確認せず、他のサービスの目標をコピーしないでください。SLOのガイド、エラーバジェットのポリシー例を参照してください。

エクスポートでは、処理対象となるリクエストの何を成功と数えるか定めます。想定した拒否と、システム障害を分けます。難しいリクエストを隠すだけで指標が改善しないよう、除外条件を文書化します。

状況を把握しやすくするために、エクスポート全体をログへ記録しないでください。診断に必要な最小限の情報を集め、そのアクセスを保護します。

誰が調整し、誰が調査し、誰が連絡するか決めます。小さなチームでは兼任できますが、責任を明確に保つ必要があります。観察したことと実行した操作を記録します。

Googleのインシデント対応ガイドは、技術的な緩和とともに、調整と連絡を重視しています。技術的に正しい修正でも、利用者に情報が伝わらなかったり、複数の対応者が矛盾する変更を行ったりする可能性があります。インシデント対応を参照してください。

エージェントは、承認されたデータの範囲内でログを要約し、仮説を比較できます。緊急のインシデントだからといって、無制限の本番権限を与えてはいけません。例外的なアクセスには、定めたエスカレーション経路を使います。

実際の条件を代表する架空のデータで、復旧手順をテストします。削除済みレコードや送信済みメッセージなど、コードのロールバックでは戻せないものを特定します。サービスの復旧に必要な時間と情報を記録します。

依存関係の更新、アクセスの見直し、必要に応じた証明書の更新、処理能力の変更、文書の修正に、継続的な担当を割り当てます。保守の対応能力がないサービスには、公開時の予算が終わった後も、対応義務が積み重なります。

インシデント後は、観察した原因に対応する改善を選びます。実装と検証に結び付けます。これでライフサイクルが循環します。運用の証拠が、チームが次に仕様化し、作るものを変えます。