Incident Response

はじめに#

001. "インシデント対応トレーニング"

こんにちは、私はRichです。「インシデント対応トレーニング」へようこそ。これはPagerDutyの社内トレーニングの短縮版で、新任のインシデントコマンダーの育成に使用しているものです。より広い対象向けに若干アレンジしていますが、大部分は私たちが実際に実施しているものと全く同じです。すべてを網羅することはできません（そうすると数日かかってしまいます）が、プロセスの最も重要な部分をいくつか取り上げます。できるだけ簡潔に進めていきたいと思います。

ちなみに今回、どのくらい時間をかけていいですか？誰か時間を管理してくれませんか？はい、そうしてもらえると助かります、ありがとうございます！

インシデントを効果的に管理する方法を学ぶ#

002. インシデントを効果的に管理する方法を学ぶ。

このセッションの目的は、組織内でインシデントを効果的に管理する方法を理解していただくことです。PagerDutyで重大なインシデントを管理するために使用しているプロセスについて説明し、「インシデントコマンダー」と呼ばれる特定の役割について詳しく説明します。

これは営業のプレゼンではありません。私は営業チームの者ではありませんし、これはPagerDutyを使ってインシデントを管理する方法についての説明でもありません（もちろん、使っていただけたら素晴らしいですが）。今日の目的は、PagerDutyでどのように社内のインシデントを管理しているかを紹介し、独自のインシデント対応プロセスを開始または改善するために、皆さんの組織に持ち帰ることができる実践的な情報を多く提供することです。

混乱を冷静さに変える。#

003. 混乱を冷静さに変える。

簡単な質問から始めましょう。現在、あなたの組織でのインシデント対応はどのように行われていますか？スムーズで効率的なプロセスですか、それとも多くの人が互いの話を遮り合っているような状況ですか？ほとんどの方にとって、おそらくその中間くらいでしょう。

私たちは後者を減らし、前者を増やしたいと考えています。混乱とパニックをなくし、冷静さに変えていきたいのです。パニックと混乱はインシデント時に良いものではありません。それらは事態を悪化させ、さらなる混乱を引き起こすだけです。私たちは物事を冷静に、そして組織的に進めたいと考えています。

インシデント対応とは何か？#

004. インシデント対応とは何か？ ドキュメント参照

では、インシデント対応について話すとき、私たちが本当に言及しているのは、インシデントに対処し管理するための組織的なアプローチです。これがPagerDutyでのインシデント対応の定義です。ここでのポイントは「組織的」という言葉にあります。アラートが鳴るたびにパニックに陥って走り回りたくはないでしょう。対応がほぼ日常的なものとなり、全員が油の乗った機械のように協力して働くことを望んでいます。

Incident Management for Operationsという素晴らしい本からの引用で、ここにぴったりの言葉を紹介しましょう：

消防署にとって火事は緊急事態ではない...あなたは、自分が抱えている問題を解決することに熟練したプロフェッショナル集団からの迅速な対応を期待している。

インシデント対応の目的#

005. インシデント対応の目的。ドキュメント参照

インシデント対応の目的が単に問題を解決することではないと知って驚くかもしれません。千匹の猿にキーボードを与えて十分な時間を与えれば、おそらく問題を解決できるでしょう。しかし、それは良いインシデント対応とは言えません。私たちは、被害を抑え、復旧時間とコストを削減する方法で問題を解決したいと考えています。ここでいうコストは単に金銭的なコストだけではありません。エンジニアの健康にも関わるコストがあります。常に深夜3時に人々を起こすことは、彼らの健康と幸福に大きな悪影響を及ぼす可能性があります。

もし金銭的な影響だけを気にするのであれば、人は高価であるということを忘れないでください。大規模な組織では、100人が数時間ほとんど何もせずに電話会議に参加しているということは珍しくありません。それぞれの人が時給約100ドルだとすると、それは1時間あたり1万ドルです！それは企業にとって本当に高価なものです。

インシデントとは何か？#

006. インシデントとは何か？ ドキュメント参照

しかし、インシデントに対応する前に、インシデントが実際に何であるかを定義する必要があります。馬鹿げているように聞こえるかもしれませんが、何かがインシデントかどうかわからなければ、それに対応すべきかどうかもわかりません。

これがPagerDutyのインシデントの定義です：

顧客のプロダクト利用に現在進行形の影響を与えている、計画外のサービスの中断または劣化。

ここでいう「顧客」は外部の顧客だけでなく、内部の顧客も指す場合があります。

あなたの定義は異なるかもしれませんし、それは問題ありません。私はただ、あなたが始めるのに役立つような定義の例を示したかっただけです。定義は簡単で、1文以内で、誰にでも理解できるものであるべきです。

このインシデントの定義がかなり広範であることにお気づきかもしれません。タイプミスでもこの説明に当てはまります。完全な停止状態もそうです。明らかにこれらは非常に異なるシナリオです。そのため、私たちには他のものもあります。

重大インシデントとは何か？#

007. 重大インシデントとは何か？ ドキュメント参照

私たちは重大インシデントと呼ぶものも定義しています。これは、チーム間の協調的な対応が必要なインシデントのことです。繰り返しになりますが、これはPagerDutyでの定義であり、あなた独自の定義を使用してください。

この定義の意図は、時にはインシデントが単一のチーム、おそらく問題を抱えているサービスの所有者によって処理できるということです。それ自体では大規模な対応を必要としません。しかし、カスタマーサポートやデータベース管理者など、他のチームを巻き込む必要が出てきた時点で、私たちはそれを重大インシデントと宣言し、より大規模な対応を開始します。ここでの鍵は協調であり、これについては後ほど詳しく説明します。

しかし、これでもまだ、かなり広範な潜在的なインシデントをカバーしています。もっと細かく分類することができます。

重大度レベル#

008. 重大度レベル。ドキュメント参照

私たちは重大度レベルを使用して、インシデントの深刻さとそれに対する対応の種類を決定します。私たちはSEV-5からSEV-1までのレベルを使用していますが、あなたは異なる方式を使用するかもしれません。P0からP5まで、あるいは絵文字を使って🔥から💩までなど。

ウェブサイトへのトラフィックのグラフを見ているとしましょう。通常、メトリクスがどの程度劇的に影響を受けているかによって重大度を判断できます。つまり、ウェブサイトのトラフィックが低下するにつれて、重大度が上がっていきます。

通常、事前に定義された目標や基準点に達すると、その時点で自動的に重大インシデントとみなされます。PagerDutyでは、それはSEV-3とSEV-2の違いですが、あなたの組織では異なる場合があります。そして、事態がさらに深刻になると、SEV-2や完全に停止状態となるSEV-1に入ります。

事前に定義された閾値とメトリクスがあれば、対応プロセスの自動トリガーを設定することができます。

誰でもインシデント対応を開始できる#

009. 誰でもいつでもインシデント対応を開始できる。

しかし、時には影響の大きさをすぐには把握できないことがあります。あるいは、メトリクスが事前に定義された閾値にまだ達していないかもしれません。それでも、人間が介入して重大インシデントを宣言する方法が必要です。

そのため、PagerDutyでは自動化の仕組みがありますが、誰でもいつでも重大インシデント対応プロセスを開始できる仕組みも用意しています。これは私たちにとって非常に重要です。インシデント対応を開始する障壁を下げることで、インシデントが解決されるスピードが劇的に向上することがわかりました。

公式のアラームがまだ鳴っていないからといって、人々が問題を抱えたまま座っているのは望ましくありません。カスタマーサポートに短時間で多くの問い合わせが来た場合、それは何か問題が起きている十分な兆候であり、彼らがアラームを鳴らす必要があります。入社1週目のインターンでさえ、インシデント対応プロセスを開始したことがあります。清掃員がグラフを見て何か変だと思ったら、インシデント対応を開始できるようにしたいのです。

当初、これを導入することに躊躇しました。過剰な注意から多くの誤報が発生することを恐れたためです。しかし、実際にはまったく逆の結果となり、人々は自主的にこれをうまく管理しています。誤報は2回だけでしたが、その時点で入手可能な情報に基づけば、どちらも妥当な判断でした。たとえ時々誤報があったとしても、それを無料の訓練として活用することができます。

チャットを通じたインシデントの開始#

010. チャットを通じたインシデントの開始。ドキュメント参照

では、どのように人間がプロセスを開始できるようにしているのでしょうか？私たちはチャットコマンドを使用していますが、これが唯一の正しい方法だと考える必要はありません。単なる一例として、私たちの方法をお見せしたいと思います。あなたの好きな方法で実装できます。エアホーン、オフィスの点滅ライト、マリアッチバンドを雇うなど、何でも構いません。

重要なのは、誰もが利用できる、迅速で簡単な方法でインシデント対応を開始できるようにすることです。

平時 vs 戦時#

011. 平時 vs 戦時。ドキュメント参照

インシデントが開始されたら、私たちは思考モードを切り替える必要があります。メンタリティの転換が必要です。「通常運用」と「インシデント進行中」を区別したいのです。意思決定を平時から戦時へと切り替える必要があります。日常業務から、ビジネスを守る体制へと移行するのです。

通常運用時には完全に受け入れられないこと、例えばテストを一切実行せずにコードをデプロイすることが、重大インシデント時にはサービスを迅速に復旧するために完全に許容される場合があります。

運用方法、役割の階層、そしてリスクを取る程度は、この転換に伴ってすべて変化します。

通常時 vs 緊急時#

012. 通常時 vs 緊急時。ドキュメント参照

平時/戦時という例えが好ましくない人もいるでしょうから、好きな呼び方を使ってください。通常時/緊急時など。

OK vs Not OK#

013. OK vs Not OK。ドキュメント参照

あるいはOK/NOT OKでも構いません。何と呼ぶかは、メンタルシフトができることほど重要ではありません。

インシデントコマンドシステム#

014. インシデントコマンドシステム（ICS）。ドキュメント参照

では、私たちのプロセスについてもう少し詳しく説明しましょう。PagerDutyでのインシデント対応の方法は、私たちが独自に発明したものではありません。インシデントコマンドシステム（通常ICSと略される）に大きく基づいています。

ICSは1970年に南カリフォルニアで発生した壊滅的な山火事の後に開発されました。数千人の消防士が対応にあたりましたが、協力して活動することが困難でした。個々の消防活動は知っていても、より大きな集団として効果的に活動するための共通のフレームワークが欠けていたのです。

火災の後、FIRESCOPE（信じられないかもしれませんが、"FIrefighting REsources of Southern California Organized for Potential Emergencies"の頭字語です）と呼ばれる機関間グループが結成され、山火事を管理するための2つのシステムを開発することになりました。そのシステムの1つがICSとして知られるようになり、最終的にはあらゆる重大インシデントの指揮構造のための全国的なモデルとなりました。

2004年には、国家インシデント管理システム（NIMS）がFEMAによって確立され、現在では米国のすべての公的機関が緊急事態管理の標準として使用しています。NIMSはその一部として複数の運用システムを定義しており、ICSはそのうちの1つです。

地域の消防署が家屋火災に対応する場合から、米国政府が自然災害に対応する場合まで、あらゆる場面で使用されています。誰もが精通している標準化された対応フレームワークを提供します。

NIMSとICSは、PagerDutyで使用しているプロセスの基礎となっていますが、私たちのニーズに合わせて大幅に修正しています。人命が危機に瀕していない場合、物事をかなり合理化できることがわかったのです。

世界中のインシデント対応#

015. 世界中のインシデント対応。ドキュメント参照

私たちのプロセスが米国のシステムであるNIMSとICSに基づいているとはいえ、世界中で多くの類似システムが使用されていることは注目に値します。多くはICSに基づいていますが、中には独自に開発されたものもあり、それでも多くの同様の機能を提供しています。

私は特に英国のシステムが好きです。単純に「ゴールドコマンダー」という役割があるからです。まるでジェームス・ボンドの悪役のような名前ですよね。

PagerDutyでプロセスを開発する際、世界中で使用されている他のシステムもいくつか調べ、最も気に入った部分を選んで自分たちのものに加えました。

役割#

016. インシデント対応の役割。

では、私たちのプロセスに関わる役割について説明しましょう。役割を1つずつ紹介していきますが、最後のスライドに表示される役割の数に驚かないでください。私たちは最初からこれほど多くの役割から始めたわけではありませんし、あらゆるインシデントですべての役割を埋める必要もありません。これは利用可能な役割を示し、それらを定義しているだけです。プロセスと役割は、対象となるインシデントの規模に応じて拡大・縮小します。

ICSと全く同じ役割を使用しているわけではありませんが、私たちに必要な役割を選び出して、独自の役割構造を作り上げました。

• まず最初はインシデントコマンダー（Incident Commander）、通常ICと略されます。彼らが責任者であり、プロセスで最も重要な役割です。すべての決定を下し、すべての情報が彼らに集まります。彼らの言うことが絶対です。この役割については後ほど詳しく説明しますので、今は他の役割の説明を続けましょう。

• 次は副指揮官（Deputy）です。これは基本的にバックアップのインシデントコマンダーです。インシデントコマンダーとしてトレーニングを受けており、同じ情報をすべて聞いています。インシデントコマンダーが見落としがないよう支援し、インシデントコマンダーが指揮を交代したい場合のホットスワップスタンバイとして機能します。これは始めたばかりの時には必要ない役割の1つです。長い間、私たちの副指揮官と書記官は同じ人物でした。

• 次に書記官（Scribe）です。書記官の仕事は、出来事の正確な時系列を記録することです。何が起こったか、いつ起こったか、そして重要な決定が何だったかを記録します。私たちはSlackを使用しており、書記官はSlackルームにメモを書き込みます。これにより、きちんとタイムスタンプの付いたデータが得られます。重要なのは、これは音声会議の直接的な書き起こしではないということです。「ジョンがこう言った、メアリーがこう言った」ではありません。むしろ「AとBの間で決定を下し、Aを選択した」といった感じです。

これらの役割を合わせてコマンドスタッフと呼びます。

• 次はカスタマーリエゾン（Customer Liaison）です。これは私たちのサポートチームのメンバーで、顧客との双方向のやり取りを担当します。メール、ツイート、またはステータスページの更新を通じて、何が起きているかを顧客に知らせます。また、顧客が何を言っているかも私たちに知らせます。数百件のサポートリクエストが来ているのか、それとも誰も問い合わせを上げていないのか。これは原因の追跡や、復旧時にどの程度のリスクを取れるかを判断する上で有用な情報となるからです。

• インターナルリエゾン（Internal Liaison）は、私たちのプロセスでは比較的新しい役割です。彼らの仕事は、経営陣やマーケティングチームなど、社内チームとのやり取りをすべて処理することです。インシデントのアップデート用に別のSlackチャンネルがあり、インターナルリエゾンはそこに定期的な状況アップデートを投稿し、組織の他のメンバーからの質問に答えます。これにより、それらの質問を主要な対応から切り離しつつ、人々は引き続き回答を得ることができます。インターナルリエゾンは、必要に応じて他のチームを呼び出すこともします。これも、ほとんどの企業では必要のない役割です。長い間、これも副指揮官/書記官の役割が担当していました。

これらはリエゾン（連絡担当者）と呼ばれます。

• 最後に、SME（Subject Matter Expert / 対象分野の専門家）がいます。これらは実際に問題を解決する人々です。サーバーにログインし、コードを変更し、コマンドを実行する人々です。

今日は、特に1つの役割、インシデントコマンダーの役割に焦点を当てて説明します。

インシデントコマンダー#

017. インシデントコマンダー。ドキュメント参照

インシデントコマンダーは最も重要な役割の1つです。副指揮官、書記官、カスタマーリエゾンなどがいなくても、インシデントコマンダーは最初に確保すべき役割です（もちろん、SMEの後です。問題を解決する人が必要になる前に、対応を調整する人が必要になることはありません）。

唯一の情報源#

018. 唯一の情報源。

彼らはインシデント中の唯一の情報源であり、責任者です。大ボスです。すべての決定を下し、インシデントコマンダーが承認しない限り、いかなる行動も取られるべきではありません。

最高位の人物#

019. 最高位の人物。

日常の役割に関係なく、インシデントコマンダーは常に対応における最高位の人物となります。彼らが指揮を執ります。先ほどメンタリティの転換について話しましたが、これはインシデント中に変化する事柄の1つです。

CEOよりも上位#

020. CEOよりも上位。

CEOが対応に加わった場合でも、インシデントコマンダーはインシデント対応の状況では彼らよりも上位にあります。これは成功するインシデント対応にとって絶対に重要ですが、経営陣の理解を得る必要があります。CEOにこれを事前に説明せずに驚かせないでください。うまくいきません。

これがあなたの組織でうまくいくかどうかは、組織次第です。これはPagerDutyでの方法であり、私たちにとってはうまく機能していますが、他の組織ではこのような理解を得ることが容易ではないかもしれないことは想像できます。私は以前、航空業界で働いていましたが、このルールはそこでは通用しないでしょう（聞こえますか？航空業界。ハロー？このマイク入ってますか？）

解決者ではない#

021. 解決者ではない。

重要なのは、インシデントコマンダーはインシデントを解決するのではなく、タスクを調整し委任することです。彼らはオーケストラの指揮者であり、楽器を演奏しているわけではありません。グラフを見たり、サーバーにログインしたりする解決者としての役割は果たしません。

これは特に、インシデントコマンダーが日常業務ではエンジニアである場合に難しい場合があります。彼らは自然と助けに入りたくなるかもしれませんが、インシデントコマンダーとして行動している場合、その衝動は抑制しなければなりません。もし彼らが絶対に問題を解決できる唯一の人物である場合、別のインシデントコマンダーに指揮を引き継ぎ、代わりにSMEの役割を引き受けるべきです。このシナリオについては後ほど詳しく説明します。

BSOD#

022. あらら、まずいですね！

おっと、これは良くありませんね。何か問題が起きたのでしょうか？インシデントが発生したようです！

では、深夜に何かが壊れたときはどうすればよいのでしょうか？インシデントに対応する最初のステップは何でしょうか？

実は、インシデント対応の最初のステップは常に同じです。小さなスタートアップであろうと大企業であろうと。25セントが危機に瀕していようと、250億ドルが危機に瀕していようと。

パニックにならない#

023. パニックにならないこと

パニックにならないこと。パニックはストレスを高め、他の人々もパニックに陥らせます。結果として、インシデント対応をより一層妨げることになります。

内心パニックになるのは構いません。 結局のところ、私たちは人間です。このような状況でパニックになるのは自然な反応です。ページャーの音など、呼び出されるときのすべてのことはアドレナリンを分泌させるように設計されています。ただし、外見上パニックを見せないようにしてください。他の人々も同じようにパニックになってしまうからです。冷静に振る舞えば、他の人々もそれに倣うでしょう。

経験豊富な人々は冷静さを保ち、それが混沌としたインシデントと、スムーズに解決するインシデントの違いを生み出すことがあります。だから、落ち着いてください！

インシデントコマンダーの自己紹介#

024. "こんにちは、Richです。インシデントコマンダーを務めます"。ドキュメント参照

しかし今日は、ここにインシデントコマンダーがいます。

こんにちは、Richです。インシデントコマンダーを務めます。

すべての会議はこのように始めるべきです。まあ、私の名前ではなく自分の名前を使ってください。でも要点はわかりますよね。

この言い方には、いくつかの重要なポイントがあります。

自己紹介をする#

025. 自己紹介をする。

まず、私は名前で自己紹介しました。単に「こんにちは、インシデントコマンダーです」とは言いませんでした。私は感情のないロボットではありません。

自己紹介は、人々があなたが誰であるかを知るために重要です。通常、彼らは名前ではなく「インシデントコマンダー」としてあなたを呼ぶことになりますが、それでもあなたをより人間的に感じさせます。名前で自己紹介すると、人々はあなたを異なる方法で扱い、物事がより円滑に進むのに役立ちます。

インシデントコマンダーの仕事の多くは、技術的な専門知識よりも心理学とフレーズの選び方に関係していることがすぐにわかるでしょう。

インシデントコマンダーと言う#

026. "インシデントコマンダー"と言う。

そして、私は「インシデントコマンダー」と言いました。新しい人々がまだ専門用語を理解していない可能性があるため、インシデントコマンダーと略さなかったのです。このように言うことで、非常に明確になります。常に明確な言葉を使用したいのです。さらに、ここで「コマンダー」という言葉を使うことで、無意識のうちにあなたが責任者であることを人々に印象付けます。

良好なコミュニケーション#

027. 良好なコミュニケーションが不可欠。

良好なコミュニケーションは不可欠です。コミュニケーションの崩壊は、対応プロセス全体を妨げる可能性があります。インシデントコマンダーとしてのあなたの仕事の1つは、コミュニケーションラインを明確に保ち、規律を維持することです。奇妙な、あるいは馴染みのない略語を議論に持ち込まないでください。

略語の過剰使用#

028. 略語の過剰使用。

略語や内部用語が多すぎると、新たな参加者を混乱させ、認知的負荷を増やします。この現実的な例が示すように。

「インシデントコマンダー（IC）を対応会議（RC）に呼んで、それから対象分野の専門家（SME）全員にベーコン、レタス、トマトのサンドイッチ（BLT）を用意しよう」と言うのは、かなり時間がかかります。しかし、何が求められているのかはずっと明確です。

明確さは簡潔さより重要#

029. 明確さは簡潔さより重要。ドキュメント参照

明確な指示は、簡潔な指示よりも重要です。他のすべてに優先して、明示的で明確なコミュニケーションを重視するべきです。5秒で済む略語を使うか、30秒かけて明確にするかの選択肢がある場合は、30秒かけてください。長い説明は避けますが、指示が曖昧にならないようにしてください。

インシデントを急いで処理しようとする傾向があり、1秒1秒が重要で、最速の対応を得るために略語を使用する必要があると考えがちです。しかし、馴染みのない不明確な言葉を使用すると、ほとんどの場合インシデントを長引かせることになります。

何が問題なのか？#

030. 何が問題なのか？ドキュメント参照

さて、実際に問題を解決し始めるにはどうすればよいでしょうか？

最初のステップは、SME（対象分野の専門家）から、彼らのサービス/担当領域に関する情報を収集することです。何が問題なのか、インシデントの症状は何かを尋ねます。1つのシステムだけに影響しているのか、すべてに影響しているのか、特定のメトリクスがアラームを引き起こしたのか？

これを「状況把握（size-up）」と呼びます。インシデントの範囲を把握しようとしているのです。

どのようなアクションを取れるか？#

031. どのようなアクションを取れるか？ドキュメント参照

次に、専門家たちに、彼らのシステムを修復するために何をしたいのかを尋ねます。覚えておいてください、インシデントコマンダーは解決策を考え出すのではありません。サービスの専門家に、彼らが取れるアクションについて尋ねたいのです。彼らの方がはるかに良く理解しているはずです。修復のための提案を集めます。

どのようなリスクが伴うか？#

032. どのようなリスクが伴うか？

重要なのは、提案されたアクションに伴うリスクについても必ず尋ねることです。「それによってどのような影響がありますか？」「どのようなリスクが伴いますか？」「うまくいく確信はどのくらいありますか？」

この情報がなければ、十分な情報に基づいた決定を下すことができません。例えば、問題を解決するためにサーバーを再起動する必要がある場合、すべてのサーバーを一度に再起動して30秒で終わらせるか、ローリング再起動を行って10分かけるか、という選択肢があります。表面的には、最初の選択肢が最適に見えます。

しかし、リスクについて尋ねると、最初の選択肢ではその30秒の間、全ユーザーにダウンタイムが発生するのに対し、2番目の選択肢は時間はかかるものの、エンドユーザーにダウンタイムが発生しないことがわかります。この情報によって、あなたの決定が変わる可能性があります。だからこそ、情報を得ることが重要なのです。

決定を下す#

033. 決定を下す。

アクションとそれに伴うリスクを収集したら、決定を下す時です。ある時は、1つの選択肢が明らかに優れているという場合もあります。しかし、時には同くらい悪い2つの選択肢を突きつけられることもあります。

ここで私が提供できる黄金律はありません。状況とあなたの会社の文化次第です。しかし、2つの選択肢の間で決められない場合は、文字通りコインを投げることをお勧めします。間違った決定を下すことは、決定を下さないことよりも良いのです。決定を下さないことは前進の助けにはなりません。何も新しい情報は得られず、インシデントはまだ続いています。たとえ「間違った」決定であっても、より多くの情報を得ることができます。それが間違いだと判明した場合は、他の選択肢に全リソースを投入できます。

間違った決定からはより有用な情報が得られますが、決定を下さないことからは何も得られません。意思決定の麻痺（decision paralysis）は何としても避けなければなりません。それはインシデントをさらに長引かせる可能性があるからです。

合意を得る#

034. 合意を得る。

決定を下したら、その計画について合意を得る必要があります。でも待ってください。先ほどインシデントコマンダーは基本的に独裁者で、全員が彼らの指示に従うべきだと言っていませんでしたか？技術的にはその通りですが、専門家たちが計画に対して持っているかもしれない潜在的な問題点を聞く機会を確保したいのです。後になって「それがうまくいかないことはわかっていた」というような発言をされたくありません。後知恵バイアス（hindsight bias）の問題を防ぎたいのです。それは対応者のやる気を失わせ、時間を無駄にします。

しかし、大人数の間で合意を得るのは少し難しい場合があります。

青い背景#

035. この背景は青です。

簡単な例を見てみましょう：

この背景は青だと提案します。全員同意しますか？

合意に達するのにどれだけ時間がかかるか見てください？分散した合意を得るのは難しいもので、提案されたアクションについて合意を得ようとすると永遠にかかってしまいます。

別の方法を試してみましょう：

この背景は青だと提案します。強い反対はありますか？...反対がないようなので、背景は青です。進めましょう。

強い反対はありますか？#

036. 強い反対はありますか？ドキュメント参照

これがどれだけ早かったか見てとれますか？部屋にいる全員の暗黙の合意を得たので、誰も後になって背景が青ではないと言うことはできません。全員に反対する機会を与えたからです。

この方法は99%のケースに最適化されています。ほとんどの場合、反対はないので、そのまま続けることができます。同様に、人々が同意するかどうかは気にしません。私たちが気にするのは人々が 反対 するかどうかです。それが最も必要な情報です。全員に「はい」と言ってもらおうとすると、本当に重要な指摘をしようとする1人が「いいえ」と言っているのに、他の全員が「はい」と言っているために聞こえなくなってしまう可能性があります。

「強い」という言葉#

037. 強い反対。

これはインシデントコマンダーとしてのツールキットの中で最も有用なフレーズの1つです。決定に関する合意を非常に早く得ることができ、後になって後知恵の問題が発生するのを防ぐことができます。しかし、私たちの言い方は重要です。「強い」という言葉は、私たちがまだインシデント状況にあり、通常の懸念が当てはまらない可能性があることを無意識のうちに人々に印象付けます。

反対を表明する機会を十分に設けるようにしてください。強い反対を求めてすぐに進めてしまうのは良くありません。すべての対応者が懸念を表明する機会を持つ必要があります。

さて、合意が得られたので、タスクを誰かに割り当てる必要があります。その前に、簡単な質問があります。

私はどのくらい話していますか？#

038. 私はどのくらい話していますか？

最初に、時間を管理してくれる人を探しましたが、実際に誰かがやってくれましたか？私が正確にどのくらい話しているか、誰か言えますか？

おそらくできないでしょう。でも、なぜできないのでしょうか？私ははっきりと頼みましたよね。

それは、私の質問の仕方に問題があったからです。

傍観者効果#

039. 傍観者効果。

私は「誰か...」と言いました。これは傍観者効果（bystander effect）と呼ばれます。全員が他の誰かがやってくれると思い込んで、結果として誰もやらないという状況です。もし運良く誰かが実際にやってくれたとしても、それが誰なのか、あるいはそもそも始めているのかどうかもわかりません。

例えば、医療緊急事態が発生し、「誰か911に電話して！（日本の場合であれば119）」と叫んでも、誰も電話しないことがわかるでしょう。全員が他の誰かがやっていると思い込むからです。そのような状況では、誰かを指さして「あなたが911に電話して」と言う必要があります。そうすれば確実に実行されます。

だから、私がすべきだったのは、部屋の誰かを指さして次のように言うことでした：

あなたが時間を管理して、30分経ったら小さく手を振って知らせてください。今から始めます。わかりましたか？

これがどれだけ違うか見てください。

タスクの割り当て#

040. タスクの割り当て。ドキュメント参照

インシデントの文脈では、それは次のようになります。「原因を調査できる人はいますか？」というよりも、はるかに詳細です。先ほどの「明確さは簡潔さより重要」に戻りますが、タスクを割り当てる際にいくつかの重要なことが起こりました。

特定の人に割り当てる#

041. タスクは特定の人に割り当てる。

まず、タスクは直接特定の人に割り当てられました。「オンコールのDBA...」などのように役割に割り当てることもできますが、それは単一の個人でなければなりません。グループにタスクを割り当てないでください。実行されないからです。

時間制限#

042. すべてのタスクに時間制限を設ける。

次に、タスクには時間制限が設けられました。これにより、SMEは私が答えを求めて戻ってくるまでの正確な時間を知ることができ、不意を突かれたり、準備不足になったりすることはありません。期待値を設定します。

確認#

043. 確認を得る。

最後に、指示を理解し、実行することを確認しました。そのため、5分後に戻ってきて、彼らが開始していなかったり、追加の質問があったりということはありません。

フォローアップ#

044. フォローアップ。

そして時間が経過した後、タスクの結果を尋ねることができます。もちろん、彼らは常に最初から正しい答えを持っており、追加の調査時間を必要とすることは決してないでしょう、そうですよね？

もっと時間が必要？#

045. もっと時間が必要な場合は？

物事が常に時間内に完了するとは限りません。5分後に、もっと時間が必要だと言われた場合はどうしますか？

単に別の任意の時間制限を与えるのではなく、1時間かけて5分ずつ時間を与え続けることになるだけなので、その代わりに専門家たちに必要な時間を尋ねてください。

時間の延長#

046. 時間の延長。

これは映画のようにはいきません。誰かが2時間必要だと言ったときに、テーブルを叩いて「1時間しかない！」とは言いません。専門家たちが正確な見積もりを提供してくれると信頼し、必要な時間を与える必要があります。不当なプレッシャーをかけることは、ミスを引き起こすことにしかなりません。

インシデント解決までの流れ 1#

047. インシデント解決のフローチャート

インシデントが解決するまで、このパターンを繰り返します。

1. 専門家からステータスを確認する
2. 報告された情報に基づいて行動を決定し、計画について合意を得る
3. タスクを割り当てる
4. タスク完了後にフォローアップし、問題が残っている場合は繰り返す

インシデント解決までの流れ 2#

048. インシデント解決のもう1つのフローチャート

より一般的には、各インシデントに対してこのサイクルに従います。状況を把握し、安定化させ（先ほど示したループ）、進行状況を全員に伝え、状況が修正されたことを確認してから対応を終了します。修正されていない場合は、再度最初から始めます。

インシデントコマンダーを無視する#

049. 「みんなインシデントコマンダーを無視して、私の言うことを聞きなさい！」

おっと、経営幹部が対応に加わり、インシデントコマンダーの決定を覆そうとしています。これは良くない状況です。

インシデント対応においてはインシデントコマンダーが最高権限を持ち、その決定が重要であることを忘れないでください。では、誰かがその決定を覆そうとする厄介な状況にどう対処すればよいでしょうか？

ここで重要なヒントがあります。インシデントコマンダーとして持っておくべき素晴らしい質問です。この状況を即座に解消できるシンプルな質問があります。

あなたが指揮を取りたいですか？#

050. あなたが指揮を取りたいですか？ ドキュメント参照

あなたが指揮を取りたいですか？

...なかなか「はい」と答えないことに注目してください。

もし「はい」と答えた場合は素晴らしい！あなたは責任から解放され、次のように対応できます：

了解しました。会議参加者の皆様にお知らせします。私は指揮権を経営幹部Aに移譲します。彼が新しいインシデントコマンダーとなります。

しかし、ほとんどの場合「いいえ」と答えるか、まったく答えません。その場合は通常通り続行し、場合によっては次のように言うことができます：

その場合は、これ以上の中断は控えていただくか、会議から退出していただく必要があります。

「あなたが指揮を取りたいですか？」は、このような経営幹部による敵対的な乗っ取りに対処する最も有用なフレーズです。

エグゼクティブの襲来#

051. エグゼクティブの襲来

これは「エグゼクティブの襲来（Executive Swoop）」と呼ばれる問題の一種です。実際には「Executive Swoop and Poop」ですが、スライドにはそう書かないように言われました。

ただし、先ほどの例は典型的ではありません。誰かが意図的にそのような問題を引き起こすことは稀です。

エグゼクティブの襲来について、より一般的な例を次に見ていきますが、これらは悪意を持って行われるものではないことに注意してください。経営幹部は対応を妨げる意図を持って参加するのではなく、人々を動機づけ、状況を把握しようとしています。それは彼らのビジネスでもあるのです！これらの行動が問題となる理由を経営幹部に理解してもらうことが重要です。そのため、このような事態が発生した場合は、インシデント後に必ずフォローアップしてください。

10分で解決しましょう#

052. 10分の解決を試みましょう

10分以内の解決を試みましょう！

これは確実にPagerDutyの誰も言ったことがないセリフです。絶対に。

表面的には、かなり無害に見えます。経営幹部は単にスタッフを動機づけ、問題を迅速に解決するよう促しているだけですよね？

残念ながら、会議の他の参加者はそのようには解釈しません。代わりに、「1時間かけるつもりだったけど、そう言うなら10分でやってみるか」と皮肉っぽく考える可能性が高いです。これは、人々がすでに問題解決のために最善を尽くしているという前提を無視しています。対応者のやる気を削ぎ、さらなるストレスを加えることになります。

インシデントコマンダーとしてのあなたの仕事は、これを芽のうちに摘み、軌道に戻すことです。

コメントは最後まで控えてください#

053. コメントは最後まで控えてください ドキュメント参照

物事を進めるために、経営幹部に現在の状況を思い出させ、質問は後で対応するよう指示する必要があります。少しぶっきらぼうに聞こえるかもしれませんが、要点を素早く伝え、前に進むことができます。ほとんどの人は暗黙のメッセージを理解するでしょう。

インシデント対応中です。コメントは最後まで控えてください。

忘れないでください。意地悪になるのではなく、事実を述べて物事を進めましょう。人々を恥じ入らせたり気分を害したりすることが目的ではなく、インシデントを解決に向けて進めることが目的です。

影響を受けた顧客のスプレッドシート#

054. 影響を受けた顧客のスプレッドシートが欲しい

影響を受けた顧客全員のスプレッドシートを作成できますか？

これも確実にPagerDutyのインシデント対応会議で一度も出てきていないセリフです。

経営幹部が会議に参加し、影響を受けた顧客のリストを取得したいと考えています。問題は、その情報を見つけるために、最も必要とされている時に誰かをインシデント対応から外さなければならないことです。リソースに余裕があれば、情報収集に人員を割り当てることは自由です。しかし、ほとんどの場合、割くリソースはないでしょう。そのため、経営幹部にそのことを伝えればよいのです。

インシデントが優先#

055. インシデントが優先 ドキュメント参照

リストを作成するか、インシデントを解決するか、どちらか一方しかできません。インシデントが優先です。

これが質問形式ではないことに注目してください。「リストを作成するか、インシデントを解決するか、どちらがよいですか？」とは言っていません。インシデントコマンダーはすでに決定を下しており、単にその決定を経営幹部に伝えているだけです。

インシデントコマンダーが依然として指揮を執っていることを忘れないでください。インシデント中に他の人に意思決定を譲りたくはありません。

本当にSEV-1？#

056. 本当にSEV-1なの？

これは本当にSEV-1なのですか？

ああ、これもPagerDutyで一度も起きていないことです。以前は、この問題で本当に大変でした。インシデント対応会議を始めると、最初の10分間はSEV-3なのかSEV-2なのかを議論していました。議論が終わる頃には、SEV-1の状態で10分が経過し、何の進展もないという状況でした。

そこで今では、ルールを設けています。会議中は重大度について議論しません。2つの重大度の間で決められない場合は、常により高い重大度を想定して進めます。

インシデント中に重大度について議論するのは時間の無駄です。

SEV-1として扱う#

057. SEV-1として扱います ドキュメント参照

そのため、インシデントコマンダーは議論しないことを明確にし、SEV-1として扱うことを伝える必要があります。結果的にSEV-4かもしれませんが、誰が知るでしょうか、それは重要ではありません。それはポストモーテムでの議論です。

会議中は重大度について議論しません。これをSEV-1として扱います。

インシデント対応のプロセスを開始したら、最後まで実行する価値があります。少なくとも、それは全員にとって良い練習になります。

ステークホルダーへの通知#

058. ステークホルダーへの通知

これらのエグゼクティブの襲来の例のほとんどは、ステークホルダーをプロセスに巻き込み、最新情報を把握する方法を提供することで事前に防ぐことができます。

PagerDutyでは、インシデントのアップデート専用のSlackルームを別途設けています。メインの対応ルームよりもノイズが少なく、必要な人々に簡潔なアップデート情報を提供します。これにより、経営幹部は状況を把握し続けることができ、メインの対応に影響を与えることなく質問することもできます。私たちのプロセスでは、インターナルリエゾンがそのチャンネルの監視とアップデートを担当します。

ステークホルダーは、対応会議やメインのインシデント対応チャットルームでの発言は許可されていません。すべての議論はアップデートルームまたはインターナルリエゾンを通じて行う必要があります。インシデントコマンダーは、主要なコミュニケーションチャンネルをこれらの種類の議論や質問から解放し、人々をインターナルリエゾンに導く責任があります。

反抗的な対応者#

059. 反抗的な対応者

エグゼクティブの襲来のカテゴリーには入らない、対応を妨げる他の要因もあります。これを私たちは反抗的な対応者と呼んでいます。元々は「酔っ払いエンジニア」と呼ばれていましたが、これもスライドには載せないように言われました。

対応会議では、様々な厄介な状況が発生する可能性があります。大きな自尊心や強い意見が存在することがあります。会議で誰かが反抗的になり、対応プロセスを妨げている場合、どうすればよいでしょうか？

毅然とした態度で、継続した場合の結果を伝える必要があります。

妨害行為#

060. 妨害行為をしています ドキュメント参照

あなたは妨害行為をしています。やめていただくか、会議から退出していただく必要があります。

事実を述べ、面子を保つ方法を提供し、続けた場合の結果を伝えます。二度目のチャンスはなく、応じない場合は行動を実行します。厳しいかもしれませんが、それが必要なことです。

ここでも特定の言い方をしていることに注意してください。「あなたを退出させます」ではなく、「退出していただく必要があります」と言っています。これにより、決定があなたの手を離れており、強制的にそうせざるを得ないように見えます。これにより、より個人的な問題になりにくく、会議後に厄介な問題が発生する可能性が低くなります。

対応者は疲れるのか？#

061. 対応者は疲れるのか？

対応中に発生する可能性のある別の問題は、長時間のインシデントの場合です。

12時間のインシデントで同じインシデントコマンダーを使用しますか？インシデントコマンダーは疲れないのでしょうか？もちろん疲れます！彼らも人間です。これはインシデント対応に関連する、最小限に抑えたい人的コストのもう1つの例です。

対応プロセスにおけるすべての役割は、精神的に疲労する可能性があります。疲れると物事を忘れたり間違えたりし始めるので、できるだけ頻繁に新鮮な視点を保つように努めることが重要です。

引き継ぎを推奨#

062. 引き継ぎを推奨

このため、私たちのプロセスでは積極的に引き継ぎを推奨しています。通常は1時間ごとを推奨していますが、関係者の裁量に委ねられています。3時間が引き継ぎを要求する絶対的な上限となります。

指揮の引き継ぎは重要で、とても簡単です。メインの議論とは別に、新しいインシデントコマンダーに状況を説明します。例えば、Slackでプライベートメッセージを使用します。副指揮官がいる場合はさらに良いでしょう。なぜなら、彼らはすでに会議に参加していて状況を把握しているからです。

そして引き継ぎを行います。

引き継ぎ#

063. 引き継ぎ ドキュメント参照

指揮を引き継ぐことを宣言し、新しいインシデントコマンダーは新しい会議を始めるかのように開始します。シンプルです！

引き継ぎができるようにするためには、できるだけ多くの訓練されたインシデントコマンダーを持つことが重要です。多ければ多いほど良いです。理想的には、少なくとも日次のローテーションができる程度は必要です。

アンチパターン#

064. アンチパターン ドキュメント参照

アンチパターンについて話しましょう。インシデント対応に役立つように見えるが、実際にはそうではないものです。これらを今知っておくことで、私たちが経験した頭痛の種や成長の痛みを避けることができます。

全員を会議に参加させる#

065. 全員を会議に参加させる ドキュメント参照

信じられないかもしれませんが、以前のPagerDutyではSEV-2が発生するたびに、すべてのエンジニアに通知を送っていました。冗談ではありません。エンジニアが5人しかいなかった時は素晴らしく機能しましたが、50人になるとそうはいきませんでした。

インシデント中は効果的な管理範囲（Span of Control）を維持することが重要です。一人の人物へレポートする人数は7人を超えないようにします。それ以上になると、厨房に料理人が多すぎる状態になります。

午前3時に30人のエンジニアを起こすことは、計り知れない損害を引き起こします。絶対にやめましょう。

対応者を退出させない#

066. 対応者を退出させない ドキュメント参照

冒頭で、インシデントに関連するコストを削減することが目標の1つだと述べたことを覚えていますか？それには人的コストも含まれます。午前3時に人々を起こすことはコストがかかります。しかし、何もできない会議に人々を留めておくことはさらに悪いことです。

そのため、一部の対応者がもう必要なくなった場合は、会議から退出させましょう。同僚の時間はサーバーよりもコストがかかります。彼らを燃え尽きさせないでください！

退出してほしい人全員をリストアップすることはお勧めしません。誰かを見落とす可能性があるからです。代わりに、残ってほしい人を言うほうが良いでしょう。そうすることで、残ってほしい人も明確になります。例えば：

オペレーション、サポート、そしてRichは残ってください。他の皆さんは、適宜退出して構いません。

頻繁すぎるステータスアップデート#

067. 頻繁すぎるステータスアップデート ドキュメント参照

特に経営幹部は頻繁なステータスアップデートを好みます。しかし、アップデートを頻繁に提供しすぎると、事態が制御不能になる可能性があります。アップデートを書くのに5分かかり、5分ごとにアップデートを求められると、インシデントの解決にどれだけ時間がかかるかが見えてきます。

PagerDutyでは、内部アップデートを20-30分ごとに行っています。アップデートを書くことはインシデントの解決から時間を奪うため、バランスを取る必要があります。このケイデンスは私たちにとってうまく機能しています。

特定の問題へ過度に焦点を当てる#

068. 特定の問題へ過度に焦点を当てる ドキュメント参照

インシデントコマンダーは通常、何が起きているかの全体像を把握している人です。しかし、対応者が全体像を考慮せずに、目の前の問題に過度に焦点を当ててしまう傾向があります。

これは通常、インシデント会議でSMEがインシデントコマンダーの指示を聞かずに同じ問題を繰り返し持ち出し、自分のシステムの特定の問題への視野狭窄に陥っている場合に現れます。

視野狭窄に陥ったり、真の問題から気を逸らすものを追いかけたりしないようにしましょう。常に全体像を念頭に置いてください。

深い技術知識を持つインシデントコマンダーを要求する#

069. 深い技術知識を持つインシデントコマンダーを要求する ドキュメント参照

以前は、すべてのインシデントコマンダーがPagerDutyのすべてのシステムについて深い技術知識を持つ経験豊富なエンジニアであることを要求していました。これは私たちの大きな間違いの1つでした。インシデントコマンダーは対応者ではなく、実際に問題を修正する人ではないため、深い技術知識は必要ないことを覚えておいてください。インシデントコマンダーは対応の調整のエキスパートであり、技術的な問題を解決するエキスパートではありません。そのためにはSMEに頼るべきです。

技術知識の制限を取り除いたことで、インシデントコマンダーになりうる人たちが劇的に増加し、インシデントへの対応能力には何の影響もありませんでした。現在では組織全体からインシデントコマンダーを迎え、さらに多くの人がトレーニング中です。

ただでさえインシデントコマンダーになりたい人を見つけることは容易ではないので、不必要な制限を追加しないようにしましょう。

複数の役割を引き受ける#

070. 複数の役割を引き受ける ドキュメント参照

過去のPagerDutyのインシデントでは、インシデントコマンダーがSMEの役割を引き受け、自分で問題を解決しようとした例がありました。これは通常、エンジニアがインシデントコマンダーで、インシデントが自分が構築を手伝ったシステムに関連している場合に発生します。「これなら修正方法がわかる！」と言って、自分で問題を解決しようとするのは非常に魅力的です。しかし、インシデントコマンダーとしてそれをしてはいけません。

必然的に、インシデントは想定よりも大きくなり、あなたが小さな火事を消そうとしている間に、別のサービスで別の火事が発生し、全体像を見失ってしまいます。

インシデントコマンダーでありながら、同時に別の役割を引き受けることはできません。もし本当にあなたが問題を解決できる唯一の人物である場合は、別のインシデントコマンダーに引き継ぎ、インシデントの残りの時間はSMEとして活動してください。

ポリシーの議論#

071. インシデント中にポリシーを議論する ドキュメント参照

重大度と同様に、ポリシーとプロセスについてもインシデント中に議論すべきではありません。現在のプロセスに従い、懸念事項はポストモーテムの際か、インシデント対応プロセスを管理するチームに直接伝えるべきです。

インシデント中にプロセスを変更しようとすることは、現在のインシデントを長引かせるだけです。それを議論する時ではありません。

プロセス変更への抵抗#

072. プロセス変更への抵抗 ドキュメント参照

最後に、安定したプロセスが確立され、インシデントが解決されるようになると、そのプロセスを変更することへの躊躇や抵抗が多く見られます。「うまく動いているものは変えない」という考えです。会社が成長するにつれて、対応も変化する必要があります。古いプロセスや慣行を長く保持しすぎると、今後のインシデント対応の妨げになる可能性があります。もちろん無謀になってはいけませんが、賢明な変更を導入するよう努め、短期的には物事を遅くするかもしれないが長期的には物事を速くする変更を恐れないでください。これらは最も実行が難しい変更ですが、最終的には最も価値のある変更となります。

解決#

073. 解決

OK、すべてがうまくいけば、インシデントは解決されます。これで全部終わりで、家に帰れますよね？！

まあ、まだそうではありません。まだやるべきことが1つあります。

ポストモーテムを怠らない#

074. ポストモーテムを怠らない ドキュメント参照

ポストモーテムを実施する必要があります。アクション後レビュー、学習レビュー、レトロスペクティブ、インシデントレポートなど、呼び方は何でも構いません。名前は実際に行うことほど重要ではありません！

インシデント後にポストモーテムを怠るという間違いを避けましょう。ポストモーテムがなければ、何が正しく行われ、どこを改善できるか、そして最も重要な、次回同じ間違いを避ける方法を認識できません。適切に設計された非難のないポストモーテムにより、チームは継続的に学習でき、インフラストラクチャとインシデント対応プロセスを反復的に改善する方法として機能します。

ポストモーテムは重要なフォローアップアクションであり、決して省略すべきではありません。インシデント対応を開始して誤報だと判断した場合でも、簡単なポストモーテムを行うべきです。不必要な対応を動員したのですから、それが再び起こらないようにする方法を特定したいはずです。

ポストモーテムの作成#

075. ポストモーテムの作成 ドキュメント参照

最初のステップは、ポストモーテム自体を作成することです。これはインシデントコマンダーの仕事です。ポストモーテム全体を書くという意味ではなく、初期テンプレートを作成するだけです。人々が「何がうまくいかなかったのか、いつわかるの？」と尋ねてきたときに渡せるリンクが存在することを確認したいのです。

オーナーの選定#

076. オーナーの選定

次にインシデントコマンダーはオーナーを割り当てる必要があります。特定の個人にタスクを割り当てたことを覚えていますか？ポストモーテムも同じです。明確なオーナーがいることを確認し、それが個人であってチームではないようにしてください。特定の人ではなくチームに割り当ててしまうと、ポストモーテムはほぼ確実に完了しません。

割り当てられた人がポストモーテムの完了に責任を持ちますが、すべてを自分でやる必要はありません。必要に応じてセクションを委任することができます。しかし、完了を確実にする責任者が必要です。

他のタスクの割り当てと同様に、期限を設定し、ポストモーテムの完了に責任があることを理解していることを確認する必要があります。

非難のないもの#

077. 非難のないもの

重要なことですが、ポストモーテムは非難のないものでなければなりません。誰かがミスをしたとしたら、あなたは二度とそれを繰り返さないよう訓練するために多額のお金を費やしたということです。誰かを解雇しても信頼性は達成できません。

例えば、Bobがデータベース全体を削除するコマンドを実行したとします。ポストモーテムは「Bobがミスを犯したので解雇されるか、アクセス権を剥奪されるべきだ！」とすべきではありません。ポストモーテムは「なぜシステムが単一のユーザーがデータベース全体を削除できるように構成されているのか？」とすべきです。

ポストモーテムで人を名指しして恥をかかせると、全員のやる気を削ぎます。次に誰かミスをしたとき、同じように恥をかかされることを恐れて、認めようとしないでしょう。問題を提起してもらいたいのです。そうすれば素早く修正できるからです。

プロセスのレビュー#

078. プロセスもレビュー！

ポストモーテムの一環として、プロセスのレビューも忘れないでください。プロセスをより良くするためにどのように変更できるでしょうか？何がうまく機能していないでしょうか？ソフトウェアの間違いから学び、修正することが重要なように、インシデント対応プロセスについても同じことをしたいのです。

練習#

079. 練習が完璧を作る

最後に、できるだけインシデント対応プロセスを練習したいと思います。実際のインシデントで初めて実践するのは大変です。読むことと実際に実践することは全く異なります。

模擬インシデントから始めましょう。そして、小さなインシデントを大きなインシデントのように扱います。インシデント対応を開始して、実際のインシデントではないとわかった場合でも、無料の練習として同じように扱います。

PagerDutyでは、Failure Fridayと呼ばれるものを実施しています。システムの回復力をテストするために意図的に障害を注入します。これを重大なインシデントとして扱い、インシデントコマンダーなど全てを含めて対応します。これにより、通常のインシデントのストレスがない状態で練習することができます。

また、Keep Talking And Nobody Explodesというゲームもプレイします。はい、その通り、仕事中にビデオゲームをプレイします。しかし、このゲームはインシデントコマンダーが対処しなければならない多くのことをシミュレートし、ストレスのない練習を得るための素晴らしい方法であることがわかりました。

要するに、できるだけ多く練習して、避けられないインシデントが発生したときに、対応が単なる日常的な作業となるようにしましょう。

オープンソースの対応ドキュメント#

080. 私たちのオープンソースのインシデント対応ドキュメント

これは、PagerDutyで私たちが自社のインシデントコマンダー向けに実施しているトレーニングのほんの一部です。全てをカバーするには時間が足りませんでした。

しかし良いニュースがあります！私たちは完全なインシデント対応プロセスをオンラインで公開しています。これは電話番号などを削除した以外は、内部ドキュメントの完全なコピーです。完全に無料で使用でき、Apache 2.0ライセンスの下でオープンソース化されているため、あなたの組織でも使用できます。GitHubにありますし、間違いを見つけたり改善提案があったりする場合はプルリクエストも受け付けています。

今日お話ししたことはすべてドキュメントに記載されており、さらに詳しく学びたい場合は素晴らしい追加の読み物もあります。

対応ドキュメントの画像#

081. 対応ドキュメントのスクリーンショット

見た目もいい感じですよ。

まとめ#

082. まとめ

インシデントコマンド研修は、夜中にサーバーが爆発するような状況以外でも多くの場面で役立ちます。高速道路での接触事故後の冷静さの維持から、大規模な自然災害時の支援まで、人生のさまざまな場面で適用できます。私自身の生活でも、親の役割とインシデントコマンダーの役割を頻繁に比較しています。日常的な状況でどれほど役立つか、驚くかもしれません。

さて、今日議論した主なポイントを簡単にまとめて終わりにしたいと思います。ありがとうございました！

画像クレジット#

083. 画像クレジット

PagerDuty University#

084. PagerDuty University

動画#