プロダクトエンジニアリング部の吉田と申します。
普段はRubyやTypeScriptといった言語を使ったサーバサイドエンジニアをしています。
今回、サイトの閲覧障害をきっかけに行ったポストモーテム会が個人的にとても有意義だと感じたので紹介させてください。
障害分析レポートの紹介
弊社では障害が起きた場合、障害分析レポートを書くという決まりがあります。
この障害分析レポートというものは、一般的にはSREの用語でポストモーテムとして知られている障害対応時のことを記録する文書のことです。
弊社では品質管理を行っている部署がテンプレートやフォーマットを整えてくれており、内容としてはオライリーのSRE本の付録Dに記載してある「ポストモーテムの例」にかなり似通った内容です。
かいつまんで紹介すると下記のような内容を記載するものです。
- 障害の概要
- 影響範囲
- タイムライン
- 水面下で起きていた問題（根本の問題など）
- 教訓（良かったこと、悪かったこと）
これらを書くことでいったい何が起きていたのかを後から振り返ることができ、同じ過ちを繰り返さないためのアクションを考えることができる、というものです。
障害分析レポートの運用上の課題感
ただ、個人的にこの障害分析レポートの"運用"に課題があると常々感じていました。
その課題とは、障害分析レポートを書く人の主観に基づいた記載だけで終わりがちであり、"障害発生時の対応方法の改善"に寄与しないという点です。
障害分析レポートは障害対応が落ち着いたら上記のフォーマットにのっとって記載する、というところまでルールとして存在していますが、それ以外については何も定まっていません。
フォーマットについて書くと、何が起きて（Why）、誰が（Who）、いつ（When）、何を対応したか（What）は分かりやすい構成になっています。
しかし、タイムラインの項目で どう対応したか（How） の部分をどれくらい書くのかは書く人の裁量に委ねられています。
障害発生時にどのような調査をして、対応したメンバーの間ではどのように連携を取っていったのか、ということまで書く人はそう多くありません。
これでは再び障害が発生して別のメンバーが対応するとなった場合、どう振る舞えば良いのかということをその場その場で学ぶしかありません。
また、リモートワークをしている昨今では、チャットの文字上だけでコミュニケーションを済ますことが多いです。
障害対応をするときは阿吽の呼吸のようなものが求められることもあり、オフィス勤務をしている際には部署を超えて一ヵ所に集まって声を掛け合いながら作業をするということも珍しくありませんでした。
しかし、リモートワークではお互いの姿が見えないのでそれも難しいことです。
これは完全に私の主観混じりの決めつけに近いものですが、お互いの姿が見えないということでコミュニケーションロスが発生していたはずだ、だからそこには障害対応時の改善点があるのではないかと睨んでいました。
そういったことも踏まえ、障害分析レポートの物自体は良いのに活用ができていない、と感じていたのです。
上記のような課題感を抱えていたあるとき、休日に障害が発生し、関係者全員がリモートワークでの障害対応を強いられる状況になりました。
そして対応後、感じていた課題感を明らかにするべくポストモーテムを振り返る場としてポストモーテム会を開くことを提案しました。
ポストモーテム会の実施前の準備
今回は私が障害分析レポートを書き、それを土台にしてチームで話し合う会として設定をしました。
話し合う内容としては下記のとおりです。
- 障害分析レポートに書かれていないけど伝えたかったこと
- Slackで書くほどでもないが当時起きていたこと
- Slackには書かなかったが実は思っていたこと
特にそれ以上のことは決めておらず、時系列を見ながらああでもない、こうでもないとワイワイする感じです。
また、私が書き忘れていた、書き漏らしていたという出来事も話し合う過程で補完されていくだろうという狙いがあります。
休日明けの最初のミーティングのタイミングでメンバーにポストモーテム会を提案しました。
今回参加したメンバーには申し訳ないのですが、私の感じている課題感の共有はそこそこに、やりたいからやらせてくれ、といった感じでやらせてもらいました。
本来はもう少し丁寧に共有すべきだったと反省しています。
障害分析レポートのテンプレートに沿って書いた時系列
障害分析レポートのテンプレートに沿って書いた時系列は以下のようになりました。
| 時間 | 起きたこと | 対応 |
|---|---|---|
| 02:05 | 外部サービスの影響で特定のページが閲覧できなくなる障害が発生 | |
| 10:30 | ユーザーが増えたことでアラートが鳴る | |
| 10:45 | エンジニア2名で調査を開始（当時のSlackへのリンクを貼っている） | |
| 11:14 | 特定のデータが原因である可能性が濃厚だと判断し、データを管理しているインフラ部門へ協力を要請（当時のSlackへのリンクを貼っている） | |
| 11:40 | インフラ部門が対応できない可能性を踏まえ別の方法を検討しているところ、主管部門から対応を開始する連絡をもらう（当時のSlackへのリンクを貼っている） | |
| 12:10 | 障害解消 | インフラ部門による対応が完了（当時のSlackへのリンクを貼っている） |
初動から約1.5時間の出来事、わずか6行にまとまっており簡潔でわかりやすいですね。
括弧書きをしているように証跡となるSlackのやりとりのリンクを記載しているので詳細な内容は追おうと思えば追えますが、この表を見ただけでは障害対応時にコミュニケーションロスなどの課題があったかどうかまでは見えてきません。
他にも10:45のエンジニアが何をどう調査していたのかはこの記載からは分からなかったり、11:14のところでもブログ記事向けに「特定のデータ」とボカして書いていますが、社内向けに書いたレポートでも具体的に何のデータのことかを書いていませんでした。
また、11:14〜11:40まで何をやっていたのかも分かりません。
こうして振り返ってみると自分でも粗が目立つとは思うのですが、書いた直後はこれで良いと思っていました。
これを見ながら複数人で話し合うことにより情報が補完できれば、という狙いです。
ポストモーテム会をやってみての時系列
上記を元にポストモーテム会を行った結果、細かく補完された時系列は以下のようになりました。
| 時間 | 起きたこと | 対応 |
|---|---|---|
| 02:05 | 外部サービスの影響で特定のページが閲覧できなくなる障害が発生 | |
| 02:30ごろ | 実はエラーが出始めていたが、そのページのアラートの設定が漏れていた | |
| 04:31 | アラートが鳴っていたが Slackの @here を利用しているため通知が飛んでいなかった |
|
| 10:30 | @here とか関係なしに通知をする設定にしていた1名が気付く（Aさんとする） |
Aさんが調査を開始する |
| 10:35 | 私がアラートに気付きSlackにて調査開始宣言をする | （エラーログの一部をレポートに貼り付け）エラーログが分かりづらく原因の特定に難航する |
| 10:45 | Aさんと私がSlackでコミュニケーションを開始 Aさんがかつて実装に関わったこともある関係で当時の記憶から心当たりを見つける |
|
| 11:14 | （Aさん）原因を特定しインフラ部門に対応を依頼するが、 休日ということもあり遠慮してメンションはつけなかった また、アプリケーション側で対応することも検討したが対応するアプリケーションが多かったのでインフラで一括対応するほうが速いと判断した |
|
| 11:18 | （私）緊急と判断し、メンションをつける | |
| 11:24 | インフラ部門が反応、私用のため20分ほど動けない旨の連絡をもらう その間、もっと短時間で解消する方法を模索する |
|
| 11:40 | インフラ部門から対応を開始する連絡をもらう そのままインフラ部門に対応してもらったほうが早そうなので別の方法の模索を打ち切り影響範囲調査に作業を転換 |
|
| 12:10 | 障害解消 | インフラ部門に対応してもらったが、インフラ部門内での対応手順が定まっていなかったので手こずってこの時間になってしまった |
| 12:35 | 影響範囲調査が完了、Slackにて報告 | |
| 12:40 | 解散 |
2倍近くの行数になり、だいぶ肉付けされましたね！
前述の10:45前後の内容が充実したおかげでどういう振る舞いをしていたかも分かりますし、原因特定に至った流れも分かるようになりましたし、11:14〜11:40の間に行っていたことも分かるようになりました。
ポストモーテム会後の時系列を受けてのアクションを決める
そして太字にした部分は、 障害対応における改善点 です。
これは最初の時系列などでは見えてこないもので、ここを改善することで障害から復旧までの短縮につながると考えられます。
理想を言えば手作業なしに復旧するのが望ましいですが、現実問題としてそうはなっていないので、オペレーションを改善するのも大事なことですね。
上記で太字にした部分に対応するアクションとして大まかに下記の3つを行いました。
- アラートの対応が漏れていたので設定をするチケットを作成した
- アラートは
@hereではなく@channelにするチケットを作成した - 障害発生時はタイミング関係なく、遠慮なくメンションをするというルールにした
他にもアプリケーションの改善といったアクションもあるのですが、今回の障害対応の改善の趣旨から外れるためここでは省略することにします。
まとめ
障害はいつ起きるものか分かりません。そのときに備え、ちょっとした対応でも複数人の目で振り返ってみることで新たな発見があり、小さいかもしれませんが改善を積み重ねることができるのではないかと思います。
なんなら今この記事を書いている最中にも「このアクションを入れたほうが良かったのでは？」という発見もあったりして振り返ることの大事さを噛み締めています。
みなさんもポストモーテム会を開いてみてはいかがでしょうか？
LIFULLでは共に改善を積み重ねていく仲間を募っています。 よろしければこちらのページもご覧ください。
