ポストモーテムはじめました

こんちは。
最近SREの領域にも足を踏み入れ始めたとよしー です。

2月からSREの役割も担うことになりました。
とはいえ、SREってなにすればええんや...状態でした。

最初になにを取り組もうかと考えている時に、インシデントを目の当たりにしました。
そこで、ふと
・エンジニアにこの障害から学んだ教訓をもっと認知させたい
・エンジニアの言語でもわかるような再発防止策を共有したい
と思い、ポストモーテムを実施してみようと考えました。

というわけで、今回の記事はポストモーテムをどのように実施し、やってみてどうだったかをまとめた記事になります。

ポストモーテムってなに？

そもそもポストモーテムってなんやねん？ですよね。
直訳すると「検死」という意味でもあり、もともとは司法機関が遺体を解剖するなどして死因を調べ、犯罪性の有無を明らかにする行為だったそうです。

システムも予期せぬ障害やインシデントが発生しますよね。（できれば発生してほしくないけど...）
主に障害の事後検証や根本原因分析を行い、それらをドキュメントにまとめる流れのことをポストモーテムといいます。

ポストモーテムのテンプレート

弊社で行う際のポストモーテムのテンプレートは下記のような感じです。

## アイスブレイク
=> 少し緊張する内容の会議体なので、最初にアイスブレイクを行うのはおすすめです

## ポストモーテムとは
=> ポストモーテムに慣れていない人が多い場合は、説明や参考記事をのせています

## ルール
人に対する非難を行わないこと
=> 人を非難しても何もいいことは起きないので場のルールとして定めています

## 障害の概要
=> その名の通り障害の概要を端的に書きます

## 対応者
=> 障害復旧にあたった担当者を書きます

## タイムライン
=> 障害対応時になにをやったのか分刻みで記録したものを書きます

## 何がおこったか
=> 端的にこの障害でシステムに何が起こっていたのかを書きます

## 根本原因分析
=> 何が原因だったのかを深掘りしたものを書きます

## 解決方法
=> 障害をどのように解決したかを書きます

## インシデント分析
### どれくらいのユーザーに影響があったか
=> ○人 / 全ユーザー

### 障害発覚から終息までの時間（平均回復時間）
=> ○分○秒

## アクションアイテム
### 観点
・今回のような事象を防ぐ方法
・障害発生から回復するまでの時間を減らすにはどうしたら良いか

## ふりかえり
### よかったこと

### 改善したいこと

やってみてよかったこと

エンジニアの言語でもアクションアイテムが出せるので、具体的かつすぐにできそうなアクションにつなげることができたことが良い点でした。
経験則ですがふわっとしたアクションアイテムだと決めて終了...という悲しいことになりかねないです。
極端な例ですが、
「みんなが仕組みを改善する意識をもつ」
とかは危険信号だと思っています。（意識ってなんやねん）

また別観点では、根本原因分析をする中で「こうすればよかったのかもしれない」というアイデアがたくさん出てきたことも良い点でした。
対話する中で気づき/学びを得ることがポストモーテムの良いところでもあるので、それを感じられてよかったです。

やってみてわかったこと

障害からポストモーテム実施までの時間は早ければ早いほど良いことに気づきました。
ポストモーテムを1週間後に設定したことがあるのですが、障害の詳細の部分まで思い出せなかったり、思い出すのに時間を要するシーンがあったので、障害発生からいかに早くポストモーテムを開催するかが今後の課題です。

参考

システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション