こんにちは。koid です。
この記事は Gunosy Advent Calendar 2022 25日目の記事です。 昨日の記事は ryoaita さんの PyO3 による Rust の Python バインディング でした。
早いもので、今年の Advent Calendar も最終日となりました。 今年の Advent Calendar でも、リモートワーク（以下リモート）における業務の進め方に関するエントリがいくつか書かれていました。元々我々はリモートではなく、オフィスに集まって働いていたのですが、コロナ禍以降、リモートにシフトしました。
今回は、障害発生時における、プロダクトマネージャー・セールス・メディアリレーション・広報などをはじめとした社内各所とのコミュニケーションがリモートになったらうまくいかなくなった話*1、そこでプロセスを見直した話について書きたいと思います。
オフライン時代の障害発生時コミュニケーション
冒頭に書いたように、元々我々はオフィスに集まって働いていました。オフライン時代では、コミュニケーションを強く意識しなくても、サービスに障害が発生すると、障害対応を始めたエンジニアたちのざわつき・発声によって、社内各所が障害を察知していました。また、「いまどんな状況？長期化しそう？」など、口頭でのコミュニケーションを行いつつ*2、それぞれが自立・分散・協調して、アプリユーザ様や取引先様へのお知らせ文面作成から、掲載や連絡などを行っていました。
リモートになって顕在化した課題
オフライン時代では、前述の「ざわつき」を契機になんとか回っていた障害発生時コミュニケーションですが、リモートになると途端うまくいかなくなりました。
リモートによってSlackメインのコミュニケーションになる中で、エンジニアは障害対応を行っているが社内各所に情報が行き届かない、結果的にアプリユーザ様や取引先様へのアナウンス等のアクションが大きく遅れる、ということが起きました。
ルールがあってもいざ障害が発生するとパニックする問題
もちろん、どのぐらいのSeverityのときに、どのSlackの部屋で、誰にメンションをつけて連絡、といったルール・フローチャートは設定していたのですが、普段なかなか発生しない障害がいざおこってしまうと、目の前の調査・対応に精一杯になり、「なにかあった気がするけどどこだっけ…」と、コミュニケーションルールの存在や在り処を忘れてしまいがちです。
障害対応で試行錯誤していると没頭しちゃう問題
これは自分自身も経験があるのですが、レスポンダーとして調査・対応を始めてしまうと、そこに没頭してしまい、関係者への状況共有等のコミュニケーションを忘れてしまいがちです。なんとか早く回復させたいという気持ちで、調査・対応に頭をフル回転させてしまうと、それ以外のことができなくなってしまいがちです。
前述の通り、社内各所が口頭で質問をしてくれれば、手を動かしながらも「状況を共有しなくては」という意識になるのですが、リモート下ではテキストのコミュニケーションも発生し、よりコミュニケーションが煩雑になり、億劫になってしまいがちです。
Slackで情報分散・断片化しがち問題
Slackで、いろんな部屋・いろんなスレッドで各所からの質問に都度答えることにより、情報が色々な場所に分散してしまうこと、更新が追えなくなることにより、情報が断片化しがちな状況に陥ってしまいました。これによって、情報の正確性が怪しくなり、情報の受け手が次のアクションを起こしにくくなってしまいました。
社内コミュニケーションをスムーズにするために
これらの課題を解決するため、インシデント・コマンド・システム／インシデント・レスポンスを参考に、いくつかのプロセスを見直してみました。
チェックイン
前述の「試行錯誤していると没頭しちゃう問題」に対し、レスポンダーが調査・対応に専念できるよう、他社事例等を参考にしつつ、改めて緊急時の役割分担を明確化しました。
現在、障害が発生したら設定する役割として、下記の役割*3を定めています。
- 指揮 (commander)
- 記録担当 (scribe)
- 社内共有担当 (liaison)
- 顧客共有担当 (customer-liaison)
- 対応担当 (responder)
下のイメージは、それを記した障害対応ログフォーマットの一部です。
我々のコミュニケーション課題に対して、scribeとliaisonを役割として明示したことは、効果があったように思います。
scribeが現況や共有すべき情報を整理・常に最新化し、liaisonが社内へのコミュニケーションを取りまとめることで、社内へのコミュニケーションのスピード・正確性を担保しつつ、responderが調査・対応に集中できるようになりました。同時に、複数ラインから同じ質問が飛んでくることも減らすことができました。
step-by-stepでのガイド / ロギング
既にチラ見せしていますが、前述の「ルールを整備してもいざ障害が発生するとパニックしてしまう問題」に対し、ログフォーマットという名のstep-by-stepでのガイドを用意しました。あわせて、「どこにあったっけ…」と探さなくても良いよう、Slackbotを活用しています。
ログを取っていくと自然に次に必要なアクションがわかってくるよう、stepを意識しながら項目を並べています。
ログを取ることのメリットとして、Slackのスレッドが深くなったり複数の部屋・スレッドに散在しがちな情報を、要約しつつ常に最新に保つことができ、liaisonが社内へのコミュニケーションを行う上での助けになりました*4。
また、これによって、「Slackで情報分散・断片化しがち問題」に対しても効果があったように思います。
ポストモーテム
障害対応が終わったあと、障害自体（技術面）のポストモーテムだけでなく、社内各所交えての障害対応の進め方・障害発生時コミュニケーションに対するポストモーテムを行うようにしました。
「こういう情報がもっと早く出てくると動きやすかった」「この情報がわかりにくかった（誤解してしまった」などを振り返り、次の障害時にはどうコミュニケーションを取るべきかという学びを得ています。
やってみて
上記の取り組みにより、（以前に比べてですが）少しずつコミュニケーションは洗練されてきたように思います。
また、上記のようなポストモーテムが波及し、ビジネスサイドでも、「アプリユーザ様・取引様に対して、こういうアクションができるとよかったよね」といった振り返りが起こるようにもなってきました。
終わりに
障害対応は、システムの対応だけすれば終わり、ではありません。 早く復旧するのはもちろん、利用してくださっているアプリユーザ様や取引先様に、誠実なコミュニケーションを行うことも、とても重要なことだと思っています。
日々の開発はもちろん、非常事態にも落ち着いて対応していくことができるよう、準備をしていきたいと思っています。
