BLOG
インシデントレスポンスの向上には、(非インテリジェントな)スウォームをコントロールすることが必要です。

投稿:2022年7月18日   |    更新:2022年7月18日

事件が起こる。物事がうまくいかない。システムが故障する。時には、予期しない劇的な方法で失敗し、重大な事故が発生することもあります。PagerDutyは、インシデントとインシデントを非常に明確に区別しています。あなたの組織でもそのような区別をしているかもしれません。

インシデントが重大かどうかの判断は、影響を受けるサービスの数、顧客への影響、インシデントの期間など、多くの要因、または特定の要因の組み合わせによって決まります。

これらの要素には、少なくともベースラインの遠隔測定と、技術エコシステムを構成するサービス間の関係性の把握が必要です。このベースラインがなければ、インシデントのトリアージにおいて、実際の影響やどこから手をつければよいかを知ることは困難です。

重要なデータがない場合、どうなるのでしょうか?次のようなデータがないと、インシデントに対応するのが難しくなります。

  • どのサービスが影響を受けるのか?
  • どのサービスにどの程度の影響があるのか?
  • そのサービスの所有者は誰ですか?

このようなデータがない場合、インシデント対応にスウォームアプローチを選択する組織もあります。

スワーミングとインテリジェントスワーミングの比較

スワーミングとは、組織内の全員に問題が発生したことを知らせ、問題解決に貢献できる可能性の有無にかかわらず、全員が参加できる大規模なウォー・ルームや電話会議を開くインシデント対応のアプローチです。インシデントの影響を軽減するためには、適切な人材を適切なタイミングで動員することが極めて重要です。スウォーミングは、適切な人が適切な時間に適切な場所にいることとは正反対で、全員がずっと参加することです。

インテリジェントスワーミングという言葉は、今月初めにお話しした、特にVIP向けの接客対応ワークフローを指す言葉として使われています。これはやや異なるアプローチで、最初にケースを拾ったチームメンバーが解決まで見届けることを指定し、問題解決を支援するために組織内のリソースを引き込む能力を持つものである。一般的なレスポンススウォームと関連しますが、インテリジェントスウォームの焦点は通常、単一の顧客であり、その体験を中心に据えることです。

一般的なテクニカルインシデント対応のためのスウォームは、建物の火災報知器のように、全員が厳戒態勢で、対応することが期待されています。基本的には、何らかの知識を持つ可能性のある人すべてにアラートが送信され、インシデントに参加するよう求められ、その後、誰がトリアージと修復を行えるかを見極める手間のかかるプロセスが開始されます。

組織はしばしば、自社のサービスやエコシステムについて十分な情報を持っていなかったり、利害関係者に情報を提供するための強力なコミュニケーション手段を持ち合わせていないために、群れをなしてしまうことがあります。何かが起こったとき、何が問題なのか、どこで起こっているのか、誰がどうすれば解決できるのか、誰もわからない。だから、自分が何か重要な知識を持っているかもしれないと、誰もが動員される。このため、スウォーミングは非常にコストがかかる。仕事は中断され、タスクやミーティングは頓挫し、リソースは有効でない場所に取り残されることになります。何百人もの人が、実際に対処できるのはほんの一握りである事故への対応のために動員されるかもしれない。むしろ、支障なく仕事を続け、適切なアップデートを受け取ることができるかもしれないのだ。

スウォーミングアップも大変です。多くの応答者がいる大規模な通報は、騒がしくて混乱することがあります。スウォーミングは、明確な調整や責任の所在が不明確なため、インシデントの復旧プロセスを遅らせることになります。中央の組織や意思決定権がない中で、あらゆる方向から情報が入ってきます。チームは、他のサービスへの影響を十分に理解しないまま、自分たちのサービスを復旧させようとするかもしれません。 スウォーミングアップは、私たちがインシデントコマンドを明示的に実践している理由の一つです。混乱を減らし、事態を悪化させることなく、できるだけ早くインシデントを解決するためです。

スワーミングは、自分たちのシステムが影響を受けていると判断された時点で人員を投入するのではなく、最初の警告からインシデントコールに必要な人員を常に配置できるとチームが考えているため、安心感があります。オンコール体制を改善することで、復旧に人員を割けないのではないかという不安を取り除くことができます。オンコールのローテーションを明確にし、責任分担を決めておくことは、いつオールコール・ページが来るかわからないと心配するよりも、対応者のストレスが軽減されるのです。応答者は、特定の日や時間帯にオンコール・シフトがあることを知っていれば、前もって計画を立てることができます。群発シナリオでは、必要な人材が不在になる可能性があります - 彼らは24時間365日オンコールで対応できるわけではありません。

スウォームからの移行

スウォーミングからプロセスを改善するには、サービスとそれを所有するチームについてのチームの考え方を変える必要があります。PagerDutyでは、この実践を「フルサービスオーナーシップ」と呼んでおり、これについてはOpsガイドで詳しく説明しています。連携したインシデント対応という文脈では、サービスの所有権はいくつかのことを意味します。

  1. 1つのチームが、本番環境でのパフォーマンスを含め、そのサービスに対する全責任を持っている。
  2. そのチームには、そのサービスに関する問題が通知されるための文書化されたプロセスがあります。一般に、これはオンコールスケジュールである。
  3. そのサービスが消費する依存関係が文書化されている。

あなたの組織には、現在、明確な所有者がいないサービスがあるかもしれません。それらは、もはや積極的な開発や注意を払う必要のない成熟したプロジェクトやレガシー・プロジェクトかもしれません。ベンダーと共同で保守している商用オフザシェルフ(COTS)製品、SaaSソリューション、あるいは組織の変更で孤立した内部サービスかもしれません。サービスが本番環境の中にある場合は、ベンダーのアップデートを受信するためにチームの電子メールエイリアスを登録するだけでも、サービスを監視するチームを作る必要があります。あなたの環境で稼働しているすべてのサービスには、明確に責任を負うチームが必要です。これらのサービスは、インシデントに巻き込まれたり、セキュリティ更新などの作業を必要としたりする可能性がまだあります。組織によっては、レガシーエンジニアリングチームやプラットフォームエンジニアリングチームが、これらのサービスの責任者になっている場合もあります。

サービスを1つのチームに割り当てることで、環境内で誰が何を所有するのかに関する混乱を減らすことができます。チームは、自分が所有するサービスについて新しいメンバーを教育し、最も影響力のあるサービスのSLOに管理することができる。サービスディレクトリを作成し、誰に通知すべきかを記載したチームの所有権構造を補完することで、組織内の全員に、問題が発生したときに相談できるリソースを提供することができます。PagerDutyでは、チームエスカレーションポリシーサービスに添付することで、これを実現しています。

エスカレーションポリシーは、サービス上のインシデントに対応するために、誰が利用可能であることが期待されるかのガイドラインを設定します。この場合の対応者は、影響を受けるサービスに精通し、問題のトリアージと修正を行うための適切なアクセス権を持つ人物であるべきです。

明確な依存関係モデルは、サービス間の関係を確立し、対応者、サポート、利害関係者が、あるサービスでの事故が環境内の他のサービスにどのような影響を与えるかについて明確に把握できるようにします。PagerDutyはさらに一歩進んで、ビジネスサービスを提供し、技術サービスを互いにリンクさせるだけでなく、それらが貢献する顧客向け機能にもリンクさせます。すべての技術サービスとビジネスサービスは、サービスグラフに表示され、そのサービスのために現在オンコールしているチームメンバーへの便利なリンクも表示されます。

このインフラデータ(特に依存関係モデル)を構築することは、あるサービスに対して最新の状態に保たれていない場合、多くの労力を要することになります。しかし、バックエンドのサービスに対するインシデントの影響を完全に把握することは、その問題が発生しているサービスを消費している他のサービスが分からなければ不可能です。

カスタマー・サポート・チームも、この作業から利益を得ることができます。インテリジェント・スワーミングは、サポート・チームがこれらの情報をすべて手元に置いておけるかどうかにかかっています。顧客が解決策を必要とするとき、チームはすべての正しい情報を見つけ、適切な人材を動員することができなければなりません。

インシデントコミュニケーションの改善

インシデントレスポンスは、観客を楽しませるスポーツではありません。チェックやプロセスの実行を待ち、エラーメッセージを追跡し、再起動を待つ時間が長くなることがあります。この作業が行われている間は、あまり変化がありません。しかし、これらの作業が進行している間でも、修復に直接関与していない人々は、何が起こっているのかを知りたがります。強力なインシデント・コミュニケーション・プランがないことも、チームがスウォーミングに頼る理由の一つです。もし誰かが何が起こっているのか知りたければ、解決にどんなに時間がかかっても、通話に参加して聞くしかないのです。

重要なインシデントのための強力なコミュニケーション・プランをあらかじめ決めておくことは、内部ユーザーが何が起こっているのかを常に把握できるようにすることと、外部ユーザーに情報を提供することの2つの機能を備えています。インシデント対応ガイドでは、インシデント発生時のコミュニケーションについて、「顧客リエゾン」と「社内リエゾン」という2つの役割を明記しています。この2つのグループには、それぞれ異なるアップデートを行うことが予想されます。組織によっては、インシデントについて公表する内容を検討したり、特定の表現を使用したりする必要があります。そのため、テンプレートを作成し、特定のチームメンバーをコミュニケーション担当として任命することで、この作業を容易にします。社内向けには、他のチームが自分たちのサービスに影響があるかどうかを判断できるように、より詳細な情報を提供することになるでしょう。

最良の計画は、すべての利害関係者に定期的に情報を提供することに基づいています。早めに、そして頻繁にコミュニケーションをとることで、状況が改善され、問題が解決されたときに、全員に知らせることができます。

NOCで群れる必要はない

第一線の対応者が汎用的なNOCチームである場合、最新のインシデント対応モデルに移行することが可能です。明示的なサービス所有権は、NOCがインシデントを解決できない場合、複雑な問題をサービス・チームにエスカレーションできることを意味します。サービスAを所有するチームのオンコール対応者を呼び出すことは、組織全体からさまざまな人を集めるよりもはるかに簡単です。

概要

対応方法を近代化することで、組織の時間とリソースを節約することができます。SAPのようなPagerDutyの顧客は、必要なときに必要な応答者だけを動員し、最も効果的な対応を提供することに集中できるという利点を享受しています。

もし、あなたのチームが解決までの時間を短縮し、大規模なスウォームコールの必要性を制限する方法をお探しなら、当社のインシデントレスポンス運用ガイドのリソースをご覧ください。フルサービスオーナーシップを実現するために必要なことは何でしょうか?当社のビデオをご覧になり、コミュニティ・フォーラムで同じ考えを持つ人々と話し合ってみてください。

この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

book-markカテゴリー :ベストプラクティス
book-markタグ: