これはTOWN Advent Calendar 2022の11日目のエントリーです。
昨日は岩井さんによる自家製ビールの飲めるお店の話でした。
本日はSiteCloud事業部のインフラエンジニアである私Komiが"Howie: The Post-Incident Guide"という資料の読後メモを記します。(個人の興味によるもので、組織としての見解や特定のサービスなどの推薦を表すものではありません)
Howie: The Post-Incident Guideは一年前の2021年12月にJeli社より公開された資料です。
https://www.jeli.io/howie
Jeliの共同設立者であるNora Jonesさんは今年日本語版が出た"Chaos
Engineering"の著者の一人でもあります。活発な登壇をされていて、先日のSRECon APACでもHowieが登場したセッションがあったようです。
Howieは"How we got here"を略した造語です。雑に訳すと「どうしてこうなった」といったところでしょうか。Nora JonesさんのPodcastも番組名が"Getting there"なのでお決まりのフレーズのようです。
https://www.heavybit.com/library/podcasts/getting-there
ポストモーテムやRCA、CoEなどSREカルチャーの一環としてインシデント後の振り返りの取り組みが行われていますが、Howieは手法だけでなく心構えなど広くカバーした先人の知恵のような資料です。
PDF版でも60ページほどの資料なので集中すれば一気に読める量だと思います。
時間の無い方は、まず最初のWelcomeを読み、中段(PDFではP6)の構成要素の図を見た上でAppendixA～Cを読んで、後から気になった要素の章を読むといいのではないかと思います。Appendix.Cの想定問答集はリアルで面白いです。例えば第一問は「良さは分かったけどすべてのインシデントでHowieをやるような時間は無い」です。
以下、かいつまんで感想を書いていきます。
Welcomeの章で、他の書籍からの引用の形で
「パフォーマンスの改善 ＝ エラーの削減 ＋ インサイトの創出」
という式が登場します。
インシデント後の分析となると右辺第一項の「～しないように」といった事ばかりが浮かびがちですが、事実に注目して「どうしてこうなったのか」から多くを得て学ぶという第二項の視点の大切さが説かれています。ここがHowieの特徴です。
レジリエンスエンジニアリングのホルナゲル先生の著書"社会技術システムの安全分析―FRAMガイドブック"は冒頭で「設計段階では私たちはシステムについて相対的に無知である」と述べています。開発だけでなく運用においても同様で、運用設計段階ではシステムについて相対的に無知であると言えます。「監視項目が足りてなかった」というのはその最たる例と言えます。インシデントを経てシステムで起こりうる状態や運用チームの特性について理解を増すことができれば、チームのインサイトも増加蓄積できるでしょう。得られたインサイトから連想して他の改善を生み出すことも期待できます。
次の章からは各ステップについて説明されています。列挙しておきます。
Assign - Identify - Analyze - Interview - Calibrate - Meet - Report - Distribute
最初にAssignが明記されている事にも重要性を感じました。インシデント発生時にインシデントコマンダーを決めるように、Howie活動においても、たとえ複数人で共同で行う場合でも責任者を決めて取り組む必要があると明記されています。バイアスを避けるためにインシデントに直接関わった人以外が良いとされています。しかし大きい組織でないと現実には難しいかもしれません。Howieは実際に何が起きたのかを重視しているので言い分は分かりますが...(そのようなポジションを設定することがJeliのビジネスチャンスでもあるのでしょうけど)
Analyzeの章は具体的で学びがあります。最近はオンコール管理ツールにインシデントの関連ログとタイムラインを集めてポストモーテムの材料を生成する機能を備えたものも増えてきました(例えばRootly, Squadcastなど)。この章で述べられている"narative"や"(needs)
follow-up"といったタグ付けは参考になります。またタイムラインは複数作っても良いという事がさらっと挙げられています。障害報告書用の時系列..と固定イメージに捕らわれていると複数のストーリーを書いても良いということは思いつきませんでした。
Calibrateの章も特徴的かもしれません。インタビューやログなどから集めた情報を元に組み立てたドラフトレポートを共有して行うブラッシュアップです。ここで最終的にインシデントから取り上げるテーマを固めます。
報告に向けて"surpriseを避ける"という言葉が繰り返し登場します。インシデント後の分析というのは決して気分の良い物ではありません。サプライズがあると相手が警戒してしまい自己防衛に動いたり非協力的になったりする恐れもあるので、全員から理解と納得を得られる分析にしなくてはいけないとしています。
Meetの章のIntro and opening
remarks(PDFのP38)にはインシデントレビュー会議の冒頭の言葉として"Blamelss宣言"のような長めの口上が紹介されています。この会では是正処置については話さない、とも述べていて前向きな共有と感謝の場であることが強調されています。
Howieはガイドではあるが画一的なテンプレートではなく、それぞれの組織に合わせて調整されるべきということも各章で繰り返し出てきます。
Reportの章(PDFのP45)にはHowieレポートのサンプルへのリンクがありますが、あくまでサンプルであってテンプレートでは無いと強調されています。最初からすべての分析ツールや分析スキルが揃うわけでも無いので、チームに合わせてカスタマイズして用いることが推奨されています。
また先ほどの会議についても「是正処置については話さない」と口上で述べていましたが、「現実には是正処置などのためにもう一回会議を開く事の方が困難な場合も多い」と言ってたりもします。そのため、レビュー会議の最後にアクションアイテムを挙げる場を設けるという提案もされています。
「再発防止」を重視しがちだった私には視点や重きを置くべき物など根本から異なる考え方だったので読んでいてとても身に沁みて目からウロコの落ちる思いでした。
インフラエンジニアとしてはインシデントの発生はツラいものですが、インサイトの創出によるパフォーマンス改善の機会でもあると捉えてまっすぐに取り組んで行きたいと思います。
おまけ
来年2月に第一回Learning From Incidents Conferenceが開催されるようです。私は現地参加は難しいですが、また新たなトピックが提供される事を楽しみにしたいと思います。
https://www.learningfromincidents.io/