Blog
ブログ

メールアラートを改善したいですか？ もう一度考えてみましょう

監視システムは、稼働中のシステムをより効果的に管理するのに役立ちます。しかし、早期に問題を特定するためにチェックとしきい値を設定するのに多くの時間を費やしたとしても、アラート自体にはインシデント対応プロセスと同じくらいの意味しかありません。 PagerDutyがお客様の声を聞いてきた中で発見した最大の課題の1つは、どのお客様もメールアラートに悩まされているということです。 受信トレイがぐちゃぐちゃになって大切なものを見逃してしまいがちだと気づいていながらもなお、多くの監視システムとIT運用チームはメールアラートに依存しています。 メールアラートを改善しようとしていますか？ もう一度考えみてください。それでもまだこのまま使い続けようとお考えのあなたに、メールによるアラートをやめてしまった方がいい理由を5つお教えしましょう。

1. メールアラートは見過ごされやすぎる

「ねえ、友達が私にメールで送った最新の猫のビデオを見ましたか？」

受信トレイを常に見ていても、重大なアラートが他のアラートや仕事関連のメールに紛れてしまうのは日常茶飯事です。 このため、優れたオペレーションチームは、通常、少なくとも2つの通知チャネルを使用します。ひとつは、電話またはSMSメッセージです。 音でアラートを知らせることは間違いなく気づくのに役立ちます。

2. メールで誰かを確実にアサインすることはできません

「えーと、この件誰か対応してる？」

深刻なインシデントへの対応では時間が重要であり、チームの誰が対応に当たることになるのかで混乱している場合ではありません。アラートが複数の人にメールで送信されている場合、チームの誰が最初に応答するかを知る方法はありません。 他の誰かが既にそのメールを見て対応しているのか、自分はそのアラートに対応するのに最も相応しいのか、それとももっと経験豊富な人を待つべきだろうか。 優秀なオペレーションチームは、各インシデントが最適な担当者に自動的に割り当てられるようにします。 インシデント管理ツールとチケットシステムは、オンコールのエンジニアを自動的に割り当て、割り当てたエンジニアのステータスを追跡することにより、このワークフローを実行させます。

PagerDutyではオンコールのスケジュールに従い、すぐに対応に当たる人を決定してインシデントを割り当てます。

3. メールを集約またはバンドルすることはできません。

「これ、止められないのか？」

アラートの嵐が吹き荒れる。スタッフが対応を誤ると、すべての監視システムが毎分何度もアラートを送信します。膨大なアラートは受信トレイをたちまちあふれさせて、事実上使用できなくなります。 PagerDutyでは単一インシデントのアラートは1つに集約し、複数インシデントのアラートは、それぞれの最初の通知の後にまとめて通知します。したがって担当者が受け取るアラートは一度だけです。また、ダッシュボードにより現在進行中のインシデントの数とその出所を簡単に把握することもできます。

4. メールは状況を可視化してくれません

「現在のステータスはどうなってるんだ？」

メールでは、誰がインシデントに対処しているのか、経過時間、最新の状況の把握などは難しいです。この情報はチームだけでなく、経営幹部やその他のビジネス関係者にも重要です。あなたが対応している最中に、状況を知りたい人々に絶えず質問されるのも迷惑です。インシデントをPagerDutyのようなシステムに取り込むことで、管理者だけでなくチーム全員がアクセスできる単一のダッシュボードですべての情報を取得できます。 CEOやCTOがこれで問い合わせを控えてくれるとは限りませんが、少なくとも自分で情報を入手できる方法を伝えることはできます。

5. メールアラートでメトリクスを作成することはできません

「僕ら、うまくやれてる？」

優れたオペレーションチームは、パフォーマンスを継続的に測定、評価、改善するためにメトリクストラッキングを採用しています。全てのメトリクスをメールからトラッキングすることは非常に困難です。インシデントが発生した時刻、最初の人が気付いて応答するまでの時間、チームが解決するまでの時間などをトラッキングすることは、完了予想時刻を管理する上で大切になってきます。このデータを使用して作成したチームのパフォーマンスを示すダッシュボードと週ごとのレポートで、チームや企業内のコミュニケーションを容易にすることができます。

メールアラートの問題は、今まさにあなたが直面している課題かもしれませんが、それはあなただけの問題ではありません。

あなたは解決不可能なチケットを受け取ったことがありますか？Stack Overflowを隅から隅までじっくり読み、時には机に顔を打ち付けながらGoogleで何時間も過ごす。 4時間が過ぎたあたりから問題を解決することはプライドの問題になってきます。生産性は最低！ こんな時こそ、あなたの正気を保つために効果的なインシデント管理プロセスが必要です。

誤解しないでください。他の誰も巻き込まずに解決したいというお気持ちは分かります。うぬぼれだったり羞恥心だったり、はたまた純粋に誰にも迷惑をかけたくなかったり、私もいつもそんな感じですから。 私の場合は問題解決偏愛症のようなものですが、こと自分のプロジェクトの健全さとなると、規定のプロセスに従った方が皆ハッピーになれるようです。

優先順位をつける

いくつかの問題は本物であり、あるものはそうではありません。 すべての問題がミッションクリティカルなわけではないので、チケットがあなたに回ってきたとき、最初のステップはそれがスタックのどこにあるかを決定することです。 あなたとチームメンバーが管理している他のバグやもろもろの要素の中にその場所を見つける必要があります。 詳細なインパクトレポートを作成し、関連するプロジェクトマネージャーたちに相談して決定を導きます。

再現

再現可能なバグは修正可能なバグです。 優先度の高い問題がキューの一番上に達すると、次のステップはそれを再現するステップをコンパイルすることです。 ユーザーが誤ってクラッシュを引き起こしていますか？ たぶんそれはメモリまたはストレージの問題です。 重要なことは、あなたがやろうとしているのは、どうすれば問題を再現できるのかを理解することで、解決法ではないということです。 いったんそれを再現することができれば（または容易に再現できないことを知ると）、修正することができます。

エスカレーション

問題を再現できるようになると、次のステップは適切な専門家を特定することです（ヒント：それはあなたかもしれません）。 問題の性質に応じて、誰の肩を叩くのかを知るのは難しいかもしれませんが、実際にその特定の機能について最後に作業した人に尋ねるのがよいでしょう。 誰に問題をエスカレーションするかにかかわらず、これまでに学習したすべての詳細なレポートを必ず含めてください。 感謝してもらえますよ。

調査

さて、これで問題は少しは見えてきて、あなたの作業リストに入ることになりました。 次のステップは、問題を調査することです。 これは、問題を再現し、ログを収集し、その分野の専門家に質問し、起こり得る問題を特定し、ソリューションをテストします。 何が起こっているのか、なぜ起こっているのかを正確に知るまで繰り返します。

回復

ここまできたら、問題の内容、再現方法、原因を正確に把握していることでしょう。 根本的な原因を特定し、テスト済みで実用的な修正を行っています。 次のステップは修正プログラムを導入することであることは明らかですが、ここで停止することはできません。 問題が解決してすべてが安定したら、問題が修正されたことをすべての関係者に通知する必要があります。 また、ソリューションの詳細を関連する専門家に伝え、必要に応じて、何が起こったのか、どのように解決されたのかを誰もが理解できるように解析しておくことも重要です。

効果的なインシデント管理は、確立されたプロセスと適切なコミュニケーション次第です。 実際の手順はプロジェクトごとに変わる可能性がありますが、問題を最も効果的に軽減するチームは大きなコミュニケーションをとり、必要となる前に計画を立てるものなのです。

「インシデント管理」と聞くと、ITプロフェッショナルがバックエンドシステムを管理していると考えるかもしれません。おそらくカスタマーサポートチームは自分たちとは関係ないと考えていることでしょう。

ですが実際のところ、カスタマーサポートチームもインシデント管理から多くの利益を得ることができるのです。

顧客を幸せにする

ほとんどすべてのIT専門職は、カスタマーサポートに回ってくるようなことがらは一般的に良くないことだと考えているでしょう。私たちは顧客に技術サポートに頼るような経験をさせたくはありません。カスタマーサポートを提供することに直接的なコストが伴うだけでなく、こういった経験をした顧客は将来的に顧客でなくなる可能性が高まるからです。

結論は、顧客を満足させることが重要であるということです。満足した顧客は、あなたの会社との経験を何人かの友人に伝えてくれるかもしれません。怒っている顧客は、自分のTwitterフォロワーに体験をシェアしたり、中には消費者庁に駆け込むようなこともあるかもしれません。

では、カスタマーサポートとインシデント管理はどんな関係があるでしょうか。その性質上、カスタマーサポートは受け身の機能です。通常、顧客は問題に突き当たるとテクニカルサポートに電話を掛け、テクニカルサポート部門は顧客の苦情に対応することになります。インシデント管理も同様に受け身なものですが、予防的な対応も可能です。適切な監視ソリューションを使用することで小さな問題を解決して、チームをより大きな問題の解決に向かわせることができます。これにより、サポートコールが少なくなり、顧客満足度の向上にダイレクトにつながります。

積極的なインシデント管理を通じてサポートコールを削減するという考えは魅力的ですが、インシデント管理計画が適切に実装されている場合にのみ有効です。重大ではなかったり重複している警告は抑止し、より緊急な問題のアラートを発信することで、ソフトウェアはIT担当者の大きな助けになります。しかし、最終的には、インシデント管理プログラムの成功は、問題が発生したときに決定的な行動をとるITスタッフの能力に左右されます。

担当者を呼び出せることの重要性

インシデントが迅速に解決されるようにするためのひとつの方法は、発生する可能性のある問題をITスタッフが常に処理できることを確認することです。組織に24時間対応のITスタッフがいない場合は、呼び出し可能なサポートチームを持つ必要があります。これは全員が常にオンコールでなければならないというわけではありません。輪番制のコール対応スケジュールを組めば、ITチームの誰かが常に起こりうる様々なインシデントに対応可能になります。

時間外の緊急事態に対処するためにコール対応スタッフを用意しておくという考えは新しいものではありません。熟練のIT技術者であれば、たいていは週末や非常識な時間に呼び出された経験が一度や二度はあると思います。

ほとんどのITサービスは時間外の問題に対処するために誰かを呼び出すことを躊躇しないものですが、関係するすべての人がより無理なく日常生活を送れるようにするためには、いくつかのポイントがあります。

オンコールオペレーションのベストプラクティス

まず、時間外のインシデントでITスタッフにアラートを出すのは、インシデント管理ソフトウェアによって起動される自動プロセスでなければなりません。自動アラートを使用することで、IT担当者は問題を可能な限り迅速に認識することができます。自動プロセスをとっていないと、誰かがインシデントを発見してIT部門に電話をかけてくるまで、ITスタッフはその問題を認識できない可能性があります。その頃には、顧客の側でも問題を経験し始めているかもしれません。

これは別のポイントをもたらします。よほど小さな組織でない限り、1人のオンコール担当ではなく、オンコールチームを用意するのが一般的です。ITは複雑な分野であり、チームの誰もが組織全体で使用されているあらゆるテクノロジーの専門家であることを期待するのは非現実的です。オンコールチームを組織しておくことで、インシデントが発生した場合、問題を解決するために相互補完的なスキルセットを持つ人々のグループを確保することができます。これは、オンコール技術者が何らかの問題が発生したときに、解決に必要なスキルを持つ特定の人を探すより好ましい方法です。輪番制のコールスケジュールは、ある人に常に役割を負わせるのではなく、いつでも問題に対処できるチームが存在することを保証します。

業務時間外に待機するのは決して楽しいことではありませんが、24時間体制で顧客にサービスを提供する企業では、ITの専門知識を年中利用できるようにすることが非常に重要です。顧客は企業の最も貴重な資産であり、企業のブランドは顧客に依存しています。インシデント管理ソリューションを活用する積極的なカスタマーサポートチームは、問題が顧客に悪影響を与えるのを防ぐことができ、より高い顧客満足度につながります。

オンコール状態を保つことは難しく、時にそれは受け入れがたい負担となります。しかし、規制業界 （国の規制により 新規参入や事業拡大が制限されている業界）で働く場合、組織に課せられるインシデント管理への要求は日増しに増大しています。この記事では、規制業界におけるソフトウェア関連のインシデント管理の基本原則について説明したいと思います。

インシデント、規制、コンプライアンス

まず、ソフトウェア関連のインシデントが規制業界で何を意味するのかを簡単におさらいしてみましょう。ソフトウェア開発やIT部門の担当に「インシデント」とは何か定義するように尋ねてみると、大概はダウンタイムやアプリケーションの応答時間の問題に言及するかと思います。しかしこれは、もう一方の重要な要素を見落としている場合があります。それはセキュリティー – 侵入、データ盗難、機密データ保護の失敗などです。

規制産業での「インシデント」という用語は、ダウンタイムやセキュリティー上の問題をはるかに超えた意味を持ちます。それは、組織またはプロダクト、またはサービスを規制の準拠外に追いやってしまうことを意味します。

水道会社にとっての問題を例に挙げると、給水中に大腸菌が入り込んでしまった場合がそれにあたります。銀行でいえば顧客の財務データが失われた場合、病院にとっていえば生命維持システムの重大な欠陥があった場合です。規制遵守が危機に瀕している場合、公共の安全や重大なデータ損失、主要サービスの中断などの事故は、ダウンタイムを伴うものほど深刻になるものです。

コンプライアンス – Stakesとは何か

規制業界に属する組織にとって最も根本的な問題の1つは、適用される規制を遵守する必要があるということです。業界およびインシデントの性質によってコンプライアンスの違反が発生する可能性があります。

罰金、手数料、またはその他の民事上または行政上の罰金 インシデントの影響を受ける組織または個人による訴訟またはその他の訴訟 業界内での作業に必要なライセンスまたはその他の証明書の保留または紛失 業界内または一般の人々の目にある評判の喪失 極端な場合には、責任ある個人の刑事告発、有罪判決、懲役刑

言い換えれば、Stakes（危険度）は非常に高くなる可能性があります。インシデント管理の手続きを裁判官に説明する状況に陥るのは、非常に望ましくないものです。

必要性とベストプラクティス

このような厳しい条件の下でインシデントをどのように管理すればよいのでしょうか。最高のインシデント管理は、コンプライアンスに関わる問題になる前にすべての潜在的なインシデントを処理するという予防対策です。それは実際の状況下では必ずしも実現できないため、法的要件と実用的必要性の両方を満たすインシデント対応計画を立てることが重要です。これを行うには、次の要因を考慮する必要があります。

規制要件とガイドライン イン**シデント管理、予防、対応に関しては、規制当局の要求事項に常に従ってください。これらは業界および関連機関によって異なりますが、大抵は正式なインシデント対応計画、ITインシデント対応チーム、インシデント対応手順およびアクションの正式文書が含まれます。 例えば、HIPAA（Health Insurance Portability and Accountability Act ）またはPCIDSS（Payment Card Industry Data Security Standard）の下で運用されている組織には、文書化されたセキュリティレスポンスプランとレスポンスチームが必要です。連邦情報セキュリティ管理法（FISMA) には同様に、連邦機関に対する詳細な事故管理および対応ガイドラインが含まれています。不明点がある場合は組織が対象とする機関と要件を確認し、すべての要件を完全に遵守しているか確認するべきです。 業界ガイドラインとベストプラクティス これらは業界によって異なります。業界全体の専門組織は多くの場合、一連の推奨プラクティスを提供しています。業界に特定のガイドラインがない場合、Common CriteriaおよびCommon Evaluation Methodのドキュメントは、一般的なITセキュリティおよび公衆安全の問題を理解するための有用なフレームワークを提供しています。

一般的な考慮事項

すべての規制産業およびすべての規制の枠組みに適用される基本的な考慮事項がいくつかあります。

識別

障害やその他の誤動作が直接的または間接的にコンプライアンスの問題につながる可能性のある機密システム（アプリケーション、ネットワーク、サービスなど）をすべて特定します。例えば、クライアントの医療記録を含むデータベース、または公益事業のための電力配分を管理するプログラムは、この項目に該当する可能性が高いです。尚、簿記ソフトウェアはこの文脈ではおそらく重要なシステムに該当しません。

プリベンション

インシデント管理の最新トレンドは、システム障害を未然に防ぐことです。つまり、システムの障害だけでなく、障害につながる可能性のある状態についてインシデント対応チームにあらかじめアラートを出す必要があります。セキュリティーに敏感なシステムの場合は侵入を試みる活動やセキュリティーソフトウェア自体のパフォーマンスの低下を示唆する活動である可能性を探る必要があります。公共安全が危機に瀕しているシステムでは、主要メトリックの異常な動作を探る必要があります。言うまでもなく、プリベンションにはデータのフルバックアップ、必要に応じてスタンバイ状態のフルバックアップシステムが含まれます。

問題がコンプライアンスに関わる問題に変わる前に問題を把握するには、インシデント対応チームが完全に同期している必要があります。このような状況では秒単位での対応が重要です。このため、対応担当者を事前に定義してエスカレーションポリシーを明確にし、複数のシステムからのメトリクスへのアクセスを統合して問題を統一的に把握することが不可欠です。

プライオリティ

事実上、既存のインシデント管理のトリアージ（行動順位決定）に別レベルの優先度を追加し、すべてのコンプライアンス関連のインシデントを既存の優先度よりもさらに優先させる必要があります。例えば、簿記システムと在庫システムの両方がクラッシュし、同時に医療記録データベースが天気予報のように不安定になった場合、もし対応できるITスタッフが十分にいなかったとしても、会計担当者と倉庫担当者は緊急チームがデータベースに対応するまで待つ必要があります。また、公共安全に関与している場合は、重大な災害が発生した直後に、重大なシステムを運用する準備ができている必要があります。

これらはとても恐ろしいことのように聞こえるかもしれません。規制当局や裁判官が規制を適切に遵守しなかったと判断した場合、企業が大きなインシデントに対して費やさなければなければならない費用ははるかに高くつく可能性があります。結論として予防的なインシデント管理は、企業にとって自身を守る最高の防衛手段となるはずです。

インシデント対応のプロセスやワークフローを改善するためのリソースを探している場合は、オープンソースのインシデント対応文書と金融サービスソリューションの要約を参照して、PagerDutyがどのように規制対象産業を支援しているか確認してみてください。

※このコンテンツはwww.pagerduty.com/blog/の抄訳です。

ビジネスは事実上ソフトウェアの上で行われるので、デジタルエクスペリエンス の質は組織の成功を左右します。 だからこそ、組織はデジタルの問題を解決するためにビジネス全体のスタッフ全員を動員するのですが、それは数時間、数分ではなく、数秒で動員しなければなりません。

そのため、PagerDuty Summit 2017では、これらのニーズを満たすまったく新しいエキサイティングなプロダクトイノベーションを発表しました。アプリケーションの学習、エンドツーエンドのレスポンスの自動化、およびリアルタイムでビジネス全体の人員動員を統合する新しい機能により、最も重要な場面での非効率をなくし、ビジネスがイノベーションに立ち戻ることに貢献します。

クイックツアーで新しい機能をすべてチェックしてみましょう。

レスポンダー向け：インテリジェントでリアルタイムな意思決定支援

インシデント発生時の不安の最大の原因の1つは、起こっていることを診断するための適切な情報の入手方法を知らないことです。 インフラストラクチャの複雑さとシステムデータの圧倒的な増加は、これをさらに困難にしています。 アラートグループ化、類似のインシデント、及び新しいユーザーエクスペリエンスを備えたPagerDutyは、インシデント発生時、必要な時に正確に提供するシステムとアサインの仕組みをインテリジェントに搭載しています。

アラートのグループ化

問題を冷静に分析しようとしている時に望むことは、電話通知が鳴り続けないようにすることです。 今回、ルールベースの自動化と機械学習によって、関連するアラートが1つのインシデントに自動的にグループ化されるので、レスポンダーは集中的にコンテキストを取得し、問題をトリアージし、応答を開始することができるようになります。

Similar Incidents

マシンデータはインシデントのトリアージ処理を開始する際の中心となりますが、全体像を把握するためには同様の問題を誰が処理したのか、それを解決するためにどのような手順を取ったのかなど、人的情報が必要です。 Similar Incidentsにより、レスポンダーはインシデント優先順位、影響、修復手順など、以前の関連する問題と概要を確認することができます。

ライブインシデントページの再設計

インシデントの影響が大きく、レスポンスが複雑になるにつれ、進行中のすべての状況を把握することが難しくなります。 新しいインシデントページでは、プラットフォーム全体のユーザーエクスペリエンスが大幅に改善されましたた。新しいインシデントページでは、フレッシュなデザイン、リアルタイムの更新、および改善された情報アーキテクチャーによってさらに使いやすさが向上しています。 レスポンダーに対するメリットは、探している情報が容易に発見でき、何が起きているのか最新の見解を常に確認できる点です。 この新しいエクスペリエンスは現在のすべてのプランで利用が可能です。 インシデントが発生した場合、画面の下部にある「Try Something New!」ボタンをクリックしてみてください。

レスポンスチームとツールチェーンオーナーのために：自動精密応答

1分ごとに数千ドルを喪失するようなビジネスを繰り広げている中で、できるだけ迅速にサービスを回復させることが最優先事項となります。 すなわち、可能な限りすべて自動化することで、チームは誰がページを見ているかを調べることなく、問題の解決に集中できるようになります。 新しいイベントとインシデントの自動化により、PagerDutyでのインシデント対応はこれまで以上に高速で、簡単で、正確です。

レスポンスオートメーション

イベントルーティング

複数の場所でビジネスロジックを管理するのは煩わしくて非効率的なだけではなく、可視性が低下し、構成エラーのリスクも高まります。 高度に要求されたイベント管理機能であるイベントルーティングにより、すべてのイベントをPagerDutyに送信し、イベントのペイロードに基づき問題を異なるチームやサービスに自動的にルーティングできます。PagerDutyで定義されたすべてのイベントの自動化により、特定のイベントがどのように処理されるのか一目瞭然です。

Dynamic Notifications

真夜中に目を覚ます必要はありません。異なるイベントではさまざまなレベルの対応が必要ですが、先月リリースされたすべてのスタンダード以上のプランでDynamic Notificationsが利用可能で、イベントデータが通知やエスカレーションに変換される方法をカスタマイズできます。 これにより、大量のアラートによる疲れを減らし、重複したサービスを少なくし、レスポンダーの負荷を軽減します。

組織全体のために：ビジネス全体のオーケストレーションプラクティス

主要なインシデント対応にはITレスポンダーだけでなく、顧客との関係を管理してブランドの評判を保護するために積極的な対策を講じる必要があるなど、ビジネス全体のステークホルダーとの調整も含まれています。 レスポンスは、サポート、カスタマーサクセス、法律やマーケティングなど、さまざまな部門に及んでいます。顧客のエクスペリエンスを保護するという統一目標に、すべてのスタッフを集中させる必要があるからです。

そのため、オープンソースのインシデントレスポンスドキュメンテーションを技術的なレスポンス以上のものに拡張しました 。 これによリ、何千もの最高のオペレーションチームのベストプラクティスに基づくインシデント対応の究極のガイドを活用し、サービスの中断が発生した場合に組織がどのように動くべきかを学ぶことができます。 さらに過去数週間にわたり、PagerDutyのリーダーたちは、 カスタマーサクセスから企業のコミュニケーション方法まで、私たちが日々の仕事でどのようにレスポンスに取り組んでいるか、独自の視点を共有しています。

新しいものを確認する

PagerDutyプラットフォームの最新機能の概要を楽しんでいただければ幸いです。 Dynamic Notifications、新しいインシデントページ、および更新されたレスポンスドキュメントは現在入手可能です。他の機能を誰よりも先に試したい場合は、 こちらからご連絡ください。

※このコンテンツは www.pagerduty.com/blog/の抄訳です。

ConfigurationからScheduleを選択します。

「New On-Call Schedule」で新しいスケジュールを追加できます。

まず、 「Time zone」を日本に設定して、Layerを追加していきます。

レイヤーを順番に設定していきます。

レイヤー１では、1人の担当者が日中の時間帯に交互に担当するよう設定してみました。

レイヤー２では、それ以外の時間帯を2名で設定してみました。

最終的なスケジュールは、以下になりました。

簡単なUI操作だけで、柔軟なスケジュール設定ができますね。

また、スケジュールのOverride機能を使うと例外的なスケジュールも組み込むことができるので、非常に便利です。