こんにちは。SREの@kyontanです。スタディサプリのSREチームにジョインしてから初のブログ記事となります。
つい先日、スタディサプリ 中学講座が大幅リニューアルされました。*1 今回は、そのリリースを自信を持ってユーザーの皆様へお届けするために実施した、プレモーテムという取り組みについてご紹介したいと思います。
背景
今回のスタディサプリ 中学講座のリニューアルは、バックエンド、フロントエンド(Web/iOS/Android)の開発をフルスクラッチで行ったため、大規模なリリースとなりました。 すでにユーザーへ提供しているサービスを、段階的にリニューアルされたものへ切り替えていく複雑なリリースということもあり、リリースにあたっては予期しないトラブルが起きる可能性が推測できます。
通常、さまざまなトラブル(障害)が起きた際には、私たちはあらかじめ定めた障害対応フローに沿って対応を行い、その失敗を繰り返さないためにポストモーテムを残して、再発防止に努めます。 障害対応やポストモーテムの取り組みについては、過去に同じチームの @chaspy がブログを投稿しているので、こちらもご参照ください。
なぜプレモーテムをするのか
今回のように新規開発のコンポーネントを多く含むリリースを行う際には、過去に起きたことのない障害が起こる可能性が非常に高く、可能な範囲でこれらを事前に予期して回避したいと考えました。
そこで、今回はリリース時の意図せぬ事象に対する防災訓練としてプレモーテムを実施しました。 今回は、プレモーテムを実施することにより、次のような事柄を明確にすることを目指しました。
- 何が起きたらユーザーが期待する動作を満たせなくなるか?
- それは何によって引き起こされうるか?
- 他にその問題を引き起こしうる原因は考えられるか?
- その問題が起きることは許容できるか?
- どの程度の可能性で起こると考えられるか?
- その可能性で起きることはプロダクトとして許容できるか?
- その問題はどうしたら回避できるか?
- 根本的にその問題が起きないようにすることはできるか?
- その問題はどうしたら検知できるか?
- モニタリングやアラートは適切に設定されているか?
- 日頃から確認している場所で通知されるか?
- QA観点や手順に抜け漏れはないか?
- その問題が起きてしまったとき、どのように対応するべきか?
- サービスを一時的にメンテナンスモードにする必要はあるか?
- ユーザーへお知らせをする手段は確立されているか?
- エスカレーションの対応フローは整備されているか?
まさにポストモーテムで書くべき内容そのままですね。 これらを事前に考え、障害を未然に防ぐことは「0回目のポストモーテム」と表現することもできるのではないでしょうか。
スタディサプリでは、以前にも異なる観点でプレモーテムを実施していますが、これはプロジェクト初期に行ったアクティビティであり、今回のリリース時の取り組みとはスコープが異なることをご理解ください。
プレモーテムの進め方
プレ・プレモーテム
今回は、スタディサプリ 中学講座の Web Application Engineer である @ywada526 に全体のファシリテーションなどをお願いし、SREの私は準備のサポートなどをするに留まりました。 @ywada526 の圧倒的な準備力とファシリ力の高さにひたすら感嘆するばかりでした。
プレモーテムは準備が肝要ということで、Atlassianの記事 (チームとともにプロジェクトのプレモーテム演習を行う方法)などを参考にしつつ、今回のプレモーテムはどのように進めるかを考えるプレ・プレモーテムを実施しました。
プレ・プレモーテムでは、プレモーテムをすることによって、チームがどのような状態になることが期待できるかを改めて整理し、何を整理したら安心してリリースに臨めるかを考えました。
今回のリリースは複数段階に分けて行われるということもあり、プレモーテムも各段階ごとに実施することにしました。 そこで、それぞれのプレモーテムが対象とするイベントを絞り、それぞれのプレモーテムが関連するチームはどこか、誰を呼べば必要な観点が洗い出せそうかなどを相談しました。
また、プレモーテムでのブレストをスムーズに行うために、リリース当日の流れをあらかじめ整理し、どのような手順で誰がどのようにリリースを行うのかなども整理しました。 これらを整理している段階で、すでに「当日はXXさんが○○をすることになっているけれど、XXさんが当日急にお休みしたらどうするんだっけ?」というような、確かにありそう……といったリスクに早速気付くことができました。
プレモーテム
今回はプレモーテムを計2回実施し、それぞれ10人前後で1時間程度の時間を取って実施しました。
- プレモーテムの説明
- リリースの流れの確認
- 当日は、どのような流れで、どのチームが何を実施するのかを確認しました
- リスクのブレスト
- 考えうるリスクをざっくばらんに書いてみる
- ブレストの結果読み上げ
- 起こりそうな事象を記入した人が、参加者に「そのリスクがどのようなもので、なぜ起きそうか」などを簡単に説明する
- 投票
- 今回のプレモーテムの時間内で議論した方が良さそうな(重要性が高そうな)リスクに投票する
- ディスカッション
- 投票の多かったリスクから順に、前述の観点(「なぜプレモーテムをするのか」の節を参照)でディスカッションをする
- プレモーテムの時間内に解消できなさそうなリスクについては、担当者を決め、別途検討してもう
- 結果のシェア
- ディスカッションを行った結果や、別途検討した結果を docs へまとめてもらい、チームへシェアする
初回はブレストをリアルタイムで行いましたが、想定以上に盛り上がったこともあり、大量のリスクが洗い出されて時間不足になってしまいました。 そこで、2回目はブレストを非同期で実施し、事前に考えられそうなリスクをある程度スプレッドシートに記入してもらい、リスクを類型化した上でプレモーテムに臨みました。 初回のプレモーテムの様子をスクリーンショットでご紹介します。 このように、提示されたリスクに対して絵文字で投票を行い、多かったものから順番に議論をする形式を取りました。
ブレストでは、この他にも「リリースが延期になった場合の裏締め切りはいつ?」「プロモーション開始までにリリースできなかったら?」「〜が起きたときにはどうやってユーザへ周知する?」というような、普段はあまり開発者が意識することのないリスクも提起され、プロダクトには色々な専門性を持った人々が関わっているのだと実感しました。
今回の学び
今回のプレモーテムを実施した結果、なんと70件以上ものリスクがブレストで提起され、大なり小なり議論されることとなりました。 すでに対応方法が検討されており、許容できるものもありましたが、「これは確かに起こりそうだが、起きたときのことは考えたことがなかった」「普段は少し聞きづらいけれど、こういうリスクは想定されているの?」「このリスクは生じないと思っていたけれど、よく考えてみたら起こるかもしれない」といったものもあり、個人的にはとても学びの多いプレモーテムになりました。
また、可能性が高そうなリスクについては個別で検討を行いましたが、それらの検討からは漏れているかもしれない、未知のリスクに直面したときの一般的な対応についても検討を行うことで幅広いリスクをカバーできるようにしました。
当初、私たちはプレモーテムは「消化対策」の精度を上げるために行うアクティビティであると認識していました。 しかし、実際にプレモーテムを実施した結果、何か起きたときの対処の検討(防火対策)や、一定のリスクを許容することによりより重要なことへリソースを割く(受け入れる)といったことの検討もでき、プレモーテムは非常に強力なアクティビティであるという感想を抱きました。
これにより、当日はプロダクトチームとして安心してリリースに臨むことができたのではないかと考えています。
今後に向けて
今はまだ初回のリリースができた段階であり、今後もさまざまなリリースは続いていきます。 何かサービスに変更を加えるとき、そこにどのようなリスクがあるかを考え、チームとしてどう望むかを考えるプレモーテムという取り組みは今後のProduction Readinessについて考える上でもきっと役に立つと考えています。
おわりに
スタディサプリでは、起きうるリスクを共に考え、乗り越える方法を共に考えていける仲間を募集しています。
