アンチパターン

全員が通話に参加する#

信じられないかも知れませんが、SEV-2インシデントが発生した時に、PagerDutyの全てのエンジニアを呼び出していました。 SEV-2が午前3時に発生した場合、午前3時にも関わらずエンジニア部門全員をページしてました。

1. 会社が今よりも小さかったとき、エンジニアは数人しかいませんでした。 なので本当に必要なエンジニアは全員だったので、この方法はうまくいってました。
2. インシデントをトリアージして必要な人を呼ぶのではなく、全員が通話にいることでより迅速に対応できると考えていました。

エンジニア部門は拡大しましたが、この方法はスケールできず、すぐに問題が明らかになりました。

1. 通話にいるひとのほとんどが何もできませんでした。何の理由もなく彼らは起こされました。
2. 人をページするのはコストがかかります。従業員の健康状態と金銭的理由の両方です。 午前3時にエンジニア部門全員が起こされてしまうと、翌日部門全体で生産的な作業ができなくなってしまいます。
3. オンコールでは無かった人には再びページされます。

あらゆるインシデント対応は 効率的な管理範囲を維持し続ける事が重要です。 もしインシデントコマンダーに直接報告する人が7-8人いるのなら、事態はすぐに気後れするでしょう。 そのためチーム全体ではなく、特定のサービスのオンコールエンジニアのみを呼び出します。 より多くの対応者が必要になった場合は、対応に参加するよう内部連絡によって動員されます。 10回中9回は追加の対応者が必要にならないため、残りのメンバーは邪魔されること無く休息をとることができます。 これによりエンジニア部門がより幸せになり、応答処理がより合理化されます。

全員が通話に残り続けるようにする#

私たちの当初の考えは、インシデントの通話に参加したら、その地点から通話終了まで居続けるべきだと考えていました。 インシデントが解決する前に再び必要になる可能性があるためです。 残念ながらそれは実際には、その必要ないということが分かりました。 通常誰かが動員されて、システムの調査をしたり特定のアクションを実行すると、その後は特に必要ありません。 通話中の全員が何もせずに、誰も眠りにつけなかったことがありました。 また通話にとどまるべきだというプレッシャーにもなります。

現在は、不要になった場合は通話から出るようお願いしています。 インシデントコマンダーが影響のあるシステムを確認すると、他のシステムの担当者は休息が取れるように通話を出られるようにします。 本当に必要な場合は、いつでも再動員できます。 ほとんどの場合はそれは必要ないので、99%のケースに適応します。

多すぎるステータスの更新#

経営陣は何が起こっているかを知る必要があり、議論に参加して5分ごとにステータスの更新情報を提供していました。 この問題は更新情報を提供するのに時間がかかりすぎるということでした。

重大インシデント発生中では、大体の場合は定期的に20-30分ごとに情報を提供するので十分だとわかりました。 これにより更新情報を提供するだけでなく、より有用な情報が含まれる可能性が高くなります。 これよりも高頻度で情報を提供できないというわけではありませんが、その必要ないでしょう。 可能な限り問題の修正に時間を使いたいと思いますが、ステークホルダーと一緒に議論もしたいです。 これは間違えやすく、微妙なバランスです。

沈黙は進捗がないという憶測#

インシデントの通話で沈黙している人は何もしていないとみなせますが、これは稀なケースです。 通話に参加するときは、おしゃべりがない期間が合っても良いですし、それは妥当です。 静かなのは、喋ったり更新情報を提供せずに、問題を解決しているからです。 私たちは「Keep talking and nobody gets fired」というゲームをプレイしているのでは無いのです。 インシデントコマンダーは通話中の殆どで話し続ける必要がある人の1人です。 通常彼らは、必要に応じて無言の時間にステータスの更新情報で埋めます。 組織の他のメンバーは通話中の沈黙は悪いことではなく、進捗が止まっていることでは無いということを、トレーニングを受けて知る必要があります。 スタッフたちがこの事を知っているか確認することで、インシデント解決を邪魔する、インシデントの通話中での不適切な会話を防ぐことができます。

インシデント通話中に深刻度について繰り返し議論する#

過去のPagerDutyでは、インシデントの通話の始まりで、状況は本当にSEV-2なのか、通話がいらないそれ未満なのかという議論が多くありました。 この議論はみんなが知りたがり、いつも時間がかかっていました。 議論中にも問題は発生しており、インシデントはその間にも進行して、SEV-1になるまでの10分間を無駄にしただけでした。

現在は インシデント通話中に深刻度の議論をしない とうルールが決まり、常に最も高い深刻度を想定して問題を扱います。 したがってSEV-2かSEV-3かわからない場合は、SEV-2としての行動します。 インシデント対応と呼び出された対応者はすでにエンジンがかかっているので、もしSEV-3であるとわかっても、通常どおり処理を続けます。

他の対応者へのエスカレーションをためらう#

午前3時で、あなたがインシデントの対応者だと仮定します。 内容領域専門家が問題をデバッグしようとしてるか行き詰まっており、夜間のため他のメンバーの呼び出しをためらっています。 これによりインシデントが必要以上に長引く可能性もあります。

「エスカレーションをためらっては行けない」というのは、私たちの持論です。 もしあなたが午前3時に問題に行き詰まってしまった場合でも、その状況を解決できる知見がある誰かを呼び出すのをためらわないでください。 ただしやりすぎたり、全員をページしないでください。アンチパターンに陥ってしまいます。 しかし助けが必要な場合は、誰かをページできないとは思わないでください。

インシデントの通話中にプロセスとポリシーの決定について議論する#

対応者がインシデント対応ポリシーとプロセスに同意しない場合があります。 これによりインシデントの通話中に議論が発生します。 結果的にみんなのプロセスが脱線し、根本的なインシデントが長引き、対応が妨げられる可能性があります。 プロセスに同意できずにそれを変更したいというのは全く問題ありません（実際に、プロセスを反復的に改善できるので、私たちはこれを奨励しています）。 しかしインシデント発生中は、その議論はすべきではありません。

深刻度と同じように、インシデント発生中は、ポリシーとプロセスについて議論すべきではないです。 インシデント発生中は現在のプロセスに従うべきで、懸念事項はその後にポストモーテムまたはインシデント対応プロセスを管理するチームに伝えるべきです。

ポストモーテムとフォローアップ活動を放置する#

ポストモーテムに悩まされずに、インシデントが解決するのは、魅力的です。 問題の原因が自明であるか、それをするに値しない場合のどちらかです。 しかしこの罠に陥らないでください。 ポストモーテムは常に価値があるものです。 人々はインシデントに動員し、それのコストもかかりました。 何が起こったかを理解して、将来そのコストを回避したいです。

インシデント収束後のポストモーテムを放置しないでください。 ポストモーテムなしでは、何が正しい行いなのか、どこを改善できるか、そして最も重要な、次回にどうすれば回避できるかの、判断ができなくなります。 よく設計された、誰も責めないポストモーテムは、チームに継続的に学びの機会を与え、インフラとインシデント対応プロセスの反復的な改善ができます。

あなたが対応者を動員したにも関わらず、それが「本当の」インシデントではなかった場合でも、ポストモーテムは必要になります。 次回以降も対応者を動員して、時間を無駄にするからです。 インシデント対応が必要なかったのにトリガーされた理由を見つけて、その問題を修正します。

目の前の問題に集中しすぎる#

インシデントの対応者は、通常は目の前のタスクに集中しがちです。 一般的にインシデントコマンダーは、目の前の問題よりも全体像を捉えてることができる人です。 内容領域専門家は全体像を把握せずに、目の前の問題に集中しすぎる事があります。 インシデントコマンダーからの指示を聞かなかったり、特定の問題に対して視野が狭すぎる、内容領域専門家との通話中に同じ問題を引き起こします。

インシデントコマンダーからの指示は常に従う必要があり、現在起こっている全体的な背景情報が含まれる事が多いです。 目のための問題に極度に集中しすぎないようにしましょう。 プロセスを狂わせることになります。 私たちはインシデントの症状ではなく、原因を処理したいのです。

ポリシーとプロセスの変更に反対する#

安定したプロセスが確立され、インシデントが解決できるようになると、そのプロセスの変更に多くの迷いと抵抗が出てきます。 「壊れない限り修正しない」のように。 会社が成長するにつれ、対応プロセスも変更する必要が出てきます。 古いプロセスとプラクティスが長い間変化しないと、将来のインシデント対応の妨げとなる可能性があります。 もちろん無謀なことはしてはいけません。 実用的な変更をして、 短期的には速度が落ちるかも知れませんが、長期的では早くかるかもしれないので、恐れないでください。 これは難しい変更ですが、通常は最も価値があることです。

複数の役割を引き受けようとする#

過去のPagerDutyのインシデントでは、インシデントコマンダーが内容領域専門家の役割を引き受けて、問題を自身で解決しようとしました。 これはインシデントコマンダーが日々の業務ではエンジニアであるときに、起こることが多いです。 彼らはインシデントが発生したシステムに詳しく、問題を修正するための知見も持っています。 問題を早く解決したいがために、インシデントコマンダーが問題解決に取り組みます。 場合によっては幸運にもインシデントを解決できるかも知れませんが、ほとんどの場合は目に見えた問題がインシデントの根本原因でない可能性が高いです。 それが明らかになる頃には、目の前の問題のみに取り組み他のシステムに注意を払えないインシデントコマンダーとなります。 これは事実上、問題解決に忙しく、インシデントコマンダーがいないということです。 必然的に問題は予想よりも遥かに大きくなり、応答者は完全に目的を見失ってしまいます。

インシデントコマンダーは同時に他の役割を引き受けることはできません。 内容領域専門家として飛びつきたいのならインシデントコマンダーになるのは難しいかも知ませんが、インシデントコマンダーを放棄したくなる気持ちを抑える必要があります。 もし本当にあなたのみが問題を解決できるのなら、インシデントコマンダーは別の誰かに引き継いで、内容領域専門家の役割になるべきです。 これによりインシデントコマンダーが、残りの手順を軌道に乗せることができます。

インシデントコマンダーの仕事には、現在のアクションで問題を解決できない場合のバックアッププランの準備も必要です。 内容領域専門家として特定の問題を修正しているときは、バックアッププランにつていも考える事ができません。

ヒーローになろうとする#

もしあなたが内容領域専門家として行動してるのなら、全ての問題をあなた自身が解決しようとします。 全ての要求に対して、飛びついて自分が引き受けると言いたいかも知れません。 あなたは全ての問題を解決するために不可欠な人となってしまいます。 意欲的なのは立派ですが、ほとんどの場合効率的ではありません。 インシデント中はマルチタスクは避けて、一度に1つの問題に取り組むべきです。 自分で全てを解決しようとしないでください。 もしあなたの専門分野に関する要求が複数来た場合は、他の専門家に委譲して、必要ならバックアップの対応者をページします。

他の内容領域専門家にタスクが割り当てられている場合は、相談せず他人のタスクを勝手に実行しないでください。 助けようとしても、2人が同じ問題に取り組み、予期しないところで互いに干渉して、最終的には対応の妨げになります。

ポリシーの変更を対応者に共有しない#

ポリシーとプロセスの変更を、みんなが事前にドキュメントを読むことに期待して、内部ドキュメント（これ）を更新するだけという罠がありました。 もちろん、何も起こりませんでした。

インシデント発生中に予期せぬことが起こらないために、ポリシーの変更は事前に対応者に適切な方法で共有する必要があります。 これはメールでもできますし、チャットルームで知らせることもできます。 対応者にとって、大きなポリシーの変更が不意打ちであってはいけません。

インシデントコマンダーに深い専門知識を要求する#

インシデントコマンダーが初期の頃に陥った罠です。 高度な専門知識をもつインシデントコマンダーのみを目指して、新しいインシデントコマンダーにはいくつかの強力な技術要件を設定していました。 問題をすばやく解決するためです。 オンコールのローテーションを効果的に維持するために幅広い選択肢が必要だとわかると、インシデントコマンダーの潜在的な候補を制限していることに気づきました。

インシデントコマンダーは組織の全員ができ、専門知識を必要としません。 インシデントコマンダーはインシデントの調整をするのみで、そのためにはシステムの深い専門知識は必要になりません。 内容領域専門家は深い専門知識が必要になる役割の1つです。 インシデントコマンダーは、システムがどのように動作しているかの高位な知識のみが必要です。 どこにデータが流れていて、システムがどのように使い、どこにデータが流れているかです。 技術的な詳細はインシデントコマンダーが内容領域専門家に質問します。

インシデントコマンダーに対する強い技術要件を落とすことで、インシデントコマンダーができる人を増やし、高い品質と効果的な対応ができ、会社の大部分でオンコールの負荷に対する共感を得ることができました。