事件が起こる。物事がうまくいかない。システムが故障する。時には、予期しない劇的な方法で失敗し、重大な事故が発生することもあります。PagerDutyは、１つのインシデントと_インシデント_を非常に明確に区別しています。あなたの組織でもそのような区別をしているかもしれません。 （訳注：太字は重大インシデント、斜体は些細なインシデントという意味）
インシデントが重大かどうかの判断は、影響を受けるサービスの数、顧客への影響、インシデントの期間など、多くの要因、または特定の要因の組み合わせによって決まります。
これらの要素には、少なくともベースラインの遠隔測定と、技術エコシステムを構成するサービス間の関係性の把握が必要です。このベースラインがなければ、インシデントのトリアージにおいて、実際の影響やどこから手をつければよいかを知ることは困難です。
重要なデータがない場合、どうなるのでしょうか？次のようなデータがないと、インシデントに対応するのが難しくなります。
- どのサービスが影響を受けるか
- どのサービスにどの程度の影響があるか
- そのサービスのオーナーは誰か
このようなデータがない場合、インシデント対応にスウォームアプローチを選択する組織もあります。
スウォーミングとインテリジェントスウォーミングの比較
スウォーミングとは、組織内の全員に問題が発生したことを知らせ、問題解決に貢献できる可能性の有無に関わらず、全員が参加できる大規模なウォールームや電話会議を開くインシデント対応のアプローチです。インシデントの影響を軽減するためには、適切な人材を適切なタイミングで動員することが極めて重要です。スウォーミングは、適切な人が適切な時間に適切な場所にいることとは正反対で、全員がずっと参加することです。
インテリジェントスウォーミングという言葉は、今月初めにお話しした、特にVIP向けの接客対応ワークフローを指す言葉として使われています。これはやや異なるアプローチで、最初にケースを拾ったチームメンバーが解決まで見届けることを指定し、問題解決を支援するために組織内のリソースを引き込む能力を持つものです。一般的なレスポンススウォームと関連しますが、インテリジェントスウォームの焦点は通常、単一の顧客であり、その体験を中心に据えることです。
一般的なテクニカルインシデント対応のためのスウォームは、建物の火災報知器のように、全員が厳戒態勢で対応することが期待されています。基本的には、何らかの知識を持つ可能性のある人全てにアラートが送信され、インシデントに参加するよう求められ、その後、誰がトリアージと修復を行えるかを見極める手間のかかるプロセスが開始されます。
組織はしばしば、自社のサービスやエコシステムについて十分な情報を持っていなかったり、ステークホルダーに情報を提供するための強力なコミュニケーション手段を持ち合わせていないために、群れをなしてしまうことがあります。何かが起こったとき、何が問題なのか、どこで起こっているのか、誰がどうすれば解決できるのか、誰も分からりません。だから、自分が何か重要な知識を持っているかもしれないと、誰もが動員されます。このため、スウォーミングは非常にコストがかかります。仕事は中断され、タスクやミーティングは頓挫し、リソースは有効でない場所に取り残されることになります。ほんの一握りだけが実際に対処できるインシデントへの対応のために、本来は障害にならない範囲で作業を続けて適切なアップデートを受け取れるはずの何百人もの人が動員されてしまうかもしれません。
スウォーミングアップも大変です。多くのレスポンダーがいる大規模な通報は、騒がしくて混乱することがあります。スウォーミングは、明確な調整や責任の所在が不明確なため、インシデントの復旧プロセスを遅らせることになります。中央の組織や意思決定権がない中で、あらゆる方向から情報が入ってきます。チームは、他のサービスへの影響を十分に理解しないまま、自分たちのサービスを復旧させようとするかもしれません。スウォーミングアップは、私たちがインシデントコマンドを明示的に実践している理由の一つです。混乱を減らし、事態を悪化させることなく、できるだけ早くインシデントを解決するためです。
スウォーミングは、自分たちのシステムが影響を受けていると判断された時点で人員を投入するのではなく、最初の警告からインシデントコールに必要な人員を常に配置できるとチームが考えているため、安心感があります。オンコール体制を改善することで、復旧に人員を割けないのではないかという不安を取り除くことができます。オンコールのローテーションを明確にし、責任分担を決めておくことは、いつオンコールの連絡が来るか分からないと心配するよりも、レスポンダーのストレスが軽減されるのです。レスポンダーは、特定の日や時間帯にオンコールシフトがあることを知っていれば、前もって計画を立てることができます。群発シナリオでは、必要な人材が不在になる可能性があります。彼らは24時間365日オンコールで対応できるわけではありません。
スウォームからの移行
スウォーミングからプロセスを改善するには、サービスとそれを所有するチームについてのチームの考え方を変える必要があります。PagerDutyでは、この実践を「フルサービスオーナーシップ」と呼んでおり、これについてはOpsガイドで詳しく説明しています。連携したインシデント対応という文脈では、サービスの所有権はいくつかのことを意味します。
- 1つのチームが、本番環境でのパフォーマンスを含め、そのサービスに対する全責任を持っている。
- そのチームには、そのサービスに関する問題が通知されるための文書化されたプロセスがある。一般に、これはオンコールスケジュール。
- そのサービスが消費する依存関係が文書化されている。
あなたの組織には、現在、明確なオーナーがいないサービスがあるかもしれません。それらは、もはや積極的な開発や注意を払う必要のない成熟したプロジェクトやレガシープロジェクトかもしれません。ベンダーと共同で保守している“棚から出してすぐ使える商品”（COTS製品）、SaaSソリューション、あるいは組織の変更で孤立した内部サービスかもしれません。サービスが本番環境の中にある場合は、ベンダーのアップデートを受信するためにチームの電子メールエイリアスを登録するだけでも、サービスを監視するチームを作る必要があります。あなたの環境で稼働している全てのサービスには、明確に責任を負うチームが必要です。これらのサービスは、インシデントに巻き込まれたり、セキュリティー更新などの作業を必要としたりする可能性がまだあります。組織によっては、レガシーエンジニアリングチームやプラットフォームエンジニアリングチームが、これらのサービスの責任者になっている場合もあります。
サービスを１つのチームに割り当てることで、環境内で誰が何を所有するのかに関する混乱を減らせます。チームは、自分が所有するサービスについて新しいメンバーを教育し、最も影響力のあるサービスのSLOに管理できます。サービスディレクトリーを作り、誰に通知すべきかを記載したチームのオーナーシップの構造を補うことで、組織内の全員に、問題が発生したときに相談できるリソースを提供するできます。PagerDutyでは、チームとエスカレーションポリシーをサービスに添付することで、これを実現しています。
エスカレーションポリシーは、サービス上のインシデントに対応するために、誰が利用可能だと期待されるかのガイドラインを設定します。この場合のレスポンダーは、影響を受けるサービスに精通し、問題のトリアージと修正を行うための適切なアクセス権を持つ人物であるべきです。
明確な依存関係モデルは、サービス間の関係を確立し、レスポンダー、サポート、ステークホルダーが、あるサービスでの事故が環境内の他のサービスにどのような影響を与えるかについて明確に把握できるようにします。PagerDutyはさらに一歩進んで、ビジネスサービスを提供し、技術サービスを互いにリンクさせるだけでなく、それらが貢献する顧客向け機能にもリンクさせます。全ての技術サービスとビジネスサービスは、サービスグラフに表示され、そのサービスのために現在オンコールしているチームメンバーへの便利なリンクも表示されます。
このインフラデータ（特に依存関係モデル）を構築することは、あるサービスに対して最新の状態に保たれていない場合、多くの労力を要することになります。しかし、バックエンドのサービスに対するインシデントの影響を完全に把握することは、その問題が発生しているサービスを消費している他のサービスが分からなければ不可能です。
カスタマーサポートチームも、この作業から利益を得ることができます。インテリジェントスウォーミングは、サポートチームがこれらの情報を全て手元に置いておけるかどうかにかかっています。顧客が解決策を必要とするとき、チームは全ての正しい情報を見つけ、適切な人材を動員できなければなりません。
インシデントコミュニケーションの改善
インシデント対応は、観客を楽しませるスポーツではありません。チェックやプロセスの実行を待ち、エラーメッセージを追跡し、再起動を待つ時間が長くなることがあります。この作業が行われている間は、あまり変化がありません。しかし、これらの作業が進行している間でも、修復に直接関与していない人々は、何が起こっているのかを知りたがります。強力なインシデントコミュニケーションプランがないことも、チームがスウォーミングに頼る理由の一つです。もし誰かが何が起こっているのか知りたければ、解決にどんなに時間がかかっても、コールに参加して聞くしかないのです。
重要なインシデントのための強力なコミュニケーションプランをあらかじめ決めておくことは、内部ユーザーが何が起こっているのかを常に把握できるようにすることと、外部ユーザーに情報を提供することの２つの機能を備えています。インシデント対応ガイドでは、インシデント発生時のコミュニケーションについて、「顧客リエゾン」と「社内リエゾン」いう２つの役割を明記しています。この２つのグループには、それぞれ異なるアップデートを行うことが予想されます。組織によっては、インシデントについて公表する内容を検討したり、特定の表現を使ったりする必要があります。そのため、テンプレートを作成し、特定のチームメンバーをコミュニケーション担当として任命することで、この作業を容易にします。社内向けには、他のチームが自分たちのサービスに影響があるかどうかを判断できるように、より詳細な情報を提供することになるでしょう。
最良の計画は、全てのステークホルダーに定期的に情報を提供することを前提にしています。早めに、そして頻繁にコミュニケーションすることで、状況が改善され、問題が解決されたときに、全員に知らせることができます。
NOCで群れる必要はない
第一線のレスポンダーが総合的な担当をするNOCチームである場合、最新のインシデント対応モデルに移行できます。サービスオーナーシップを明確にしていれば、NOCがインシデントを解決できない場合、複雑な問題をサービスチームにエスカレーションできます。サービスAを担当するチームのオンコール中のレスポンダーを呼び出すことは、組織全体からさまざまな人を集めるよりもはるかに簡単です。
まとめ
対応方法を近代化することで、組織の時間とリソースを節約できます。SAPのようなPagerDutyの顧客は、必要なときに必要なレスポンダーだけを動員し、最も効果的な対応を提供することに集中できるという利点を享受しています。
もし、あなたのチームが解決までの時間を短縮し、大規模なスウォームコールの必要を抑制する方法をお探しなら、当社のインシデントレスポンス運用ガイドのリソースをご覧ください。フルサービスオーナーシップを実現するために必要なことは何でしょうか？当社のビデオをご覧になり、コミュニティーフォーラムで同じ考えを持つ人々と話し合ってみてください。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カテゴリー ：ベストプラクティス
