本番障害はチームにとって最悪だ。突如としてあなたの携帯が鳴り出す。システムダッシュボードはレッドシグナルでいっぱいになる。ツイッターのタイムラインにはお客様の不満で溢れかえっている。事業責任者がチームの背後に陣取って、いまかいまかとレポートを要求してくる。あなたの幸せな金曜日はすでにむちゃくちゃにされてしまった。
注目！指揮官が陣頭指揮を取ります！
チームには問題を特定して行動するための効果的なアプローチが必要だ。戦闘指揮官は古典的だがとても有効な手段である。シニアエンジニアが障害対応を全体指揮する。これは有効な手段である。なぜなら本番障害は多くのケースで「直感」を必要とするからだ。あなたはきっとたくさんの混乱したレポートを受け取るだろう。「CPU が張り付いたままだ」「外部ネットワークから異常なアクセスがあるぞ」「ネットワークを使いすぎている。これが原因にちがいないぞ」あなたはこれらのレポートの中から、何が原因で、何が事象に過ぎないのかを見分けなければならない。こうした目利きは教科書からは学ぶことはできない。実践から学ぶしかないのだ。それ故に経験豊富な戦闘指揮官は本番障害に対して有効な手段たりえるのである。 戦闘指揮官はコミュニケーションの観点でも有効である。一つの統合されたレポートラインは障害対応を一貫性のあるものにする。レポートラインの集約も、マネジメントにとってありがたいものだ。エンジニアリングチームの中に混乱して見当違いのアクションを取る者もいなくなる。
協調障害対応
一方、もう一つの障害対応パラダイムとして、協調障害対応がある。一度本番障害が発生すると、第一報は Slack チャンネルに透過される。Slack チャンネルやオンライン会議室に次から次へとエンジニアが飛び込んで対応を始める。チームは何が起こっていて何が原因なのか議論を始める。それぞれ各自で自分の仮説を立て、指示を待つことなく分析をはじめる。事前にだれが指揮を取るなどという取り決めはない。人々は自然とそれぞれの領域でリーダーシップを発揮する。全ての対応が並行して進む中、レポートは一箇所に纏められる。今日の IT コラボレーションツールがあるからこそ機能する方法である。 協調障害対応は組織的にも、より「耐障害性」のあるアプローチである。単一障害点がないのだ。チームは戦闘指揮官が不在でも行動することができる。戦闘指揮官が一時的に現場から離れることも可能だ。来客があったり、採用面談などどうしても外せない用事があろうと問題ない。 協調障害対応は自然のリーダーシップを育む。全員が全体状況を観察し、アクションを決める。全員がそれぞれの仮説を立て、分析を独自に進める。ときに他の人の助けを借りたり、修正作業に巻き込んだりする。これはすべての人材に実際の障害を通じて実践的な経験を得る機会を与える。 協調障害対応は、不確定要素の多いデジタルワールドにおいて理想的な手段だ。コンピューターシステムは過去に比べてずっと巨大で複雑になった。これは、 Davit Epstein 博士の言う「意地悪な学習環境」にあたる。知識の幅こそが問題解決の鍵だ。協調障害対応はより多くの人間を分析に巻き込むことに寄って、より多くの視点をもたらす。ときにはビギナーズラックが決め手になることだってある。我々は多様な視点を活かして複雑な問題を解決するべきなのである。
協調障害対応を成し遂げるために必要なもの
協調障害対応をなしとげるためのいくつかの鍵をこちらで紹介しよう。
ライブドキュメント
ライブドキュメントは最も重要であるというのが自分の意見だ。協調型ドキュメンテーションツールの進化のおかげで、いまでは多人数で文章を書くのがずっと簡単になった。最近の製品では、リアルタイムに協調して文章を書くことすら可能なものも多い。これは複数人で並行して情報をまとめるのに最適だ。
ライブドキュメントは錯綜するレポートを理解するのに役立つ。5 つの議論が並行している状況を想像してみてほしい。あなたはそれらのどの議論も理解できないだろう。しかし、ライブドキュメントで情報が纏められていればそれも可能になる。あなたはそれぞれのトピックについて一つずつ意識を集中して順番に理解していける。現在進行している議論を遮って他の議論をする必要もない。
手順
作業手順を確立しておくことも協調作業をなすために重要だ。手順には以下のような事項が含まれる。
- コミュニケーションチャネル
- レポートフォーマット
- 意思決定プロセス
コミュニケーションチャネルを障害発生前に決めておくことは大事だ。さもなくば、各々勝手にスレッドを立て始めることだろう。これは障害対応情報を散らばらせることになりかねない。複数の DM にそれぞれレポートをするなんて言うのは最悪だ。我々は複数の DM チャンネルを行ったり来たりしている暇などない。障害対応のために時間を使わなければならないのだ！ ライブドキュメントのフォーマットを決めておくことも大事だ。フォーマットはライブドキュメントに分かりやすい構造を作り出す。 意思決定プロセスは、特段の断りなしに実行してよいアクションと、そうでないアクションを明確にする。分析はだれがどうやろうと自由である。しかしながら、本番システムの変更は注意深く決定されなければならない。場合によっては経験のあるエンジニアが決定を下すべきものもあるだろう。 場合によっては事業責任者の承認が必要となるようなものもある (サイトの一時完全停止など)。
コーディネーター
コーディネーターは協調障害対応を効率的に実施するための役割である。コーディネーターは指揮官ではない。コーディネーターは同僚が正しい手順に従うよう促す。コーディネータは、アクションアイテムを指示する代わりに、それぞれのアクションを誰が担当しているのかを明確にする。追加で必要なアクションがあれば、誰かにアクションを取ってもらうよう頼む。この方法によって、全員がそれぞれの領域でのリーダーシップを発揮することができ、かつ全体として一貫性の取れた行動を可能にする。 コーディネーターはライブドキュメントの「編集者」である。コーディネーターは全体のフォーマットを整え、不足する情報を書き足し、人々に足りない情報を文章化するよう促す。コーディネーターはすべての情報を文章に落とし込むようにするべきである。そうすることに寄って全員が全体状況を把握できるようにある。そして、障害対応が長引いた場合などに要員交代も可能になる。
みんなで協力して終わりにしよう
協調障害対応は不確定要素の多い今日の本番障害における効果的なアプローチだ。人々が同時にかつ一貫性のある方法で仕事を成し遂げることができる。協調障害対応は特定のシニアエンジニアへの依存を避け、全員に経験から障害対応の学びを得る機会をもたらすだろう。
原文:
