サイト信頼性エンジニア(SRE)の世界では、故障はオプションであるだけでなく、期待されるものです。 システム、Webアプリケーション、サーバ、デバイスなど、パフォーマンスの問題や予期しない停止が発生しやすくなります。 それはやむを得ない事実です。 これらの予期せぬ失敗は、巨額の収益損失、顧客の信頼、そして業界によっては罰金につながる可能性があります。 幸い、SRE インシデント管理は、予期しない問題によって発生する中断を制限するために使用されるコア プラクティスの 1 つです。 別の記事では、 カオスエンジニアリング について、そしてSREチームが最悪の事態を防ぐために失敗を積極的に探し出し、テストする方法について説明しました。 しかし、私たちが知っているように、問題は亀裂をすり抜ける可能性があります。 目標は、これらのインシデントが大規模な連鎖障害にならないようにすることです。 SR と DevOps チームは、これらのインシデントを利用して、システムとサービスをより良く構築し、改善することができます。
インシデントとは
このトピックについて詳しく説明する前に、まずインシデントとは何かを説明する必要があります。 即時の行動を必要とするものと後で調査できるものの間に線が引かれている場所はどこですか? すべての問題が緊急に分類された場合、誰も解決を得ることはありません。 IT (情報技術) のコンテキストでは、インシデントは、通常の運用やサービス品質を妨害するイベントまたは問題です。 失敗は発生しませんが、チェックを外した場合は、サービスや運用に大きな影響を与える可能性があります。 そして、彼らは通常、あなたが至福の眠っている間に午前2時に起こり、あなたの携帯電話が消える音で目を覚ます。 私たちはもちろん冗談ですが、朝早く起こった場合、何かが悪いことを知っています。 特にIT業界について話している場合は、2:00 a.m.では何の良い問題も起こりません。
インシデント管理とは
インシデントとは何かについて説明したところで、インシデント管理は、チームがこれらのイベントを解決し、システムとサービスを通常の動作に戻すプロセスです。 また、インシデント管理は IT サービス管理 (ITSM) と呼ばれる大きな概念の一つの要素に過ぎないことに注意する必要があります。 ITSMは、チームがサービスを設計、作成、提供する方法を定義します。 これは、IT サポート以上のものです。 ITSMは、ITサービスのライフサイクルの背後にあるポリシー、プロセス、構造です。 ITSM は、ITIL の情報技術基盤ライブラリのプラクティスの 1 つです。
ITIL は、ITSM ソリューションを構築するためのフレームワークとガイドラインを提供します。 ビジネス プロセス フレームワーク (eTOM)、情報および関連技術の制御目標 (COBIT)、FitSM、ISO/IEC 20000、マイクロソフトオペレーション フレームワーク (MOF) など、他のフレームワークにすでに精通している場合があります。
IT サービス管理 (ITSM) フレームワーク
ITSMフレームワーク内の要素に少し焦点を当てると、ITSMの「ホイール」を構成するコンポーネントがインシデント管理と共に6つあります。 これらについては詳しく説明しませんが、これらのすべての部分がインシデント管理とどのように組み合わされているかを理解することが重要です。
サービスカタログ
IT サービス カタログは、通常、運用サービスやサービスに関する情報をユーザーに提供するために組織が作成するデータベースまたはリソースです。 これらのサービス カタログは、現在のサービスと計画されているサービス、価格、購買プロセス、連絡先、およびその他の成果物に関する有用な情報を提供します。
サービスデスク
サービス デスクは、内部の従業員、利害関係者、顧客など、サービス プロバイダーとユーザーの間の窓口と考えることができます。 これは、ユーザーが支援とサービスを受けるために行く中心的な「ハブ」です。 ITIL の定義では、サービス デスクはインシデント解決またはサービス要求の形をとることができますが、どのような場合でも、サービス デスクの主な目標は、迅速かつ効率的なサービスを提供します。
問題管理
インシデント管理について説明すると、SRE チームはインシデントを迅速に解決できる場合がありますが、根本的な問題は存在し、しばらく続く可能性があります。 問題管理とは、インシデントの根本原因を永続的に修正するプロセスであり、長期的なパフォーマンスと将来のサービス展開を改善します。
変更管理
新しいサービス展開や個人的な変更について話しているかどうかにかかわらず、どのような種類の変更でも、常にリスクの要素があります。 変更管理とは、変更がサービスの展開に与える影響を判断するプロセスです。 変更管理は、リリース管理とグループ化されることもあります。
資産管理
すべてを仮想化することはできません。尚。 ソフトウェア サービスは、機能するために物理デバイスとハードウェアを必要とします。 また、組織は、これらのデバイスを追跡、管理、および継続的に更新して、サービスが円滑に実行されるようにする必要があります。 資産管理は、IT資産管理(ITAM)とも呼ばれます。
知識、方針、手順の管理
ナレッジ マネジメントの目的は、組織内の情報の収集、確認、共有という観点から冗長性を軽減することです。 これにより、効率性が向上し、情報の一貫性、最新の状態、および使用可能な状態が保証されます。
インシデント管理ライフサイル: プロセスと手順
ダウンタイム、セキュリティ侵害、サイバー攻撃、あるいは長期の遅延や繰り返しエラーなど、インシデントに対する組織の対応は、顧客またはエンド ユーザーからのビジネスと信頼の継続的な成功にとって重要です。 SR は、複雑な分散システムを管理する必要があります。 これらのシステムの利点は、信頼性、拡張性、フォールト トレラント性が高い点ですが、非常に複雑になり、問題の検出と特定が困難になるため、修復時間が長くなる可能性があります。 最高のSREインシデント管理チームは、厳格なインシデント管理と修復プロセスに準拠します。 実際の手順とプロセスは組織によって異なる場合がありますが、ほとんどが同じ基本的なパスに従います。 SRE インシデント管理プロセスと手順を見てみましょう。
インシデントの識別
わからない問題は修正できません。 インシデントの識別は、何らかの形で監視または警告メカニズムから始まります。 分散システムの監視については別の記事で説明し、SREチームとの関係について説明しました。 エラー、ダウンタイム、またはアプリケーションの遅延が発生する時期と場所を把握することは、ユーザーと顧客への影響を制限するうえで重要な要素です。 しかし、場合によっては、サポートチケット、電話、ソーシャルメディアを通じてインシデントが判明し、すべての人が公に問題を投稿しても決して良いニュースではありません。
インシデントログ
検出方法が何であれ、インシデントが特定されると、インシデントをログに記録する必要があります。 インシデント ログは、複数の目的で使用されます。 送信された正式レコードが存在し、後でインシデントの傾向を確認するためのものが確実に存在します。 同じ、または類似したインシデントが繰り返し表示される場合は、対処する必要があるより複雑な問題を示している可能性があります。 インシデントをログに記録する場合、タイムスタンプ、インシデントの説明、問題を発見したユーザーなど、関連情報も含まれます。 より詳細な情報は、より良いです。
インシデントの分類
次に、重大度、緊急度、影響を受ける機能領域などの要因に基づいてインシデントを分類します。 インシデントのログと同様に、後で提供される情報が多いほど、インシデント対応に割り当てる適切なチームまたは個人を決定する際に役立ちます。
インシデントの優先度設定
インシデントがどのように分類されたかに基づいて、次の手順では優先度レベルを設定します。 繰り返しますが、これらのステップの一部は同時に発生するため、場合によっては同時に実行される場合があります。 組織では通常、低、中、高という単純なスケールを使用しますが、影響を受けたものに応じて特定のカテゴリに分類されるインシデントもあります。 たとえば、インシデントが停止に関連している場合、自動的に高優先度に分類されます。
インシデント対応、解決、および閉鎖
最後のステップは、最終的に対応し、閉鎖をもたらすためにインシデントを解決することです。 この最後のステップは、科学というより芸術の形です。 ここには簡単なボタンはありません。 数サイクルを要し、インシデントが最終的に解決されたことを確認しようとします。 各試行は、インシデントが発生している理由に関するより多くの情報と追加の理論をもたらすことができます。 これはまた、弱点が存在する可能性があるさらなる機会を特定することにつながる可能性があります。 インシデントが処理されたら、要求を閉じ、インシデントを報告した元のユーザーに応答します。
死後
インシデント対応の後、通常はインシデントの詳細を完全に確認することをお勧めします。 これはインシデントの事後分析と呼ばれます。 事後分析が必要なインシデントを決定することは、通常、チームまたは組織によって決定されます。 事後分析は、改善できる領域の特定、パフォーマンスの盲点の特定、およびインシデント対応プロセスの改善に役立ちます。 事後分析は、インシデントのすべての側面を要約し、次の要素を含める必要があります。
- インシデントの概要とタイムライン。
- 根本原因の分析とインシデントの原因。
- インシデントを解決するために実行されたアクションと、どのインシデントが有効であるか、または有効でないか。
- 今後のインシデント防止と、発見された追加情報。
死後は SRE文化の中核的なルールの1つです。 実際、彼らはそれを非難のない死後と呼びます。 このコンセプトの背後にある考え方は、チームの全員が最善の意図を持って行動し、誰も事件の責任を負わないということです。 その理由と、システムパフォーマンスを改善する方法を特定することに重点を置いています。 間違いは業界の自然な部分なので、個人を非難するのではなく、問題が二度と起こらないように、より堅牢で弾力性のあるシステムを作ることに焦点を当てています。
SRE インシデント管理: ツールとサービス
現在、SRは、ワークロードの自動化と管理を支援する幅広いツール、プラットフォーム、サービスへのアクセスと機会が無制限に見えます。 これらのツールの一部は別の記事で既に取り上げられていますが、具体的には SRE インシデント管理ツールについて説明します。
読む: トップ 13 サイト信頼性エンジニア (SRE) ツール
インシデント、アラート、およびコミュニケーションツール
インシデント管理、通信、およびアラートツールは、SREチームが利用する最も重要なツールの一部です。 チームが早く気づくと、インシデントの迅速な管理が可能になります。 これらのツールは、監視戦略と共に使用する必要があります。 Dotcom-Monitor プラットフォームは、これらのツールと統合され、監視と監視の目標にチームが既に使用している可能性のあるツールをシームレスに組み込むことができます。
ページャーデューティ
PagerDuty は、組織固有の監視要件に基づいてアラートを特定し、トリガーするのに役立ちます。 インシデントの識別段階を自動化することで、チームは手動による監視の量と、インシデント管理プロセスの開始に必要な時間を削減できます。 適切なチームに直ちに通知が行われるため、インシデント対応はできるだけ早く行うことができます。
ビクターオップス
現在 Splunk On-Call はインシデントの解決にかかる時間を短縮し、SR と DevOps チームがインシデント対応プロセスを効率的に管理する方法を提供するインシデント自動化プラットフォームです。 Splunk On-Call は、オンコールスケジュールとインシデントエスカレーションポリシーの簡素化にも役立ちます。
スラック
真のインシデント対応ツールではありませんが、通信はインシデント対応プロセスの重要な要素です。 市場で最も有名で人気のあるチャットアプリケーションの1つであるSlackは、SREチームにすべての通信を1つのダッシュボードに取り込む機能を提供します。 会社間通信に最適な Slack は、応答やイベントを自動化し、他のシステムやサービスに接続することもできます。
Microsoft Teams
組織で Office 365 を使用している場合は、Microsoft Teamsを既に認識している可能性があります。 Slack と同様に、Microsoft はオンライン メッセージング、ビデオ チャット、ドキュメント共有などの機能を提供するリアルタイムの通信アプリケーションです。
オプスゲニー
別のインシデント対応ソリューションである OpsGenie は、グループとフィルタリング メカニズムを使用して自動アラートを設定および構成する機能をチームに提供します。 さらに、SR はオンコール ルーティング ルールと特定のエスカレーション ポリシーを管理できます。 OpsGenie にはレポートや分析などの機能も用意されているので、チームはインシデント対応の指標と効率を確認して追跡できます。
結論: SRE インシデント管理 – 概要、テクニック、ツール
SRE インシデント管理は、システム、アプリケーション、サイト、サービスを稼働状態に維持するために不可欠です。 秒は、特にユーザーのエクスペリエンスに関しては重要です。 大規模な分散システムでは、最小の問題が原因で、連鎖問題が発生する可能性があります。 適切なアラートと通知を事前に設定することは、問題が発生したときに違いがあり、ユーザーへの影響が制限されることを保証します。 Dotcom-Monitor プラットフォームとこれらのインシデント管理ツールを統合する方法の詳細については、 ナレッジベースをご覧ください。
30日間無料のDotcom-Monitorを試してみて、プラットフォーム内のすべてのソリューション、統合、機能にアクセスしてください。
