今日から始めるインシデントタスクフォースの作り方
タスクフォースって言ったかっただけ…じゃなーい！！！
まえがき
長くなりそうなので、まずはまえがきから。
書こうと思ったきっかけ的なところは、マネージメントしているチームでちょくちょくインシデントが起きていて、まぁそれ自体は別に良いこと（ただし事業的にヤバめなのはよくない）なんですが、いざそのインシデントが起きたときに俗に言うジュニア/ミドル層のインシデント時の対応があんまりよろしくない、というより改善の余地があるので、一例としてこんな感じで進めると良いよ～的なことを書いてみようかなと。
で、別に社内だけに展開する必要もないので個人ブログにおいて公開しようと思います。
ジュニア/ミドル層というよりは、「インシデント時の対応に慣れていない人たち」というのが正しいかもしれませんが便宜上こう書いています。
あくまで一例なのでコレが正解というわけではないし、それぞれの組織・チームによって調整が必要なところもあると思いますが、参考になれば幸いです。
あと、これはエンジニアに限らず様々な職種にも当てはまる内容になっています。
インシデントタスクフォースを作る前に
インシデント発生者は攻めるな
インシデントタスクフォースがなんたらかんたらって言う前に大事なこと。
一番の肝ですが、「インシデントは誰が何をしても起きるもの」です。
たとえ歴戦の猛者でも、CTOでも、CEOだろうが起きるものは起きるものです。
そしてインシデント発生者を攻めたところで何も解決しません。それで解決するなら人格失うまで攻めまくりますが、なーんにも解決しませんし、むしろインシデントの要因が見えにくくなる悪手以外の何物でもないです。
大事なのはインシデント発生後に適切にそして素早く対応、その後要因を調査・分析し二度と同じことが起きないようにすることです。
自分ごととして捉える
「あーなんかサーバー落ちてるけど詳しい○○さん対応してるしいいか」とかは止めましょう。
個人的な主観でアレですが、インシデントはエンジニアとして一番の真価が発揮され、成長機会となります。
他人事ではなく、自分ごととして捉えて対応しましょう。
「でも自分よくわからん…」でもいいです。
後述しますがインシデントの際の野次馬は大歓迎です。
インシデント対応は経験が物を言います。いくら座学で勉強したところで(全くの無駄とはいいませんが)、実践に勝るものはありません。
なぜ難しいのか。まず一つはインシデント対応の最優先事項である「迅速に正常の状態に戻す」という関係上"できる人"だけでオペレーションを行ってしまうこと。
もう一つは総じてインシデントはケースバイケースが多すぎるため体系的に言語化するのが難しいということです。
以上からインシデント対応を最も効率的にかつ効果的に学ぶ方法は自ら参加することです。
そしてインシデントというのはいつ起きるかわからないものです。分かっている場合は大抵対応策を事前に講じているので簡単ですね。
その時に組織のインシデント対応が得意な人がいなかったら？自分しか対応できる人がいなかったら？
何もしないで他人を待っていますか？事業として致命的な場合でも？ユーザーが困っていても？
静観も一つの手でしょう。それは否定しません。
下手に関わると責任を負わされる組織もあるでしょう。
ですが、自己を成長させたい/自分が関わるプロダクトに責任を持ちたい/ユーザーが困っているなら助けたい、僕はそういう人と働きたいと思います。
そういう人のためのドキュメントです。
インシデントタスクフォースとは
インシデントタスクフォースとは、"インシデント発生時に適切な対応を行うために組織されるチーム"のことです。
と言うだけなら簡単です。
では実際にどういう組織編成が良いのかというと、理想論としては以下になります。
- 司令官(コマンダー)
- 一人
- 役割: ステークホルダーとの調整/インシデントの状況把握/インシデントの終了判断
- 人選: "インシデント"に対する知識・経験が豊富な人/ステークホルダーとの調整ができる人
- 作業者(オペレーター)
- 一人
- 役割: 画面共有で作業を表示する/インシデントに対して書き込み権限のあるオペレーティングを行う/観測者が上げてきた情報を共有画面に表示する
- 人選: インシデント発生者とは別の人/画面共有で作業を表示するのが得意な人(得意ってなんぞ？)
- 観測者(オブザーバー)
- 複数人
- 役割: インシデントに関するログ・メトリクス・トレースなどの情報を集める/作業者に情報を共有する
- 人選: だれでも(できればインシデントに関するシステムに対して知見があると良い)
- 記録者(ライター)
- おまかせ
- 役割: インシデントに関する情報を記録する/インシデントの終了後にポストモーテムのタイムラインを作成する
- 人選: だれでも
- 野次馬
- 上記以外の人
- 役割: 作業を眺める"だけ"
- 人選: だれでも
これだけ書いてもわからないと思うのでそれぞれの役割について説明します。
司令官(コマンダー)
コマンダーはインシデントの司令塔です。（それはそう
一言でいうと俗に言う"ボール"を持っている人です。
一番大事なのはチーム外から進捗だったり影響範囲をステークホルダーに適切に伝え、インシデントタスクフォースを外部から守ることです。
ここで言う"守る"というのは、「インシデントタスクフォースが復旧オペレーティングに集中できる状況を作る」ということであって、外部が"敵"という意味ではありません。
むしろインシデントタスクフォースの外部の人間をどれだけ味方につけて、復旧オペレーティング遂行にプラスの影響を与えるかがコマンダーの手腕にかかっています。
それ故、人選の際に各ステークホルダーと調整が最も上手な人が最適となります。（大抵の場合役職付きになることが多い
そしてコマンダーは"インシデント"に対して最も冷静かつ俯瞰的に判断を下せる人間である必要があります。
基本的に相当な場数を踏まない限り人はインシデント発生時に冷静ではいられません。パニックになって興奮状態になったり、自責の念でものすごくネガティブな影響を受けます。
ですので、コマンダーはその場にいる人間の中で一定インシデントに対して経験を詰んだ人間が適切となります。
最初の方に"ボール"を持っている人という表現をしたのが、最終的に何を持って復旧オペレーティングが完了となるか最終的に決める必要があるからです。
サービスが接続できるようになった・データの整合性が取れるようになった・レスポンスタイムが回復したなどなど、復旧オペレーティングの完了基準は様々です。
インシデント関係者が復旧オペレーティングが完了したと思っても、コマンダーが完了と判断しない限りは完了とはなりません。
なぜなら、復旧オペレーティングが完了したと思っても、その後に"何かしら"の影響が出る可能性があるからです。
例えば「サービスが接続できなかった」というインシデントが発生して、「サービスが接続できるようになった」という状態にしたら完了と思われがちですが、それに付随してlogの欠損・課金ステータスの更新・ユーザーへのお知らせ等など当事者の意識外の作業が山ほどあります。
それ故実際のオペーレーター以外のコマンダーという立場でインシデントを眺めることによりそういった意識外の作業を見落とさず、各種ステークホルダーとの調整を行いながら復旧オペレーティングを完了させる必要があります。
作業者(オペレーター)
作業者はインシデントの復旧オペレーティングを行う人です（それはｓ
まずオペレーターの人選ですが、インシデント発生者とは別の人が望ましいです。
インシデント発生者は先程もあげたとおり、心情が穏やかではありません。復旧オペレーティング中に思わぬミスをしてしまい、インシデントにインシデントを重ねることが往々にしてあります。（経験談
逆にインシデント自体にある程度経験がある人がインシデント発生者の場合は、そのままオペレーターをやった方が良いかと思います。
実際にインシデントを起こした人が原因を一番知っているので復旧自体としてはオペレーターとしては最適です。
が、さっきも記述した通り、インシデント発生者は基本的には心情が穏やかではないので、場馴れした人ならある程度はコントロールできるのでダイジョブかと。
それでもコマンダーの指示には従いましょうね^^
具体的に何をやる人かというと、画面共有を行い破壊的なオペレーションを行う人です。
破壊的という言葉が穏やかではないのであれば、書き込み権限を必要とするオペレーションと表現しても良いです。言葉遊びですが。
人数を"一人"としているのは、破壊的作業を複数人で作業するとその破壊的変更によるさらなるインシデントが発生した場合誰の変更が影響したのかが特定しにくくなる可能性があるからです。
一見直列的作業が効率が悪く感じるとは思いますが、インシデントがインシデントを呼ぶのはよくあること。それを防ぐ/特定しやすくするという面で一人で作業したほうが最終的に良くなるパターンが多いです。
観測者(オブザーバー)
観測者はインシデントに関する情報を集めたりする人です(そｒ
ログやメトリクスを集めて、インシデントに関する情報をオペレーターやコマンダーに伝える人です。
大事なことは収集した"事実"を伝えることです。「これがこういう風だからこうなっている」という"憶測"ではなく、"事実"を伝えることが大事です。
例えば「"ログが出力されていない"から"アプリケーションがリクエストを受け取っていない"」というのは"事実"ではなく"憶測"です。実際はfluentdが落ちていたり、ログの出力自体に問題がある可能性があります。
オブザーバーは事実をオペレーターに伝え、オペレーターが事実を画面で共有しながら確認が理想的です。
記録者(ライター)
記録者はインシデントに関する情報を記録する人です。(s
優先度は一番低いです。
人選はできれば最後までちゃんと立ち会える人 、最後まで無理でも引き継げば別に大丈夫です。
やることは簡単で、”いつ”、”誰が”、”何を”、を記録しましょう。
フォーマットとかはてきとーでとりあえず残って良いです。
その場で暫定対応して後日根本原因の調査や再発防止、インシデントレポート・ポストモーテムを作成すると時に役に立ちます。
野次馬
野次馬は野次馬です。(
最初に書きましたが、わからなくてもとりあえずインシデントに対しては関わっていきましょう。見てるだけでも十二分です。
わからない単語が出たらググって、それでもわからないことがあったらインシデント完了後などに知見がある人に聞いてみましょう。
インシデントのススメ方
インシデントは事前準備が大事
「インシデントが起きた！さぁどうすればいい！？」とかではなく、事前に準備をしておきましょう。
インシデント対応の初動や、リカバリーの質は事前準備が半分以上を占めていると言っても過言ではないと思います。
まず、会社・組織としてインシデントフローが決まっている場合は頭に叩き込みましょう。
上長に連絡、カスタマーサクセスチームに一報、インシデントチャンネルに報告などなど。
そもそものインシデントフローが決まっていない場合は早急に決めましょう。もしあなたがそれらのインシデントフローを決定・企画できない立場であるなら上長なりに提案をしてみましょう。もし、それらが受け入れられない、話を聞いてもらえない場合は、インシデントが起きて痛い目をあってもらいましょう。時に人は傷を負わないと学べないことがあります。
この記事で記述しているのはあくまで現場レベルのインシデント対応の話であって、会社・組織としてのインシデント対応の話ではないことは留意してください。
ちなみにこのブログをまとめたあとに社内用にドキュメント作成して一定ルール化する予定です。
インシデントが起きたら
まずやることはインシデントである宣言をしましょう。
これはどの組織でもあるあるだと思うんですが、アラートチャンネルみたいなところに色々流れるものの流れすぎていて、オオカミ少年状態になっているとそのアラートがインシデントなのかどうかすら属人化しているというパターン。
それゆえインシデントであるという宣言は意外と大事だったりします。
次に関係者に一報を入れましょう。関係者の範囲はざっくりで良いです。狭いよりかはやや広めに一報入れるとことがポイントです。
関係なかったら後で「ごめんなさい関係ありませんでした」ですみますが、関係あるのに一報入れなかったらごめんなさいでどうにかならない時もあります。
インシデントタスクフォースの結成
＼まってました！／
インシデントタスクフォースの結成です。
タイミング的に上記の一報の前後どちらもで良いと思います。
初動では人数が揃わないことがよくあるので最低限「コマンダー」「オペレーター」は決めておきましょう。
まぁ自分しか反応しなくて一人で全部の役割するってことはあったりします。特に深夜。がんばれ。
あとはまぁケースバイケースでがんばりましょう（適当
インシデント後
インシデントが終わったら、会社・組織のフローとしてインシデントレポートの作成があると思いますのでそちらを作成しましょう
そして再度同じことを繰り返さないため、失敗から学びを得るため、何より他のメンバーやチームに共有するためにポストモーテムを作成しましょう。
ポストモーテムとはなんぞやみたいな話はSRE本やネットでそれぞれのSREチームが書いてある記事を参考にしてください。
O'Reilly Japan - SRE サイトリライアビリティエンジニアリング
Google - Site Reliability Engineering
初めてのポストモーテム - Platinum Data Blog by BrainPad
まとめ
インシデント対応が難しい理由に「冷静さ」「心理的負荷」があると思います。
この2点に関して個人的に「経験を積む」という根性論もどきが一番効果があるかなと思います。
ここでいう経験は別に直接オペレーターとして手を動かすというわけではなくその場に居合わせるだけでも十二分に効果があると思います。
最初の方に書いた野次馬歓迎というのはそういう意味でもあります。
恐れず、だが慎重にインシデント対応をしていき、自己の成長にも利用していきましょう。