# 社内障害情報共有のススメ [[Hatena]] のエンジニア shiba_yu36 による 2018 年のブログ記事。障害報告を全社エンジニアに共有する仕組みと、その効果を具体例とともに紹介する。 ## 報告フレームワーク | 項目 | 基準 | |---|---| | **いつ報告するか** | ユーザー影響のあるインシデント、および他チームに価値のあるニアミス | | **誰が報告するか** | インシデントの全文脈を持つチームメンバー | | **誰が受け取るか** | 全社のエンジニア | | **記載項目** | 状況、原因、即時対応、今後の予防策、備考 | ## 実装方法 はてなグループ（社内グループウェア）を利用し、社内日記にインシデント概要を公開してエンジニアをメンション。集約用キーワードにリンクすることで検索可能なアーカイブを構築する。Slack チャンネルとも連携し、インシデント通知から議論が展開する。 ## 文書化の効果 - 構造化された文書化が自然に徹底的な根本原因分析を促す - 他チームが類似問題の発生前に予防策を実装できる - チーム横断のアドバイスと協調的問題解決が生まれる > [!key-insight] 障害共有の射程は「再発防止」を超えて「知識の横展開」にある > ポストモーテムは通常「同じ障害を繰り返さない」ことを目的にするが、全社共有により「類似の構造を持つ別の障害を予防する」という横方向の学習が実現する。 ## 既存 wiki との接続 - [[@mixi developers__インフラ障害対応とポストモーテム]] と並び、日本のウェブ企業におけるポストモーテム文化の具体的実装 - [[@2016__OReilly__SRE Book - Chapter 15 Postmortem Culture - Learning from Failure]] の「広い共有」原則を日本企業で実現した事例 - [[@2018__Google SRE Workbook__Chapter 10 Postmortem Culture - Learning from Failure]] が強調する「広い共有・アクションアイテム追跡・文化的インセンティブ」のうち「広い共有」を最も純粋に実装したケース