はじめに
この記事はSTORES Advent Calendar 2022の13日目の記事です。
STORES 予約 のSREをしているaao4seyです。 少し前に STORES 予約 のチーム内で障害対応のやり方みたいなところの改善を行なったので、どういった課題があって、どういった改善を行なったのかについてご紹介できたらと思っております。
きっかけと課題
ある障害が発生した際に障害対応のやり方に関して、チーム内から次のような課題が出てきました。
障害対応中のコミュニケーションに関する課題
予約チームにはバックエンドエンジニアが10人程度在籍しているのですが、その中で障害の対応作業を行なっているメンバーとそれ以外のメンバーとのコミュニケーションが上手く取れていませんでした。障害の対応作業を行なっているメンバーの中で障害に関する情報が閉じてしまっており、それ以外のメンバーからは障害の詳細な状況がうまく把握できず自ら助けに入るといった行動が取りづらい状況となっていました。
なぜこのような状態が発生したのか推測してみると2つの要因があったのかなと考えています。
1つは当時の予約チームは採用を拡大している時期で毎月あたらしいメンバーがジョインしていました。そういったドメインに関する知識が少ないメンバーからすると障害対応に自ら入っていく心理的なハードル高い状況だったかもしれないということです。
もう1つは障害対応を行なっているメンバーは調査や修正に手一杯だったということです。私自身も立場上障害の調査、復旧作業を行うことがあるので障害調査中はシステムの復旧に目が行きがちでなかなか他のことまで気が回りづらいということを知っています。情報共有！と言われると一見簡単なように感じそうですが、システムで起こっていることをシステムに明るくない関係者にもご理解いただけるような内容で誤解なく共有するのは意外と大変です。
障害対応の仕組みに関する課題
障害が起こった際にやることはざっくり決まっていたのですが、粒度が荒かったためどういったタイミングで何をやるべきなのかのような細かい部分までの定義はない状態でした。
課題の解決案
これらの課題を解決するために2つの取組みを行うことにしました。障害対応時の役割を決めることと、Slackのワークフローにやることをまとめる ということです。
1つ目の障害対応時の役割を決めるでは、以下のようなことを取り決めました。
- 調査を担当するメンバー以外に新たにチーム内外とのコミュニケーションを担当する役割(社内では旗振り役と呼んでいます)を作ること
- 誰がその役割の人を任命するのかということ
この旗振り役のメンバーがコミュニケーションに徹することで、これまでうまくできていなかった「障害の状況の周知」や「調査の手が足りない場合に周囲を巻き込む」といった部分をカバーするようにしています。意思決定が必要な場合は旗振り役が意思決定に必要なメンバーを集めて意思決定を促すような役回りをします。
2つ目のSlackのワークフローにやることをまとめるでは従来からあった障害対応時に起動するSlackワークフローをより充実させ、ワークフロー通りに進めれば障害対応時にやるべきことがある程度終っている状態を作れるようにしました。また、1つ目の課題の役割決めのプロセスもこちらのワークフロー内で定義することにしました。
作成された障害対応 ワークフロー
この内容がSlackのワークフローとして登録されており、障害発生時にそのワークフローを起動してワークフローの指示に従い対応を進める形にしています。このフローは対応準備、障害対応、後作業の大きく3つのフェーズに分けることができます。
対応準備
このフェーズでは障害対応に必要な準備作業である全体周知と役割決め、ドキュメントの準備をします。
全体周知ですが、ワークフローを起動して概要を入力したタイミングで次のようなメッセージが部門のチャンネルに自動的に流れます。
次に、簡単にフローに登場する役割を紹介します。
- 役割
- お急ぎ便
- チームの中で普段から運用されている役割で、軽微なバグ対応や技術的な調査が必要なお客様からのお問い合わせ対応等を行なっています。(週ごとにローテーションしている)
- フローの中では旗振り役を決める役割としています。
- 旗振り役
- 前述したとおり今回新設したコミュニケーションを担当する役割です。
- 調査を担当する人を決めます
- 調査担当
- 文字通り調査や復旧作業を担当する役割です。
- お急ぎ便
役割決めは以下のようなイメージです。以下は旗振り役を決めるものですが、調査役も同じようにSlackワークフロー上のフォームでメンバーのSlackのアカウントを指定することで行います。
役割が決まったら必要なドキュメントをテンプレートから作成します。このタイミングではとりあえず仮のタイトルを入れてそのURLを周知することのみを行います。
- 作成するドキュメント
障害対応
調査担当は障害対応を行なっていきます。旗振り役は調査担当から進捗を聞きつつ、対応の履歴などをドキュメントに記載していきます。また、定期的な全体への情報共有や調査が難航している場合は周りのメンバーを巻き込むといったことも行なっていきます。
後作業
障害が収束と判断できたら後作業として以下を行なっていきます。
- 未完成のドキュメントの不足事項の記入
- このドキュメントには再発防止策も記載するのですが、この時点では決定していないことが多いので後から記入にしています。
- ポストモーテム(振り返り)に利用する記事の作成
- ポストモーテムのスケジュール決定
スケジュールまで決めてしまうことによって記憶が新しいうちにポストモーテムをやりきってしまうことを意識しています。
実際に運用してみて
このフローを策定してしばらく運用してみていますが、以下のような効果が出てきています。
- 調査担当が調査へ集中できるようになった
- 障害の状況がよりチーム内外へ周知されるようになった
- チーム外からのサポートが徐々に増えている気がする
当初課題となっていたコミュニケーション部分が徐々に改善されていっているように感じています。エンジニアチームから正しく情報を発信することによって他のチームからもこういったことしましょうか？といったサポートも増えてきている状況です。
さいごに
プロダクトが成長し更新されていく限り障害を0にすることはなかなか難しいですが、いざというときの備えをしておくことで慌てずに対応することが可能になります。 STORES 予約のSREチームとしては障害を未然に防ぐといった取り組みももちろん行なっていますので、今回ご紹介した障害対応の部分以外でもご興味持っていただける部分がありましたらぜひカジュアル面談などにいらしてください。
- エンジニア向け採用サイト
- Hello STORES
