インシデント管理 - パターン

Well-Architected Operational Excellenceの詳細 → インシデント管理

パターン

参照すべき場所外観
プラットフォーム | 監視✅ アラートアーキテクチャには、重大度分類によって重要なインシデント (本番が使用できない、データが破損している、セキュリティ侵害がある) をすぐにオンコールのページにルーティングすることが含まれます。
プラットフォーム | 監視✅ 重大度の高いインシデント (パフォーマンスの低下、部分的な停止) では、営業時間を迅速に調査するための通知がすぐに生成されます。
プラットフォーム | 監視✅ 警告 (しきい値に近づいている、設定ドリフト) が日次ダイジェストに集計され、プロアクティブな修正が可能
プラットフォーム | 監視✅ アラート強化には、影響を受けたユーザー数、エラー率 (パーセント)、最近のリリース、関連アラート、ダッシュボードの直接リンクなどの診断コンテキストが含まれます。
プラットフォーム | 監視✅ アラートコンテキストにより、個別のクエリで基本情報を収集することなく、状況を即座に評価できるため、承認までの平均時間が短縮されます。
プラットフォーム | 監視✅ アラートのグループ化により、1 つの根本問題に関連する数百件のアラートを集計統計を含む 1 つの通知に統合することで、アラートの嵐を回避
プラットフォーム | 監視✅ グループアラートには、件数、レート、影響を受けたトランザクションが表示され、回答者を圧倒することなく問題パターンを明らかにすることができます。
プラットフォーム | 監視✅ アラートの抑制により、予想されるメンテナンス期間や自動修正期間中に既知の一時的な状況でアラートが生成されないようにします。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | 監視⚠️ インテグレーションの失敗により、5 分間で 100 件の個別のアラートが生成されます。各アラートはタイムスタンプを除き同じです。
プラットフォーム | 監視⚠️ アラートの範囲、最近の変更、問題パターンに関するコンテキストがないため、オンコールエンジニアが基本情報を手動で収集する必要がある
プラットフォーム | 監視⚠️ すべてのアラートは重要度に関係なく同じチャネルを通過し、重大な本番の停止は軽微な警告と競合
プラットフォーム | 監視⚠️ スケジュールされたメンテナンス期間中にアラートが起動し、監視システムに対するTrustを損なう偽陽性を生成
プラットフォーム | 監視⚠️ アラートグルーピングが存在しない。トランザクションの失敗ごとに個別のアラートが起動し、インシデント中にアラートストームが発生する
プラットフォーム | 監視⚠️ アラートには関連するダッシュボードへのリンクがないため、回答者はインシデント対応中に監視ツールを見つけるのに時間がかかります。

パターン

参照すべき場所外観
プラットフォーム | 運用✅ オンコールのローテーションは、コンテキストの保存に対する負荷の分散を毎週または隔週に調整
プラットフォーム | 運用✅ Runbook はアラート種別ごとに文書化されるため、オンコールエンジニアは専門分野の専門知識がなくても効果的に対応できます。
プラットフォーム | 運用✅ Runbook には、問題の説明、診断ステップ、修正手順、エスカレーション条件、関連ドキュメントリンクが含まれます。
プラットフォーム | 運用✅ Runbook は、死後のアクション項目によって進化するバージョン管理された生きたドキュメントです。
プラットフォーム | 運用✅ 引き継ぎ手順には、有効な問題、最近の変更、既知のリスク、今後のメンテナンスなど、状況移行中の簡単なミーティングが含まれます。
プラットフォーム | 運用✅ 手書きのハンドオフノートで口頭でのハンドオフを補完し、ローテーション移行中の情報の損失を防止
プラットフォーム | 運用✅ ページ頻度、業務時間外インシデント数、偽陽性率を測定し、アーキテクチャの修正が必要な継続的なオンコール負荷を特定します。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | 運用⚠️ Runbookが存在しない。オンコール エンジニアは、部族のKnowledgeと専門分野のエキスパートへの頻繁なエスカレーションを必要としている
プラットフォーム | 運用⚠️ Runbook は、チームメンバーがアクセスして更新できる共有バージョン管理ではなく、個人文書に保存されます。
プラットフォーム | 運用⚠️ オンコールのローテーション移行は、引き継ぎミーティングなしで行われます。新しいエンジニアは、有効な問題や最近の変更に関するコンテキストがありません。
プラットフォーム | 運用⚠️ アーキテクチャの改善を促進するのではなく、運用上の英雄を通じて、高いオンコール負担が無期限に続く
プラットフォーム | 運用⚠️ オンコール評価指標 (ページ頻度、業務時間外インシデント、偽陽性) は追跡されず、負担パターンは表示されないまま
プラットフォーム | 運用⚠️ Runbook は初期リリース時に 1 回作成され、システムの進化や新しい障害モードの発生時に更新されることはありません。

パターン

参照すべき場所外観
プラットフォーム | 運用✅ テクニカルエスカレーションパスでは、特定の問題ドメインを処理する専門分野のエキスパートを定義します。
プラットフォーム | 運用✅ 管理エスカレーションパスでは、重大度または期間のしきい値を超えるインシデントの通知を受信するマネージャーを定義します。
プラットフォーム | 運用✅ ベンダーエスカレーションパスのドキュメント Salesforce サポートのケース作成手順と重要度条件
プラットフォーム | 運用✅ エグゼクティブエスカレーションパスでは、ビジネスクリティカルなインシデントの通知を受信するエグゼクティブを定義します。
プラットフォーム | 運用✅ エスカレーション条件が明示的かつ客観的である: 重要度レベル、時間のしきい値、影響を受けるユーザー数、ビジネスへの影響評価
プラットフォーム | 運用✅ エスカレーションパスはランブックに文書化され、インシデント中に連絡先情報を検索することなくアクセスできます。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | 運用⚠️ エスカレーションパスが文書化されていない。オンコールエンジニアがインシデント中に適切な取引先責任者を検索するのに時間を浪費する
プラットフォーム | 運用⚠️ エスカレーション条件が曖昧 (「 悪いと思われる場合はエスカレーションする」) で、回答者がエスカレーションのタイミングに関する明確なガイダンスがない
プラットフォーム | 運用⚠️ 重要度しきい値が定義されていないため、管理通知が遅すぎる。エグゼクティブがユーザーからインシデントについて学習する。
プラットフォーム | 運用⚠️ Salesforce サポートのエスカレーション手順が文書化されていない。チームはサポートケースのオープンを遅らせ、貴重な応答時間を失う
プラットフォーム | 運用⚠️ 専門分野のエキスパートの連絡先が古い。エスカレーションが誤ったユーザーに到達したり、ローテーションの変更に失敗したりする

パターン

参照すべき場所外観
プラットフォーム | 運用✅ 重大な業務イベント後 5 営業日以内に非難のないインシデント後レビューを実施
プラットフォーム | 運用✅ 個人の責任ではなくシステムの改善に焦点を絞った非難のない文化により、正直な評価のための心理的安全性が創出される
プラットフォーム | 運用✅ タイムラインには、初期条件から最初のシグナル、検出、確認、調査、対応、復旧、検証までの詳細な順序が含まれます。
プラットフォーム | 運用✅ 検知、対応、復旧フェーズの期間分析を可能にする各イベントのタイムラインタイムスタンプ
プラットフォーム | 運用✅ 根本原因により、インシデントを直接引き起こした技術的な不具合や状態を特定し、要因と区別
プラットフォーム | 運用✅ 要因分析により、インシデントの影響を有効化または増幅した組織、プロセス、またはアーキテクチャの状態を明らかにします。
プラットフォーム | 運用✅ 検知分析ではインシデントの検知方法と検知を高速化できたかどうかを評価
プラットフォーム | 運用✅ 対応評価により、対応中にうまくいったこと、必要以上に遅かったこと、大変だったことを特定
プラットフォーム | 運用✅ アクション項目は、特定、割り当て済み、期限付きで、再発を防止したり、今後の対応を改善したりできます。
プラットフォーム | 運用✅ アクション項目は、具体的なタスクを優先するためにあいまいな改善 (「 監視の改善 」) を避けます (「 10 分以上の API エラー率が 5% を超えた場合のアラートの追加 」)。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | 運用⚠️ インシデント後のディスカッションで「一括処理ジョブにバグがありました。修正しました。」と結論付けられますが、ドキュメントや体系的な改善はありません。
プラットフォーム | 運用⚠️ インシデント後レビューでは、システムの改善ではなく個々の障害に焦点が絞られ、心理的安全性が損なわれます。
プラットフォーム | 運用⚠️ タイムラインに期間分析を妨げるタイムスタンプがないため、チームは検出または応答が遅かったかどうかを特定できない
プラットフォーム | 運用⚠️ 根本原因分析では、直接的な技術的原因と組織またはプロセスの寄与要因は区別されません。
プラットフォーム | 運用⚠️ 検知分析はスキップされます。ユーザーがインシデントを最初に報告できる監視ギャップは特定されません。
プラットフォーム | 運用⚠️ アクション項目が所有者や期日がなく曖昧で、改善が議論されているが実行されていない
プラットフォーム | 運用⚠️ インシデント後レビューは 5 営業日以内に実施されず、コンテキストが失われ、改善の緊急性が薄れる

パターン

参照すべき場所外観
プラットフォーム | Knowledge管理✅ インシデント後レビューは文書化され、組織の学習のためにインシデント対応担当者だけでなく広く共有されます。
プラットフォーム | Knowledge管理✅ インシデント後のレビューは、タグ付けされた共有WikiまたはKnowledge Baseに保存され、複数のインシデントのパターン分析が可能
プラットフォーム | Knowledge管理✅ アクション項目の完了が後続のレビューで追跡されるため、フォローアップなしで振り返りが議論の繰り返しになることを防止
プラットフォーム | Knowledge管理✅ アクション項目の完了率は、改善が実施されているか単に議論されているかを明らかにする業務健全性インジケーターとして測定されます。
プラットフォーム | 運用✅ 複数のインシデントのインシデントパターンを分析して、アーキテクチャ投資が必要なシステム上の問題を明らかにする
プラットフォーム | 運用✅ Runbooks はインシデント後の学習に基づいて更新され、実際のインシデント対応経験を反映した手順が保証されます。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | Knowledge管理⚠️ インシデント後のレビューは文書化されず、学習は組織全体に広がらずにインシデント対応者に残ります。
プラットフォーム | Knowledge管理⚠️ インシデント後のレビューは、チームメンバーが履歴から学べる共有Knowledgeベースではなく、個人文書に保存される
プラットフォーム | Knowledge管理⚠️ アクション項目が定義されているが追跡されていない。完了率は不明であり、改善が実装されていない。
プラットフォーム | Knowledge管理⚠️ フォローアップなしでは事後調査が効果がないことを認識できないと、低いアクション項目完了率が続く
プラットフォーム | 運用⚠️ 複数のインシデントにまたがるインシデントパターンは分析されず、各インシデントが個別に処理されるため、システム上の問題は非表示のままです。
プラットフォーム | 運用⚠️ Runbooks はインシデント後に更新されず、システムの進化や新しい障害モードの出現に伴って手順が古くなります。

パターン

参照すべき場所外観
プラットフォーム | 運用✅ インシデント発生から検出までの平均検出時間 (MTTD) の計測
プラットフォーム | 運用✅ 平均承認時間 (MTTA) は、検出からオンコールエンジニアによる承認までの測定時間を追跡します。
プラットフォーム | 運用✅ 平均復元時間 (MTTR) は、検出からサービス復元までの測定期間を追跡します。
プラットフォーム | 運用✅ 毎月のトレンドレビューでインシデント頻度を追跡し、安定性が向上しているか低下しているかを明らかにする
プラットフォーム | 運用✅ 変更失敗率を追跡し、修正が必要な本番インシデントの原因となったリリースの割合を測定する
プラットフォーム | 運用✅ 変更の失敗率は一貫して低く抑えられ、すべてのリリースのほんの一部です。
プラットフォーム | 運用✅ インシデント評価指標は、バックログの優先順位付けとアーキテクチャの改善を通知するために、スプリント計画中に開発チームと共有されます。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | 運用⚠️ インシデント総計値は追跡されず、チームは応答時間が改善しているか低下しているかを把握できない
プラットフォーム | 運用⚠️ MTTD、MTTA、MTTR は測定されないため、チームは検出と対応がボトルネックになっているかどうかを特定できない
プラットフォーム | 運用⚠️ 変更失敗率は追跡されず、チームは品質ゲートが有効かどうかわからない
プラットフォーム | 運用⚠️ インシデント頻度トレンドは毎月確認されず、重大インシデントが発生するまで安定性の低下は検出されません。
プラットフォーム | 運用⚠️ インシデント評価指標は開発チームと共有されずに運用チームに残り、アーキテクチャの問題は解決されない
プラットフォーム | 運用⚠️ 評価指標は追跡されますが、意思決定に役立つことはありません。アクションなしでの測定は労力を浪費し、価値がありません。