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

2017年12月22日  (更新日:2022年5月13日)

Firefightに必要なインシデント管理ツール

火事が発生する前に適切なツール を用意することが重要です。適切なツール がないと、大規模な停止を認識し、整理し、解決することがはるかに難しくなります。事前にベストプラクティスが確立されていれば、困難なインシデントをよりスムーズに処理できます。

以下は、障害発生に備えたプランを網羅したリストではありませんが、問題の調整と準備のための組織の能力を大幅に向上させます。

  1. 内部コミュニケーション

内部のコミュニケーションは通常電子メールで行われます。これは、いくつかの理由で問題があります。電子メールは1対1のメディアです。つまり、送信者と受信者だけが読み取り可能であり、迅速なステータス情報が必要な場合は解析が困難です。SlackやHipChatなどのコラボレーション環境は、情報を伝達するために外部ホストを利用します。これらは、全員への公開チャンネル、登録者のみに公開されるチャンネル、あるトピックについてのチャンネルなどを提供します。クリティカルレベルでは、ステータスの更新(または問題が既に分かっており、作業中であることを伝えるメッセージ)を、主要なスタッフ(サポート、リーダー)にほぼリアルタイムで提供することができます。

  1. アプリケーションのパフォーマンスとインフラストラクチャの監視

本来、チームは顧客より先にアプリケーションに問題があることを知るべきです。アプリケーションやインフラストラクチャの監視技術は、修正や更新が必要なときに役立つかどうかの情報を提供します(New RelicやAWS CloudWatchなどがこれにあたる)。また、PagerDutyなどのソリューションを使い、アプリケーションのパフォーマンスとインフラストラクチャのパフォーマンスを監視することも重要です。問題が発生した場合は、全サービスの正常度データを単一のビューに統合し、緊急行動が必要な場合はオンコール担当者に通知します。アプリケーションとインフラストラクチャの両方が可視化されていれば、問題解決ははるかに簡単です。

  1. ステータスの更新

パフォーマンス上の問題が発生した場合、サポートチームに更新要求が殺到します。この流入を緩和するための主な方法は、Twitter、ステータスページなどを利用すること、またはPagerDutyのような製品を使うことです。これらは、主要インフラストラクチャとは別のインフラ上で稼働し、サイト全体が停止しても動き続けることが必要です。Twitter上では、ユーザーがピントゥイートと最近の返信を簡単に探すことができます。ユーザーはstatusapp.comで「黄色」または「赤」のステータスを確認することもできます。statuspage.ioのような読みやすいステータスページは、ダウンタイム中に情報を顧客に伝えるための重要なコンポーネントです。ユーザーはトラブルの際の情報が正確で更新が適切に行われている場合、そのページに信頼を置きます。そうすれば、彼らはあなたのビジネスにもっと信頼を寄せるでしょう。また、トラブル対応の最中にも情報の更新と各主要サブコンポーネントのステータスを知らせる必要があります。これらの更新は、完全な可視性を担保するために数分ごとに行われるべきです。最後に、PagerDutyのステークホルダーエンゲージメントのような機能により、インシデント担当者は、任意の優先通知チャネル(電話、SMS、電子メール、またはプッシュ通知)を介して、事前定義されたビジネス関係者のグループに到達するステータス更新を簡単に送信できます。ステークホルダーは、インシデント状況の更新を購読して、顧客に影響を与える問題についてリアルタイムの情報を得ることもできます。

  1. チケットソリューション

ZenDeskのようなチケットソリューションは、停電を管理するために絶対に重要です。重大な停止は破壊的であり、信用を失うことにつながります。チケット管理システムは、アプリケーションモニターが見逃した間欠的に起こる問題を特定するのに役立ちます。また、サポート要求に対して情報を公開します。問題のエスカレーションのワークフローは、特に大きなサポートチームにおいて、個々の判断に頼るよりも迅速な問題解決を導きます。あらかじめ用意されたメッセージは、システム停止中にメッセージの一貫性と正確性を維持するのに役立ちます。また、「related to」タグを使うと、問題が解決された後で簡単に報告することができます。

  1. プロシージャのトラッキング

適切な手順を講じることで、組織はアプリケーションから発生する可能性のある問題を予測できます。これらのシナリオは、事前に文書化する必要があります。トラブル対応、障害緩和、修復に関する情報は、チームのために文書化されるべきです。この文書には、誰が何をすべきかという職務チェックリスト、緊急連絡先電話番号とオンコール担当者の名前も入れておきましょう。もし可能ならば、模擬停電の訓練が、実際の停電が発生した際の対応に役立ちます。その後、訓練終了後、事後検証チームと一緒に検討し手順を改善してください。別のトラブルが発生した際、プロセスに追加できる情報があれば追加します。上記の他の項目と同様に、ローカルのインフラが利用できなくなる可能性があるため、これらのプロシージャを外部にホストされたリポジトリに格納するか、PagerDutyなどのソリューションで自動化することをお勧めします。

これらは一連のリストの最初のいくつかに過ぎません。トラブル時に有効だったことを記録しておくのは、事前に理解して準備するために費やされた時間と同じくらい貴重です。社内外のステークホルダーとのコミュニケーションはIT業界だけでなく、あらゆる業界にとって重要です。

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

買うべきか作るべきか?

典型的な技術者はたった1つの質問ですべての課題に対峙します:「私は自分でこの ソリューションを構築できるだろうか?」と。そしてこの質問は重要な考察が得られるので十分考えるに値します。 では私たちは作るべきですか?買うべきですか? インシデント管理ソリューションの評価は今この問題を招いているようです。 しかし、今インシデント管理プラットフォームを作るべきか、あるいは購入するべきかは、どう分かるのでしょうか?

なぜビルドするの?

独自のソリューションを構築したいという願望が、商用ソリューションの調達権限があなたにないという単純な理由によることもあります。 例えばエンタープライズのITにはツールの予算があっても、DevOpsチームがそれを必要としていたりします。 オープンソースプロジェクトを基にソリューションを構築する方が、商用ソリューションを購入するのに必要な長い駆け引きをするより簡単に思えるかもしれません。 しかし、これは組織的な問題であって、技術的な問題ではありません。 そしてカスタムビルドのソリューションは短命になることがよくあります。

でも独自のソリューションを構築する理由は他にもあります。

現実のまたは既に必要が見えている固有の要件がある

セキュリティとプライバシーに関する懸念がある

コスト

これらは、インシデント管理ソリューションの構築を検討する正当な理由ですが、どれも精査する必要があります。

あなたの要件は本当にユニークですか? これが当てはまるかどうかを特定する方法は、競合他社と彼らが使っているものを見て、さらに類似の組織と比較して要件を調査することです。同時に、独自の要件があっても、なぜそれがユニークであるのか疑問に思うかもしれません。それって本当に必要なの?と。

セキュリティに関しては、商業的なインシデント管理を使わないようにさせるようなセキュリティとプライバシー上の懸念は何ですか?データが暴露される可能性がありますか?ほとんどの場合、アプリケーションのデータはアラートの中に含める必要はありませんが、そうなっている場合は、検討する必要があります。一般的なセキュリティに懸念があるのなら、ベンダーは自らが常にセキュリティの脅威に敏感であろうと努めていることを知っておいてください。多くの場合彼らはあなたの社内の運用チームよりもセキュリティの面ではるかに優れた能力を持っています。

そして、コストの問題があります。 独自のソリューションを構築する上で最もコストのかかる側面は簡単には数字にならないため、コストの計算は難しいのです。インシデント管理サービスの月額料金と、フルタイムの開発者による一回きりの開発のコストを計算するのは簡単です。しかし、継続的なメンテナンス、機能の変更、および大きな一回切りの開発のコストを予期することは困難です。このソリューションを構築していない場合に、開発者は何をしているんでしょうか?また、開発中に複数のプロジェクトやバックログを脇に置いてしまうコストはいくらですか?構築した人が退社した場合に別の問題が発生します。残されたコードベースを理解するためにまたコストがかかります。組織のインフラストラクチャのミッションクリティカルな部分に関連している場合、知識を持つ人が組織を離れることは望ましくありません。

インテグレー?

インシデント管理ソリューションの構築には、1つに大きな弱点があります。成功したインシデント管理プラットフォームには、ソース(アプリケーションとインフラストラクチャなど)とディストリビューション(コラボレーションツールなど)への統合に関する膨大なライブラリが用意されています。これらの統合を実現するためには開発者は新しいAPIに対して習得し、構築する必要があり、かなりの時間がかかります。独自のインシデント管理プラットフォームを構築する組織は、いろいろなユースケースをサポートする必要がなく、重要な統合を行うだけで済みます。

しかし、これらのシステムのAPIが変更されると、あなたは盲目になる可能性があります。新しい機能を使えず、プラットフォームを完全に壊す可能性があります。オープンソースプロジェクトは、統合の中での変化に、あるいは新しいものを作リ出すために素早く対応することはありません。何か不具合が生じた場合も、開発者はもう別の何かを抱えています。もちろん、インシデント管理システムと統合する必要のあるツールの選択は、チームの規模の拡大とそのニーズの変化に伴って変化する可能性があります。

ビルドする時期

オープンソースプロジェクトを基盤とするカスタムインシデント管理プラットフォームが有用なシナリオがあります。それは特定の目的のためのビルドが必要という、とてもニッチなシナリオです。一般的に、このようなソリューションが必要な組織は、グローバルでの商業的インシデント管理を行っており、ニッチなシナリオのためにインシデント管理プラットフォームのAPIに統合していることさえあります。

もう1つの目的は、アプリケーションまたはインフラストラクチャのサポートとは異なるコンテキストで使用されるアラートのためです。おそらくそのアラートはコラボレーションや製品管理に使用されています。このような場合は、自社で作った他のユースケース向けの責任の低いシステムと、商用およびミッションクリティカルなインシデント管理システムとそのユースケースを分けたほうが有用な場合があります。アプリケーションの使用方法から学ぶことについては同じことが、すでに多くのカスタマイズを行っているチームにも当てはまります。例えば、新しい機能がローンチされたときに、その機能が使用されたらアラートを受け取るということができます。また、新しいインフラストラクチャが配備されたときに、パフォーマンスを示す特定のKPIにヒットしたときにアラートを表示させるように設定することもできます。

もう1つの理由は、内外へのデータ漏えいの懸念がある場合です。例えば、是正措置が個人を識別できる情報を、内部のティア1のサポートに、その人たちには見る権限がないのに晒してしまうアラートです。これは問題であり、特に規制産業では問題となる可能性があります。 ほとんどの場合あなたはプラットフォームでの役割と見られる内容を変更できるため、これは問題にはなりません。一般的に言って、あなたはそれを常に試すようにするべきです。避けられない場合もまれにはあるでしょう。

あなたの輝く時間が来る

熟練した技術者は、自分の興味の範囲を超えて、いつビルドや購入をするのが適切かを判断し問題を解決できるようになります。このソリューションは早速作り始めるべきで、立ち止っていてはいけません。これはカスタムソリューションに伴う長期的なサポートであり、リスクです。ソリューションの作成だけでなく、実行する必要もあります。インシデント管理システムにインシデント管理システムをインストールしているんですか?他の何かの稼働時間を心配することはストレスであり、インシデント管理がダウンすると、何も見えなくなります。

コードベースとインフラストラクチャへのカスタムニッチの統合を理由に、独自のインシデント管理ソリューションを構築することが正当化されることがあります。あるいは、商用インシデント管理と連動する非ミッションクリティカルなユースケースがある場合は、独自のインシデント管理を構築する価値があります。しかし、一般的に商用ソリューションの総所有コスト(TCO)は低く、規模の拡大に合わせてニーズに対応し、特定の専門家が退職したときにツールやプロセスが破壊されないようにし、キュリティとプライバシーに関する懸念にもより良いカバレッジとソリューションを提供します。

ビルドや購入を決定するときは、機会費用に重点を置くことをお勧めします。これはあまり知られていない費用ですが、これを考えると普通はかなり早く答えがはっきりします。

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

災いの後で:過去のインシデント経験から学ぶ方法

インシデント 管理の主な目的は、インフラストラクチャ に影響を与える問題を特定し解決することですが、インシデント管理業務はそこで停止するべきではありません。

お客様のチケットに反応するだけではなく、アラートシステムが生成する豊富なデータを活用すれば、問題を事前に検出しインフラストラクチャをより弾力的に運用するための洞察を得られます。

ここでは、データの収集と分析の方法、情報を扱う際に探すべき点など、過去のインシデント管理データを扱うための戦略の概要を説明します。

データの保存と標準化

過去のインシデント管理データを分析するための第一歩は、情報を収集して解析する標準化された方法を見つけることです。しかしながら、Screen-Shot-2017-12-14-at-11履歴ログの量と形式がさまざまな監視システムによって大きく異なるため、困難な場合があります。

いくつかの監視システムは、事後に調べることができる記録をまったく残しません。たとえば、Pingdomはリアルタイムモニタリングのための優れたツールですが、昨日のことではなく、今起きていることを伝えるように設計されているので、独自の履歴データをあまり提供しません。

他の監視システムは、限られた期間だけデータを保管したり、扱いにくい形式で保管したりします。たとえば、Snortのデータを分析するにはパケットダンプを調べなければならない場合があります。金曜の夜にWiresharkにハマるのが好きでない限り、やっかいな仕事です。

さらに、多くの監視システムを設置している場合は、違う場所にバラバラにデータをダンプする可能性があります。いくつかのツールはローカルマシン上の/var/logにログを書き出します。ローカルマシンのログは見逃しやすく、メンテナンススクリプトで削除されることもあります。あるいは、一定ではない期間ログをクラウドに保存したりします。これは、すべての履歴データを一度に分析するには理想的とは言えません。

これらの理由から、インシデント管理データを最大限に活用するには、次の2つのことを確実に行う必要があります。

アラートとログを中央の収集ポイントに送信します。モニタリングシステムや ローカルストレージがそれをサポートしていれば、必要に応じてアラートやログを保存できます。 収集ポイントのデータを標準フォーマットに変換し実用的な洞察を抽出します。

これにはLogstash、Splunk、Papertrailなどのツールが役立ちます。 これらは、サイロ化された場所からデータを収集し、中央のストレージポイントに転送できます。

PagerDutyは以上のソースや他のソースからデータをインポートし、標準化されたフォーマットに変換してパターンや傾向を可視化し、データの集中化と相互関連付けを行い、根本的な原因などを特定することができます。

データの表示と分析

データを表示する最も簡単な方法は、Webベースのインターフェースを使用する方法です。ログから特定のイベントを検索したり、インシデントの現在のステータスを監視したりするために使用できる洗練された検索機能が求められます。

Webインターフェースは、小さな傾向の発見、特定タイプのインシデント履歴のトレースから、全体状況の理解まで可能にしてくれます。アラートの表やリストは、システム全体の傾向を理解するのに役立ちません。 PagerDutyがレポートに含めるようなインシデント管理データに基づく可視化は大規模な情報の解釈に役立ちます。

特にプログラムでデータを分析する場合は、必要に応じてログデータをエクスポートできるAPIが重要です。 PagerDutyのAPIを使用すると、必要な形式でログデータを簡単に収集しエクスポートできます(Events API v2では、そのデータをすべて共通の形式に自動的に正規化します)。

何を探すか

データ分析をしたら、次に何を探すべきでしょうか。 監視しているインフラストラクチャのタイプによって異なりますが、一般的に注意すべき点は次のとおりです。

インシデントが発生している頻度。この数が時間の経過とともに変化する場合は、その理由を知りたいでしょう 平均認識時間(MTTA)と平均解決時間(MTTR)。これらの時間を把握することで、チームがインシデント管理をどの程度効果的に処理しているかを知ることができます。 チームの誰が最も多くのアラートを処理しているか。これはメンバーの評価基準になるだけでなく、アラートが適切に配分されているかどうか、そして最適な人に届けられているかどうかの判断基準になります。たとえば、1人の管理者が応分の分担以上のアラートを受け取っているときは調整する必要があります どの監視システムが最も多くのアラートを生成しているか。上記のように、さまざまな監視システムからのアラートを1つのログ記録場所に統合すれば、最も多くの情報を提供しているシステムを特定することができます。システムのパフォーマンスが低下しているかどうか、またはノイズが多すぎるかどうかを確認し、必要に応じてしきい値を調整できます。

これらのヒントに従えば、悲惨な歴史を繰り返すことはありません。

それがインシデント管理がいかに実を結ぶかです。 インシデント対応は治療行為ですが、過去のインシデント管理データを含むフィードバックループを継続的に作成すれば、インシデントの予防も可能になります。

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

次世代インシデント管理:スクリプト化されたインフラストラクチャ

Chef、Puppet、Ansibleのような構成管理ツールの大きな利点は、データセンターを「スクリプト化された」インフラストラクチャに変えることです。人生の時間を無駄にするサーバのプロビジョニングや設定を手動で行う代わりに、構成ツールで自動化することができます。

ただし、これらのツールはインシデント管理を自動化するようには設計されていません。他のIT業務がスクリプト化されているときにインシデント管理だけを手動で処理する理由はありません。インシデント管理もスクリプト化されたルーに統合すべきです。インシデント管理のためのスクリプト化されたインフラストラクチャアプローチを採用することで、監視とアラート管理だけでなく、残りの操作も拡張できます。

問題

まず、インシデント管理に対するスクリプト化されたインフラストラクチャアプローチが非常に重要である理由について説明します。

まだ手動でインシデント管理、自分を責めないでください。あなたは悪い管理者ではなく状況の犠牲者です。最近まで自動化されたインシデント管理ソリューションは、Chefのようなインフラストラクチャ管理ツールを容易に利用できませんでした。

インシデント管理の要件も、今日のように常に複雑ではありませんでした。10年前のデータセンターには、たいていの場合、数十台のオンプレミスサーバがあり、手動でインシデント管理を処理できました。

しかし今日、インフラストラクチャは、拡張性と迅速な製品革新の要求から、ますます複雑なものになっています。オンプレミスのベアメタルサーバがあり、ローカル仮想サーバがあります。クラウドサーバ、コンテナ、モバイルデバイスもあります。IoT革命が本格化した今、まもなく冷蔵庫と電子レンジとパーキングメーターを追加する必要があるかもしれません。

これらすべてのデバイスでインシデント管理を効果的に実行したい場合は、可能な限り反復的な手作業を排除する必要があります。これを実現するには、急増するデータセンターインフラストラクチャの構成を自動化するのと同じ方法で、自動化およびスクリプト化が可能な次世代インシデント管理ソリューションが必要です。

ソリューション

スクリプト化されたインフラストラクチャの時代にインシデント管理を効果的に処理するためには、

適切な人にアラートを自動的にルーティングする。適切な人に問題を通知するのに手作業が入れば、プロセスは壊れてしまいます。

インシデントを自動的にエスカレーションします。ここでもまた、人々が行動を取ることを忘れ、特に巨大なインフラストラクチャを持っている場合は、人間が手作業で問題を再割り当てするのを待つことはできません。ChefとPuppetがサーバーを自動的に構成するのに十分なほどスマートなのと同じように、あなたのソフトウェアはあなたのために十分にスマートである必要があります。

スケーラブルにアラートの動作を管理します。インフラストラクチャスクリプトツール便利な理由の1つは、既存のリソースを最も効率使用することに優れているからです。彼らは、クラウド内のどこに仮想サーバを配置すべきかを知っています。同じように、インシデント管理ツールは、アラートを適切なサービスやチームに自動的にグループ化し、無駄なアラートは抑制してルーティングすることができるため、ノイズが減り応答時間が短縮されます。

ChatOpsと統合することで、インシデント管理作業から通信プロセスを切り離すことなく、チームがインシデント対応に協力できるようになります。さらに、チャットボックスを通じて、ChatOpsは特定のレスポンスタスクを自動化するのに役立ちます。

すべての監視ニーズをサポートします。AWS Cloudwatch、Nagios、Pingdomなど、複数の監視ツールを利用している可能性があります。インシデント管理をスケーラブルかつ自動化するために、これらのツールは手動による介入なしで連携する必要があります。すべてのソースからのアラートを自動処理するインシデント管理戦略で、あるアラートだけを除外するのは、他のすべてのインフラストラクチャをPuppetで構成しながら1つだけ手動でプロビジョニングするのと同様に問題があります。イベントを自動化されたワークフローに変えることができるソリューションで、すべてのツールを集中管理することが重要です。

100%の稼働。私はオンプレミスの通知だけに頼ることが悪い考えであることを思い出すために、この点を常に念頭に置いています。私はNagiosを愛していました。しかし、今日、アラートを届けるためにローカルで稼働するNagiosのようなツールだけに頼っていると、インフラストラクチャに問題があった場合、インシデント管理システム自体がダウンするリスクがあります。Nagiosを使用するのは良いことですが、残りの監視システムからのアラートを、インフラストラクチャの問題の影響を受けない集中型のクラウドベースのインシデント管理ソリューションに供給する必要があります。

レガシーなアラートと監視システムだけで作業していた場合、上の要求リストはファンタジーのように見えるかもしれませんが、そうではありません。スクリプティングされたインフラストラクチャがデータセンターを自動化するのと同じくらい効果的に、すべてのイベントに対して迅速なレスポンスワークフローを自動化するインシデント管理ソフトウェアがここにあります。あなたの仕事をはるかに生産的で効果的なものにするために、今はそれを活用する時です。

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

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

小売業向けインシデント管理法

近年、1年で最も忙しいショッピングデー「ブラック フライデー」(注)にシステム障害が多発しています。

有名ブランドのWebサイトの停止やシステムトラブルの記事を目した管理者は、他人事とは思えないでしょう。大規模な小売業者でもスムーズにインフラストラクチャーを稼動させるのに苦労しているというのに、中小企業はどうすれば障害を防止できるでしょうか。

幸いにも、手はあります。適切なインシデント管理手順に従うことで、小規模のチームでも必然的に起こる業務の中断による影響を最小限に抑えることができます。

ここでは小売業者のニーズに焦点を当てて解決法を紹介します。

(注;ブラックフライデー(英語: Black Friday)とは、小売店などで大規模な安売りが実施される11月の第4金曜日のことである。 アメリカ合衆国では感謝祭(11月の第4木曜日)の翌日にあたり、正式の休暇日ではないが休暇になることが多い。当日は感謝祭プレゼントの売れ残り一掃セール日にもなっている。買い物客が殺到して小売店が繁盛することで知られ、特にアメリカの小売業界では1年で最も売り上げを見込める日とされている。また、年末商戦の幕開けを告げるイベントでもある。 )

小売業者の優先順位の定義

小売業者の効果的な監視とインシデント管理を行うために、管理者はまず、インフラストラクチャの可用性と稼働時間に関して小売業者の最も重要な要件が何であるかを理解しなければなりません。

実店舗とオンラインショップの両方を備えた最新の小売業者にとっては、以下を確実に行うことが不可欠です。

顧客がアクセスするWebサイトを常に正常に稼動させる。** 顧客が接触するサイトがパブリックなインターネット上にあり、DDoS攻撃など悪意のあるトラフィックスパイクからクラッシュする可能性や不正侵入の脅威があるからです。Webサイトは販売促進のために実店舗のみの小売業者にも不可欠です。顧客は通常、オンラインで購入するか店舗に足を運ぶかにかかわらず、購入を計画するためにWebサイトを使用します。

バックエンドシステムの稼動を維持する**。在庫の追跡やトランザクション履歴の保存などのタスクを処理するバックエンドサーバも、ビジネスオペレーションにとって不可欠です。一般にバックエンドサーバはプライベートネットワーク上で実行できるため、パブリックサイトよりも攻撃者から保護しやすいですが、一方で別の脆弱性も持っています。非常に機密性の高い情報が保管されていたりするので、効果的なモニタリングが不可欠です。

POSシステムの安定稼働を確保する**。小売業者はPOS端末がクラッシュした場合、販売を続けられなくなります。POSシステムを稼働させ続けるには、ローカルネットワーク接続から物理的なセキュリティ、さらに電源供給まで、複雑な変数の組み合わせを効果的に管理する必要があります。

IoT資産を保護する**。小売業もIoTを活用してワークフローをパーソナライズし、自動化することでデバイスとセンサーの安定稼働と接続性を保証し、業務を強化します。高度に自動化されたIoTデバイスベースのビジネスオペレーションへの移行は、システム監視の分野でも新たな課題となります。

これらは、取引完了を確実にするための小売業者の第一の要件です。ここでは、監視とインシデント管理を使用して重要な課題に対処する方法について説明します。

システムダウンの防止

小売業のシステムインフラの重要な部分を円滑に運用するためのガイドラインを紹介します。

インフラストラクチャ全体の可視性を最大化する**。非常に多くの要素があるため、小売業者は特に複雑で多様なITインフラを持つ傾向があります。それはWebサイトだけでなく、バックエンドシステムや各種専用デバイス、センサーなども含みます。このようなインフラストラクチャを把握するために、全面的な可視化が必要です。監視情報はそれを理解する唯一の方法であるため、1カ所に集中させる必要があります。

柔軟な監視ソリューションを導入する**。多様なインフラストラクチャには、多様な監視ツールが必要です。小売業者は、インフラストラクチャのさまざまな部分にすべて監視エージェントをインストールし、収集した監視情報を中央の管理プラットフォームへ転送し、正規化する必要があります。

リアルタイムに対応する**。小売業者にとっては、販売サイトやPOSシステムの数時間(またはわずか数分)のダウンタイムが非常にコストの高い影響を与えます。ダウンタイムの直接的な結果として失われた売上に加えて、企業も評判にも損害を与えます。したがって、影響は数カ月続く可能性があります。これらのリスクを軽減するために、インシデント管理システムとワークフローが鋭い洞察を基にしたリアルタイム応答を可能にし、サービスができるだけ迅速に復元されるようにする必要があります。

効果的コミュニケーションを図る**。小売業におけるインシデント管理の課題のひとつは、企業のインフラストラクチャが、特に店舗や倉庫の大規模なネットワークを持つ小売業者にとって、非常に大きく広く分散する傾向があることです。インフラストラクチャの稼動を維持する管理者も分散しがちです。この課題に取り組むには、シームレスなコミュニケーションツールを提供するインシデント管理システムが必要で、ChatOpsなどの共同作業ワークフローを活用すべきです。そうすれば、広範囲に広がった大規模な管理者チームでも、問題を解決するときに効果的にコミュニケートできます。

ダウンタイムをもたらす脅威を完全に排除することは決してできないと言っても過言ではありません。しかし、最新技術による監視とインシデント管理のソリューションは、小売業者が大規模なサービス障害の話題の提供者にならないために重要な役割を果たします。

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

クラウドとオンプレミスのハイブリッド環境のインシデント管理

2018年、サーバインフラストラクチャはハイブリッド化されているでしょう。 インシデント管理ソリューションもハイブリッド環境への対応が必要です。オンプレミスサーバのみを管理する場合、仮想ネットワークやマイクロサービスが混在していない場合は、インシデント管理は簡単です。しかし、そんな時代はもう終わりました。

今日、ほぼすべてのインフラストラクチャは、ある意味でハイブリッドなのです。 オンプレミスのサーバとデバイスは、パブリックまたはプライベートクラウドとシームレスに稼働します。ネットワークは物理層から抽象化されています。ストレージはスケールアウトされ、多くのサーバに分散しています。複数のデータセンターに分散配置されているかもしれません。

この環境で管理者がすべきことは何でしょうか。簡単なのは、ハイブリッド対応のインシデント管理ソリューションを採用することです。では、今日のハイブリッドインフラストラクチャのインシデント管理を最適化するためのヒントをお教えしましょう。

ハイブリッド環境におけるインシデント管理の課題

ハイブリッド環境におけるインシデント管理に特徴的な課題を説明しましょう。

インシデント管理チームは、インフラストラクチャ全体に物理的にアクセスするとは限りません**。インフラストラクチャが複数のデータセンターにまたがる場合や、クラウドを含む場合、管理者がアラートを発呼するデバイスと同じ場所にいない可能性があります。 すべてのインフラストラクチャを完全に制御することはできません**。パブリックまたはプライベートクラウドは、他の誰かのサーバ上にホストされている可能性があります。 物理デバイスは抽象化されています**。その結果、アラートがソフトウェアの問題、ハードウェアの問題、またはその両方によって引き起こされているかどうかを判断するのが難しくなります。たとえば、仮想サーバ上のファイルシステムの問題に関するアラートの原因には、ホスト上のディスクのハードウェア障害、ゲスト上のソフトウェアファイルシステムのエラー、またはその組み合わせなどがありえます。 インフラストラクチャは変化します**。新しいデバイスが追加または削除されたり、ストレージが拡張されたり、コンテナがスピンアップやスイングしたりするなど、絶えずスケーリングされています。

ハイブリッド環境の課題を解決する

ハイブリッドインフラストラクチャインシデント管理戦略を計画する際に考慮すべきいくつかの提案を示しましょう。

原因に応じてアラートをルーティングできるインテリジェントなインシデント管理プラットフォーム(PagerDutyなど)を採用します。そうすれば、あるデータセンターで生成されたアラートは、別の場所のチームではなく、そのデータセンターを管理している管理者に確実に届きます。 柔軟な監視とアラート設定を提供し、既存の環境と容易に統合できるインシデント管理プラットフォームを導入します。これにより、インフラストラクチャのさまざまな部分にさまざまなツールを統合できるようになり、その特定の部分に最も適したツールが決まることになります。パブリッククラウドサーバでは、AWS CloudWatchを使用することができ、Nagiosはオンプレミスサーバを処理できます。SnortまたはOSSECはネットワークイベントを監視できます。PagerDutyを例にとると、既存のハイブリッドインフラストラクチャと統合できる150以上のインテグレーションがすぐに利用できます。 すべてのアラートをセントラルハブに送信します。複数の監視プラットフォームを使用している場合は、アラートをグループまたはクラスタで一緒に表示する必要があります。さもなければ、管理が困難になり、関連する問題の間のリンクを導き出すことが不可能になります。PagerDutyのようなプラットフォームは、ハイブリッド環境全体からさまざまなアラートを受信して正規化する集中ハブを提供しこれを解決します。 インシデント管理ソリューションが拡張できることを確認します。インフラストラクチャのサイズは一定ではないため、アラートの変化する量を受信して格納できるプラットフォームが必要です。 ベンダー依存は推奨できません。特定のオペレーティングシステムやベンダー製品のみをサポートするインシデント管理ソリューションは、ハイブリッドインフラストラクチャでは機能しません。ハイブリッド環境は、通常、さまざまなハードウェアとソフトウェアのコンポーネントで構成され、部品をすばやく交換できるのが利点です。 PagerDutyのようなソリューションは、ベンダー固有の監視ソフトウェアと統合し、柔軟なインシデント管理インターフェイスを使用してアラートを変換できるためハイブリッド環境でも便利に使えます。

以上の課題のいくつかは、まだハイブリッド化していない組織にとって今のところまだ重要ではないように思えるかもしれません。しかし、明確な傾向はハイブリッド環境にに向かっています。 インフラストラクチャを監視する能力に影響を与えることなく、インシデント管理ソリューションを早期に準備すれば、ハイブリッド環境に完全に移行できるようになります。

注)インシデントとアラート

インシデントの定義は、

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

アラートとは監視システムが、そのシステムの監視対象のある定量情報(メトリック)があらかじめ設定されたしきい値と超えた場合に管理者に送る通知を指します。ある1つのアラートまたは複数のアラートの組み合わせが1つのインシデントの予兆または症状として発生します。

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

ビジネス関係者にもインシデントの最新状況を知らせる

by Adam Keller

想像してみてください。航空会社のデータセンターでチケット発券システムがダウンするような重大なITインシデントが起こりました。舞台裏では、エンジニアが問題の診断と修正を急いでいます。しかし、昨今のシステムは非常に複雑であるため、問題の解決には予想よりも長い時間がかかり、システムがダウンしてから数時間が経過しています。

一方、乗客は長い列を作り、地上係員に怒りをぶつけ、ソーシャルメディアで人々とフラストレーションを共有しています。カスタマーサービス要員には何が起こっているのかわからず、乗客と同様の情報にしか与えられていないにもかかわらず、なんとか状況を説明して全員を落ち着かせようと最善を尽くしています。

ここで、顧客が直面しているのは技術的なインシデント対応で、カスタマーサービス要員、フライトクルー、手荷物係などの内部関係者に情報を提供するなどのビジネス的な対応は存在しないか、あっても行き当たりばったりなので、インシデントの影響を悪化させ、会社のブランドや評判に深刻な損害を与えてしまいます。

そこで我々は、PagerDuty Solution for Business Responseをご用意しました。

ビジネス対応のためのPagerDutyソリューション

この例のように、ビジネスや顧客に影響を与える重大なインシデントが発生した場合、技術面の対応者(つまり、プライマリレスポンダー)だけが行動を起こす必要があるのではありません。会社全体の関係者(エンジニアと非エンジニア)も動員する必要があります。

これらの「二次対応者」は、例えばメディアへの説明ポイントをまとめるなど、ビジネス上の負の影響を軽減するために、最新のインシデント解決の進捗状況を知る必要があります。航空会社の例では、顧客サービスチームとチケット発券業者は、このインシデントがビジネスにどのような影響を与えるかを理解し、ホテルクーポンの提供や乗客の再予約が必要かどうかを決定する必要があります。

PagerDuty Solution for Business Responseは、インシデント対応に当たる技術チームの手をわずらわせることなく、簡潔で実用的なステータス更新を、それを知る必要のある人と自動的に共有することにより、インシデント発生時のビジネス部門と顧客とのコミュニケーションを円滑にします。

「顧客がデジタル製品に24時間年中無休でアクセスできることをますます期待するにつれて、システムダウンの潜在的な悪影響が増大します。インシデント発生中、技術的な対応はビジネス的な対応とうまく統合されないことが多く、このコミュニケーションのギャップは消費者の体験を左右します。PagerDutyのビジネスレスポンスソリューションは、技術とビジネス利害関係者の両方にインシデントを迅速に通知し、問題を修復するための調整されたアクションを実行できるよう構築されました」。

–Rachel Stephens、RedMonkアナリスト

ユーザーは、通知方法をカスタマイズすることもできます。たとえば、PagerDutyのWebサイトのステータスダッシュボードを表示するだけでなく、SMSやメール、PagerDutyモバイルアプリを介してプッシュ通知を受信するように設定できるため、特定のインシデントが発生したことをリアルタイムで知ることができます。

リアルタイム更新のステータスダッシュボード

PagerDutyのステータスダッシュボードには、事前に選択されたビジネスサービスの健全度が表示されるため、従業員はシステムの現在の状態を一目で把握し、過去に起こったことを確認し、メンテナンスやアップグレードなどの今後のサービス変更予定を確認できます。エンジニアは、技術的アクションとビジネスアクションの協調が最も重要なときに両方を調整する洗練されたインシデントレスポンスプレイとフローを設定することもできます。

PagerDutyのビジネス対応ソリューションの利点

Modern Incident Response製品の上に構築されたPagerDuty Solution for Business Responseは、ユーザーにインシデントの状況認識をシームレスかつ自動的に通知するので、技術面の対応者とビジネス関係者/利害関係者の両方がリアルタイムのインシデント情報を使用して対応を調整できます。追加の有料アドオンは必要ありません。利点は次のとおりです。

顧客との関係を積極的に管理することで、企業とブランドに対する顧客の信頼が高まります。関係者と従業員は、顧客から質問される前にインシデントを認識します リアルタイムでインシデントに対応できるようにすることで、ビジネス関係者と対応エンジニアの生産性を向上 顧客に影響を与えるインシデントが発生した場合に、技術的対応とともに、ビジネス対応活動を迅速に開始できる サービスの健全度が一目でわかるライブステータスダッシュボード リアルタイムのターゲットを絞ったステータス更新とビジネス部門自らの関与により、IT部門の負担なしで主要な利害関係者と積極的に関与する機能

Business Responseが実際にどのように機能するか、さらにお知りになりたい方は、次のビデオをご覧ください。

サブスクライバー(情報購読者)の追加、ステータス更新の追加、ステータスダッシュボードでビジネス対応を調整する:https://youtu.be/MaUmLBgLDBE 利害関係者チームや関連対象者向けの特定のビジネスサービスのみを含むカスタムダッシュボードを作成する:https://youtu.be/Ug1s_fsheu4 サブスクリプションの管理と通知ルールの表示:https://youtu.be/XX2aP200wSw ユーザーとチームを追加して、ステータス更新の受信と公開をする:https://youtu.be/C39wNKK_RMw

PagerDuty Solution for Business Responseは、Modern Incident Responseプランのお客様が利用できるようになりました。ステータスのボタンをクリックするだけで準備完了です。この機能にご興味がある場合は担当者に連絡し、詳細についてサポート技術情報をご覧ください。

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

2017年12月28日  (更新日:2022年3月10日)     |    インシデント&アラート

Twitterはコールセンターをなくす

インシデント管理における外部メディアの重要性

インシデント管理について偏狭な考え方に陥るのは簡単です。私たちは何カ月も問題を警告するシステムの設計と構築を行い、我々がキャッチできなかった問題を発見するために顧客サポートのチャネルも構築しました。この考え方は間違っていませんが、このアプローチではなく、TwitterやFacebookなどのSNSで問題を報告するユーザーが増えています。

新たな道を歩むソーシャルメディア

ソーシャルメディアは、企業がカジュアルな雰囲気でユーザーと直接つながる素晴らしい手段として、より密接な双方向コミュニケーションの扉を開いています。ソーシャルメディアは個人が企業とコミュニケーションをとるだけでなく、より効果的な方法でユーザーサポートを得ることもできます。

一般的に、ユーザーが電話やサポートチケットなどの伝統的なルートでサポートを得ることができない場合、ツイートで不満を述べるとすぐに答えがが得られることがあります。SNSは苦情を訴える手段だけではありません。多くのユーザーは、ソーシャルメディアを企業とのコミュニケーションに使用するのが好きです。

私も何度かツイートしたことがあります。

彼らのサイトは500のエラーを発生させている?

素敵なJavaScriptはある?

開発者として私が気づいていないかもしれない問題を指摘していただければ幸いです。「何かを見つけたら話す」です。

同期 vs. 非同期

ソーシャルメディアによるサポートの「報告」の側面は強力ですが、他にもより大きな利点があります。ソーシャルメディア(特にTwitter)は、「リアルタイム」を感じさせるからです。

たとえば、電子メールは非同期通信メディアであり、顧客サポートの手順では受けた質問はキューに追加されます。そこに緊急感はありません。一方、Twitterにはより同期的なフローがあります。電話やライブチャットのようなリアルタイムのサポートチャネルではありませんが、回答する時間が公に記録されているため、電子メールよりも緊急性があります。フィードバックは直接的かつ個別的なもので、あなたの問題を他と同様に重要なものと感じさせます。

干し草の山から針を探し出す

それでは、インシデント管理以外の質問に埋もれることなく、うまくやるにはどうすればいいのでしょうか。この問題の解決策はサポートチャネルと同じで、判定と引き継ぎです。

判定

ソーシャルメディアは顧客サービスのためだけに使用されるわけではないため、ユーザーサポート以外の書き込みで混雑することもあります。バグレポートをそれ以外から物理的に隔離することが重要です。単純にバグを非バグから隔離するだけでなく、レポート間の共通点を特定することも重要です。これによりパターンを検出し、問題が手に負えなくなりそうならばその前にエスカレーションすることもできます。たとえばコマンドコンソールは、ツイートなどのデータソースをインフラストラクチャ内の特定のイベントに関連付けたり、影響の範囲を視覚化したりすることができます。こうして、ソーシャルメディアへの反応からデプロイの失敗や停止が顧客に影響をもたらしたかどうかや、影響の程度を理解することができます。

引き継ぎ

問題が特定され、グループの他の部分から隔離されたら、適切な人やチームを割り当てる必要があります。これは、既存のヘルプデスクアプリケーションにレポートを転送するだけでなく、専用のソーシャルメディアサポートアプリケーションを使用して、多種多様な方法で実行できます。

ソーシャルメディアプラットフォームは、マーケティング部門だけが利用するものではなく、インフラストラクチャ内の問題に関するリアルタイムの情報を得る優れた方法であり、今日のデジタル世界では完全な可視性を提供するために不可欠なデータソースです。これらのプラットフォームに従来のサポートチャネルと同じレベルのプロセスと労力をかけることで、問題がより深刻なものになった後ではなく、最初のレポートが到着してすぐのインシデント対応が可能になります。

コールセンターが不要というわけではありませんが、顧客満足度をを確保するためには、ソーシャルメディアを介して入手可能な豊富な顧客データを積極的に活用しなくてはなりません。監視とインシデント管理戦略の重要な要素として、ソーシャルメディアはユーザーエクスペリエンスの質をより深く把握し、顧客のロイヤリティを向上させるための重要な要素です。

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

インシデント管理データで技術的負債を測る

技術的負債(technical debt)が借金のようなものだったら、手作業でチェックインしない限り、それを追跡するのは難しいでしょう。 多くの人にとっては自分の当座預金口座に資金がなくなったことを知る唯一の方法は、口座の残高を確認することです。さらに悪くなると、小切手が返されたり、デビットカードが拒否されます。

しかし、技術的負債の測定はもっと自動化できます。 これは、お客様の銀行口座とは違って、ITインフラストラクチャの場合はそれを専用のツールで継続的に監視でき、重要なヘルスメトリックについて通知を受けることができるからです。 次に、監視データを使い技術的負債についての情報を得ることができます。 つまり、データセンターで問題が発生したときに手動で監査する必要はありません。 問題があることを知るのに、サーバーがダウンするまで待つ必要はありません。 インシデント管理ツールは、その情報を提供します。 エクステンションを使えば手作業で面倒なことを測定することなく、技術的負債を取り込む方法も提供しています。

インシデント管理は、技術的負債を追跡して修正するのに役立ちます。追加の投資は必要ありません。

技術的負債の定義

まず、技術的負債の意味を説明しましょう。 技術的負債とは、長期的には非効率性やその他の問題を引き起こすような、ソフトウェアコードやアーキテクチャの不完全性を指します。 たとえ欠陥自体が小さいとしても、その効果が継続的に繰り返されるため、時間の経過とともに多くの利子が生じることがあります。

例えば、モジュラーアプローチを採用しておらず、同じ機能の複数のバージョンをコードに含むようなプログラムは、より優れたプログラムよりも実行に数ミリ秒余計にかかることがあります。 一度だけそれを実行するなら、大きな問題にはなりません。 しかし、それがサーバーの側で1日に数千回実行されるWebアプリケーションであれば、パフォーマンスが低下したり、CPU時間が浪費されたりするという負債があっという間に積み上がります。

技術的負債には多くの潜在的な原因(訳注:クリックすると英語版のWikiに飛びます)があります。 場合によっては、例えば何かを迅速に導入しなければならず、ベストプラクティスに従う時間がない場合は、負債がコストに見合う価値があると判断(少なくともその時点で)して、技術的負債を意図的に負うことがあります。管理者の中で最も優れた人でも将来の技術的負債を避けることは難しいです。 将来を見通せない限りは(例えば、あなたがアップグレードする余裕がないために今日も使用している10年前のスイッチが、最新のファイアウォールツールではうまく機能しないということは過去の時点では分からなかったはずです)。 その場合、技術的負債は、不完全な世界での生活で起きることまったく同じ経緯をたどります。

技術的負債を追跡する

技術的負債には多くの源がありますが、それをインシデント管理を使用して測定するというアプローチは、問題の原因を問わず問題の追跡を容易にします。繰り返しますが、時間のかかる手動のシステム監査で非効率性を検索する代わりに、インシデント管理データを技術的な負債の程度を評価し、それを評価するためのプロキシとして活用できます。

やり方を理解するために、PagerDutyが追跡するさまざまな種類のインシデント管理データの例と、それらのデータが技術的負債について明らかにできることをいくつか見てみましょう。

まず、ツールが生成するアラートの生の数を取得します。これは非常に基本的な指標であり、さまざまな要因によって影響を受ける可能性があります。しかし、インシデント管理の報告システムが適切に構成されており、インフラストラクチャに大きな変更を加えなくてよいと仮定すると、技術的負債の規模とツールが報告するインシデントの数との間に相関が見られる可能性があります。負債が増えるとパフォーマンスが低下し、応答時間やリソースレベルが特定のしきい値に達するとアラートがトリガーされるためです。したがってアラートの発生率が月ごとに減っていれば、コードがより効率的になったので技術的負債が減っている可能性があります。

平均解決時間(MTTR)は、技術的負債を見るためのインシデント管理の指標です。MTTRが悪い一般的な原因の1つは、コードがあまりにも複雑すぎることです。例えば、上の例を再利用するために、急いで書かれたコードには冗長な機能が含まれているため、管理者にはすぐに理解するのが難しいでしょう。これは、事件に対応するためにコードを読み込んで変更する必要がある場合に、解決時間が長くなることを意味します。

技術的負債の源を見つける

インシデント管理データは、技術的な負債に関する一般的な傾向を追跡するのに役立つだけでなく、問題の原因をゼロにするのにも便利です。

たとえば、特定のプログラムに関連するインシデントのMTTRが平均MTTRよりも高い場合、問題のプログラムが技術的な負債を生成している可能性があります。同様に、あるタイプのオペレーティングシステムを実行しているサーバーが不均衡なアラート数の大部分を占めている場合、おそらくコードまたは構成上の欠陥があります。それはあなたが対処できる技術的な負債です。

インシデント管理データを使って技術的負債を特定し、対処するのはとてもクールで、ほとんど追加作業を必要としません。あなたは既にPagerDutyのような操作と報告を集中化するハブ(うまく設定すればですが)を備えた監視システムを備えています。これらのリソースを活用して技術的負債を見つけて修正するには、追加のツールや投資を必要としません。既存のソフトウェアを使用して、コードや操作をより効率的にすることができます。

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

余計なアラートを抑制しよう!

インシデント管理におけるノイズ回避

抑制( 注:Suppression )。シソーラスによると、この単語は削除、排除、消滅などの用語と同義語です。

しかし、インシデント管理の文脈の中では、抑制とは全く異なることを意味します。永遠にデータを削除することではありません。そうではなく、騒音を軽減して管理者が適切なタイミングで適切なアラートに注目できるようにする方法として機能します。

ここでは、抑制がインシデント管理を合理化する様子をご紹介します。

抑制が重要な理由

インシデント管理に抑制が役立つのはなぜでしょう。簡単に言えば、現代のインフラストラクチャは大量のアラートを生成するので、管理者は全てのアラートをレビューできないのです。試してみればすぐにアラート疲れすることに気づきます。つまり、アラートの量に圧倒されて燃え尽きてしまい、本当に重要なアラートを無視するようになってしまいます。また、アラートに注意を払うのをやめるとインシデント管理プロセス全体が壊れてしまいます。

アラート抑制はこの問題を回避する方法です。管理者は、特定の種類のアラートを抑制することで、対処可能で優先度の高いアラートを重視するようにできます。また、ダッシュボードに表示されるアラートの総数を減らすことができるので、アラート疲れを防ぐのに役立ちます。

例えば、ワークステーション群が更新プログラムのインストール後に1週間に1回再起動するようになってしまったケースを考えてみましょう。ワークステーションが再起動後にオフラインになってまた復帰するまでの間に一連のアラートが生成されます。管理者が見ているインシデントダッシュボードにこれらを追加すると、ダッシュボードが役に立たなくなってしまうでしょう。それらのアラートは特にアクションを必要としないルーチンの手続き型イベントが起きたことを示すものだからです。この役に立たないノイズを管理者のダッシュボードに表示させないようにするには、管理者はインシデント管理ソフトウェアの設定で、ワークステーションの再起動に関連するアラートを抑制することができます。

抑制はゼロか100かという問題ではありません

アラート抑制を理解するうえで大事なのは、アラートを抑制するというのはゼロか100かを選ぶのではないということです。つまり、管理者のオプションは、特定のタイプのすべてのアラートを有効にするか、またはすべてのアラートを永久に抑制するか、ということではありません。

そうではなく、抑制にはもっと繊細なアプローチをとることができます。特定の期間内に繰り返し発生しない限り、特定の種類のアラートが抑制されるように設定できます。あるアラートを特定の時間帯に発生した場合だけ報告するように設定したり、他の時間帯には抑制するように設定したりすることもできます。同様に、管理者は特定の種類のデバイスで発生した特定の種類のアラートは抑制したいが、他の種類のアラートは抑制したくないという場合があります。

こういう柔軟性はアラートの有効性を最大限に引き出すために重要です。幅広く雑な抑制ポリシーを適用するのではなく適切に調整すれば、インシデント管理システムに不要なノイズを出さず、重要なイベントを最大限に可視化することができます。

上記の例では、繊細な抑制が役に立ちます。私が指摘したように、管理者は普通、ワークステーションがソフトウェア更新後、深夜に再起動したときに出すアラートは受信したくありません。しかし、インシデント管理ソフトウェアが同じ期間に複数回再起動するワークステーションを検出した場合は、管理者が知りたい問題(ソフトウェアの欠陥など)が発生している可能性があります。この状況では、再起動が反復される場合だけセンターのダッシュボードに表示されるインシデントが生成されるように設定すれば、インシデント管理の効果を最適化できます。

抑制はデータの損失を意味しません

インシデント管理の文脈でいう抑制は、抑制されたアラートが永遠に消えることを意味するものではないことを強調しておきます。逆に、抑制されたアラートはまだ発生しますし、それらに関連するデータは保存する必要があります。抑制されたアラートとされていないアラートとの唯一の違いは、前者はインシデント管理システムの優先順位の高いダッシュボードには送信されないということです。

これは管理者が必要に応じて抑制されたアラートを見てインシデントを把握できることを意味します。これにより、アラートのしきい値を調整するのに役立ちます。さらに、抑制されたアラートを過去のインシデント管理データとして見ることで、インフラストラクチャの効率性やシステムの健全性のトレンドに関する多くの貴重な情報を明らかにできます。

抑制されたアラートを活用することで管理者がインシデントの特定と対応に役立てることもできますし、優先順位の高いインシデントを解決するために活用したいダッシュボードを、対処不可能な情報で混乱させることもなくなります。さらに、インフラストラクチャを完全に把握できるように、アラートが適切な状況下でのみ抑制されるようにして、常に報告が続けられるよう微調整することもできます。

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

インシデント管理のメトリックでタブを常時オンにする

およそ1年前(注:2016年)、Citiで起きた技術的な問題が原因で数十万枚のカードとATMが同時に使えなくなりました。その結果、Citiが新しく立ち上げたCostco Anywhereカードは、「苦情の洪水」(flood of complaints)を受けました。 インターネットの世界で言えばこれに相当するフレーズは「タイヤ火災」(”tire fire” 、https://en.wikipedia.org/wiki/Tire_fire)です。 Tire fireに発展するインシデントには、通常、リーダーシップからユーザー、サポートデスクまで、組織内の全員が関与します。PRやマーケティングはアラートを出し、外とのコミュニケーションに対処し、技術チームは状況把握に努めます。 これは、SLA(Service Level Agreement)などに則る事後検証を外部向けに書面で用意することを意味します。これらは、しばしば「根本原因」の分析として書かれ、インシデントに関係する人、プロセス、技術を批判し、修正することに焦点を当てています。 技術リーダーは、このような状況では責めを負う以上のことはできません。もちろん、チームは可能な限り早くトリアージをし、サービスを正常に戻すことができます。しかし、インシデントの原因、効果の有効性、および影響を測定する過程では、目標を「根本的原因」にのみ合わせるべきではありません。 「ポイントアンドシュートアプローチ」では、責任を追求し予算を要求します。「ポートフォリオアプローチ」は、現在の投資がどのような結果を返したか、再配分がその結果をどのように変えうるかを示しています。これは、組織の他のメンバーがDevOps、サポート、サービスにどの割合で投資するべきかを理解するのに役立ちます。

経営側と話をつける

たとえば、ServiceNow、PagerDuty、Slackなどの内部ツールは、スピードとカバーの広さへの投資であり、インフラストラクチャ全体の問題を迅速に解決するのに役立ちます。それらをさらに補強するには、開発用ツール、オンコールスタッフの増員、モバイルやアプリ内でユーザーに警告するためのシステムとの緊密な統合が必要になるでしょう。これらの投資は、インシデント後に計画なしに提示されるべきではありません。むしろ、インシデント管理とインシデント解決の指標は、インシデント解決の結果を改善するために、現在インフラがどう設定されているのか、人やプロセス、ツールをどこに追加すべきかを示すものでなければなりません。

また、インシデントは必ずDevOpsやTechOps、サポート、サービス部門と経営側との対話を強制するため、明確な「ビジネス現場で通じる」言葉で話せる必要があります。 以下はインシデントについて情報を交換するための非常に基本的なフレームワークの例です。

優先度2

社内のインシデント通知(変更管理チケットなど)は、(PagerDutyとSlackを使用して)オンコール担当者に直ちに送信されること。SLAでは、アカウントオーナーとの同日中の管理連絡を求めます。

SLAが合意した目標内で実際にに解決された優先度3のインシデントの割合(過去の割合) 該当する期間内の優先度3のインシデントの割合(パーセンテージ)

優先度1

内部でのインシデント通知(カート機能のダウンなど)は、オンコール担当者、管理チーム、サポートにすぐに送信される。SLAは、この通知から1時間以内にインシデント責任者との管理連絡を求めます。

SLAが合意した目標内で現実に解決された優先度1のインシデントの割合(過去の割合) 該当する期間内の優先度1のインシデントの割合(パーセンテージ)

このテンプレートは、インシデント対応担当者やビジネス関係者向けに内部だけで使うこともできますし、顧客や見込み客向け、つまり外向けに使うこともできます。技術的な知識がなくても、経営側はインシデント履歴と解決にかかった時間を理解できます。このデータは、テクニカルチームが保守できる資産であり、インシデント解決とDevOpsプロセスを直接結びつけるものです。

上記は経営レベルで適切な会話をするのに役立ちますが、内部の事後検証は開発チームやサービスチームにとってより内省的です。 質問:これらのプロセスは正しいですか? インフラストラクチャは十分な弾力性を備えていますか? そうでない場合は、自分たちが知っているることと、変えられることをどう計ればよいでしょう? チームの成果を判断する際に考慮すべき基準の例を次に示します。

インシデントのインパクトと緊急性に基づいて優先順位を設定したか

ログ処理後に優先度が変更されたチケットの数 苦情やエスカレーションのために作成された追加チケットの数 各優先度のチケットに割り当てられた担当者の数と層(ティア)

顧客とユーザーが何が起こっているのか、そしてインシデントが解決されることを期待できるかを理解するよう、コミュニケーションをうまく行えるかどうか

顧客が最新情報を求めるためにサービスデスクに連絡したインシデントの割合

顧客はインシデントを処理する方法に満足しているかどうか

インシデント終息後の調査でユーザーの満足度の割合 年間顧客満足度調査で調べたインシデント解決による満足度の向上

繰り返されるインシデントを認識し、将来の悪影響を減らすために公開の場(フォーラム)で問題を説明したかどうか

フォーラムに公開されたサービスデスクに記録された問題の数 フォーラムにリダイレクトされたチケットの数 フォーラムにより生成されたチケットの数

インシデント解決への投資とツールを効率的に活用したかどうか

メール/フォーラム/アプリケーション経由で記録されたインシデントの割合 セルフサービスツールで検出され解決されたインシデントの割合 インシデント解決の平均コスト(優先度別) ツールへの投資後にインシデントを解決するためにかかった平均時間 ツールへの投資後のインシデント数の減少率

専門チームのために分析が最大の意味を持つようにするには、はるかに多くの基準がありますが、これらの基準は不可避な質問に答えるための出発点となります。モダンなチケット発行、監視、インシデント解決、コラボレーション、顧客満足度測定ツールを使用してください。多くのツールには分析機能が組み込まれています。

先に書いたPagerDutyとSlackは、インシデント解決とコラボレーションの標準ツールです。ServiceNowとAtlassianスイートは、インシデント管理と資産管理の連携に最適です。何よりも、インシデントを効果的に解決しその後の発生を防ぐには、ツールだけではなく、効果的かつ統合された、セルフサービス型でツールを使えるようにする明確なプロセスが必要です。

ツール、プロセス、人の効果を評価する際に、「Other」、「Misc」、あるいは他のざっくりと包括するようなカテゴリーを使わないでください。そんなカテゴリーを使うのは全ての基準に罠を仕掛けるようなものです。また、まずテンプレートを使ってみるのが良い場合もありますが、テンプレートからコピーするだけではなく自分たちで改良すれば、チームのレポート機能をさらに強化します。さもなければ、次の点についてチームの感覚で検討を始めてください。

課金モジュールのエラーがあなたのサービスでは優先度1または2に分類されていますか? 顧客は優先度1になるでしょうか? 全部が優先度1である顧客はいますか?

無理はしないでください。あなたもチームの一員なのです。 自分のチームがインシデントをどう扱うか(タイムライン、人員、ツールの使用法など)という質問にフォーカスし、それに基づいて優先順位を付けてください。インシデント解決ツールの基本的なカテゴリーとプロセス、ビジネス改善のための投資を継続できるかを示す指標が分かっていれば健康を維持できます。Tire fireが起きた場合でも。

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

インシデント管理が全従業員のやる気をアップ!

失敗への恐れは開発チーム や運用チーム のメンバーにとって大きな壁となります。この恐怖は耐えがたいもので、社内の士気を大幅に下げ、従業員の生産性と進歩も傷つける可能性があります。

適切なインシデント管理とモニタリングを実施するだけで、アラートを管理して分析機能を提供する以上の効果が得られます。つまり開発の失敗を軽減し、アプリの作り方や投入方法を変えられるようにすることもできるのです。効果的なインシデント管理ソリューションを導入して、開発チームの士気を高め、最高の仕事ができるようにするいくつかの方法を見てみましょう。

インシデント対応中のストレスレベルを下げます

ストレスの軽減は正しいデータを得ることから始まります。正しいデータを持っていない場合は、どこを見て解決すべきかが分かりません。インシデント管理では、適切なコンテキストで全ての適切なアラートを集中管理し、関連する監視ツールのデータを浮かび上がらせることでさらに深く分析を掘り下げることができます。これはインシデントのトラブルシューティング時にチームがよりうまく動き、問題をより速く解決するのに役立ちます。全てのツールのデータをインシデント管理ソリューションに統合することで、チームの誰が何を担当しているかを全員が把握できます。さらに、問題を素早く修復するために必要なデータ(ランブック、グラフなど)も備えています。より速い解決は常にチームをよりハッピーにします。

( 注:ランブックは、運用時に実施する一連の操作について、手順を明確に示した操作指示書のこと)

新機能でインシデントの発生が予測可能になります

インシデント管理プロセスがうまく機能している場合、何が原因で繰り返しダウンタイムが発生するのか、またどのインフラストラクチャやアプリケーションが障害の影響を受けやすいのかが分かります。これにより、新しい機能を追加する際の信頼性が向上します。QAチームは、例えば、注意を必要とするアプリの特定のエリアをチェックするテストを書くことができます。また、経験から問題の原因が分かるため、新しい機能を拒否することさえできます。チームが新しい機能のフィードバックを提供するには、システムの機能と定期的に起こる問題についての深い理解が必要です。このような理解はインシデント管理プラットフォームを使うことでしか得られません。この予測可能性は、チームが「システムを信頼する」ことを助け、あらゆるステップで次に何を期待できるかが分かるようになります。この心の安らぎは従業員の士気と自信を高めます。

全チームが優れたユーザーエクスペリエンスを 提供できるようにします

伝統的に開発チームは、アプリケーションのコードを書きあげて、「壁の向こうの運用チームに投げ込めば」、自分たちの仕事は終わるものと思っていました。同様に、運用チームは、提出されたコードの品質を保証することは自分たちの仕事ではなく、開発から来るものをデプロイすればよいと思っていました。インシデント管理が機能すれば、開発チームと運用チームが統一されたプラットフォームで連携して、チーム間で可視性と一貫性のある単一の真実に向き合えるようになります。彼らは、どれがコードに起因する問題か、そしてどれがインフラストラクチャに起因する問題かを認識できます。

つまり稼働時間は、いくつのサーバが稼働しているか、アプリケーションのどれくらいが正常に稼働しているかによって決まるのではなく、エンドユーザーの経験によって評価されているのだということです。稼働時間に関するこの現実的な見方は、チームの目標とプロセスを、ユーザーの期待を超えるアプリケーションを提供するというより広いビジネス目標へと向かわせます。幸せな顧客がチームを幸せにするのです。チームの仕事のおかげでエンドユーザーが喜んでいることを見せる以上に、従業員の士気を高める良い方法がありますか?

パイプライン全体を加速します

ゲームを変えるようなアプリケーションを構築したい場合は、スピードが不可欠です。インシデント管理は、インシデントが発生したときに、開発チームと運用チーム(ヘルプデスク、サポート、ビジネス関係者など)間の明確なコミュニケーションを可能にします。コミュニケーションのボトルネックが解消されば、チームメンバーは繰り返し起きる問題をより短い時間で解決できるようになり、顧客の幸せを保つためのアプリケーションの開発にもっと多くの時間をかけられるようになります。アプリの開発に使える時間が増えることは、品質向上と市場投入までの時間短縮をもたらします。市場への投入がより迅速になり、チームが1日あたりに出来ることが増えれば、彼らは自分たちの能力が上がったと感じ、より深く取り組むようになり、自分の仕事に情熱を感じるようになります。

オーナー感覚を作り出します

インシデント管理は、インシデント対応のさ中にチームメンバーがより責任を持ち、インシデント対応の手順を確立して、より上位の人たちに頼ることなく重要な意思決定を行えるようにします。決定する能力を持つことは簡単なように思えるかもしれませんが、組織のプロセスの中でチームメンバーがより強い影響力と自信を持つようになるまでは、長い道のりがあります。上位のチームメンバーからの許可を待たないようにすれば、お役所仕事を減らせます。チームのメンバーは、顧客の体験を24時間確実にサポートするために、オンコールを担う責任を全うしています。あらゆるレベルのチームメンバーが意思決定に関与できるようにすると、無茶苦茶なカオスや冗長な作業に費やす時間を短縮し、貴重な時間を無駄にせず、実際の開発に多くの時間を割けるようになります。

効果的なインシデント管理ソリューションは、失敗への恐れを減らし、予期せぬ事態をチームが自信を持って管理できるようにし、結果として従業員の士気を向上させます。チームメンバーが獲得できた信頼感は、パイプライン全体で革新と標準化を推し進め、従業員の士気、生産性、成功を大幅に向上させます。

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

2019年春リリースの概要:The Intelligent Enterprise

今日のデジタルワールドでは、企業のビジネス関係者や障害対応にあたる技術者は、中断が発生したときにすぐに対応できるように、常にデジタルサービスの健全性を意識する必要があります。それでも過去3年間で、1人のレスポンダーあたりの業務の複雑さは平均3倍に増えているため、チームがデータを理解し、意味のある洞察を得て、デジタルオペレーションを改善することはますます難しくなっています。

そこで今日私たちは、インテリジェントな企業向けに設計した新しい一連の製品の機能を発表します。これらの機能強化によって、各チームが重要な瞬間にデータ、インテリジェンス、そして大規模な自動化を使って、効果的に成果を上げることができます。Spring 2019リリースでは、プラットフォーム全体で新しい改善が行われており、エンタープライズクラスのものでありながらユーザーを念頭に置いて設計されたエクスペリエンスを提供します。

新製品のアップデート

この1年で、私たちは、マシン、チーム、サービスの所有権、そして人間の応答データにわたる、独自のテレメトリの流れに基づいて構築された、いくつかの新しいモジュラー製品をコアプラットフォームの上にリリースしました。 以下に詳述するこれらの新製品は、すでに何千ものチームがよりインテリジェントで効率的な方法でリアルタイム作業を処理するのを助けています。

PagerDuty Event Intelligence

ますます複雑化する運用上の複雑さを管理し、ノイズから信号を抽出し、機械学習主導のコンテキストでトリアージを加速することで、チームの拡張を支援します。

PagerDuty Modern Incident Response

自動対応の動員と利害関係者のコミュニケーションにより、チームは重要なインシデントをより迅速に解決できます。

PagerDuty Visibility

レスポンダーと事業主の両方がデジタルの混乱への共通の状況を受け取ることができます。

PagerDuty Analytics

運用上の投資と成熟度を向上させるための最新の洞察をデジタルビジネスのリーダーに提供します。

Human-Context Enriched Intelligenceの提供へ

Springリリースの一部として、 いくつかの新しい機能でPagerDuty Event Intelligenceを強化しました。 機械学習を使用してノイズを低減するPagerDuty独自のIntelligent Alert Groupingアルゴリズムは、これをさらに効率的に実行するように改善されているため、少ないトレーニングデータでより早く作業を開始できます。 新しいアラートグループ化プレビューにより、サービスのオーナーはインテリジェントアラートグループ化をアクティブにする前に、潜在的なノイズ低減とグループ化動作を理解することができます。

2017年12月21日  (更新日:2022年3月10日)     |    インシデント&アラート

クリティカルなアプリとインフラを継続稼動させる

「インシデントのライフサイクル管理? ある事件から次の事件まで生き伸びさせることができれば、 良い一日。悪い日は何もかもパニックさ」

残念ながら、これは非常に多くのソフトウェアやIT企業のインシデントライフサイクル管理の現実ですが、必ずそうなるものではありません。本来は、本物のプロアクティブなインシデントライフサイクル管理により、インシデント対応チームが慢性疾患やパニックモードに陥るのを防ぐことができるのです。

インシデントライフサイクル管理は、インシデントを分類、応答、解決、および文書化するためのフレームワークであり、サービス損失を最小化し、良く組織化されたフォローアップをもたらします。重要なサービスを維持するには、エンドツーエンドのインシデント解決フレームワークが不可欠です。

顧客中心のインシデント管理を

最新のインシデント管理システムは、英国政府のセントラル・コンピューティング・アンド・テレコミュニケーションエージェンシーによって1980年代に最初に開発されたITIL(注1)モデルに基づいています。ITILモデルは、厳密に技術仕様に従って主要システムを維持するのではなく、クライアントや顧客にサービスを提供することを中心にしています。これは、ユーザーサービスのメンテナンスが非常に重要な外部向けのアプリケーションでのインシデント対応の理想的なモデルになります。インシデント・ライフサイクル管理フレームワークを設定する際に留意すべきITILモデルの最も重要な点は次のとおりです。

初期対応

これは、着信アラートが記録され、分類され、適切なチームにルーティングされるフェーズです。多くの点で、これはインシデント管理ライフサイクルの中で最も重要な部分です。なぜなら、問題を検出し、ノイズ(対応不可能なアラート)をフィルタリングし、優先順位を設定し、各アラートをどこにルーティングするかを決定するからです。

プロセスのこの部分を適切に管理できないと、重要なアラートが見落とされたり、あまりにも低い優先度で処理されたり、誤った担当者にルーティングされたり、レスポンスチームの作業負荷が不均衡になったりする可能性があります。

レベル1レスポンス

アラートが分類されると、アラートはレベル1対応チームに送信されます。レベル1のチームが最初の対応者です。彼らの仕事は、典型的には特定の時間枠内で、顧客満足度を満たすように解決することです。レベル1のチームは、事件を調査し、基本的な問題が何であるかを把握し、可能な限り、既知の修正または推奨された修正を適用します。

レベル1のサポートは、インシデントの特にエスカレーションに関するステータスも監視します。レベル1のサポートのもう1つの重要な責務は、影響を受ける顧客とのコミュニケーションを維持し、契約や組織ポリシーによって設定された間隔で状態の更新情報を提供することです。これにより、たとえインシデントがより高いレベルのサポートに引き継がれたとしても、一貫した通信チャネルを維持することが可能になります。

レベル2レスポンス

インシデントがレベル1サポートの診断と迅速な解決能力を超えている場合、より多くのリソースと経験を持つレベル2のサポートチームに引き継がれます。

レベル2のチームは、製造業者、ベンダーなどからの専門的な助言を受けることもできます。レベル2サポートの基本的な目標は、レベル1と同じ状況に戻す、つまり顧客またはクライアントへのサービスをできるだけ迅速に復元することです。

解決後のレポート作成とレビュー

正式なITILモデルでは、解決後のプロセスはインシデントのクローズと評価、およびインシデント管理レポートの2つに分けられます。多くの組織、特に小規模の組織では、それらを1つのプロセスにまとめるほうが便利かもしれません。

解決後のまとめの重要な要素は、解決策(またはその不足)の検証、記録、評価、およびインシデントの詳細報告(通常、事後検証報告による)です。インシデントの事後検証報告は、将来のインシデントへの対応(うまくいけば防止)のために簡単にアクセスできる情報源として機能するように、対応チームやマネージャーが利用できる、インデックスが付いて検索可能な情報として蓄積されなければなりません。

その他の重要な問題

上記の要素に加えて、ITILモデルには、現実的なインシデント・ライフサイクル管理システムで活躍する2つの要点があります。

重大インシデントのハンドリング

重大インシデントは通常、基本インフラストラクチャや主要なサービスの運用、あるいはセキュリティに直接的かつ深刻な脅威を与えるものです。目的は、できるだけ早くシステムを稼働させることですが、初期応答の優先順位とレベルははるかに高くなります。重大インシデント、例えばハードウェアインフラストラクチャの重要コンポーネントが故障した場合などには、レベル2となり、専門サポートチーム、サードパーティのサポートに直接渡すことがあります。

各組織は重大インシデントを構成する要件について独自の基準を作れますが、優先順位と対応のレベルがはるかに高い独自のカテゴリーに設定することが肝要です。

応急策

ITILモデルのインシデント管理の最優先事項の1つは顧客サービスを可能な限り迅速に維持、復元することであるため、初期の対策には応急策(ロールバックなど)が含まれる可能性があります。これはすべてのレベルで当てはまります。その理由は単純です。顧客サービスを今復元するとすぐに問題を解決でき、運用チームや開発チームは根本的な問題を解決するために必要なだけ時間を取ることができるからです。

インシデントレポートシステムと運用、開発アップデートのスケジューリングの両方で、すべての応急策をログに記録して識別することが重要です。また、応急策を取ったことで技術的負債(注2)が発生し、そのコストは負債を解消するまで大きくかつ長くなります。つまり、インシデント対応に適用した応急の回避策は、できるだけ早くシステム設計基準に準拠したソリューションで置き換える必要があります。多くの点で、回避策がより永続的なソリューションに置き換えられるまで、インシデントは完全には解決されません。

インシデント対応チームが日常的にサバイバルモードで運用を続ける必要はありません。インシデントへの準備ができていなくても顧客に対して大きな影響がない場合は、そうすることで混乱と不安が生じます。

組織のニーズに合わせたインシデント・ライフサイクル管理フレームワークにより、重要なアプリケーションやインフラストラクチャーを最小限のサービス中断やストレスなしに管理できます。インシデントライフサイクルのベストプラクティスを実装することが信頼性の鍵であり、信頼性そのものは長期的な成功を左右する不可欠なサービスです。

※注1:ITILはITサービスマネジメントを実現するため、ITサービスの品質向上、中長期的なコストの削減などを目的として実在する企業、サプライヤ、コンサルタントなどからITサービスに関する実際の運営方式やノウハウを収集し、書籍化したもの。欧米社会においてITILは既にITサービスマネジメントの業界標準として広く認知されており、社会的な地位を確立している。(ウィキペディア)

※注2:技術的負債(英:Technical debt)とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。「設計上の負債(design debt)」とも言う。1992年ウォード・カニンガムが、技術的な複雑さと債務の比較を経験報告で初めて行った。(ウィキペディア)

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

中小企業のスマートアクティベーションと効果的なデベロップオフ

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

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

優先順位をつける

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

再現

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

エスカレーション

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

調査

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

回復

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

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

2017年12月15日  (更新日:2022年3月10日)     |    インシデント&アラート

インシデント管理による優れたSecOps

脅威の影響範囲は狂ったようなペースで拡大しています。毎日新しい脆弱性が露わになり、ITOps担当者が管理するサーバ、アプリケーション、およびエンドポイントの量は絶えず増加しています。最近の世界的なランサムウェア攻撃の脅威が数千ドルを加害者に稼がせていることで分かるように、これらの脅威はさらに強力になり頻発するようになっています。専門家は、犯罪者がしばしばデータ破壊の試みを隠す偽装をしていると考えています。

組織がより機敏になるようバイモーダルITOps(2つの流儀のITOps)の手法を採用するにつれて、インシデントを回避し、セキュリティを強化することはかなりの難題を引き起こす可能性があります。新しい課題には、コンテナとパブリッククラウドリソースを活用することと、これらの別々のデータドメイン間でセキュリティインシデントを管理すること、そして重要なリソースにアクセスできる新たな擬似管理ユーザーの集団を運用することが含まれます。ますます拡大するITOpsの要求に対して全層に渡る可視性とインシデント解決を可能にするには、SecOpsへの多面的な戦略が必要です。実際、SecOpsインシデント管理は、実用的で見やすい真に安全な環境を構築するために必要な組み合わせだという考えに私は傾いています。

フェーズ1:脅威を止める

まず第一に、SecOpsスタックの複雑さを軽減することが、SecOpsポリシーを実施するのに役立ちます。簡単に言えば、攻撃を阻止し、ITOpsチームに修復する必要があることを通知します。単純さは、セキュリティアラートやインシデントのノイズを削減し、本当に重要なシグナルに集中できるようにするためにに重要です。SecOpsのプラクティスでは、チームが組み込みのストップウォッチを活用して、可能な限り迅速に対応し、脅威がSLAや重要なデータに損害を与える前にそれを停止することを保証します。過酷な状況の好例は、ネットワークとシステムがゼロデイ攻撃やランサムウェアにさらされている場合です。このような場合、重要なのは、大規模な脅威への暴露を防止し、インシデント管理システムにアラートを発行するという戦略を構築することです。CryptolockerやCryptowallのような暗号化されたランサムウェアの場合、そのランサムウェアが脅威をもたらすのを防ぐツール(ソフォスのインフォグラフィックスの第2段階を参照)を利用して、ハンドシェイクを防ぎ、暗号の感染を回避することが目標です。

ファイアウォール、エンドポイント、第三者のセキュリティ監視ツール、およびその他の関連するデータソースを、中央のインシデント管理ソリューションにパイプすることができます。このように、SecOpsとITOpsには、優先度の高い問題の効果的な調査と修復に必要なデータとワークフローが即座に通知され、装備されます。効果的なセキュリティツールを使用することは、セキュリティインシデントの管理の成功に不可欠です。

フェーズ2:インシデント管理と修復

問題を検出して通知する能力だけでなく、事態の収れんや将来の予防策を十分に考えておくことは、ベストプラクティス、エンドツーエンドのセキュリティインシデントライフサイクル管理と同様に重要です。また、このフルスタックの可視性を実現するには、すべてのセキュリティシステムを集中的なインシデント管理ソリューションに統合して集約したいと思うでしょう。例えば、SNMPトラップ/クエリを活用して監視プラットフォームに情報を集約するようにファイアウォールやネットワークデバイスを構成します。さらにsyslogサーバーを統合し、すべてのセキュリティインシデントをこれらのソースに送信するようにします。

ファイアウォールとネットワークのsyslogを設定するときに、Info、Debugアラートと、Warning、Criticalアラートの間のしきい値を設定することで、かなりの時間を節約し、アラート疲れを軽減できます。ベンダーによって、しきい値が異ながす。 ただし、SNMPではOID(注:オブジェクトID)をフィルタリングしてInfo、Debugアラートを無視しWarning、Criticalアラートを許可することで、重要度の高いアラートのみをインシデント管理システムへ送信させるようにできます。

syslogを使用すると、より詳細なログ条件を設定できますが、ここで重要な点は、ノイズを抑えて特定の条件に合う場合にのみ通知させることです。これらのイベントを監視システムに集約できれば、実行可能な情報でアラートを強化したうえでチームに送信して脅威を修復するフレームワークを構築できます。

syslogは、いくつかの理由で価値あるものになります。監視システムに流入するセキュリティとネットワークデータに関する詳細な情報を取得するだけでなく、侵入検知と防御と脅威情報の収集も容易にすることができます。syslogを監視システムに直接つなぐのではなく、syslogデータをAlienVaultやLogRhythmなどのサードパーティの侵入解析システムに送信して侵入を容易に見つけられるようにしたり、ログデータを豊かにしたり、即応性の高いアラートを作成したりすることもできます。その後、PagerDutyなどのインシデント管理システムにアラートを送信して、関連のある症状をグループ化し、根本的な原因を理解し、適切なエキスパートにエスカレートし、適切なコンテキストで是正し、今後のセキュリティインシデント対応を改善するための分析や反省を実施できます。

結論**:セキュリティツールを活用して脅威を実際に阻止する

ベースラインモニタリング**:ベースラインのモニタリングおよびアラートポリシーを確立する

エンリッチメント**:サードパーティのツールを活用してデータと脅威情報を強化にする

インシデント管理**:フルスタックの可視性を最大化し、問題の優先順位付け、ルーティング、エスカレーションを保証します。ワークフローと分析で解決までの時間を短縮できます

最後に付け加えると、ハイブリッドクラウドやパブリッククラウドのリソースを使っている組織でも、同じフレームワークを実装できます。ただし可視化とアラート分析を強化するには、さまざまなサードパーティのツールを活用する必要があります。たとえば、Amazonクラウドを利用する際にはAWS Cloud Watchを活用して、あるいはMicrosoft Cloudを活用する際にはAzure Alertsを活用することで、パブリッククラウドサーバーの監視とアラートを使い、類似のしきい値の設定とノイズ削減が可能になります。さらに幸いなことに、Evident.ioやThreat Stackなどのサードパーティのツールもあり、アジャイル、パブリック、ハイブリッド、またはバイモーダルのITOps戦略を持つ誰もが、クラウドインフラストラクチャ全体にわたってセキュリティに焦点を当てた分析を簡単に実行できます。

SecOpsチームに合う完全なインシデント管理プロセスを設計する際に活用するツールやシステムは、シンプルさ、可視性、ノイズリダクション、実行可能性といった基本的な部分がその成功に最も重要な要素になります。ITOpsとSecOpsのチームはビジネス上に求められるものでは非常に似通った立場にいます。そこでは、2つのチームが絶え間なく増大するデバイス、サービス、およびその他のエンドポイントのリストに安全かつ効率的にアクセスする能力とビジネス上の要求がしばしば競合します。

セキュリティインシデント対応のベストプラクティスの詳細をさらに知りたければ、我々が社内で使っているPagerDutyのオープンソースドキュメントを参照してください。実行可能なチェックリストと、攻撃方法を遮断する方法、レスポンスチームを組織する方法、侵入されたデータを処理する方法などの情報を得ることができます。これらのリソースが、効果的なインシデント管理を備えたSecOpsを最適化するための強固なフレームワークを構築する上での最初の出発点になることを願っています。

2017年12月15日  (更新日:2022年3月10日)     |    インシデント&アラート

インシデント管理をスケールさせる方法

インシデント管理は、現代のITOpsチームの成功に最重要です。しかし、ビジネスを成長させるようにインシデント管理をスケールさせることは、成長の痛みを引き起こす可能性があります。監視が必要なデバイス、アプリケーション、システムの規模が拡大するにつれて、ノイズも増え、オンコールスタッフの管理の複雑さも増えます。チームのエンジニアの数が増えるにつれて、効率的で負荷が公平に分散されるような人員配置や、新しい通知方法の実装、時間外の運用計画を立てるのが困難になります。また、ITのハイブリッドモデルとバイモーダルなIT環境を志向する動きは、インシデント管理を複雑にする可能性があります。それにもかかわらず、いくつか実証された技術を試してみると、インシデント管理を計画的で組織的かつ効果的な方法で拡張することができます。

変化するITOps環境に被害を与えない

スケーリングが深刻な問題になる例を参考にまずこの問題の重要性を理解しよう

あなたは会社が新しい事業を買ったのを知りました。そこで、あなたは新たなインシデント管理プロセスを始めることになります。あなたのOpsチームは、すでに担当していることに加えて、新しいIT環境を引き継がなければなりません。まずあなたは、新しいスタックに同じツールと方法を適用することができる完璧なシナリオがないかを考えます。

しかし、現実は完璧ではありません。新しい会社は、以前と違う技術スタックと異なるインシデント管理の監視ツールと方法論を活用するかもしれません。このシナリオは非常に困難ですが、ITチームの成長や、よりアジャイルでバイモーダルなITOps構造の採用など、あらゆる成長シナリオと非常によく似ています。あなたがどんなスケールのシナリオに直面するにせよ、監視、インシデント管理、およびチームの拡大に取り組んでいる組織のためには下記が参考になります。

スケールの主な領域を特定する

新しいハードウェア、ソフトウェア、またはサービスを実装していますか? あなたの将来のITOps環境には新たな複雑さがありますか? あなたのエンジニアリングチームは育っていますか? コードエラーを報告する必要があるアプリケーションを継承しましたか? いずれの場合でも、ITOpsチームが業務を拡大することを余儀なくされている分野を特定する必要があります。

監視ツール

監視ツールが確実にスタック全体をカバーできるようにすることは、スケーリングの成功に最も重要です。この変更を採用するには、現在のスタックの外に複数の、または全く新しい監視システムを実装する必要があるかもしれません。これらのシステムの目的は、フルスタックの可視性を得ることであり、多くの場合、異種システムや新しいシステムを適切に監視するために、さまざまな監視ツールを実装する必要があります。しかし、組織化されたスケールを本当にサポートするには、このデータすべてを正規化し、重複を排除し、相関を取り、実行可能な洞察を得る方法が必要です。各監視ツールによって生成された全イベントを、単一のハブに集中させる必要があります。このハブからはイベントがトリアージされ、オンコールエンジニアにルーティングされるようにできます。

ノイズ減少

監視を実施するのは、効果的なインシデント解決のためにデータを理解することが目標です。監視ツール全体のルーティング動作を調整し、適切なしきい値を設定することは、新しいツールを実装した後にチームがアラート疲れを経験しないで済むようにするための次の大きなステップです。データを集約し、共通のインシデント管理システム内のページングからの対応不能なアラートを抑制またはフィルタリングすることは、ノイズを削減し、スタック全体のインシデントの可視性を高めるために重要です。

事故管理

包括的なインシデント管理プラットフォームは、すべてのツールのデータを統合し、スケールを拡大しながら成長するのに役立ちます。これは、すべての異種監視アラートを1つの共通システムに統合するだけでなく、リソース管理に関する混乱を防ぎ、エンジニアリングチームの成長をサポートします。さらに、より組織的なコラボレーションだけでなく、よりアカウンタビリティを促進するのに役立ちます。ボーナスとして、インシデント分析を活用して、上司にITOpsチームがどれだけうまく稼働停止を管理し解決するかを示すことができます。

スケールと複雑さは去っていません

ITOpsの世界は急速に進化していますが、1つの点は明らかです。ITチームは、業務拡大に全力を傾けるように指示されています。ITOps環境は、よりハイブリッドでアジャイルなアーキテクチャとフレームワークへと移行しています。ユーザーは、さまざまなデバイス間でデータへの高速で信頼性の高いアクセスを絶えず要求しています。その結果、ITOpsチームはスケーリングの計画を立てる必要があります。ダウンタイムの損害が大きくなるにつれて、インシデント管理が必要になっているのです。

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

ファーストデータ、ファーストモニタリング

ビッグデータはもう古い。 今日、データを効果的に活用するための鍵は、ファーストデータです。

大量の監視情報の収集と分析を伴う従来のインシデント管理ではもはや十分ではありません。 また、監視データの収集だけでなく それをリアルタイムで実行する「ファーストモニタリング」が必要とされています。

ここでは、ファーストモニタリングが意味することを検証し、インシデント管理チームがこのアプローチを実装して大きなメリットを実現する方法について説明します。

ファーストデータの定義

ファーストモニタリングの概念を理解するためには、ビッグデータの世界で最も新しいイノベーションの1つであるファーストデータを理解する必要があります。

非常に簡単に言えば、ファーストデータは高速にビッグデータを処理することです。 ビッグデータとは、伝統的に大量の情報を保存して後で分析することを意味しますが、ファーストデータとは、大量の情報をできるだけ速く、理想的にはリアルタイムでデータ分析を実行することを意味します。 その目標は、できるだけ実用的で関連性のあるデータを分析することです。

ソースから分析プラットフォームにデータをストリームするのは、ファーストデータを活用する上で重要な部分です。 これが、Apache Sparkのようなビッグデータツールが近年普及している理由です。 ストリームデータの収集とインメモリ処理をサポートすることにより、Sparkは非ストリーミングやハードディスクによるデータ解析プラットフォームよりもはるかに高速で大量の情報を取り込み、分析できます。

ファーストデータとインシデント管理

インシデント管理はデータ分析とは異なる分野ですが、インシデント管理者はファーストデータへの移行トレンドから多くのことを学ぶことができます。 インフラストラクチャの監視とインシデント管理の世界では、大量の監視とアラートのデータをリアルタイムで分析してレスポンスを向上させることが、これまで以上に重要になっています。

伝統的なインシデント管理から迅速なインシデント管理まで

ファーストデータとファーストモニタリングのつながりは偶然ではありません。多くの点で、インシデント管理の進化はデータ分析の進化を反映しています。

約10年前までは、インフラストラクチャのデータは比較的小さくて済んでいました。ほとんどの組織では、それほど多くのデータを生成しなかったため、ペタバイトクラスのデータを分析する必要はありませんでした。同様に多くの組織は、大規模で多様なインフラストラクチャをサポートできる監視ソリューションを必要としませんでした。代わりに、サーバやワークステーションからなる比較的小さくて複雑ではないネットワークをトラックするためのベーシックな監視システムで済んでいました。

そして、2000年代半ばには、データとインフラストラクチャの両方が大幅に拡大し始めました。すべてをデジタル化することで、組織は大量の情報収集を開始し、ビッグデータを生み出しました。その一方で、モバイルデバイスの普及、仮想化の台頭、さらにますます強くなるコンピューティングパワーの必要性は、インフラストラクチャをはるかに大きく複雑にしました。この新しい状況には大規模なモニタリングが必要でした。

そして、ここ数年の間に、もうひとつの変化が起こっています。情報が絶えず変化している時代には、ほんの数時間の分析の遅れでもデータの価値が損なわれます。同様に、最新ではない情報を監視することに基づいてインシデント管理を実行することにより、管理者はインシデントを迅速に処理して対応することができなくなります。

したがって、ファーストデータとファーストモニタリングには異なるツールセットが必要な場合がありますが、両方の動機と原則は同じです。インシデント管理チームがインフラストラクチャとアプリケーションをできるだけスムーズに稼動させようとファーストモニタリングに専念するのは、データアナリストの仕事とよく似ています。

ファーストモニタリングの促進

情報の収集と迅速な対応は簡単に聞こえるかもしれませんが、実際にはどのようにしてファーストモニタリングを行うことができるでしょうか。主なガイドラインは次のとおりです。

データ収集を一元化する:** 迅速に情報を監視するためには、すべての監視データを中央のインターフェイスに転送する必要があります。これにより、異なるダッシュボードや監視システムを切り替える必要がなくなり、時間と精神的なエネルギーを無駄にするだけでなく、根本原因を理解することが非常に困難になります。 利用可能なすべての情報を収集する:** 伝統的なインシデント管理は、マシンのデータとアラートの収集だけに集中する傾向があります。その情報は、迅速な監視を行うために必要なものの一部を提供しますが、可能な限り迅速にインシデントに対応するためには、可視性と洞察力を可能な限り広げるべきです。たとえば、チケットやサポートコールから人間が生成したデータを収集することを無視してはいけません。これは、PagerDutyのカスタムイベントトランスフォーマーなどの機能を活用して、従来はインシデント管理ワークフローの一部ではないソーシャルメディアチャネルなどのソースからデータを収集することも意味します。 ノイズを最小限に抑える:** 大量のアラートを受け取っても、アクションを必要とするのはそのうちの一部だけです。 したがって、警告の数が最小限になるようにノイズをカットし、対応不要なものを抑止することは絶対に重要です。重複するアラートは自動的に排除されるべきであり、解決が必要な単一の問題に関連する症状をグループ化するのは簡単なはずです。これにより、注意を必要とするアラートの瞬時識別が容易になり、リアルタイムで適切な応答ワークフローが開始されます。 データを解釈しやすくする:** 大量の監視データを収集し、中央の場所に格納することで、そのデータをすぐに価値に変えることができます。 しかし、ダッシュボード上の情報を分析する負荷を軽減するには、さまざまなソースからのデータを一貫した形式に正規化する必要があります。 そうすれば、さまざまなベンダーのすべてのスキーマを暗記する必要はありません。 これを実現するには、さまざまな形で情報を取得し、フィールドを普遍的なものに標準化し、即座に実行可能でわかりやすい洞察を与えるインシデント管理ソリューションが必要です。

これらのプラクティスはすべて、重大な事故の際にインシデント管理者が必要とする手動分析の量を最小限に抑えます。 また、アラート収集とアクションの間隔を最小限に抑え、インシデント管理スタッフがインシデントに素早く反応し、ファーストモニタリングをリアルタイムレスポンスに変えて正常稼働時間を向上させます。

<  123  >