レビュー日 · Hosmio リソース
始める前に
アプリケーションインベントリ、クライアント連絡先、現在の運用者、可能な代替者を集めること。VPSが利用できない場合でもアクセス可能なブリーフを保存する場所を用意すること。保護されたシークレットストレージを参照すること。資格情報をドキュメントに貼り付けないこと。
01
まずサービス境界を定義する。
アプリケーションを有用に保つために必要な作業をリストアップすること: アクセスレビュー、オペレーティングシステムの更新、ランタイム変更、データベースメンテナンス、バックアップ、監視、ドメイン更新。これをインフラストラクチャサプライヤーが実際に実行することに合意した作業と分けること。リセットボタン、オプションのバックアップ選択、サポート連絡先は、それ自体でマネージドサービス契約を確立しない。
所有者がまだ不明なものはすべて書き留めること。Hosmio については、最終的なサプライヤーの介入とサポート範囲の確認が必要である。今すぐ自分の責任を計画することで、アプリケーションインシデントがホストによって自動的に診断されると仮定することを避けられる。
02
アクションと決定権限を割り当てる。
| アクティビティ | 担当役割 | トリガーとチェック |
|---|---|---|
| アプリケーションリリース | アプリケーション運用担当者、指名されたバックアップ | 承認済み変更、テストサインインおよび代表的なタスク |
| サービス停止を伴うメンテナンス | クライアント変更承認者 | 既知の影響時間帯、明示的な go/no-go |
| リカバリ演習 | リカバリ運用担当者 | 予定されたリハーサル、復元されたレコードと添付ファイルの確認 |
| インシデントコミュニケーション | 現インシデントオーナー | 重大な影響を伴う変更、タイムスタンプ付き引き継ぎ |
| 支払い例外 | 購買担当窓口 | 不一致または不確実な結果、事実に基づく支払い詳細を保持 |
役割は、チームが到達可能な担当者を割り当てて初めて有用になります。現在の割り当てを非公開の運用ノートに記録してください。1人が複数の役割を担うこともありますが、この区別により、技術者が誤ってクライアントを代表してビジネスリスクを承認することを防ぎます。
03
変更とその停止点に合意する。
計画された更新では、なぜ必要か、何が変わるか、影響を受けるサービス、既知の状態に戻す方法を記録します。中断を承認できる人と、チェックが失敗した場合に作業を停止できる人を指定します。明示的なタイムゾーンを含む合意された時間帯を使用してください。国際チームにとって「営業時間外」は曖昧です。
作業開始前に、アクセス、リカバリコピー、変更される正確なバージョンまたは構成を確認します。チームが受け入れチェックに合格するか、リカバリ計画を発動しなければならない期限を設定します。実際のリハーサルがその期待を裏付けない限り、ロールバックを即時と表現しないでください。
04
アクションにつながるシグナルを選択する。
ユーザータスクから始めます。代表的なアカウントがサインインでき、期待されるレコードを読み取り、安全な操作を完了できるか。失敗の説明に役立つリソースと依存関係のチェックを追加します。バックグラウンドキューが進行しなくなっても、アプリケーションが基本的なヘルスリクエストに応答することがあります。
エスカレーションしきい値は、プロジェクトのニーズと観察から選択します。概説的なポータルでは、スケジュールされたタスクチェックの2回の失敗を、普遍的な障害定義ではなく調査のきっかけとして扱うかもしれません。チェックの実行方法と、運用担当者が次に何を確認すべきかを記録します。責任ある受信者を伴わないアラートはカバレッジを生み出しません。
05
インシデントの前に代替を準備する。
交代の運用担当者が、指導なしにインベントリ、保護されたアクセス手順、最新の変更記録、リカバリノートを見つけられるようにします。既知の事実と未検証の仮説を区別できる必要があります。アクセスを便利にするためだけに個人アカウントを共有するのではなく、役割に適した権限を与えてください。
インシデントのタイムスタンプは曖昧にしないでください。RFC 3339 は UTC または明示的なオフセットによるタイムスタンプ表現を定義しています。次のような記録は 2026-09-12T14:00:00Z 説明のないローカル時計の値を避けます。 RFC 3339: インターネットタイムスタンプ ↗ 参照 タイムゾーン引き継ぎガイド 現在のオーナーシップのより完全な移行のために。
06
ブリーフをリハーサルし、ギャップを記録する。
文書に依存する前にテーブルトップ演習を行います。プライマリ運用担当者が不在の間に、バックグラウンドジョブが失敗したという仮想シナリオを提示します。交代担当者に、影響、許可されるアクション、承認経路、次の更新を特定してもらいます。概要の存在を実証するためだけに実際のサービス変更を行わないでください。
不足している権限、不明確なオーナーシップ、アクセスできない文書を、オーナー付きのアクションとして記録します。スタッフ、統合、リカバリ目標、サプライヤーが変更されたときに概要を見直します。完了とは、別の権限を持つ人がプロセスに従いその限界を説明できることを意味し、継続的なサポートチームが確立されたことを意味するものではありません。
次に進む プロバイダー退出リハーサル および インシデント概要テンプレート。運用概要は問題発生時に使用できる程度に簡潔にし、必要に応じて詳細な手順にリンクしてください。