小売業向けインシデント管理法
近年、1年で最も忙しいショッピングデー「ブラック フライデー」(注）にシステム障害が多発しています。
有名ブランドのWebサイトの停止やシステムトラブルの記事を目した管理者は、他人事とは思えないでしょう。大規模な小売業者でもスムーズにインフラストラクチャーを稼動させるのに苦労しているというのに、中小企業はどうすれば障害を防止できるでしょうか。
幸いにも、手はあります。適切なインシデント管理手順に従うことで、小規模のチームでも必然的に起こる業務の中断による影響を最小限に抑えることができます。
ここでは小売業者のニーズに焦点を当てて解決法を紹介します。
（注；ブラックフライデー（英語: Black Friday）とは、小売店などで大規模な安売りが実施される11月の第4金曜日のことである。 アメリカ合衆国では感謝祭（11月の第4木曜日）の翌日にあたり、正式の休暇日ではないが休暇になることが多い。当日は感謝祭プレゼントの売れ残り一掃セール日にもなっている。買い物客が殺到して小売店が繁盛することで知られ、特にアメリカの小売業界では1年で最も売り上げを見込める日とされている。また、年末商戦の幕開けを告げるイベントでもある。 ）
小売業者の優先順位の定義
小売業者の効果的な監視とインシデント管理を行うために、管理者はまず、インフラストラクチャの可用性と稼働時間に関して小売業者の最も重要な要件が何であるかを理解しなければなりません。
実店舗とオンラインショップの両方を備えた最新の小売業者にとっては、以下を確実に行うことが不可欠です。
顧客がアクセスするWebサイトを常に正常に稼動させる。** 顧客が接触するサイトがパブリックなインターネット上にあり、DDoS攻撃など悪意のあるトラフィックスパイクからクラッシュする可能性や不正侵入の脅威があるからです。Webサイトは販売促進のために実店舗のみの小売業者にも不可欠です。顧客は通常、オンラインで購入するか店舗に足を運ぶかにかかわらず、購入を計画するためにWebサイトを使用します。
バックエンドシステムの稼動を維持する**。在庫の追跡やトランザクション履歴の保存などのタスクを処理するバックエンドサーバも、ビジネスオペレーションにとって不可欠です。一般にバックエンドサーバはプライベートネットワーク上で実行できるため、パブリックサイトよりも攻撃者から保護しやすいですが、一方で別の脆弱性も持っています。非常に機密性の高い情報が保管されていたりするので、効果的なモニタリングが不可欠です。
POSシステムの安定稼働を確保する**。小売業者はPOS端末がクラッシュした場合、販売を続けられなくなります。POSシステムを稼働させ続けるには、ローカルネットワーク接続から物理的なセキュリティ、さらに電源供給まで、複雑な変数の組み合わせを効果的に管理する必要があります。
IoT資産を保護する**。小売業もIoTを活用してワークフローをパーソナライズし、自動化することでデバイスとセンサーの安定稼働と接続性を保証し、業務を強化します。高度に自動化されたIoTデバイスベースのビジネスオペレーションへの移行は、システム監視の分野でも新たな課題となります。
これらは、取引完了を確実にするための小売業者の第一の要件です。ここでは、監視とインシデント管理を使用して重要な課題に対処する方法について説明します。
システムダウンの防止
小売業のシステムインフラの重要な部分を円滑に運用するためのガイドラインを紹介します。
インフラストラクチャ全体の可視性を最大化する**。非常に多くの要素があるため、小売業者は特に複雑で多様なITインフラを持つ傾向があります。それはWebサイトだけでなく、バックエンドシステムや各種専用デバイス、センサーなども含みます。このようなインフラストラクチャを把握するために、全面的な可視化が必要です。監視情報はそれを理解する唯一の方法であるため、1カ所に集中させる必要があります。
柔軟な監視ソリューションを導入する**。多様なインフラストラクチャには、多様な監視ツールが必要です。小売業者は、インフラストラクチャのさまざまな部分にすべて監視エージェントをインストールし、収集した監視情報を中央の管理プラットフォームへ転送し、正規化する必要があります。
リアルタイムに対応する**。小売業者にとっては、販売サイトやPOSシステムの数時間（またはわずか数分）のダウンタイムが非常にコストの高い影響を与えます。ダウンタイムの直接的な結果として失われた売上に加えて、企業も評判にも損害を与えます。したがって、影響は数カ月続く可能性があります。これらのリスクを軽減するために、インシデント管理システムとワークフローが鋭い洞察を基にしたリアルタイム応答を可能にし、サービスができるだけ迅速に復元されるようにする必要があります。
効果的コミュニケーションを図る**。小売業におけるインシデント管理の課題のひとつは、企業のインフラストラクチャが、特に店舗や倉庫の大規模なネットワークを持つ小売業者にとって、非常に大きく広く分散する傾向があることです。インフラストラクチャの稼動を維持する管理者も分散しがちです。この課題に取り組むには、シームレスなコミュニケーションツールを提供するインシデント管理システムが必要で、ChatOpsなどの共同作業ワークフローを活用すべきです。そうすれば、広範囲に広がった大規模な管理者チームでも、問題を解決するときに効果的にコミュニケートできます。
ダウンタイムをもたらす脅威を完全に排除することは決してできないと言っても過言ではありません。しかし、最新技術による監視とインシデント管理のソリューションは、小売業者が大規模なサービス障害の話題の提供者にならないために重要な役割を果たします。
インシデント＆アラート
インシデント管理が全従業員のやる気をアップ！
失敗への恐れは開発チーム や運用チーム のメンバーにとって大きな壁となります。この恐怖は耐えがたいもので、社内の士気を大幅に下げ、従業員の生産性と進歩も傷つける可能性があります。
適切なインシデント管理とモニタリングを実施するだけで、アラートを管理して分析機能を提供する以上の効果が得られます。つまり開発の失敗を軽減し、アプリの作り方や投入方法を変えられるようにすることもできるのです。効果的なインシデント管理ソリューションを導入して、開発チームの士気を高め、最高の仕事ができるようにするいくつかの方法を見てみましょう。
インシデント対応中のストレスレベルを下げます
ストレスの軽減は正しいデータを得ることから始まります。正しいデータを持っていない場合は、どこを見て解決すべきかが分かりません。インシデント管理では、適切なコンテキストで全ての適切なアラートを集中管理し、関連する監視ツールのデータを浮かび上がらせることでさらに深く分析を掘り下げることができます。これはインシデントのトラブルシューティング時にチームがよりうまく動き、問題をより速く解決するのに役立ちます。全てのツールのデータをインシデント管理ソリューションに統合することで、チームの誰が何を担当しているかを全員が把握できます。さらに、問題を素早く修復するために必要なデータ（ランブック、グラフなど）も備えています。より速い解決は常にチームをよりハッピーにします。
( 注：ランブックは、運用時に実施する一連の操作について、手順を明確に示した操作指示書のこと）
新機能でインシデントの発生が予測可能になります
インシデント管理プロセスがうまく機能している場合、何が原因で繰り返しダウンタイムが発生するのか、またどのインフラストラクチャやアプリケーションが障害の影響を受けやすいのかが分かります。これにより、新しい機能を追加する際の信頼性が向上します。QAチームは、例えば、注意を必要とするアプリの特定のエリアをチェックするテストを書くことができます。また、経験から問題の原因が分かるため、新しい機能を拒否することさえできます。チームが新しい機能のフィードバックを提供するには、システムの機能と定期的に起こる問題についての深い理解が必要です。このような理解はインシデント管理プラットフォームを使うことでしか得られません。この予測可能性は、チームが「システムを信頼する」ことを助け、あらゆるステップで次に何を期待できるかが分かるようになります。この心の安らぎは従業員の士気と自信を高めます。
全チームが優れたユーザーエクスペリエンスを 提供できるようにします
伝統的に開発チームは、アプリケーションのコードを書きあげて、「壁の向こうの運用チームに投げ込めば」、自分たちの仕事は終わるものと思っていました。同様に、運用チームは、提出されたコードの品質を保証することは自分たちの仕事ではなく、開発から来るものをデプロイすればよいと思っていました。インシデント管理が機能すれば、開発チームと運用チームが統一されたプラットフォームで連携して、チーム間で可視性と一貫性のある単一の真実に向き合えるようになります。彼らは、どれがコードに起因する問題か、そしてどれがインフラストラクチャに起因する問題かを認識できます。
つまり稼働時間は、いくつのサーバが稼働しているか、アプリケーションのどれくらいが正常に稼働しているかによって決まるのではなく、エンドユーザーの経験によって評価されているのだということです。稼働時間に関するこの現実的な見方は、チームの目標とプロセスを、ユーザーの期待を超えるアプリケーションを提供するというより広いビジネス目標へと向かわせます。幸せな顧客がチームを幸せにするのです。チームの仕事のおかげでエンドユーザーが喜んでいることを見せる以上に、従業員の士気を高める良い方法がありますか？
パイプライン全体を加速します
ゲームを変えるようなアプリケーションを構築したい場合は、スピードが不可欠です。インシデント管理は、インシデントが発生したときに、開発チームと運用チーム（ヘルプデスク、サポート、ビジネス関係者など）間の明確なコミュニケーションを可能にします。コミュニケーションのボトルネックが解消されば、チームメンバーは繰り返し起きる問題をより短い時間で解決できるようになり、顧客の幸せを保つためのアプリケーションの開発にもっと多くの時間をかけられるようになります。アプリの開発に使える時間が増えることは、品質向上と市場投入までの時間短縮をもたらします。市場への投入がより迅速になり、チームが1日あたりに出来ることが増えれば、彼らは自分たちの能力が上がったと感じ、より深く取り組むようになり、自分の仕事に情熱を感じるようになります。
オーナー感覚を作り出します
インシデント管理は、インシデント対応のさ中にチームメンバーがより責任を持ち、インシデント対応の手順を確立して、より上位の人たちに頼ることなく重要な意思決定を行えるようにします。決定する能力を持つことは簡単なように思えるかもしれませんが、組織のプロセスの中でチームメンバーがより強い影響力と自信を持つようになるまでは、長い道のりがあります。上位のチームメンバーからの許可を待たないようにすれば、お役所仕事を減らせます。チームのメンバーは、顧客の体験を24時間確実にサポートするために、オンコールを担う責任を全うしています。あらゆるレベルのチームメンバーが意思決定に関与できるようにすると、無茶苦茶なカオスや冗長な作業に費やす時間を短縮し、貴重な時間を無駄にせず、実際の開発に多くの時間を割けるようになります。
効果的なインシデント管理ソリューションは、失敗への恐れを減らし、予期せぬ事態をチームが自信を持って管理できるようにし、結果として従業員の士気を向上させます。チームメンバーが獲得できた信頼感は、パイプライン全体で革新と標準化を推し進め、従業員の士気、生産性、成功を大幅に向上させます。
インシデント＆アラート
良いインシデント対応が金融機関への顧客の信頼を増す
「そこには金があるから」。悪名高い銀行強盗Willie Sutton（注：William Francis “Willie” Sutton, Jr. (June 30, 1901 – November 2, 1980)）が言ったように、金融機関はセキュリティ犯罪の最大の被害者です。サイバー犯罪者がセンシティブなデータや金融資産を盗もうとする試みを止めるために、金融機関ができることはあまりありません。被害が増えているために金融機関は顧客と規制当局からますます厳しい監視を受けています。
事実、FDIC（Federal Deposit Insurance Corp.、連邦預金保険公社）の審査員は、必要とされるインシデント対応の最小要件https://www.fdic.gov/regulations/examinations/supervisory/insights/siwin06/article01_incident.htmlを参照 を提示して侵害が判明した場合、規制当局と顧客に通知することを要求します。
しかし多くの金融機関は、進行中の損害に対してクリティカルなインシデント対応をすることにかかりきりになってしまいます。これは時間を浪費するだけでなく、組織の準備が整っていない、あるいは適切なセキュリティ管理策を講じていないという印象を残してしまいます。
インシデント対応計画を立てておく
規制当局は金融機関の規模に関わらず、より広いリスク管理基準でITセキュリティを日常的に監視していることを明らかにしています。そのため、セキュリティ侵害防止対策だけでなく、インシデント対応の有効性についても、金融機関に説明責任を課しています。完全なセキュリティは存在しませんが、金融機関はセキュリティ侵害が発見された場合、ただちに対応できなければなりません。また、迅速な解決と異なる部門間で効率的な緊急連絡の手段を備えていなければなりません。
そのため、金融機関にはIT部門の問題解決の方法から、財務、法務チームが迅速に規制当局とやり取りする方法、必要に応じて顧客と市場に情報提供する方法に至るまでの、対応計画が必要です。ビジネスへのダメージを軽減するには、セキュリティ侵害が発生したときに重要なステークホルダーを関与させるための明確な枠組みが必要です。このようなシステムを導入することで、財務的、法的に重大な影響を及ぼす可能性を見落とさないだけでなく、金融機関とその資産が健全であるという安心感を顧客や株主に与えることができます。
情報共有
そのために、インシデント対応フレームワークは、組織と顧客に対するセキュリティ侵害の影響を緩和するための透明なプロセスでなければなりません。例えばIT組織内の全員がインシデントの影響を評価するための手続きを理解し、適切な専門家を迅速に動員し、基本的なトラブルシューティングや修復を実施できる必要があります。さらに、組織内のステークホルダーは、IT担当者が誰かを正確に把握できるだけでなく、問題解決にかかる時間を顧客に知らせるためにどんな言葉を使うべきかをリアルタイムで理解する必要があります。
このようなベストプラクティスは自然に出来上がるものではありません。ビジネスリーダーとITリーダーはトーンを調整する必要があります。組織が適切なプロセス（定例の研修や実践を含む）を用意していれば、セキュリティ侵害や他の形態のITトラブルに自然に対処できるようになります。金銭的損害の出るセキュリティ侵害よりも唯一悪いこと、そして顧客の信頼を失う最速の方法は、顧客が金融機関そのものではなく、他のソースから問題を知ったときです。そのため、顧客には迅速に問題の発生を知らせる必要があります。
もちろん、サービスに問題があることを顧客に伝えるのは当然として、その問題がいつ解決されるかも正確に伝えられないと、顧客は他の金融機関への乗り換えを検討し始めるかもしれません。チームに適切なプロセスとワークフローが整っているかを常にチェックしましょう。
インシデント＆アラート
セキュリティスタックに入れておくべき6つの必須ツール
最新のセキュリティ監視：どのツールをスタックに入れておくべきか*
クラウドネイティブまたはコンテナ化されたアプリケーションを管理する際には、セキュリティ監視に関するアプローチを完全に変える必要があります。このような複雑な環境では、従来のツールを使ってセキュリティインシデントを迅速にトラブルシュートし解決するのは無理だからです。
これを念頭においてみると、クラウドベースまたはコンテナ化された環境で効果的なセキュリティ監視を行うのに役立つツールがいくつかあります。
コンテナ監視ツール
イメージスキャンツール：コンテナイメージはDockerのセキュリティの中心です。誰でもアクセスできる公開されたイメージはシステムに脆弱性をもたらす可能性があり、使用する全コンテナイメージを検証することが不可欠です。Docker Hubは、基本的なイメージスキャン機能を提供します。プロセスをより詳細に制御するには、ファイアウォールの背後でも機能するDock（Docker Trusted Registry）を選択することができます。さらに、QuayやGitLab Container Registryのような多くのサードパーティのイメージスキャナがあります。どのイメージスキャニングツールを選択するにしても、スタック内で許可されているイメージの種類を厳重に守ることが重要です。できるだけ公式のリポジトリを選択し、未確認のイメージを使用する必要がある場合は、常に完全にスキャンされていることを確認してください。
エンドツーエンドのコンテナ監視ツール：これらのツールはイメージをスキャンするだけでなく、カーネル、ネットワーク、オーケストレーションツール、アクセスコントロールなど、Dockerスタックのすべてのレイヤーを保護します。Twistlockのようなツールは、全面的にコンテナセキュリティツールと統合し、コンテナの監視を1カ所でできるようにします。
クラウド監視ツール
Threatstack、Signal Sciences、Evident.ioなどのツールは、Webアプリケーションやクラウド環境全体で侵入検知とセキュリティ監視を強化するソリューションです。これらのツールは、パブリッククラウド環境の急速な変化に対応し、可視性を提供すると同時にコンプライアンス要件を満たすのを助けてくれるのでリスクを軽減するのに役立ちます。
オープンソースの監視ツール
オープンソースの監視ツールは、あらゆる監視スイートの大事な要素です。それらの機能は、クラウドネイティブアプリケーション用に専用に設計されており、活気にあふれた開発者コミュニティが持続しています。
Calicoはコンテナのネットワークセキュリティツールです。ネットワーク全体に1つのファイアウォールを提供するのではなく、Calicoは各インスタンスを1つのファイアウォールで保護します。このようにして、1つのサービスやポッドが侵害された場合でも、他のサービスやポッドは安全に保たれます。Calicoでは、ポリシーを使用してネットワークセキュリティを定義できます。サービスにアクセスするだけで、タスクを完了できるようになり、そのアクセスを取り消すことができます。
ELKスタック（ELKスタックとはElasticsearch社のElasticsearch（解析） + Logstash（収集） + Kibana（可視化）の3つの製品の総称）は、ログ解析ソリューションとして説明の必要はありません。スタックのデータベースコンポーネントであるElasticsearchは、ログデータの分散ストレージと分析を提供します。シャード（注）用の自動フェイルオーバーとクエリの並列処理により、ELKスタックは規模に合わせて構築されます。使用量を増やすと、ELKスタックを維持するのが難しくなるかもしれませんが、ベンダーがスタックのメンテナンスを担当してあなたが自システムのロギングに集中できるように、ELK用のマネージドサービスを選ぶことができます。
（注：DBのインデックスは、単一ノードのハードウェア制限を超える大量のデータを格納しなければならない場合があります。その問題を解決するために、Elasticsearchは、複数の部分にインデックスを分割でき、これをシャードと呼んでます。）
Prometheusは今日最もホットなオープンソースの監視ツールの1つです。これは主にKubernetesとの深い統合によるものです。これは、ポッド、サービス、コンテナ、ノードなどのKubernetesコンポーネントを自動的に検出します。アラートと通知の基本的な管理を行うアラートマネージャが含まれています。高度なアラート管理とレスポンスオーケストレーションのために、PagerDutyのようなプラットフォームと統合されています。
ログ分析ツール
ELKスタックを独自に管理するのは面倒な作業です。特に、ノードの限界に達するとシャーディングがスムーズに行われるようにするのは手間がかかります。この場合、SplunkやSumo Logicのようなクラウドベースのログ解析ソリューションが必要かもしれません。これらのソリューションは、機械学習を活用してログデータから予測に役立つ洞察を収集します。また、他の監視ツールとの統合も容易です。
インシデント管理ツール
スタックが複雑であると、すべてのコンポーネントに関するレポートデータが常に流れ込んできます。これは圧倒的な量になり、ノイズの中の重要なアラートを見落とす原因となります。PagerDutyのようなインシデント管理ソリューションで、他のすべてのセキュリティ監視ツールを補完することが不可欠です。
PagerDutyは、様々な監視ツールと統合し、すべてのメトリックを1カ所に統合します。パワフルな自動化ルールを適用して誤検知を減らし、適切な人に注意が必要なイベントが通知されるようにします。インシデントの最中は、適切な人物を即座にスタックの状況に関与させる必要があります。これがPagerDutyによって実現されます。
ChatOpsツール
火消しに注力している状況では、他の人と協力する必要があります。これまでは電子メールやチケット管理システムを使っていたでしょうが、今日ではSlack、HipChat、Flockなどのコミュニケーションツールがチームコラボレーションを促進します。また、チャットボットがマシンが生成したデータをチャットインターフェースで伝えます。PagerDutyとSlackなどとの統合により、ChatOpsインターフェイスとインシデント管理ソリューション全体でアクションを同期させ、インシデントをより迅速に共同作業し解決することができます。
クラウドネイティブのアプリケーションを保護する際には、DevSecOpsとインシデントのライフサイクルに関する最良のアプローチを採用してください。多くのツールはユニークな機能を提供しますが、選択したツールが他のツールともうまく機能することを確認してください。問題を検出する際に最大の馬力を発揮できるだけでなく、最も重要なときに指先で適切なデータを取得できるようになります。
ベストプラクティス
DevOpsへのよりディープな監視の導入
継続的インテグレーションのポイント は、ビルドとテスト を自動化し、効率と品質を開発パイプラインにもたらすことです。しかし、継続的インテグレーションプロセスに伴って頻繁な更新が行われると、状況が悪化してしまうことがあります。
重大なインシデントや何か悪いことが起こるとパニックになります。それがインシデント管理のよくある風景です。しかし、何かが起きた後に常にそうなるでしょうか。初めからインシデント管理を継続的インテグレーションプロセスに組み込むことで、アカウンタビリティ、可視性、透明性を全く新しいレベルに引き上げることができます。
ここでは、いかにしてDevOpsへの深い監視を行い、それがアプリケーション開発方法を変革するかについて説明します。
コードの品質に対する責任は 継続的インテグレーションフェーズから始まります
DevOpsの目標は、開発チームと運用チームの協力を促進し、お互いのニーズを理解し、状況が悪化したときでも相手の責任を追求するのではなく共に解決することです。稼働時間の向上は必ずしもOpsチームだけの役割ではありません。DevOpsでは、新たに加わった開発者でさえ稼働時間に責任を感じ、ダウン時には協働することができるはずです。
継続的インテグレーションを実装する大きなメリットのひとつは、開発チームと品質管理チームの両方が出荷品質のコードに対して責任を負うことです。新しいビルドがコミットされるたびに、一連の自動ユニットテストによってコードが検証されます。インシデント管理がこのレベルで実装されていれば、何か不具合が発生した場合には適切なデータが手元に残るため問題を効果的に解決できます。こうして、誰も責めずに、パニックに陥ることもなく迅速にトラブルシューティングを行うことができます。インシデント管理を導入すれば高い品質を求める文化が醸成され、開発チームと品質管理チームは互いに可用性に責任を負うようになります。
緊急医療チームと同じように、責任者が現場に到着する前に最初に働く初心者のエンジニア、つまりオンコールエンジニアを待機させることも良いでしょう。この責任の文化を醸成するには、監視データをチーム間で見えるようにするモニタリングとオンコール管理システムが必要であり、公平なシフトに基づいて計画外の作業を分担する必要があります。
開発チームと運用チーム間の可視性
チーム全体の取り組みと進行状況を把握することで、誰もが自分の仕事に集中できるようになります。多くの企業は、悪い事が起こったときやインシデントが発生したときにのみ、Opsチームに新しいコードの実装を任せます。結果として、Opsチームは不信のために変更を控えていると非難され、更新が遅くなります。
Devチームが計画段階から変更点についてOpsチームに情報公開を行っている場合、それがビジネス全体にどのように役立つかを理解することができます。Opsチームに開発フェーズから新しいアイデア、今後の機能、考えられるリスクを認識してもらうことは、チーム全体の意識を高めます。Opsチームは何かあってもいいようにいつも準備ができているため、安心していられます。
早い段階でインシデント管理を実装することで、アプリケーションの健全性と問題が発生したときに何をすべきかを誰もが理解できるようになります。誰もが大きな図式を知っており、より迅速にトラブルシューティングを行うことができます。
透明性には統一された指標が必要
チーム全体が、危機の間お互いの責任を認識しているほど、彼らはより効果的に動き、より速く正常に戻すことができます。
複数のソースからデータを収集し、相関させ、分析することにより、DevとOpsは継続的な洞察を得ることができます。しかし、そのデータは実用的になった場合にのみ価値があります。インシデント管理ソリューションを使用すると、適切な人に問題の全体像を提供し、最終的にはアプリを壊してしまう可能性のある問題をゼロにすることさえできます。
最後に、インシデント管理ツールが問題が起きている時にリアルタイム通知を提供することで、実際に役立つことを確認してください。さまざまな重大度の問題の経路を決めるプロセスを定義することは非常に重要です。データを捨てようとは思いませんが、手元の問題を解決することに貢献しない無意味なメトリックを通知されることは望みません。
DevOpsへのトランスフォーメーションに成功するためには、継続的インテグレーションとインシデント管理が不可欠です。チーム全体にとってたのもしいリリーフとなり、ダウンタイムに対するより迅速な対応が可能になります。インシデント管理によってDevOpsエンジンは故障することなくスムーズに回転するようになります。
DevOps
余計なアラートを抑制しよう！
インシデント管理におけるノイズ回避
抑制（ 注：Suppression ）。シソーラスによると、この単語は削除、排除、消滅などの用語と同義語です。
しかし、インシデント管理の文脈の中では、抑制とは全く異なることを意味します。永遠にデータを削除することではありません。そうではなく、騒音を軽減して管理者が適切なタイミングで適切なアラートに注目できるようにする方法として機能します。
ここでは、抑制がインシデント管理を合理化する様子をご紹介します。
抑制が重要な理由
インシデント管理に抑制が役立つのはなぜでしょう。簡単に言えば、現代のインフラストラクチャは大量のアラートを生成するので、管理者は全てのアラートをレビューできないのです。試してみればすぐにアラート疲れすることに気づきます。つまり、アラートの量に圧倒されて燃え尽きてしまい、本当に重要なアラートを無視するようになってしまいます。また、アラートに注意を払うのをやめるとインシデント管理プロセス全体が壊れてしまいます。
アラート抑制はこの問題を回避する方法です。管理者は、特定の種類のアラートを抑制することで、対処可能で優先度の高いアラートを重視するようにできます。また、ダッシュボードに表示されるアラートの総数を減らすことができるので、アラート疲れを防ぐのに役立ちます。
例えば、ワークステーション群が更新プログラムのインストール後に1週間に1回再起動するようになってしまったケースを考えてみましょう。ワークステーションが再起動後にオフラインになってまた復帰するまでの間に一連のアラートが生成されます。管理者が見ているインシデントダッシュボードにこれらを追加すると、ダッシュボードが役に立たなくなってしまうでしょう。それらのアラートは特にアクションを必要としないルーチンの手続き型イベントが起きたことを示すものだからです。この役に立たないノイズを管理者のダッシュボードに表示させないようにするには、管理者はインシデント管理ソフトウェアの設定で、ワークステーションの再起動に関連するアラートを抑制することができます。
抑制はゼロか100かという問題ではありません
アラート抑制を理解するうえで大事なのは、アラートを抑制するというのはゼロか100かを選ぶのではないということです。つまり、管理者のオプションは、特定のタイプのすべてのアラートを有効にするか、またはすべてのアラートを永久に抑制するか、ということではありません。
そうではなく、抑制にはもっと繊細なアプローチをとることができます。特定の期間内に繰り返し発生しない限り、特定の種類のアラートが抑制されるように設定できます。あるアラートを特定の時間帯に発生した場合だけ報告するように設定したり、他の時間帯には抑制するように設定したりすることもできます。同様に、管理者は特定の種類のデバイスで発生した特定の種類のアラートは抑制したいが、他の種類のアラートは抑制したくないという場合があります。
こういう柔軟性はアラートの有効性を最大限に引き出すために重要です。幅広く雑な抑制ポリシーを適用するのではなく適切に調整すれば、インシデント管理システムに不要なノイズを出さず、重要なイベントを最大限に可視化することができます。
上記の例では、繊細な抑制が役に立ちます。私が指摘したように、管理者は普通、ワークステーションがソフトウェア更新後、深夜に再起動したときに出すアラートは受信したくありません。しかし、インシデント管理ソフトウェアが同じ期間に複数回再起動するワークステーションを検出した場合は、管理者が知りたい問題（ソフトウェアの欠陥など）が発生している可能性があります。この状況では、再起動が反復される場合だけセンターのダッシュボードに表示されるインシデントが生成されるように設定すれば、インシデント管理の効果を最適化できます。
抑制はデータの損失を意味しません
インシデント管理の文脈でいう抑制は、抑制されたアラートが永遠に消えることを意味するものではないことを強調しておきます。逆に、抑制されたアラートはまだ発生しますし、それらに関連するデータは保存する必要があります。抑制されたアラートとされていないアラートとの唯一の違いは、前者はインシデント管理システムの優先順位の高いダッシュボードには送信されないということです。
これは管理者が必要に応じて抑制されたアラートを見てインシデントを把握できることを意味します。これにより、アラートのしきい値を調整するのに役立ちます。さらに、抑制されたアラートを過去のインシデント管理データとして見ることで、インフラストラクチャの効率性やシステムの健全性のトレンドに関する多くの貴重な情報を明らかにできます。
抑制されたアラートを活用することで管理者がインシデントの特定と対応に役立てることもできますし、優先順位の高いインシデントを解決するために活用したいダッシュボードを、対処不可能な情報で混乱させることもなくなります。さらに、インフラストラクチャを完全に把握できるように、アラートが適切な状況下でのみ抑制されるようにして、常に報告が続けられるよう微調整することもできます。
インシデント＆アラート
マイクロサービス時代のモニタリング
迅速性の高まりにつれて増大する複雑さの管理
DockerとDevOps革命のおかげで、マイクロサービスはアプリケーションを構築して展開する新しい方法として浮上しました。マイクロサービスのトレンドを受け入れる理由はたくさんあります。
マイクロサービスを採用する場合は、マイクロサービスアーキテクチャには多くの部品があることも理解しておく必要があります。 インシデント管理に関して言えば、マイクロサービスとモノリシックアーキテクチャの間に重要な違いがあります。 部品が多いほど、アプリケーションとインフラストラクチャの健全性と継続性を維持するために、監視と管理がより複雑になります。
マイクロサービスがいかにIT監視の課題を増やすか、そして増大する複雑さを組織がどのように処理すべきかを探ってみましょう。
マイクロサービスの定義
マイクロサービスは、他のマイクロサービスと組み合わせて完全なアプリケーションを形成する小さなアプリケーションコンポーネントです。 Dockerを使用してアプリケーションをデプロイする場合は、複数のコンテナで構成されている可能性があります。各コンテナは個別のマイクロサービスを実行します。
DevOpsはソフトウェアの継続的デリバリーを奨励しているため、マイクロサービスはこの数年間で普及してきました。管理者はアプリケーション内の特定のマイクロサービスの問題を追跡できるため、マイクロサービスとして配備されたアプリケーションは管理しやすくなります。アプリケーションの特定のコンポーネントへの更新では、アプリ全体ではなくそのマイクロサービスだけを再起動できるため更新するのも簡単です。以上のような理由から、マイクロサービスは継続的デリバリーを容易にします。
2013年にDockerが導入されたことで、マイクロサービスへの関心が高まりました。Dockerコンテナは、マイクロサービスのための便利なビルディングブロックを提供し、モノリシックアーキテクチャに従って設計されたレガシーアプリケーションをマイクロサービスモデルに移植しようとする際に容易な移行パスを提供します。
複雑さ：マイクロサービスのトレードオフ
マイクロサービスを採用している組織は、インフラに追加する複雑さを考慮する必要があります。モノリシックアプリケーションがマイクロサービスアプリケーションに変換されると、管理者が監視すべきパーツが増大します。
たとえば、フロントエンドとデータベースがそのアプリケーション専用の仮想サーバ上で単一のアプリケーションとして実行される、モノリシックなWebアプリケーションを考えてみましょう。このアプリケーションの監視は比較的簡単です。その一部がダウンすると、アプリ全体がダウンします。監視するホストは1つだけであり、対処するアラートも1つだけです。このようなアプリは、異なるポート間の接続やサーバとデータベースのプロセスを監視することで事足ります。
ここで、コンテナのセットとしてデプロイされた同じアプリを考えてみましょう。単一の仮想サーバでアプリケーションを単純なプロセスとして実行する代わりに、フロントエンドとデータベースのレイヤーを異なるプロセスとして実行しているアプリです。Dockerはたくさんのプロセスを起動します。スケールアウトするようなアプリでは、おそらく何百ものコンテナがそれぞれのプロセスを担当するでしょう。コンテナの数はアプリケーションの要求に応じて絶えず変化します。さらに、アプリケーションの統計を収集するなどのタスクを担当するコンテナも抱えることになります。アプリケーションの可用性とパフォーマンスを保証するには、Dockerデーモン自体はもちろんのこと、これらすべてのコンポーネントを監視する必要があるため複雑です。
念のために言えば、私はマイクロサービスが悪いアイデアであるとは全く考えていません。上記の例では、マイクロサービスバージョンのWebアプリケーションは、モノリシックバージョンよりもはるかに拡張性と機敏性が高くなります。スケールアウトの敏捷性には、監視作業を増やすだけの価値があります。
マイクロサービスを効果的に監視する方法
効果的なマイクロサービス監視戦略には、2つの事実に注意が必要です。
明らかなのは、マイクロサービスでは監視すべきコンポーネントが増えているということです。しかし利用するインシデント管理プラットフォームが多数のアラートを処理したり、トライアルを支援したり、適切な人にルーティングしたりする能力を十分に備えていれば、これはさほど大きな問題ではありません。さらに、マイクロサービスではアラートの量がはるかに多くなるため、インシデント管理プラットフォームではアラートノイズを減らす必要があります。関連するアラートをグループ化したり、必要な対応を関連付ける一方、対応不能なアラートは抑制する必要があります。
もう1つ、やっかいな事実は、マイクロサービスが複雑になると、管理者にとってインシデント管理の役に立つ情報の量も増えることです。これは良いことです。モニターするコンポーネントが増えれば、対処すべきデータが増えますが、その余分なデータを活用して問題を特定することができます。モノリシックアプリに関連するアラートは、単にそのアプリのどこかに何か問題があることだけを伝えるため、問題の内容を正確に把握することはあなたの努力次第です。しかし、マイクロサービスでは、個々のDockerコンテナからのアラートにより、管理者は事件の原因となったアプリ内の正確なマイクロサービスを特定することができます。そして、アプリケーションが依存する他のコンテナを中断することなく、そのコンテナのインシデントを解決できます。
マイクロサービスは、インシデント管理チームにチャレンジとチャンスの両方を提供します。インフラストラクチャはより複雑になりますが、インシデント対応をより効果的かつ容易に行うことができます。マイクロサービスのモニタリングの鍵は、モノリシックなアプリの監視とマイクロサービスで構成されたアプリの監視の違いを理解し、マイクロサービス対応のインシデント管理ソリューションとワークフローを適切に配置することです。
DevOps監視は複数のツールの組み合わせで
監視ツールはDevOps チームの人生を楽にします。正しいDevOps 監視ツールを選択することで、効率的なワークフローとエンドユーザーの幸せを手に入れることができます。
多様なDevOps監視ツール
ほとんどの開発チームのための通常の監視ツールキットには、次のものが含まれます（ただしこれに限定されません）。
インフラ監視ツール アプリケーション・パフォーマンス・モニタリング（APM）ツール ログ解析ツール
各レイヤーに目を通し、あなたのDevOps監視プロセスにどこにフィットするか見てみましょう。
インフラストラクチャとネットワークの監視
これらのツールは、サーバ、ルータ、スイッチなどのインフラストラクチャとネットワーク全体を監視できます。インフラストラクチャ監視ツールは、重要なビジネスプロセスに影響を与える前に、ITインフラストラクチャの問題を特定し解決するのに役立ちます。また、古いシステムで障害が発生する前に、アップグレードの計画を立てるのに役立ちます。インフラストラクチャとネットワークの監視ツールは、メンテナンスの停止がユーザーに与える影響を最小限に抑えます。
インフラストラクチャの健全性を監視することで、インフラストラクチャ上で実行されているアプリケーションの正常性を把握できます。ただし、これらのツールはアプリケーションを完全な一連のサービスとして監視しません。その意味で、今日のクラウドアプリケーションには適していない従来の監視方法を採用しています。
例：Nagios、Zabbix
アプリケーションパフォーマンスの監視
アプリケーション・パフォーマンス・モニタリングツールは、その名前が示すように、アプリケーションのパフォーマンスを監視します。アプリケーションの動作を可視化し、ユーザーに影響を与える問題を検出し、それらの問題を迅速に解決するのに役立ちます。エンドツーエンドのアプリケーションフローを監視し、コードレベルの詳細を含むトレースを提供します。APMツールの診断には深い洞察が含まれており、パフォーマンスの低下や障害の原因となる可能性のある正確なコード行を見つけられます。
APMツールはパフォーマンスの向上、処理速度低下とダウンタイムの防止に役立ちますが、APMだけでは解決できない、さらに深いトラブルシューティングが必要な問題もあります。これらの問題には、ログファイルのインデックス付けと検索が必要です。残念ながら、APMツールはログファイルを分析せず、セキュリティ攻撃を検出できません。この種の分析には、ログ解析ツールが必要です。
例：AppDynamics、New Relic、
ログ解析
ログ解析ツールは、ログファイルを格納しインデックス付けするスケーラブルで信頼性の高い方法を提供します。ファイルをすばやく検索し、ログデータに基づいて詳細な分析を作成し、セキュリティ違反やサイバー攻撃を監視することができます。ただし、エンドツーエンドのアプリケーションパフォーマンス監視は提供されず、コードレベルのトレースを明らかにすることもできません 例：Splunk、Elastic Stack
これらのツールは、エンドツーエンドの監視のためのものではありません。インシデントが発生したときにこれらのツールのいずれか1つだけを使うと、解決の鍵となる部分が欠けることがあります。
監視ツールにはさらにその監視が必要
監視のためにこれらのツールを全て採用したとしても、インシデントが発生したときに混乱を招く可能性があります。これらツール全てからの警告は、重複するデータをたくさん提供します。これにより、あなたはツール間を行き来してあちこち見回することになり、チームだけでなく顧客にも多くの不満を引き起こす原因になります。ツールセット全体からのデータのオーバーロードに直面するので、MTTRは長くなります。インシデント管理での監視を簡素化が必要なのです。
監視ツールを集約する単一のインシデント管理プラットフォームが必要
ITチームやDevOpsチームは、互いに深く統合されたベスト・オブ・ブリード（複数ベンダーの組み合わせ）のツールを使用した監視を長年受け入れてきました。これらの全ての監視ツールを使用すると、矛盾する情報と膨大なアラートが表示されることがあります。その全てを管理し、問題の概要を把握するためのセンターハブが必要です。PagerDutyのようなインシデント管理プラットフォームは、インシデントが発生した際の混乱から秩序を回復するために不可欠です。
インシデント管理ツールは、優先度の低いアラートを抑制し、適切な人に適切なタイミングで優先度の高いアラートを表示することで、ノイズからシグナルを引き出します。インシデント管理ツールは、その他の監視システムと深く統合されているため、あらゆるDevOpsチームが必要とする真のエンドツーエンドの監視が可能です。十分に錬られた通知オプションを使用すると、PagerDutyなどのインシデント管理ソリューションはチームに自分たちへの通知方法を選択させることができます。さらに、これらのプロセスを自動化することで、解決までのの時間を大幅に節約し、全体的なMTTRを削減できます。
全ての監視ツールにはそれぞれ独自の機能が用意されていますが、全体を管理していないと混乱が生じます。1つで全てをカバーできるDevOps監視ツールはありませんが、1カ所から全ての監視ツールを管理して、送られてくるデータをフィルタできるPagerDutyのようなソリューションを使えば、完璧に一歩近づくことができるでしょう。
インシデント管理をスケールさせる方法
インシデント管理は、現代のITOpsチームの成功に最重要です。しかし、ビジネスを成長させるようにインシデント管理をスケールさせることは、成長の痛みを引き起こす可能性があります。監視が必要なデバイス、アプリケーション、システムの規模が拡大するにつれて、ノイズも増え、オンコールスタッフの管理の複雑さも増えます。チームのエンジニアの数が増えるにつれて、効率的で負荷が公平に分散されるような人員配置や、新しい通知方法の実装、時間外の運用計画を立てるのが困難になります。また、ITのハイブリッドモデルとバイモーダルなIT環境を志向する動きは、インシデント管理を複雑にする可能性があります。それにもかかわらず、いくつか実証された技術を試してみると、インシデント管理を計画的で組織的かつ効果的な方法で拡張することができます。
変化するITOps環境に被害を与えない
スケーリングが深刻な問題になる例を参考にまずこの問題の重要性を理解しよう
あなたは会社が新しい事業を買ったのを知りました。そこで、あなたは新たなインシデント管理プロセスを始めることになります。あなたのOpsチームは、すでに担当していることに加えて、新しいIT環境を引き継がなければなりません。まずあなたは、新しいスタックに同じツールと方法を適用することができる完璧なシナリオがないかを考えます。
しかし、現実は完璧ではありません。新しい会社は、以前と違う技術スタックと異なるインシデント管理の監視ツールと方法論を活用するかもしれません。このシナリオは非常に困難ですが、ITチームの成長や、よりアジャイルでバイモーダルなITOps構造の採用など、あらゆる成長シナリオと非常によく似ています。あなたがどんなスケールのシナリオに直面するにせよ、監視、インシデント管理、およびチームの拡大に取り組んでいる組織のためには下記が参考になります。
スケールの主な領域を特定する
新しいハードウェア、ソフトウェア、またはサービスを実装していますか？ あなたの将来のITOps環境には新たな複雑さがありますか？ あなたのエンジニアリングチームは育っていますか？ コードエラーを報告する必要があるアプリケーションを継承しましたか？ いずれの場合でも、ITOpsチームが業務を拡大することを余儀なくされている分野を特定する必要があります。
監視ツール
監視ツールが確実にスタック全体をカバーできるようにすることは、スケーリングの成功に最も重要です。この変更を採用するには、現在のスタックの外に複数の、または全く新しい監視システムを実装する必要があるかもしれません。これらのシステムの目的は、フルスタックの可視性を得ることであり、多くの場合、異種システムや新しいシステムを適切に監視するために、さまざまな監視ツールを実装する必要があります。しかし、組織化されたスケールを本当にサポートするには、このデータすべてを正規化し、重複を排除し、相関を取り、実行可能な洞察を得る方法が必要です。各監視ツールによって生成された全イベントを、単一のハブに集中させる必要があります。このハブからはイベントがトリアージされ、オンコールエンジニアにルーティングされるようにできます。
ノイズ減少
監視を実施するのは、効果的なインシデント解決のためにデータを理解することが目標です。監視ツール全体のルーティング動作を調整し、適切なしきい値を設定することは、新しいツールを実装した後にチームがアラート疲れを経験しないで済むようにするための次の大きなステップです。データを集約し、共通のインシデント管理システム内のページングからの対応不能なアラートを抑制またはフィルタリングすることは、ノイズを削減し、スタック全体のインシデントの可視性を高めるために重要です。
事故管理
包括的なインシデント管理プラットフォームは、すべてのツールのデータを統合し、スケールを拡大しながら成長するのに役立ちます。これは、すべての異種監視アラートを1つの共通システムに統合するだけでなく、リソース管理に関する混乱を防ぎ、エンジニアリングチームの成長をサポートします。さらに、より組織的なコラボレーションだけでなく、よりアカウンタビリティを促進するのに役立ちます。ボーナスとして、インシデント分析を活用して、上司にITOpsチームがどれだけうまく稼働停止を管理し解決するかを示すことができます。
スケールと複雑さは去っていません
ITOpsの世界は急速に進化していますが、1つの点は明らかです。ITチームは、業務拡大に全力を傾けるように指示されています。ITOps環境は、よりハイブリッドでアジャイルなアーキテクチャとフレームワークへと移行しています。ユーザーは、さまざまなデバイス間でデータへの高速で信頼性の高いアクセスを絶えず要求しています。その結果、ITOpsチームはスケーリングの計画を立てる必要があります。ダウンタイムの損害が大きくなるにつれて、インシデント管理が必要になっているのです。
インシデント管理による優れた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を最適化するための強固なフレームワークを構築する上での最初の出発点になることを願っています。
インシデント対応のボトルネックを回避する
インシデント 対応のボトルネック―今お使いのインシデント 対応システムでは少ないかも知れませんが、確かに存在することをご存知でしょう。オンコールのチームやお客様のためにボトルネックは最小限に抑える必要があります。最も重大なボトルネックのいくつか、およびそれらを回避する方法を見てみましょう。
あなたの目標は何ですか?
まず、プロセスのボトルネックを理解する前に、そのプロセスの目標が何かを理解する必要があります。インシデント対応の目標は何でしょうか。
ほとんどのインシデント対応チームにとって目標はおそらく次のようになります。
インシデントの発生を防ぐ**。 インシデントの予防は、問題解決を主な目的とするインシデント管理の手には余る可能性がありますが、予防は計画外の作業を削減するために重要です。 損害を最小限の範囲にとどめる**。実際には、インシデント管理における予防的取り組みの大部分はこの点に焦点に当てられています。インシデントが発生しないようにすることができない場合でも、インシデントが広がらないようにすることができます。 インシデントを迅速に解決する**。全てのインシデントを解決できるわけではなく、全ての修正が根本的な問題を解決するわけではありませんが、迅速なインシデント解決は一番重要です。
各ボトルネックを監視する
上記がインシデント対応の基本的な目標である場合、ボトルネックはそれらの目標を達成することを困難にします。これらの中で最も重要なものは次のとおりです。
優先順位を適切に設定できない
優先順位付けは、インシデント解決とインシデントの影響の封じ込めに利用できる最も重要な手段です。深刻な影響の可能性に基づいて、最も注意が必要なインシデントに焦点を当てることができます。インパクトが比較的少ないインシデントは脇に置いておくこともできますが、それでも多大なチームの時間と注意が取られます。適切な優先順位を設定しなかった場合、重要なインシデントの一部が速やかに処理されない、あるいはまったく処理されないことがあります。
過負荷とアラート疲れ
対応チームがアラートの量に圧倒された場合、どの問題を優先すべきか判断する時間がないため、または真のインシデントをノイズのアラートから見分けることができず、麻痺して全てに対応することができなくなります。これは慢性的なアラート疲れにつながる可能性があります。チームメンバーが無意識にほとんどのアラートを無視する精神状態に陥るため、僅かなインシデントにしか集中できなくなります。
アラートのノイズをフィルタリングするための（典型的には自動化された）システムが絶対必要です。対応不可能なアラートを抑制し、関連するアラートを1つのインシデントにグループ化する必要があります。理想的には、これはルールを介して自動的に行われるべきです。さらに、アラート疲れや報告忘れが致命傷になる可能性があるため、チームメンバー全員にアラートするのではなく、適切なチームやチームメンバーだけにアラートを送るシステムを導入することが重要です。
不十分な準備、訓練、経験
理想的には、全てのインシデント対応チームは、問題を迅速に診断でき、各インシデントを修正するためにどのツールとテクニックを使用すべきかを理解している、高度に熟練した技術者で構成する必要があります。
このような問題を最小限に抑える最良の方法は、インシデント対応者のための正式なトレーニングシステムを用意すること、新しいチームメンバーは可能な限り経験豊富なチームに配属すること、チームに適切なドキュメントを用意することです。一貫性と再現性の高いベストプラクティスを実現するためのドキュメントには、基本的な手順のマニュアルや、索引付きで簡単に検索できる相互参照の効くデータベース（過去のインシデントなど）が含まれている必要があります。
メジャーな新製品のロールアウトに対する不十分な準備
メジャーなアプリケーションのリリースの際―それは全く新しいアプリケーションやサービスかもしれませんがー開発者がいくつかの重大なバグを見逃して大量のアラートが押し寄せる事態に対応チームは備えておくべきでしょうか。結局のところマーフィーの法則はいつでも有効です。それが起こるのは広く使われているプログラムのアップデートや、1つ2つのバグが絡みあったトレースしにくいエラーを発生させる場合です。対応チームが準備できていない場合、時間とリソースの全てが優先順位の高いアラートの暴風に巻き込まれ、関連性のないその他のインシデントを処理するための余裕はほとんどありません。
もちろん、リリース前にA／Bテストやカナリアテストなどでアップデートが適切にテストされていることが理想的です。応答チームが配備作業に加わっていれば、問題がはるかに小さなうちに対処できる機会があります。しかし、限定的な導入から始めるという決定をインシデント対応チームが下すのは不可能であり、十分にテストされていないリリースに対処しなければならない可能性があります。
このような状況では、全ての対応者をオンコール待機にするか、アップデートで起こる全ての問題を処理する特別なチームを指定する必要があります。どのアプローチが最も効果的かは、少なくとも更新の範囲と利用可能な対応チームのリソースによって決まります。しかし、計画はいつでも何度でも必要に応じて変更できますし、計画を立てておけば準備ができていない場合とは大違いになります。
ボトルネックの解消
他にも、時代遅れの障害が発生しやすいインフラや過負荷のインフラから生じるインシデントや、インシデントとは無関係のタスクで対応チームの時間が取られるなど、多くのボトルネックがあります。しかし、私たちが列挙したボトルネックは、インシデント対応チームが時間を消費した理由の多くを占めており、ここで提案した修復アプローチは、それらの大半をなくすのに役立ちます。
災いの後で：過去のインシデント経験から学ぶ方法
インシデント 管理の主な目的は、インフラストラクチャ に影響を与える問題を特定し解決することですが、インシデント管理業務はそこで停止するべきではありません。
お客様のチケットに反応するだけではなく、アラートシステムが生成する豊富なデータを活用すれば、問題を事前に検出しインフラストラクチャをより弾力的に運用するための洞察を得られます。
ここでは、データの収集と分析の方法、情報を扱う際に探すべき点など、過去のインシデント管理データを扱うための戦略の概要を説明します。
データの保存と標準化
過去のインシデント管理データを分析するための第一歩は、情報を収集して解析する標準化された方法を見つけることです。しかしながら、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つのログ記録場所に統合すれば、最も多くの情報を提供しているシステムを特定することができます。システムのパフォーマンスが低下しているかどうか、またはノイズが多すぎるかどうかを確認し、必要に応じてしきい値を調整できます。
これらのヒントに従えば、悲惨な歴史を繰り返すことはありません。
それがインシデント管理がいかに実を結ぶかです。 インシデント対応は治療行為ですが、過去のインシデント管理データを含むフィードバックループを継続的に作成すれば、インシデントの予防も可能になります。
次世代インシデント管理：スクリプト化されたインフラストラクチャ
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/ の抄訳です。
クラウドとオンプレミスのハイブリッド環境のインシデント管理
2018年、サーバインフラストラクチャはハイブリッド化されているでしょう。 インシデント管理ソリューションもハイブリッド環境への対応が必要です。オンプレミスサーバのみを管理する場合、仮想ネットワークやマイクロサービスが混在していない場合は、インシデント管理は簡単です。しかし、そんな時代はもう終わりました。
今日、ほぼすべてのインフラストラクチャは、ある意味でハイブリッドなのです。 オンプレミスのサーバとデバイスは、パブリックまたはプライベートクラウドとシームレスに稼働します。ネットワークは物理層から抽象化されています。ストレージはスケールアウトされ、多くのサーバに分散しています。複数のデータセンターに分散配置されているかもしれません。
この環境で管理者がすべきことは何でしょうか。簡単なのは、ハイブリッド対応のインシデント管理ソリューションを採用することです。では、今日のハイブリッドインフラストラクチャのインシデント管理を最適化するためのヒントをお教えしましょう。
ハイブリッド環境におけるインシデント管理の課題
ハイブリッド環境におけるインシデント管理に特徴的な課題を説明しましょう。
インシデント管理チームは、インフラストラクチャ全体に物理的にアクセスするとは限りません**。インフラストラクチャが複数のデータセンターにまたがる場合や、クラウドを含む場合、管理者がアラートを発呼するデバイスと同じ場所にいない可能性があります。 すべてのインフラストラクチャを完全に制御することはできません**。パブリックまたはプライベートクラウドは、他の誰かのサーバ上にホストされている可能性があります。 物理デバイスは抽象化されています**。その結果、アラートがソフトウェアの問題、ハードウェアの問題、またはその両方によって引き起こされているかどうかを判断するのが難しくなります。たとえば、仮想サーバ上のファイルシステムの問題に関するアラートの原因には、ホスト上のディスクのハードウェア障害、ゲスト上のソフトウェアファイルシステムのエラー、またはその組み合わせなどがありえます。 インフラストラクチャは変化します**。新しいデバイスが追加または削除されたり、ストレージが拡張されたり、コンテナがスピンアップやスイングしたりするなど、絶えずスケーリングされています。
ハイブリッド環境の課題を解決する
ハイブリッドインフラストラクチャインシデント管理戦略を計画する際に考慮すべきいくつかの提案を示しましょう。
原因に応じてアラートをルーティングできるインテリジェントなインシデント管理プラットフォーム（PagerDutyなど）を採用します。そうすれば、あるデータセンターで生成されたアラートは、別の場所のチームではなく、そのデータセンターを管理している管理者に確実に届きます。 柔軟な監視とアラート設定を提供し、既存の環境と容易に統合できるインシデント管理プラットフォームを導入します。これにより、インフラストラクチャのさまざまな部分にさまざまなツールを統合できるようになり、その特定の部分に最も適したツールが決まることになります。パブリッククラウドサーバでは、AWS CloudWatchを使用することができ、Nagiosはオンプレミスサーバを処理できます。SnortまたはOSSECはネットワークイベントを監視できます。PagerDutyを例にとると、既存のハイブリッドインフラストラクチャと統合できる150以上のインテグレーションがすぐに利用できます。 すべてのアラートをセントラルハブに送信します。複数の監視プラットフォームを使用している場合は、アラートをグループまたはクラスタで一緒に表示する必要があります。さもなければ、管理が困難になり、関連する問題の間のリンクを導き出すことが不可能になります。PagerDutyのようなプラットフォームは、ハイブリッド環境全体からさまざまなアラートを受信して正規化する集中ハブを提供しこれを解決します。 インシデント管理ソリューションが拡張できることを確認します。インフラストラクチャのサイズは一定ではないため、アラートの変化する量を受信して格納できるプラットフォームが必要です。 ベンダー依存は推奨できません。特定のオペレーティングシステムやベンダー製品のみをサポートするインシデント管理ソリューションは、ハイブリッドインフラストラクチャでは機能しません。ハイブリッド環境は、通常、さまざまなハードウェアとソフトウェアのコンポーネントで構成され、部品をすばやく交換できるのが利点です。 PagerDutyのようなソリューションは、ベンダー固有の監視ソフトウェアと統合し、柔軟なインシデント管理インターフェイスを使用してアラートを変換できるためハイブリッド環境でも便利に使えます。
以上の課題のいくつかは、まだハイブリッド化していない組織にとって今のところまだ重要ではないように思えるかもしれません。しかし、明確な傾向はハイブリッド環境にに向かっています。 インフラストラクチャを監視する能力に影響を与えることなく、インシデント管理ソリューションを早期に準備すれば、ハイブリッド環境に完全に移行できるようになります。
注）インシデントとアラート
インシデントの定義は、
「システムの運用を通して提供されるサービスの中断、サービス品質の低下、 またはその可能性がある出来事」、つまり、「ディスクの使用率があらかじめ決めたしきい値を上回った」などの、システム利用者には影響がなくても、サービスの品質が落ちる可能性がある出来事もインシデントとなります。
アラートとは監視システムが、そのシステムの監視対象のある定量情報（メトリック）があらかじめ設定されたしきい値と超えた場合に管理者に送る通知を指します。ある1つのアラートまたは複数のアラートの組み合わせが1つのインシデントの予兆または症状として発生します。
オンコールエンジニアのベストフレンド
オフィス に戻って、一晩中サーバ がダウンしていたことを知った経験がありますか。また、その時にアラート通知を受ける方法がなかったのですか。 だとすれば、モバイルインシデント管理が必要です。 ほぼすべての人のポケットにスマートデバイスを持つ現代社会で、インシデントが発生したときにスマートデバイスを活用せずに自分が無力だと思い込むのは残念です。
モバイルインシデント管理の重要性 計画外のインシデントはいつでも襲ってきますが、その時、モバイル端末はインシデント管理の重要なギャップを埋めます。 多くのインシデントは、チームメンバーがオフィスにいないときに発生します。 チームメンバーが眠っているときにも起きます。 インシデントは、こちらの都合を待ってはくれません。
そのため、モバイルインシデント管理が絶対に重要です。 モバイルインシデント管理では、あらゆるデバイスから、外出先でインシデントを解決する方法を提供します。 アラート、統計、要約、タイムライン、ログなどの概要を表示します。 誰がオンコール待機かを知ることができ、オンコールのチームメンバーは、選択したデバイスを介してリアルタイムで通知を受け取ります。 その他にも、チームの割り当て、どこからでもコミュニケーションやコラボレーションを行う機能、他のアプリと簡単に統合できる機能など、便利な機能があります。
モバイルアドバンテージ 一見すると、モバイルインシデント管理は「モバイル用のアプリならありますよ」と言いたがるトレンドに沿っただけのものに見えます。しかしモバイルインシデント管理の利点は無視することはできません。
インシデント管理アプリケーションをスマートフォンまたはタブレットにインストールすることは、デバイスにすべての機能が統合されていることを意味します。 PCと比較して、スマートフォンはより便利な通信手段です。単独でデータを持てますし、電話をかけたり、電子メールを送信したり、テレビ電話をかけたり、緊急サービスに知らせることができます。ラップトップやデスクトップをいつも持ち歩いていなくても、おそらく電話ならいつもお手元に置いてるはずです（またはベッドサイドに）。インスタントメッセージアプリ、作業ファイルなども内蔵しているでしょう。これは、それを4時間いつでも問題を通知するのに理想的なデバイスにします。さらに、インシデント管理アプリケーションはすべての電話連絡先と統合されるため、適切な連絡先情報で適切な人物に自動的に連絡してインシデントを解決しやすくしてくれます。また、アプリのダッシュボードやサマリーに重要なインシデントがあるかどうかを素早く判断して把握することもできます。この方法で、後回しにするインシデントを再割り当てまたはスヌーズすることができます。
インシデント管理アプリケーションを持ち歩けば、問題を見逃すことはありません。あなたがいない間に何が起きるかを心配せずに机を離れることができます。モバイルインシデント管理は、インシデント管理の強力な自動化と、いつでもどこでもあなたに届くフェールセーフを提供します。
DevOpsにとっての利益は？
DevOpsを実践する場合、チームがモバイルインシデント管理アプリケーションを使用することは、多くの利点があります。応答が必要なリアルタイムの問題についての情報を得られることは非常に強力です。常に準備を整え、問題を迅速に解決することができます。これにより、イノベーションとコラボレーションにより多くの時間を費やすことができます。モバイルインシデント管理では、Dev、QA、およびOperationsのすべての人をインシデント管理に確実に同列に関与させていることを確認します。
このコラボレーションは強力なものとなり、インシデントをより効率的に解決するのに役立ちます。チーム全体が常にインシデントを追跡する能力を持っていることで士気が高まります。これにより、多くのプレッシャーが軽減され仕事に集中できます。そして、誰もが開発中のコードについてコールを受けられるようにしておくことは、開発者がより良いコードを生産することを可能にします。これにより、開発プロセスのスピードアップと品質が大幅に向上します。
オンコールエンジニアのベストフレンド オンコールエンジニアは、救急サービスの一次対応チームのようなものです。モバイルインシデント管理は、仕事をずっと簡単にします。リアルタイムにインシデントに適切なアクションをとるためのソリューションを提供します。タイムライン、ログ、対応者の割り当てなど、インシデントを解決するために必要な機能をすべて備えています。モバイルインシデント管理アプリケーションを使用すると、オンコールのエンジニアはインシデントの重要度を迅速に分類して、優先順位や影響を受けるサービス、外部向けの対応を把握し、モバイルデバイスからエスカレート、共同作業、解決、またはスヌーズを直接行うことができます。これにより、誰も時間を無駄にすることがなくなり、オンコールのエンジニアは必要な時に、そして必要なときに対応できる人を募ったり、インシデントを再割り当てすることができます。インシデントがはるかに迅速に解決されるため、不要なエスカレーションが最小限に抑えられます。
PagerDutyのモバイルインシデント管理アプリケーション（iOSまたはAndroid対応）は、集中ダッシュボード、重要な統計情報、インシデントの再割り当て、連絡先の統合、インシデントタイムラインなどのすべての機能を提供します。ユーザーごとのアクセス許可と細かいカスタムアクセス制御は、どのデバイスでも可能です。それはインシデント管理のワークフローをより合理化します。どこにいてもモバイルデバイスから迅速かつ簡単にインシデント管理ができるようにします。インシデント管理プロセスの中では絶対不可欠なものです。
※このコンテンツはwww.pagerduty.com/blog/の抄訳です。
モバイルでのインシデント管理
モバイルでのインシデント管理。 どんなときも。 どこでも。
すべてのデバイスで、卓越したユーザーエクスペリエンスを備えたインシデント管理ライフサイクルを実現します。 PagerDuty Mobileアプリケーションを使用すると、アラートを視覚化し、外出先でアラートを確認、解決、再割り当てすることができます。 モバイルアプリ、メール、SMS、電話などのマルチチャネル通信オプションを使用すると、アラートやインシデントの更新を見逃すことがありません。
“ iOSアプリが本当に好きです。 オフィス外にいる間にすべてのインシデントを認知し、エスカレートし、解決する能力は本当に素晴らしいです。 “
モバイルインシデント管理の詳細をご覧ください
インシデントを作成する
モバイルアプリから直接新しいインシデントを簡単に作成できます。
モバイルアプリ
iOSとAndroidの携帯電話、タブレット、スマートウォッチでインシデントを管理します。
アラートと通知
アラート音をカスタマイズして、無制限のプッシュ通知アラートを受信することができます。また、割り当てられたインシデントについて承認、エスカレート、解決されたことを知ることができます。
インシデントの詳細
インシデントの詳細、インシデント履歴、オンコールスケジュールを表示します。 オープンしているインシデントに対して、認識、解決、再割り当てすることができます。
スケジューリング
自分またはチームのオンコールスケジュールとブックされたオーバーライドを表示します。
インシデントをスヌーズする
すぐに解決する必要のないアラートをスヌーズします。
PagerDutyのインシデント解決プラットフォームは、ノイズを削減し、インシデントをより迅速に解決するのに役立ちます。
サイロを壊す：ベンダー間のデータを関連付ける
DevOpsのへの移行で、一連のサイロからなる ソフトウェアデリバリーチェーンがなぜ悪いのか理解されるようになりました。 サイロは異なるチーム間のコミュニケーションを複雑にし、デリバリー遅延や手戻り、バグにつながります。
インシデント管理においては、あるベンダー製品の管理データと別のベンダー製品の管理データを分けるというサイロがあります。このサイロは、複数ソースからの監視データの収集と分析を困難にするため、インシデント解決を妨げます。
インシデント管理業務を効率的に流していくために、サイロをどのように分析していますか？
サイロを特定する
インシデント管理での作業の最初のステップは、サイロが最初に存在する理由を理解することです。
理由は簡単です。現代のインフラストラクチャは、多様なハードウェアとソフトウェアで構成されています。ほとんどのコンポーネントには特別な監視が必要です。特定のリズムに従って情報を特定の形式で出力し、特定の方法でデータを収集する必要があります。したがって、インフラストラクチャの各部分に関連する監視情報は、インフラストラクチャの他の部分からのデータと容易に比較できないため、サイロの中に入ってしまいます。
基本的な例として、Windowsを実行する10個のベアメタルサーバと、Linuxを実行する10個のベアメタルサーバで構成されるデータセンターを考えてみましょう。このシナリオでは、Windows用とLinux用の異なる監視ツールを必要とします。ホストが落ちていないかどうかなど、各タイプのオペレーティングシステムに関する監視情報の一部は同じですが、他のデータには違いもあります。そのため、各OS専用のツールでデータを収集する必要があります。したがって、Windows、Linuxそれぞれが専用ツールでデータを監視するエコシステムを備えた明確なサイロになります。
これは単なる例です。モニタリングする2種類のベアメタルサーバだけでなく、各種のハイパーバイザ上で実行される仮想サーバ、各種デスクトップOSを実行するワークステーション、いろいろなモバイル機器やモバイルOS、バージョンなど実際の現場ではさらに複雑になります。
サイロを壊す
シームレスで全体的な監視の可視性を得るために、インフラストラクチャ内の各監視コンテキストを分離するサイロをどのように排除するか。このソリューションには2つの部分があります。
ステップ1：データ収集の集中化
最初のステップは、さまざまなタイプの環境から情報を収集し、その情報を中央の場所に転送できるインシデント管理ソリューションを実装することです。 こうすればエンジニアはインフラストラクチャ全体を1点で監視することができます。 インフラストラクチャのさまざまな部分を監視するために個々のサイロを調べる必要はありません。
集中型のデータ収集には、複数のソースからの監視情報を集約するのに十分な機能を持つインシデント管理ソリューションが必要です。 これは簡単な作業ではありません。 幅広い環境とエンドポイントをサポートするためには、さまざまなタイプの監視システムと統合する必要があります。
ステップ2：データを翻訳する
2番目のステップは見落としやすい点です。インシデント管理チームは、多くの監視ツールのデータを集約し一元管理することに加えて、すべてのデータを一貫したフォーマットに変換する必要があります。
すべてのエンジニアがあらゆるソースからのアラートを解釈して対応できることを保証する唯一の方法は、データ変換だけです。データが共通のフォーマットに翻訳されない場合、エンジニアは特定のタイプの監視システムに必要な特別の知識を持たなければならないか、または特定ベンダーのスキーマを知ってそのシステムから発生したデータを理解する必要があります。このように、中央の場所ですべてのデータを利用できるようにするだけでは、複数のシステムを隔てる大きな障壁が依然として存在するため、サイロを分解することはできないでしょう。
たとえば、ZabbixとNagiosで「エイリアス」という用語の使われ方を見てみましょう。以前の監視システムでは、エイリアスは基本的に各種コンフィギュレーションの略語として機能します。対照的に、Nagiosでは、エイリアスはホストの名前です。この違いを理解しないまま、ZabbixシステムとNagiosシステムの両方のデータが集中ダッシュボードに集約されていたら混乱するでしょう。
効果的なインシデント管理のためには、ベンダーやプラットフォーム固有の用語を単一の言葉に置き換えるソリューションが必要です。 PagerDuty Common Event Formatで有効になっているようなイベントの正規化だけで、レスポンダは複数のソースからのデータを簡単かつ正確に解釈できます。
現代のインフラの複雑さは、サイロを避けることを困難にしています。しかしそれは、監視情報がサイロの中になければならないということを意味するものではありません。さまざまなソースからの監視情報を集約し、オンコールチームの誰でも理解できる言語に変換することで、インシデント管理チームはインフラストラクチャ内に存在するサイロを分解することができます。彼らは、シームレスなコミュニケーションと、機敏なインシデント対応が可能になります。
ファーストデータ、ファーストモニタリング
ビッグデータはもう古い。 今日、データを効果的に活用するための鍵は、ファーストデータです。
大量の監視情報の収集と分析を伴う従来のインシデント管理ではもはや十分ではありません。 また、監視データの収集だけでなく それをリアルタイムで実行する「ファーストモニタリング」が必要とされています。
ここでは、ファーストモニタリングが意味することを検証し、インシデント管理チームがこのアプローチを実装して大きなメリットを実現する方法について説明します。
ファーストデータの定義
ファーストモニタリングの概念を理解するためには、ビッグデータの世界で最も新しいイノベーションの1つであるファーストデータを理解する必要があります。
非常に簡単に言えば、ファーストデータは高速にビッグデータを処理することです。 ビッグデータとは、伝統的に大量の情報を保存して後で分析することを意味しますが、ファーストデータとは、大量の情報をできるだけ速く、理想的にはリアルタイムでデータ分析を実行することを意味します。 その目標は、できるだけ実用的で関連性のあるデータを分析することです。
ソースから分析プラットフォームにデータをストリームするのは、ファーストデータを活用する上で重要な部分です。 これが、Apache Sparkのようなビッグデータツールが近年普及している理由です。 ストリームデータの収集とインメモリ処理をサポートすることにより、Sparkは非ストリーミングやハードディスクによるデータ解析プラットフォームよりもはるかに高速で大量の情報を取り込み、分析できます。
ファーストデータとインシデント管理
インシデント管理はデータ分析とは異なる分野ですが、インシデント管理者はファーストデータへの移行トレンドから多くのことを学ぶことができます。 インフラストラクチャの監視とインシデント管理の世界では、大量の監視とアラートのデータをリアルタイムで分析してレスポンスを向上させることが、これまで以上に重要になっています。
伝統的なインシデント管理から迅速なインシデント管理まで
ファーストデータとファーストモニタリングのつながりは偶然ではありません。多くの点で、インシデント管理の進化はデータ分析の進化を反映しています。
約10年前までは、インフラストラクチャのデータは比較的小さくて済んでいました。ほとんどの組織では、それほど多くのデータを生成しなかったため、ペタバイトクラスのデータを分析する必要はありませんでした。同様に多くの組織は、大規模で多様なインフラストラクチャをサポートできる監視ソリューションを必要としませんでした。代わりに、サーバやワークステーションからなる比較的小さくて複雑ではないネットワークをトラックするためのベーシックな監視システムで済んでいました。
そして、2000年代半ばには、データとインフラストラクチャの両方が大幅に拡大し始めました。すべてをデジタル化することで、組織は大量の情報収集を開始し、ビッグデータを生み出しました。その一方で、モバイルデバイスの普及、仮想化の台頭、さらにますます強くなるコンピューティングパワーの必要性は、インフラストラクチャをはるかに大きく複雑にしました。この新しい状況には大規模なモニタリングが必要でした。
そして、ここ数年の間に、もうひとつの変化が起こっています。情報が絶えず変化している時代には、ほんの数時間の分析の遅れでもデータの価値が損なわれます。同様に、最新ではない情報を監視することに基づいてインシデント管理を実行することにより、管理者はインシデントを迅速に処理して対応することができなくなります。
したがって、ファーストデータとファーストモニタリングには異なるツールセットが必要な場合がありますが、両方の動機と原則は同じです。インシデント管理チームがインフラストラクチャとアプリケーションをできるだけスムーズに稼動させようとファーストモニタリングに専念するのは、データアナリストの仕事とよく似ています。
ファーストモニタリングの促進
情報の収集と迅速な対応は簡単に聞こえるかもしれませんが、実際にはどのようにしてファーストモニタリングを行うことができるでしょうか。主なガイドラインは次のとおりです。
データ収集を一元化する:** 迅速に情報を監視するためには、すべての監視データを中央のインターフェイスに転送する必要があります。これにより、異なるダッシュボードや監視システムを切り替える必要がなくなり、時間と精神的なエネルギーを無駄にするだけでなく、根本原因を理解することが非常に困難になります。 利用可能なすべての情報を収集する:** 伝統的なインシデント管理は、マシンのデータとアラートの収集だけに集中する傾向があります。その情報は、迅速な監視を行うために必要なものの一部を提供しますが、可能な限り迅速にインシデントに対応するためには、可視性と洞察力を可能な限り広げるべきです。たとえば、チケットやサポートコールから人間が生成したデータを収集することを無視してはいけません。これは、PagerDutyのカスタムイベントトランスフォーマーなどの機能を活用して、従来はインシデント管理ワークフローの一部ではないソーシャルメディアチャネルなどのソースからデータを収集することも意味します。 ノイズを最小限に抑える:** 大量のアラートを受け取っても、アクションを必要とするのはそのうちの一部だけです。 したがって、警告の数が最小限になるようにノイズをカットし、対応不要なものを抑止することは絶対に重要です。重複するアラートは自動的に排除されるべきであり、解決が必要な単一の問題に関連する症状をグループ化するのは簡単なはずです。これにより、注意を必要とするアラートの瞬時識別が容易になり、リアルタイムで適切な応答ワークフローが開始されます。 データを解釈しやすくする:** 大量の監視データを収集し、中央の場所に格納することで、そのデータをすぐに価値に変えることができます。 しかし、ダッシュボード上の情報を分析する負荷を軽減するには、さまざまなソースからのデータを一貫した形式に正規化する必要があります。 そうすれば、さまざまなベンダーのすべてのスキーマを暗記する必要はありません。 これを実現するには、さまざまな形で情報を取得し、フィールドを普遍的なものに標準化し、即座に実行可能でわかりやすい洞察を与えるインシデント管理ソリューションが必要です。
これらのプラクティスはすべて、重大な事故の際にインシデント管理者が必要とする手動分析の量を最小限に抑えます。 また、アラート収集とアクションの間隔を最小限に抑え、インシデント管理スタッフがインシデントに素早く反応し、ファーストモニタリングをリアルタイムレスポンスに変えて正常稼働時間を向上させます。
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のような通知を集中管理するソリューションを実装することで、既に導入済みの監視ツールからさらに多くの価値を引き出せます。
