再発防止策が全然思いつかない...とお悩みの方へ。再発防止策は様々な視点から検討しない限り、納得のいくものにすることは困難です。そこで、複数の角度から120項目準備しました。再発防止策を起こすときに参考にしたり、すでに作成した再発防止策に追加できないか見返したりしてもらえれば幸いです。

再発防止策検討の基本方針

多層防御アプローチが検討しやすく基本です。レイヤーや人、プロセスごとに分解し、どんどん考えていきましょう。

分類の例: チームごと

各々のチームで、なにかできることはないでしょうか？後工程はお客様。前段の工程側に一見誤りがなくても、前段の工程のほうを改善したほうが成果が圧倒的にでることは非常によくあります。たまたま事象が発生したチームだけに閉じているアクションアイテムは失敗です。

分類の例:被害の分解

被害 = 発生確率 * ( 検知時間 + 修正時間) * 影響範囲

この4つのパラメータごとに検討してみましょう。

即効性か

まずはすぐできるものをどんどん挙げてやっていきましょう。行動に移せなければ何も効果がないので。

一方で、手軽なものはインパクトが小さいことがほとんどです。特にプロダクトが成熟してくると、手軽で効果が大きいものはやりつくしてしまっています。組織での対応や意思決定の手間がかかるものにどれくらい手を付けているか確認しましょう。

障害を経て、なんだか雰囲気が変わったなとメンバーが感じることができるかどうか。重要な指標の一つです。

開発プロセスを強化する

要件をまとめる時点で気づくことは可能でしたか？
設計の段階で気づくことは可能でしたか？
レビューで検知できなかった背景は？
プルリクエストによる差分確認だけではなくウォークスルーはたまにしていますか？
テストで検知できなかった背景は？
開発やステージング環境で検知できなかった背景は？
リリース後に気づかなかった背景は？
Integration Testはしていますか？
E2Eはしていますか？
CDはできていますか？
- コマンドとはいえデプロイだけ手動、しかもローカルPC経由という事例あり
各種の自動化できていない背景は？
障害訓練はしたほうがよさそうですか？
障害試験はしたほうがよさそうですか？
実機での検証に改善の余地はありますか？

信頼性設計をやり直す

Well Architected Frameworkは確認していますか？
リトライは妥当ですか？
- jitter + exponential backoffは入ってますか？
タイムアウトは妥当ですか？
キャッシュは妥当ですか？
コンポーネント障害時の動作を認識していますか？
リソースの制限はデフォルトのままですか？
リソースの制限はかけていますか？
リソースの制限は妥当ですか？
データ整合性は定期的に検証していますか？
チーム間で疎結合になっていますか？
アクセスが増大したときに最初にボトルネックになるのはどこか把握できていますか？
N+1クエリを発行していませんか？
APIのエラーは想定していますか？
APIの遅延は想定していますか？
APIの認証エラーは想定していますか？
その機能が必要なエビデンスはありますか？

オペレーションを次の段階へ進める

Feature Flagは使えませんか？
カナリアリリースできませんか？
B/Gデプロイはできませんか？
リリースとデプロイは分離できていますか？
モニタリングツールのアラートは設定できていますか？
アラートに手順書は設置していますか？
アラートを見たら何をすればよいかわかるようになっていますか？
自作したダッシュボードは短時間で情報が見つけられますか？
BIツールで誰でもビジネスメトリクスが確認できますか？
オンコールツールで自動的に電話等がかかる設定になっていますか？
リリースにかかる時間はさらに短くできませんか？
リリースは営業時間中にできませんか？
金曜夜にリリースが難しい背景は？
リリース頻度が少なすぎませんか？
ユーザーが気づく前にエンジニアが検知できますか？
外形監視(ハートビート)はできてますか？
RUMによるモニタリングはできていますか？
ブラウザからAPIまで一気通貫してトレースできますか？
ロールバックはできていますか？
ログは不足していませんか？
ログにコンテキストは入っていますか？�突き合わせ作業の量は最小限になっていますか？
動作確認はもっと早くできる余地はありますか
調査ツールに改善の余地はあるか？
SSHやリモートデスクトップでの対応ではなく管理ツールは作成できていますか？
ドキュメントは整理されていますか？
ドキュメントは作成と更新されていますか？
ドキュメントは探しやすくインデックスを作成していますか？
Q&Aはありますか？
初心者向けガイドはありますか？
手順書へのリンクはありますか？
重要なドキュメントは全員が読んでいますか？
作業記録は記載していますか？
作業がトレースできるようになっていますか？
2名で行う場合は指示者と対応者に分けていますか？＊脱ダブルチェック
ラフで良いのでチェックリストはありますか？
エンジニアが行う必要性の薄い作業を別のメンバーでもできるようにできませんか？
オンラインでRDBのインデックスは追加できますか？
バックアップは取っていますか？
バックアップからのリストアは実績ありますか？
その作業は必要ですか？

メンバーのスキルを高める

調査は系統立てて行っていますか？
調査ツールに習熟の余地はありますか？
人によって作業スピードのばらつきはありますか？
モニタリングツールで使い方がわからない部分はありませんか？
チーム勉強会といった機会は確保していますか？
チーム内で自分が得意なスキルを教えていますか？
今回の事象を図に表しましたか？
ペアプログラミングやペア作業はできそうですか？
そのオペレーションの頻度はどれくらいですか？忘れない程度ですか？

インシデント対応プロセスを進化させる

作業者は作業に集中できましたか？
ストレス反応が出たメンバーは見受けられましたか？
対応可能メンバーはローテーション通りでしたか？
対応可能メンバーは想定通り参加できましたか？
対応者は速やかに参加できましたか？
連絡の頻度は適切でしたか？
コミュニケーションチャネルは混線していませんでしたか？
何をしたらいいかわからない待ち時間はありましたか？
統制者は対応に集中できましたか？
書記は確保できましたか？
適切な情報は得られましたか？
必要なときに助けは得られましたか？
必要なときに助けを求めることができましたか？
ある特定のメンバーしか対応できなかった背景は？
毎回同じメンバーが対応している背景は？
意思決定は統一できていましたか？
意思決定者は一人に絞り込めていましたか？
テンプレートは準備できていましたか？
解散宣言は適切なタイミングででましたか？
対応中休憩は取れましたか？
対応の引き継ぎは適切でしたか？
社外とのコミュニケーション速度を上げる方法はありますか？
対外文書は穴埋めだけでできるフォーマット(holding statement)がパターンごとに作成済みですか？

総合的にプロセスを改善する

前工程で改善できませんか？
複数のプロセスや人、チームごとに改善案が出ていますか？
VSM(Value Stream Mapping)は書いてみましたか？
後工程に対して各成果物に改善の余地がないか相談したことはありますか？
どのフェーズが障害面で弱いですか？

組織の悩みを解消する

改善にリソースがさけてない背景はなんですか？
以前のアクションアイテムを消化できていない背景はなんですか？
今回も含め、振り返りの時間が取れてない/取りづらい背景はなんですか？
教育学習の時間が取れてない背景はなんですか？
平常時、他チーム、他部門からのプレッシャーはありましたか？
当該事象に対する関係者からのアラートはありましたか？
当該事象のリスクに気づいていても声をあげられなかった背景はなんですか？
チームは健全と感じていますか？
短期的なローテーションは検討の価値はありますか？
他部門との交流の機会は確保できていますか？
他部門のKPIやOKR、目標は把握できていますか？
他部門の業務内容はどの程度理解していますか？
緊急対応したメンバーに報いていますか？
平時の備えより緊急時への対応へのインセンティブのほうが大きくなっていませんか？
この事象を予測していた人はいますか？伝わらなかった背景はなんですか？
経営会議ではシステムについて、品質についてどれくらい時間を割いていますか？

良い方法を広める

チーム内でうまくいっている方法を応用できませんか？
チームの誰かが個人的にやっているノウハウを使えませんか？
社内でうまくいっている方法でよさそうなものはありますか？

その他

他に聞いておくべきだがまだ質問されていないことはありますか？
各チームが打ち合わせをしやすい時間帯はいつですか？

まとめ

前回の記事ではふりかえりについてまとめ、今回はふりかえりの分析が終わったあとのアクションアイテムのヒントを提示しました。

これらの項目を検討していれば、関係者の納得のいく再発防止策ができることでしょう。

文責: 高木

最後に

カケハシではアドベントカレンダーもやっています。そちらもぜひ確認してみてください。

KAKEHASHI Tech Blog

カケハシのEngineer Teamによるブログです。

これ一つで解決する、全120項目の再発防止策チェックポイント