Blog
ブログ

2017年12月28日  (更新日:2022年3月10日)

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

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

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

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

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

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

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

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

素敵なJavaScriptはある?

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

同期 vs. 非同期

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

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

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

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

判定

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

引き継ぎ

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

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

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

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

オンコールのシャドー中に驚いた5つのこと

シャドーイング( 訓練のためインシデント対応を見学すること )中のコールエンジニアは、医師の肩越しに開腹手術を見ているような感じがします。精密さとスピードが最優先事項であり、間違いは深刻な結果につながります。私はPagerDutyエンジニアリングチームのオンコールローテーションにシャドーオブザーバーとして1週間参加しました。

オンコール中、私は同じエスカレーションポリシーで、他のすべての人たちと同じように通知を受けました。エンジニアが緊急でセンシティブな状況に立ち向かうため、Slackで起こされると私も起こされます。私はストレスが人々を悪い状況に追い込むと予想しました。ところが、驚いたことにそれは完全に間違っていました。

コールは睡眠、食事、シンプルな文章は、何時間ものストレスを乗り切れるようにします。

思考、そしてほかの多くのものを中断するために鳴り響き、チャットチャンネルは一晩中炎上と対応を知らせるメッセージを流し続けました。オンコールの責任とストレスに押しつぶされそうなのに、エンジニアが見せる優しさ、助け合い、ユーモアに私は驚かされました。

励まし

シンプルな文章は、何時間ものストレスを乗り切れるようにします。

初日のシャドーイングの午後遅くに、私は最初の通知を受けました。私はSlackのチャンネルを見て、問題の調査が完了したのを知りました。チームは直ちに新しいマシンを停止し、再配置をしました。トリアージと診断の混乱の中で、そのオンコール担当者が私と同じく新人だと知りました。私たちはどちらもまだ1カ月足らずの新米でした。彼はこれまで一度も遭遇したことのない問題を修正していました。

夕方までに事態は回復しました。長い1日を終え、人々は家に帰って行きました。それでも、ベテランのエンジニアPがチームメイトKの応援に入っていました。

6:14 PM (P)すべて終わった?

6:15 PM (K)まだ、ホストを再起動してるところです。すべてがスムーズに進んでます

6:18 PM (P) その調子だ! 俺達はこいつのために半日つぶしたんだ

このような仲間の励ましは、プロジェクトに新しく加わった人、新人社員、新人エンジニアに自信をもたせます。シニアエンジニアからの励ましは経験の少ないエンジニアに質問する勇気を与えます。質問は新人がエキスパートになるための第一歩です。「その調子だ!」の一言は人々に力を与えます。

謙虚さと感謝

この初心者オンコールエンジニアは、その励ましにすぐ反応しました。彼は自分を助けてくれたシニアエンジニアに短い言葉で謙虚さと感謝を示しました。

6:21 PM (P)本当にあなたとMがいなければダメになるところでした。勉強になりました

Kが彼を助けた別のチームメイトの名前を挙げたのが嬉しかったです。DevOpsのエンジニアリングチームは、チームメイトを高く評価しています。彼らが今開発しているソフトウェアが明日、地獄のオンコール嵐を起こさないため、互いに頼り合っています。誰も常にすべてのことを知ることはできません。彼らは常に互いから学び、お互いに助け合わなければなりません。

上の例では、謙虚さと自己嫌悪の間の細い境界線が見えました。エンジニアは「学ぶことがとても大事」と述べています。この態度は「こんなことは絶対自分ではやりません」や「私にはこんなこと全部分かるわけないでしょう」とは異なります。謙虚で感謝の気持ちがあれば、チームメート同士の信頼を築けます。自己嫌悪は迷いと不安を引き起こすでしょう。

軽薄さとたくさんのGIFファイル

オンコール待機中は(幸せなことに)退屈でもあります。オンコールに入る予定が分かっていることはストレスを軽減してくれますが、それでも常に不安があります。幸運なことに、インターネット上のGIFファイルは、ストレスに満ちたオンコールシフトをユーモアで支えてくれます。

PagerDutyはユーモアの文化とカスタムGIFに特別な情熱を持っています。3つのタイムゾーンと2つの異なる国に分かれているこの楽しくてちょっとおバカなチームを観察するのが私は大好きです。オンコールでない人々がいつも明るいことに気づきました。

どうすればオンコールをよりポジティブにすることができるか

あなたがオンコールでない場合でも、チームと共にあれ 応援しよう。特に新人を 挑戦やリスク、時間のかかることを肯定する 感謝をもってあなたに直接影響を与えてくれた人々に接する。チームが将来どのような強みを持つか理解するのに役立つ ひょうきんに振る舞う。皆笑うのが大好き

たくさんの問題解決と心労を経験しましたし、他人が週末や夜にもオンコール待機をするところも見ました。そのまっただ中で、チームメイトが示す小さなジェスチャーが、あなたが1人ではないことを思い出させてくれます。

空が落ちてくると思うような時は、互いに品性ある振る舞いをすることが助けてくれるでしょう。

続きを読む
ベストプラクティス
2017年12月27日  (更新日:2022年3月9日)

インシデントの経験を事後検証で最大活用

インシデントを経験した後 のポストモーティム(事後検証。post-mortem またはpostmortem と表記される)に 何をします? 簡単な質問のように見えるかもしれません。 結局のところ、インシデントの処理の最後のステップとして事後検証を考えるのは簡単です。

しかし、そうではありません。 多くの点でインシデントのポストモーティムで何を検証するかは、ポストモーティムをすることと同じくらい大事なんです。以下、理由を説明し、事後検証が終わったあとに何をするべきか、そのヒントを提供します。

なぜポストモーティムするの?

しかし、この質問の意味を考える前に、より根本的な質問、つまりポストモーティムの機能とは何か、そしてそれには何を含めるべきかを検討する必要があります。

ポストモーティムは基本的に以下の役割を果たします:

インシデントとその原因および関連する兆候、解決策、将来の参考になる影響の記録を提供する。技術的問題を将来理解するためと、事件から生じる法的または行政上の懸念の解決の両方にとって重要になり得る。 事件を引き起こした基本的な技術的問題を分析し解決するための基礎として役立ちます。 インシデント対応プロセスを理解し改善するためのフレームワークを提供します 。

これらの基本的な役割をサポートするために、ポストモーティムにはインシデント、対応、解決の記録が含まれていなければなりません。 また、インシデントの根本原因の分析 、インシデントの範囲とその影響の説明、根本的な問題の解決、対応プロセスの改善、および/または将来のインシデントの影響の最小化のために適切な推奨事項も含める必要があります。

理解したあとに、責めないこと

大事な注意点ですが、ポストモーティムを責任追及の手段にしてはいけませんし、企業や組織のポリシーに点を付ける手段にならないように注意してください。必要ならば、事後検証から責任追及を分離するためにインシデント関連の問題を議論するために別のプロセス(すなわち、部門内での非公式で司会を立てた議論)を設定してください。

一方ポストモーティムでは、インシデントを起こす背景になった可能性のある、または対応中に明らかになった、技術的または組織的問題についての正直な議論が含まれるべきです。 技術や反応プロセスの改善に重点を置くべきであり、個人やチーム、あるいはその仕事の欠陥に置くべきではありません。

ポストモーティムはいつ必要?

すべてのインシデントでポストモーティムをする必要はありません。 軽度の運用上の問題や、よく原因が分かっており簡単な解決策があるインシデント、そしてダウンタイムやデータの消失が起きなかったインシデントには、ポストモーティムが必要ない場合があります。

ポストモーティムが必要な状況の例をいくつか示します。

データや生産性の低下、または顧客のアクセスにつながるインシデント シャットダウン、再ルーティング、以前のソフトウェアバージョンへのロールバック、および/または解決のための長期のアクションが必要だったインシデント 適切な監視やアラートシステムがあったのにうまく検出または処理されなかったインシデント 根本原因が不明、あるいは予想を超えていた、または今後も発生が疑われるインシデント システムの動作に広範囲の影響を及ぼす可能性のある、アプリケーションアーキテクチャや技術の根本を含むように見えるインシデント 回答や解決プロセスに深刻な問題や不備があったインシデント

ポストモーティムは学習を容易にする

ポストモーティムを価値あるものにするにはその書き方を、長期的な問題の分析、解決、防止を担当する人々が読みやすくかつ理解しやすくする必要があります。

これは、例えば、問題やその解決を抱えているチームや部署は、ポストモーティムの記録を読むことを読み、さらに結果として適切な次のステップを決定するために、できるだけ早く議論に参加することを要求されているからです。 どうポストモーティムの資料を流通させて、それらを読んだあとの行動にどう導くかという実際のプロセスは、もちろん、あなたの組織の構造と経営理念に依存します。

ポストモーティムの基本要素

ポストモーティムを書いたり読んだりするときには、次の3つの重要な分野があります。

根本的な原因

ポストモーティムは必ず根本原因の説明を含むべきです。根本的な理由が既に分かっていても、ささいなことであっても。ささいな原因ではない場合は、問題の実際の根本原因を正確に特定し、それを修正する必要があるかどうかを、原因の分析に含める必要があります。 根本原因を正確に特定できない場合は、将来の特定につながる可能性のある情報を含める必要があります。

例えば、インシデントの解決の過程で、その問題が多量のレガシーコードを含むモジュールで生じたことが明らかになったけれども、そのモジュールよりも下の部分にある根本原因を特定できなかったという場合でも、その事実を根本原因の分析に含めることが重要です。インシデントと関連してレガシーコードを特定したという事実の記録は、インシデントの解決だけでなく、後の調査で置き換える必要のあるコードを特定することにおいても価値があります。

対応

ポストモーティムには、対応プロセスの完全な技術的説明が含まれていなければなりません。 また、そのプロセスの相対的に見た成功または失敗の説明と分析も含める必要があります。 これは誰の責任も問うことなく実施されなければなりませんが、対応プロセスまたはそのプロセスの実施中の明らかな失敗や弱点を明確に示すべきです。 これには、対応チームメンバー間の責任分担、対応チーム内の連絡、または対応チームと他のステークホルダーとの間のやり取り、特定の対応プロセスの問題が含まれます。

対応プロセスの失敗は、技術的または組織的なものに及ぶ可能性があります。インシデントの解決中にシステムやアプリケーションが利用できないことを、その影響を受ける部門やユーザーに伝えられなかったというような、簡単なことが含まれます。 2つのチームのメンバーが協調せずに同じタスクを実行してしまったり、誰も必要なタスクを実行しなかったために、結果として解決に時間がかかりすぎた場合は、ポストモーティムの中にはチーム構成やコミュニケーションの潜在的な問題を示す注記を入れておく必要があります。

被害の影響範囲の確認と制御

ポストモーティムには、データの損失、生産性の低下、ユーザーアクセスの中断など、インシデントによって引き起こされた損害の程度を明確かつ正確に記述する必要があります。 この被害を限定あるいは緩和するために取られた措置についての説明と分析を含めることも同様に重要です。 ダメージコントロールは、技術的なインシデント解決とは別のプロセスとして考慮する必要があります。 インシデントの種類、被害の種類、および組織の構造によっては、カスタマーサービスの責任である場合や、ビジネス内の他の部門のアクションアイテムが必要な場合があります。

ダメージコントロールは、似たようなインシデントを将来どう処理すべきかに直接または間接に影響する可能性があるため、ポストモーティムの一部に入れておく必要があります。 例えば停電により航空会社のフライト予約システムが停止した場合、そのダウンタイム中に予約を処理するための代替システムを導入することを優先する必要があるかもしれません。

恥と思わず、金と思え

ポストモーティムを最大限に活用するための鍵は、これがアプリケーション、インフラストラクチャ、および対応プロセスの改善のためのロードマップであることを理解することにあります。 各ポストモーティムは、システムの動作方法とインシデントの処理方法を改善する可能性があります。 ポストモーティムを恥とか何らかの失敗の徴候として扱うのではなく、これは将来の金になる貴重な機会だと考えるべきです。

PageDutyは、業界のベストプラクティスを共有し、ポストモーティムのテンプレートを含む完全に無料のポストモーティムハンドブックを提供します。 あなたのチームが問題にできるだけ簡単に対応できるように、自分のポストモーティムプロセスを正式化するのに役立ちます。 PureDutyプラットフォームの一部であるポストモーティムは、自動化されたタイムライン構築、コラボレーティブな編集、実用的な洞察など、 14日間の無償体験版にサインアップし、ポストモーティムのプロセス全体を合理化します。

続きを読む
ベストプラクティス
2017年12月27日  (更新日:2022年3月10日)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

続きを読む
DevOps
2017年12月26日  (更新日:2022年3月9日)

オムニチャネルで成功しているリテーラーのDevOpsを学ぶ

ウォルマートのようなリテーラー( 小売業者)の増加に伴い、eコマースとリテーラーの間の戦いが収束しつつあり、Amazonのようなeコマース企業の多くはオフラインでのプレゼンスを確立しています。この2方向の展開をサポートするため、リテーラーとeコマース企業は、優れたオムニチャネルカスタマーエクスペリエンスを提供することを目指しています。

リテールの世界のオムニチャネル

顧客は、店舗内、Webサイト内、モバイルアプリ内、またはソーシャルメディア内の全チャンネルでシームレスな体験ができると期待しています。世界最先端のリテールブランドはトレンドに乗っており、たくさん成功事例があります。以下は、オムニチャネルのリテール体験を提供しているブランドの好例です:

ディズニー:ディズニーランドでの休暇を計画するのは大変です。しかし、ディズニーのWebサイトやモバイルアプリのおかげで、レストランや観光スポットなど、休暇全体をオンラインで計画することができます。また、各アトラクションの待ち時間を知ることもできます。

スターバックス:スターバックスの特典カードを使えば、コーヒー代でキャッシュを使い切ることはありません。モバイルデバイスから簡単に特典カードを取り出して、いつでもカウンターで使えます。

ノードストローム:ノードストロームは、顧客がiPhoneアプリで行う注文を店内のスタッフが補助することで、優れたカスタマーエクスペリエンスを提供しています。各スタッフはアイテムの在庫を確認でき、特定のアイテムが在庫切れの場合、すぐにiPhoneで予約して顧客の家に届けることができます。顧客はオンラインで商品を購入して店頭で持ち帰ることもでき、返品も簡単です。

これらのチャネルでのエクスペリエンスをサポートするためには、深くよく統合されたバックエンドと、一貫したフロントエンドインタフェースが必要です。しかし、これは以前よりもずっと簡単になりました。従来のインフラストラクチャ、ツール利用、そして開発プロセスを放棄して、リテールアプリケーションを構築するための最新のDevOpsアプローチに移行すればよいのです。顧客は絶えず新しい機能や体験を求めており、そのために頻繁になる更新は、安定性を損なうことなくアジャイルさと正確さを最大化する方法で展開する必要があります。これは、デジタルチャネルと物理チャネルをシームレスに統合したエクスペリエンスを構築するために不可欠です。何千もの日常的なやりとりは破綻を生じやすく、また、人気ブランドはサイバー攻撃の目標とされやすいです。何百万人ものユーザーをサポートするためには堅牢なシステムが必要です。システムの可用性とセキュリティを確保する必要があります。これは簡単な仕事ではありません。

いかにしてDevOpsチームがオムニチャンネルリテーラーをサポートするか

インフラストラクチャ層から始めて、アプリケーションスタックまで移動し、オムニチャネルのリテールアプリケーションを構築する際に、DevOpsチームが留意べきことを理解しましょう。

クラウドに移行する

モバイルは、オムニチャンネルのリテールを考える際に最も重要なメディアです。これは、顧客にアプローチする最も個人的かつ強力なチャネルです。どこにいても、お客はあなたの会社とやりとりして、都合のいいときに買うことができます。しかし、ほとんどのリテールアプリは、過去に使われていたクライアントサーバモデルをベースにしていて、現代の最先端の消費者をサポートすることはできません。複数のデバイスやモバイルオペレーティングシステム用のアプリケーションを構築するには、クラウドテクノロジーを活用する必要があります。しかし、いくつかのクラウドツールをあなたのレガシーなスタックに投入するだけでは足りません。AWS EC2などのクラウドサーバでアプリケーションを実行したり、AWS S3などのブロックストレージにデータを格納したり、Sauce Labsなどのクラウドベースのテストプラットフォームを使ったり、Prometheusなどのクラウドネイティブな監視ツールを使ったりする場合は、全システムをクラウドで稼働させるか、少なくともそこへの移行を開始しなければなりません。

マイクロサービスモデルにゆっくりと移行する

マイクロサービスは、単一のモノリシックなアプリケーションを、小規模なクロスファンクショナルチームによって開発・管理される小さなサービスに分解するアプローチです。このタイプの複合型のシステムにより、新しい機能をより早くリリースできます。さらに、あるサービスに障害が発生しても、システム全体をダウンさせることはありません。しかし、マイクロサービスへの移行は、一度に1ステップで行う必要があります。最初のバッチが安定した後に、いくつかの機能を切り分けてください。マイクロサービスアプリは、従来のツールセットを使用する場合に限り、管理が難しくなります。幸いにも、DockerやKubernetesのようなコンテナ技術は、マイクロサービスの管理を容易にしています。

VMからコンテナへの切り替え

クラウドへ移行することが最初にやるべきことです。クラウド内にもう移行していても、アプリをコンテナで実行することが重要です。マイクロサービスモデルに移行すると、サーバインスタンスごとにハードウェアハイパーバイザとOSのオーバーヘッドがアプリのパフォーマンスを低下させます。マイクロサービスアプリケーションを拡張するには、コンテナにコードをパッケージ化する必要があります。コンテナ化すると全く新しいツールセットを使うことになります。たとえば、Kubernetesのようなオーケストレータを活用して、数千のコンテナを管理する必要があります。幸いなことに、コンテナ周辺のツール事情は昨今急速に成熟しました。今日、多くの世界クラスのアプリは、コンテナを使用して確実かつ安全に稼動しています。業界は、クラウドネイティブコンピューティングファウンデーション(CNCF)が認めた標準規格を整理統合しているところです。

分散データストア

インシデント管理でシステムを保護する

現代のマイクロサービスベースのコンテナ駆動型システムでは、多くのパーツがあり、これらのパーツはしばしばフェイルします。DevOpsの呪文の「早く進んで前向きに失敗する」とは、これらの失敗にすばやく反応し対処できる必要があることを意味します。パフォーマンスとセキュリティの両方が、オムチャンネルのリテールアプリの最大の課題です。サイバー犯罪者は多数のユーザーを持つアプリに引き寄せられますが、リテールアプリは名前、住所、クレジットカード情報などの価値のある重要なユーザーデータを数十億単位で持つことが知られています。システム障害やサイバー攻撃から守るには、データポイントを集中管理し、問題に応じて適切な対応者をリアルタイムで把握するインシデント管理システムが必要です。

大規模なDevOpsチームでは、重要な通知が失われる可能性があるため、適切なメッセージが適切な人に届くようにルーティングシステムが必要です。インフラストラクチャの複雑さが増し、大量のデータを処理する必要があるため、機械学習を活用してデータを理解し、重要なポイントに人々が集中できるようにするソリューションが必要です。オムニチャネルリテール向けのインシデント管理ツールは、システム全体にわたる監視、チケット発行およびその他のデータソースを相互に関連付け、集中化することができます。最先端のインシデント管理プラットフォームにより、疑わしいパターンを特定し、インシデントがエスカーレートする前に適切な人材を確保できます。

オムニチャネルのリテールは単純ではないので、完璧なシステムを構築するためには数年以上の時間が必要です。ただし、ここに記載されている方法とツールは、DevOpsチームにオムニチャネル体験を提供するための手がかりを与えることになります。クラウドへの移行、マイクロサービスの活用、コンテナの採用、データストアの分散化、またはインシデントの予見的な管理など、次世代のコンピューティングテクノロジーが今や利用可能です。リテールビジネスに必要なのは、計画を立て直す準備を整えた開発チームだけです。

続きを読む
DevOps
2017年12月26日  (更新日:2022年5月19日)

現代のインフラストラクチャに真のフルスタック可視性を

「フルスタックの可視性」とは?

ツールのベンダーが「フルスタックの可視性を提供します」と宣伝していることがありますが、これが何を意味しているか分かるでしょうか。ツールが違えばどう可視化するかも違います。理由は、可視性がITインフラストラクチャの構成方法に依存するだけでなく、あなたが何が見たいかにもよるためです。極論すればフルスタックの可視性は、ツール、アプリケーション、システム、サービス、および全体的なインフラストラクチャの状態を一覧できるようにすることです。

近代的なインフラ

まず、現代のアプリケーションとサービスをホストするフルスタックインフラストラクチャのタイプを特定してみましょう。以下は、現代のインフラストラクチャに見られる最も一般的なコンポーネント要素です。これらは、仮想デバイスと物理デバイスのミックスとしてオンプレミス、クラウド、またはハイブリッド環境でホストされる場合があります。

現代のインフラストラクチャコンポーネント

アプリケーションとツール オペレーティングシステム ミドルウェア ネットワーク データベース ストレージ Webサーバ 演算装置

これらのインフラストラクチャコンポーネントはすべて、膨大な量の構造化データと非構造化データの両方を生成します。この指数関数的に急増するデータの量と多様性はITOps、DevOps、開発チームに挑戦を突き付けます。つまりシステム、アプリケーション、サービスの可用性を高く維持し、最適なパフォーマンスを発揮させるためにカギとなる情報を収拾し解釈し、実用的な洞察を抽出することを要求します。

以下は、今日の組織がインフラストラクチャとアプリケーションのパフォーマンスを自動化するために採用しているツールの例です。これらのツールのそれぞれは、インフラストラクチャ、アプリケーション、サービス、コードの展開、ビルドなどのステータス、健全性、脆弱性を知らせるデータを生成することができます。

インフラストラクチャ、アプリケーション、自動化ツール

オートメーション/継続的インテグレーション ソースコード管理

構成管理とプロビジョニング リポジトリ管理

ソースコードとリポジトリ管理 プロビジョニング

デプロイ リリース管理

データベース テスト

モニタリング セキュリティ

ビルド クラウドIaaS

マイクロサービスと仮想化

どんな風に可視化できるか

アプリケーションとサービス、システムは、データテーブル、ステータスダッシュボード、パフォーマンスグラフとチャート、ヒートマップ、トレース、システムヘルスメトリック、分析、レポートなど、さまざまな形で可視化できます。フルスタックの可視性は、複数のツールを組み合わせて構成することができます。

監視ツールカテゴリ 人気ベンダー

アプリケーションパフォーマンス監視 New Relic、AppDynamics、Dynatrace

インフラ/クラウド監視 AWS CloudWatch、Microsoft Azure、Google Stackdriver

メトリック Datadog、Librato、Keen IO

ログの監視と分析 Splunk、Elastic、Sumo Logic

既に複数の組織が、上記のさまざまなソリューションを使ってITツールのポートフォリオを構築し、インフラストラクチャ全体で何が起こっているのかを深く調べられるようにしています。

PagerDutyのようなソリューションは、ITポートフォリオ内の全ツールから生成された全イベントとアラートを集中管理して集計し、インシデントへのより適切な対応をリアルタイムで選び出します。

何が起きているのかを示せるツールは世の中にたくさんあって、ほとんどのチームは複数の監視とチケット発行ソリューションに投資しています。ここでもっと重要になるのは、大規模なインシデントがビジネスに影響を及ぼすことを防ぐ、あるいはサービスを復旧するため、専門家に対してよりよく事態を理解するために必要なリソースを提供するソリューションです。

さらにその先へ

PagerDutyでは、真のフルスタック可視性は、インフラストラクチャ、アプリケーション、およびサービスの健全性に関するビューだけではありません。インシデント管理、レスポンスオーケストレーション、システムと運用の両方の効率性の視覚化など、他の重要な部分も含まれているため、チームはSLAを継続的に改善できます。ソフトウェアがビジネスと顧客の経験の中心になるにつれて、ITOps、DevOps、開発者、ITリーダー、エグゼクティブ、ビジネス関係者は、インフラストラクチャ全体で何が起こっているかをよりよく把握する必要があります。

インフラストラクチャの真の健全性を評価する際には、人の役割の重要性を忘れることはできません。ツールは常に仕事をしますが、インシデントはそれらのツールのデータを理解できる人々が解決するのです。PagerDutyのオペレーションコマンドコンソールとインテリジェンスアプリケーションは、多数のベンダーの製品から得た状況の推移を単一のビューにまとめ、どんな重大なインシデントが際立っているか、担当者が取り組んでいるインシデントはどれか、どんなイベントが関連性があるかを包括的に把握できるようにします。そしてインシデントへの技術的、ビジネス的対応の両方を調整します。

PagerDutyを使うと、アプリケーション、サービス、インフラストラクチャの健全性を簡単に視覚化し、インシデント対応ワークフローを1カ所で管理できます。

続きを読む
DevOps
2017年12月26日  (更新日:2022年11月10日)    |    ベストプラクティス

「インシデントコマンダー」に求められるトップスキルとは―養成のプロセスを考える

組織は、オンコール の負担を下げつつ顧客に高いレベルのサービスを提供するために多くのインシデント対応の司令官( 「インシデントコマンダー」)を必要とします。多くの人は上級の技術者(シニアテクニカルリード)だけがその役を担えると思っているので、インシデントコマンダーになりたがりません。しかし、実際には「ソフトスキル」のほうが重要であり、この記事で説明されているような明確なプロセスで、チームは障害対応を主導し調整を成功させる人員を養成できます。*

私はエンジニアではなく、PagerDutyのスクラムマスター(チームのまとめ役)です。私は最近インシデントコマンダーになりました。インシデントコマンダーとして働くには上級の技術者である必要はないということを最初に学びました。*

インシデントコマンダーには誰でもなれる

効果的なインシデント対応には、インシデントコマンダーが意思決定者として機能し、明確に調整をする必要があります。ユニークなスキルが求められる厳しい職務です。インシデントはいつでも発生するので、オンコールの負荷を軽減し、燃え尽きるのを回避するのに十分な数のインシデントコマンダーが必要です。したがって、インシデントコマンダーを養成するプロセスを開発することが重要です。

インシデントコマンダーにとって、組織のサービスが相互にどのようにやり取りしているかという知識は重要ですが、インシデント対応をリードするために高度な技術を備えている必要はありません。インシデントコマンダーは、技術的な回復や調査作業自体は自分では行わず、キーになるソフトスキルを駆使してインシデント対応をコーディネートするのに注力することが重要です。インシデントコマンダーは、ベストな対策を決めるために、今明らかになっている症状と対策案を積極的に聞き取る必要があります。自分が選ぶアプローチには技術的な知識によるバイアスをかけないようにしなければなりません。

インシデントコマンダーには職位や技術的な専門知識に関係なく、誰でもなれます。PagerDutyのインシデント対応マニュアルは、独自のプロセスを形式化するための素晴らしい出発点ですが、座学だけでは新しいインシデントコマンダーを完璧には訓練できません。適切な訓練には実践的な練習が必要です。PagerDutyでは、主要なインシデント対応を導く上で、ほとんどのジュニアチームのメンバーでも快適にサポートできるトレーニングプログラムを開発しました。

主な教育内容

プロセス**:インシデント対応プロセスは、発生した問題を迅速に解決し、SLAの範囲内でシステムを継続稼働させるのに役立ちます。これは明確な役割とコミュニケーションルールを持つ構造化されたプロセスです。優れたインシデントコマンダーは、プロセスに精通しており、混沌とした状況も整理できます。

指示伝達**:インシデントコマンダーは、指示伝達に慣れていなければなりません。タスクを委せるのがあなたの責任なので、職位に関係なく、何をすべきかを相手に伝えることを恐れてはなりません。

時間管理**:インシデント対応中は、時間設定が重要です。タスクを委任するときには、指示を更新するためにいつチェックするかを相手に伝えます。変化する情報に追随したいなら、オンコール中であっても全員への定期的な指示更新のリズムを維持し続けるべきです。

聴取**:体制と方向性は重要ですが、エキスパートのフィードバックに耳を傾け即断即決で計画を変更することも必要です。オンコールに携わる全員からも情報と提案受けられるようにします。あらゆる提案を聞いて、あなたが最終決定をします。

これらを明文化し、プロセス、指示伝達、時間管理、 および聴取をどのように実践するかを正確に話しましょう

当社のインシデントコマンダーは、インシデント対応に関心のある全従業員に対して、営業時間中、常に問い合わせを受け付けています。訓練開始を決めたインシデントコマンダーのタマゴたちはその間に質問をし、プロセスについて学べます。これは、たくさんのインシデントコマンダーが必要な理由を説明する機会であり、みんなが試しにやってみて学ぶのを助ける機会です。

インシデント対応の準備のためにスタッフを訓練する方法を知りたい場合は、次の無料のウェビナーに登録してください。

Introduction to Being an Incident Commander インシデントコマンダーの紹介(英語)

Introduction to Being an Incident Responder インシデントレスポンダの概要(英語)

私たちは就業時間内にプロセスをキックスタートした後、インシデントコマンダーのシャドウスケジュールに訓練生を送り込みます。インシデントコマンダーのやることをシャドウすることで、訓練生は実際にオンコールをしているような気分を味わえます。また、インシデントコマンダーが呼び出されるたびに、一緒に起こされたり自分の仕事を中断されたりします。訓練生はシャドーイングの間にインシデントのコールに加わります。研修生は、「沈黙の観察者」のままにしておいて、最後まで質問をさせずにおくことが重要です。インシデントコマンダーは、事が終わってから訓練生の質問に答える時間を取って、彼らの学習を助け、満足度を高め、コミュニティにサポートされていると感じられるよう計らいます。

研修生がいくつかのコールを聞いた後は、進行中のインシデントのタイムラインを文書化して、スクライブ(記録者) として手伝うように勧めます。より長いインシデントでは、頻繁な引き継ぎが効果的な対応を維持し、燃え尽きを避けるために大きな違いを生むことがわかっています。記録者として参加することはインシデントコマンダー候補がその準備が整う前に手助けを始めるには非常に良い方法です。このようにインシデント対応に取り組むことで、訓練生はプロセスにさらに精通し、自信を高めるのに役立ちます。

いくつかのインシデントコールを聞いて手助けをした後、訓練生には勇気を出してメインスケジュールに入るように促します。彼らは、バックアップインシデントコマンダーのサポートでコールをリードする、リバースシャドウをすることができます。バックアップが対応の全過程で役に立つということを訓練生に理解させてください。新たなインシデントコマンダーにコールを担当させることが重要で、そうすれば彼らは信頼を得られ、さらに自信を深められます。ヒントやリマインダー、励ましなどを添えて個人としてメッセージを送ってください。

新しいインシデントコマンダーが最初のインシデント対応をうまくリードした後は祝ってあげてください。効果的なインシデント対応を導くことは、お客様のビジネスの成功と顧客の幸福に直接影響し、チームの士気を維持するうえでも重要です。互いをサポートし合うインシデント対応者のコミュニティを作ることで、より多くのインシデントコマンダーを育てることができ、オンコールの負荷を減らせるようになります。

オンデマンドのウェブセミナーを使い、インシデントコマンドとインシデントレスポンダのトレーニングを開始してください。

インシデント・コマンダー・トレーニング:主要インシデント時の対応

Incident Commander Training: Leading the Response During Major Incidents

インシデントレスポンダトレーニング:重大インシデント時の成功のベストプラクティス

Incident Commander Training: Leading the Response During Major Incidents

2017年12月23日  (更新日:2022年3月9日)    |    DevOps

ChatOps:チャットボットがインシデントを引き受けます

あなたの考えていることをずっと追いかけていて、あなたの計画の実行を助ける、そんな小さな ロボット があったら素晴らしいでしょう。もし、あなたがインシデント監視インフラストラクチャを担当する管理者なら、それは存在します。チャットボットと呼ばれる彼らは、インシデント管理ワークフローを最適化するための鍵です。

ここではチャットボットとChatOpsを使うのが、DevOps手法を採用している組織にとってとても重要な理由について説明します。

チャットボットの定義

「チャットボット」は人によって異なるものを意味します。大まかに定義すると、チャットボットは、人間と「会話」をするプログラムです。チャットボットはずいぶん昔から存在しています。あなたがAOL(注:America Online)がまだインターネットを支配していた時代に育ったなら、例えばSmarterChildというAIMインスタントメッセージングサービスのためのチャットボットを覚えているでしょう。

インシデント管理とインフラストラクチャの監視の分野でいうチャットボットは、もっと狭い意味を持ちます。彼らは人間の言うことを理解し会話をするだけでなく、人の代わりにアラートを監視しインシデントに対応します。

言い換えれば、この意味でのチャットボットは、SlackやHipChatなどのコミュニケーションプラットフォームと統合され、人間の入力に応答してコマンドを処理するプログラムです。コマンド自体は、多くの場合、バックグラウンドで動作するサーバで実行されていますが、管理者が行う必要があるのは、何をするかチャットボットを教えることだけで、残りは事前に定義された手順に基づいて自動的に処理されます。

チャットボットとChatOps

チャットボットは開発業務におけるツール、プラットフォームであり、ChatOpsと呼ばれます。彼らは開発者と運用チームに以下のような利益をもたらします。

コマンドを実行するための便利なインタフェースを提供する

すでにSlack、HipChatや他のコミュニケーションプラットフォームをすでに使っている場合、なぜコマンドを実行するために異なるインタフェースに乗り換えるのでしょうか。チャットボットならばあなたがコマンドを実行する必要はありません。チャットインターフェイスから直接実行させることができるので、ずっと素早く実行できます。

チーム全体を可視化

あなたがチャットボットとの対話を公開していれば、参加するすべての人があなたが実行したコマンドを確認することができます。これは、あなたのチーム全体を可視化し、チームメンバーが同じコマンドや矛盾したコマンドを実行していないことを確認できます。そして同時に、チーム全体が学習する機会も提供します。

リアルタイムなアクションを促進

伝統的に、チームは集まり、計画を立て、別れて、実行します。チャットボットとChatOpsを使うと、コミュニケーションと操作インターフェースが統合されているので、対話と実行が同時に可能です。重要なオペレーションを実行する前、計画を立てるための時間が要らないとは言いませんが、例えばインフラの障害に対応しているときのように時間が最重要である場合、計画とオペレーションが同時に行えるのは大きな利点です。

チャットボットとChatOps、DevOpsチーム

これらの利点は、ほぼすべてのタイプの組織に有用です。組織がDevOpsチームスタイルのワークフローに移行しつつある現在、これは特に重要だといえるでしょう。

それはなぜか。DevOpsチームの2つの原則は、シームレスなコミュニケーションとオペレーションの俊敏性であるためです。ソフトウェアの継続的デリバリー(と透明性と公開性)を求める場合は、チームメンバー間のコミュニケーションギャップを回避する必要があります。また、インシデント対応時に継続的デリバリーのパイプラインを壊さぬよう、迅速かつ容易に行動できる必要があります。

同じ論理は、監視とインシデント管理にも適用されます。監視チームを継続的に活動できるようにしたい場合、リアルタイムでインシデントを特定し解決するため、瞬時に可視化されたコミュニケーションが可能な手段が必要です。素早いアクションと効率的かつ協調的な方法でチームメンバー間に責任を持たせるための方法です。チャットボットはこのすべてを可能にします。そのため、チャットロボットはDevOpsの世界を席捲しているのです。

2017年12月23日  (更新日:2022年3月9日)    |    ベストプラクティス

インシデント発生時のベストなコミュニケーションの方法

あらゆるビジネスが デジタルビジネス に進化し、ほんの少しの停止時間でも、これまで以上に収益とブランド価値に深刻な影響を与えるようになり、危機に直面した際の効果的なコミュニケーションの必要性が増してきました。これによりサービスを開発・管理する技術チームにより高いプレッシャーがかかっているということですが、さらにデジタルトランスフォームは、ブランドの評判と顧客体験に責任を持つ他の事業部門にもプレッシャーをかけています。

製品やサービスから顧客が最大の価値を引き出せるようにする責任を負うコミュニケーション、マーケティング、とりわけサポートチームを見てみましょう。プレッシャーによって渉外機能に新しいワークフローとベストプラクティスが必要になっています。PagerDutyで私たちが学んだ実践から、これまでに磨いてきた4つのベストプラクティスを紹介します。

  1. みんながオンコール担当

PagerDutyのコミュニケーションチームの一員として、私は技術担当の同僚や他の多くの人と一緒にオンコールの仕事に従事しています。受け取るインシデント通知のほんの一部を見ても、なぜ自動化とインシデント対応プロセスを持つことがスムースな運用に必要なのかを深く理解しています。それが今日のデジタルサービスをうまく稼働させているのです。何かが顧客にインパクトを与えるとき、コミュニケーションチームやサポート、営業、法務、そしてリーダーなど他の部門の関係者は、私たちが顧客と適切なコミュニケーション対応をプロアクティブに取れること、そして時が経つ間に自らのブランドと顧客の約束を守るために正しい対応を効果的にやれるのだということを、知っておく必要があります。

2.サポートと足並みをそろえる

受賞経験のある当社のサポートチームは重大インシデントに遭遇したときには顧客対応の最前線に立ちます。しかしコミュニケーションチームは次のことを理解するために整列して待機しています。

どんなインシデントでなぜそれが起きたのか? どのくらい多くの顧客がどのくらい長く影響を受けているのか? インシデント対応はどのくらい進んでいるのか(まだ調査中なのか解決に近づいているのか)?

インシデント対応プロセスの中では、チームは顧客との連絡窓口(注:カスタマーリエゾン)を必要とします。その窓口担当は、アプリやサービスに起きている障害がさらに悪くなりそうな時に外部と最善の方法でコミュニケーションをとれるよう訓練されている人たちです。

私たちのコミュニケーションチームは、今何が起きていてどんな影響があるのかを正確に理解するために、カスタマーリエゾンと一緒に作業をします。PagerDutyの中では、インシデントに関するSlackチャネルの一部に加え、Stakeholder Engagementという機能で情報の更新を自動化しています。我々は各チームからより抜かれた適切な人の間で協業が進むようタイトなラインを作り、顧客やより広い市場との有益なコミュニケーションが作れるように協力しています。

3.プロアクティブになろう

伝統的なチケットやITSMのワークフローを使っている場合、プロアクティブになる機会を失っているかもしれません。顧客は何か悪いことが起きるのをあなたより前に知ります。例えばソーシャルメディアなどの公開の場やニュースで彼らが気づく前にあなたが問題を修復する機会はないでしょう。コミュニケーション対応の観点からは、外向けに出すメッセージをより早く作れるよう行動するべきです。そうすれば不満のツイートや正しい情報を求める記者からの電話に対応できるようになります。インシデント対応コミュニケーションのこの段階では、傷ついた評判を修復する戦略を立てることが大事であり、理想的には事態を正常化するためにリアルタイムに起きていることを共有すべきです。プロアクティブなコミュニケーションを支援するため、我々は発生しうる危機のシナリオを特定してワークフローを作り、さらにこれまでの経験に基づいて、使うべき言葉を中心に、ベストプラクティスを作成しました。もちろん、危機シナリオは独自のものですが、平和な時に基礎を作っておけば、余裕がなくとストレスが高い戦闘中でも、素早く行動できます。

4.ブランドをリシェイプする

インシデントが解決してもコミュニケーションチームの仕事は終わりません。理想的なインシデント管理のライフサイクルの中で、重大インシデントは必ず事後検証を受けるのです。その中では関係者全員が、何が起こったのか、その対応がどう実行されたのか、今後どのように改善できるのかを議論します。これは学習と改善のための時間です。コミュニケーションチームにとしては、組織全体で協力し顧客や広範なコミュニティの信頼を回復する計画を策定し実行する必要があります。つまり当社のブランドが期待に応えられなかった部分を改善する戦略を実行するのだと考えてもらってよいでしょう。企業としての表明も改訂し、健全な判断を使い今後どうするのかを検討しないといけないでしょう。これはまた、あなたががビジネスに携わっている理由と言行一致を確約するための時間でもあります。ビジネス全体での行動が間違いを正すために必要かもしれません。

今日の、”マイクロ秒単位の時間”に支配され、常時オンが当たり前の世界で成功するためには、コミュニケーションチームは他のチームと一緒にデジタルオペレーションのエクセレンスの追及に”レーザーフォーカス”しなければなりません。これは、これまでと違う覚醒を意味するだけでなく、法外に優れた顧客体験を提供することを心の中の統一目標として、各機能部門を横串した新しい作業とコラボレーションのやり方を意味します。

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

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

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

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

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

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

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

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

  1. ステータスの更新

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

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

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

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

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

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

2017年12月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月22日  (更新日:2022年6月14日)    |    インシデント&アラート

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

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

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

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

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

会社のリーダーシップ

広報

法務

人事

顧客サービス

危機管理

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

会社のリーダーシップ

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

広報

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

法務

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

人事

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

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

顧客サービス

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

危機管理

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

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

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

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

クラウドへの旅、インシデント管理の改善

多くのIT組織は、クラウドインフラストラクチャ の活用はやむを得ずやることではなく、IT組織がビジネスニーズに即応するための最も効果的な方法だと悟りました。

しかし、クラウドには、ダウンタイムの最小化、運用コストの削減、社員の燃え尽き症候群防止など、新たな課題があります。企業がプロセスと手順を新しい現実であるクラウドベースのインフラストラクチャに移行するのに合わせて、これらの課題を解決するためにインシデント管理ソリューションを採用する必要があります。これはハイブリッド環境で運用する大企業の場合、つまり従来型のインフラストラクチャとクラウドベースのインフラストラクチャを混在させて、インシデント管理にもハイブリッドなアプローチが必要な場合に特に当てはまります。クラウドに移行するには時間がかかりますが、それは1回で済むものではありません。

組織がこの新しいパラダイムを受け入れてクラウドに移行する理由と、シームレスなクラウド移行のためにインシデント管理をどのように処理しているのかを見てみましょう。

なぜクラウドに移行するのか

組織がクラウドに移行するには多くの経路があります。クラウドネイティブアプリを担当する開発チームを、プライベートクラウドとパブリッククラウドの様々な組み合わせを担当するインフラストラクチャチームへと移行させ、2つのクラウドを相互接続するためのハイブリッドインフラストラクチャを構築する方法など、クラウドに移行するメリットのいくつかを見てみましょう。

インフラストラクチャ管理の削減**:クラウドサービスを活用することで、従業員は、下位レイヤーのコンポーネントをパッチして維持する必要がなくなり、ビジネス価値を提供することに集中することができます。 アジリティ(俊敏性)の向上**:クラウドインフラストラクチャ上でサービスを更新、追加、削除する機能は、企業が新しい機会に対応するスピードを大幅に加速します。 クラウドネイティブアプリ**:アジャイル開発のプラクティスと継続的インテグレーション、継続的デリバリー、マイクロサービスを組み合わせることで、チームはビジネス機能をスピードとスケールをもって提供することができます。 ディザスタリカバリとビジネス継続性**:クラウドインフラストラクチャのビルトインデータレプリケーション機能を活用することで、迅速なリカバリを目的としたセカンダリサイトの構築が可能になります。時間が経つと、これは複数のゾーンや地域に配置した冗長システムに変わります。 常時稼働**:クラウドサービスは、一般的に24時間365日稼働しており、サービスへの移行以外の余分な労力や人員を必要としません。 設備投資の無償**:クラウドサービスはサブスクリプションベースで機能するため、大きな設備投資が不要で、償却費や減価償却費を払う必要はなく、コストを運用予算に移行できます。クラウドサービスプロバイダは、資本投資を必要とする物理的環境を維持します。 市場投入までの時間短縮**:購買手続きが全くなくてもチームは新しいアイデアのテストを数日間で開始することができます。数週間または数カ月のリードタイムを必要とする従来のモデルとは異なる点です。

クラウドへの移行は、企業がより機敏に対応できる利点があるため、規模を問わず多くの組織にとって合理的です。クラウドへの移行は、やるかやらないかではなく、いつやるかという問題になっているのです。結果として、ITチームはこの新しいパラダイム内でアプリケーションを構築、運用、サポートする方法を学ばなければなりません。

クラウド環境でリアルタイムの可視性を得る

クラウドへの移行の前後にインシデント管理プロセスを導入していないと、問題が発生したときに盲点になり、インシデント対応が遅れることがあります。これらの問題は、ビジネスへのリスク、顧客への影響、および移行プロセスの遅延につながる可能性があります。また、ハイブリッドインフラストラクチャを使用したり、パブリッククラウドインフラストラクチャに完全に移行したりする場合に、これらの弱点を未解決のままにしておくと、実際のインシデント対応に支障をきたすようになります。効果的なインシデント対応でハイブリッドクラウド環境を管理することは非常に重要です。そうすればクラウドベースのアプリケーションで動作しているものをリアルタイムに把握し、移行中または移行後に問題が発生した場合に対処できます。

クラウド移行中のインシデント管理の課題

前述したように、クラウドに移行する際には、次のような新たな課題を克服する必要があります。

クラウドインフラストラクチャプロバイダとの統合と監視

クラウドネイティブアプリケーションを組織のアプリケーションポートフォリオに導入することで、複数のクラウドプロバイダー間でインスタンスを動的に追加または削除する場合でも、すべてのインスタンスを表示、レポートできることが不可欠です。現代のクラウドベースのツールからシグナルを引き出すことが重要ですが、従来のツールからシグナルを引き出せることも同様に重要です。組織がハイブリッド環境に存在する可能性が高いからです。すべてのアプリケーションが同時に移行されるわけではないため、これは移行中に大きなリスクになりますが、既存のサービスやアプリケーションを提供するには、オンプレミスとクラウドの両方のコンポーネントが必要です。

解決策:最新と従来のアプリケーションパフォーマンス管理スイートと、すべてのクラウドインフラストラクチャで使用可能なネイティブツールを理解し、統合できるインシデント管理プラットフォームを用意します。

常時オンは常時サポートが必要だという意味です

顧客は常時オンの経験に慣れてくると、自社のサービスは24時間いつでも利用できると期待しますから、問題を報告するために月曜日の朝まで待たずに声を掛けることを躊躇しません。

解決策:24時間365日のサポートを処理するために構築されたインシデント管理プラットフォームに投資し、監視ソリューションが事前に障害を検出したとき、またはクライアントがインシデントを報告したときに、どのチームに通知するかを知ることができます。その後、インシデント対応のライフサイクルを通してそのチームをサポートします。

クラウドの可視性

クラウドベースのプロバイダーから提供されるサービスが増えましたが、アプリケーション、ミドルウェア、インフラストラクチャからのイベントやアラートに必要な可視性を、顧客が影響を受けたり、あなたのプロジェクトが遅れる前に実現できるようにするにはどうしたらよいでしょうか。

解決策:複数の情報源からの情報を受け取れるソリューションに投資し、問題の影響を調査するチームの能力をサポートします。対応者が適切な情報を持って行動し、ビジネスチームやプロジェクトチームのリスクを最小限に抑えることが重要です。これにより、クラウドの移行ライフサイクルが迅速に回り、高品質なアプリケーションの変更が本番環境に導入されるようになります。

分散した労働力

クラウドにはモバイルフレンドリーなプラットフォームがあり、地理的に分散した複数のオフィスを持つ組織がますます増えていますから、単一の統一されたコミュニケーションチャネルを持つことが重要です。

解決策:従来の電話会議を使っているのか、それともSlackやHipChatなどの最新のコラボレーションソリューションを使っているのかどうかは関係ありません。目標は、あなたが話す必要がある人々を見つけられる場所を1つにすることです。SlackやHipChatのようなツールの利点は、会話を離れずにチャットに情報とアクションを持ち込めるようにインシデント管理と監視ソリューションにフックできる点です。

クラウドの移行の一環として、開発チームやビジネスユニットのニーズに合わせて、同じティアでチームをサポートする必要性を検討することが重要です。サポートチームが、開発者が展開しているものの背後にあって必要なすべてのプロセスとツールを持っていない場合、追加されたすべての複雑なレイヤは、信頼性の高い方法で使えないため、ビジネスにとっては無駄になります。

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

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

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

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

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

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

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

初期対応

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

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

レベル1レスポンス

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

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

レベル2レスポンス

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

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

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

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

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

その他の重要な問題

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

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

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

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

応急策

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

システムダウンの防止

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

情報共有

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

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

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

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

セキュリティスタックに入れておくべき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とインシデントのライフサイクルに関する最良のアプローチを採用してください。多くのツールはユニークな機能を提供しますが、選択したツールが他のツールともうまく機能することを確認してください。問題を検出する際に最大の馬力を発揮できるだけでなく、最も重要なときに指先で適切なデータを取得できるようになります。