Category
インシデント&アラート

2022年11月22日  (更新日:2022年11月24日)

PagerDutyの新しいIncident Workflowsを深堀りする

新興企業であろうとFortune500社であろうと、コストの最適化、ツールの統合、効率化の努力は最優先事項です。インシデント対応プロセスで労力を省き、自動化を進めることは、解決までの時間を短縮するだけでなく、チームの効率化にも役立ちます。リソースが限られた世界では、開発者と対応者の時間と集中力を守ることが、総運用コストの削減とカスタマーエクスペリエンスの最適化に欠かせません。

今月初め、PagerDutyは、お客様がチームの効率と生産性を向上させるためのいくつかの製品の進化を発表しました。その中でも最も期待されているのが、インシデント対応を自動化するIncident Workflowsの導入です。この機能は、本日よりEarly Accessのお客様を対象に提供を開始します。

インシデント対応プロセスにおける全ての手動ステップを考えてみてください。複数のチームに影響を与える優先度の高いインシデントは、できるだけ早く問題を解決するために総力を挙げて取り組む必要があるため、混乱が生じる可能性があります。ただでさえストレスの多いプロセスに、毎回X,Y,Zを確実に実行することを念頭に置いていると、さらに大きな負担がかかってしまいます。このような繰り返しの多い手作業は、自動化するのに最適な候補となります。

自動化によってインシデント対応の労力を減らし、定型タスクを処理できれば、チームはより迅速に問題の特定と解決に集中できます。そして、インシデントを迅速に解決できればできるほど、新しい製品やサービスの構築に早く戻ることができるようになります。

Incident Workflowsは、インシデントの種類に応じて、必要なアクションを自動的に編成します。Response Playsからのアップグレードとして、カスタマイズ可能なインシデントワークフローをノーコード/ローコードビルダーで作成できるようになり、あらゆるユースケースに対して適切なインシデント対応をエスカレーション、動員、調整するためのマニュアル作業が軽減されるようになりました。レスポンダーの追加、関係者の登録、コンファレンスブリッジの起動など、一般的なインシデントアクションをシーケンス化し、IFTTTロジックを使用して自動的に組織化された対応をトリガーできます。

(訳注:原文ではここでインシデント発生時にSlack上にチャネルを作り必要なメンバーを参加させるといったワークフローを設定するショートデモ動画を紹介しています。次のリンクでそのショートデモを見られます。 PagerDuty Incident Workflowsの紹介 )

ここでは、Incident Workflowsを強力にする機能を詳しく見ていきましょう。

条件付きトリガー

インシデントの種類が異なれば、必要な改善手順も異なります。条件付きトリガーを使用すると、緊急度、優先度、ステータスの変更など、特定のインシデントフィールドの基準が満たされたときにワークフローを開始するロジックを作成し、これらのニーズに対応できます。例えば、インシデントがP3からP1にアップグレードされた場合、条件付きトリガーを設定して、重大インシデントに特化したワークフローを開始できます。また、自動化をさらに進めたいユーザーは、Event Orchestrationを使用して優先度を設定し、Incident Workflowsがその優先度の変更を主なインシデントのワークフローのトリガーとしてピックアップできるようにすることも可能です。

また、レスポンダーがインシデントの詳細ページから直接ワークフローを開始できるようにする手動トリガーも利用できます。手動トリガーを追加すると、Incident WorkflowsはPagerDutyウェブアプリ、モバイルアプリ、Slack、Microsoft Teams、またはAPIから直接トリガーできるようになります。

CollabOpsアクションの強化

ワークフローを設定することで、コラボレーションチャンネルを設定する時間を短縮しましょう。ワークフローアクションを使用して、Zoomコンファレンスブリッジを起動したり、全てのインシデントレスポンダーとインシデントの更新を含む、インシデントごとのSlackチャンネルを作成したりできます。MS Teams Meetingを作成するための同様の機能は、近日中に提供される予定です。前述のとおり、チームの要望に応じて、SlackやMS Teamsで手動トリガーを設定することも可能です。

容易なコミュニケーション

効果的なインシデント対応には、社内外のステークホルダーに対してタイムリーで透明性のあるコミュニケーションを行うことが不可欠です。私の同僚である Hannah Culver が説明したように、ビジネス側の対応計画を準備しておくことは、社内の部門横断的なチーム間の連携を強化し、また顧客対応チームが積極的なコミュニケーションを通じて顧客の信頼を維持するのに役立つのです。Incident Workflowsは、インシデントへのレスポンダーの追加、ステークホルダーの登録、ステータスの更新を自動化し、インシデントについて知る必要のある全員にリアルタイムで情報を提供することで、このパズルを簡単に解決できます。

統一プラットフォームでエンドツーエンドの自動化を実現

Incident Workflowsは、PagerDutyプラットフォームの他の自動化機能と組み合わせることで、チームがより迅速に解決し、収益への影響を最小限に抑えられるように構築されています。例えば、Event Orchestrationでは、優先順位を変更してIncident Workflowsを自動的にトリガーすると同時に、Automation Actionで自動診断を開始し、適切なレスポンダーが呼び出され、Incident Workflowsが起動したインシデント専用のSlackチャンネルに達するまでに、スクリプトが既に実行されているようにできます。

結論

Incident Response中、レスポンダーは中核となる責任であるインシデントの解決に専念する必要があります。Incident Workflowsは、標準化された反復可能な方法で、その他の不可欠でありながらも退屈なタスクを自動化できます。インシデント対応プロセスを標準化することで、チーム間で適切なアクションを取ることができ、インシデント解決の時間を短縮できます。Incident Workflowsは、Business and Digital Operationsプランに含まれているため、この素晴らしい新機能を追加費用なしで利用できます。エンドツーエンドのインシデント対応を1カ所で実現できるのですから、技術を寄せ集める必要はもうありません。ツールの統合について質問している経営陣は、きっとこの機能を高く評価することでしょう。

これは、お客様が独自のユースケースに対応できるような拡張性を提供するためのPagerDutyの旅の第一歩にすぎません。Incident Workflowsの詳細については、Knowledge baseの記事をご覧ください。また、Early Accessへのサインアップをお勧めします。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
インシデント&アラート
2022年8月23日  (更新日:2022年11月8日)

組織が大規模なサービスをうまく構成するのに役立つPagerDuty Service Standards

DevOpsのベストプラクティスであるサービスオーナーシップは、多くの企業で採用が進んでいる手法です。サービスオーナーシップのメリットは多岐にわたり、開発チームと顧客、ビジネス、提供される価値との距離を縮めることができるなどの利点があります。開発者は、革新的で顧客満足度の高い機能を開発するインセンティブを得られるため、「構築し、所有するモデル」は、顧客体験に明確な効果をもたらします。

しかし、サービスオーナーシップへの移行は、特に数百、数千のサービスを抱える大企業にとっては困難です。サービスの定義や境界、誰が所有するかなど、全てが大変な作業となります。また、組織が迅速に拡張できるような方法でサービスが構成されていることを確認することは、テクノロジーエコシステム全体において不可能に近いことです。しかし、このレベルの可視性を獲得することは、より良いビジネス成果を得るために非常に重要です。

この問題に対処するため、PagerDutyは全プランでService Standardsを正式版として提供します。PagerDutyは、サービスベースのアーキテクチャーを通じてサービスのオーナーシップを重視しており、従来は個々のチームがサービスをどのように構成するかを決定することが可能でした。しかし、Service Standardsを利用することで、組織の全チームがベストプラクティスがどんなものかを理解でき、また、サービスオーナーシップに慣れていないチーム間で、チームと組織の両方にとって有益な方法で、その知識を標準化する柔軟性を手に入れることができます。 Service Standardsは、全てのチームが、サービスの構成がサービスオーナーシップのベストプラクティスを順守していることを確認するのに役立ちます。これは、サービスが有益であり、適切なツールと統合され、適切な人材によってサポートされていることを意味します。Service Standardsでは、サービスオーナーシップを採用するだけでなく、組織全体でそれを拡大するために、チーム全体に標準を導入するための可視性と手段を提供します。

Service Standardsの導入

サービスを設定する場合、組織内の各チームはそれぞれ異なる方法をとります。インシデント発生時に全チームが迅速に行動するために必要な情報を持っているサービスもあれば、そうでないものもあります。このように統一性がないため、情報が失われたり、純粋にチーム固有の知識として閉じられたりして、エコシステム全体に問題が発生する可能性があります。また、マネージャーや管理者が、自分たちの担当するサービスが健全な状態かどうかを知ることは不可能に近いのです。 Service Standardsは、個々のエンジニアがより上手にサービスを設定する方法を理解するのに役立つだけでなく、マネージャーや管理者が組織全体でこれらの標準を拡張するためのガイドを提供します。

成功のためのガイドラインで、より良いサービスを設定する

クラウドへの移行に伴い、あらゆる組織のサービスの数は飛躍的に増加し、中央の管理・作成チームではその負荷を処理しきれないことが多くなっています。さらに複雑なのは、サービスオーナーが、それぞれ異なる方法でサービスを構成していることです。命名規則から説明文、適切な人材が待機しているかどうかに至るまで、サービスは提供する情報の深さにおいてさまざまです。

その結果、多くの手戻りが発生することがよくあります。こんなシナリオを想像してみてください。新しいサービスを立ち上げたものの、本番稼動前にブロックされてしまう。その結果、さまざまな変更や修正を加えて出荷するように言われる。そして、これらの要件は成文化されておらず、広く知られていないことが多いため、チームは何度も間違いを犯し、サービス作成プロセスに苦痛と労力を上乗せすることになります。

お客様からよく聞きます。実際、「"良い"とはどういう状態ですか」という質問が上位を占めます。本当のところ、場合によりけりで、チームそれぞれに合った固有のものであることは間違いありません。

Service Standardsを使えば、チームは会社の方針に従って「良いこと」とは何かを標準化することができます。PagerDutyは、サービスがよく構成されているとみなされるために必要な深さとコンテキストを持つために、各サービスが満たすべき9つの標準を提供します。これらは全てオンとオフの切り替えが可能になっています。

説明責任を果たすための監査サービス

また、Service Standardsは、マネージャーや管理者に対して、設定要件が大規模に満たされることを保証するために必要なレベルの制御を提供します。管理者は、これらの標準を組織の他のメンバーが閲覧できるように公開するかどうかを決定し、可視性を決定することができます。また、企業のニーズに応じて、9つの標準のオン/オフを切り替えることもできます。より詳細なレベルでは、管理者はこれらの標準をサービスのサブセットのみに適用して、より柔軟に対応することができます。また、サービスのパフォーマンスデータはPagerDutyからエクスポートし、必要に応じて共有することで、説明責任を果たし、進捗状況を示すことができます。

試してみませんか

Service Standardsは、全組織がサービスオーナーシップのベストプラクティスを展開できるようにします。この機能により、エンジニアは何が本番環境に適しているかを理解し、新しいサービスを出荷するために必要な労力を軽減できます。管理者やマネージャーにとって、Service Standardsは、テクノロジーエコシステム全体の説明責任を促進し、進捗を評価する方法を提供するのに役立ちます。やがてこれは、迅速な状況を求めるファーストレスポンダーのためのインシデント対応を改善し、組織レベルでの運用の成熟を促進するのに役立ちます。

詳細については、最近のウェビナー「How to Standardize Service Ownership at Scale for Improved Incident Response」をご覧いただくか、こちらのKnowledge baseの記事をご覧ください。

Service Standardsを実際に見てみたい方は、PagerDutyを14日間無料でお試しください。

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

続きを読む
インシデント&アラート
2018年5月17日  (更新日:2022年10月13日)

HOW-TO:Twitterトレンド・アラート・システムの作り方

こんにちは!私はリチャード・チャオ、PagerDutyのプラットフォームチームのソフトウェアエンジニアリング部門でインターンをしています。私はワーテルロー大学でコンピューター工学を学ぶ2年生でもあります。この記事では、2018年のMarch Hackdayプロジェクトを紹介します。最小限のコーディング知識でTwitterトレンドのアラート・システムを40分以内で作成できるガイドです。

PagerDutyを活用してTwitterで自分のブランドを監視するシステムを作る―しかも40分以内で

ソーシャルメディアの時代、ブランドの評判の管理より複雑なことはありません。公開企業の66.7%がTwitterでメンションする中、あなたは適切なタイミング、例えば顧客が最もよく見ている時間に興味深く影響力のあるコンテンツを宣伝したいとします。それと同時に、主要なPR活動を監視して迅速にチームを動員できるように準備させておき、ブランドが顧客と収益を失わないようにしたいとします。そのために必要とされるものは競争力です。それは、チャンスなのかトラブルなのかに関係なく、ソーシャルメディアで何かが起こったらすぐにそのトレンドのトップに立つことを意味します。

導入事例

今日は、ほとんどの人はToronto Raptors(訳注:カナダ・オンタリオ州トロントに本拠を置く全米プロバスケットボール協会所属のチーム)について話しているようです。おそらく、これはぼくらのジャージの5割引セールを宣伝するのにベストなタイミングでしょう。

PagerDutyソリューション

ほとんどの企業はPagerDutyを使い、顧客に影響を与える不具合の管理や、適切な対応者へのアラート送信、インシデントが従業員と顧客満足度に及ぼす影響の分析などを行っています。

しかし、PagerDutyをTwitterのトレンド・アラート・システムとして活用できることも知っているのでしょうか?

PagerDutyの良いところは、ニーズに合わせて簡単に拡張できることです。このガイドの最後まで行けば、Twitterのキーワード、メンション、リツイートをリアルタイムで追跡し、ソーシャルメディアの活動が急増したときにeメール、SMS、または電話で即座にアラートする自動化されたアプリケーションができ上がっています。一番おいしい点は、これにかかる時間は40分以下で、コーディングに関する知識もほとんど必要ないことです。では、早速作業に入りましょう。

ステップ… 別名 “Engineering Stuff”

ステップ1:Twitterアプリケーションを設定します。

新しいTwitterアカウントの作成 このプロジェクトにはあなたの会社のTwitterアカウントを使用する必要はないので 、セキュリティとテストのため新しいTwitterアカウントを作成することをお勧めします。 Twitter APIキーの取得 メールを確認してください。 Twitter APIを使用するには、Twitterがアプリケーションをあなたのアカウントに関連付けるためのトークンが必要です。https://apps.twitter.com/にアクセスして新しいアプリを作成します。 Keys and Access Tokensタブの下で、トークンを生成します。後でキーをコピーできるように、このタブを開いたままにしておきます。

あなたのTwitterアカウントを開発用に設定する必要があります。

ステップ2:プロジェクトコードをダウンロードします。

PagerDutyはGitHubを使用してコードリポジトリの管理をします。

プロジェクトコードをダウンロードするため、Gitがインストールされていることを確認してください。 https://github.com/pagerduty/twitter-trend-alert-system にアクセスしてください。ターミナル/CMDで、”git clone https://github.com/pagerduty/twitter-trend-alert-system ”を実行してプロジェクトコードをダウンロードします。 このプロジェクトはPython 2.7.14を使用しています。インストールしていない場合は、https://www.python.org/downloads/にアクセスしてください。 “pip -version”と入力してインストールを確認してください。

プロジェクトを設定するには、READMEに記載されている指示に従ってください。この時点ではDatadog APIキーが欠落しているはずです。

ヒント: このガイドでは、ローカルコンピュータでプロジェクトを実行します。これを無期限に実行したい場合は、小さなサーバーで実行することをお勧めします。

この作業が完了する前に、Twitterに投稿されたすべてのステータスをフィルタリングし、リストされたキーワードを含むステータスのみを返すプロセスがあります。

ステップ3:PagerDutyを設定します

あなたの会社が現在PagerDutyを使用していない場合は、https://signup.pagerduty.com/accounts/newにアクセスして無料の14日間の試用アカウントを作成する必要があります。

オンボーディングページはスキップできますが、通知を設定していることを確認してください:

サービスを設定するまであと少しです。

まず、エスカレーションポリシー(EP)を設定します。通常、EPは状況を適切な人にエスカレートさせ、誰かがインシデントに対応できるようにします。ここで詳しい情報を見つけることができます:https://support.pagerduty.com/docs/quick-start-guide#section-create-an-escalation-policy ホームページから、Configuration → Escalation Policies → New Escalation Policy へ移動します。 EPの名前を作成します。

次にサービスを設定します。サービスは関連情報を裏付けるために設計されています。詳細については、https://support.pagerduty.com/docs/quick-start-guide#section-create-a-serviceをご覧ください。 Configuration → Services → Add New Service の順に選択します。 きちんとした名前をつけてください。 DatadogをIntegration Typeの欄に表示させてください。 How should responders be notified(レスポンダーにどのように通知するか)というフィールドは、状況によって異なります。あなたが話題のトレンドをモニターしたいならば緊急性の低いサービスをお勧めします。一方、重大な顧客サポートに関わるインシデントを監視したい場合は、緊急性の高いサービスをお勧めします。低緊急度サービスと高緊急度サービスの違いの詳細については、https://support.pagerduty.com/docs/service-settings#section-use-case-1-critical-and-non-critical-incidentsを参照してください。

ヒント: なぜDatadog?

PagerDutyには連携する200以上のインテグレーションがあり、そのうちの1つがDatadogです。あなたのチームが他のツールを使用している場合でも、PagerDutyがそれとインテグレーションできる可能性は非常に高いです。また、インプルななREST APIを使用することもできます。

あるコンテンツがトレンドになっている時や、熱いソーシャルメディアの状況を管理する必要がある場合、適切な時に適切な人に通知するためのアラートサービスを提供しています。

ステップ4:Datadogホストを作成します。

https://app.datadoghq.com/signupで新しい試用アカウントを作成します。 指示に従って、MacまたはWindowsコンピュータにDatadog Agentを設定します。Macではターミナルでコードスニペットを実行します。Windowsではインストーラーをダウンロードして使用します。

https://app.datadoghq.com/account/settings#apiにアクセスし、APIキーをコピーします。そして設定ファイルに貼り付けます:

このクイックガイドに従って、PagerDutyのDatadogとのインテグレーションを行ってください。すでにサービスを設定しているので、次のような画面が表示されます。

アプリを実行します。アプリケーションの起動方法については、README.mdを参照してください。最初のツィートが追跡された後、この指標はDatadogに存在するはずです。 Monitors→New Monitors** の順に移動して、新しいメトリック・モニターを作成します。

メトリックに_tweet_countを選択します。 システムが動作することを確認するために、低いアラート閾値(例では5)を設定します。例えば、

分かりやすいメッセージをタイトルに追加し、説明に@pagerdutyがタグ付けされていることを確認してください。次の図を参照してください。

Saveをクリックすると、数分間であなたの電話にアラートが表示されます。 これで完全なTwitter Trend Alert Systemを持っていることになりました。

ステップ5:ブラッシュアップ

順調に機能できたので、これからはアラートを解決しましょう。

テスト設定からのアラートを避けるために、Datadogの閾値を上げましょう。Monitors→Manage Monitorsの順に移動します。メッセージタイトルのmonitorの上にマウスカーソルを置き、Editをクリックします。アラートの閾値を100,000などの大きな数値に変更します。

PagerDutyでは、通話やテキストメッセージに返信することでアラートを解決できます。あるいは、Webサイトからインシデントを解決することもできます。

次のステップ

あなたは今、完全に動作しているTwitter Trend Alert Systemを持っています。今こそ、ソーシャルメディアのトレンドを効果的に活用する時です。

PagerDutyがシステムの機能をどのように強化するかに興味がありますか?

弊社の製品を最大限に活用するための次のいいステップがあります:

エスカレーションポリシー :特定の広報インシデントには経営幹部の決定が必要です。連絡を取る時間を短縮し、エスカレーションポリシーを設定して通知を受けるようにします。 ステークホルダーユーザー:あなたの社内に重大な広報インシデントが起こったことを通知されたい人がいますか? 次は利害関係者のユーザーを設定することを検討してください。 操作コマンドコンソール (OCC):大規模なインシデントの際にTwitterで顧客がどのように反応しているかを監視します。

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

続きを読む
インシデント&アラート
2022年6月3日  (更新日:2022年9月14日)

Automated Diagnosticsとは何か、どのような影響があるか

インシデントのコストはどのように測定するか

テクノロジー業界の多くの人々は、インシデントのコストを、ダウンタイムや影響を受けた顧客や従業員の数といった観点のみから語ります。そして、表面的には正しい見方であることが多いのです。ニュースにもなりますし、顧客の評判と信頼はあらゆるビジネスの成功に欠かせないことは明らかです。

しかし、インシデントの直接的なコストとしてあまり認識されていないのが、インシデント発生時に関与する必要がある人数です。顧客に影響を与えるほど深刻なインシデントであろうとなかろうと、根本原因の調査、トラブルシューティング、インシデントの解決、チームの責任の放棄などに多くの人が関わります。

PagerDutyのデータによると、レスポンダーの時間の50%は、x環境、またはyサービスでの追加サポートのために誰を呼び出すのが最善かを判断する(そして実際に問題があるかどうかを見極める)ために費やされています。この統計によると、インシデントの寿命の50%は、実際の改善活動ではなく、インシデントの初期段階(診断とトリアージの段階)に費やされていることになります。

結論から言うと、インシデントごとにかかる工数と手動アクションの数は、急速に増加する可能性があります。

インシデント対応の自動化

インシデントの深刻度を診断し、何が(どのように)うまくいかなかったのかの構造を理解するなど、インシデントの初期の再発段階に自動化を適用することは、最終的なインシデントの是正を成功させるために非常に重要です。

自動化は人の観点からも重要です。インシデントが発生するたびに同じ作業を繰り返し、チームが疲弊しないようにする必要があります。診断データを第一レスポンダーが確実に利用できるようにすることは、事故対応のルーティング効率と全体的なワークフローに最も重要です。

先に進む前に、まず診断データの定義について説明します。診断データは、インシデントレスポンダーによって取得されるデータで、通常、監視ツールによって提供される情報よりも具体的です。たとえば、監視ツールは、CPUやメモリーが急増したときに警告を発しますが、インシデントレスポンダーは、CPUやメモリーを最も多く消費するプロセスを見ることで調査を行います。したがって、この場合、プロセス名またはID、およびそれらに関連するコンピューターの消費量が「診断データ」となります。

さて、Automated Diagnosticsの定義は分かりましたが、なぜ必要なのでしょうか。それは、Automated Diagnosticsを導入すると、インシデントの発生期間を短縮し、対応にかかる人数を減らすことで、インシデントのコストを削減できるからです。

MTTRの問題点

ここで「問題」という言葉は適さないかもしれませんが、最後まで読んでください。MTTRという指標は、粒度の細かい実用的な洞察を得るには広すぎるのです。MTTR(Mean Time to Repair)は、IT業界では何十年も前から保守性の指標として定番となっています。MTTRには多くの用途があり、一般的な回復速度を説明するのに適していますが、その欠点は一般的であるということです。そして今、レスポンダーの時間の50%は、追加サポートのために誰を呼び出すのが最善かを判断するために費やされていると安全に推測できるため、MTTT(トリアージまでの平均時間)やMTTI(調査までの平均時間)など、MTTRタイムライン内の他の指標にも目を向けるようになりました。

MTTI/MTTT**。ITインシデントを検出してから、組織がその原因や解決策の調査を開始するまでの平均時間。MTTD(平均検出時間)からMTTR(平均修復時間)開始までの時間を表す。_

PagerDutyでは、最初のレスポンダーが受任してからリゾルバーが受任するまでの時間として測定しています。この指標は、インシデント発生時に水面下で実際に何が起きているのかを知るのに役立ちます。自社のデータを観察した結果、MTTIはMTTRの中で最も時間を消費する要因の1つであると推測することができました。現代のビジネスでは、エンジニアが時間と注意を払う必要があるタスクは、ビジネスにとって高価なものなのです。 本当に 高価なものです。

Automated Diagnosticsの活用

ここで、MTTIとAutomated Diagnosticsに話を戻しましょう。MTTIは、レスポンダーが手動で診断データを取得し、xサービスとyインシデントに基づいてどのチームにエスカレーションするかを解読しなければならないという技術的タスクによって長引くだけではありません。解決に必要な専門知識によって、担当者とその制約も変わってきます。例えば、多くの場合、最初のレスポンダーは、データベースやネットワークの「視点」から問題を調査する方法を知りません。それは、彼らのスキル(データベースやネットワークのバックグラウンド)、アクセス、またはチーム的知識(例えば、特定のアプリコンポーネントがサードパーティーのサービスとの複雑なインテグレーションに依存していること)の不足が原因である可能性があります。

このような調査やデバッグの作業を自動化し、チームや担当者にこれらの作業を委ねることができれば、MTTI、ひいてはMTTRにプラスの連鎖効果をもたらすことができます。

なぜAutomated Diagnosticsにこだわる必要があるか

Automated Diagnosticsでできることは以下の通りです。

通常、手作業で収集される情報をファーストレスポンダーに提供するパスを設計することで、希少な専門家へのエスカレーションを削減 対応チームに専門知識を共有 ファイアウォールやVPCの背後にある安全な自動化の呼び出し 人の手を借りずにトラブルシューティングと解決を迅速化 新人エンジニアへの教育のスピードを向上させ、インシデント対応組織の全レベルで最適な効率性を確保

始めましょう

あなたは決断しました。今こそ道を切り開く時ですが、何から始めればいいのでしょうか。

マーケティングのスラングを使えば、「海を沸かそうとしてはいけない(訳注:無理な仕事を引き受けてはいけない)」ということです。複雑さもリスクも低いアクションをいくつか試してみてください。例えば、最もノイズの多いサービスを詳しく調べたり、さまざまな監視アプリケーションから簡単なデータを取得したり、ディスクの使用状況を調べたりすることができます。しかし、この機能を長期的に展開するための戦略を持つことが重要です。確かに、多数のソースからデータを取得し、それをインシデントに追加するスクリプトを書くことは可能です。しかし、それではスケーラブルであることとは程遠くなります。

診断データを取得するために、さまざまなインフラやツールについて考えることは重要です。異機種混在のダイナミックな環境と連動するための標準化されたアプローチが必要です。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
インシデント&アラート
2022年1月27日  (更新日:2022年9月13日)

インテリジェントアラートグループのタイトルのつけ方

共著者:PagerDutyデータサイエンティストVI、Chris Bonnell氏

引き続き、IAG(Intelligent Alert Grouping)の活用・改善方法について、第3回目をお届けします。最初の投稿では、インテリジェントアラートグループ化機能を紹介しました(こちら)。2回目の投稿では、IAGがどのようにマージを使用してアラートをグループ化するのかを説明しました(こちら)。本日は、IAGのマッチングを向上させるためにアラートタイトルを使う方法について説明します。

アラートタイトルが表示される場所 - 再確認

アラートがプラットフォームでトリガーされると、eメール、テキスト、またはアプリ自体からのプッシュ通知など、いくつかの経路で通知が行われることがあります。どの経路であっても、表示される最小限の情報は、アラート番号、サービス、およびアラートタイトルです。これは、いくつかの注目すべき場所に表示されます。アラートの受信方法によっては、これらの一部または全部が見慣れたものかもしれません。緊急度レベル(例:高)は、連絡方法を決定するために使用されますが、目に見える形で表示されないことに注意してください(ただし、インシデントの詳細には表示されます)。

電話のプッシュ通知とテキスト通知

例えば、iPhoneのロック画面を見てみましょう(同じインシデントについてのテキストメッセージ通知や電話着信)。

これはブログ投稿のために全てのチャンネルにアラートをプッシュしています。ここでは、アラートのタイトル、番号、サービスが表示されていることが分かります。テキストメッセージも似たような感じです。

メール通知

これらは少し違っているように見えます。メールの件名にはあまり詳細が書かれていませんが、メッセージの本文にはアラートの詳細が記載されています。

なぜ、アラートタイトルの表示場所を見直すのですか?

私のような方なら、実際の状況やサービスに関するアラートタイトルや説明文を書いていたときは、人間の脳に最適化させていたのではないでしょうか。証拠は上にも表れています。このアラートタイトルはブログ記事のタイトルのようだし、文頭に「Title」という識別子を強引に含んで、それが表示される場所を強調しています。これは人間のためのもの。読者の皆さんが画像から情報を読み取る際に、私が特定の部分に注目してもらいたくて故意にやりました。

もし、人間以外のために設計するとしたら?例えば、機械学習に適した設計ならどうでしょう?機械学習について知っていることや学んだことを何でも取り込み、それらを活用しようとメッセージを歪め始めるでしょう。

私が皆さんにお伝えしたいのは、このことです。インテリジェントアラートグループの体験を向上させるために機械学習を取り入れる際にも、人間のことを念頭に置く必要があるということです。

アラートタイトルを活用する

人のためにアラートタイトルを構築するとき、忘れてはならないことがあります。

簡潔であること。ご覧の通り、プッシュ通知もテキスト通知も文字数制限が短いです。 OSやウェブブラウザーによって制限が異なります。例えば、Androidの場合、プッシュするタイトルの文字数制限は65文字で、さらに説明文の文字数制限は240文字です。iOSの場合は、タイトルと説明文を合わせて178文字となっています。

明確であること。タイトルが分かりにくくなったり、何も伝わらなかったりするほど簡潔であってはなりません。 タイトル欄を優先するあまり、他の欄をおろそかにしないこと。 ウェブインターフェイスと同様に、PagerDutyモバイルアプリでは、他のインシデント、そのサービス、その説明を含む完全なインシデント情報を利用することができます。最初に表示されるからといって、タイトルフィールドに情報を盛り込みすぎないでください。

これらの詳細については、インシデントレスポンス運用ガイドの「アラート発信の原則」のページをご覧ください。

機械学習では、以下のことに注意しましょう。

識別性と頻度を上手に利用する。 データモデルは(人間と同じようには)読むことができない。 データモデルは意図を推論することができない。

その理由は、機械が「自然言語処理」と呼ばれるものをどのように行っているかを理解するためです。自然言語処理とは、スペルチェックや文法チェッカーが「it's」と「its」を区別して著者に通知したり、オートコレクトがどの単語と活用、どの形式(活用、自然下降)を提案するかを知るためのものです。アラートタイトルに適用される自然言語処理では、タイトルを匿名化し(詳細は後述)、「文トークン化」と「単語トークン化」というプロセスでそれぞれ文と単語に分解し、単語を見出し語化(レンマ化)して、最終結果を頻度の決定と他のアラートとの相関性の検索に使用します。

匿名化から始めると、例えば特定のIPアドレスをxx.xx.xxに置き換えるように、そうでなければあまりにも一意な情報をその情報のパターンに置き換えることが目的です。このテキストは、一意な情報によって本来関連するはずのタイトルが関連しなくなることを防ぎます。関連する可能性のあるコンテキストが完全に削除されるわけではありません。レンマ化とは、活用語や屈折変化をレンマと呼ばれる基本形に単純化する工程のことです。再び例で説明します。{“dogs”, “dog’s”, “dogs’”, “dog”}は全て“dog”にレンマ化され、同様に{“is”, “are”, “be”, “were”}は”be”にレンマ化されます。つまり、“The dog's bones.”と“The dogs' bones.”のような文は、この段階でどちらも{“the”, “dog”, “bone”, “.”}にレンマ化されるのです。

この時点で、インテリジェントアラートグループモデルは、N-gram(N個の単語のグループ)とインシデント言語のパターンに関する知識の両方を使用して、アラートタイトルから情報を抽出し、意味のある相関関係を作成します。前回の記事で紹介した例をもう一度見てみましょう。

最初のパターン memory usage high (> N %) on server $NAME in region $REGION 2つ目のパターン memory usage on host is high (> N %)

既にN %と$NAMEで少し匿名化しましたが、これらのタイトルにあるものをトークン化する練習をしてみましょう。 トークン化、レンマ化された最初のパターン。 {“memory”, “use”, “high”, “(“, “>”, “N”, “%”, “)”, “on”, “server”, “$NAME”, “in”, “region”, “$REGION”} トークン化、レンマ化された第2パターン。 {“memory”, “use”, “on”, “host”, “be”, “high”, “(“, “>”, “N”, “%”, “)”}

パターンが意味することの影響を考えると、2番目のアラートでは、そこに置かれた値によって変化する唯一の用語はNです。もし閾値が現在のメモリー使用量ではなく、一貫したものであれば、Nは全く変化しないか、タイトルに表示される値が1つか2つしかない可能性があります。それに対して、最初のアラートのタイトルには、サーバー名とその地域の一意性がより強くなっています。つまり、用語は1つまたは全く変化しないのではなく、3つの変化する用語があるわけです。言語処理装置に関する限り、2番目のパターンのアラートは1番目のパターンよりも相関関係がある可能性がはるかに高いです。

これからの方向性

アラートのタイトルを作成する際には、人間と機械学習の両方を考慮することが重要です。人間はアラートやインシデントの詳細情報を利用して追加のコンテキストや情報を得ることができますが、インテリジェントアラートグループではタイトルフィールドのみを使用するため、機械学習の最適化を若干意識するとよいでしょう。自然言語処理の基本については、Towards Data Scienceブログの「Introduction to Natural Language Processing for Text」ブログ記事をご覧ください。一般的にアラートやインシデントに含めるべき情報についてのベストプラクティスは、当社のインシデントレスポンス運用ガイドをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
インシデント&アラート
2022年1月28日  (更新日:2022年9月12日)

インテリジェントなサービス設計

共著者:PagerDutyデータサイエンティストVI、Chris Bonnell氏

EIアーキテクチャーシリーズの第4回目、「Intelligent Alert Grouping(インテリジェントアラートグルーピング)」についてご紹介します。前回は、インシデントのマージを使用してIntelligent Alert Grouping をトレーニングする方法(こちら)と、デフォルト マッチングを改善するためにアラートのタイトルを設定する方法について説明しました。今回は、サービスデザインがIntelligent Alert GroupingやPagerDutyアプリの使用感にどのような影響を与えるかについて説明します。

サービスについて

サービスを設計したり、再設計したりする前に、組織で機能するサービスの定義を持つことが重要です。この定義は、理解できるほどは具体的である必要がありますが、複数のチームがサービスとは何かを抽象的には同じように理解できるように広いものである必要があります。PagerDutyでは、次のような定義を使っています。 サービスとは、チームによって完全に所有される、価値を提供する機能の個別部分である。

担当チームは、サービスを構築し維持するチームであり、あらゆるインシデントに対応することも含まれるため、把握しておくことが重要です。サービスとオーナーシップについての概説は、サービスの定義に関する完全なサービスオーナーシップ運用ガイドを参照してください。

サービスやその所有者について考えるだけでなく、サービス名にも気を配る必要があります。Service Directoryに目を通すと、追加の制度的知識がなくても、それぞれのサービスが何であるか簡単に理解できるようになるはずです。簡単に言うと、「Payment Service」という名前のサービスがあったり、あらゆるトランザクションサービスがギリシャ神話の神々にちなんで名付けられているという社内文書を知っているか参照して、どのギリシャ神が支払いを処理するサービスに相当するかを調べるかの違いです。この点については、Full Service Ownership Ops Guideの「Naming Services」のセクションで詳しく説明しています。

PagerDutyアプリでは、サービスはビジネスサービスとは区別されます。ここまでは、全てサービスに関連する話です。また、ビジネスサービスとの混同を防ぐため、弊社のドキュメントでは技術サービスと表記している場合があります。ビジネスサービスは、技術サービスや他のビジネスサービスの集合体であり、通常、ビジネスロジックおよび/またはステークホルダーに従います。Intelligent Alert Groupingは技術サービスのみを利用し、ビジネスサービスは利用しないため、この記事でサービスと書いた場合、技術サービスのみを指します。

粒度

サービスをどう分けるか、そのバランスを考えてもすぐには分かりませんし、万能の解決策もありません。基本的には、粒度の高いものと低いもののバランスを取り、時には置き換えすることになります。例えば、PagerDutyのアプリケーションでは、1つの監視ツールで、その構成機能を全部別のサービスに分解しています。一方、より広範で粒度の低いサービスの使い方としては、iOSとAndroidの開発を別々のチームが担当している場合でも、あらゆるモバイルアプリケーションを1つのサービスとして提供することが挙げられます。後者の例では、サービスの構成方法について単一の推奨事項が存在しない理由は、組織にモバイルチームが1つしかないとか、モバイルチームがないとか、異なる基準で分割されたモバイルチームがあるためだとよく分かります。

では、どうすればよいのでしょうか。私たちは、サービス定義のナビゲートに役立ついくつかのアドバイスを抽き出せます。まず始めに、オーナーシップについて説明します。PagerDutyアプリケーションでサービスを定義する主な理由の1つは、インシデント対応のためです。つまり、サービスの問題に対処できるのは誰かを知ることは、サービスを所有しているのは誰かを知ることなので、組織内で誰がサービスを所有しているかによって、PagerDutyでサービスをどのように定義するかを決めることができます。これは、完全なサービスオーナーシップモデルではないものの、望ましいエスカレーションパスが分かっているサービス構造が既にある場合、その知識を活用できる点で重要です。この場合、Intelligent Alert Groupingがインシデントをグループ化すると、サービスが希望するエスカレーションパスに関連付けられるだけにしても、このコンテキストではそれが重要であり、達成する最終結果になるのです。

また、現在のプロジェクトを見直して、どれが事実上機能単位になっているかを確認し、それらをPagerDutyで1サービスとして定義する必要があります。こうすることで、エスカレーションパスが同じプロジェクトは正しくグループ化される一方で、エスカレーションパスの関係で複数のプロジェクトが単一のサービスとして定義され、可視性が損なわれるというシナリオを防ぐことができるはずです。もう少し踏み込んで、常にインシデントが同時に発生している2つ以上のサービスがある場合、それらを1つのサービスに集約する必要があるかもしれません。具体的な例として、メトリクス、ハートビート、ログなどの個別のコンポーネントを持つモニタリングマイクロサービスがあるとします。これらがそれぞれPagerDutyサービスを持っている場合、ほとんどの場合、インシデントがこれら全サービスに同時にまたがることになるので、モニタリングマイクロサービス自体として1つのサービスにまとめる必要があります。一方、同じ人が働いているからと言って、別々のプロジェクトが1つのサービスとして定義されている場合、そのサービスは十分に粒度が揃っていない可能性があります。このシナリオでは、PagerDutyアプリに関する限り、サービス内のエンティティーは全て1つの「もの」であるため、どのエンティティーが他のエンティティーよりも注意を払う必要があるかを判断するのが難しくなります。

次に何をするべきか

既存のサービス、あるいはこれから作成されるであろうサービスを見て、それらをチェックすることから始めましょう。

エスカレーションパス 名称 機能単位

そして、PagerDutyアプリケーションでサービスを定義する際の指針として使用します。Intelligent Alert Groupingは、関連するサービスの下にアラートをグループ化することで、そこからの作業を行います。サービスをゼロから設計したり、サービスの定義を見直したりする場合は、「フルサービス オーナーシップ運用ガイド」で、レスポンスの命名とオーナーシップに関するベストプラクティスを参照し、「(技術)サービス」と「ビジネスサービス」に関するドキュメントもご覧ください。次回は、このシリーズの最終回で、これまで取り上げた内容を全て再録する予定です。ei-architecture-seriesタグを使うと、このシリーズの記事をご覧いただけます。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
インシデント&アラート
2022年4月7日  (更新日:2022年9月9日)     |    インシデント&アラート

Intelligent Alert Groupingシリーズまとめ

Co-authored by Chris Bonnell, PagerDuty Data Scientist VI

Intelligent Alert GroupingについてのEIアーキテクチャーシリーズの最終回へようこそ。このシリーズを楽しんでいただけたなら幸いです。もし私たちの過去の投稿を見たいなら、ei-architecture-seriesタグをお使いください。少し時間をとって、私たちが学んだことを全て振り返ってみましょう。

記事のポイント

Intelligent Alert Grouping(IAG)のデフォルトの動作は、インシデント管理における抽象化されたパターンに基づいており、また機械学習モデルも利用しています。つまり、このツールは、いわば経験則に基づいた推測を数多く行うことができますが、個々の環境では完全に一致するものを生成できない可能性があります。それを補うために、マージ、タイトル、サービスデザインなどを活用することで、グループ化の動作を改善することができます。

マージ動作

インシデントは、PagerDutyアプリケーションのマージと呼ばれるプロセスによってグループ化されます。一般に、どのインシデントも他のインシデントとマージすることができます。特にIAGでは、この投稿でレビューしたように、個々のアラートを新しいインシデントにマージすべきか分離すべきかを判断しようとするときに、Alert Titleフィールドを分析します。アラートが不適切に共通のインシデントにマージされた場合、それらを分離し、あるべき場所に移動させるための措置を講じることができます。機械学習モデルは、反復するたびに行動を強化するため、アラートが残るか、マージされるか、移動されるかによって、今後の行動が改善されます。

アラートタイトル

IAGはAlert Titleフィールドを基にマージ動作を行うため、以前の投稿で一般的な機械学習の原理を用いたアラートタイトルの基本を説明しました。ここでは、3つの重要なポイントがあります。

アラートのタイトルは、人間と機械学習の両方に役立つべきもので、機械学習寄りにするため、残りのインシデントの詳細は詳細に記述すべきです。 機械はコンテキストを理解できないので、コンピューターが「一意」「共通」を区別できるようにするのが重要であることを忘れないでください。 プッシュ通知で表示されるアラートタイトルの部分には字数制限があるため、人間向けのテキストはタイトルの後半ではなく、前半に配置するようにしましょう。

これらの実装方法を掘り下げるには、前述の記事の機械学習の部分と、Towards Data Scienceブログの「Introduction to Natural Language Processing for Text」のブログ記事をご覧ください。

サービスデザイン

最後に紹介した概念は、サービスデザインのことです。 一般的な考え方としては、同じサービス上の類似したアラートはデフォルトで、他のサービス上のアラートよりも相関性が高いと想定されます。サービス定義をどの程度細かくするかによって、PagerDutyアプリケーションで「サービス」をどのように実装するかが決まるため、ここではかなり多くのことを説明できました。一般的なルールとして、2つの「もの」が別々のサービスであるべきかどうか分からない場合は、望ましいエスカレーションの経路を模倣してください。もし両者が同じチームや人によって所有されているのであれば、PagerDutyアプリケーションで両者を1つのサービスとみなすことで、エスカレーションを尊重し続け、アラートの相関性をより高くするという利点も得られます。もし、異なるチームが担当している場合や、アラートの相関性を高めたくないという理由で論理的に区別している場合は、別々のサービスとして定義してください。所有するチームについては、一般的なサービス定義と所有権のベストプラクティスについて詳しく知りたい場合は、フルサービス所有権運用ガイドをご覧ください。

今後の方向性

ここまでです。Intelligent Alert Groupingをフル活用する方法について、時間を割いて学んでいただき、本当にありがとうございました。もしこれらの記事を長期的に参照したい場合は、ei-architecture-seriesタグをブックマークしてください。さらに議論を深めたい場合は、当社のコミュニティーフォーラムをご覧ください。より詳細なQ&Aについては、サポートチームにお問い合わせください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2022年1月11日  (更新日:2022年9月6日)     |    インシデント&アラート

ラウンドロビンスケジューリングによるオンコール責任の均等分配とインシデント対応効率化

PagerDutyは、ラウンドロビンスケジューリングを発表できることをうれしく思います。ラウンドロビンスケジューリングは、チームメンバー間でオンコールシフトの責任を公平に分配することを可能にします。自動的に異なるユーザーまたはエスカレーションレベルのオンコールスケジュールに新しいインシデントを割り当てることで、チームが可能な限り効率的にインシデントを解決することを保証します。また、複数のユーザーで作業負荷のバランスをとることで、燃え尽き症候群のリスクも軽減されます。

同一サービスで発生した複数のインシデントのシームレスな解決

あるサービスでインシデントが発生すると、1人のレスポンダーがアラートを受信し、トリアージを開始します。インシデントが1つだけであれば対処可能です。しかし、アラートの量が多いサービスでは、レスポンダーが複数のインシデントに対応するために複数の方向に引きずられるため、インシデント対応中に混乱が生じる可能性があります。あるサービスで、30分以内に対処しなければならない5つの異なるアラートが同時に発生したとします。1人のオンコールエンジニアがその全てに対応することはできません。そこで、ラウンドロビンスケジューリングが役に立ちます。

ラウンドロビンスケジューリングでは、新しいエスカレーションポリシーを作成するか、既存のエスカレーションポリシーを編集して、”Users are assigned via round robin on the escalation level”(エスカレーションレベルではユーザーはラウンドロビンで割り当てられる)というボックスをチェックすれば、ユーザーは簡単にローテーションを設定することができます。

上記の例のような場合、ラウンドロビンの各担当者は、5つのアラートのうち1つをトリアージするよう割り当てられることになります。これにより、インシデント対応が効率化され、ダウンタイムが短縮され、顧客体験が向上します。

ラウンドロビンスケジューリングなしラウンドロビンスケジューリングあり
全てのインシデントが1人の担当者に割り当てられ、残りのメンバーはスケジュールにないためアイドル状態インシデントをチーム内で公平に割り当て、それぞれが分担する
1人のレスポンダーが複数のアラートを処理しようとするため、MTTAとMTTRが増加する各レスポンダーがアラートに最大の注意を払うことができるため、MTTAとMTTRが減少する
レスポンダーに余裕がなくなると、エスカレーションを余儀なくされる入ってきた問題にすぐに対応できる別のレスポンダーがいるため、エスカレーションの頻度が少ない

さらに、ローテーションの対象者を特定するのも簡単です。ユーザーがエスカレーションポリシーを表示すると、ラウンドロビンのローテーションで誰が次になるかが緑の矢印で示されるので、問題が発生したときに誰がアラートを受けるかがあらかじめ分かるのです。

燃え尽き症候群を減らすために、仕事を分散し、必要に応じてエスカレーションする

大量の依頼を受けるオンコールチームでは、燃え尽き症候群が常に念頭にあります。 一人のチームメイトが複数の問題を同時に処理し、他のチームメイトが待機していることもあります。このようなオンコールシフトは、注意力不足、応答速度の低下、認知能力の低下などを引き起こす可能性があります。たとえオンコールシフトが月に一度しか発生しないとしても、それは離職率を高めるのに十分な圧力となり得ます。

ラウンドロビンスケジューリングは、各新規インシデントが、マネージャーもユーザーも含めて順次割り当てられるようにし、チームが責任のバランスをより良くとれるようにします。これは、エスカレーションの上位レベルにいるディレクターなど、優先順位の高いインシデント中にステップインする必要があるかもしれない人も含めて、オンコールスケジュールにいる全ての人にとって公正かつ予測可能なローテーションを維持するのに役立ちます。

ラウンドロビンスケジューリングを使用する

あなたのチームでオンコールボリュームを管理し、インシデント対応を合理化し、公平に作業負荷を分散する方法をお探しですか。ラウンドロビンスケジューリングは、BusinessとDigital Operationsの全てのプランで利用できるようになりました。現在ご利用中のお客様で、この機能へのアクセスを解除するためのアップグレードをご希望の場合は、PagerDutyアカウントチームまでご連絡ください。まだご利用でない方は、この機能を14日間無料でお試しいただけます。

ラウンドロビンスケジューリングの詳細については、こちらのサポートドキュメントをご覧いただくか、こちらのYouTubeショートムービーをご覧ください。

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

2022年1月10日  (更新日:2022年9月5日)     |    インシデント&アラート

インテリジェントスウォーミング vs 階層型サポート。カスタマーサービスチームがPagerDutyを使い重要な問題をスウォームさせる方法

今日、ほとんどのサポート組織は、何らかの形で従来の階層型サポートモデルを採用しています。これは、エスカレーションと顧客の引き継ぎのプロセスに基づいているものです。このモデルでは、顧客の問題は、サポート階層の複数のレベルを介してエスカレーションされ、3つの階層が一般的なワークフローとなります。

この典型的な3層構造のサポートシステムの例では、Tier 1は入ってくる顧客の問題を受ける最初の防御線であり、一般的なテクニカルサポートを提供します。Tier 1サポートで解決できない問題は、より深い技術的知識とサポートスキルを持つTier 2にエスカレーションされます。このレベルでも解決できない場合は、対象となるアプリケーションの専門家であるTier 3のスペシャリストにエスカレーションされます。

このモデルは、それほど深刻でなく繰り返し発生する問題には有効ですが、今日の常時接続のデジタル世界において、優先度が高く重要なインシデントに対処する場合には、全く適していません。おそらく、今日のカスタマーサービス組織で広く見られるこの従来のサポートモデルの考え方を疑うべき時が来ているのでしょう。

このモデルは、エスカレーションと顧客の引き継ぎのプロセスに基づいているため、以下のようないくつかの欠点があることは驚くことではありません。

解決までの時間、First Reply Timeが長い。** 全チケットが同じトリアージのキューに従うため、最終的に適切な担当者にたどり着くまでは、その問題に対処する能力がないエージェントのもとで時間を浪費することになります。このモデルでは、適切な専門家にたどり着くまでに障壁があり、問題についての重要な文脈や情報が途中で失われることが多く、不必要な遅延が発生します。 長いバックログ項目。** Tier 1レベルで解決できないお客様の問題は、他のサポート層への待ち行列に入ります。このケースは、リアルタイムでアクティブに作業されている状態から、バックログのアイテムになるのです アカウンタビリティーの低下。** 階層化モデルは、エスカレーションと顧客対応のプロセスに基づいています。最前線のスタッフが問題を専門家にエスカレーションすることを求められると、アカウンタビリティーが低下し、インシデントからエンドツーエンドで学ぶ機会も減少します。 顧客にネガティブな体験をさせる。** 複数のサポート担当者に問いを繰り返さなければならなかった経験のある人なら誰でも、このことが顧客満足度にマイナスの影響を与えると理解してるはずです。

これは、サポート組織は階層型サポートモデルを廃止すべきである、と言っているのではありません。階層型サポートは、それほど深刻でない問題や単発の質問に対応するには非常に効果的です。しかし、重要で緊急性の高いインシデントになると、階層型モデル特有の非効率性が、最終的に顧客離れにつながる負の顧客体験をもたらす可能性があります。

IIntelligent Swarming℠は、オーソドックスな階層型サポートに代わるフレームワークを提供します。このフレームワークでは、キュー内の作業よりもリアルタイムの作業、サイロ内の作業よりもコラボレーション、一方的なエスカレーションよりもケースのオーナーシップを優先します。

インテリジェントスウォーミングモデルでは、チケットを受け取ったカスタマーサービス担当者が、その案件を最後まで担当します。サポートに階層はなく、お客様の引き継ぎもありません。チケットの所有者であるエージェントが解決できない場合、そのエージェントは即座に問題の「スウォーム」化を行う専門家チームを引き込みます。このような的を絞ったアプローチはインテリジェントスウォーミングと呼ばれ、適切な人が適切なタイミングで動員され、協調した対応を行います。これは、多くの人が対応策に参加しても、必ずしも問題解決に適した専門家であるとは限らないという、インシデントに対する協調性のないスウォーミングとは対照的なものです。インテリジェントスウォーミングのフレームワークでは、ケースオーナーが専門家チームと情報を共有し、解決に向けて協力し合います。

このモデルには、いくつかの利点があります。

この理論を実践するためには、カスタマーサービス担当者が適切な情報にアクセスし、専門家と協働できるようにする必要があります。つまり、組織全体からリアルタイムのサービス障害データを提供してもらうことです。また、運用チームとの双方向のコミュニケーションを可能にする双方向通信チャネルを確立することも必要です。また、機械学習機能を使って、顧客に影響を与える前にインシデントを特定することも可能です。

PagerDutyでは、サポートエージェントがインシデントの履歴コンテキストを可視化し、テクニカルリソースからの監視データを提供することで、問題の全体像を把握し、正しい解決策を特定できます。エージェントがチケットで助けを必要とする時は、PagerDutyの一連の機能を使って迅速に追加支援を引き出すことで、スウォーミングモデルをさまざまな方法で実現できます。

エージェントは、インシデントにレスポンダーを追加することで(「Add responders」という分かりやすい名前の機能があります)、PagerDutyで迅速にスウォームリクエストを始められます。これにより、組織全体から必要な専門家が直ちにループに入れられ、コラボレーションのための会議ブリッジを設定するオプションも用意されています。追加されたレスポンダーは、緊急性の高い通知ルールで通知され、重要な問題を見逃すことがないようにします。

PagerDutyのエージェントは、レスポンスプレイ(ボタンをクリックするだけでインシデントに対して実行できる定義済みアクションのセット)を利用して、スウォームの開始に関連する定番のワークフローを自動化することもできます。これらの定義済みアクションには、対応者の追加、カンファレンスブリッジの設定、関係者のインシデントへのサブスクライブ、ステータスアップデートの公開などが含まれます。レスポンスプレイは、特定のサービスに結びついたインシデントに対して自動的に実行されたり、PagerDutyを使っている誰もが手動で開始したりでき、実行されるアクションが問題の規模に適していることを確認できます。

最後に、PagerDutyはZendeskなどのチケットツールやSlackなどのChatOpsツールとネイティブに統合されているため、エンジニアリングチームと簡単に双方向のコミュニケーションが可能です。また、エージェントが使っているツールからPagerDutyのインシデントをトリガーできるため、コンテキストスイッチの必要がなく、適切なチームや専門家にすぐに接続して問題を解決できます。PagerDutyをオールインワンの対応オーケストレーションおよびコラボレーションツールとして使用することで、チームは簡単に問題をスウォーミングし、顧客とエージェントの両方にとってよりシンプルで合理的なエクスペリエンスを実現できます。

スウォーミングや階層型プラクティスを使用するかどうかにかかわらず、今日、あらゆる顧客問題をサポートするためのよく知られたアプローチが存在します。適切なスウォーミングの手法を事前に構築しておけば、適切なタイミングで適切な専門知識を自動的に活用できます。また、即時対応が必要でない重要度の低い問題については、階層化されたアプローチを自動化(自動エスカレーションポリシーやオンコール通知など)することです。

デジタルイノベーションとユーザーエクスペリエンスによって定義されるようになるパンデミック後の世界では、カスタマーサービス機能を強化する新しい方法を検討する時期が来ています。

Intelligent Swarming℠は、サービスイノベーションコンソーシアム™のサービスマークです。

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

2022年1月5日  (更新日:2022年8月30日)     |    インシデント&アラート

オンコールの人間模様:オンコール中のストレス、不安、生活を管理するための5つの教訓

DevOpsでは、オンコールプロセスについてよく話しますが、オンコール中の人間的な側面についてはどうでしょうか?例えば、シフト中のストレスや不安に対処する効果的な方法は何でしょうか?オンコール当番中に子供の世話をしなければならないなど、オンコールに専念しづらい生活状況とどのように両立すればよいでしょうか?また、共感的なチームカルチャーは、燃え尽き症候群や離職を防ぐのにどのように役立つのでしょうか? 2021年11月から12月にかけて、PagerDutyの9つのチームのオンコールエンジニアが集まり、オンコールの人間的側面についてディスカッションしました。ここでは、そのセッションで得られた5つの重要なポイントを紹介します。

チーム内の共感が重要である 一日中グラフを眺めていてはいけない ポストモーテムはストレスになり、多くの労力を要する 緊急性の低いアラートは、夜間のノイズを減らす 1週間のオンコールは燃え尽き症候群につながる可能性がある

それぞれの重要なポイントに入る前に、私たちが話を聞いたチームに関連するいくつかの指標を見てみましょう。

2017年12月31日  (更新日:2022年7月14日)     |    インシデント&アラート

運用コマンドコンソールの中でビデオ会議をするには

フェイスツーフェイスで話をする。

プラットフォームになることの大きな点の1つは、ユーザーが、自分とは異なる方向に製品を持っていけることです。 私たちはあなたの好みの電話会議ツールをインシデント対応プロセスに組み込めるようにしました。以前自分のインシデント対応にビデオ会議を追加するんだと冗談を言っていたお客様には、どうやってオペレーションコマンドコンソール に追加するかを教えましたけれど。

私は、インシデントの間に私のブサイクな顔を見たい人がいるなんて思ってなかったんです!

以下は私たちがやった通りのソリューションではありません、オーバービューです。

iframeに埋め込むことのできるビデオ会議ツールを使用します。この例ではAppear.inを使用しています。 サインアップのプロセスがないので。

操作コマンドコンソールを開きます(まだこの機能を試していない場合は営業担当者に相談してください)。インシデントのコンテキストで表示する場合は、これをワークフローの拡張にすることもできます。

コンソール設定に移動し、「カスタムURLモジュール」を追加します。 これはしばらくの間ベータ版であった機能で、顧客はチャット、wikiページ、エーテルパッド、ステータスページをこのように埋め込んでいます。 私のURLはht​tps://appear.in/diligent-quailでした。

以上でおしまいです!

これで自分のチームがオペレーションコマンドコンソールを使ってインシデント対応を調整しているときに、お互いの集中している様子見てほめあうことができます。 次は、Snapchatフィルタを追加する方法を理解する必要があります。

あなたのチームがPagerDutyプラットフォームを拡張した妙だけど素晴らしい方法はいくつあります? [email protected]で電子メールを送って知らせてください!

2017年12月20日  (更新日:2022年7月14日)     |    インシデント&アラート

良いインシデント対応が金融機関への顧客の信頼を増す

「そこには金があるから」。悪名高い銀行強盗Willie Sutton(注:William Francis “Willie” Sutton, Jr. (June 30, 1901 – November 2, 1980))が言ったように、金融機関はセキュリティ犯罪の最大の被害者です。サイバー犯罪者がセンシティブなデータや金融資産を盗もうとする試みを止めるために、金融機関ができることはあまりありません。被害が増えているために金融機関は顧客と規制当局からますます厳しい監視を受けています。

事実、FDIC(Federal Deposit Insurance Corp.、連邦預金保険公社)の審査員は、必要とされるインシデント対応の最小要件ht​tps://w​ww.fdic.gov/regulations/examinations/supervisory/insights/siwin06/article01_incident.htmlを参照 を提示して侵害が判明した場合、規制当局と顧客に通知することを要求します。

しかし多くの金融機関は、進行中の損害に対してクリティカルなインシデント対応をすることにかかりきりになってしまいます。これは時間を浪費するだけでなく、組織の準備が整っていない、あるいは適切なセキュリティ管理策を講じていないという印象を残してしまいます。

インシデント対応計画を立てておく

規制当局は金融機関の規模に関わらず、より広いリスク管理基準でITセキュリティを日常的に監視していることを明らかにしています。そのため、セキュリティ侵害防止対策だけでなく、インシデント対応の有効性についても、金融機関に説明責任を課しています。完全なセキュリティは存在しませんが、金融機関はセキュリティ侵害が発見された場合、ただちに対応できなければなりません。また、迅速な解決と異なる部門間で効率的な緊急連絡の手段を備えていなければなりません。

そのため、金融機関にはIT部門の問題解決の方法から、財務、法務チームが迅速に規制当局とやり取りする方法、必要に応じて顧客と市場に情報提供する方法に至るまでの、対応計画が必要です。ビジネスへのダメージを軽減するには、セキュリティ侵害が発生したときに重要なステークホルダーを関与させるための明確な枠組みが必要です。このようなシステムを導入することで、財務的、法的に重大な影響を及ぼす可能性を見落とさないだけでなく、金融機関とその資産が健全であるという安心感を顧客や株主に与えることができます。

情報共有

そのために、インシデント対応フレームワークは、組織と顧客に対するセキュリティ侵害の影響を緩和するための透明なプロセスでなければなりません。例えばIT組織内の全員がインシデントの影響を評価するための手続きを理解し、適切な専門家を迅速に動員し、基本的なトラブルシューティングや修復を実施できる必要があります。さらに、組織内のステークホルダーは、IT担当者が誰かを正確に把握できるだけでなく、問題解決にかかる時間を顧客に知らせるためにどんな言葉を使うべきかをリアルタイムで理解する必要があります。

このようなベストプラクティスは自然に出来上がるものではありません。ビジネスリーダーとITリーダーはトーンを調整する必要があります。組織が適切なプロセス(定例の研修や実践を含む)を用意していれば、セキュリティ侵害や他の形態のITトラブルに自然に対処できるようになります。金銭的損害の出るセキュリティ侵害よりも唯一悪いこと、そして顧客の信頼を失う最速の方法は、顧客が金融機関そのものではなく、他のソースから問題を知ったときです。そのため、顧客には迅速に問題の発生を知らせる必要があります。

もちろん、サービスに問題があることを顧客に伝えるのは当然として、その問題がいつ解決されるかも正確に伝えられないと、顧客は他の金融機関への乗り換えを検討し始めるかもしれません。チームに適切なプロセスとワークフローが整っているかを常にチェックしましょう。

2017年12月19日  (更新日:2022年6月14日)     |    インシデント&アラート

マイクロサービス時代のモニタリング

迅速性の高まりにつれて増大する複雑さの管理

DockerとDevOps革命のおかげで、マイクロサービスはアプリケーションを構築して展開する新しい方法として浮上しました。マイクロサービスのトレンドを受け入れる理由はたくさんあります。

マイクロサービスを採用する場合は、マイクロサービスアーキテクチャには多くの部品があることも理解しておく必要があります。 インシデント管理に関して言えば、マイクロサービスとモノリシックアーキテクチャの間に重要な違いがあります。 部品が多いほど、アプリケーションとインフラストラクチャの健全性と継続性を維持するために、監視と管理がより複雑になります。

マイクロサービスがいかにIT監視の課題を増やすか、そして増大する複雑さを組織がどのように処理すべきかを探ってみましょう。

マイクロサービスの定義

マイクロサービスは、他のマイクロサービスと組み合わせて完全なアプリケーションを形成する小さなアプリケーションコンポーネントです。 Dockerを使用してアプリケーションをデプロイする場合は、複数のコンテナで構成されている可能性があります。各コンテナは個別のマイクロサービスを実行します。

DevOpsはソフトウェアの継続的デリバリーを奨励しているため、マイクロサービスはこの数年間で普及してきました。管理者はアプリケーション内の特定のマイクロサービスの問題を追跡できるため、マイクロサービスとして配備されたアプリケーションは管理しやすくなります。アプリケーションの特定のコンポーネントへの更新では、アプリ全体ではなくそのマイクロサービスだけを再起動できるため更新するのも簡単です。以上のような理由から、マイクロサービスは継続的デリバリーを容易にします。

2013年にDockerが導入されたことで、マイクロサービスへの関心が高まりました。Dockerコンテナは、マイクロサービスのための便利なビルディングブロックを提供し、モノリシックアーキテクチャに従って設計されたレガシーアプリケーションをマイクロサービスモデルに移植しようとする際に容易な移行パスを提供します。

複雑さ:マイクロサービスのトレードオフ

マイクロサービスを採用している組織は、インフラに追加する複雑さを考慮する必要があります。モノリシックアプリケーションがマイクロサービスアプリケーションに変換されると、管理者が監視すべきパーツが増大します。

たとえば、フロントエンドとデータベースがそのアプリケーション専用の仮想サーバ上で単一のアプリケーションとして実行される、モノリシックなWebアプリケーションを考えてみましょう。このアプリケーションの監視は比較的簡単です。その一部がダウンすると、アプリ全体がダウンします。監視するホストは1つだけであり、対処するアラートも1つだけです。このようなアプリは、異なるポート間の接続やサーバとデータベースのプロセスを監視することで事足ります。

ここで、コンテナのセットとしてデプロイされた同じアプリを考えてみましょう。単一の仮想サーバでアプリケーションを単純なプロセスとして実行する代わりに、フロントエンドとデータベースのレイヤーを異なるプロセスとして実行しているアプリです。Dockerはたくさんのプロセスを起動します。スケールアウトするようなアプリでは、おそらく何百ものコンテナがそれぞれのプロセスを担当するでしょう。コンテナの数はアプリケーションの要求に応じて絶えず変化します。さらに、アプリケーションの統計を収集するなどのタスクを担当するコンテナも抱えることになります。アプリケーションの可用性とパフォーマンスを保証するには、Dockerデーモン自体はもちろんのこと、これらすべてのコンポーネントを監視する必要があるため複雑です。

念のために言えば、私はマイクロサービスが悪いアイデアであるとは全く考えていません。上記の例では、マイクロサービスバージョンのWebアプリケーションは、モノリシックバージョンよりもはるかに拡張性と機敏性が高くなります。スケールアウトの敏捷性には、監視作業を増やすだけの価値があります。

マイクロサービスを効果的に監視する方法

効果的なマイクロサービス監視戦略には、2つの事実に注意が必要です。

明らかなのは、マイクロサービスでは監視すべきコンポーネントが増えているということです。しかし利用するインシデント管理プラットフォームが多数のアラートを処理したり、トライアルを支援したり、適切な人にルーティングしたりする能力を十分に備えていれば、これはさほど大きな問題ではありません。さらに、マイクロサービスではアラートの量がはるかに多くなるため、インシデント管理プラットフォームではアラートノイズを減らす必要があります。関連するアラートをグループ化したり、必要な対応を関連付ける一方、対応不能なアラートは抑制する必要があります。

もう1つ、やっかいな事実は、マイクロサービスが複雑になると、管理者にとってインシデント管理の役に立つ情報の量も増えることです。これは良いことです。モニターするコンポーネントが増えれば、対処すべきデータが増えますが、その余分なデータを活用して問題を特定することができます。モノリシックアプリに関連するアラートは、単にそのアプリのどこかに何か問題があることだけを伝えるため、問題の内容を正確に把握することはあなたの努力次第です。しかし、マイクロサービスでは、個々のDockerコンテナからのアラートにより、管理者は事件の原因となったアプリ内の正確なマイクロサービスを特定することができます。そして、アプリケーションが依存する他のコンテナを中断することなく、そのコンテナのインシデントを解決できます。

マイクロサービスは、インシデント管理チームにチャレンジとチャンスの両方を提供します。インフラストラクチャはより複雑になりますが、インシデント対応をより効果的かつ容易に行うことができます。マイクロサービスのモニタリングの鍵は、モノリシックなアプリの監視とマイクロサービスで構成されたアプリの監視の違いを理解し、マイクロサービス対応のインシデント管理ソリューションとワークフローを適切に配置することです。

2017年12月22日  (更新日:2022年6月14日)     |    インシデント&アラート

コールを処理するのは誰?

今日の統合されたデジタルエコノミーでは、ほとんどの企業のITインフラストラクチャはもはやサイロ内に留まっていることはできません。統合の圧倒的なメリットは、新しいアイデアやソリューションを急速に発展させられることです。残念なことは、統合と接続性の向上は自分たちの会社とユーザーを、サイバー攻撃、コンピュータウィルス、インフラストラクチャの問題のリスクにさらすことにもなる、ということです。

組織がシステムを保護し、データと顧客を保護するための対策に投資することが不可欠です。組織は、何かが起こる前に明確なインシデント対応計画を策定しておく必要があります。侵害または顧客に影響を与えるインシデントの検出後には、応答チームを率いる人を探し、誰が関与する必要があるかを決めるのに時間をかけるべきではありません。必要なのは、包括的なインシデント対応計画であり、企業のリーダーシップを含む総合的な対応として事前に用意されていなければなりません。

インシデント対応チームはどこまで包括する必要がある?

インシデント対応チームを組織する際は、ITインフラ、開発、品質保証の担当者を含めるべきです。しかし、他にもその代表を含めるべき部門が多数あります。

会社のリーダーシップ

広報

法務

人事

顧客サービス

危機管理

インシデント対応チームは、インシデントに対する組織の対応を監督し指揮する責任を負うべきですが、リスクを軽減しインシデントが発生する前に予防することも義務付けられます。チームのフォーメーションは、まず適切な対応計画の策定に焦点を当てて、インシデントが発生しないように対策を実施する方向に移行する必要があります。インシデントの予防と対応にさまざまな部門が関与すべき理由と、その方法を決定するために各機能を見てみましょう。

会社のリーダーシップ

インシデント対応チームの創設と成功には、最高レベルの企業リーダーの積極的参加が不可欠です。リーダーの積極性は適切なサポートを可能にし、組織のあらゆる側面にわたるチームとの整合性を確保します。リーダーシップの関与は、インシデントのフォローアップにおいても重要です。インシデントに対応する各リーダーとビジネスの調整は、効果的で迅速に対応するために不可欠です。

広報

インシデントのフォローにおいて、広報担当者が企業とユーザーの主要な接点になります。広報活動の準備の中で重要な責務は、包括的な情報開示方針の策定と、他のチームと連携して、特定の種類のインシデントに対して実行可能なシナリオに沿って対策を実施することです。

法務

法務は、契約や企業責任を担当するチームとして、会社のデータと知的財産の完全性を保護するための法的枠組みを開発する重要な役割を担っています。インシデント発生直後の期間に、法務は会社の責任を決定し、開示および通知に関する法的義務が適切に処理されるようにリードします。

人事

人事には、インシデント対応チームの初期開発段階で、社内から来た人であろうと、組織外で雇用された人であろうと、適切な人材が適切に配置されるようにする責任があります。

人事にはさらに他のチームと協力して、機密データへのアクセスを含む従業員向けのポリシーを策定し、従業員にそのポリシーを教え、必要に応じて従わせる責任があります。

顧客サービス

企業の外向きの顔として、顧客サービスチームは、潜在的な脅威を見つけて報告し、ユーザーへ事態の状況を明確に伝えるという重要なポジションにいます。さらに、既存の情報開示方針に精通し、インシデントがいつ誰にエスカレートされるべきかを理解している必要があります。また、渉外担当者は、外部ユーザーとの作業の中で直面する可能性のあるデータセキュリティ要件と潜在的な脅威を熟知している必要があります。

危機管理

最後に、危機管理チームは、コンピュータセキュリティチームと協力して、リスクが発生する前にリスクを特定し軽減するポリシーを開発し実装します。また、他のチームと連携して脆弱性評価法を開発し、実施し、潜在的なインシデントの早期警告システムとして機能する脅威検出指標を設定して監視する必要があります。

強力な防御が効果的な攻撃を可能にする

インシデント対応はIT部門の責任ではありません。ITは、対応チームで重要な役割を果たしますが、組織全体の全チームの協調的な努力こそが、インシデントに対し統一され調整された対応を可能にします。企業がインシデントを処理するための強力な防衛戦略を策定したら、インシデントが発生する前にリスクを特定し、リスクを軽減することに焦点を当てるべきです。

2017年8月30日  (更新日:2022年6月13日)     |    インシデント&アラート

インシデントとアラートの違い

インシデントの定義は、 「システムの運用を通して提供されるサービスの中断、サービス品質の低下、 またはその可能性がある出来事」 つまり、「ディスクの使用率があらかじめ決めたしきい値を上回った」等の、 システム利用者には影響がなくても、サービスの品質が落ちる可能性がある出来事もインシデントとなります。

<<インシデントの例>>

■ システム運用者のインシデント

システムが利用できない プリンタで印刷できない アプリケーションのバグが見つかった システム運用監視ツールが発するアラート(警告)

■ コールセンターやヘルプデスクのインシデント

製品に不具合が出たので直したい 業務に必要なデータを書類にまとめてほしい パスワードを忘れたので再発行してほしい アプリケーションの機能を知らないので使用できない

このように障害だけではなく、課題、質問、要望もインシデントに相当します。 突発的な出来事で、迅速な対応が要求され、即座に対応しなければ被害が広がっていくものは全てインシデントとなります。

2017年11月2日  (更新日:2022年6月10日)     |    インシデント&アラート

規制産業のインシデント管理

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

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

まず、ソフトウェア関連のインシデントが規制業界で何を意味するのかを簡単におさらいしてみましょう。ソフトウェア開発や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/の抄訳です。

2017年12月8日  (更新日:2022年5月19日)     |    インシデント&アラート

ITOpsチームのためのインシデント管理:集中化を学ぶ

ITOpsチームはインシデント管理を集中化できますか? ITOps部門で仕事をしている人なら、その質問に対する最初の答えは、はっきり「いいえ」かもしれません。

結局のところ、ITOpsはあまりにも幅広く多様なことに責任を抱えているため、インシデント管理に関してはすべてを一つの傘の下に置くことはほとんど無理と思われるかもしれません。サーバの管理、デスクトップPCのプロビジョニングからヘルプデスクのサポートまで―業者の選定や管理には言及していませんが、ITOpsチームはすべてそれを行います。

これは、ITOpsを組織の他のほとんどの部門と大きく違うものにします。プログラミング部門の場合は、コードリポジトリを使って開発プロセスとバグ管理プロセスを集中管理できます。 営業部門なら、Salesforceのような集中型プラットフォームを使用して、製品と顧客の連絡先を管理できます。でもITOps部門ではそうはいきません。非常に多くの異なるタスクをカバーしているからです。

ここでは、ITOpsの集中インシデント管理が単なる夢物語だとは限らないことをお伝えします。確かにITOpsは非常に多くの多様なジョブを処理しているため、1つであらゆる組織の問題を監視して対応できるプラットフォームはありませんが、インフラストラクチャ全体のインシデントを管理は一元化できます。

どうやって? その答えは、ITOpsワークフローのさまざまな要素を統合できるインシデント管理ツールを使うことです。

監視サービスを最大限に活用する

ITOps自体が集中化されていない場合でも、ITOpsチームがインシデント管理を集中化する方法について基本を説明しましょう。

あなたが中小企業のITOpsのプロフェッショナルであれば、3つの主要なインフラを把握しておく必要があります。1つ目は、ローカルファイル共有をホストしたり、いくつかのWebサイトを提供するために使用する社内サーバです。 2つ目はデータをバックアップしているパブリッククラウドです。 3つ目はローカルのワークステーションで、常に稼働状態にして、オンプレミスとクラウドのサーバに接続している必要があります。

このインフラの各部分のインシデント管理を計画するのは難しいことです。一部の監視システムは、ベアメタルサーバ、クラウドインフラストラクチャ、そしてPCを等しく良好にサポートできると主張しているものがあります。しかし、もしそうなら、おそらくどの分野にも特化した機能を持っていないのでしょう。そういうシステムは、特定の種類のインフラ向けに設計された高度な機能を持たずに、一般的な監視機能だけを提供しているのです。

ですから、単一の監視システムでカバーしようとするのではなく、各インフラの特質に合わせて調整された監視サービスを複数組み合わせて使う方がよいでしょう。クラウドの場合は、AWS CloudWatchなどのクラウドセントリックの監視システムを使えば最大の効果を引き出せます。 SolarWindsは、オンプレミスのデバイスやローカルネットワークに便利です。 Splunkのようなものを使えば、多くのデバイスが吐き出しているすべてのログデータを分析することもできます。

すべてを統べるたった1つのインシデント管理ツール

ここで紹介した各監視プラットフォームには、アラートまたは通知システムが付属していますが、通知は必要十分なほどロバストではない可能性があります。たとえ十分ロバストであっても、ITOpsチームは、いくつかの異なるプラットフォームからアラートを(しかも異なるフォーマットでいろいろな種類のコンテンツを)一度に受け取りたいとは思いません。そんな状況では、適切なアラートが適切な人に適時届いているかどうかを確認するのはまず無理です。

同じく重要なことに、通知をチームにどのように配信するかを集中管理することもできます。たとえば、監視サービスの中には、SMSアラートをそのサービスだけでは出せないものがあります。通知を必要な形式に変換できる集中管理型のインシデント管理プラットフォームとこれらのサービスを連携させれば、必要に応じて管理者の電話に通知を転送できます。

最後に、集中管理されたインシデント管理ソリューションを使うと、冗長なアラートを回避できます。ネットワークが過負荷になると、ネットワークスイッチを監視しているサービスからの通知だけでなく、サーバ上の監視スタックまで通知を出し始める可能性があります。

同じ問題に起因する複数のアラートを受信すると、チーム間で混乱が起こり、対応にかかる時間が長くなります。これとは対照的に、集中管理されたインシデント管理では、監視システムごとではなく、インシデントごとに通知を受け取ります。したがって、ノイズは少なく、何が起きているのかはすぐに分かります。

通常、ITOpsワークフローにもう1つのツールを追加すると、余分なだけに見えるかもしれません。多くの状況ではそうかもしれませんが、インシデント管理の場合、PagerDutyのような通知を集中管理するソリューションを実装することで、既に導入済みの監視ツールからさらに多くの価値を引き出せます。

2018年1月2日  (更新日:2022年5月19日)     |    インシデント&アラート

IoTのインシデント管理を助けるPagerDuty API 2.0

Internet of Things (IoT) は、世界中の企業や人々の生活に普遍になりつつあります。それは目新しいものとして始まりましたが、最近ではもっと革新的でミッションクリティカルに使われるケースが出てきています。利用できるIoTデバイスが多様になり、生成されるデータも膨大になっているなか、さまざまなセキュリティ上の脆弱性が露わになり、IoTデバイスを製造する企業は多数の課題に直面していますが、ここでもインシデント解決プラットフォームが役立ちます。今日IoTシステムを構築している場合、または今後IoTシステムを構築する予定がある場合は、ベストプラクティスのインシデント解決ソリューションに投資して、IoTシステムを確実にレジリアント( 弾力性に富み) かつ安全にすることが不可欠です。

IoTシステムには統合が必要

IoTシステムには本質的な複雑さがあるため、エンドツーエンドの監視と統合が不可欠です。非常に多くのデバイスが存在し、すべてがインターネットに接続され、家庭にデータを戻してくるので、使われるのを待つだけの大量のデータがあることになります。ユーザーがIoTデバイスを使うと、使用時間と頻度、使われている機能など、詳細な使用パターンにあなた(注:サービス提供側)はアクセスできます。

監視、ロギング、およびITSM(ITサービス管理)ツールとの統合は、IoTに大きな違いをもたらし、IoTデバイスの開発者が一息つくことができます。PagerDutyのようなソリューションは、すべてを集中管理されたダッシュボードで管理し、ルールを定義してイベント管理の手順やワークフローをカスタマイズできるようにしてカオスを防ぎます。

PagerDuty APIバージョン2.0を使うとまさしくこれが可能になります。このAPIを使用すると、アプリの通知とアラート管理がよりシームレスでカスタマイズ可能になります。あなたのアプリにPagerDutyを埋め込めるだけでなく、PagerDutyにあなたのアプリを埋め込むこともできます。PagerDutyの機能は、必要なデータを表示するためにあなたが独自のダッシュボードを埋め込むことでさらに拡張できます。Custom Event Transformer(カスタムイベントトランスフォーマー)があればJavaScriptを使い、通常のデータを価値がある、そして正規化されたインシデントに変換し、PagerDutyとのカスタム統合が実現できます。

PagerDuty APIによるさまざまなIoTの統合例

PagerDutyのAPIがIoTの革新に影響を与えた事例はたくさんあります。

Resinio

Resin.ioは、IoTのクライアント、サーバ、およびデバイスプラットフォームであり、PagerDutyを使用してIoTインシデント管理を処理します。Resin.ioのようなソリューションは、DevOpsの原則と利点をIoTの世界にもたらします。Resin.ioの他の利点には、Linuxカーネルの採用も含まれており、おかげでIoTデバイス用に独自のソフトを使う必要がなくなります。これにより、開発がより身近なものになります。

Temboo

さらに、Tembooはセンサーモジュールを使った駐車場管理にPagerDutyを使っています。IoTセンサーは警報をトリガーすることができ、駐車スペースが利用可能かどうかを知るためにセンサーデータを使えるようにします。TembooとPagerDutyは、高齢者の介助にセンサーを利用することもできます。センサーを老人の生活エリアに設置すれば、手助けを求めている時に家族が通知を受けることができます。

AlertSite

別のツールで、SmartBearのAlertSiteは、IoTの品質チェックとAPIテストに役立ちます。これらのテストは手動で行う必要はなく、AlertSiteが実行を自動化します。本質的には、それは統合された複合型の監視プラットフォームであり、テスト場所から直接迅速なアラートを送信する機能や、エンドユーザーの動作をエミュレートするアラート機能も含まれています。PagerDutyはAlertSiteと統合することで実現される、最先端のエンドツーエンドのインシデント解決機能により監視機能を強化します。

起こる前に不正を防止

倫理的なハッカーは、インターネットに接続されているデバイスが、さまざまな手段で悪用されることを明らかにしました。例えばユーザーにトラブルをもたらすために機能を悪用したり、デバイスを使ってDDoS攻撃をかけるといった手口を繰り返し明らかにしてきました。インシデント管理は、IoTチームにデバイスに潜在する誤用、悪用の可能性を警告するための重要な保護層であり、特に異常に動作が起きた場合は、調整された応答をトリガーします。

インシデント管理は、それをすること自体が目標と見なされるべきものではありません。IoTが存在するためのより安全な環境を作り出すことは非常に重要です。IoTは、これまで決してできなかったような方法で人々の生活を改善することを目指しています。デバイスがそのような重要な役割を果たしている場合、インシデントの防止と修復はこれまで以上に重要になります。PagerDuty API V2.0は、IoTセントリックな未来のためにPagerDutyプラットフォームを準備するものであり、エンドユーザーと開発者のエクスペリエンスをより快適で、拡張性があり、信頼できるものにする無限の可能性をもたらします。

<  123  >