はじめに
この記事は アイスタイル Advent Calendar 2025 12日目の記事です。
アットコスメのWEBを担当しているyamaguchiiです。
私たちの部署では、毎週障害を振り返るミーティングを行っています。
年末なので、この障害振り返りについて振り返ってみたいと思います。
振り返れば奴がいる！
2種類のチケット
障害を報告するチケットは
- 障害対応報告
- 振り返り結果共有
の2種類あり、ペアで作成します。
障害対応報告チケット
障害内容を報告します。
事象の詳細、システムの前提知識、影響範囲を書きます。
原因を特定し、暫定対応や恒久対応を実施し、復旧したことを報告します。
検知から対処までのタイムラインを書きます。
振り返り結果共有チケット
根本原因を分析します。
根本原因が再発しないための防止策を検討します。
再発防止策が実施されたことを確認し、チケットをクローズします。
障害振り返りミーティング
毎週1回30分、部署のメンバーを5人くらいのチームに分けて、先週に起票された障害チケットをレビューする会議を行います。
人数が多い会議だと発言する人が限られてしまうので、発言しやすいように少人数のチームにしています。
チームのファシリテーターは、持ち回りで行っています。
ファシリテーターは、部署の会議でチームから上がった意見を発表します。
全社の障害に目を通す
まず振り返る障害の対象ですが、先週に起票された障害チケットをすべて振り返ります。
自分の部署の障害だけでなく、他の部署の障害チケットもすべて対象としています。
自分の部署はWEBのシステムを担当しているのですが、スマホアプリやEC、機械学習などの他部署から報告された障害チケットにも目を通します。
これにより、全社システムでどんな障害が起きているかが分かります。
また、他システムで発生した障害を自分が担当しているシステムに置き換えて、どのような障害対応を行ったら良いか、自分事として捉えます。
障害対応報告チケットのレビュー観点
エンドユーザーにどれくらいの影響があったのかを見るようにしています。
例えばバッチが異常終了して、再実行したという報告だけでは、どれだけの影響があったのか把握できません。
そのバッチの影響で画面の一部が2時間ほど表示されない障害であれば、その間のアクセス数などで影響範囲を確認します。
また当社では素早い復旧を目指しているので、検知から復旧までの時間がレビューのポイントとなります。
検知が遅ければ、監視の項目を追加して、アラートを上げる対応をしたり、復旧が遅ければ、自動でリカバリやリトライする仕組みを導入するなどの対策が考えられます。
単に事象と対処の報告確認だけでなく、課題を明確にして施策につなげられるようにレビューをしています。
振り返り結果共有チケットのレビュー観点
原因がバグであれば、そのバグが混入したフェーズやチェック体制などをレビューします。
テストがあれば防げたのか、規約などドキュメント類が不足していたのかなど、根本原因を探ります。
根本原因が分析されていなければ、それを二度と起こさないための再発防止策を立てられません。
再発防止策に単なる恒久対応を記載しているチケットを見かけることがあります。
再発防止策は、その原因が二度と発生しないような施策であって、障害の対応方法ではありません。
ここでも人的なミスが発生しないように、例えばCI・CDの導入やインフラをコード化するなど、なるべく機械的・自動的にチェックする方法がないか検討します。
振り返り結果共有チケットで同じような障害を起こさないような観点でレビューしています。
おわりに
このように自分の部署の報告だけでなく、他部署の報告もレビューすることで、重要な観点が明確となり、チケット記載の質も向上し、原因の分析も深く考えられるようになりました。
全ての障害をレビューするなんて、ちょっと面倒と思われますが、毎週30分くらいの会議で、習慣化してしまえば、それほど負担じゃなくなります。
また上で述べたような効果もあるので、ぜひやってみてはいかがでしょうか。
ソフトウェアの複雑性は増し、不具合の原因は多岐に渡り、障害無く運用することは困難になっています。
障害をすばやく検知・復旧する仕組みを活用し、二度と再発しない施策で障害の影響を少なくするようにしていければと考えております。