インシデント対応の基礎
現在、組織はクラウドのアクセシビリティ、効率性、および利便性の恩恵を受けていますが、クラウド サービスにビジネスの一部を移行することを伴うデジタル変革に伴い、多くの課題に直面しています。
組織で直面する可能性のある一般的な課題には、次のようなものがあります。
- サービスの中断回数の増加
- インシデントを追跡して対応するための効果的な方法がない (すべてがアドホックで復古的)
- 許容できない解決時間
- 解決までの時間が短縮されていないか、または悪化している
- 情報とステータスを見つけにくい
- 同じ問題と誤りの繰り返し
これらの課題に対応するには、堅固な基盤に基づいて明確に定義されたインシデント対応計画が必要です。
基礎と柱
基礎の目的は、その上に構造を保持することです。 このラーニング パスの別の概要モジュールでは、信頼性の作業が、監視という基本レベルの上に構築されており、インシデント対応は階層内でそのすぐ上にあるという考え方について説明しました。
インシデント対応にも基礎があります。 優れたインシデント対応計画を支える柱には、次の 3 つがあります。
- 名簿
- ロール
- ローテーション
このユニットでは、これらの各柱が何であるか、またこれらが、信頼性の目標に向けてさらに進むためのインシデント対応戦略の設計でどのような役割を果たすかについて説明します。
名簿
優れた計画を立てることは不可欠ですが、実行されなければ役に立ちません。 したがって、まず、問題に対応するメンバーを特定し、対応が必要になったときにそのメンバーに通知する方法を決定することをお勧めします。
この課題に対処する最善の方法は、名簿をデザインすることです。 名簿は、待機チームに割り当てられている人の一覧です。 このチームは複数のエンジニアで構成されている必要があります。 これらのチーム メンバーは、環境内で発生する可能性のある問題の種類に対処するための知識とスキルを備えている必要があるだけでなく、インシデント対応のトレーニングが必要です。
ただし、名前の一覧では不十分です。 特定の時点でどのメンバーが待機し、各メンバーが何を担当するかについてフレームワークを構築する必要があります。 そこで登場するのがロールです。
ロール
ロールは、無秩序、よく言ってもその場限りの対応に秩序をもたらします。 このためには、特定の状況で各メンバーが担当する具体的な役割と、"指揮系統" 内でのそれぞれの位置を定義します。ロールは組織によって異なる場合もあれば、インシデントの種類によって異なる場合もありますが、組織立ったインシデント対応チームには一般に、次のロールが必要です。
- 一次対応者: これは "連絡係" であり、通常は最初に駆けつける人物、つまりインシデントが発生したときに最初に呼び出される待機エンジニアです。
- 二次対応者: これは、控えとなるメンバーであり、一次対応者が対応できない場合、または 2 人目が必要な場合に対応することができます。
- 領域の専門家 (SME): オペレーションの特定の領域に詳しい知識を持っているメンバーです。 一次対応者や二次対応者が、より多くの専門知識を持つメンバーに問題をエスカレートする必要がある場合、SME にエスカレートします。 SME は常に待機しているわけではありませんが、特別なスキルが必要なときには連絡することができます。 さまざまな分野 (データベース、フロントエンド、ネットワーク インフラストラクチャ、Web アプリ、サイバーセキュリティなど) の SME の一覧を保持しておく必要があります。
- インシデント指揮者: 多くの異なるコンポーネントに影響を与える、または多くの異なるチームやシステム間で調整が必要になるような、大規模なインシデントまたは障害が発生した場合に重要な役割です。 インシデント指揮者は、対応と修復の活動に関する会話の大部分および作業を調整する人物です。 インシデント指揮者は "全体像" を常に監視し、何が起きているのか、だれが何をしているのかを把握します。 インシデント指揮者は、エンジニアが各自の修復作業に集中して取り組み、互いに作業を邪魔したり台無しにしたりしていないことを確認します。
- 記録係: 記録係の役割は、インシデントに関する会話を可能な限り詳細に文書化することです。 多くの場合、チームでは電話ブリッジ、電話会議、またはビデオ チャットを使用して全員を集め、何が起こっているかを把握しようとします。これは、会話のための場所を作るのに役立ちます。 しかし、エンジニアが何を言っているのか、何をしているのか、文字に起こしていない限り、詳細に理解することは困難です。 このため、記録係は、後でレビューできるように可能な限り文書化するのを担当する係です。 記録係は、チーム メンバーが何を行っているかだけでなく、何を言っているか、何を感じたり経験したりしているかなど、あらゆるデータを記録します。
- 連絡コーディネーター: この担当者は、インシデントの "広報マネージャー" と考えてください。 連絡コーディネーターは、インシデント指揮者と連携して、インシデントの解決と復旧に前面で取り組んでいない人々とインシデントに関する情報を共有します。 これには、顧客、営業およびマーケティング チーム、カスタマー サポート、組織内外のその他の利害関係者が含まれます。彼らは、発生していること、および対応と修復の進行状況を把握する必要があります。
ローテーション
これで、対応チームの担当者の名簿が作成され、適切なロールが割り当てられました。 次の最後の手順では、ローテーションを作成します。これは、各メンバーに待機のシフトを割り当てるスケジュールです。
シフトを分割するには、さまざまな方法があります。 シフトのスケジュール設定は、複雑な戦略プロセスになることがあります。 シフトをランダムに割り当てるべきではありません。できるだけ効果的で、チーム メンバーにとっても快適なシフトにするために、ある程度検討した上でスケジュールを設定する必要があります。
シフトをスケジュールする方法には、次のようなものがあります。
- 24 時間 365 日体制: これは、チーム メンバーが数日間連続して待機するローテーションです。 これは、シフト範囲を割り当てる簡単な方法ですが、期間を制限するように注意する必要があります。 3 から 4 日を超えるシフトのローテーションは、エンジニアリング スタッフの健康全般に悪影響を及ぼす可能性があるため、システム全体の信頼性が低下します。
- 日勤を基本にする: このシフト モデルでは、エンジニアは通常の就業時間内にのみ待機シフトをスケジュールし、就業日の終了時に、別のタイム ゾーンに配置されている別の同僚に待機責任を引き継ぎます。
これらは、シフトを割り当てる方法の例にすぎません。 重要な点は、対応チームの個人に最適な方法でシフトを分割することです。 特にエンジニアがシフトの柔軟性を必要とする週末については、シフトをカスタマイズする方法が数多くあります。 エンジニアは、仕事に関係のない競合が発生したときに、他の担当者に役割を簡単に引き継ぐことができる必要があります。