[Move past incident response to reliability · GitHub](https://github.com/readme/guides/incident-response) Standard Response ![[Pasted image 20230223104830.png]] - [[MTTD]]や[[MTTM]]のような指標はインシデントレスポンスの有効性を効率的に評価 - これらの指標は、次に進むべき道を示すのが難しい - インシデント対応プログラムを拡張し、インシデントの分析も含める 1. インシデントが発生したら、その影響を緩和するなど、これまでと同じようにインシデントに対応する。 2. インシデントに関するメタデータを一元的に記録し（照会可能なWiki、スプレッドシート、またはより高度なもの）、インシデントの影響と原因に焦点を当てます。 3. 新しい種類のインシデントレビュー会議を導入し、個々のインシデントをレビューするのではなく、関連するインシデントのバッチのレビューに焦点を当てる。 - インシデントのカテゴリ全体の再発を防止するための改善策を提案 （ここまでは、[[SREの組織的実践]]と似ている） せっかく生まれたアイデアに優先順位がつかない - インシデント分析の取り組みがなぜより信頼性の高いソフトウェアを生み出さないのか？ - メタデータの収集と厳密な構造化プロセスを倍加させる - インシデント合法主義（[[Incident legalism]]） - インシデントの合法化とは、インシデントに関するタグをより多く収集し、インシデントのメタデータをファイルするためのスケジュールをより厳しく設定し、インシデントレビュー・セッションをより多く予定するなど、より多く働き、より成功しないという結果をもたらす ### 信頼性向上のための拡張モデル 信頼性プログラムの設計やデバッグには、システムモデリングが非常に有効なツール。 - 以下のそれぞれの項目の数を時系列で測定する 1. システム内で変更（新しいコードなど）が発生すると、変更の一部に将来インシデントを引き起こす可能性のある動作（潜在的インシデントなど）が含まれる 2. それらの潜在的なインシデントがインシデントに変わる発見率 3. インシデントが発生すると、ある割合でそれを軽減し、インシデントからMitigated Incidentsに変化 4. Mitigated Incidentsを調査し、再発防止策を決定し、Remediated Incidentsへ変化