SRE課で、主にBacklogのSREを担当しているMuziです。
Backlogでは2019年8月から、アプリケーションの障害については、開発チーム自身が対応できるオンコール体制を取っています。これにより、サービス影響の少ないアプリケーション障害については開発チーム自身で対応できるようになりました。
しかし、サービス影響の大きいものについては依然としてSREの対応が必要な状況が続いていました。この問題を解決するために、インシデント対応をするオンコール担当者のためのチェックリスト（以下、インシデント対応チェックリスト）を新たに考案し、今年の7月から導入しました。
今回の記事では、このインシデント対応チェックリストの詳細に加えて、導入に至った背景からその効果までご紹介します。開発チームへの運用ノウハウの移管について悩んでいる方の参考になれば幸いです。
目次
Backlogのオンコール体制
元々、Backlogではインフラとアプリの両方についてSREチームがオンコール対応を行っていました。アラートの一次対応と、再起動などのワークアラウンドをSREが実施し、それでも解決できない場合のみ開発チームにエスカレーションしていました。
しかし2019年8月に、アプリケーションの障害については、開発チーム自身が対応するオンコール体制を導入しました。オンコール体制の導入をスムーズに進めるため、SREチームは、必要なアラート（アプリケーション関係のアラート）を、必要な人（オンコール担当者）のみに通知するアラート通知システムを開発しました。
アラート通知システムの全体像（過去のブログ記事からの抜粋）
これらの詳細については、以前に、私のブログ記事にて詳しく紹介しました。もし興味ありましたら、こちらもご覧ください。
Backlog開発チーム自身によるオンコール対応を支えるアラート通知システム | Backlogブログ
このオンコール体制およびアラート通知システムは、導入から2年以上経過しましたが、現在もうまく運用されています。しかし、その運用を通して、このオンコール体制の課題もいくつか見えてきました。
前提知識：インシデント指揮者
オンコール体制の課題について詳しく話す前に、話を理解しやすくするための前提知識として、「インシデント指揮者」という考え方を含むインシデント管理のシステムについて説明させてください。
このインシデント管理のシステムは、Googleで実践されているSREの方法論を紹介した「SRE サイトリライアビリティエンジニアリング」（以下、SRE本）の14章「インシデント管理」、およびその実践編といえる「サイトリライアビリティワークブック――SREの実践方法」（以下、SREワークブック）の9章「インシデント対応」で紹介されています。
SRE本に書かれていることを自分なりに要約すると、こんな感じになります。
『インシデント対応時はみんな焦っているから特定の人が仕事を抱えてしまって、本来できるはずの作業分担や、必要な情報伝達がうまくいかなくなる。連携せずに作業すると、別の人の作業とバッティングして障害が悪化することもある。だから、インシデントごとに「インシデント指揮者」「実行担当者」「コミュニケーション担当者」「計画担当者」などの役割を明確化し、作業分担を明確にしよう。』
SREワークブックはこれを実践しやすい形にして、インシデント対応における主な役割を以下の3つと定義づけています。個人的には、SREワークブックの方を読んでやっと実践のイメージを掴むことができたので、こちらを読むのをおすすめします。
- インシデント指揮者（Incident Commander, IC）
- インシデント対応の指示を出し、調整し、必要に応じてその役割の一部を委任する
- コミュニケーションリード、実作業リードから最新状況の報告を受ける
- コミュニケーションリード（Communication Lead, CL）
- インシデント対応チームとステークホルダーに、定期的にアップデートを提供する
- インシデントに関する社内外からの問い合わせを管理する
- 実作業リード（Operations or Ops Lead, OL）
- インシデントの緩和または解決のための実作業を指揮する
Backlogのオンコール体制の課題
Backlogのアプリケーションに関するオンコール体制の課題は、この「インシデント指揮者」としての役割を、SREチームから開発チームにうまく引き継げなかったことでした。これにより、本来必要ないはずの負荷がSREチームにかかり続けていました。この課題を少し詳しく説明します。
これまで、マニュアルに記載された範囲のアラートについては、マニュアルに従ってオンコール担当者が迅速に対応できていました。これは、2019年に導入されたオンコール体制の大きな成果でした。
しかし、解決が難しい障害の場合は、オンコール担当者1〜2名で調査に時間をかけてしまい、お客様への連絡や、他の開発者やSREとの共同作業が遅れがちでした。そのため、初動はオンコール担当者が行うが、サービス影響が大きそうな場合はアプリケーション関係のインシデントでもSREがインシデント指揮者になる、という運用が定着してしまっていました。
インシデント指揮者になる、といえば聞こえはいいですが、この概念を持っているSRE以外にしてみれば「指揮系統を横取りしている」ように見える行動です。少なくとも私にとっては、作業時間がかかること以上に、これが気の落ち着かないことでした。
これまでの連携方法
インシデントの内容によっては、開発チームからSREチームへのエスカレーションが必要なケースは当然存在します。ただ、それは以下の図のような連携方法でいいはずです。
あるべき連携方法
過去に試した対策
「それなら、開発チームにインシデント指揮者として動くための教育をすればいいのでは？」と考えるのは自然な発想かと思います。
私たちも、開発チームに対してこのような問題があることを伝え、インシデント指揮者の引き継ぎについて議論を重ねてきました。この議論のなかで、同じSRE課の大城さんが、インシデント指揮者に必要なスキルを整理してくれました。しかし、必要なスキルが多すぎるということで、この引き継ぎはうまくいきませんでした。
確かに、各開発者にオンコール担当が回ってくる頻度（約2ヶ月に1回）から考えると、開発チーム全員にこの教育をし、かつ定着させるというのは現実的には思えませんでした。オンコール対応だけでも、開発者から「自分のオンコール担当の期間にアラートが発生しなかったので、方法を忘れてしまった」という意見が時々出て、その都度説明をし直してきました。そのため、開発者が覚えるべきことを更に増やすのは難しいと考えました。
そのため、まずは開発者にインシデント対応の様子を見学してもらうということを試しました。各開発チームから数名ずつ選んでもらい、インシデント発生時にはチャットボット経由でそれらの代表者にメンションを通知しました。これにより、インシデントの事後対応は以前よりスムーズに引き継げるようになりましたが、インシデント指揮者については引き継げないままでした。
インシデント対応チェックリスト
このような活動のなかで、私はあるときふと、「インシデント指揮者が取るべきタスクをチェックリストとして簡略化し、かつそのチェックリストを情報共有のためのホワイトボードとしても使えばいいのではないか？」と思いつきました。それが、今回紹介するインシデント対応チェックリストです。
インシデント対応チェックリストとは、
- チェックリストに従うことで、自然とインシデント対応の役割分担が決まる
- チェックリストに従うことで、それぞれの役割（インシデント指揮者など）に求められる行動を取ることができる
- 役割を持っていない人も、ここを見ればすべての状況がわかるため、他人の作業を止めて状況を聞く必要がなくなる
ことを目的とした、Googleドキュメント（Google Docs）のファイルです。
私たちはGoogleドキュメントを用いましたが、以下の機能を持っていれば他のエディタでも実践できると思います。
- テンプレートから新しいファイルを作成できる
- 同時編集ができる
- チェックボックス機能がある
また、弊社は2020年よりフルリモートを前提としているためオンラインツールを活用せざるを得ませんが、オフィスで働いている場合は実際のホワイトボードを使うこともできるかもしれません。
インシデント対応チェックリストの全体像は以下の通りです。前半パートはチェックリスト、後半パートは情報共有のための対応記録欄になっています。なお、説明のために、実際に使用しているものより内容を簡略化しました。
インシデント対応チェックリストの全体像（1ページ目）
インシデント対応チェックリストの全体像（2ページ目）
インシデント対応チェックリストの全体像（3ページ目）
以下、各パートを詳しく見ながら説明していきます。
前半パート：チェックリスト
インシデント対応チェックリストの導入にあたり、SREチームは、障害対応のためのチャットルームにいくつかのチャットボットを用意しました。ヌーラボの場合は、Typetalkという自社サービスのチャットツールを利用しており、その中のBacklog Emergencyトピック（チャットルーム）でインシデント対応を行っています。
インシデントが発生した際、オンコール担当者は、Backlog Emergencyトピックで@emergency-checklist+ボットを実行します。このボットがGoogleドキュメントにファイルを作成し、そのURLをBacklog Emergencyトピックにポストします。
このファイルを開くと、まず以下のようなチェックリストが目に入ります。
チェックリストの前半
このチェックリストに従ってボットを実行すると、開発チームおよびサポートチームのメンバーが、Google Meetの会議室に招待されます。この会議室の参加者は、自分たちの中から今回のインシデントでの役割分担を決めて、後述する対応記録欄に記入します。
役割分担が決まったあとは、各自がチェックリストを見ながらインシデント対応を進めます。このチェックリストに従うことで、それぞれの役割に求められる行動を取ることができます。チェックリストを見てもらえれば、インシデント指揮者のためのチェック項目が特に多いことに気づかれると思います。
チェックリストの後半
開発者がインシデント対応を行う頻度は低いため、単純なチェックリストだけにしてしまうと、項目の意味を忘れてしまって対応できない可能性があると考えました。そのため、内容を思い出しやすくするために、チェックリスト中に各項目の短い説明も含めました。しかし、文章が長すぎると逆に読みづらくなるため、そのバランスは現在も調整中です。
後半パート：対応記録欄
対応記録欄は、インシデント対応の最中に、ホワイトボードのように用いる記入欄です。
いままでは、Google Meetの会議室でインシデント対応をしている最中の人に、後から参加した人が「いまどうなっているの」と話しかけて作業を中断させることが頻繁にありました。そのような中断を避けるため、テンプレートには、後から来た人がリアルタイムで知りたいであろう情報（現在のステータス、役割分担、障害発生時刻、影響範囲など）の入力欄があらかじめ用意されています。
インシデント指揮者をすべての情報のハブとするため、ここに情報を記入するのは基本的にはインシデント指揮者です。しかし、他の人が、インシデント指揮者に情報を伝えるためのメモ欄として使うことも許可しています。特に、障害の根本原因がすぐにわからない場合には、そのような情報伝達（文字だけでなく、URLや画面のスクリーンショットなど）が重要になるでしょう。
対応記録欄の前半
対応記録欄の後半は、インシデント対応が完了したあとに、簡単なふりかえりを行うための記入欄です。ヌーラボの場合は、インシデント対応の最終的な記録をBacklog上に作成しているため、この欄を使う場合も使わない場合もあります。
対応記録欄の後半
以上がインシデント対応チェックリストの簡単な説明になります。
インシデント対応チェックリストの導入プロセス
インシデント指揮者の動き方を簡略化したとはいえ、チェックリストの導入にあたっては開発チームへの教育が必要不可欠でした。また、その導入中に気づいたことですが、コミュニケーションリードを担当してもらうサポートチームへの教育も同じかまたはそれ以上に重要でした。
このチェックリストの素案を作成したのは今年の6月上旬で、まずSRE課の課長とサービス開発部の部長に提案しました。以前から議論していたテーマだったこともあり、導入はスムーズに決定されました。6月中に発生した障害で1回試用し、7月上旬に開発チームへの説明会およびサポートチームへの説明会を実施しました。説明会に参加できなかった方には、各チームリーダーからの説明を依頼しました。
この説明会の目的は「このテンプレートを用意した意図と、想定する使い方について説明すること」と「打合せで出た意見をもとに、その場でテンプレートを改善すること」の2点でした。その結果を元に、テンプレートやチャットボットの改善を行ったのち、7月上旬から運用を開始しました。
インシデント対応チェックリストの導入結果
このチェックリストの導入から約5ヶ月が経過した現在も、問題なく運用できています。
最初は私がチェックリストを作成し、インシデント指揮者になるケースもありましたが、7月下旬に初めて開発者がインシデント指揮者になるケースが発生しました。最初のうちは私もインシデント対応に同席し、チェックリストを問題なく運用できているかどうかを確認していました。しかし、現在は運用が軌道に乗り、私が同席する必要もなくなっています。
インシデント指揮者を経験した開発者はまだ少ないですが、例えば以下のような感想をいただきました。
開発者から感想をもらった際のチャットログ
自分でチェックリストを使ってみた感想としては、これはインシデント対応に慣れているSREが使っても便利なものでした。特に、口頭での割り込みを減らす効果が大きいと感じました。その一方、小規模な障害ではチェックリストを作っても結局使わないことがありました。障害が発生した段階では影響範囲がわからないことも多いため、試しにチェックリストを作って、使わなかったら捨てればいい、と気楽に考えるのがよさそうです。
また、今回ある程度の効果が見られたことで、他のプロダクトでも同様のチェックリストの導入が進みつつあります。すでに、ヌーラボアカウント（ヌーラボが提供するサービスのアカウント管理機能）の運用にも、このチェックリストが採用されました。
このチェックリストが必要になる障害はまだ数件しか発生していないため、運用経験を重ねて、開発チームの意見を聞きながら、今後さらに改善していきたいと考えています。
まとめ
Backlogの運用現場では、約2年前に、アプリケーションに関するインシデント対応のマニュアルや監視システムを整備し、開発チーム自身がオンコール対応をできるようになりました。しかし、それだけでは開発者にインシデント指揮者を担当してもらうのは難しいという課題が残っていました。
今回、インシデント指揮者が取るべきタスクをチェックリストとして簡略化し、かつそのチェックリストを情報共有のためのホワイトボードとしても使うことを目的として、「インシデント対応チェックリスト」というものを新たに考案・導入しました。
このチェックリストの導入を進めるなかで、開発チームへの配慮はもちろんのこと、コミュニケーションリードにあたる部署（サポートチーム）への配慮も同じく重要なことがわかりました。
チェックリストの導入後は、SREがインシデント指揮者を担当せず、開発チームとサポートチームでインシデント対応できるケースが増えてきています。また、その効果を見て、Backlog以外のプロダクトへの導入も進みつつあります。
今回のブログ記事が、開発者とSREの間の責任分界点について考える際のきっかけになれば幸いです。
※ このブログはヌーラバーブログリレー2021 2日目の記事です。明日は竹内さんの記事です。お楽しみに！
