インシデント対応の基礎

現在、組織はクラウドのアクセシビリティ、効率性、利便性の恩恵を受けていますが、ビジネスの一部をクラウド サービスに移行するデジタル変革を受ける中で、多くの課題に直面しています。

組織で直面する可能性がある一般的な課題には、次のようなものがあります。

• サービス中断の数の増加
• インシデントを追跡して対応する効果的な方法はありません (すべてが即興で反作用的です)
• 許容できない解決までの時間
• 解決までの時間が改善されていないか、悪化しています
• 情報と状態を見つけるのが難しい
• 同じ問題と間違いの繰り返し

これらの課題に対応するには、強固な基盤に基づいて構築された明確に定義されたインシデント対応計画が必要です。

基礎と柱

基礎の目的は、その上の構造を保持し、一緒に保持することです。 このラーニング パスに対する別のイントロ モジュールでは、信頼性作業は監視の基本レベルに基づいて構築され、インシデント対応は階層内のそれと同じ上に置かれるという考え方について説明しました。

インシデント対応にも基盤があります。 適切なインシデント対応計画をサポートする 3 つの柱があります。

• 名簿
• 役割
• ローテーション

このユニットでは、これらの各柱の概要と、信頼性目標への道を進むインシデント対応戦略の設計でどのような部分を果たすかを確認します。

名簿

良い計画を立てるのは不可欠ですが、計画を実行する人がいなければ役に立ちません。 したがって、まず、問題に対応するユーザーを決定し、応答が必要になったときに通知する方法を決定します。

この課題に対処する最善の方法は、名簿を設計することです。 名簿は、オンコール チームに割り当てられているユーザーの一覧です。 このチームは、複数のエンジニアで構成されている必要があります。 これらのチーム メンバーには、環境内で発生する可能性がある問題の種類に対処するための知識とスキルと、インシデント対応のトレーニングが必要です。

ただし、名前の一覧では不十分です。 特定の時点で通話中のユーザーと、各ユーザーが何を行うかに関するフレームワークを構築する必要があります。 そこで役割が生まれます。

役割

ロールは、混乱した応答、またはせいぜい即興的な応答に秩序を与えます。 これは、特定の状況で各人が想定する特定の機能と、それぞれの「コマンドチェーン」の場所を定義することによって行われます。ロールは組織やインシデントの種類によって異なる場合がありますが、通常、次の役割は組織化されたインシデント対応チームの一部である必要があります。

• プライマリレスポンダー:これは、通常、シーンの最初の人である「ポイント人物」です。つまり、インシデントが発生したときに呼び出される最初のオンコール エンジニアです。
• セカンダリ レスポンダー: これはバックアップとして機能し、プライマリ レスポンダーが使用できない場合や、2 番目の目のペアが必要な場合にステップインできるユーザーです。
• 対象分野の専門家 (中小企業): これらは、業務の特定の側面に関する詳細な知識を持つユーザーです。 プライマリレスポンダーとセカンダリレスポンダーが、より多くの専門知識を持つ人に問題をエスカレートする必要がある場合は、そこにいます。 常に呼び出し中ではありませんが、特殊なスキルが必要な場合に利用できます。 さまざまな対象 (データベース、フロントエンド、ネットワーク インフラストラクチャ、Web アプリ、サイバーセキュリティなど) の中堅・中小企業の一覧を保持する必要があります。
• インシデントの指揮官: これは、多数の異なるコンポーネントに影響を与えたり、さまざまなチームやシステム間の調整を必要とする大規模なインシデントや停止において重要な役割を果たします。 インシデントの指揮官は、多くの会話と、対応と修復アクティビティに関する取り組みを調整する人物になります。 インシデント指揮官は状況全体を監視し、何が起こっているか、誰が何をしているかを把握しています。 インシデントの指揮官は、エンジニアが集中して作業を続け、互いの作業を妨げたり元に戻したりせずに自分の修復作業に取り組んでいることを確実にするために最適です。
• Scribe: 筆記者の役割は、インシデントに関する会話を可能な限り詳細に文書化することです。 Teams では、一般的に電話ブリッジ、電話会議、ビデオ チャットを使用して全員を集め、何が起こっているかを理解しようとします。これは、会話のスペースを作成するのに役立ちます。 しかし、文字起こしされない限り、エンジニアが何を言っていたのか、何をしているのかを詳しく理解することは困難です。 その結果、書記は、後で見直すためにできるだけ多くの情報を記録するのに役立つ人です。 筆記者は、可能なすべてのデータをキャプチャします。チーム メンバーが行っていることだけでなく、言っていることや、感じたり経験したりしていることも含まれます。
• コミュニケーション コーディネーター: この人物をインシデントの "広報マネージャー" と考えてください。 コミュニケーション コーディネーターは、インシデントの指揮官と連携して、インシデントに関する情報を、インシデントへの対処と復旧に積極的に取り組んでいないユーザーと共有します。 これには、顧客、営業チーム、マーケティング チーム、カスタマー サポート、組織内または組織外の他の利害関係者が含まれます。この関係者は、何が起こっているか、および応答と修復の進行状況を把握する必要があります。

ローテーション

これで、対応チームの担当者の名簿が作成され、適切なロールが割り当てられました。 次の最後の手順では、ローテーションを作成します。これは、各ユーザーが通話中のシフトを割り当てるスケジュールです。

シフトを分割するには、さまざまな方法があります。 シフト スケジューリングは、複雑な戦略的プロセスになる可能性があります。 シフトはランダムに割り当てることはできません。可能な限り効果的で、チーム メンバーにとって快適なものにするために、スケジュールを考慮する必要があります。

シフトをスケジュールする方法には、次のようなものがあります。

• 24 x 7: これは、チーム メンバーが数日間連続して呼び出されるローテーションです。 これはシフト カバレッジを割り当てる簡単な方法ですが、期間を制限するように注意する必要があります。 3 日から 4 日を超えるシフト ローテーションは、エンジニアリング スタッフの全体的な正常性に悪影響を与える可能性があるため、システム全体の信頼性が低下します。
• 太陽のシフトに従う:これは、エンジニアが通常の勤務時間にのみ通話シフトをスケジュールし、勤務日の終了時に別のタイム ゾーンにある別の同僚に通話時の責任を引き渡すシフト モデルです。

これらは、シフトを割り当てることができる方法のほんの一部の例にすぎません。 重要なポイントは、応答チームの個人に最適な方法でシフトを分割することです。 シフトをカスタマイズする方法は多数あります。特に、エンジニアがより柔軟に対応する必要がある週末の場合です。 エンジニアは、仕事に関連しない競合が発生したときに、誰かに簡単に役割を引き渡すことができる必要があります。