Capordia実際に引き継がれる責任の範囲を明確にする
対象となるプロジェクト、キャンペーン、期間を明記します。引き継ぎは、バッチの監視、その結果の受け入れ、エクスポートの準備などを対象にできます。ただし、業務上の判断、新しい期間の購入、ソフトウェアを変更する権限まで自動的に移るわけではありません。作業を引き受ける人、代理の人、範囲外の判断を仰ぐ責任者を指名します。
アクセスの準備と責任の引き継ぎは区別します。アクセス専用のガイドでは本人確認と権限を扱います。ここでは、受け取る人が用意された手段を使いこなし、適切な情報を見つけられるかを確認します。引き継ぎシートにパスワードを書いて渡さないでください。注文アカウントの参照情報と運用アクセスは、それぞれ異なる役割を担います。
ある時点の作業状況を正確に記録する
引き継ぎシートには、完了したタスク、進行中のタスク、待機中のタスク、未解決の差異を示す必要があります。この記録の時刻、有効なバージョン、最後の変更、次の作業も加えます。「すべて正常」といった一文は、タスクが一つ失敗しただけで古くなります。識別子と日時の記された状態があれば、同僚はシートと実際に観察した内容を突き合わせられます。
『Site Reliability Workbook』は、引き継ぎの冒頭に前回の引き継ぎを読み、次回に向けて書面による申し送りを準備することを述べています。GPU キャンペーンに合わせて、この原則をいくつかの有用な事実に当てはめましょう。予想される変化、止まっている作業、すでに試した対応、連絡済みの相手です。引き継ぎシートは次の判断を導くものであるべきで、すべてのメッセージを網羅する日誌になってはいけません。
観察・実行・停止を区別する手順を書く
運用手順（ランブック）は、ある状況と許可された操作を記述します。各操作について、その前提条件、期待される効果、実行後の確認、停止条件を示します。「必要なら再実行」を、対象タスクを特定し、すでに受け入れ済みの結果がないか確認し、同時実行を禁止するルールに置き換えます。手順が観察したケースを網羅していなければ、受け取る人は誰に連絡すべきか分かります。
提示する一覧はチームの判断を整理するものであり、Capordia 内にいかなる権限も付与しません。しきい値、担当者、ツールはプロジェクトに合わせて調整してください。また、コマンドを実行する技術的な可能性と、それを実行する許可を区別しましょう。機能的なアクセスがあっても、削除や新たな支出を承認するには不十分です。
| 状況 | 予定された操作 | 必要な判断 |
|---|---|---|
| タスクが常に稼働中 | その状態と最後の結果を観察する | 中断する前に |
| 手順で対応済みの失敗 | 出力を確認したうえで特定のタスクを再実行する | 原因が文書化されたケースと異なる場合 |
| 結果の差異 | 出力を別に保管し、責任者に知らせる | 公開または受け入れの前に |
| 期間終了が迫っている | エクスポートを準備し、残りの必要量を報告する | 新たに注文する前に |
受け取る人に次の対応を説明してもらう
短いペア作業の引き継ぎを行います。引き継ぐ同僚がシートを開き、タスクを一つ見つけて、次に何をするか、そして自分だけでは判断しないことを説明します。エクスポート先と採用した再開状態を特定してもらいましょう。引き継ぐ側がすべてを行ってしまうと、文書にまだ欠けている情報が見えなくなることがあります。
プロジェクトに不慣れな人の場合は、この引き継ぎを範囲を限定した実習で補います。Google SRE の学習に関する章では、知っておくべきドキュメント、専門家の連絡先、理解を確認する質問を区別しています。ここでは、試験範囲で日常的な操作を一つ選びます。理解を評価するために実際のインシデントを起こしたり、有効な処理を止めたりする必要はありません。
解決済みの例: 128件のタスクを二重起動せずに引き継ぐ
この架空の例では、Camilleが14時UTCにNoorへ引き継ぎます。キャンペーンには128件のタスクがあり、96件が承認済み、8件が進行中、24件が待機中です。96 + 8 + 24 = 128の合計が棚卸しと一致します。しかし、進行中の8件のうち2件は直前に失敗しています。引き継ぎの瞬間に突き合わせを行わなければ、Noorはすでに古くなったスナップショットを現在の状態として扱ってしまう可能性があります。
そこでCamilleは一覧を更新します。承認済み96件、進行中6件、失敗2件、待機中24件です。2件の失敗はすでに許可されている再開のケースに該当します。Noorは承認済みの出力やまだ稼働中のプロセスがないことを確認し、それらを待機中に戻します。状態は96 + 6 + 26 = 128になります。6件のアクティブなタスクは継続します。Noorは引き受けを確認し、次のチェックを記録します。Camilleはこの範囲でアクションを起動するのをやめます。
| 時点 | 承認済み | 進行中 | 失敗 | 待機中 |
|---|---|---|---|---|
| 突き合わせ前 | 96 | 8 | 0 | 24 |
| 更新後 | 96 | 6 | 2 | 24 |
| 許可された待機中への差し戻し後 | 96 | 6 | 0 | 26 |
不在、変更、引き継ぎの終了に対応する
引き継ぎ先が引き継ぎを確認できない場合は、あらかじめ決めた代理の人を使い、それまでの間は誰が責任者であるかを明確にしてください。明示的な受領がないまま複数人に送るメッセージは避けてください。すでにインシデントが起票されている場合は、除外した仮説と進行中のアクションもあわせて伝えてください。新たに担当する人が、すでに試みられた対応を黙って繰り返すべきではありません。
ソフトウェアの基準が変わるたびに、手順を更新し、何が古くなったかを知らせてください。必要な作業が終わったら、承認済みのエクスポート、残ったアクション、期限をプロジェクトの記録に紐づけてください。3日、7日、30日という期間は、同僚が作業を引き継いだからといって自動的に延長されるものではありません。必要であれば、次のレンタルは別途の判断と注文のままです。
判断のための質問
引き継ぎには長い文書が必要ですか？
いいえ。範囲、日付入りの状態、次のアクション、権限の範囲、有用な連絡先が示されていれば、短い記録で十分な場合があります。詳細な手順は、この記録からリンクしておきます。特に確認すべきなのは、引き継ぎ先が次のステップを見つけて説明できるかどうかです。
口頭のメッセージだけで作業を引き継いでもよいですか？
口頭でのやり取りはニュアンスの理解に役立ちますが、状態と引き継ぎの合意について日付入りの記録を残してください。これにより、すでに完了していたことと、これから行うことを区別できます。特に、引き継ぎの後に第三者が関与する場合に有効です。
手順に指示が欠けている場合はどうすればよいですか？
引き継ぎ先はその差異を記録し、データを変更したり作業を中断したりする可能性のあるアクションの前に、あらかじめ決められた責任者に確認してください。その後、その判断を範囲とともに手順に追記します。一度うまくいった即興が、自動的に一般ルールになるわけではありません。