Blog
ブログ

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日)

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

「そこには金があるから」。悪名高い銀行強盗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トラブルに自然に対処できるようになります。金銭的損害の出るセキュリティ侵害よりも唯一悪いこと、そして顧客の信頼を失う最速の方法は、顧客が金融機関そのものではなく、他のソースから問題を知ったときです。そのため、顧客には迅速に問題の発生を知らせる必要があります。

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

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

2020年春のローンチ:新しいデジタル時代の新機能

進行中のパンデミックとその結果としての景気後退は、市場の状況を劇的に変化させました。その結果、エンジニアチームは、完全リモート環境に突然移行することによる影響を軽減するために、財務リスクを最小限に抑え、コストを削減する必要性をますます感じることになりました。

一部の人にとっては、ビジネスの継続性を維持するための苦労がありました。つまり、皆が自宅で仕事をしているときもビジネスの物理コンポーネントは実行し続けています。他の人にとっては、社内外の顧客に対するデジタルサービスへの依存度を強調することが課題の中心となっています。最近の調査で判明したように、すべての組織や部門が同じように影響を受けるわけではありません。

このような環境では、会社の種類に関係なく、ビジネス目標はコストを削減し、収益を保護し、デジタルトランスフォーメーションを加速するという3つのニーズに集約されます。困難なように思われるかもしれませんが、楽観的な見方があります。適切なテクノロジーソリューションを導入することで、組織は予算を拡大し、プロセスをより効率的にし、シームレスなデジタル体験で顧客を満足させることができます。

PagerDutyは、お客様の課題解決を支援するために、対応チームの効率を向上させ、デジタルファーストの世界でお客様との関係を保護できるようにする最新のリリースを発表しました。

積極的なインシデント対応

デジタルサービスへの信じられないほどのアクセスに直面している場合でも、それがまもなく予定されている場合でも、あらゆる組織が積極的にインシデント対応することが重要であると考えています。積極的になるとは、技術スタッフとビジネススタッフの両方にデジタルサービスを活用するためのツールを提供し、問題が発生しても無知の状態から始まらないようにすることです。デジタルの世界では、秒単位の時間が重要であり、重要な個人がその場でインフラや対応手順について学習することはできません。今こそ行動の時です。そのため、デジタルの準備が非常に重要です。

積極的なインシデント対応に関する新機能とアップデートされた機能により、すべてのチームにデジタルサービスとその依存関係、ハイパーケアを提供し、収益に影響する危機になる前に問題を回避するために必要な運用指標を提供します。

サービスプロファイルを使用すると、エンジニアリングマネージャーと対応者はランブック、抑制されたアラート、過去のインシデント、通信チャネルなど、サービスに関する関連情報を整理、検索することができます。

サービスダッシュボードは、運用メトリックとKPIを分析して、組織間の調整を行い、より良いビジネス成果を実現します。

サービスの依存関係(アーリーアクセス可能)は、ユーザーがPagerDutyのサービス間の関係を理解し、問題をより迅速に特定、トリアージ、修正し、チーム全体でより効果的にコラボレーションするのに役立ちます。

可視性コンソール(アーリーアクセス可能)は、サービスパフォーマンスのリアルタイムの統合ビューを提供し、UIが一新された高度なフィルタリングとカスタマイズ可能なレイアウトが含まれるようになりました。このツールは、チームがインシデント対応に積極的なアプローチを取り、ハイパーケアの瞬間に顧客のニーズを満たすのに必要なコンテキストを提供します。

インテリジェントな対応と自動化

チームがまだハンドブックを調べて問題への対応方法を決定している、または手動で過去のインシデントを調べて何が関連しているのかを確認していては、時間やリソースを最大限に活用できません。チームの効率を改善して収益を保護する最も簡単な方法の1つは、価値の低いアクティビティや労力を自動化して削減し、貴重なリソースを他の場所に再展開できるようにすることです。

インテリジェントな対応と自動化のための最新のソリューションは、何が最も重要であるかに焦点を当てたリアルタイム情報を提供します。また、作業の重複を減らし、マシンが手動タスクを自動化できるようにすることで、対応者の負担を軽減します。自動化でより少ないリソースでより多くのことを実行できるようになり、ビジネスの回復力が向上し、収益が保護されます。

イベントインテリジェンスの一部であるモバイルインテリジェントトリアージは、チームによる作業の重複を防ぎます。機械学習は、問題とコラボレーションの履歴レコードを利用し、関連するインシデントをマージすることで、誰が責任を持ち、問題に取り組んでいるかをより正確に特定できるようにします。

インシデントの再開**(アーリーアクセス可能)は、対応者の柔軟性が向上し、インシデントの重複が減少し、問題が予期せずに再発したときに、より迅速な再動員が可能になります。

Rundeck、Ayehu、Pliant、Amazon EventBridgeとのインテグレーションは、ワークフローマニュアル自動化し、レスポンスプレイの一部として対応チーム内のコミュニケーションを改善することができます。

リアルタイムビジネスオーケストレーション

今日、テクノロジーチームは、デジタルサービスに対する顧客の需要の劇的な増加だけでなく、完全に分散されたチーム間でのインシデントコミュニケーションの管理にも取り組んでいます。一方、顧客は依然として完璧な体験を期待しています。インシデントが発生した場合、ビジネス面での対応と技術的な対応を緊密に統合することが重要であると考えています。これは、既存の技術プロセスの自然な拡張である必要があり、手動のプロセスを伴うことや、追加のツールをセットアップをしなくてもいいことが必要です。

当社の最新の機能強化は、サイロを分解し、すべてのチームに適切なレベルの情報を提供することで、重要な瞬間に作業とコミュニケーションをより効率的に行えるようにし、最終的にはより良い顧客体験につながります。

モバイルステータスダッシュボードは、ビジネスの利害関係者に、ビジネスサービスに関する情報更新への外出先でのアクセスを提供します。

ステータス更新ブランディングはブランド化された通知により、通知受信者のエンゲージメントと信頼を高めます。

Salesforceとのインテグレーションにより、チームはワークフローをカスタマイズして適切なリソースを適切なタイミングで動員できるようになるため、デジタルサービスのカスタマーサポートにおけるクラス最高の統一フロントが実現します。標準のSalesforceオブジェクトと統合して、PagerDutyで対応するアクションをトリガーします。

オンコールスケジューリングタイムライン(制限付きアクセス)および* ハンドオフ通知の拡張機能*により、オンコールシフトとチームメンバーが担当するサービスの可視性が向上し、競合、ワークロード、シフトのオーバーライドを管理する簡単な方法がユーザーに提供されます。

Microsoft Teamsとのインテグレーションにより、対応者はチーム内の重要なインシデントの詳細を表示できます。また、新しいインシデントを受任、解決、トリガーするだけでなく、インシデントのメモをすべて1つのインターフェイスから追加できます。

新しいインテグレーションとAPI

詳細が重要であることはわかっており、小さな改善や拡張されたインテグレーションでも、停止に迅速に対応し、最高のパフォーマンスで運用するチームの能力にすべての違いをもたらすことができます。そのため、私たちはSalesforce、Microsoft Teams、Jiraなどのツールとの統合を強化し、テクノロジースタック全体の可視性を最大化して、すでに知っているツールやお気に入りのツールから作業できるようにするために懸命に取り組んできました。さらに、ビジネスサービスとレスポンスプレイAPIにより、主要なデータと機能にアクセスできます。

最新のリリースの詳細については、このリンクをご覧ください。

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

続きを読む
ニュース&告知
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年ウォード・カニンガムが、技術的な複雑さと債務の比較を経験報告で初めて行った。(ウィキペディア)

続きを読む
インシデント&アラート
2018年5月11日  (更新日:2022年3月10日)    |    インテグレーション&ガイド

Icinga 2インテグレーションガイドを追加しました

IcingaはNagiosからフォークしたオープンソースのシステム、ネットワーク監視ソフトです。このガイドではPerlベースのプラグインを使用して、IcingaのインストールとPagerDutyへのインテグレーションを解説します。

詳しくはこちら

2018年4月6日  (更新日:2022年3月10日)    |    インテグレーション&ガイド

IBM Bluemix Integrationガイドを追加しました

IBM Bluemixクラウドプラットフォームは、アプリケーション、インフラストラクチャー、サービスなどで問題を解決しビジネスを推進します。Bluemixは複数のデータソースの統合、システムの拡張、コグニティブサービスの組み込みにより、ビジネス価値を迅速かつ安価に推進します。

詳しくはこちら

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

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

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

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

優先順位をつける

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

再現

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

エスカレーション

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

調査

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

回復

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

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

2017年12月27日  (更新日:2022年3月10日)    |    DevOps

デジタルオペレーションの人間的側面

2017年2月28日の朝のこと、インターネットが広大な範囲で利用できなくなりました。 Slack 、Quora 、GitHub、Trelloなど、数千人が頼りにしている個々のサイトからサービスに至るまでたくさんのものが利用できなくなりました。たぶん、人為的ミスがインターネットの大部分をダウンさせたこの日を覚えているでしょう。AWSの幅広いコンポーネントが機能しなくなりました。一つの停止でインターネットが無秩序になったのは今回が初めてではありませんが、AWSの規模を考えれば、その影響はいつでもありうると感じられます。

多くの場合、危機の最中に重大な事件に対処する人間の側面を忘れることがあります。例えば人々に連絡する難しさや、個人的な連絡先情報を見つけること、複数のタイムゾーンに主要なスタッフが分散していること、会議から人を引き離すことなど、予期しない出来事のため計画していた作業を中断することなどです。

PagerDutyは、こういう時代に存在する最先端のデジタル運用管理プラットフォームです。私たちは、チームや組織が事態が悪化したときにPagerDutyを使いインシデントを先取りして管理することを支援し、チームがやりたい仕事に集中できるようにします。当社の製品は、予期せぬ事態が発生した場合の行動のプラットフォームとして機能します。私たちは主にエンジニアリングとITチームにフォーカスしてきましたが、チームや人をサポートする他のビジネス分野にとってPagerDutyがどんな意味を持っているかも考えていました。

過去には、エンタープライズシステムや人事部門こそが、AWS停止などの事態が発生したときに必要となる重要な人員の詳細を把握するシステムの責任者でした。人事チームはまた、大事な顧客への影響が発生したときに情報を提供する必要があります。私たちの情報の世界の大部分はクラウドにあり、クラウドベースのサービスが利用できない場合に、私たちが仕事をするために必要な重要な情報もそこにあります。私たちが日常的に利用している人気のあるサービス、社内のメッセージングとVoIPサービスは、すべて利用できなくなる可能性が隠れています。これらのクラウドサービスの大規模な停止またはダウンタイムの間、顧客と従業員に情報を提供し、行動と対応を調整することは困難です。

「 私たちの情報の世界の大部分はクラウドにあり、クラウドベースのサービスが利用できない場合、私たちが仕事をするために必要な重要な情報もそこにあります。」

現代の企業には、通常、人の情報をすべて記録したシステムがいくつもありますが、その詳細を最新の状態に保つインセンティブを人々に持たせていることはめったにありません。 PagerDutyのようなインシデントや危機対応の鍵を握るシステムでは、従業員全員が緊密な接触を維持する気にさせる深いインセンティブと日常のビジネスニーズがあります。そのプラットホームを活用して正確な人の情報を得、応答を調整すればスムースになります。

これは、ビジネス全体で高度に採用されているプラ​​ットフォームをHRチームが使用する絶好の機会であり、私たちを行動の心臓部につなぎとめ、妨げにならないように支援します。私たちが最も避けたいことは、素早い返事と行動を求められている最中に、社内で不要な騒音や官僚的な行動を作り出すことです。

従業員に対する環境的、物理的、またはデジタル的な脅威など、人事部門が責任を持つべき危機のことを考えてください。私たちに必要なのは、状況を管理し、重要な情報にアクセスし、サイロになったりワークフローにまぎれずに、あるいは、チケットによって遅くならずに応対できるようにすることです。いつもそうとは見えないかもしれませんが、HR部門は、さまざまな状況になると、しばしば第一級の対応ができる部門です。ベストプラクティスとアジャイルワークフローを使い重大な事態に対処するには、法律、設備、ベンダー、サイバーセキュリティチームと連絡する必要があります。

当社の顧客の多くは、物理的な在庫やサプライチェーンを持たないビジネスモデルを採用しています。デジタルインフラストラクチャがビジネスの主体であり、顧客の経験に大きな影響を与えます。エンジニアリングから法律およびマーケティングに至るまで、インフラストラクチャと顧客体験の成功に投資しています。リアルタイムの顧客への影響がある場合、そのインフラストラクチャ全体を調整できるプラットフォームを使う方が優れた対応ができます。

“ これらのチームが人々と意思決定とシステムの間に持っているスピード、オーケストレーション、相互運用性からはみんなが恩恵を受けられます。”

テクノロジーに焦点を絞ったビジネスでは、エンジニアリングチームや開発チームが使用するプラットフォームやプロセスから学ぶ必要があります。これらのチームが人々と意思決定とシステムの間に持っているスピード、オーケストレーション、相互運用性からはみんなが恩恵を受けられます。各チームが醸成した文化、つまり最前線に至るまでのカスタマーエクスペリエンスの説明責任を果たせること、チームが対策を組織できると信頼すること、非常に高い協調性から学んだこと、そしてDevOpsチーム、ITチーム、顧客が習熟してきたインシデント対応へのアプローチから、恩恵を受けることができます。ビジネス全体がこれから学ぶことができます。

“ HRの専門家としての私たちの責務は、組織の人々のデータおよびオーケストレーションのインフラストラクチャが、インシデント対応の技術インフラストラクチャおよびオーケストレーションと同じくらい効果的だと保証することです。”

さまざまな機能が共有プラットフォーム上で共同して働ける新しい方法を見つけ出すことは私をワクワクさせます。例えばデータを集めることと機械学習を活用して、あるパターンが出現する前にそれを見つけたり、過去の反省から対策を覚えたり改善したりすることができます。 HRの専門家としての私たちの責務は、組織の人々のデータおよびオーケストレーションのインフラストラクチャが、インシデント対応の技術インフラストラクチャおよびオーケストレーションと同じくらい効果的だと保証することです。私たちは社員が顧客のために構築した経験を彼らから借用していますし、オンコールエンジニアの人生をより良くしていくことで、デジタルビジネスに関わる全員の人生をより良くすることができるはずです。

2020年8月17日  (更新日:2022年3月10日)    |    インテグレーション&ガイド

PagerDuty:私たちは常にオンです

COVID-19の急速な感染拡大に伴い、多くの企業が完全なリモートワークに移行しています。顧客、ベンダー、パートナーがオンラインであることは、企業にとってこれまで以上に重要です。PagerDutyでは、従業員、その家族、そして私たちが属するより広い地域社会の健康と安全に主眼を置いていますが、他の最優先事項の1つは、特にこのような困難な時期には、顧客へのコミットメントです。

ご存知の方もいらっしゃるかもしれませんが、現在、全世界の従業員がリモートで仕事をしており、出張を停止しています。これが今のところの新しい常識かもしれませんが、リモートワークは当社にとって新しいことではなく、当社は最初からこのようなシナリオを想定して作られています。

当社の従業員は世界中に分散しており、分散したリモート環境での当社プラットフォームの開発と運用に慣れています。つまり、この事態にもかかわらず、お客様のデジタルビジネスが24時間365日稼働するように、PagerDutyを稼働させ続けることができます。

お客様へのコミットメント

デジタル運用管理のマーケットリーダーとして、当社はこの分野で最大規模、最も信頼性が高く、回復力のあるプラットフォームを提供しています。当社のお客様からは、昼夜を問わず、いつでもシステムに問題が発生したときに、リアルタイムで適切な対応を行うための支援を受けることができるとの信頼をいただいています。では、それをどうやって実現しているのでしょうか。

当社のチームメンバーが分散しているのと同様に、当社のプラットフォームアーキテクチャも分散しています。当社は、複数の物理的なデータセンターからなる地理的に独立したクラウドリージョンに分散して配置されています。当社のアーキテクチャは、お客様からのトラフィックの急増を想定しています。例えば、旅行業界やEコマース業界とは異なり、予測可能なトラフィックパターンには季節性がありません。1万2700人以上のお客様からの予期せぬトラフィック量の増加に最善の準備をするために、必要に応じて動的にスケーリングできるように準備しています。

当社は、「失敗の金曜日」シリーズでカオスエンジニアリングを実践し、お客様のために信頼性と回復力を維持する能力を実践していることで知られています。時間をかけて障害シナリオのシミュレーションに取り組んできた結果、現在では「Failure Anydays」(失敗はいつでも起こる)を実施しています。そう、当社のチームの1つまたは複数が、お客様へのサービス提供の質に影響を与える可能性のある問題を迅速に特定して軽減するために、制御された障害テストをいつでも実施しているのです。2013年以来、当社のプロセスと実践をお客様と共有してきたので、失敗からの学習への投資は新しいものではありません。私たちは、プラットフォームアーキテクチャ、ベストプラクティス、そしてお客様への取り組みを維持するために懸命に努力し続けるチームに適した要素を備えていると確信しています。

ダウンタイムといえば、PagerDutyでは予定されたダウンタイムはありません。あなたの時計は止まることはありません。当社のサービスレベルアグリーメント(SLA)は、お客様に提供する可用性とパフォーマンスの両方をカバーします。メンテナンスのために計画的なダウンタイムを実施することはありません。問題が発生した場合、設定された配信期間内にお客様が通知を受け取ることができるように、プラットフォーム製品に冗長性を持たせています。

多くの企業がリモートワークへのシフトを行おうとしているか、または行っています。そして今、これまで以上にデジタルビジネスが稼働し続けることが不可欠です。PagerDutyはそれを助けるためにここにいます。

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

2020年9月16日  (更新日:2022年3月10日)    |    DevOps

DevOpsトランスフォーメーションに血を通わせる

チェスをしたことがある人なら誰でも、望む結果に到達する方法が1つではないことを知っています。1手目の後には400の違った指し手があり、2手目の後には19万7742の、3手目の後には1億2000万の可能性があり、これらはすべて望む同じな結果に向かって進んでいます。

「これがDevOpsと何の関係があるの?」。真っ当な質問です。チェスの試合にアプローチする方法が1つではないのと同じように、DevOpsの変革に取り組む方法も1つではありません。

では、どのようにしてビジネス、既存のプロセス、従業員に大きな影響を与えることなく、より速いデプロイメント、安定性の向上、コラボレーションの向上を約束する変革を行うのでしょうか?

PagerDutyでこれに成功した企業は、5つの重要な戦術に従っていることがわかりました。

避けられない変化を認識する

今日の企業は、顧客の期待の高まりに応えるためにデジタルサービスを変革していかなければなりません。変化はしばしば不快なものであり、多くの組織は変革の取り組みに関してチームからの反発を経験し、場合によってはメンバーの離職を経験することもあります。多くの場合、DevOpsの「自分で構築して自分がオーナーになる」というモットーは、現実には一歩踏み込みすぎていることがあります。

しかし、それでいいのです。私たちは、多くの組織で抵抗や従業員の離職が起こるのを見てきました。しかし、このシナリオでは、短期的な苦痛は長期的な利益に値します。

あなたと一緒に変革の旅に出たいと思っている人には、この変革を視覚化するのを手伝ってあげてください。既存のプロセスを解体して置き換えるのではなく、小規模なプロジェクトから始めることで、新しいアイデアをテストし、リスクを評価し、すぐに成果を得て、将来の「新しい標準」の感覚を得ることができます。目標は、オンコールを変化の障壁にするのではなく、学び、成長する機会にするために、考え方を変えることです。成功の種を蒔き、早期に小さな成功を得ることで、たとえ変化が避けられないとしても、少なくともそれがより身近なものになるようにしましょう。

DevOpsはゼロサムゲームではありません。加算的です。その意図は、チームのアウトプットとスキルの質を継続的に向上させることです。

ビジョンへの賛同を得る

トップの賛同なしでは、開発者チームがより多くのオーナーシップを持つようになれないということを強調することが重要です。経営陣と開発チームの両方が、将来の状態と潜在的な利益について相互に理解していることが重要です。

小さく始めて、隠れたところでいくつかの勝利を得ることは、2つの目的に役立ちます。

アジャイルアプローチが達成可能であり、開発者とOpsチームにとっても同様にうまく機能していることを示します。周囲の期待を得ると、この成功を紹介して新しいプロセスを実現する開発者のサポートを得られるため、経営陣へのアピールが容易になります。 この成功の成果が、開発側が得たデプロイ頻度の向上やコード品質の向上なのか、運用側が得た重大インシデントの減少やインフラの回復力の向上なのかに関わらず、それが経営陣の賛同を得るための要素であり、目に見えるものであることが重要です。結果を定量化することで、組織が新しいプロセスを完全に実装した場合に、経営陣はこれらの新しいプロセスがもたらすプラスの影響をよりよく理解することができます。

開発チームの賛同を得ることは、乗り越えなければならない大きな障害のように思えるかもしれませんが、最終的には彼らのサポートが最も貴重な資産となります。ビジョンに取り組むことで、役割と責任を調整し、DevOps への全体的なアプローチを作成することができます。

インセンティブの変化を理解する

PagerDutyを使用することで開発文化がシフトし、より多くの説明責任を果たすことができるということを、私たちは顧客からよく聞かされます。では、これは正確には何を意味しているのでしょうか?

従来のOpsモデルでは、開発者とOpsチームのインセンティブは一般的にずれています。開発者は迅速なコード出荷を望んでいますが、コードが本番になってからの信頼性の可視性は低くなっています。一方、Opsチームは、たとえ出荷が遅くなったとしても、信頼性と完璧に動くコードを望んでいます。

DevOps のアプローチでは、インセンティブが変わります。開発者は出荷するコードのオーナーなので、夜中に本番環境で起きた問題で起こされるのを避けるために、品質に焦点を当てようとする意欲が高まります。多くの開発者は、このような理由からオンコールを恐れています。しかし、私たちが発見したのは、アジャイル DevOps アーキテクチャではコードの品質が大幅に改善されているため、実際に電話が掛かってくることは予想よりもずっと少ないということです。

オンコールであることは、オーナーシップを促進し、インセンティブを調整する戦術であり、リアルタイムの学習を促し、品質の向上とより迅速なイノベーションを促進します。

DevOpsを自分のものにする

チームがDevOpsトランスフォーメーションをナビゲートするのに役立つ情報は、そこら中に豊富にあります。しかし、最終的には、DevOpsの実装方法はチームや組織に固有のものであり、ツールやプロセスだけでは実現できません。

DevOpsの原則は単なるフレームワークですが、そのフレームワークをどのようにチームに適合させるかによって、DevOpsは組織独自のものとなります。チームを変革プロセスに参加させ続けることが、最終的な成功への最も重要なステップです。例えば、新しいプロセスについてチームからのフィードバックを収集し、組織全体からの提案や新しいアイデアを求めてフォーラムを開いておくことは、チームの一体感を構築し、チームが新しい変化を積極的に受け入れようとするモチベーションを高めるのに役立ちます。

このようにして、より多くの成功を収めることで、より多くの支持と採用を得ることができ、文化的な変化は有機的に起こるようになります。多くの先行投資が必要ですが、早い段階での投資は、将来的に配当金として戻ってきます。

指標を理解する

DevOpsの利点について説得力のある議論をするには、証明が必要です。既存のプロセスを測定して定量化し、以下のような質問をして、比較のためのベースラインを作成することを確認してください。

新しいコードを本番環境にデプロイするのにどのくらいの時間がかかるか? デプロイの頻度は? バグのトラブルシューティングにはどのくらいの時間がかかるか? 四半期ごとのダウンタイムはどのくらいか?

これらは単なる測定基準のサンプルであり、あなたの組織で測定するものは全く異なる可能性があります。重要なのは、DevOps モデルの「後」の状態のパフォーマンスを評価できるように、「前」の状態の指標を十分に把握しておくことです。

理想的には、DevOpsアプローチにより指標がより良い結果を示すことが望ましいです。例えば、アップタイムの向上やデプロイ頻度の向上などです。通常、問題を確認する平均時間(MTTA)と解決する平均時間(MTTR)に注目しますが、重要な指標はこれだけではありません。

これらの測定基準を取得することで、改善すべき領域をより明確に把握することができます。経営の第一人者であるピーター・ドラッカーがかつて言ったように、「測定できないものを改善することはできない」のです。 DevOpsには幅広い解釈があり、あなたの組織にとって意味するものは、別の組織にとっては全く異なる意味を持つことがあります。DevOpsへの移行は、リスク、忍耐、コミットメントを伴う重大な変化であり、それが早すぎたり、組織全体の賛同を得ずに行われた場合には、不安な気持ちになることもあります。しかし、思慮深いアプローチでは、開発者がオンコールしている状態でDevOpsの世界に移行する際に生じる懸念や成長の痛みの多くを軽減することができます。

2019年11月12日  (更新日:2022年3月10日)    |    ニュース&告知

Slackインテグレーションの一般提供を開始

by Andrew Marshall

PagerDutyの製品管理担当副社長Rachel Obstlerが4月にSlack Frontiersの「Slackによるインシデントの予測、監視、管理」パネルで新しいSlackインテグレーションのベータ版を発表したとき、私たちはこのインテグレーションに関心を持っていただけることを期待していました。

しかし、まだベータ版であるにもかかわらず、すぐにトップレベルのインテグレーション製品になるとは予想していませんでした。そしてこのほど、PagerDutyのSlackインテグレーションが一般公開されました。この記事では、Slack Integrationの主要な機能のいくつかを紹介し、ベータユーザーからのフィードバックを共有します。

どこにいても働ける

現代のOpsやDevOpsチームは、日々ますます多くのツールに依存しています。各ツールにはそれぞれ目的がありますが、必要なコンテキストを取得するためにアプリを切り替えることで、特に複雑なインシデントに対処するときには、素早さと集中力が低下することがあります。PagerDuty for Slackとのインテグレーションでは、PagerDutyインシデントに関するコンテキストの作成、エスカレーション、収集をSlack内から行えます。アプリを切り替える必要がないで、PagerDutyのデスクトップやモバイルインターフェースを使用する場合でも、Slackでリアルタイムオペレーションを管理する場合でも、PagerDutyがこれ1つで利用できます。

Fuzeのインシデント管理マネージャであるCorey Forman氏は、このインテグレーションについて次のように述べています。

「DevOpsチームとエンジニアリングチームがSlackのヘビーユーザであるため、PagerDutyのインテグレーションを各チームチャネルに追加するのは簡単です。アラートを受信し、インシデントを受任し、追加のリソースを通知し、トラブルシューティングの会話を継続する機能は、他にはないこのアドオンの真価です」。

SlackからのResponse Playの実行

Response Playの実行などのPagerDutyのリアルタイム操作機能はSlack内から操作できます。Response Playを実行するPagerDutyの対応チームは、インシデント管理プロセスをSlackアプリの中から素早く簡単に実行できるため、時間を節約し、集中力を維持できます。

ウォールームと他のスラックチャンネルの作成

チームがSlackのようなChatOpsツールに依存するようになった主な理由の1つは、全員が同じページと共通のダイアログスレッドに参加できるように指定されたチャネルを作成できるからです。PagerDutyから新しいウォールーム(または任意のSlackチャンネル)を作成したり、既存のウォールームに参加したりする機能を追加する際には、私達はこれを念頭に置いていました。また、追加のSlackチャンネル対応者をミックスに招待する機能も加えました。チームは、チャネル内のすべてのディスカッションとアクションをキャプチャして、事後レビューに使用できます。

Slack通知に対応

response作業には、豊富なインシデントコンテキストが不可欠です。PagerDuty for Slackでは、関連するインシデント・ファクトとデータ・ポイントをすべてSlack内に表示することで、対応者の武器となります。また、custom incident response playsを実行し、Slack通知から直接対応者を追加することもできます。

WallCraftのAleksey Smirnov氏は「PagerDutyのSlackインテグレーションは、チームに新しいレベルの可視性をもたらします。Slack内でGrafanaアラートを表示できるので、時間を大幅に節約できます」と述べています。

Slackからオンコール情報の表示

最新のオンコールシフトのスケジュールは、インシデント管理計画とインシデント対応に不可欠ですが、スケジュールを覚えていないこともありえます。PagerDuty for Slackのインテグレーションにより、チームはSlackのインターフェースから最新のオンコール情報とタイムラインを表示できます。

「以前は『今夜の当番は誰?』という会話がSlackでよくありました。SlackとPagerDutyのインテグレーションで、誰がオンコールなのかが分かり、Slackを離れずにアラートを知ることができるようになりました」と前出のForman氏は述べています。

Slackからインシデントのトリガー

Slackから直接PagerDutyインシデントをトリガーすることもできます。SlackのようなChatOpsツールは、チーム内やチーム間をリアルタイムでつなぎます。多くの場合、この個人間のやり取りはリアルタイムで問題を特定するのに役立ちます。問題が発生している最中にSlackからインシデントを発生させることができるため、チームはSlackを離れることなく、その時点で規定されたアクションを素早く起動することができます。

組織内の様々なITOpsチームとの接続

現代の企業の多くには、NOCからCentral Ops、DevOpsなどの様々なチームが存在します。PagerDuty for Slackのインテグレーションは、これらの異なる構造のOpsチーム、セキュリティやカスタマーサービスなどの他のチームを共通のインシデント管理フレームワークに接続して、チーム内とチーム間のコミュニケーションを改善します。また、チームはSlackbotを使って、Slackのインテグレーション機能の使用方法を学習できます。

SlackとPagerDuty間のアクセス許可の調整

チームのPagerDuty PermissionのセットをSlackユーザーと同じにすれば、個人とチームが簡単に連携できます。PagerDuty for Slackインテグレーションにより、権限を複製したり再設定する必要はありません。

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

2018年4月18日  (更新日:2022年3月10日)    |    ベストプラクティス

「シフトレフト」:オペレーションがセキュリティを早くプロセスに組み込むために

クラウドセキュリティ会社の運用のプロとして、私はオペレーションとセキュリティを同時に実現できるかどうか―理想的な世界においてそうすべき―ということについて独自の視点を持っています。今日のハイテク業界で見られる共通の問題の1つは、開発プロセスにおいてセキュリティの実現がほとんどいつも遅れているということです。

セキュリティというのは完全に別個の規律なので、それをタイトなDevOpsフィードバックループに組み込むことは難しく思えるかもしれません。しかし、それは可能なだけでなく、思ったほど難しくないということをここで伝えたいと思います。そして、それを普通に行えれば、多くの問題を除去しながら全体的なセキュリティ方針に大きな違いをもたらします。

特に、「シフトレフト」というコンセプトは、チームが以前にデプロイプロセスの後半で行っていたセキュリティ導入プロセスを早期に組み込むことを可能にします。この記事では、これを行う方法について説明します。

「遅すぎる」とはどういう意味か

まず、今日DevOpsプロセスにセキュリティがどのようにもたらされているかを見てみましょう。実際は多くの場合そうなってはいません。これは、エンジニアが準備できたコードをデプロイするとき、セキュリティプロセスはまったく含まれていないことを示しています。もちろん、これを行う開発者は自分の仕事をしているだけです。彼らは製品チームから機能をリリースするという圧力を受けています。できるだけ早くコードを書き上げるために、自分がしなければならないことをやっているだけです。

他のケースでは、セキュリティチームが投入され、門番としてコードが外に出る前にセキュリティレビューを行うことがあります。セキュリティ要員が呼ばれて、欠陥があるかどうかを確認することは良いことです。しかし、最後の最後まで待つことは、継続的デリバリーのサイクルを妨げる可能性があり、今日のアジャイルな開発風土では選択肢とはなりえません。言うまでもなく、それはお互いを対立する立場に立たせることになり、チーム間の緊張につながる可能性があります。

いかにして「シフトレフト」するか

ここ数年、DevOpsチームをよりスピードアップし、継続的デリバリーで開発するよう最適化している組織がますます増えています。しかし、今はセキュリティを織り込む時です。それが「シフトレフト」です。

今までは、

Devチームが開発を行う → テスト → セキュリティチームがチェック(やらないこともしばしば) → デプロイ

というプロセスだったのを、

Devチームが開発を行う → セキュリティチームがチェック → テスト → デプロイ

というように、セキュリティを確保するプロセスを前段階に組み込むのです。それを実現するためのいくつかのヒントがあります。

同じツールを使用する

セキュリティチームがDevOpsチームが使用するのと同じ継続的インテグレーション/デリバリーのツールに精通していることが重要です。Opsのチームにコードの書き方を教えたり、Chefのような構成管理ツールの使い方をDevチームに教えたりと、DevとOpsのチームが協働するのです。今度はこれをセキュリティで行う番です。

Jenkinsは最適な例です。開発者が既にJenkinsを使用してコードのテストやデプロイをしている場合、セキュリティチームにも使うように教えたらどうでしょうか。彼らがセキュリティテストに同じツールを使用すれば、すぐにそれをプロセス化することができます。

もう1つの素晴らしいツールはGauntltです。「Rugged DevOps」という用語についてはいくつか言いたいことがありますが、Gauntltのアイデアは良いものです。Gauntltのサイトで、

「Gauntltは、さまざまなセキュリティツールを提供し、セキュリティ、Dev、Opsチームで連携させて、堅牢なソフトウェアを構築します。これは、グループ間のテストとコミュニケーションを容易にし、実行可能なテストを作成して、デプロイプロセスとテストプロセスに投入できるようにします」

運用と開発プロセスの途中でセキュリティを導入するというコンセプトは基本的に妥当なものです。この方法では、セキュリティがデプロイを遅らせることはなく、問題が発見されたときのフィードバックループを強化できます。セキュリティチームはGauntltを使用してコードを書き、テストして、継続的デリバリーを容易にします。

スタティック解析を試みる

別のオプションは、Veracodeのようなツールを使ってスタティック解析を試みることです。セキュリティチームは、デプロイの前にコードを解析し、潜在的な問題をキャッチしようとします。スタティック解析は、コードを実行することなくソフトウェアを分析します。セキュリティチームは、デリバリーサイクルを中断することなく、潜在的な脆弱性を自動的にチェックすることができます。

インセンティブを合わせる

歴史的に、DevOpsとセキュリティを連携させるための課題の1つは、相反するインセンティブがあることでした。DevOpsチームはコードを素早く書き上げることが勝利です。セキュリティチームは安全なコードができたときが勝ちです。

所有権を提供する

私たちが抱えている一般的な間違いの1つは、開発にアクセスすることさえできないセキュリティチームがあることです。セキュリティチームがコードに対して直接的な所有権を持たない場合、DevOpsサイクルに緊密に統合されない可能性があります。

一方で、セキュリティチームに所有権を与え、コード内の問題を自分で解決する方法を教えると、サイロ化を免れ、よく油の効いたマシンの一部になることができます。たとえば、 Threat Stackはセキュリティ上の問題についてチームに警告することができます。セキュリティチームに問題を解決する方法を教え、構成管理コードにアクセスできるようにすると、システムに直接アクセスして変更を加えることができるようになります。

同様に、Chef は監査とテストのフレームワークであるInSpecというツールをオープンソース化しています。InSpecを使用すると、セキュリティチームは監査サーバにコードを記述し、コンプライアンスを確保できるようになります。これにより、プロセスに対する直接的な所有権が大幅に強化されます。そして、セキュリティチームの開発スキルを向上させることができます。論より証拠です。

これにアプローチする別の方法(特に専用のセキュリティチームを持たない場合)は、セキュリティ上の脆弱性が発生した場合に、バックエンドのエンジニアにコードの修正を担当させることです。エンジニアがコードの健全性に直接の責任を負っている場合、最初からセキュリティに重点を置く可能性が高いです。Threat Stackでは、2人のOpsと10人のバックエンドのエンジニアがオンコールに従事しています。製品に問題が発生した場合、そのコードを書いたのは通常バックエンドのエンジニアリングチームです。このレベルのコード所有は、最初から正しいものを構築するようなインセンティブを彼らにもたらします。

前に進むことは横に行くこと

セキュリティをシフトレフトすると、ビジネス全体の健康状態が改善されます。セキュリティチームが問題をキャッチしチケットを開いたあと、開発者やOpsの担当者が物事を修正するのを待つのではなく、彼ら自身で解決するような力を与えます。これにより、時間と人員が節約できるだけでなく、コードが安全かつ継続的にリリースされることが保証されます。この方程式が他のチームの仕組みやワークフローにどのようにしっかりと統合されているかを、より積極的に理解できるかは皆さん次第です。

上記のヒントは、組織の現実を「セキュリティをシフトレフトする」ための出発点です。セキュリティの多くの側面と同様に、新しいツールを導入するだけでなく、 文化的な変化も必要であることを覚えておいてください。それにより、正しい考え方、インセンティブ、フィードバックループを適切に実行することができるのです。

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

2018年2月5日  (更新日:2022年3月10日)    |    インテグレーション&ガイド

ServiceNowエンタープライズインテグレーションガイドを追加しました

ServiceNow Enterprise は、エンタープライズ環境に高度な自動化とプロセスワークフローを提供する強力な サービスプラットフォームです。PagerDutyの堅牢なオンコールスケジューリング、通知、エスカレーションにより、ServiceNowのワークフローやチケット機能を活用することができます。 このガイドは、ServiceNow IstanbulおよびHelsinkiの認定を受けており、お客様の環境にPagerDutyをインテグレートするプロセスを案内します。

詳しくはこちら

2018年2月27日  (更新日:2022年3月10日)    |    インテグレーション&ガイド

ServiceNow Expressインテグレーションガイドを追加しました

ServiceNow Express は、中小企業向けに高度な自動化とプロセスワークフローを提供するプラットフォームです。ServiceNow Express をインテグレートすることにより、PagerDutyの堅牢なオンコールスケジューリングと通知、エスカレーションにより、ServiceNowのワークフローとチケット機能を活用することができます。

詳しくはこちら

2019年11月20日  (更新日:2022年3月10日)    |    ベストプラクティス

サービスベースとチームベースのアプローチのどちらを選ぶべきか

by Mark Gabbard

インシデント対応プロセスをどのように設定していますか?

PagerDutyのアプローチは、お客様のインフラ、お客様の顧客向けアプリケーション、お客様の製品を総合的に調べることです。これらの項目を「サービス」と表現して、それらを総合した「ビジネスサービス」を構成します。この設定により、チームはサービスをより効率的に管理できるようになり、インシデントが発生したときに、応答者はより迅速にコンテキストを取得できるようになります。

まず、サービスについて説明しましょう。サービスは持続するように構築されており、通常、元々サービスを開発したチームよりも長生きします。言い換えれば、人々は出入りし、チームは常に再編成されるということです。また、サービスを所有するチームの変更は、年に一度だけとか、再編成時にだけに行われるのではありません。特定のプロジェクトでは、わずか数週間で新しいサービスを開始し、古いサービスを継承し、所有権を変更します。

そのため、インシデント対応プラットフォームをチームやサービスに合わせる(さらに悪いのはサービスをまったく提供しない)場合、チームの再編成が発生するたびにインシデント対応のセットアップ全体をやり直す必要があります。さらに、チームの変化に伴い、組織の知識と重要な分析データが失われます。悪夢のようですね。

そのため、PagerDutyはインシデント管理プロセスをサービスに合わせて容易に調整できるようにプラットフォームを構築しました。これにより、チームは時間の経過とともに成長し、変化することができ、サービスの状態とトレンドをより明確に把握できるようになりました。サービスのデリバリーや保守、改善に影響を与えることなく変更を行うことができるため、最終的にはダウンタイムの長期化と顧客への悪影響を軽減できます。

時間の経過に伴うビジネスインパクトやサービスの稼働状態、トレンドの可視性を向上

ほとんどの企業と同じように、インシデントプロセスのセットアップ、運用サポートや構成をチーム単位で行うことができます。つまり、チームベースのアプローチを取ります。これは、ITSM、DevOps、ITOpsのチームが混在し、ビジネスチームと技術チームがビジネスサービスを定義し、他の多くのチームも異なるサービスを持っていることを意味します。

では、チームベースの設定からサービスベースの設定にどのようにして移行するでしょうか。それは、ほとんどの人が考えるよりも簡単です。

最初に、顧客が特定のタスクや成果を実行するためにやり取りする製品やアプリケーションの部分にあたる最上位レベルのビジネスサービスを特定します。たとえば、「ログイン、ショッピングカート、検索」はすべてビジネスサービスです。次に、そのビジネスサービスを支える技術サービスを特定します。各技術サービスは、複数のチームが長期的なメンテナンスに携わっている場合でも、理想的には一度に1つのチームが所有し、開発する必要があります。

ビジネスサービスとそれをサポートする技術サービスを特定すると、さまざまな興味深いことができるようになります。たとえば、チームはビジネス全体で何が起こっているかをリアルタイムで確認できるようになり、単独の問題なのか、より大きな影響を与えているのかをよりよく理解できるようになります。これにより、問題が複数のチームやサービスにまたがる場合に、より適切に連携した対応が可能になります。

イベントが、環境内のサービスから別のサービスにルーティングされても、個々のサービスが環境にどのように反映するか、何が起こっているのかを誰もが簡単に伝えることができます。さらに、対応者はインフラ全体で発生している他のインシデントを把握できます。

例えば、Site Reliabilityエンジニアリングチームに所属していて、サービスが停止したという通知を受信したとします。同時に、データベースチームの別の対応者も同じ通知を受けました。あなたは、複数のサービスに関連するインシデントを表示できるため、それがデータベースの問題であることがわかり、データベースチームが対処することがわかった時点で、あなたによる問題の処理を中止できます。

ビジネスとビジネスニーズに対応

今日のほとんどの企業には、インシデント管理プロセスのためのチームベースの対応セットがあります。初期の段階では対応セットの設定は簡単ですが、成長と拡張に伴い、長期的な管理が実際には困難になります。なぜでしょうか。

このアプローチで生成されたサイロは、対応者に混乱をもたらします。インシデントが発生したときに、協調的で効果的な対応はより困難です。これは、対応者が実際に影響を受けたものを調べるために時間を費やす必要があるためです。何をすべきかを考える前に「サービスAとサービスBのどちらがページに表示されているのか、どの程度の対応が必要か」を考えるべきです。覚えておいてください。ほとんどのチームは少なくとも10の異なるサービスを所有しており、アラートが異なるサービスにルーティングされるようにイベント情報を整理しておくと、何が起こっているのかをよりよく理解するのに役立ちます。

これとは対照的に、技術サービスとビジネスサービスの橋渡しをする、サービス優先のアプローチを採用している組織は、特定のサービスの重要性に関するコンテキストを提供できるため、ビジネスと顧客に明確なインパクトを与えます。また、コミュニケーションのための共通言語を提供し、簡潔で実用的なステータスの変化を知る必要がある人と自動的に情報共有できるようにします(例:サービスAは見積りから現金までのシステムをサポートしているため、インシデントが発生した場合には、SLAがなく必須ではない内部サービスBより高いレベルの対応が必要、などの情報)。

チームベースのセットアップは簡単

前述したように、インシデント管理プロセスの構成と設定にチームベースのアプローチを使用すると、最初は簡単です。ただし、長期的にはマイナスの方がプラスよりも大きくなります。たとえば、チームベースのアプローチでは次のことはできません。

インシデントのビジネスインパクトをリアルタイムで評価する

サービスがアプリケーションの信頼性や安定性に及ぼす影響を分析する

問題の影響範囲を正確に評価する。これは通常、複数のサービスにまたがるので重要

重大なインシデント発生中に通知すべきビジネス関係者を迅速に決定する

加えて、チームベースのアプローチには、チームの変更や再編成に応じて変更を加える柔軟性がありません。さらに、組織の変更がある場合は常にチームとサービスを再構築する必要があります。

最適なアプローチ

インシデント管理プロセスを設定するため、チームベースのアプローチとサービスベースのアプローチのどちらを採用するか決定する前に、「オンコールを設定するのはなぜか」を考えてみましょう。

最も可能性の高い回答は、問題が発生したときに迅速に対応するチームや担当者が必要なため、ということです。また、多くの企業では、チームファーストのアプローチで構成を設定しています。これは、チームがあり、全員がオンコールローテーションに参加していることを確認する必要があり、この方法だと簡単に設定できるからです。

誤解しないでほしいのですが、チームは非常に重要です。しかし、インシデント管理の設定とサービスのセットアップを最初に行うことをお勧めする理由は、それによって次のことが得られるからです。

サービスの健全性を理解し、プロセスを改善するために必要な可視性

ホットスポットを特定するためのトレンドに関する洞察

どのチームがどのサービスをサポートしているかを簡単かつ迅速に確認する能力と、複数のチームを通過して問題のサービスに到達する前にそれらのレイヤーを理解する能力

結局のところ、企業が本当に気にしているのは、ビジネスを遂行できること、そして、迅速に対応する必要がある影響を与えるあらゆることです。そのための最善の方法は、サービスベースのアプローチを使用することです。サービスベースのアプローチを使用すると、何に取り組む必要があるのか、どのように優先順位を付ける必要があるのかを理解できるようになるため、問題のサービスを探すためにいくつものチームのレイヤーを掘り返すことで時間を無駄にすることがなくなります。

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

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を最適化するための強固なフレームワークを構築する上での最初の出発点になることを願っています。

<  123456789101112  >