インシデント管理データで技術的負債を測る
技術的負債(technical debt)が借金のようなものだったら、手作業でチェックインしない限り、それを追跡するのは難しいでしょう。 多くの人にとっては自分の当座預金口座に資金がなくなったことを知る唯一の方法は、口座の残高を確認することです。さらに悪くなると、小切手が返されたり、デビットカードが拒否されます。
しかし、技術的負債の測定はもっと自動化できます。 これは、お客様の銀行口座とは違って、ITインフラストラクチャの場合はそれを専用のツールで継続的に監視でき、重要なヘルスメトリックについて通知を受けることができるからです。 次に、監視データを使い技術的負債についての情報を得ることができます。 つまり、データセンターで問題が発生したときに手動で監査する必要はありません。 問題があることを知るのに、サーバーがダウンするまで待つ必要はありません。 インシデント管理ツールは、その情報を提供します。 エクステンションを使えば手作業で面倒なことを測定することなく、技術的負債を取り込む方法も提供しています。
インシデント管理は、技術的負債を追跡して修正するのに役立ちます。追加の投資は必要ありません。
技術的負債の定義
まず、技術的負債の意味を説明しましょう。 技術的負債とは、長期的には非効率性やその他の問題を引き起こすような、ソフトウェアコードやアーキテクチャの不完全性を指します。 たとえ欠陥自体が小さいとしても、その効果が継続的に繰り返されるため、時間の経過とともに多くの利子が生じることがあります。
例えば、モジュラーアプローチを採用しておらず、同じ機能の複数のバージョンをコードに含むようなプログラムは、より優れたプログラムよりも実行に数ミリ秒余計にかかることがあります。 一度だけそれを実行するなら、大きな問題にはなりません。 しかし、それがサーバーの側で1日に数千回実行されるWebアプリケーションであれば、パフォーマンスが低下したり、CPU時間が浪費されたりするという負債があっという間に積み上がります。
技術的負債には多くの潜在的な原因(訳注:クリックすると英語版のWikiに飛びます)があります。 場合によっては、例えば何かを迅速に導入しなければならず、ベストプラクティスに従う時間がない場合は、負債がコストに見合う価値があると判断(少なくともその時点で)して、技術的負債を意図的に負うことがあります。管理者の中で最も優れた人でも将来の技術的負債を避けることは難しいです。 将来を見通せない限りは(例えば、あなたがアップグレードする余裕がないために今日も使用している10年前のスイッチが、最新のファイアウォールツールではうまく機能しないということは過去の時点では分からなかったはずです)。 その場合、技術的負債は、不完全な世界での生活で起きることまったく同じ経緯をたどります。
技術的負債を追跡する
技術的負債には多くの源がありますが、それをインシデント管理を使用して測定するというアプローチは、問題の原因を問わず問題の追跡を容易にします。繰り返しますが、時間のかかる手動のシステム監査で非効率性を検索する代わりに、インシデント管理データを技術的な負債の程度を評価し、それを評価するためのプロキシとして活用できます。
やり方を理解するために、PagerDutyが追跡するさまざまな種類のインシデント管理データの例と、それらのデータが技術的負債について明らかにできることをいくつか見てみましょう。
まず、ツールが生成するアラートの生の数を取得します。これは非常に基本的な指標であり、さまざまな要因によって影響を受ける可能性があります。しかし、インシデント管理の報告システムが適切に構成されており、インフラストラクチャに大きな変更を加えなくてよいと仮定すると、技術的負債の規模とツールが報告するインシデントの数との間に相関が見られる可能性があります。負債が増えるとパフォーマンスが低下し、応答時間やリソースレベルが特定のしきい値に達するとアラートがトリガーされるためです。したがってアラートの発生率が月ごとに減っていれば、コードがより効率的になったので技術的負債が減っている可能性があります。
平均解決時間(MTTR)は、技術的負債を見るためのインシデント管理の指標です。MTTRが悪い一般的な原因の1つは、コードがあまりにも複雑すぎることです。例えば、上の例を再利用するために、急いで書かれたコードには冗長な機能が含まれているため、管理者にはすぐに理解するのが難しいでしょう。これは、事件に対応するためにコードを読み込んで変更する必要がある場合に、解決時間が長くなることを意味します。
技術的負債の源を見つける
インシデント管理データは、技術的な負債に関する一般的な傾向を追跡するのに役立つだけでなく、問題の原因をゼロにするのにも便利です。
たとえば、特定のプログラムに関連するインシデントのMTTRが平均MTTRよりも高い場合、問題のプログラムが技術的な負債を生成している可能性があります。同様に、あるタイプのオペレーティングシステムを実行しているサーバーが不均衡なアラート数の大部分を占めている場合、おそらくコードまたは構成上の欠陥があります。それはあなたが対処できる技術的な負債です。
インシデント管理データを使って技術的負債を特定し、対処するのはとてもクールで、ほとんど追加作業を必要としません。あなたは既にPagerDutyのような操作と報告を集中化するハブ(うまく設定すればですが)を備えた監視システムを備えています。これらのリソースを活用して技術的負債を見つけて修正するには、追加のツールや投資を必要としません。既存のソフトウェアを使用して、コードや操作をより効率的にすることができます。
インシデント&アラート
余計なアラートを抑制しよう!
インシデント管理におけるノイズ回避
抑制( 注:Suppression )。シソーラスによると、この単語は削除、排除、消滅などの用語と同義語です。
しかし、インシデント管理の文脈の中では、抑制とは全く異なることを意味します。永遠にデータを削除することではありません。そうではなく、騒音を軽減して管理者が適切なタイミングで適切なアラートに注目できるようにする方法として機能します。
ここでは、抑制がインシデント管理を合理化する様子をご紹介します。
抑制が重要な理由
インシデント管理に抑制が役立つのはなぜでしょう。簡単に言えば、現代のインフラストラクチャは大量のアラートを生成するので、管理者は全てのアラートをレビューできないのです。試してみればすぐにアラート疲れすることに気づきます。つまり、アラートの量に圧倒されて燃え尽きてしまい、本当に重要なアラートを無視するようになってしまいます。また、アラートに注意を払うのをやめるとインシデント管理プロセス全体が壊れてしまいます。
アラート抑制はこの問題を回避する方法です。管理者は、特定の種類のアラートを抑制することで、対処可能で優先度の高いアラートを重視するようにできます。また、ダッシュボードに表示されるアラートの総数を減らすことができるので、アラート疲れを防ぐのに役立ちます。
例えば、ワークステーション群が更新プログラムのインストール後に1週間に1回再起動するようになってしまったケースを考えてみましょう。ワークステーションが再起動後にオフラインになってまた復帰するまでの間に一連のアラートが生成されます。管理者が見ているインシデントダッシュボードにこれらを追加すると、ダッシュボードが役に立たなくなってしまうでしょう。それらのアラートは特にアクションを必要としないルーチンの手続き型イベントが起きたことを示すものだからです。この役に立たないノイズを管理者のダッシュボードに表示させないようにするには、管理者はインシデント管理ソフトウェアの設定で、ワークステーションの再起動に関連するアラートを抑制することができます。
抑制はゼロか100かという問題ではありません
アラート抑制を理解するうえで大事なのは、アラートを抑制するというのはゼロか100かを選ぶのではないということです。つまり、管理者のオプションは、特定のタイプのすべてのアラートを有効にするか、またはすべてのアラートを永久に抑制するか、ということではありません。
そうではなく、抑制にはもっと繊細なアプローチをとることができます。特定の期間内に繰り返し発生しない限り、特定の種類のアラートが抑制されるように設定できます。あるアラートを特定の時間帯に発生した場合だけ報告するように設定したり、他の時間帯には抑制するように設定したりすることもできます。同様に、管理者は特定の種類のデバイスで発生した特定の種類のアラートは抑制したいが、他の種類のアラートは抑制したくないという場合があります。
こういう柔軟性はアラートの有効性を最大限に引き出すために重要です。幅広く雑な抑制ポリシーを適用するのではなく適切に調整すれば、インシデント管理システムに不要なノイズを出さず、重要なイベントを最大限に可視化することができます。
上記の例では、繊細な抑制が役に立ちます。私が指摘したように、管理者は普通、ワークステーションがソフトウェア更新後、深夜に再起動したときに出すアラートは受信したくありません。しかし、インシデント管理ソフトウェアが同じ期間に複数回再起動するワークステーションを検出した場合は、管理者が知りたい問題(ソフトウェアの欠陥など)が発生している可能性があります。この状況では、再起動が反復される場合だけセンターのダッシュボードに表示されるインシデントが生成されるように設定すれば、インシデント管理の効果を最適化できます。
抑制はデータの損失を意味しません
インシデント管理の文脈でいう抑制は、抑制されたアラートが永遠に消えることを意味するものではないことを強調しておきます。逆に、抑制されたアラートはまだ発生しますし、それらに関連するデータは保存する必要があります。抑制されたアラートとされていないアラートとの唯一の違いは、前者はインシデント管理システムの優先順位の高いダッシュボードには送信されないということです。
これは管理者が必要に応じて抑制されたアラートを見てインシデントを把握できることを意味します。これにより、アラートのしきい値を調整するのに役立ちます。さらに、抑制されたアラートを過去のインシデント管理データとして見ることで、インフラストラクチャの効率性やシステムの健全性のトレンドに関する多くの貴重な情報を明らかにできます。
抑制されたアラートを活用することで管理者がインシデントの特定と対応に役立てることもできますし、優先順位の高いインシデントを解決するために活用したいダッシュボードを、対処不可能な情報で混乱させることもなくなります。さらに、インフラストラクチャを完全に把握できるように、アラートが適切な状況下でのみ抑制されるようにして、常に報告が続けられるよう微調整することもできます。
インシデント&アラート
インシデント管理のメトリックでタブを常時オンにする
およそ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が起きた場合でも。
インシデント&アラート
インシデント管理が全従業員のやる気をアップ!
失敗への恐れは開発チーム や運用チーム のメンバーにとって大きな壁となります。この恐怖は耐えがたいもので、社内の士気を大幅に下げ、従業員の生産性と進歩も傷つける可能性があります。
適切なインシデント管理とモニタリングを実施するだけで、アラートを管理して分析機能を提供する以上の効果が得られます。つまり開発の失敗を軽減し、アプリの作り方や投入方法を変えられるようにすることもできるのです。効果的なインシデント管理ソリューションを導入して、開発チームの士気を高め、最高の仕事ができるようにするいくつかの方法を見てみましょう。
インシデント対応中のストレスレベルを下げます
ストレスの軽減は正しいデータを得ることから始まります。正しいデータを持っていない場合は、どこを見て解決すべきかが分かりません。インシデント管理では、適切なコンテキストで全ての適切なアラートを集中管理し、関連する監視ツールのデータを浮かび上がらせることでさらに深く分析を掘り下げることができます。これはインシデントのトラブルシューティング時にチームがよりうまく動き、問題をより速く解決するのに役立ちます。全てのツールのデータをインシデント管理ソリューションに統合することで、チームの誰が何を担当しているかを全員が把握できます。さらに、問題を素早く修復するために必要なデータ(ランブック、グラフなど)も備えています。より速い解決は常にチームをよりハッピーにします。
( 注:ランブックは、運用時に実施する一連の操作について、手順を明確に示した操作指示書のこと)
新機能でインシデントの発生が予測可能になります
インシデント管理プロセスがうまく機能している場合、何が原因で繰り返しダウンタイムが発生するのか、またどのインフラストラクチャやアプリケーションが障害の影響を受けやすいのかが分かります。これにより、新しい機能を追加する際の信頼性が向上します。QAチームは、例えば、注意を必要とするアプリの特定のエリアをチェックするテストを書くことができます。また、経験から問題の原因が分かるため、新しい機能を拒否することさえできます。チームが新しい機能のフィードバックを提供するには、システムの機能と定期的に起こる問題についての深い理解が必要です。このような理解はインシデント管理プラットフォームを使うことでしか得られません。この予測可能性は、チームが「システムを信頼する」ことを助け、あらゆるステップで次に何を期待できるかが分かるようになります。この心の安らぎは従業員の士気と自信を高めます。
全チームが優れたユーザーエクスペリエンスを 提供できるようにします
伝統的に開発チームは、アプリケーションのコードを書きあげて、「壁の向こうの運用チームに投げ込めば」、自分たちの仕事は終わるものと思っていました。同様に、運用チームは、提出されたコードの品質を保証することは自分たちの仕事ではなく、開発から来るものをデプロイすればよいと思っていました。インシデント管理が機能すれば、開発チームと運用チームが統一されたプラットフォームで連携して、チーム間で可視性と一貫性のある単一の真実に向き合えるようになります。彼らは、どれがコードに起因する問題か、そしてどれがインフラストラクチャに起因する問題かを認識できます。
つまり稼働時間は、いくつのサーバが稼働しているか、アプリケーションのどれくらいが正常に稼働しているかによって決まるのではなく、エンドユーザーの経験によって評価されているのだということです。稼働時間に関するこの現実的な見方は、チームの目標とプロセスを、ユーザーの期待を超えるアプリケーションを提供するというより広いビジネス目標へと向かわせます。幸せな顧客がチームを幸せにするのです。チームの仕事のおかげでエンドユーザーが喜んでいることを見せる以上に、従業員の士気を高める良い方法がありますか?
パイプライン全体を加速します
ゲームを変えるようなアプリケーションを構築したい場合は、スピードが不可欠です。インシデント管理は、インシデントが発生したときに、開発チームと運用チーム(ヘルプデスク、サポート、ビジネス関係者など)間の明確なコミュニケーションを可能にします。コミュニケーションのボトルネックが解消されば、チームメンバーは繰り返し起きる問題をより短い時間で解決できるようになり、顧客の幸せを保つためのアプリケーションの開発にもっと多くの時間をかけられるようになります。アプリの開発に使える時間が増えることは、品質向上と市場投入までの時間短縮をもたらします。市場への投入がより迅速になり、チームが1日あたりに出来ることが増えれば、彼らは自分たちの能力が上がったと感じ、より深く取り組むようになり、自分の仕事に情熱を感じるようになります。
オーナー感覚を作り出します
インシデント管理は、インシデント対応のさ中にチームメンバーがより責任を持ち、インシデント対応の手順を確立して、より上位の人たちに頼ることなく重要な意思決定を行えるようにします。決定する能力を持つことは簡単なように思えるかもしれませんが、組織のプロセスの中でチームメンバーがより強い影響力と自信を持つようになるまでは、長い道のりがあります。上位のチームメンバーからの許可を待たないようにすれば、お役所仕事を減らせます。チームのメンバーは、顧客の体験を24時間確実にサポートするために、オンコールを担う責任を全うしています。あらゆるレベルのチームメンバーが意思決定に関与できるようにすると、無茶苦茶なカオスや冗長な作業に費やす時間を短縮し、貴重な時間を無駄にせず、実際の開発に多くの時間を割けるようになります。
効果的なインシデント管理ソリューションは、失敗への恐れを減らし、予期せぬ事態をチームが自信を持って管理できるようにし、結果として従業員の士気を向上させます。チームメンバーが獲得できた信頼感は、パイプライン全体で革新と標準化を推し進め、従業員の士気、生産性、成功を大幅に向上させます。
インシデント&アラート
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アルゴリズムは、これをさらに効率的に実行するように改善されているため、少ないトレーニングデータでより早く作業を開始できます。 新しいアラートグループ化プレビューにより、サービスのオーナーはインテリジェントアラートグループ化をアクティブにする前に、潜在的なノイズ低減とグループ化動作を理解することができます。
インシデント&アラート
クリティカルなアプリとインフラを継続稼動させる
「インシデントのライフサイクル管理? ある事件から次の事件まで生き伸びさせることができれば、 良い一日。悪い日は何もかもパニックさ」
残念ながら、これは非常に多くのソフトウェアや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年ウォード・カニンガムが、技術的な複雑さと債務の比較を経験報告で初めて行った。(ウィキペディア)
インシデント&アラート
中小企業のスマートアクティベーションと効果的なデベロップオフ
あなたは解決不可能なチケットを受け取ったことがありますか?Stack Overflowを隅から隅までじっくり読み、時には机に顔を打ち付けながらGoogleで何時間も過ごす。 4時間が過ぎたあたりから問題を解決することはプライドの問題になってきます。生産性は最低! こんな時こそ、あなたの正気を保つために効果的なインシデント管理プロセスが必要です。
誤解しないでください。他の誰も巻き込まずに解決したいというお気持ちは分かります。うぬぼれだったり羞恥心だったり、はたまた純粋に誰にも迷惑をかけたくなかったり、私もいつもそんな感じですから。 私の場合は問題解決偏愛症のようなものですが、こと自分のプロジェクトの健全さとなると、規定のプロセスに従った方が皆ハッピーになれるようです。
優先順位をつける
いくつかの問題は本物であり、あるものはそうではありません。 すべての問題がミッションクリティカルなわけではないので、チケットがあなたに回ってきたとき、最初のステップはそれがスタックのどこにあるかを決定することです。 あなたとチームメンバーが管理している他のバグやもろもろの要素の中にその場所を見つける必要があります。 詳細なインパクトレポートを作成し、関連するプロジェクトマネージャーたちに相談して決定を導きます。
再現
再現可能なバグは修正可能なバグです。 優先度の高い問題がキューの一番上に達すると、次のステップはそれを再現するステップをコンパイルすることです。 ユーザーが誤ってクラッシュを引き起こしていますか? たぶんそれはメモリまたはストレージの問題です。 重要なことは、あなたがやろうとしているのは、どうすれば問題を再現できるのかを理解することで、解決法ではないということです。 いったんそれを再現することができれば(または容易に再現できないことを知ると)、修正することができます。
エスカレーション
問題を再現できるようになると、次のステップは適切な専門家を特定することです(ヒント:それはあなたかもしれません)。 問題の性質に応じて、誰の肩を叩くのかを知るのは難しいかもしれませんが、実際にその特定の機能について最後に作業した人に尋ねるのがよいでしょう。 誰に問題をエスカレーションするかにかかわらず、これまでに学習したすべての詳細なレポートを必ず含めてください。 感謝してもらえますよ。
調査
さて、これで問題は少しは見えてきて、あなたの作業リストに入ることになりました。 次のステップは、問題を調査することです。 これは、問題を再現し、ログを収集し、その分野の専門家に質問し、起こり得る問題を特定し、ソリューションをテストします。 何が起こっているのか、なぜ起こっているのかを正確に知るまで繰り返します。
回復
ここまできたら、問題の内容、再現方法、原因を正確に把握していることでしょう。 根本的な原因を特定し、テスト済みで実用的な修正を行っています。 次のステップは修正プログラムを導入することであることは明らかですが、ここで停止することはできません。 問題が解決してすべてが安定したら、問題が修正されたことをすべての関係者に通知する必要があります。 また、ソリューションの詳細を関連する専門家に伝え、必要に応じて、何が起こったのか、どのように解決されたのかを誰もが理解できるように解析しておくことも重要です。
効果的なインシデント管理は、確立されたプロセスと適切なコミュニケーション次第です。 実際の手順はプロジェクトごとに変わる可能性がありますが、問題を最も効果的に軽減するチームは大きなコミュニケーションをとり、必要となる前に計画を立てるものなのです。
インシデント管理による優れた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を最適化するための強固なフレームワークを構築する上での最初の出発点になることを願っています。
インシデント管理をスケールさせる方法
インシデント管理は、現代のITOpsチームの成功に最重要です。しかし、ビジネスを成長させるようにインシデント管理をスケールさせることは、成長の痛みを引き起こす可能性があります。監視が必要なデバイス、アプリケーション、システムの規模が拡大するにつれて、ノイズも増え、オンコールスタッフの管理の複雑さも増えます。チームのエンジニアの数が増えるにつれて、効率的で負荷が公平に分散されるような人員配置や、新しい通知方法の実装、時間外の運用計画を立てるのが困難になります。また、ITのハイブリッドモデルとバイモーダルなIT環境を志向する動きは、インシデント管理を複雑にする可能性があります。それにもかかわらず、いくつか実証された技術を試してみると、インシデント管理を計画的で組織的かつ効果的な方法で拡張することができます。
変化するITOps環境に被害を与えない
スケーリングが深刻な問題になる例を参考にまずこの問題の重要性を理解しよう
あなたは会社が新しい事業を買ったのを知りました。そこで、あなたは新たなインシデント管理プロセスを始めることになります。あなたのOpsチームは、すでに担当していることに加えて、新しいIT環境を引き継がなければなりません。まずあなたは、新しいスタックに同じツールと方法を適用することができる完璧なシナリオがないかを考えます。
しかし、現実は完璧ではありません。新しい会社は、以前と違う技術スタックと異なるインシデント管理の監視ツールと方法論を活用するかもしれません。このシナリオは非常に困難ですが、ITチームの成長や、よりアジャイルでバイモーダルなITOps構造の採用など、あらゆる成長シナリオと非常によく似ています。あなたがどんなスケールのシナリオに直面するにせよ、監視、インシデント管理、およびチームの拡大に取り組んでいる組織のためには下記が参考になります。
スケールの主な領域を特定する
新しいハードウェア、ソフトウェア、またはサービスを実装していますか? あなたの将来のITOps環境には新たな複雑さがありますか? あなたのエンジニアリングチームは育っていますか? コードエラーを報告する必要があるアプリケーションを継承しましたか? いずれの場合でも、ITOpsチームが業務を拡大することを余儀なくされている分野を特定する必要があります。
監視ツール
監視ツールが確実にスタック全体をカバーできるようにすることは、スケーリングの成功に最も重要です。この変更を採用するには、現在のスタックの外に複数の、または全く新しい監視システムを実装する必要があるかもしれません。これらのシステムの目的は、フルスタックの可視性を得ることであり、多くの場合、異種システムや新しいシステムを適切に監視するために、さまざまな監視ツールを実装する必要があります。しかし、組織化されたスケールを本当にサポートするには、このデータすべてを正規化し、重複を排除し、相関を取り、実行可能な洞察を得る方法が必要です。各監視ツールによって生成された全イベントを、単一のハブに集中させる必要があります。このハブからはイベントがトリアージされ、オンコールエンジニアにルーティングされるようにできます。
ノイズ減少
監視を実施するのは、効果的なインシデント解決のためにデータを理解することが目標です。監視ツール全体のルーティング動作を調整し、適切なしきい値を設定することは、新しいツールを実装した後にチームがアラート疲れを経験しないで済むようにするための次の大きなステップです。データを集約し、共通のインシデント管理システム内のページングからの対応不能なアラートを抑制またはフィルタリングすることは、ノイズを削減し、スタック全体のインシデントの可視性を高めるために重要です。
事故管理
包括的なインシデント管理プラットフォームは、すべてのツールのデータを統合し、スケールを拡大しながら成長するのに役立ちます。これは、すべての異種監視アラートを1つの共通システムに統合するだけでなく、リソース管理に関する混乱を防ぎ、エンジニアリングチームの成長をサポートします。さらに、より組織的なコラボレーションだけでなく、よりアカウンタビリティを促進するのに役立ちます。ボーナスとして、インシデント分析を活用して、上司にITOpsチームがどれだけうまく稼働停止を管理し解決するかを示すことができます。
スケールと複雑さは去っていません
ITOpsの世界は急速に進化していますが、1つの点は明らかです。ITチームは、業務拡大に全力を傾けるように指示されています。ITOps環境は、よりハイブリッドでアジャイルなアーキテクチャとフレームワークへと移行しています。ユーザーは、さまざまなデバイス間でデータへの高速で信頼性の高いアクセスを絶えず要求しています。その結果、ITOpsチームはスケーリングの計画を立てる必要があります。ダウンタイムの損害が大きくなるにつれて、インシデント管理が必要になっているのです。
ファーストデータ、ファーストモニタリング
ビッグデータはもう古い。 今日、データを効果的に活用するための鍵は、ファーストデータです。
大量の監視情報の収集と分析を伴う従来のインシデント管理ではもはや十分ではありません。 また、監視データの収集だけでなく それをリアルタイムで実行する「ファーストモニタリング」が必要とされています。
ここでは、ファーストモニタリングが意味することを検証し、インシデント管理チームがこのアプローチを実装して大きなメリットを実現する方法について説明します。
ファーストデータの定義
ファーストモニタリングの概念を理解するためには、ビッグデータの世界で最も新しいイノベーションの1つであるファーストデータを理解する必要があります。
非常に簡単に言えば、ファーストデータは高速にビッグデータを処理することです。 ビッグデータとは、伝統的に大量の情報を保存して後で分析することを意味しますが、ファーストデータとは、大量の情報をできるだけ速く、理想的にはリアルタイムでデータ分析を実行することを意味します。 その目標は、できるだけ実用的で関連性のあるデータを分析することです。
ソースから分析プラットフォームにデータをストリームするのは、ファーストデータを活用する上で重要な部分です。 これが、Apache Sparkのようなビッグデータツールが近年普及している理由です。 ストリームデータの収集とインメモリ処理をサポートすることにより、Sparkは非ストリーミングやハードディスクによるデータ解析プラットフォームよりもはるかに高速で大量の情報を取り込み、分析できます。
ファーストデータとインシデント管理
インシデント管理はデータ分析とは異なる分野ですが、インシデント管理者はファーストデータへの移行トレンドから多くのことを学ぶことができます。 インフラストラクチャの監視とインシデント管理の世界では、大量の監視とアラートのデータをリアルタイムで分析してレスポンスを向上させることが、これまで以上に重要になっています。
伝統的なインシデント管理から迅速なインシデント管理まで
ファーストデータとファーストモニタリングのつながりは偶然ではありません。多くの点で、インシデント管理の進化はデータ分析の進化を反映しています。
約10年前までは、インフラストラクチャのデータは比較的小さくて済んでいました。ほとんどの組織では、それほど多くのデータを生成しなかったため、ペタバイトクラスのデータを分析する必要はありませんでした。同様に多くの組織は、大規模で多様なインフラストラクチャをサポートできる監視ソリューションを必要としませんでした。代わりに、サーバやワークステーションからなる比較的小さくて複雑ではないネットワークをトラックするためのベーシックな監視システムで済んでいました。
そして、2000年代半ばには、データとインフラストラクチャの両方が大幅に拡大し始めました。すべてをデジタル化することで、組織は大量の情報収集を開始し、ビッグデータを生み出しました。その一方で、モバイルデバイスの普及、仮想化の台頭、さらにますます強くなるコンピューティングパワーの必要性は、インフラストラクチャをはるかに大きく複雑にしました。この新しい状況には大規模なモニタリングが必要でした。
そして、ここ数年の間に、もうひとつの変化が起こっています。情報が絶えず変化している時代には、ほんの数時間の分析の遅れでもデータの価値が損なわれます。同様に、最新ではない情報を監視することに基づいてインシデント管理を実行することにより、管理者はインシデントを迅速に処理して対応することができなくなります。
したがって、ファーストデータとファーストモニタリングには異なるツールセットが必要な場合がありますが、両方の動機と原則は同じです。インシデント管理チームがインフラストラクチャとアプリケーションをできるだけスムーズに稼動させようとファーストモニタリングに専念するのは、データアナリストの仕事とよく似ています。
ファーストモニタリングの促進
情報の収集と迅速な対応は簡単に聞こえるかもしれませんが、実際にはどのようにしてファーストモニタリングを行うことができるでしょうか。主なガイドラインは次のとおりです。
データ収集を一元化する:** 迅速に情報を監視するためには、すべての監視データを中央のインターフェイスに転送する必要があります。これにより、異なるダッシュボードや監視システムを切り替える必要がなくなり、時間と精神的なエネルギーを無駄にするだけでなく、根本原因を理解することが非常に困難になります。 利用可能なすべての情報を収集する:** 伝統的なインシデント管理は、マシンのデータとアラートの収集だけに集中する傾向があります。その情報は、迅速な監視を行うために必要なものの一部を提供しますが、可能な限り迅速にインシデントに対応するためには、可視性と洞察力を可能な限り広げるべきです。たとえば、チケットやサポートコールから人間が生成したデータを収集することを無視してはいけません。これは、PagerDutyのカスタムイベントトランスフォーマーなどの機能を活用して、従来はインシデント管理ワークフローの一部ではないソーシャルメディアチャネルなどのソースからデータを収集することも意味します。 ノイズを最小限に抑える:** 大量のアラートを受け取っても、アクションを必要とするのはそのうちの一部だけです。 したがって、警告の数が最小限になるようにノイズをカットし、対応不要なものを抑止することは絶対に重要です。重複するアラートは自動的に排除されるべきであり、解決が必要な単一の問題に関連する症状をグループ化するのは簡単なはずです。これにより、注意を必要とするアラートの瞬時識別が容易になり、リアルタイムで適切な応答ワークフローが開始されます。 データを解釈しやすくする:** 大量の監視データを収集し、中央の場所に格納することで、そのデータをすぐに価値に変えることができます。 しかし、ダッシュボード上の情報を分析する負荷を軽減するには、さまざまなソースからのデータを一貫した形式に正規化する必要があります。 そうすれば、さまざまなベンダーのすべてのスキーマを暗記する必要はありません。 これを実現するには、さまざまな形で情報を取得し、フィールドを普遍的なものに標準化し、即座に実行可能でわかりやすい洞察を与えるインシデント管理ソリューションが必要です。
これらのプラクティスはすべて、重大な事故の際にインシデント管理者が必要とする手動分析の量を最小限に抑えます。 また、アラート収集とアクションの間隔を最小限に抑え、インシデント管理スタッフがインシデントに素早く反応し、ファーストモニタリングをリアルタイムレスポンスに変えて正常稼働時間を向上させます。
リモートインシデント対応でPagerDutyを常にオンに保つ
2020年7月初め、多くの地域で、サービスプロバイダーのルータの設定ミスによる大規模なインシデントが発生しました。これにより、サービスの障害が連鎖的に発生し、いくつかの有名なSaaSに広範囲の停止と混乱を引き起こしました。
障害が発生したとき、我々PagerDutyのチームはすぐにイベントやインシデントの世界的な急増に気付きました。いくつかの組織内でアラートやインシデントが増加することは珍しくありませんが、今回のケースでは、複数の地域で多数発生していました。これは懸念材料でした。
インシデントの量が異常に増加した場合には、問題に対処するために総力を挙げて対処できるように、予防措置としてメジャーインシデント対応を積極的に展開しています。対応者にタイムリーに通知を行うために、PagerDutyのモバイルアプリを使用して、必要な関係者がどこにいようとも、即座に連絡を取るようにしています。
この特定の問題は、私たち全員がリモートで仕事をしている時に起きたので、私たちはSlackとZoomを使って対応を調整しました。PagerDutyとSlackとのインテグレーションを利用して、インシデント責任者、エキスパート、利害関係者、記録係からなる完全にリモートのチームを編成し、サンフランシスコ、トロント、アトランタで協力して大規模なインシデント対応を3分以内に完了させました。
当社のインシデント責任者が対応を調整し、カスタマーサポートが内部と外部の情報更新を管理し、専門分野のエキスパートが取るべき必要な手順を議論し、記録係が対応の進捗状況とコミュニケーションを文書化しました。
幸いなことに、当社のシステムがインシデントトラフィックの急激な増加に対応できることを迅速に判断し、問題を沈静化することができました。
リモートインシデント対応の重要性
完全に遠隔地での作業環境でのこのような大規模なインシデントは、場所に関係なく、インシデントを迅速に受任し、チームとして対応することの重要性を浮き彫りにしました。PagerDutyでは、分散化した作業と対応の文化は、初日から私たちのプロセスに組み込まれています。実際、当社のインシデント対応ドキュメントを見てみると、対処中に対応者の物理的な接近を必要とするプロトコルは1つも見当たりません。PagerDutyプラットフォームを使えば、どこにいても、インシデントに瞬時に対応し、作業することができます。
また、SlackやZoomのようなコラボレーションツールを利用して、インシデント発生時にリアルタイムでコミュニケーションを取ることもできます。今回のケースでは、PagerDutyとSlackのインテグレーションが、インシデントの状況と関係者への情報更新のための中心的なハブとなりました。Slackで当社のチームメンバーは主要な利害関係者に通知し、役割を割り当て、仮想的な場所に集まり、インシデントに真正面から取り組むことができました。
さらに、インシデントが解決したあとにも、Slackは事後検証のプロセスに役立つため、将来の対応プロセスにも貢献します。記録係はSlackインテグレーションを使用して、対応中に発生したすべてのことを文書化して記録します。誰が対応したのか、誰が対応しなかったのか、なぜエスカレーションしたのかなど、起きたことをすべて見ることができるので便利です。これにより、インシデントの全体像を把握して理解することができ、将来インシデントが発生した場合でも、より迅速に対応して解決するためのプロセスを改善することができるようになります。
私たちの分散型エンジニアリングの文化は、PagerDutyが何があってもお客様のために常にオンになっていることを保証することを可能にしています。PagerDuty をコラボレーションツールや明確に定義されたプラクティスと共に真実の単一ソースとして使用することで、事実上どこからでもインシデントに効果的に対応することができます。多くの場合、オフィス内のオーケストレーションから仮想的な対応に移行することは困難だと思うでしょうが、PagerDuty を使用することで、ほとんどの場合、通常通りの業務を行うことができます。
チームがどのように PagerDuty を使ってリモートインシデントレスポンスを行うかについては、分散型コミュニケーションに関するこのブログを参照してください。
本記事は米国PagerDuty社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ブランドと評判を守るインシデント対応
顧客は、価値観 を共有していると 感じる企業に忠実です。予期せぬ出来事が企業を襲ったとき、結果として生じた激動がブランドを危険にさらします。航空会社の災難や、テクノロジーシステムを巻き込んだ性能に関するインシデントなど、これらの瞬間は、顧客にサービスする能力を低下させることで、顧客体験に影響を与えます。顧客にブランドへのアクセスを提供するデジタルチャネルが増えている状況で、今日の現実は、世界中がポリシーや行動を監視する中で企業は事業を展開しているということです。
このシフトの影響から、CEOのオフィスにブランドが置かれるようになり、インシデント対応の中で企業のコミュニケーションを重視させる一因になりました。しかし、このチャレンジは企業のコミュニケーションのように、テクノロジー、製品、セキュリティなどのインシデント対応の共通部分にフォーカスする傾向があります。しかし、実際に問題となるのは、全ての側面がインシデント・オペレーションに書記から統合されていた場合、予期しない事態が発生したら、それらがどうに連携して最も効果的な戦略になりうるかです。
最近のForbesの記事で私たちは、危機の最中、特にインシデントのニュアンスが見落とされたときに、組織がブランドを保護するために使える3つのコミュニケーションのヒントを紹介しました。このような状況でストーリーラインをコントロールすることは、企業のコミュニケーションの責任です。彼らの役割は、オペレーションと顧客との関わり方を変えられるコミュニケーション計画を準備し実行することです。企業のコミュニケーションがインシデント対応業務に合わせて準備されている場合、次の点に対応できるメリットがあります。
出血を遅らせる
重大インシデントでは、技術とセキュリティの関係者だけが含まれる古典的な対応チームが組織されることがよくあります。 専門家が問題を特定して解決する間に、企業のコミュニケーションチームは待機させられ、対応作業に遅れをとります。 その一方で、デジタルチャネルを横断して世論が醸成され、形成されています。 レポーターは複数のストーリーを公開し、コミュニティ、ユーザー、パートナーはソーシャルチャネルを通じて意見を共有しています。インシデントの進展に合わせて企業のコミュニケーションチームを早期に巻き込むことで、危機に瀕しているブランドの出血を遅らせる機会が得られます。
ブランドの再構築
ポストモーティム(事後検証)のフェーズでは、重大インシデントに巻き込まれたビジネス全体の関係者が集まり、何が起こったのか、どのように対応業務が実行されたのか、何が改善できるのかを議論します。事態が終息すると、企業のコミュニケーションチームは、顧客やコミュニティの信頼を回復するために組織の舞台裏で働きます。彼らは企業側のメッセージを次にどこへ届けるかを決定し、PRの機会として何をすべきか、あるいは何をしないべきかを決定するために良い判断を下します。危機後に各ブランドは顧客の評判を素早く回復するためにどれだけのケアと行動を取ったかを顧客に迅速に伝えます。時には、整合性が取れない行動に直面したり、次の関連イベントが発生したりして、バックファイアを食らうことがあります。
デジタル時代には、企業の運営方法やコミュニケーションの役割に対する期待が急速に高まっています。新しい技術が登場し、デジタルチャネルが増加する現在、重大インシデントへ対応するための運用の初期段階でコミュニケーションを統合しておくことが、お客様のブランドが世間から否定されず称賛されるという差を生み出します。
PagerDutyがお届けする今年夏の新機能
2018年はPagerDutyにとって極めて重要な一年でした。 過去6ヶ月間にわたり、私たちは多くのPagerDutyの新機能の開発を加速し、デジタルオペレーション管理プラットフォームとモバイルアプリケーションのさまざまなアップデートと拡張をリリースしました。
これらの機能により、各組織は、レスポンス体制の編成と継続的な開発と配信をさらに最適化できます。開発者、運用チーム、DevOpsの実践者、および管理者が、コンテキストの洞察とインタラクティブなアプリケーションを通じて、カスタマーエクスペリエンスのあらゆる側面を視覚化できるようになります。
(訳注:下記の新機能の機能名は英文が正式名称です。和文の名称はDigitalStackが仮に訳したもので、正式ではありません。)
新機能のリリース
イベントインテリジェンスのリリース
最新の製品であるイベントインテリジェンス(Event Intelligence)は、デジタルシグナルと人間の対応行動の両方を組み込み、機械と人間のテレメトリーを組み合わせて、デジタルオペレーションを最適化します。自動適応学習アルゴリズムは、ノイズを削減し、チームがイノベーションと生産性向上に容易に集中できるようにします。 統合されたイベントインテリジェンスとインシデント対応により、誰もが同じ情報に接し、問題をより迅速に解決するために必要なコンテキストが確保されます。 ルーティングとワークフローの自動化、インテリジェントなアラート相関分析、ノイズ抑制、類似インシデントの憑依、API、およびプログラマビリティが連携して、レスポンダーが必要とする正確なマシンと人間のコンテキスト情報を提供します。
イベントルール(Event Rules) 、PagerDutyのルーティングとワークフローの自動化機能は、200以上のツールから大量のイベントデータをプログラムで管理するのに役立ちます。 イベントデータ、問題の重大度、サポート時間などに基づいて、ルーティング、抑制、通知、およびその他の動作をインテリジェントに自動化できます。
インテリジェントアラートグルーピング(Intelligent Alert Grouping)により、重要なコンテキストを集中しながらノイズを削減し、適応的機械学習とルールベースのアプローチによって、複雑なシステムにわたる関連する着信アラートを自動的にグループ化して1つのインシデントすることで、トリアージをスピードアップします。
類似インシデント(Similar Incidents)は 、トリアージを改善するのに役立つように、インシデント内に過去の関連のある問題を自動的に埋め込んで表示します。過去に類似の問題を処理していたエキスパートや過去のその問題の発生頻度を把握したり、過去のインシデントから得たより迅速に問題を解決するのに役立つ修復手順を含めて、状況に応じた洞察を得ることができます。
継続的な強化
今年の年初に、モダンインシデントレスポンス(Modern Incident Response)機能をリリースしました。私たちは、顧客からのフィードバックを取り入れながら、この製品を引き続き改良し続けています。
モダンインシデントレスポンス(Modern Incident Response)機能 の更新
既にPagerDutyのレスポンスプレイ機能を使用し、複数のチームのレスポンスをモバイル化し、ワンクリックでインシデントに関するアップデートを送れるようステークホルダーを登録している方もいらっしゃると思います。今夏からはさらに レスポンスブリッジ(Response Bridge)をレスポンスプレイにつなぎ合わせて、レスポンダーがシームレスにコラボレーションできるようになりました。この機能によって問題の最下部までレスポンダーが下りていけるようになり、ビジネスの重要なサービスをすばやく元に戻せるようになります。
ライブコールルーティングの機能拡張(Live Call Routing enhancements)。 電話番号をダイヤルしてオンコール通話相手にすぐにアクセスできるほか、重要なアプリやサービスに関連付けられたオンコールスケジュールとエスカレーションポリシーでオンコールをルーティングすることができます。
あるコールが次のレスポンダーにエスカレートする前に鳴動時間をカスタマイズする
自動受付の文言をカスタマイズする
コール内容を文章に転記する
この柔軟性は、さまざまなチームの対応プロセスに対応し、チーム全体および組織全体の学習を促進します。
レスポンスのモバイル化中の全エスカレーションのインシデントタイムライン項目化。 インシデントレスポンスに携わっているのが誰かを知ることは、インシデントレスポンスを加速するうえで重要であり、適切な人材を重要な問題の解決に専念させ、他者が開発に戻れるようにします。 PagerDutyのインシデントのタイムラインは、レスポンスプレイ、カスタムインシデントアクション、チャットの会話など、豊富なインシデント関連アクティビティをキャプチャします。 現在では、レスポンスのモバイル化中に発生するすべてのエスカレーション関連アクティビティもインシデントのタイムラインに記載されており、定期的な問題や新たな問題に直面した場合に貴チームが信頼する貴重な事後検証(ポストモーティム)にその内容を簡単に含めることができます。
クリティカルインシデント関連の活動をどのようにあなたの事後検証に含めることができるかについて詳しくはここでご覧ください。
インテグレーションとAPI
PagerDuty開発プラットフォームは柔軟なAPIと拡張性ツールを提供しており、どんなチームもPagerDutyと簡単に統合して拡張することができます。 私たちはすでに280以上のビルトインのインテグレーションとエクステンションをカバーしており、さらに追加しています!
最新の PagerDuty とServiceNowの公認インテグレーションは、ITチームが重要なサービス管理およびセキュリティインシデントの問題にリアルタイムで対処するのに役立ちます。 チームは脅威を緩和し、根本原因の特定とサービス修復を加速する力を得られます。 この統合により、チームは解決までの平均時間を短縮し、デジタルでの障害がビジネスへ及ぼす影響を軽減できます。
サービス群とチームの同期
ServiceNowプラットフォーム全体にわたるリアルタイム応答
自動化されたエンタープライズワイドなモバイル化
セキュリティインシデントレスポンスの迅速化
PagerDuty + Microsoft AzureとVisual Studio Team Services(VSTS)は、もうひとつの新しいインテグレーションです。ソフトウェア開発のライフサイクル全体を通して、チームに運用上の健全性の洞察とイベントインテリジェンスを提供することに私たちも大きく期待しています。各チームは、PagerDutyとMicrosoftを使用して、アプリケーションのコーディング、所有、および管理を効率的に行うことができるため、顧客に影響を与える問題を先取りしてより高品質なアプリケーションやサービスを迅速に提供できます。 その他の利点は次のとおりです。
PagerDutyインシデントとMicrosoft Azure Metric AlertsとMicrosoft Visual Studio Team Services Work Itemsとの自動同期
新しいMicrosoft Azure Metric Alertsフォーマットのサポート
インシデントレスポンスとサービス提供の迅速化
改善されたコンテキストによる開発サイクル時間の短縮
各サービスとAzureインフラストラクチャ全体の可視性の向上
V2 webhooks。 インシデントベースのWebフックを使用すると、インシデントが発生したときに外のWebhook URLにWebhookメッセージを送信できます。 Webhook受信者は、ID、イベント、作成日時、インシデント、ウェブフック、およびログエントリなどの複数のメッセージ要素を含む、メッセージ配列のペイロードを受信できます。
あるアカウントに拡張機能を追加するためのAPI 。 APIを介してサービスに拡張機能(webhookなど)を追加できます。
モバイル
アップデート: iOSのUniversal Linksのサポート (訳注:Universal LinksはiOS 9以降で導入されています)。レスポンダーが時間を節約できれば収益とカスタマーエクスペリエンスにポジティブなインパクトを与えられるため、調和のとれたモバイルエクスペリエンスが、レスポンダーにとってとても重要です。そのため、私たちはiOSのUniversal Linksのサポートを実装しました。 iOS Safari、Mail、Messagesからタップされた、インシデント、エスカレーションポリシー、ユーザーへのリンクは、PagerDuty Appでシームレスに開けます。
モバイルアプリについて多くのご意見をいただきました。人々はどこにいてもモバイルデバイスからアクセスできて、エスカレートできるようにすることが大好きなので、次の機能を追加することでアプリをさらに便利にすることに決めました。
iOS 1Passwordインテグレーション 。
インシデントの中の詳細、メモ、電話番号とURLをクリック可能に。
インシデント優先度(Incident Priority)のサポート (詳細、インシデントリスト、ソートなどを含みます)。
インシデントタイムラインのレスポンダリクエストとメモのiOSの電話番号とURLをタップ可能に。
PagerDutyモバイルアプリでのライブアップデート対応。この詳細については、 エンジニアリングのブログをご覧ください。
これらは2018年のこれまでに用意した全アップデートです! しかし、今年はまだ終わっていませんし、後半に発表する予定も増えています。製品や機能の最新かつ最大限の情報を知るためにチューニングはそのままにブログをチェックしてください。
本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。
クラウドへの旅、インシデント管理の改善
多くのIT組織は、クラウドインフラストラクチャ の活用はやむを得ずやることではなく、IT組織がビジネスニーズに即応するための最も効果的な方法だと悟りました。
しかし、クラウドには、ダウンタイムの最小化、運用コストの削減、社員の燃え尽き症候群防止など、新たな課題があります。企業がプロセスと手順を新しい現実であるクラウドベースのインフラストラクチャに移行するのに合わせて、これらの課題を解決するためにインシデント管理ソリューションを採用する必要があります。これはハイブリッド環境で運用する大企業の場合、つまり従来型のインフラストラクチャとクラウドベースのインフラストラクチャを混在させて、インシデント管理にもハイブリッドなアプローチが必要な場合に特に当てはまります。クラウドに移行するには時間がかかりますが、それは1回で済むものではありません。
組織がこの新しいパラダイムを受け入れてクラウドに移行する理由と、シームレスなクラウド移行のためにインシデント管理をどのように処理しているのかを見てみましょう。
なぜクラウドに移行するのか
組織がクラウドに移行するには多くの経路があります。クラウドネイティブアプリを担当する開発チームを、プライベートクラウドとパブリッククラウドの様々な組み合わせを担当するインフラストラクチャチームへと移行させ、2つのクラウドを相互接続するためのハイブリッドインフラストラクチャを構築する方法など、クラウドに移行するメリットのいくつかを見てみましょう。
インフラストラクチャ管理の削減**:クラウドサービスを活用することで、従業員は、下位レイヤーのコンポーネントをパッチして維持する必要がなくなり、ビジネス価値を提供することに集中することができます。 アジリティ(俊敏性)の向上**:クラウドインフラストラクチャ上でサービスを更新、追加、削除する機能は、企業が新しい機会に対応するスピードを大幅に加速します。 クラウドネイティブアプリ**:アジャイル開発のプラクティスと継続的インテグレーション、継続的デリバリー、マイクロサービスを組み合わせることで、チームはビジネス機能をスピードとスケールをもって提供することができます。 ディザスタリカバリとビジネス継続性**:クラウドインフラストラクチャのビルトインデータレプリケーション機能を活用することで、迅速なリカバリを目的としたセカンダリサイトの構築が可能になります。時間が経つと、これは複数のゾーンや地域に配置した冗長システムに変わります。 常時稼働**:クラウドサービスは、一般的に24時間365日稼働しており、サービスへの移行以外の余分な労力や人員を必要としません。 設備投資の無償**:クラウドサービスはサブスクリプションベースで機能するため、大きな設備投資が不要で、償却費や減価償却費を払う必要はなく、コストを運用予算に移行できます。クラウドサービスプロバイダは、資本投資を必要とする物理的環境を維持します。 市場投入までの時間短縮**:購買手続きが全くなくてもチームは新しいアイデアのテストを数日間で開始することができます。数週間または数カ月のリードタイムを必要とする従来のモデルとは異なる点です。
クラウドへの移行は、企業がより機敏に対応できる利点があるため、規模を問わず多くの組織にとって合理的です。クラウドへの移行は、やるかやらないかではなく、いつやるかという問題になっているのです。結果として、ITチームはこの新しいパラダイム内でアプリケーションを構築、運用、サポートする方法を学ばなければなりません。
クラウド環境でリアルタイムの可視性を得る
クラウドへの移行の前後にインシデント管理プロセスを導入していないと、問題が発生したときに盲点になり、インシデント対応が遅れることがあります。これらの問題は、ビジネスへのリスク、顧客への影響、および移行プロセスの遅延につながる可能性があります。また、ハイブリッドインフラストラクチャを使用したり、パブリッククラウドインフラストラクチャに完全に移行したりする場合に、これらの弱点を未解決のままにしておくと、実際のインシデント対応に支障をきたすようになります。効果的なインシデント対応でハイブリッドクラウド環境を管理することは非常に重要です。そうすればクラウドベースのアプリケーションで動作しているものをリアルタイムに把握し、移行中または移行後に問題が発生した場合に対処できます。
クラウド移行中のインシデント管理の課題
前述したように、クラウドに移行する際には、次のような新たな課題を克服する必要があります。
クラウドインフラストラクチャプロバイダとの統合と監視
クラウドネイティブアプリケーションを組織のアプリケーションポートフォリオに導入することで、複数のクラウドプロバイダー間でインスタンスを動的に追加または削除する場合でも、すべてのインスタンスを表示、レポートできることが不可欠です。現代のクラウドベースのツールからシグナルを引き出すことが重要ですが、従来のツールからシグナルを引き出せることも同様に重要です。組織がハイブリッド環境に存在する可能性が高いからです。すべてのアプリケーションが同時に移行されるわけではないため、これは移行中に大きなリスクになりますが、既存のサービスやアプリケーションを提供するには、オンプレミスとクラウドの両方のコンポーネントが必要です。
解決策:最新と従来のアプリケーションパフォーマンス管理スイートと、すべてのクラウドインフラストラクチャで使用可能なネイティブツールを理解し、統合できるインシデント管理プラットフォームを用意します。
常時オンは常時サポートが必要だという意味です
顧客は常時オンの経験に慣れてくると、自社のサービスは24時間いつでも利用できると期待しますから、問題を報告するために月曜日の朝まで待たずに声を掛けることを躊躇しません。
解決策:24時間365日のサポートを処理するために構築されたインシデント管理プラットフォームに投資し、監視ソリューションが事前に障害を検出したとき、またはクライアントがインシデントを報告したときに、どのチームに通知するかを知ることができます。その後、インシデント対応のライフサイクルを通してそのチームをサポートします。
クラウドの可視性
クラウドベースのプロバイダーから提供されるサービスが増えましたが、アプリケーション、ミドルウェア、インフラストラクチャからのイベントやアラートに必要な可視性を、顧客が影響を受けたり、あなたのプロジェクトが遅れる前に実現できるようにするにはどうしたらよいでしょうか。
解決策:複数の情報源からの情報を受け取れるソリューションに投資し、問題の影響を調査するチームの能力をサポートします。対応者が適切な情報を持って行動し、ビジネスチームやプロジェクトチームのリスクを最小限に抑えることが重要です。これにより、クラウドの移行ライフサイクルが迅速に回り、高品質なアプリケーションの変更が本番環境に導入されるようになります。
分散した労働力
クラウドにはモバイルフレンドリーなプラットフォームがあり、地理的に分散した複数のオフィスを持つ組織がますます増えていますから、単一の統一されたコミュニケーションチャネルを持つことが重要です。
解決策:従来の電話会議を使っているのか、それともSlackやHipChatなどの最新のコラボレーションソリューションを使っているのかどうかは関係ありません。目標は、あなたが話す必要がある人々を見つけられる場所を1つにすることです。SlackやHipChatのようなツールの利点は、会話を離れずにチャットに情報とアクションを持ち込めるようにインシデント管理と監視ソリューションにフックできる点です。
クラウドの移行の一環として、開発チームやビジネスユニットのニーズに合わせて、同じティアでチームをサポートする必要性を検討することが重要です。サポートチームが、開発者が展開しているものの背後にあって必要なすべてのプロセスとツールを持っていない場合、追加されたすべての複雑なレイヤは、信頼性の高い方法で使えないため、ビジネスにとっては無駄になります。
オンコールエンジニアのための準備
オンコールエンジニア は インシデント 管理 で重要な役割を果たします。 彼らは、インシデントをクリティカルな状態から管理された状態に変える役割を果たし、迅速に解決します。
スタートアップには誰がコールを受けるべきかについてあまり多くの選択肢がないかもしれませんが、組織が成長し、インシデント管理がより複雑になり、関係者が増えるにつれて、構造化されたプロセスを用意しておくことがオンコールエンジニアにとって重要になります。スタートアップ企業であれ大企業であれ、オンコールエンジニアを成功させるための明確なプロセスを用意しておくことで大きな利益を得られます。 ここにいくつかのガイドラインを示します。
最初の対応が重要
インシデント発生の最初の数分間で、オンコールエンジニアはインシデントの重大度とサービスへの影響を把握する必要があります。それに基づいて、影響を受ける下流のサービスと、誰がそのインシデントを解決する必要があるのか、そしてその人たちを迅速に実戦に投入する方法を判断する必要があります。これには、何かが壊れたときに根本原因を特定し、作業の優先順位を決定できるように、システムがどのように機能しているかを実践的に知っておく必要があります。オンコールエンジニアのローテーションは自動的にスケジュールされます。こうすれば負荷が分散され、チームは公平性と説明責任のために最適化され、誰もがインシデントを処理でき、接触を失うことはありません。大規模なチームでは、最初の対応を開始できる専門のインシデント管理者がいることがあります。いずれの場合も、オンコールエンジニアの主な目標は、インシデントのトラブルシューティングや解決ができない場合でも、インシデントを解決するために必要なリソースを取り込むことです。
2次オンコールエンジニアを用意しておく
2次(そしておそらく3次も)のオンコールエンジニアをバックアップとして持つべきです。 そうして、第1レベルの対応者が寝過ごして午前3時の電話連絡に気づかなくても、何も谷間に落ちないようにします。これはまた、チーム内の役割のローテーションのスケジュールが必要だということです。1次担当のエンジニアからの応答がない場合、インシデント通知がバックアップエンジニアにエスカレートされるように、自動化されたルールを設定します。
オンコールエンジニアが必要なトレーニングを
受けていることを確認する
インシデント発生時には多くの問題が発生するため、オンコールのエンジニアはプロトコルを遵守し事態の推移に遅れず考えることができる必要があります。 彼または彼女は、さまざまな部門間のステークホルダー(顧客サポート、マーケティング、PRなど)が連絡を取り合う適切な方法も理解しておく必要もあります。そうすれば修復状況を外部に伝達できます。インシデントが発生した場合に従うべきチェックリストまたはフローチャートをオンコールエンジニアに渡しておくと便利です。
ダウンタイムの1分ごとに何千ドルもの損失が発生する可能性があるため、オンコールエンジニアができるだけ早くインシデント対応をする必要があります。そのための手順は次のとおりです。
インシデントの特定とログ作成
まず、インシデントを特定または検出してログを作成します。ロギングは、問題の根本的な原因を迅速に突き止めるのに役立ち、解決後のインシデントの包括的な事後検証の進め方を示してくれます。インシデントに迅速に対応することが重要なので、特定とロギングは迅速かつ体系的に行ってさっさと次のステップに進む必要があります。
カテゴリを分けて優先順位を付ける
チームが遭遇する可能性がある問題はその種類が膨大なため、混乱を避けるためにインシデントを分類することが重要です。影響を受けるユーザーの数、影響を受けるサービスに関する問題の「爆発の半径」、潜在的な収益への影響などに注意してください。インシデントの優先順位を設定することで、オンコールエンジニアは、インシデントが残りのチームの時間とリソースを必要としているかどうかを連絡することができます。可能であれば、チーム全体の時間を節約するために、あまり複雑ではないマイナーなインシデントにはエンジニアだけで対応できるようにしておくとよいでしょう。オンコールエンジニアが重要なことに集中できるようにするため、行動不可能なアラートは抑制する必要があります。
正しい人に通知する
PagerDutyのようなプラットフォームやそれに内蔵されたChatOpsやコラボレーションは、関係する人材を採用し、その人たちを適切なタイミングで適切な場所に集めるためのベストプラクティスです。特に、特定のChatOpsチャンネル/会議室、ビデオ通話と会議での共有、コンテキスト内の問題の修正機能を使うと、解決のスピードとビジネスの影響レベルに大きな違いが生じます。チームメンバーとコミュニケーションしている間は、自分と他の人の時間を節約するために、事件の説明を簡潔かつ理解しやすくすることも重要です。チームはアラートが多すぎて注意をそらすことがあるので、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つのインシデントにグループ化する必要があります。理想的には、これはルールを介して自動的に行われるべきです。さらに、アラート疲れや報告忘れが致命傷になる可能性があるため、チームメンバー全員にアラートするのではなく、適切なチームやチームメンバーだけにアラートを送るシステムを導入することが重要です。
不十分な準備、訓練、経験
理想的には、全てのインシデント対応チームは、問題を迅速に診断でき、各インシデントを修正するためにどのツールとテクニックを使用すべきかを理解している、高度に熟練した技術者で構成する必要があります。
このような問題を最小限に抑える最良の方法は、インシデント対応者のための正式なトレーニングシステムを用意すること、新しいチームメンバーは可能な限り経験豊富なチームに配属すること、チームに適切なドキュメントを用意することです。一貫性と再現性の高いベストプラクティスを実現するためのドキュメントには、基本的な手順のマニュアルや、索引付きで簡単に検索できる相互参照の効くデータベース(過去のインシデントなど)が含まれている必要があります。
メジャーな新製品のロールアウトに対する不十分な準備
メジャーなアプリケーションのリリースの際―それは全く新しいアプリケーションやサービスかもしれませんがー開発者がいくつかの重大なバグを見逃して大量のアラートが押し寄せる事態に対応チームは備えておくべきでしょうか。結局のところマーフィーの法則はいつでも有効です。それが起こるのは広く使われているプログラムのアップデートや、1つ2つのバグが絡みあったトレースしにくいエラーを発生させる場合です。対応チームが準備できていない場合、時間とリソースの全てが優先順位の高いアラートの暴風に巻き込まれ、関連性のないその他のインシデントを処理するための余裕はほとんどありません。
もちろん、リリース前にA/Bテストやカナリアテストなどでアップデートが適切にテストされていることが理想的です。応答チームが配備作業に加わっていれば、問題がはるかに小さなうちに対処できる機会があります。しかし、限定的な導入から始めるという決定をインシデント対応チームが下すのは不可能であり、十分にテストされていないリリースに対処しなければならない可能性があります。
このような状況では、全ての対応者をオンコール待機にするか、アップデートで起こる全ての問題を処理する特別なチームを指定する必要があります。どのアプローチが最も効果的かは、少なくとも更新の範囲と利用可能な対応チームのリソースによって決まります。しかし、計画はいつでも何度でも必要に応じて変更できますし、計画を立てておけば準備ができていない場合とは大違いになります。
ボトルネックの解消
他にも、時代遅れの障害が発生しやすいインフラや過負荷のインフラから生じるインシデントや、インシデントとは無関係のタスクで対応チームの時間が取られるなど、多くのボトルネックがあります。しかし、私たちが列挙したボトルネックは、インシデント対応チームが時間を消費した理由の多くを占めており、ここで提案した修復アプローチは、それらの大半をなくすのに役立ちます。
インシデント管理がアプリケーションのサポートにもたらす7つの利点
インシデント管理は、アプリケーションをサポートする大事な要素です。アプリケーションの仕事をするとき、私たちはプロダクション(本番バージョン)のリリースに大部分の時間を費やします。これには、ロードマップについての打ち合わせ、ニーズと要望の特定、私たちのストーリーと機能の構築が含まれます。その後、多くのサイクルが開発、テスト、QA(品質検証)に費やされます。エンジニアリングチームは環境を準備しながら作業します。その後、アプリがローンチを迎え、チームは次のアプリに移ります。アプリを本格的に提供するのは運営チームの責任です。これがアプリとのやりとりの終わりである場合、開発チームは、改善に関する貴重なフィードバックを多く未解決または未発見のまま残しています。 そこで、インシデント管理プロセスが、アプリケーションを改善し、最終的にお客様にとってより良いエクスペリエンスを提供する鍵を握ることになるのです。
- 必要に応じて迅速にエスカレーションし、解決までの時間を短縮する
明確かつ十分に利用されるインシデント管理プロセスがあると、アプリケーションサポートは組織文化の自然な一部となります。インシデントは、ベストプラクティスを反映した方法に沿ってより迅速に、より一貫して解決されます。明文化されていなかったり不規則だったりするインシデント管理は、解決と絶え間ない消火作業で試行を繰り返すことにつながる可能性があります。
- クロストレーニングを奨励する
「夜中に誰かを起こしてそれを修正させる」という原則に従って、インシデント管理プロセスは、開発チーム内とチーム間の両方でクロストレーニングを奨励します。 これには、コードの可読性の重要性を強調し、コメントすることで、運用文書と構成管理を最新の状態に保つことを奨励するという副次的な利点があります。
- 信頼と透明性の文化を築く
開発チームのすべての人は、バックアップとプライマリの両方でエスカレーションのローテーションに参加する必要があります。これはコミュニケーションとチームの友情を深めます。また、透明性を奨励することで、オンコールに出る開発者はすでにアプリケーションの一般的な感覚を持っているはずであるため、解決までの時間が短縮されます。 チームがマイクロサービスのパラダイムに従っており、各アプリケーションに1つのサービスを含む場合、これはさらに強化されます。
- ジュニアスタッフの成長の道を提供する
私たちは、私たちが前進するために急いで来た場所を振り返ることをしばしば忘れています。 チームはまた、思考や意見の多様性から恩恵を受けます。インシデント管理プロセスでは、エスカレーションパスのすべてのレベルをアプリケーションに公開することで、これを促進できます。インシデントを解決することは、ジュニアメンバーにより多くのチームのことを理解させるのに役立ちます。特定のインシデント解決について貴重な知識を得る一方で、アプリケーショントポロジの包括的な設計にも触れる機会が持てます。才能ある人を募集し維持することは、組織にとって重要です。第1層のインシデント対応から開発およびエンジニアリングチームまでの可視的なパスを提供することは、貴重な採用ツールになります。
- より良い全体プロセスを作成する
継続的なインテグレーションと継続的な配信技術を組み合わせることで、以前の月次または四半期の導入よりも迅速に展開されます。 これはインシデントを促進し、量と頻度を減らします。 これの成果は、はるかに短い時間枠でバグを修正でき、繰り返しの一時的な修正の必要性を大幅に削減できることです。 これにより、エンジニアリングチームとオペレーションチームの技術的負債の蓄積も少なくなり、実践的に役立つ修正の道が開かれます。
- 定量的フィードバックを生成する
追跡される各インシデントは、多くのもののカプセル化です。 これには、修理のための複数の人の時間、解決を記した文書、おそらくバグレポートの提出が含まれます。また、アプリケーションを操作する際に苦労する点の評価も明らかにするに違いありません。これにより、アプリケーションのロードマップを知らせることができ、実装可能な高価値、低エフォートな機能拡張に関する会話を促進することができます。
- 内部ツールを開発する
チームが一定のサイズに達すると、職務の差別化が行われます。 これは組織の自然な進歩であり、規模を拡大する方法です。 以前はうまく機能していたアプリケーションを操作するツールは、組織の成長を維持するために不可欠になっています。 インシデント管理プロセスは、このニーズだけでなく、これらのツールを作成するときに開始する場所を明示することもできます。
アプリケーションのインシデント管理は、多くの場合、顧客サポートと成功にとっては重視されないものですが、顧客はアプリケーションの一部のみを見ています。 彼らが経験するのは、アプリケーションのレイヤーを通る狭いパスだけです。 もっと目に見えるくらいアプリケーションの復元力が高く、インシデントが迅速に解決されるほど、すばやくアプリケーションを使用することができます。
本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。
- PagerDuty最高製品開発責任者による「AIと自動化が実現するオペレーショナル・エクセレンス」講演録画が公開
- PagerDuty、新しいアップデートで運用効率を向上
- PagerDuty 8月の製品アップデート情報
- Juneteenthを受け入れる:インクルージョンへの旅
- Custom Fields on Incidentsのユースケーストップ5
- ゼロトラストセキュリティーの正体と、気にしておくべき理由
- 5 年間の社会的影響: 公約 1% に対する進捗状況を振り返る (そしてこれから)
- AIOpsと自動:Forresterの主席アナリストであるCarlos Casanova氏をゲストスピーカーとして迎えた対談
- Runbook Automation for Incident Resolutionの新製品トライアルを活用する
- PagerDuty Operations Cloudに生成AIを投入