SREチームの藤原です。今回は、SREチームが主導してポストモーテムを書く取り組みを、社内で1年半ほど運用してみたという話です。
ポストモーテムとは?
「ポストモーテム」(postmortem=事後検証)とは、システムにインシデントが発生したことによる影響、緩和や解決のために取られた行動、インシデントの原因、再発防止策などをまとめた文書です。
カヤックのSREチームは、各メンバーがそれぞれのプロダクトに参加し、他のエンジニアとともに開発と運用を行う、いわゆる「Embedded SRE」という形態を取っています。そのため、SREチームのメンバーでも自分が関わっていないプロダクトで発生したインシデントについては詳しく把握できないことがありました。SRE以外で運用に携わっている、プロダクト専任のサーバーサイドエンジニアにはなおさら困難でした。
また、インシデント発生時に実際に手を動かす人がどうしても固定化されてしまうという問題も認識されていました。障害対応には迅速な行動が求められることから、経験が多かったりチーム歴が長いエンジニアが率先して対応してしまうことが多くあります。その結果、経験が少ない人がインシデントの対応によってあらたに経験を積む機会が少なくなっていました。
そこでインシデントから得られた知見を共有するために、2020年10月からSREが関わっている自社サービス(ソーシャルゲーム、コミュニティーサービスなど複数のプロダクト)で、ポストモーテムを統一的なフォーマットで書きはじめました。
ポストモーテムをどのように運用するか
ポストモーテムを書くにあたっては、次のような取り決めを行いました。
- あらかじめテンプレートをGoogleドキュメントで作っておき、インシデントの対応がある程度完了したら項目を埋める形で記述する
- チーム内でレビューを行って完成させる
- 月に1回、社内の大半のエンジニアが参加しているSlackチャンネルで「先月のポストモーテム」として一言興味を引くコメントを添えて、まとめてURLを共有する
ポストモーテムで大事なことは「非難をしない」ことと言われています。
ポストモーテムで批判を行わないことは、SRE の文化における信条です。ポストモーテムが本当に非難を伴わないようにするためには、悪い行動や不適切な行動をもって特定の個人やチームを糾弾することなく、インシデントに影響を及ぼした原因を特定することに集中しなければなりません。非難なくポストモーテムを書くための前提となるのは、インシデントに関わりを持ったすべての人々が善意の下で、知り得た情報をもって正しい行動をとったものと考えることです。個人やチームの「間違った」行いに対する指弾と不名誉の文化が広がってしまえば、人々は処罰を恐れて問題を公表しようとしなくなります。
O'Reilly SRE サイトアビリティエンジニアリング 15章より引用
この点については特に取り決めはしませんでしたし、社内で運用するに当たってもあまり心配していませんでした。元々社内の文化として、問題が発生したときに特定の個人を非難するような風潮はないためです。
また、ポストモーテムを書くかどうかの判断基準については、現在のところ次のように取り決めています。
- プロダクトの利用者に大きな影響を与えたインシデントについては必ず書く
- 「大きな」の定義は当初は漠然としていましたが、現在はチームでSLI/SLOを運用している場合はエラーバジェットの消費量を基準に定義しています
- メンテナンス時などに想定外の事象が発生した場合は、(メンテナンス延長などで利用者への直接の影響はなくても)積極的に書く
- 他のチームへ想定外の事例を共有することで、同様のインシデントを発生しにくくするためです
2020年10月から現在まで、1年半の運用で計25本以上のポストモーテムが書かれています。
1本も書かれない月もたまにはあります
ポストモーテムを運用してみて
ポストモーテムを書くことを1年半運用してみて、実際に得られた効果は次のようなものがありました。
障害の原因追及や根本原因の解消が放置されにくくなった
インシデントはいつ発生するか分からないものです。特に業務時間外の夜間や休日に発生した場合、これまではその場での対応は行われるものの、その振り返りが行われないことが多くありました。
ポストモーテムを書くことで、後日発生原因を詳しく調査したり、根本原因の解消や再発防止策立案のために使う時間を強制的に確保できるようになりました。
社内の他のプロダクトで起きている事例を知る機会ができた
カヤック社内には多数のプロダクトがありますが、他のプロダクトで起きているインシデントを知る機会はこれまであまりありませんでした。Slackのパブリックチャンネルは自分が関わっていようといまいとどこでも出入り自由、ということになってはいますが、それでも自分の業務と直接関係がないチャンネルに参加している人はあまりいません(稀に、どこにでもいるような人はいますが……)。
社内の多くのプロダクトはある程度共通する技術要素を使っているものです。自分が関わっていない場所で起きたインシデントを月に1回、知る機会ができたことで、運用の参考にできることが増えたという声がありました。
プロダクトが消滅しても、その事例が保持されるようになった
社内に多数のプロダクトがあるということは、常に多数のプロダクトが生まれ、そして一方では死んでいるということでもあります。いろいろな事情で、数ヶ月や1年程度でクローズしてしまうサービスもあります。
発生したインシデントのドキュメントがそのプロダクト内に閉じた置き場所に書かれていた場合、どれだけしっかり書かれていたとしても、終了後は見返される機会がどうしても減ってしまいます。SREチームが一カ所にとりまとめることで、残念ながら終了してしまったプロダクトの事例も永続化できるようになりました。
あらたなツールが生まれた
ポストモーテムの中には、クラウドインフラやミドルウェアなどの設定が発生要因となったものもありました。これらは通常時には問題なく動作していたものの、高負荷時や長期間の運用を通して初めて発覚したものです。このような事例から得られた教訓を、他のプロダクトにも伝えるにはどうしたらいいでしょうか。
設定などに問題がないかをチェックするために、最初に思いつくのはいわゆる「チェックシート」です。しかし、チェックシートが好きなエンジニアは個人的な観測範囲ではほぼいない上に、内容を埋めるのも負担が大きいものです。一度のチェックならまだしも、継続的に同じ内容をチェックしてシートで管理するのは、大変なトイルになります。
そこで、チェックシートの代わりに設定項目の不備を機械的に検出するツールを内製することにしました。
ポストモーテムの運用から生まれた、この sre-advisor という名前のツールについては SRE NEXT 2022 というイベントの発表で詳しく紹介します。
sre-next.dev
まとめ
ポストモーテムをどのように運用しているか、ポストモーテムを書き続ける運用によって得られたメリットを紹介しました。
カヤックのSREチームは、最終的にはプロダクトに専任のSREメンバーがいなくても運用できる状態になることを目指して活動しています。そのためには、得られた知見をツールやコードで自動化された形に整備し、社内で横断的に適用できる状態にすることが求められています。
カヤックではSREチームで一緒に働く仲間を募集しています！
hubspot.kayac.com
