アプリケーションの担当者が交代するとき、タスクリストを渡したり、チャットチャンネルにリンクを送ったりするだけでは不十分です。当番を引き継ぐ人は、どのサービスに影響があるのか、未決定の事項は何か、自分に何ができるのか、対応が機能したことをどう確認するのかを理解する必要があります。こうしたコンテキストがなければ、チームは事実の再構築に時間を費やし、対応を重複させたり、リスクを放置したりするおそれがあります。
PHPアプリケーションの技術当番の引き継ぎは、最新の状態を反映し、次のアクションにつなげる運用上の要約であるべきです。インシデント管理システム、タスク管理ツール、runbookの代わりになるものではありません。それらのリソースを結び付け、次の担当期間にどう解釈すべきかを説明するものです。
次の当番に何を引き継ぐべきかを定義する
形式を決める前に、当番担当者がどのような判断を下せるのか、どのような状況で別の役割の担当者にエスカレーションする必要があるのかを決めましょう。担当範囲には、アラートの監視、初期診断、元に戻せる緩和措置、復旧の調整などが含まれます。破壊的な変更、データ移行、社外向けの告知に関する判断には、明示的な承認が必要な場合があります。
引き継ぎでは、少なくとも次の5項目を明確にします。対象サービス、現在の状態、把握している影響、次のアクションの担当者、結果を確認する基準です。いずれかが欠けていると、引き継ぐ人は問題の存在を把握できても、どう進めればよいか分からない可能性があります。
また、文書を更新するタイミング、チームが使用するタイムゾーン、緊急事態をどの連絡経路で宣言するかも決めておくとよいでしょう。最新データの時刻は重要です。時刻の記載がないメトリクスやインシデントの状態は、すでに解決した状況に対する対応を促すおそれがあります。
追跡を重複させずにインシデントとタスクを記録する
引き継ぎ記録を別の作業キューにしてはいけません。各インシデントは既存の管理システムで追跡し、要約には識別子、リンク、状態、次のステップを記載します。そうすれば、一方だけが更新され、もう一方が古いままになることで、2つの記録が食い違うのを防げます。
対応中のインシデントについては、引き継ぎを続けるために必要な事実を要約します。
- サービスと環境：PHPアプリケーション、影響を受けるコンポーネント、問題が本番環境、staging、または別の環境で発生しているか。
- 確認された影響：機能の劣化、判明している場合は影響を受けるユーザー、未確認の影響範囲。
- 状態と経緯：おおよその発生時刻、重要な変更、最後の確認結果とタイムゾーン。
- 実施した対応：何を変更し、どのような結果が確認されたか。事実と仮説を分けて記載します。
- 次のアクションと担当者：具体的な作業、担当者または役割、確認するタイミング。
- エスカレーション：別の担当者またはチームへの連絡が必要となる条件。
インシデントではない未完了タスクは、チケットだけで十分な場合があります。当番の引き継ぎには、次の担当期間に影響するものだけを含めます。たとえば、当番中に期限を迎えるものや、運用上の対応に影響するものです。
条件と確認方法を添えてrunbookを参照する
runbookへのリンクだけでは、いつ使うのか、どのような結果を期待するのかは分かりません。その手順を開始するシグナルと、適用範囲の限界を説明する一文を添えましょう。たとえば、「本番環境でヘルスチェックに失敗した場合に使用する。進行中のマイグレーションがないことを確認する前にプロセスを再起動しない」のように記載します。詳細は推測ではなく、チームが実際に使用しているシステムに即したものでなければなりません。
手順には、必要な権限、診断手順、安全な対応、復旧の検証方法、検証に失敗した場合のエスカレーション先を記載します。PHPアプリケーションの場合、エラーログ、プロセスの状態、メトリクス、キュー、外部依存先への参照を含めることがあります。ただし、それらのシグナルが実際に存在し、当番担当者がアクセスできることが前提です。
手順が特定の設定、バージョン、インフラに依存する場合は、その制約を文書化します。引き継ぎに認証情報やシークレットを含めず、承認されたアクセス取得手段を参照してください。古くなったrunbookや、誰も持っていない権限を要求するrunbookは、役に立つどころかリスクになります。
リスク、依存関係、復旧の限界を明示する
対応方針を変える可能性のある既知のリスクを記録します。たとえば、劣化している依存先、停止中のスケジュールタスク、一時的な回避策、変更後も監視中の項目などです。それぞれについて、確認に使えるシグナルと必要な対応を記載します。原因が立証されていない場合は仮説と明記し、相関関係を確定診断として扱わないでください。
復旧の限界も明確にする必要があります。元に戻せる操作は何か。データに影響する可能性がある操作は何か。復元を検証済みのバックアップがあるのか、それともバックアップポリシーが存在するだけなのか。復元や設定変更を誰が承認するのか。文書に記載された能力と検証済みの能力を区別すれば、根拠のない安心感を与えずに済みます。
複数のコンポーネントがあるシステムでは、関連する内部参照を使って依存関係と連絡先チームを記載します。外部API、データベース、キューの障害が、観測された症状の原因だと次の担当者が知っていると決めつけないでください。
簡潔なテンプレートを使い、実際に対応できるか確認する
テンプレートは、当番中に更新し続けられる程度に短く、判断を導ける程度に正確であるべきです。形式の例として仮のサンプルを示すことはできますが、各サービスの値は観測したデータに基づいて入力してください。
サービスと環境：[アプリケーション／コンポーネント／環境] 当番期間：[開始と終了、タイムゾーン] 現在の状態：[正常／劣化／対応中のインシデント] 確認された影響：[事実と判明している範囲] インシデント：[識別子、状態、参照先] 最後の確認：[時刻、シグナル、結果] 実施した対応：[変更と確認された結果] 次のアクション：[具体的な手順、担当者、期限] リスクまたは仮説：[シグナル、制約、見分け方] 該当するrunbook：[参照先と使用条件] エスカレーション：[連絡先と条件] 保留中の判断：[判断事項、担当者、確認日]
たとえばチームは、キューのアラートが継続していることを記録し、既存のインシデントにリンクし、その推移の確認を次の当番の役割に割り当てることができます。最後に観測した時刻と、正常化を確認できるしきい値またはシグナルを記載する必要があります。チケットのイベントをすべて複製する必要はありません。必要なのは、どこから対応を始め、次に何を確認するかを残すことです。
引き継ぐ側の視点で内容を検証する
文書が完全でも、使いやすいとは限りません。実践的な確認では、引き継ぐ人が、引き継ぎ担当者の記憶に頼らずに状態を説明し、最新の情報源を見つけ、最初のアクションを特定し、その結果を確認する方法を把握できるかを確かめます。同じ点について何度も質問が必要なら、形式やrunbookがニーズを満たしていません。
引き継ぎを定期的に見直し、空欄、リンク切れ、曖昧な担当者、誰も検証していない手順がないか確認します。インシデント後に得られた教訓は、引き継ぎのたびに参照しにくい履歴ファイルを増やすのではなく、runbookまたは適切なプロセスに反映します。
最終的な運用基準は明確です。事実と仮説を区別し、情報の鮮度を示し、次のアクションを割り当て、エスカレーションと検証の方法を定めます。こうすることで、並行する文書管理や追跡の仕組みを作らずに、当番交代後もコンテキストを維持できます。
