お久しぶりです。SREグループの菅原です。
おすすめのアイスはオハヨー乳業のBRULEEです。夏場は1日にアイスをいくつも食べてしまいました。もう末期ですね。
弊社ではポストモーテムをバックエンド(サーバーサイド+SRE)で運用して3年経ちました。2019年のSREチームを立ち上げ直後から導入しており、そこで作った運用ルールを基に現在も引き続き運用しております。今回は弊社のポストモーテムについて詳しくご紹介します。
目次
ポストモーテム導入で何を解決したかったのか？
以前のスタディプラスでは以下の課題があり、それらを解決するためにポストモーテム導入を推進しました。
障害対応のドキュメントが単なる作業証跡だった
障害が起きた際には障害対応のドキュメントとしてまとめる文化は既にありました。しかし、振り返りをする訳ではなく、作業の証跡として残しているという状況でした。障害発生時刻や影響範囲、発生原因といった項目があるものの、事実と推測が入り混じっていたり、再発防止策を議論した経緯が追えない形になってました。どうしてこの時、この判断をしたのか読み取れるドキュメントになっていませんでした。
障害対応を率先して行うメンバーに偏りがあった
障害対応を率先して行うサーバーサイドメンバーに偏りがあるという問題もありました。弊社はマイクロサービスを採用しているのですが、それぞれのマイクロサービスで詳しいメンバーとそうでないメンバーに分かれていました。例えばAサービスはA'さんが、BサービスはB'さんが詳しいといった状況でした。
システムの理解度に差が生まれがちだった
障害になると素早く復旧させる必要があるため、詳しいメンバーが率先して対応することになります。そうするとサービスに詳しくないメンバーは経験が積みづらく、情報の格差が生まれ易い状況でした。例に漏れずインフラ側もその状況に陥っており、インフラで何か障害が起きるとインフラエンジニアに聞かないとわからないという形になっていました。
ポストモーテムの布教
前述の通り、障害対応のドキュメントを書く文化やDevOpsをやっていくといった意識はあったので、導入にそれほどハードルはありませんでした。
まず行ったのはSREについての共有です。SREチーム創設したときには「SREは結局何してくれるチームなの？」という疑問を他のチームから頂いていました。そこでオライリーのSRE本から大事な部分を抽出してスライドを作成し、社内登壇という形で共有しました。その中で「ポストモーテムとは何か」を伝えたところ、弊社でもやっていきたいという機運が生まれてきました。
ポストモーテムのルール作成
ポストモーテムのルール自体はSREチームで作成しました。ドキュメントにまとめているのですが、特に以下の項目は試行錯誤して追加していきました。
ポストモーテムを書くべきインシデントの基準
どのくらいのインシデントでポストモーテムを実施するべきかという基準を書いています。 サービスの性質やインシデントの頻度にも寄りますが、振り返ると効果的なポストモーテムに集中するため、弊社では主に以下5つの基準を設けています。
- 1分以上一般ユーザーに影響が出たダウンタイムの発生 (システムメンテナンス時を除く)
- 種類の如何を問わず、データの損失が生じた場合
- 一般ユーザーから見て何か使えない機能があり、その状態が30分を超えた場合
- 件数や発生期間を問わず、通知(メールやDM、push通知)が飛ばなかった
- 件数や発生期間を問わず、セキュリティインシデントが発生した場合
当時この辺りの基準設定には悩みました。SLOを設定する前にポストモーテムの導入をしたので、どのくらいの影響範囲や時間にするべきかといった部分が難しかったです。この辺りの基準もSLOから逆算したり、実際に過去に起きたインシデントの頻度から設定すると良さそうです。
ポストモーテムのレビュー
ポストモーテムを実際に運用し始めた後に出てきた問題に、ポストモーテムまでにドキュメントを読まないメンバーがいたり、再発防止のアイディアを書くメンバーが固定化されるということでした。
そこでレビューまで行うことをポストモーテムの一連のタスクとして設定しました。ポストモーテムを記載する担当者はポストモーテム実施日の24時間前までに書き上げて、他の参加メンバーにレビューと再発防止アイディアの記載を依頼するという運用にしました。
レビューをしてもらうことで全員が事前にドキュメントを読み込むことになります。するとポストモーテムのミーテティングではアクションアイテム(再発防止策)の議論に集中でき、効率的に時間を使えるようになりました。
ポストモーテムの運用
ポストモーテムの運用を続けていく中で、ポストモーテムを継続していくために工夫や改善したポイントを挙げていきます。
ポストモーテムの担当者
ポストモーテムの運用を開始してはじめの内はSREメンバーが担当者になり、ドキュメントの作成やファシリテーションするようにしていました。まずはポストモーテムの習慣であったり、雰囲気を作ることに尽力しました。徐々にSRE以外のサーバーサイドメンバーも担当者になってもらい、担当を回してもらうことでポストモーテムを広めていきました。
ポストモーテムの実施タイミング
ポストモーテムを書き始めてから長く放置されてしまい、振り返りをするモチベーションが下がってしまうという問題が出てきました。そこでスクラムイベントのスプリントレビュー内でポストモーテムを実施することにして、実施するタイミングや期限を明確に決めることにしました。スプリント内で起きたインシデントをそのスプリントで振り返りするようにしたため、リズムを作りやすくなりました。
ポストモーテム自体の振り返り
ポストモーテムを運用して1年くらい経った頃に振り返りのミーティングを実施しました。1年以上運用した結果、建設的な話し合いができるチームに成長していたり、障害が起こりづらいシステムになっている実感を得られました。一方で、レビューがおざなりになっていたり、アクションアイテムがいつまでに実施されるか曖昧になっているなど改善すべき部分も見えて来ました。
ポストモーテムの仕組み自体の振り返りはポストモーテムの改善だけでなく、ポストモーテムが建設的に議論できる場だという認識合わせにもなるのですごく有意義なミーティングになりました。今後は年に1度くらいの頻度で振り返りを行っていきたいです。
ポストモーテムのテンプレート
最後に現在弊社で使っているポストモーテムのテンプレートを紹介します。運用を始めた当初は例を書いていなかったのですが、書き方の粒度にばらつきがあったので統一をするため、記載するようにしました。
# 現在のステータス
- 完全に収束したのか、それとも完全収束にまだ時間がかかるのか
# ユーザ影響
- この期間どの機能にアクセスできなかったとか、収益に影響があったかとか
- 例) 2020/12/22 10:34〜11:20までの間、全ユーザが勉強記録をつけられなかった
- 例) 2020/12/20 12:01〜12:42までの間、Androidユーザにpush通知が届かなかった。またその期間のいいね通知データを損失した。
# 検出
- なにでその障害に気づいたか
- 例1) CSからの報告
- 例2) Datadogのアラート
# 根本原因とトリガー
- 例1) PR(Githubへのリンクを貼る)。このPRをデプロイ後、自分の勉強記録タイムラインに60s以上かかるようになりnginx側でリクエストがタイムアウトになり自分の勉強記録タイムラインが表示されなくなった。
- 例2) 〇〇作業(ドキュメントへのリンクを貼る)の際に作業ミスが起こりRedisインスタンスを削除してしまったためキャッシュがなくなった。その後大量のDB問い合わせが発生しDBの負荷が高まり多くのリクエストがタイムアウトになった。
# 時系列の対応
- hh:mm 〇〇を本番環境にデプロイ
- hh:mm 障害発生
- hh:mm アラートが発生
- hh:mm 〇〇を切り戻し
- hh:mm 〇〇のメトリクスが正常に戻ったことを確認
- hh:mm 障害解消
# 教訓
- 障害発生から解消の間にうまくいったこと
- 例1) 障害発生から1分後に監視アラートが届き、すぐに対応を開始することができた
- 例2) 以前サーバー台数を手動で増やす手順書を用意していたために、迅速にサーバー台数増やすことができた
- 障害発生から解消の間にうまくいかなかったこと
- 例1) 監視アラートが設定されていたが通知設定が間違っていてアラートがslackに届かなかった
- 例2) 以前用意した再起動プログラムがうまく動かなかった
- 例3) オートスケールアウト機能が想定通り動かなかった
- 幸運だったこと(ここには本当にニアミス(ヒヤリハット的な)だったことを書きます)
- 例1) たまたま1台だけデプロイが失敗していたため機能がすべて使えなくなるということは回避された
- 例2) 前日に〇〇対応のためにサーバー台数を2台から4台に増やしていたおかげで急激な負荷の影響を軽減することができた。2台だったら状況は更に悪くなっていただろう。
# アクションアイテム(恒久対応策・再発防止策)
恒久対策・再発防止策は、やる/やらない, すぐにできる/できないに関わらず考えられるものは全て出す。その上で実際に取り組むことを選択する
- hoge
# ネクストアクション(採用されたアクションアイテム)
ネクストアクションが決まったら、忘れないようにすぐにタスクにしましょう
- hoge
まとめ
弊社のポストモーテムについてお話しさせていただきました。SRE以外のメンバーの理解と協力もあって、弊社では運用が3年続いています。これからも振り返りをしてより効果的なポストモーテムを目指していきたいです。
