1人目の専任SREがポストモーテム文化を改善したらエンジニア以外にも広まり、他部門との連携も強化された話
2022年7月に primeNumber に入社した、1人目の専任 SRE の高塚 (@tk3fftk) です🙏
primeNumber が開発する trocco® のSREチームは現在、CTOの鈴木さん (@kekekenta) と自分、業務委託の方数名で日々さまざまな改善を行っています。
入社して半年以上経ち、行ってきた改善をふりかえりを行いがてら、記事を書いてみることにしました。
この記事では、SREの取り組みの1つとして、primeNumber のポストモーテム文化を改善した話をします。
追記: この記事をベースにしたLT登壇の機会をいただきました🎉
ポストモーテムとは?
ポストモーテムとは、簡単に言うと、発生したインシデントについて読めば把握できるようなドキュメントです。
影響範囲、根本原因、タイムライン、行われた対応や再発防止策などが含まれます。
具体的な定義や書き方については、Google の SRE Workbook を始めとする先人の知恵がありますので、この記事では詳しく触れません。
primeNumber に元々あったポストモーテム文化について
エンジニア組織にポストモーテムを書く文化は既にありました。
ポストモーテム用の GitHub issue テンプレートの項目を埋めるような形となっており、発生原因や影響範囲の共有、記録といった観点が強いものとなっていました。
どういうところを課題と感じたか
ポストモーテム作成に関する課題と、ポストモーテム作成後の活用の仕方について、ポストモーテムの目的の1つである「失敗から学ぶ」という観点から見ると改善の余地があるように思えました。
(「せっかくのインシデントを無駄にする」というアンチパターンがシステム運用アンチパターンにも書かれていますね)
ポストモーテム作成について
issue は作成されているが、ほぼタイトル以外の情報が埋まっていないものや、内容は記入されているものの、再発防止のためのアクションがないものなどもありました。
「issue にポストモーテムを書く」ということ関しても、GitHub 上での紐付けがやりやすいというメリットはあると思う一方で、同時編集ができないため、ポストモーテムを書く人が固定化されてしまい、負荷が集中しているように見えました。
また、インシデント対応と並列でポストモーテムを書きにくい状態となっていました。
ポストモーテム作成後のふりかえりについて
ポストモーテムをベースに議論・再発防止策を検討するミーティング ( primeNumber では「ポストモーテムふりかえり」と呼んでいます) を開催する割合が少なく、また開催の基準なども明確になっていませんでした。
また、ポストモーテムふりかえりの議事録は Google Docs に記入していたため、ポストモーテムの内容と議論内容の情報が分散しており、議論の効率が悪いように見えました。
どのような改善を行ったか
ポストモーテム作成については以下のような改善を行いました。
ポストモーテムの Google Docs 移行
Google の SRE本 の Chapter 15 (Postmortem Culture: Learning from Failure) にも書かれている通り、同時編集でき、誰とでもコラボレーション可能なツール (というか本に書かれているそのもの) を利用するように
Google Docs のテンプレート機能を利用し、ポストモーテムテンプレートを更新
対応に関わっていない人でもできるだけ読めば何が起こったか分かる、追えるように
再発防止のためのアクションに優先度をつけるように
「インシデント対応からの学び」の項目を追加
インシデント対応マニュアルの作成
インシデント発生時に行うことをまとめておき、最低限「インシデント検知した人が何をしたらいいかわからない」状態を無くす目的
ポストモーテム作成もインシデント対応フローに組み込む
並行して「ポストモーテムふりかえり」の推進を行いました。
primeNumber という会社の特徴だと思うのですが、他の会社ではあまり関わりがないような他部署との連携や交流が活発だと感じています。
そのため、ポストモーテムに関してもエンジニア組織だけに閉じてしまうのはもったいない、と感じ、エンジニア組織以外にも「ポストモーテムふりかえり」を推進しました。
たとえば、テクニカルライターチームの方が以下のように trocco® のドキュメントにテストデータを反映させてしまったときの Slack 上のやりとりを抜粋してご紹介します。
また、アクションアイテムに「〇〇をしないようにする」といった旨のものがあったので入れたコメントです。
個人的に、多くの人の時間を使ってまでふりかえりを行うべき理由の1つだと考えています。
改善した結果として、目に見える成果に繋がったもの
2023年1月の CircleCI のセキュリティインシデントの対応を行った際にも、幸い影響は見られなかったのですが、ポストモーテムを書き、ふりかえりを行いました。
影響範囲の広いインシデント発生時の対応体制の見直しなど、単に「他社のインシデント」と終わらせず改善に繋げられたと考えています。
また、インシデント対応とポストモーテムふりかえりを通じて、trocco®のカスタマーサクセス(CS)チームとの連携改善にも繋がりました。
ポストモーテムにCSチームからお客様に連絡いただく内容を盛り込み、ポストモーテムを見ればCSチームがすべきアクションが分かる、アクションについて議論ができるようにポストモーテムのテンプレートを修正しました。
(この後実施したふりかえりで詳細を詰めました)
ポストモーテムの推進活動を始めてから、SRE チームでふりかえりのファシリテーションを行うことが多かったのですが、今年に入ってから、SRE チーム以外の方がファシリテータとなって進めてくれたふりかえりも開催されました。
開発チームの方から会社としての強みではないか、というコメントをいただいたことも。
今後どうしていきたいか
SRE チーム以外の再発防止のアクションの対応状況まで追いきれていないので、「アクションが確実に実施されること」「実施できない場合に優先度・期日を変更した判断理由が書かれること」を促進するような仕組みなり文化を作りたいなと考えています。
合わせて、記憶が新鮮なうちにポストモーテムを書き、ふりかえりを行うことを組織として習慣化できると良いなと思っています。
おわりに
primeNumber では SRE として trocco® の改善に留まらず、組織の文化の改善を一緒に行ってくれる仲間を募集しています。
詳しくはRecruitページをご覧ください🙏 カジュアル面談もお気軽にお申し込みください！
この記事が気に入ったらサポートをしてみませんか？