こんにちは、ソフトウェアエンジニアの yuku です。
2019年も残すところわずかとなり、一年の振り返りをする季節になりました。フライウィールには何かしらのインシデントが発生した際に事後分析のために Postmortem と呼ばれるドキュメントを書く文化があります。2019 年最終営業日の今日、エンジニアチームでは今年書かれた Postmortem を読んで一年を振り返る『Postmortem 読書会』を行いました。
この記事では、 Postmortem の簡単な背景と、 Postmortem 読書会の様子を紹介します。
Postmortem とは
システムを開発し運用していく中でトラブルを完全に避けて通ることはできません。インシデントを経験した際に事後分析のために書かれるのが Postmortem です。このような文書には会社ごとにさまざまな呼び名があると思いますが、Postmortem という名前は Google によって書かれた書籍『Site Reliability Engineering』（通称『SRE本』）で広く知られるようになりました：
ちなみに、この本は Google 社内の SRE チームについて説明した書籍で、これを契機に多く企業で SRE という職種が設けられるようになったことをご存知の方も多いかも知れません。
フライウィールにおける SRE と Postmortem
フライウィールには 2019 年 12 月末時点で、SRE という名前がついた専任の職種は存在していません。しかし、ソフトウェアエンジニアがサービスの開発から安定稼働までの面倒を見ていく中で、多くのプラクティスを SRE 本の中から取り入れており、その一環としてインシデントが発生した際は以下のテンプレートをベースに Postmortem を書いています：
このテンプレートは SRE 本に掲載されている Postmortem のサンプルと エンジニアなら知っておきたい障害報告&再発防止策の考え方 – Qiita を参考に書かれています。
Postmortem 読書会
Postmortem をただ書いただけでは意味があまりありません。失敗から学び、次に繋げていくことが大切です。年末ということでエンジニアチームで一年を振り返る目的から Postmortem 読書会を行いました。
SRE 本の中でも繰り返し言及されていますが、 Postmortem は失敗から学ぶために書くものであって、これを書くことで誰かを責める、あるいは責められていると感じるものであってはなりません。今回の読書会では、冒頭で改めてこの点を説明し、会の趣旨が学びのためにあることを強調した上で、一本あたり 5 ~ 10 分のペースでインシデントの原因と分析、そこから発生した対応とその進捗を振り返りました。
会社で一番明るくて見晴らしのいい会議室で行いました。
今回の読書会に参加したメンバーからは以下のような感想が寄せられました：
- 複数まとめて振り返ると、一つ一つ見ているだけだと分からない傾向が見えてくるのがよかった。
- 明るい雰囲気で行われたのがよかった。
- 一年近く前だとコンテキストが分からなくなってくるので、四半期あるいは半年ごとにやるのがいいのではないか。
- 書いた人がいるとコンテキストがより共有できて良かった。（注：休暇中のメンバーが書いた Postmortem があった）
- 参加したことで当事者意識が強くなった。
- 自分たちがやってきたことの振り返りとしていい。Postmortem という名前だけど、裏を返せばインシデントと向き合ってきた歴史でもある。
- 過去を知ることができてよかった。
- アクションアイテムの状況をトラッキングする機会として良さそう。
いくら「あなたは非難されない」と言葉を尽くしても、 Postmortem を書くのは気が滅入る作業です。こうして明るい雰囲気の中で振り返っていくことで、少しでも Postmortem を書くことに対する心理的な抵抗感が小さくなればいいなと思います。
おわりに
会社が大きくなっていけば必然的に Postmortem が書かれる機会も比例して多くなっていくでしょう。失敗から学び、次に繋げていくために、今後も Postmortem 読書会を継続していきたいです。次回はフィードバックを踏まえて三ヶ月後に行う予定です。
フライウィールでは健全な挑戦と失敗の山の上にイノベーションの旗を掲げたいエンジニアを募集しています！