期待される正常な状態からの逸脱.
- 検知・報告
- 影響範囲の評価
- 復旧対応
- 根本原因の分析
- 再発防止
障害テンプレート
PagerDuty Incident Response
最も広く参照される
- Severity levels: SEV1（全面停止）〜 SEV5（軽微）
- Post-Incident Review (PIR): Timeline → Root Cause → Impact → Action Items
- blamelessカルチャーを重視
ITIL
エンタープライズ寄り
- Incident → Problem → Known Error → Change の管理フロー
incident vs bug
- 定義: コードの欠陥・不具合/サービスに影響を与えた事象
- 発見: テスト・コードレビュー/本番環境での異常検知
- 緊急度: 修正は計画的でよい/即時対応が必要
1つのincidentの原因が複数のbugであったり、bugがあっても本番で発火しなければincidentにならない.
🎓品質工学
Quality Engineering「仕様通りに作れているか？」
- SPC
- タグチメソッド
- ✅ソフトウェアテスト
✔品質管理(QC)
統計的品質管理
デミング.
🎓安全工学
Safety Engineering「失敗したとき、人や環境を傷つけないか？」
🎓信頼性工学
Reliability Engineering「長期間、安定して動くか？」
Reliability(信頼性)
Avalability(可用性)
Serviceability(保守性)
Blameless文化
責任追及しない（障害の原因を個人に求めない）」文化や手法.
📝ポストモーテム
システム障害やプロジェクトでの想定外のトラブルが起きた後に行う「事後検証」や「振り返り」のプロセス.
blameless postmortem
Google SRE
SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）
Googleが提唱した、ソフトウェアエンジニアリングの手法を用いてITシステムの運用・管理を行う手法
🔖RAS
Reliability, Availability, Serviceabilityの略. 信頼性に関わるスローガン的なもの.
cf. 🧠網様体賦活系(RAS)、世間的にはこっちのほう知名度あり？
📍根本原因分析(RCA)
適切な解決策を把握するために問題の根本原因を見出すプロセス.
根本原因分析, Root Analysis, RCA
ref. 根本原因分析: 定義、例、ハウツーガイド
RCAの手法として以下がある.
RCAの注意点は, サーキュラーな問題 に対してはスパゲッティみたいな循環が生まれてしまうこと.
ひとつの Root causeが複数の問題を生み出してたりとかするので、一本戦のツリーみたいになるっていうよりは、スパゲティになるんだよね。
なんかのタイミングで、一回しっかりやって地図ができると、なんかスパゲッティの構造だろうとこれどこにリンクしてるなっていうのは割と想起しやすくなるので、やることがすごい重要だったかなみたいなのを、今は思ってますね。
ref. #63 Issue Analysisについて-タベリー初期の資料も大公開
🪛なぜなぜ分析
トヨタが広めたカイゼン手法. 5ways, 芋づる式アプローチとも.
ある問題とその問題に対する対策に関してその問題を引き起こした要因 (『なぜ』) を提示し, さらにその要因を引き起こした要因 (『なぜ』) を提示することを繰り返すことによりその問題への対策の効果を検証する手段.
ref. なぜなぜ分析 - Wikipedia
論理チェック.
- なぜ (why so?)
- だから (so what)
- いいかえれば
そもそも白黒はっきりする問題なのか？
なぜなぜ分析は重要な問題解決法の 1 つであるが, その対象は「なぜ」の問いかけが意味を持つ問題に限られる.
「なぜなぜ分析」は「原因のある問題」のうち特定化された困った問題の原因分析への適用においてのみ効果がある.
ref. どこがマズイ|なぜなぜ分析
🐟特性要因図
特性要因図は問題の要因を自由な発想で出来るだけ多く提示するもの.
魚の骨のようなのでフィッシュボーンチャートとも.
網羅的に要因を探るために MECE を心がける.
業界ごとに分解の型みたいなものもある.
- マーケティングファネル
新規マーケットでは分解の型はないので自分で考える.
with me
<2026-04-06 Mon 08:54>わたしのやっていたことは、信頼性工学だったのか！🔖エラーリカバリー