Google Cloud アーキテクチャ フレームワークのこのドキュメントでは、サービスを管理し、インシデントに対応するプロセスを定義するためのベスト プラクティスについて説明します。インシデントは、すべてのサービスで発生するため、効率的に対応してこの問題を軽減するには、詳細が文書化されたプロセスが必要です。
インシデント管理の概要
適切に設計されたシステムでも、いつかは SLO を下回ることになります。SLO がない場合でも、ユーザーにより過去の経験に基づいて許容可能なサービスレベルが大まかに定義されます。SLA の内容に関係なく、テクニカル サポートや同様のグループにエスカレーションされます。
ユーザーに適切なサービスを提供するため、インシデント管理計画を確立し定期的にテストします。その計画は、1 ページで 10 項目のチェックリストのような短いものでかまいません。このプロセスによって、チームは検出時間（TTD）と軽減時間（TTM）を短縮できます。
TTR ではなく TTM が推奨されます。TTR の R は、修復または復元を意味し、軽減策ではなく完全修正を意味するからです。TTM は、停止による顧客への影響を迅速に終了させる迅速な軽減を重視し、問題を完全に解決するために通常より長いプロセスを開始します。
優れた操作性を備えたシステムを設計すれば、故障間隔時間（TBF）が長くなります。つまり、優れたインシデント管理などの信頼性を確保するための運用原則は、障害の発生頻度を低くすることを目標とします。
信頼性の高いサービスを実行するには、インシデント管理プロセスに次のベスト プラクティスを適用します。
明確なサービス オーナーを割り当てる
すべてのサービスとそれらの重要な依存関係には、SLO を遵守する明確なオーナーが必要です。再編成やチームの人員削減が行われる場合、エンジニアリング リードは、必要に応じてドキュメントやトレーニングとともに、所有権を新しいチームに明示的に引き継ぐ必要があります。サービスのオーナーが他のチームからも簡単にわかるようにする必要があります。
適切に調整されたアラートによって検出時間（TTD）を短縮する
TTD を短縮する前に、インフラストラクチャとアプリケーションへのオブザーバビリティ組み込みで最適化案を審査して実施し、アーキテクチャ・フレームワーク信頼性カテゴリのセクションを信頼性の目標と定義します。たとえば、アプリケーションの問題と基盤となるクラウドの問題を明確に区別します。
適切に調整された一連の SLI は、アラートの過負荷を発生させることなく、適切なタイミングでチームに通知します。詳細については、アーキテクチャ フレームワーク信頼性カテゴリの効率的なアラートを作成するセクションまたは SLI 指標の調整: CRE ライフレッスンを調整するをご覧ください。
インシデント管理計画とトレーニングによって軽減時間（TTM）を短縮する
TTM を短縮するには、文書化され、十分に訓練されたインシデント管理計画を定義します。環境の変更点に関するデータは、すぐに入手できるようにしてください。迅速に適用して TTM を最小化できる一般的な緩和策をチームに周知してください。これらの緩和策には、ドレイン、変更のロールバック、リソースの規模拡大、サービス品質を低下させることが含まれます。
別のアーキテクチャ フレームワークの信頼性カテゴリに関するドキュメントで説明されているように、信頼性の高い運用プロセスとツールを作成して、変更の安全性と迅速なロールバックをサポートします。
ダッシュボードのレイアウトとコンテンツを設計して TTM を最小化する
サービス ダッシュボードのレイアウトとナビゲーションを整理して、サービスとそのすべての重要な依存関係が実行されているかどうかをオペレータが 1～2 分で判断できるようにします。問題の潜在的な原因をすばやく特定するには、ダッシュボード上のすべてのグラフをスキャンして、アラートの時点で大幅に変化するグラフをすばやく探し出すことができるようにする必要があります。
トラブルシューティングに役立つよう、以下に例示するようなグラフがダッシュボードに表示されることもあります。インシデント対応者は、単一のビューから以下を一目で確認できる必要があります。
- サービスレベル指標（成功したリクエストを有効なリクエストの合計数で割ったなど）
- 構成やバイナリのロールアウト
- システムへの 1 秒あたりのリクエスト数
- システムからの 1 秒あたりのエラー レスポンス数
- システムからその依存関係への 1 秒あたりのリクエスト数
- 依存関係からシステムへの 1 秒あたりのエラー レスポンス数
トラブルシューティングに役立つその他の一般的なグラフには、レイテンシ、飽和度、リクエスト サイズ、レスポンス サイズ、クエリ費用、スレッドプール使用率、Java 仮想マシン（JVM）の指標（該当する場合）があります。飽和度とは、割り当てやシステムメモリ サイズなど、一定の上限による完全性のことです。スレッドプールの使用率は、プールの枯渇による回帰を探します。
いくつかの停止シナリオに対してこれらのグラフの配置をテストし、最も重要なグラフが上部に近くなり、グラフの順序が標準の診断ワークフローと一致するようにします。また、ML と統計的異常検出を適用して、これらのグラフの適切なサブセットの表示もできます。
既知の停止シナリオの診断手順と軽減策を文書化する
ハンドブックを作成し、アラート通知にハンドブックへのリンクを追加します。アラート通知からこうしたドキュメントにアクセスできると、オペレータがトラブルシューティングと問題の軽減に必要な情報をすばやく入手できます。
過失を責めない事後検証により、サービス停止の教訓を活かして再発を防止する
過失を責めない事後検証の文化とインシデントのレビュー プロセスを確立します。過失を責めないとは、チームが過失を責めることなく、問題点を客観的に評価して文書化することを意味します。
失敗は学習の機会とみなされ、批判の対象にはなりません。システムの復元力を高めて、人為的ミスから迅速に回復できるようにするか、さらには人為的ミスを検出して防止できるようにします。それぞれの事後分析からできるだけ多くの学習を抽出して事後分析のアクション アイテムに注意しながら対処し、サービス停止の回数を減らして TBF を増加させます。
インシデント管理計画の例
本番環境の問題が、アラートやページなどから検出された、または自分にエスカレーションされました。
- 他の誰かに委任する必要がありますか？
- 自分たちで解決できない場合は、「はい」です。
- これはプライバシーやセキュリティの侵害ですか？
- 「はい」の場合、プライバシー チームまたはセキュリティ チームに委任します。
- この問題は緊急事態ですか、あるいは SLO が達成できなくなる恐れがありますか？
- 疑わしい場合は、緊急事態として処理します。
- 人員を増やす必要がありますか？
- お客様の X% 以上に影響が及ぶ場合、あるいは解決に Y 分以上かかる場合は、「はい」です。疑わしい場合は、（特に営業時間中には）より多くの人員で取り組みます。
- メインの通信チャネル（IRC、Hangouts Chat、Slack など）を定義します。
- 次のような事前定義のロールを委任します。
- 全体的な調整を担当するインシデント コマンダー。
- 内部および外部のコミュニケーションを担当するコミュニケーション リーダー。
- 問題の軽減を担当するオペレーション リーダー。
- インシデントがいつ終了するかを定義します。この決断には、サポート担当者や他の同様のチームからの承認が必要になります。
- 過失を責めない事後分析に協力します。
- 事後分析インシデント レビュー会議に参加して話し合い、タスクの割り当てを行います。
推奨事項
アーキテクチャ フレームワークのガイダンスを実際の環境に適用するには、次の推奨事項に従ってください。
- インシデント管理計画を確立し、それを使用するチームをトレーニングします。
- TTD を短縮するには、インフラストラクチャとアプリケーションにオブザーバビリティを組み込むための推奨事項を実装します。
- インシデントがあるときに一目で確認できる、「変更内容」ダッシュボードを作成します。
- クエリ スニペットを文書化するか、頻繁なログクエリを使用して Looker Studio ダッシュボードを構築します。
- Firebase Remote Config を評価して、モバイル アプリケーションのロールアウトの問題を軽減します。
- 障害復旧のテストを実施し、バックアップからデータを復元するなどして、インシデントのサブセットの TTM を短縮します。
- 構成とバイナリのロールバックを設計してテストします。
- 障害復旧のためにリージョン間でデータを複製し、障害復旧テストを使用して、リージョンの停止後の TTM を短縮します。
- TBF を増やすために、高可用性に対するビジネスニーズによりコストが正当化される場合には、リージョンの停止に対する耐障害性を確保するためのマルチリージョン アーキテクチャを設計します。
次のステップ
詳細については、次のリソースを使用して共同インシデント管理プロセスを構築する方法をご覧ください。
アーキテクチャ フレームワークの他のカテゴリ、たとえば、システム設計、オペレーショナル エクセレンス、セキュリティ、プライバシー、コンプライアンスなどを確認する。