DevOpsの効率を上げるため適切なツールを選択する
運用面での成熟は、いくつかの新しい ツール を実装したからといって一晩で起こるものではありません。核となるのは、より良いソフトウェアを提供するためみんながコミュニケーションのサイロを壊せるよう一丸となって文化を変える努力です。個別にツールがあるだけでは十分ではありませんが、スピードと精度を向上させ、コラボレーションを促進するようなオートメーションを適用すれば、ツールが大きな利益をもたらすようになります。
環境に合ったDevOpsツールは、チームの規模やニーズに応じて大きく異なる場合があります。あなたのツールチェーンを構築する方法には正解はありません。現実に、まず私たちが学び、模倣しようとしたいくつかの最良のワークフローやツールはNetflix、Etsy、Dropboxなどの革新的なチームが社内に構築したものだということを告白しておきましょう。
このリストの目的は、ソフトウェア配信ライフサイクルの各段階で最も人気のあるツールをいくつか共有することです。その一部は社内でも使っています。自分のチームのために適切なツールを評価する際にご参考になることを願っています。
計画
何をどうビルドするのか
リリースのすべての単一の依存関係と作業を計画しておくというウォーターフォール型のアプローチはDevOpsに反します。代わりに、アジャイルアプローチでは、ソフトウェアを小さな塊で構築してテストし、顧客のフィードバックを反復することで、リスクを減らし、可視性を向上させることができます。それが私たちを含む多くのチームが約2〜4週間のスプリントでの私たちがリリースを繰り返している理由です。
チームが各スプリントの開始時にアイデアや計画を共有しているので、以前のスプリントの反省からのフィードバックを考慮に入れてチームとサービスが継続的に改善されるようにします。ツールは学習やアイデアを計画に集中させるのに役立ちます。ブレーンストーミングプロセスを開始する際は、顧客リサーチデータ、機能要求、およびバグレポートをそれぞれ対象となる個人を特定し、その人にマップできます。このプロセスでは、物理的またはデジタルの付箋を使用して、共通のテーマをまとめてグループ化し、バックログのユーザーストーリーを構築しやすくします。ユーザーストーリーを特定のペルソナにマッピングすることで、提供される顧客価値に重点を置くことができます。アイデア段階の後、プロジェクトのバーンダウンと毎日のスプリントの進行状況を追跡するツール内のタスクを整理し、優先順位を付けます。
私たちが使っているツール:Active Collab、Pivotal Tracker、VersionOne、Jira、Trello、StoriesOnBoardなど。
コード
いくつかのコードを書いた後に、ステージングに入る前に済ませる必要があることがいくつかあります。 コードをレビューして承認し、バージョンコントロールリポジトリのマスターブランチにマージし、必要に応じてローカルテストを実行します。
トップツール:Github、Bitbucket、Gerrit、GitLab
テストとビルド
今度はコードのビルド、テスト、およびリリースに関連するタスクの実行を自動化する時です。 ビルドが展開される前に、単体テスト、統合テスト、機能テスト、受入れテストなど、生産過程に完璧に押し込めることを確認するために、多数のテストを行う必要があります。 テストは、新しい変更が導入されたときに、コードベースの既存の部分が期待どおり確実に機能し続けるようにするための素晴らしい方法です。 新しいプルリクエストがあるときには自動的にテストを実行することが重要です。 これにより、手動による監視のために見落とされるエラーを最小限に抑え、信頼性の高いテストを実行するコストを削減し、早期にバグを面に出せます。
また、テストが完了したら、マスターの変更を自動的にピックアップし、依存関係のあるものをリポジトリからプルダウンして新しいパッケージを構築するなど、便利な機能を果たす多数の優れたオープンソースツールと有償ツールもあります。
トップツール:Jenkins、GoCD、Maven、CruiseControl、TravisCI、CircleCI
コンテナとスケジューラ
Dockerとコンテナの登場により、チームは新しい仮想化オペレーティングシステムをスピンアップすることなく、軽量で一貫した使い捨てのステージング&開発環境を簡単にプロビジョニングできます。
コンテナは、アプリケーションをパッケージ化する方法を標準化し、記憶容量と柔軟性を向上させ、変更をより簡単にすることを容易にします。 これにより、アプリケーションをどこでも実行することができます。 言い換えれば、物事は、あなたがラップトップで変更を加えたときとまったく同じように、魔法のようにプロダクションで行動します。
トップツール:Docker、Kubernetes、Mesos、Nomad
構成管理
構成管理を使用すると、インフラストラクチャの変更を追跡し、システム構成の単一ソースを維持できます。 バージョン管理とイメージの複製を簡単に実行できるツール、つまりシステム、クラウドインスタンス、コンテナなどのスナップショットを撮ることができるツールを探してください。 ここでの目標は、標準化された環境と一貫した製品パフォーマンスを保証することです。 構成管理は、変更に起因する問題の識別にも役立ち、さらに容量が必要な場合に既存のサーバーを自動的に再現することでオートスケーリングをシンプルにします。
トップツール:Chef、Ansible、Puppet、SaltStack
リリース リリースの自動化
リリース自動化ツールを使用すると、本番環境に自動的にデプロイできます。 自動ロールバック、展開を開始する前にホストに成果物をコピーする機能などを備えた製品を選ぶべきであり、特に大規模な組織の場合は、サーバーインスタンスのスケールに合わせて、エージェントを簡単にインストールし、ファイアウォールを簡単に構成できるエージェントレスアーキテクチャが必要です。
テストに合格したものは、自動的にデプロイされることに注意してください。 ベストプラクティスは、最初に「カナリヤ」デプロイメントとしてインフラのサブセットに展開してみて、エラーが起きなければ全体に展開することです。
多くのチームでは、ボットを使って簡単なコマンドでデプロイするチャットベースのデプロイメントワークフローも使っているため、誰もが簡単にデプロイメントの活動を見たり、一緒に学習することができます。
トップツール:Bamboo、Puppet
デプロイメントを監視する
リリース用のダッシュボードとモニタをセットアップすると、リリースの進捗状況と要件のステータスをハイレベルで視覚化するのに役立ちます。 サービスが健全かどうか、導入前、導入中、導入後に異常があるかどうかを理解することも重要です。継続稼働している統合サーバー上で発生する重要なイベント、例えば失敗したビルドがあるとか、デプロイメントを中止またはロールバックするといった重要なイベントがリアルタイムで通知されること確認しておくことです。
トップツール:Datadog、Elastic Stack、PagerDuty
モニター サーバーの監視
サーバーの監視では、インフラストラクチャレベルのビューが提供されます。 多くのチームでは、ログの統合機能を使い特定の問題をドリルダウンしています。 このタイプの監視をすると、メトリック(メモリ、CPU、システム負荷の平均など)を統合でき、サーバーの健康状態を常に把握でき、アプリケーションが影響を受ける前に(そしてお客様がそれに気がつく前に)に問題に対処できるようになります。
トップツール:Datadog、AWS Cloudwatch、Splunk、Nagios、Pingdom、Solarwinds、Sensu
アプリケーションパフォーマンスの監視
アプリケーションパフォーマンスの監視では、Webサイトなどのアプリケーションやビジネスサービスのパフォーマンスと可用性をコードレベルで把握できます。 これにより、パフォーマンスメトリックを迅速に理解し、サービスSLAを満たすことが容易になります。
トップツール:New Relic、Dynatrace、AppDynamics
対応と学習 インシデント解決
監視ツールは豊富なデータを提供しますが、リアルタイムで問題に対して正しい行動をとることができる適切な人物にルーティングされないならそのデータは無駄になります。ダウンタイムを最小限に抑えるには、問題が検出されたときに適切な情報が通知され、トリアージおよび優先順位付けに関する明確なプロセスが確立されていることが大事で、それらによってようやく効率的なコラボレーションと解決が可能になります。
1分に数千ドルのコストがかかるようなアプリケーションとパフォーマンスの問題が起きた場合、適切な対応を調整することはしばしば非常にストレスですが、混乱することはありません。火事の最中に、連絡先の住所録を取り出して、コンファレンスブリッジに適切な人を選ぶ方法を探すのに30分も無駄にするのは望ましくありません。
PagerDutyはエンドツーエンドのインシデント対応プロセスを自動化して、主要な顧客に影響を与えるインシデントや日々の運用上の問題の解決にかける時間を削減できます。 PagerDuty社内では、エンジニアリングチーム、サポートチーム、セキュリティチーム、エグゼクティブなどみんなが、自社製品を使い、ITやビジネスの中断への対応策を調整して準備しています。柔軟性を持って私たちはオンコールのリソースを管理したり、実行不可能なものを止めたり、関連するコンテキストを統合したり、適切な人やビジネスのステークホルダーを動員したり、自社が推奨するツールと協働で対応にしたりしています。自分が戦闘中に何をどうに見たいかを簡単に設計できるとしたら、あなたももっと安心できるでしょう。
私たちが使っているツール:PagerDuty、HipChat、Slack、Conferencing tools
学び、改善する
対応が終われば、インシデントはプロセスとシステムをより弾力性を持って改善する方法を理解する重要な学習機会を提供します。 DevOpssのCAMS(文化、オートメーション、測定、共有の頭文字)の支えによって、インシデント対応とシステム性能のメトリクスを理解し、継続的な改善の目標に向けて、成功と失敗を共有するオープンな対話を促進することが重要です。
ポストモーティム(事後検証)の手順を合理化でき、解決すべき事項に関するアクション項目の優先順位付けを目的にポストモーティム分析を実行できるソリューションを探してください。あなたはきっと製品の使用状況や顧客からのフィードバックを理解するのに役立つツールを使い、ビジネス目標と顧客経験のメトリクスに関連するサービスがどのくらい成功しているか測定したいと思うでしょう。より良い製品とより幸せな顧客のために、システムと機能の両方の改善を正確に計画して優先順位を付けられるよう、すべてが次のスプリントに組み込まれるのです。
私たちが使っているツール:PagerDuty、Looker、Pendo、SurveyMonkey
繰り返しますが、ツールに投資するだけでは、モノリシックアーキテクチャーからマイクロサービスアーキテクチャに移行することはできません。また、セルフサービスのデプロイメントを1日に何回も実行できるチームは幻のままになります。 しかし、適切なツールとプロセスで新しい文化へのシフトを強化することで、ソフトウェア配信を最適化し、継続的に改善し、それを担当するすべての人の間でシームレスなコラボレーションと信頼を実現することができます。
以上を参考に、あなたのための適切なツールを探究し、見つけることに成功してほしいです!全員参加の機運を最大限に高めるために社内で使用すべきツールや、DevOpsのベストプラクティスを加速する方法について詳しく知りたい場合は、これらのリソースをご覧ください。
ベストプラクティス
ブランドと評判を守るインシデント対応
顧客は、価値観 を共有していると 感じる企業に忠実です。予期せぬ出来事が企業を襲ったとき、結果として生じた激動がブランドを危険にさらします。航空会社の災難や、テクノロジーシステムを巻き込んだ性能に関するインシデントなど、これらの瞬間は、顧客にサービスする能力を低下させることで、顧客体験に影響を与えます。顧客にブランドへのアクセスを提供するデジタルチャネルが増えている状況で、今日の現実は、世界中がポリシーや行動を監視する中で企業は事業を展開しているということです。
このシフトの影響から、CEOのオフィスにブランドが置かれるようになり、インシデント対応の中で企業のコミュニケーションを重視させる一因になりました。しかし、このチャレンジは企業のコミュニケーションのように、テクノロジー、製品、セキュリティなどのインシデント対応の共通部分にフォーカスする傾向があります。しかし、実際に問題となるのは、全ての側面がインシデント・オペレーションに書記から統合されていた場合、予期しない事態が発生したら、それらがどうに連携して最も効果的な戦略になりうるかです。
最近のForbesの記事で私たちは、危機の最中、特にインシデントのニュアンスが見落とされたときに、組織がブランドを保護するために使える3つのコミュニケーションのヒントを紹介しました。このような状況でストーリーラインをコントロールすることは、企業のコミュニケーションの責任です。彼らの役割は、オペレーションと顧客との関わり方を変えられるコミュニケーション計画を準備し実行することです。企業のコミュニケーションがインシデント対応業務に合わせて準備されている場合、次の点に対応できるメリットがあります。
出血を遅らせる
重大インシデントでは、技術とセキュリティの関係者だけが含まれる古典的な対応チームが組織されることがよくあります。 専門家が問題を特定して解決する間に、企業のコミュニケーションチームは待機させられ、対応作業に遅れをとります。 その一方で、デジタルチャネルを横断して世論が醸成され、形成されています。 レポーターは複数のストーリーを公開し、コミュニティ、ユーザー、パートナーはソーシャルチャネルを通じて意見を共有しています。インシデントの進展に合わせて企業のコミュニケーションチームを早期に巻き込むことで、危機に瀕しているブランドの出血を遅らせる機会が得られます。
ブランドの再構築
ポストモーティム(事後検証)のフェーズでは、重大インシデントに巻き込まれたビジネス全体の関係者が集まり、何が起こったのか、どのように対応業務が実行されたのか、何が改善できるのかを議論します。事態が終息すると、企業のコミュニケーションチームは、顧客やコミュニティの信頼を回復するために組織の舞台裏で働きます。彼らは企業側のメッセージを次にどこへ届けるかを決定し、PRの機会として何をすべきか、あるいは何をしないべきかを決定するために良い判断を下します。危機後に各ブランドは顧客の評判を素早く回復するためにどれだけのケアと行動を取ったかを顧客に迅速に伝えます。時には、整合性が取れない行動に直面したり、次の関連イベントが発生したりして、バックファイアを食らうことがあります。
デジタル時代には、企業の運営方法やコミュニケーションの役割に対する期待が急速に高まっています。新しい技術が登場し、デジタルチャネルが増加する現在、重大インシデントへ対応するための運用の初期段階でコミュニケーションを統合しておくことが、お客様のブランドが世間から否定されず称賛されるという差を生み出します。
インシデント&アラート
買うべきか作るべきか?
典型的な技術者はたった1つの質問ですべての課題に対峙します:「私は自分でこの ソリューションを構築できるだろうか?」と。そしてこの質問は重要な考察が得られるので十分考えるに値します。 では私たちは作るべきですか?買うべきですか? インシデント管理ソリューションの評価は今この問題を招いているようです。 しかし、今インシデント管理プラットフォームを作るべきか、あるいは購入するべきかは、どう分かるのでしょうか?
なぜビルドするの?
独自のソリューションを構築したいという願望が、商用ソリューションの調達権限があなたにないという単純な理由によることもあります。 例えばエンタープライズのITにはツールの予算があっても、DevOpsチームがそれを必要としていたりします。 オープンソースプロジェクトを基にソリューションを構築する方が、商用ソリューションを購入するのに必要な長い駆け引きをするより簡単に思えるかもしれません。 しかし、これは組織的な問題であって、技術的な問題ではありません。 そしてカスタムビルドのソリューションは短命になることがよくあります。
でも独自のソリューションを構築する理由は他にもあります。
現実のまたは既に必要が見えている固有の要件がある
セキュリティとプライバシーに関する懸念がある
コスト
これらは、インシデント管理ソリューションの構築を検討する正当な理由ですが、どれも精査する必要があります。
あなたの要件は本当にユニークですか? これが当てはまるかどうかを特定する方法は、競合他社と彼らが使っているものを見て、さらに類似の組織と比較して要件を調査することです。同時に、独自の要件があっても、なぜそれがユニークであるのか疑問に思うかもしれません。それって本当に必要なの?と。
セキュリティに関しては、商業的なインシデント管理を使わないようにさせるようなセキュリティとプライバシー上の懸念は何ですか?データが暴露される可能性がありますか?ほとんどの場合、アプリケーションのデータはアラートの中に含める必要はありませんが、そうなっている場合は、検討する必要があります。一般的なセキュリティに懸念があるのなら、ベンダーは自らが常にセキュリティの脅威に敏感であろうと努めていることを知っておいてください。多くの場合彼らはあなたの社内の運用チームよりもセキュリティの面ではるかに優れた能力を持っています。
そして、コストの問題があります。 独自のソリューションを構築する上で最もコストのかかる側面は簡単には数字にならないため、コストの計算は難しいのです。インシデント管理サービスの月額料金と、フルタイムの開発者による一回きりの開発のコストを計算するのは簡単です。しかし、継続的なメンテナンス、機能の変更、および大きな一回切りの開発のコストを予期することは困難です。このソリューションを構築していない場合に、開発者は何をしているんでしょうか?また、開発中に複数のプロジェクトやバックログを脇に置いてしまうコストはいくらですか?構築した人が退社した場合に別の問題が発生します。残されたコードベースを理解するためにまたコストがかかります。組織のインフラストラクチャのミッションクリティカルな部分に関連している場合、知識を持つ人が組織を離れることは望ましくありません。
インテグレー?
インシデント管理ソリューションの構築には、1つに大きな弱点があります。成功したインシデント管理プラットフォームには、ソース(アプリケーションとインフラストラクチャなど)とディストリビューション(コラボレーションツールなど)への統合に関する膨大なライブラリが用意されています。これらの統合を実現するためには開発者は新しいAPIに対して習得し、構築する必要があり、かなりの時間がかかります。独自のインシデント管理プラットフォームを構築する組織は、いろいろなユースケースをサポートする必要がなく、重要な統合を行うだけで済みます。
しかし、これらのシステムのAPIが変更されると、あなたは盲目になる可能性があります。新しい機能を使えず、プラットフォームを完全に壊す可能性があります。オープンソースプロジェクトは、統合の中での変化に、あるいは新しいものを作リ出すために素早く対応することはありません。何か不具合が生じた場合も、開発者はもう別の何かを抱えています。もちろん、インシデント管理システムと統合する必要のあるツールの選択は、チームの規模の拡大とそのニーズの変化に伴って変化する可能性があります。
ビルドする時期
オープンソースプロジェクトを基盤とするカスタムインシデント管理プラットフォームが有用なシナリオがあります。それは特定の目的のためのビルドが必要という、とてもニッチなシナリオです。一般的に、このようなソリューションが必要な組織は、グローバルでの商業的インシデント管理を行っており、ニッチなシナリオのためにインシデント管理プラットフォームのAPIに統合していることさえあります。
もう1つの目的は、アプリケーションまたはインフラストラクチャのサポートとは異なるコンテキストで使用されるアラートのためです。おそらくそのアラートはコラボレーションや製品管理に使用されています。このような場合は、自社で作った他のユースケース向けの責任の低いシステムと、商用およびミッションクリティカルなインシデント管理システムとそのユースケースを分けたほうが有用な場合があります。アプリケーションの使用方法から学ぶことについては同じことが、すでに多くのカスタマイズを行っているチームにも当てはまります。例えば、新しい機能がローンチされたときに、その機能が使用されたらアラートを受け取るということができます。また、新しいインフラストラクチャが配備されたときに、パフォーマンスを示す特定のKPIにヒットしたときにアラートを表示させるように設定することもできます。
もう1つの理由は、内外へのデータ漏えいの懸念がある場合です。例えば、是正措置が個人を識別できる情報を、内部のティア1のサポートに、その人たちには見る権限がないのに晒してしまうアラートです。これは問題であり、特に規制産業では問題となる可能性があります。 ほとんどの場合あなたはプラットフォームでの役割と見られる内容を変更できるため、これは問題にはなりません。一般的に言って、あなたはそれを常に試すようにするべきです。避けられない場合もまれにはあるでしょう。
あなたの輝く時間が来る
熟練した技術者は、自分の興味の範囲を超えて、いつビルドや購入をするのが適切かを判断し問題を解決できるようになります。このソリューションは早速作り始めるべきで、立ち止っていてはいけません。これはカスタムソリューションに伴う長期的なサポートであり、リスクです。ソリューションの作成だけでなく、実行する必要もあります。インシデント管理システムにインシデント管理システムをインストールしているんですか?他の何かの稼働時間を心配することはストレスであり、インシデント管理がダウンすると、何も見えなくなります。
コードベースとインフラストラクチャへのカスタムニッチの統合を理由に、独自のインシデント管理ソリューションを構築することが正当化されることがあります。あるいは、商用インシデント管理と連動する非ミッションクリティカルなユースケースがある場合は、独自のインシデント管理を構築する価値があります。しかし、一般的に商用ソリューションの総所有コスト(TCO)は低く、規模の拡大に合わせてニーズに対応し、特定の専門家が退職したときにツールやプロセスが破壊されないようにし、キュリティとプライバシーに関する懸念にもより良いカバレッジとソリューションを提供します。
ビルドや購入を決定するときは、機会費用に重点を置くことをお勧めします。これはあまり知られていない費用ですが、これを考えると普通はかなり早く答えがはっきりします。
インシデント&アラート
Twitterはコールセンターをなくす
インシデント管理における外部メディアの重要性
インシデント管理について偏狭な考え方に陥るのは簡単です。私たちは何カ月も問題を警告するシステムの設計と構築を行い、我々がキャッチできなかった問題を発見するために顧客サポートのチャネルも構築しました。この考え方は間違っていませんが、このアプローチではなく、TwitterやFacebookなどのSNSで問題を報告するユーザーが増えています。
新たな道を歩むソーシャルメディア
ソーシャルメディアは、企業がカジュアルな雰囲気でユーザーと直接つながる素晴らしい手段として、より密接な双方向コミュニケーションの扉を開いています。ソーシャルメディアは個人が企業とコミュニケーションをとるだけでなく、より効果的な方法でユーザーサポートを得ることもできます。
一般的に、ユーザーが電話やサポートチケットなどの伝統的なルートでサポートを得ることができない場合、ツイートで不満を述べるとすぐに答えがが得られることがあります。SNSは苦情を訴える手段だけではありません。多くのユーザーは、ソーシャルメディアを企業とのコミュニケーションに使用するのが好きです。
私も何度かツイートしたことがあります。
彼らのサイトは500のエラーを発生させている?
素敵なJavaScriptはある?
開発者として私が気づいていないかもしれない問題を指摘していただければ幸いです。「何かを見つけたら話す」です。
同期 vs. 非同期
ソーシャルメディアによるサポートの「報告」の側面は強力ですが、他にもより大きな利点があります。ソーシャルメディア(特にTwitter)は、「リアルタイム」を感じさせるからです。
たとえば、電子メールは非同期通信メディアであり、顧客サポートの手順では受けた質問はキューに追加されます。そこに緊急感はありません。一方、Twitterにはより同期的なフローがあります。電話やライブチャットのようなリアルタイムのサポートチャネルではありませんが、回答する時間が公に記録されているため、電子メールよりも緊急性があります。フィードバックは直接的かつ個別的なもので、あなたの問題を他と同様に重要なものと感じさせます。
干し草の山から針を探し出す
それでは、インシデント管理以外の質問に埋もれることなく、うまくやるにはどうすればいいのでしょうか。この問題の解決策はサポートチャネルと同じで、判定と引き継ぎです。
判定
ソーシャルメディアは顧客サービスのためだけに使用されるわけではないため、ユーザーサポート以外の書き込みで混雑することもあります。バグレポートをそれ以外から物理的に隔離することが重要です。単純にバグを非バグから隔離するだけでなく、レポート間の共通点を特定することも重要です。これによりパターンを検出し、問題が手に負えなくなりそうならばその前にエスカレーションすることもできます。たとえばコマンドコンソールは、ツイートなどのデータソースをインフラストラクチャ内の特定のイベントに関連付けたり、影響の範囲を視覚化したりすることができます。こうして、ソーシャルメディアへの反応からデプロイの失敗や停止が顧客に影響をもたらしたかどうかや、影響の程度を理解することができます。
引き継ぎ
問題が特定され、グループの他の部分から隔離されたら、適切な人やチームを割り当てる必要があります。これは、既存のヘルプデスクアプリケーションにレポートを転送するだけでなく、専用のソーシャルメディアサポートアプリケーションを使用して、多種多様な方法で実行できます。
ソーシャルメディアプラットフォームは、マーケティング部門だけが利用するものではなく、インフラストラクチャ内の問題に関するリアルタイムの情報を得る優れた方法であり、今日のデジタル世界では完全な可視性を提供するために不可欠なデータソースです。これらのプラットフォームに従来のサポートチャネルと同じレベルのプロセスと労力をかけることで、問題がより深刻なものになった後ではなく、最初のレポートが到着してすぐのインシデント対応が可能になります。
コールセンターが不要というわけではありませんが、顧客満足度をを確保するためには、ソーシャルメディアを介して入手可能な豊富な顧客データを積極的に活用しなくてはなりません。監視とインシデント管理戦略の重要な要素として、ソーシャルメディアはユーザーエクスペリエンスの質をより深く把握し、顧客のロイヤリティを向上させるための重要な要素です。
インシデント&アラート
オンコールのシャドー中に驚いた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人ではないことを思い出させてくれます。
空が落ちてくると思うような時は、互いに品性ある振る舞いをすることが助けてくれるでしょう。
ベストプラクティス
インシデントの経験を事後検証で最大活用
インシデントを経験した後 のポストモーティム(事後検証。post-mortem またはpostmortem と表記される)に 何をします? 簡単な質問のように見えるかもしれません。 結局のところ、インシデントの処理の最後のステップとして事後検証を考えるのは簡単です。
しかし、そうではありません。 多くの点でインシデントのポストモーティムで何を検証するかは、ポストモーティムをすることと同じくらい大事なんです。以下、理由を説明し、事後検証が終わったあとに何をするべきか、そのヒントを提供します。
なぜポストモーティムするの?
しかし、この質問の意味を考える前に、より根本的な質問、つまりポストモーティムの機能とは何か、そしてそれには何を含めるべきかを検討する必要があります。
ポストモーティムは基本的に以下の役割を果たします:
インシデントとその原因および関連する兆候、解決策、将来の参考になる影響の記録を提供する。技術的問題を将来理解するためと、事件から生じる法的または行政上の懸念の解決の両方にとって重要になり得る。 事件を引き起こした基本的な技術的問題を分析し解決するための基礎として役立ちます。 インシデント対応プロセスを理解し改善するためのフレームワークを提供します 。
これらの基本的な役割をサポートするために、ポストモーティムにはインシデント、対応、解決の記録が含まれていなければなりません。 また、インシデントの根本原因の分析 、インシデントの範囲とその影響の説明、根本的な問題の解決、対応プロセスの改善、および/または将来のインシデントの影響の最小化のために適切な推奨事項も含める必要があります。
理解したあとに、責めないこと
大事な注意点ですが、ポストモーティムを責任追及の手段にしてはいけませんし、企業や組織のポリシーに点を付ける手段にならないように注意してください。必要ならば、事後検証から責任追及を分離するためにインシデント関連の問題を議論するために別のプロセス(すなわち、部門内での非公式で司会を立てた議論)を設定してください。
一方ポストモーティムでは、インシデントを起こす背景になった可能性のある、または対応中に明らかになった、技術的または組織的問題についての正直な議論が含まれるべきです。 技術や反応プロセスの改善に重点を置くべきであり、個人やチーム、あるいはその仕事の欠陥に置くべきではありません。
ポストモーティムはいつ必要?
すべてのインシデントでポストモーティムをする必要はありません。 軽度の運用上の問題や、よく原因が分かっており簡単な解決策があるインシデント、そしてダウンタイムやデータの消失が起きなかったインシデントには、ポストモーティムが必要ない場合があります。
ポストモーティムが必要な状況の例をいくつか示します。
データや生産性の低下、または顧客のアクセスにつながるインシデント シャットダウン、再ルーティング、以前のソフトウェアバージョンへのロールバック、および/または解決のための長期のアクションが必要だったインシデント 適切な監視やアラートシステムがあったのにうまく検出または処理されなかったインシデント 根本原因が不明、あるいは予想を超えていた、または今後も発生が疑われるインシデント システムの動作に広範囲の影響を及ぼす可能性のある、アプリケーションアーキテクチャや技術の根本を含むように見えるインシデント 回答や解決プロセスに深刻な問題や不備があったインシデント
ポストモーティムは学習を容易にする
ポストモーティムを価値あるものにするにはその書き方を、長期的な問題の分析、解決、防止を担当する人々が読みやすくかつ理解しやすくする必要があります。
これは、例えば、問題やその解決を抱えているチームや部署は、ポストモーティムの記録を読むことを読み、さらに結果として適切な次のステップを決定するために、できるだけ早く議論に参加することを要求されているからです。 どうポストモーティムの資料を流通させて、それらを読んだあとの行動にどう導くかという実際のプロセスは、もちろん、あなたの組織の構造と経営理念に依存します。
ポストモーティムの基本要素
ポストモーティムを書いたり読んだりするときには、次の3つの重要な分野があります。
根本的な原因
ポストモーティムは必ず根本原因の説明を含むべきです。根本的な理由が既に分かっていても、ささいなことであっても。ささいな原因ではない場合は、問題の実際の根本原因を正確に特定し、それを修正する必要があるかどうかを、原因の分析に含める必要があります。 根本原因を正確に特定できない場合は、将来の特定につながる可能性のある情報を含める必要があります。
例えば、インシデントの解決の過程で、その問題が多量のレガシーコードを含むモジュールで生じたことが明らかになったけれども、そのモジュールよりも下の部分にある根本原因を特定できなかったという場合でも、その事実を根本原因の分析に含めることが重要です。インシデントと関連してレガシーコードを特定したという事実の記録は、インシデントの解決だけでなく、後の調査で置き換える必要のあるコードを特定することにおいても価値があります。
対応
ポストモーティムには、対応プロセスの完全な技術的説明が含まれていなければなりません。 また、そのプロセスの相対的に見た成功または失敗の説明と分析も含める必要があります。 これは誰の責任も問うことなく実施されなければなりませんが、対応プロセスまたはそのプロセスの実施中の明らかな失敗や弱点を明確に示すべきです。 これには、対応チームメンバー間の責任分担、対応チーム内の連絡、または対応チームと他のステークホルダーとの間のやり取り、特定の対応プロセスの問題が含まれます。
対応プロセスの失敗は、技術的または組織的なものに及ぶ可能性があります。インシデントの解決中にシステムやアプリケーションが利用できないことを、その影響を受ける部門やユーザーに伝えられなかったというような、簡単なことが含まれます。 2つのチームのメンバーが協調せずに同じタスクを実行してしまったり、誰も必要なタスクを実行しなかったために、結果として解決に時間がかかりすぎた場合は、ポストモーティムの中にはチーム構成やコミュニケーションの潜在的な問題を示す注記を入れておく必要があります。
被害の影響範囲の確認と制御
ポストモーティムには、データの損失、生産性の低下、ユーザーアクセスの中断など、インシデントによって引き起こされた損害の程度を明確かつ正確に記述する必要があります。 この被害を限定あるいは緩和するために取られた措置についての説明と分析を含めることも同様に重要です。 ダメージコントロールは、技術的なインシデント解決とは別のプロセスとして考慮する必要があります。 インシデントの種類、被害の種類、および組織の構造によっては、カスタマーサービスの責任である場合や、ビジネス内の他の部門のアクションアイテムが必要な場合があります。
ダメージコントロールは、似たようなインシデントを将来どう処理すべきかに直接または間接に影響する可能性があるため、ポストモーティムの一部に入れておく必要があります。 例えば停電により航空会社のフライト予約システムが停止した場合、そのダウンタイム中に予約を処理するための代替システムを導入することを優先する必要があるかもしれません。
恥と思わず、金と思え
ポストモーティムを最大限に活用するための鍵は、これがアプリケーション、インフラストラクチャ、および対応プロセスの改善のためのロードマップであることを理解することにあります。 各ポストモーティムは、システムの動作方法とインシデントの処理方法を改善する可能性があります。 ポストモーティムを恥とか何らかの失敗の徴候として扱うのではなく、これは将来の金になる貴重な機会だと考えるべきです。
PageDutyは、業界のベストプラクティスを共有し、ポストモーティムのテンプレートを含む完全に無料のポストモーティムハンドブックを提供します。 あなたのチームが問題にできるだけ簡単に対応できるように、自分のポストモーティムプロセスを正式化するのに役立ちます。 PureDutyプラットフォームの一部であるポストモーティムは、自動化されたタイムライン構築、コラボレーティブな編集、実用的な洞察など、 14日間の無償体験版にサインアップし、ポストモーティムのプロセス全体を合理化します。
ベストプラクティス
デジタルオペレーションの人間的側面
2017年2月28日の朝のこと、インターネットが広大な範囲で利用できなくなりました。 Slack 、Quora 、GitHub、Trelloなど、数千人が頼りにしている個々のサイトからサービスに至るまでたくさんのものが利用できなくなりました。たぶん、人為的ミスがインターネットの大部分をダウンさせたこの日を覚えているでしょう。AWSの幅広いコンポーネントが機能しなくなりました。一つの停止でインターネットが無秩序になったのは今回が初めてではありませんが、AWSの規模を考えれば、その影響はいつでもありうると感じられます。
多くの場合、危機の最中に重大な事件に対処する人間の側面を忘れることがあります。例えば人々に連絡する難しさや、個人的な連絡先情報を見つけること、複数のタイムゾーンに主要なスタッフが分散していること、会議から人を引き離すことなど、予期しない出来事のため計画していた作業を中断することなどです。
PagerDutyは、こういう時代に存在する最先端のデジタル運用管理プラットフォームです。私たちは、チームや組織が事態が悪化したときにPagerDutyを使いインシデントを先取りして管理することを支援し、チームがやりたい仕事に集中できるようにします。当社の製品は、予期せぬ事態が発生した場合の行動のプラットフォームとして機能します。私たちは主にエンジニアリングとITチームにフォーカスしてきましたが、チームや人をサポートする他のビジネス分野にとってPagerDutyがどんな意味を持っているかも考えていました。
過去には、エンタープライズシステムや人事部門こそが、AWS停止などの事態が発生したときに必要となる重要な人員の詳細を把握するシステムの責任者でした。人事チームはまた、大事な顧客への影響が発生したときに情報を提供する必要があります。私たちの情報の世界の大部分はクラウドにあり、クラウドベースのサービスが利用できない場合に、私たちが仕事をするために必要な重要な情報もそこにあります。私たちが日常的に利用している人気のあるサービス、社内のメッセージングとVoIPサービスは、すべて利用できなくなる可能性が隠れています。これらのクラウドサービスの大規模な停止またはダウンタイムの間、顧客と従業員に情報を提供し、行動と対応を調整することは困難です。
「 私たちの情報の世界の大部分はクラウドにあり、クラウドベースのサービスが利用できない場合、私たちが仕事をするために必要な重要な情報もそこにあります。」
現代の企業には、通常、人の情報をすべて記録したシステムがいくつもありますが、その詳細を最新の状態に保つインセンティブを人々に持たせていることはめったにありません。 PagerDutyのようなインシデントや危機対応の鍵を握るシステムでは、従業員全員が緊密な接触を維持する気にさせる深いインセンティブと日常のビジネスニーズがあります。そのプラットホームを活用して正確な人の情報を得、応答を調整すればスムースになります。
これは、ビジネス全体で高度に採用されているプラットフォームをHRチームが使用する絶好の機会であり、私たちを行動の心臓部につなぎとめ、妨げにならないように支援します。私たちが最も避けたいことは、素早い返事と行動を求められている最中に、社内で不要な騒音や官僚的な行動を作り出すことです。
従業員に対する環境的、物理的、またはデジタル的な脅威など、人事部門が責任を持つべき危機のことを考えてください。私たちに必要なのは、状況を管理し、重要な情報にアクセスし、サイロになったりワークフローにまぎれずに、あるいは、チケットによって遅くならずに応対できるようにすることです。いつもそうとは見えないかもしれませんが、HR部門は、さまざまな状況になると、しばしば第一級の対応ができる部門です。ベストプラクティスとアジャイルワークフローを使い重大な事態に対処するには、法律、設備、ベンダー、サイバーセキュリティチームと連絡する必要があります。
当社の顧客の多くは、物理的な在庫やサプライチェーンを持たないビジネスモデルを採用しています。デジタルインフラストラクチャがビジネスの主体であり、顧客の経験に大きな影響を与えます。エンジニアリングから法律およびマーケティングに至るまで、インフラストラクチャと顧客体験の成功に投資しています。リアルタイムの顧客への影響がある場合、そのインフラストラクチャ全体を調整できるプラットフォームを使う方が優れた対応ができます。
“ これらのチームが人々と意思決定とシステムの間に持っているスピード、オーケストレーション、相互運用性からはみんなが恩恵を受けられます。”
テクノロジーに焦点を絞ったビジネスでは、エンジニアリングチームや開発チームが使用するプラットフォームやプロセスから学ぶ必要があります。これらのチームが人々と意思決定とシステムの間に持っているスピード、オーケストレーション、相互運用性からはみんなが恩恵を受けられます。各チームが醸成した文化、つまり最前線に至るまでのカスタマーエクスペリエンスの説明責任を果たせること、チームが対策を組織できると信頼すること、非常に高い協調性から学んだこと、そしてDevOpsチーム、ITチーム、顧客が習熟してきたインシデント対応へのアプローチから、恩恵を受けることができます。ビジネス全体がこれから学ぶことができます。
“ HRの専門家としての私たちの責務は、組織の人々のデータおよびオーケストレーションのインフラストラクチャが、インシデント対応の技術インフラストラクチャおよびオーケストレーションと同じくらい効果的だと保証することです。”
さまざまな機能が共有プラットフォーム上で共同して働ける新しい方法を見つけ出すことは私をワクワクさせます。例えばデータを集めることと機械学習を活用して、あるパターンが出現する前にそれを見つけたり、過去の反省から対策を覚えたり改善したりすることができます。 HRの専門家としての私たちの責務は、組織の人々のデータおよびオーケストレーションのインフラストラクチャが、インシデント対応の技術インフラストラクチャおよびオーケストレーションと同じくらい効果的だと保証することです。私たちは社員が顧客のために構築した経験を彼らから借用していますし、オンコールエンジニアの人生をより良くしていくことで、デジタルビジネスに関わる全員の人生をより良くすることができるはずです。
オムニチャネルで成功しているリテーラーの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チームにオムニチャネル体験を提供するための手がかりを与えることになります。クラウドへの移行、マイクロサービスの活用、コンテナの採用、データストアの分散化、またはインシデントの予見的な管理など、次世代のコンピューティングテクノロジーが今や利用可能です。リテールビジネスに必要なのは、計画を立て直す準備を整えた開発チームだけです。
現代のインフラストラクチャに真のフルスタック可視性を
「フルスタックの可視性」とは?
ツールのベンダーが「フルスタックの可視性を提供します」と宣伝していることがありますが、これが何を意味しているか分かるでしょうか。ツールが違えばどう可視化するかも違います。理由は、可視性が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カ所で管理できます。
「インシデントコマンダー」に求められるトップスキルとは―養成のプロセスを考える
組織は、オンコール の負担を下げつつ顧客に高いレベルのサービスを提供するために多くのインシデント対応の司令官( 「インシデントコマンダー」)を必要とします。多くの人は上級の技術者(シニアテクニカルリード)だけがその役を担えると思っているので、インシデントコマンダーになりたがりません。しかし、実際には「ソフトスキル」のほうが重要であり、この記事で説明されているような明確なプロセスで、チームは障害対応を主導し調整を成功させる人員を養成できます。*
私はエンジニアではなく、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
ChatOps:チャットボットがインシデントを引き受けます
あなたの考えていることをずっと追いかけていて、あなたの計画の実行を助ける、そんな小さな ロボット があったら素晴らしいでしょう。もし、あなたがインシデント監視インフラストラクチャを担当する管理者なら、それは存在します。チャットボットと呼ばれる彼らは、インシデント管理ワークフローを最適化するための鍵です。
ここではチャットボットとChatOpsを使うのが、DevOps手法を採用している組織にとってとても重要な理由について説明します。
チャットボットの定義
「チャットボット」は人によって異なるものを意味します。大まかに定義すると、チャットボットは、人間と「会話」をするプログラムです。チャットボットはずいぶん昔から存在しています。あなたがAOL(注:America Online)がまだインターネットを支配していた時代に育ったなら、例えばSmarterChildというAIMインスタントメッセージングサービスのためのチャットボットを覚えているでしょう。
インシデント管理とインフラストラクチャの監視の分野でいうチャットボットは、もっと狭い意味を持ちます。彼らは人間の言うことを理解し会話をするだけでなく、人の代わりにアラートを監視しインシデントに対応します。
言い換えれば、この意味でのチャットボットは、SlackやHipChatなどのコミュニケーションプラットフォームと統合され、人間の入力に応答してコマンドを処理するプログラムです。コマンド自体は、多くの場合、バックグラウンドで動作するサーバで実行されていますが、管理者が行う必要があるのは、何をするかチャットボットを教えることだけで、残りは事前に定義された手順に基づいて自動的に処理されます。
チャットボットとChatOps
チャットボットは開発業務におけるツール、プラットフォームであり、ChatOpsと呼ばれます。彼らは開発者と運用チームに以下のような利益をもたらします。
コマンドを実行するための便利なインタフェースを提供する
すでにSlack、HipChatや他のコミュニケーションプラットフォームをすでに使っている場合、なぜコマンドを実行するために異なるインタフェースに乗り換えるのでしょうか。チャットボットならばあなたがコマンドを実行する必要はありません。チャットインターフェイスから直接実行させることができるので、ずっと素早く実行できます。
チーム全体を可視化
あなたがチャットボットとの対話を公開していれば、参加するすべての人があなたが実行したコマンドを確認することができます。これは、あなたのチーム全体を可視化し、チームメンバーが同じコマンドや矛盾したコマンドを実行していないことを確認できます。そして同時に、チーム全体が学習する機会も提供します。
リアルタイムなアクションを促進
伝統的に、チームは集まり、計画を立て、別れて、実行します。チャットボットとChatOpsを使うと、コミュニケーションと操作インターフェースが統合されているので、対話と実行が同時に可能です。重要なオペレーションを実行する前、計画を立てるための時間が要らないとは言いませんが、例えばインフラの障害に対応しているときのように時間が最重要である場合、計画とオペレーションが同時に行えるのは大きな利点です。
チャットボットとChatOps、DevOpsチーム
これらの利点は、ほぼすべてのタイプの組織に有用です。組織がDevOpsチームスタイルのワークフローに移行しつつある現在、これは特に重要だといえるでしょう。
それはなぜか。DevOpsチームの2つの原則は、シームレスなコミュニケーションとオペレーションの俊敏性であるためです。ソフトウェアの継続的デリバリー(と透明性と公開性)を求める場合は、チームメンバー間のコミュニケーションギャップを回避する必要があります。また、インシデント対応時に継続的デリバリーのパイプラインを壊さぬよう、迅速かつ容易に行動できる必要があります。
同じ論理は、監視とインシデント管理にも適用されます。監視チームを継続的に活動できるようにしたい場合、リアルタイムでインシデントを特定し解決するため、瞬時に可視化されたコミュニケーションが可能な手段が必要です。素早いアクションと効率的かつ協調的な方法でチームメンバー間に責任を持たせるための方法です。チャットボットはこのすべてを可能にします。そのため、チャットロボットはDevOpsの世界を席捲しているのです。
インシデント発生時のベストなコミュニケーションの方法
あらゆるビジネスが デジタルビジネス に進化し、ほんの少しの停止時間でも、これまで以上に収益とブランド価値に深刻な影響を与えるようになり、危機に直面した際の効果的なコミュニケーションの必要性が増してきました。これによりサービスを開発・管理する技術チームにより高いプレッシャーがかかっているということですが、さらにデジタルトランスフォームは、ブランドの評判と顧客体験に責任を持つ他の事業部門にもプレッシャーをかけています。
製品やサービスから顧客が最大の価値を引き出せるようにする責任を負うコミュニケーション、マーケティング、とりわけサポートチームを見てみましょう。プレッシャーによって渉外機能に新しいワークフローとベストプラクティスが必要になっています。PagerDutyで私たちが学んだ実践から、これまでに磨いてきた4つのベストプラクティスを紹介します。
- みんながオンコール担当
PagerDutyのコミュニケーションチームの一員として、私は技術担当の同僚や他の多くの人と一緒にオンコールの仕事に従事しています。受け取るインシデント通知のほんの一部を見ても、なぜ自動化とインシデント対応プロセスを持つことがスムースな運用に必要なのかを深く理解しています。それが今日のデジタルサービスをうまく稼働させているのです。何かが顧客にインパクトを与えるとき、コミュニケーションチームやサポート、営業、法務、そしてリーダーなど他の部門の関係者は、私たちが顧客と適切なコミュニケーション対応をプロアクティブに取れること、そして時が経つ間に自らのブランドと顧客の約束を守るために正しい対応を効果的にやれるのだということを、知っておく必要があります。
2.サポートと足並みをそろえる
受賞経験のある当社のサポートチームは重大インシデントに遭遇したときには顧客対応の最前線に立ちます。しかしコミュニケーションチームは次のことを理解するために整列して待機しています。
どんなインシデントでなぜそれが起きたのか? どのくらい多くの顧客がどのくらい長く影響を受けているのか? インシデント対応はどのくらい進んでいるのか(まだ調査中なのか解決に近づいているのか)?
インシデント対応プロセスの中では、チームは顧客との連絡窓口(注:カスタマーリエゾン)を必要とします。その窓口担当は、アプリやサービスに起きている障害がさらに悪くなりそうな時に外部と最善の方法でコミュニケーションをとれるよう訓練されている人たちです。
私たちのコミュニケーションチームは、今何が起きていてどんな影響があるのかを正確に理解するために、カスタマーリエゾンと一緒に作業をします。PagerDutyの中では、インシデントに関するSlackチャネルの一部に加え、Stakeholder Engagementという機能で情報の更新を自動化しています。我々は各チームからより抜かれた適切な人の間で協業が進むようタイトなラインを作り、顧客やより広い市場との有益なコミュニケーションが作れるように協力しています。
3.プロアクティブになろう
伝統的なチケットやITSMのワークフローを使っている場合、プロアクティブになる機会を失っているかもしれません。顧客は何か悪いことが起きるのをあなたより前に知ります。例えばソーシャルメディアなどの公開の場やニュースで彼らが気づく前にあなたが問題を修復する機会はないでしょう。コミュニケーション対応の観点からは、外向けに出すメッセージをより早く作れるよう行動するべきです。そうすれば不満のツイートや正しい情報を求める記者からの電話に対応できるようになります。インシデント対応コミュニケーションのこの段階では、傷ついた評判を修復する戦略を立てることが大事であり、理想的には事態を正常化するためにリアルタイムに起きていることを共有すべきです。プロアクティブなコミュニケーションを支援するため、我々は発生しうる危機のシナリオを特定してワークフローを作り、さらにこれまでの経験に基づいて、使うべき言葉を中心に、ベストプラクティスを作成しました。もちろん、危機シナリオは独自のものですが、平和な時に基礎を作っておけば、余裕がなくとストレスが高い戦闘中でも、素早く行動できます。
4.ブランドをリシェイプする
インシデントが解決してもコミュニケーションチームの仕事は終わりません。理想的なインシデント管理のライフサイクルの中で、重大インシデントは必ず事後検証を受けるのです。その中では関係者全員が、何が起こったのか、その対応がどう実行されたのか、今後どのように改善できるのかを議論します。これは学習と改善のための時間です。コミュニケーションチームにとしては、組織全体で協力し顧客や広範なコミュニティの信頼を回復する計画を策定し実行する必要があります。つまり当社のブランドが期待に応えられなかった部分を改善する戦略を実行するのだと考えてもらってよいでしょう。企業としての表明も改訂し、健全な判断を使い今後どうするのかを検討しないといけないでしょう。これはまた、あなたががビジネスに携わっている理由と言行一致を確約するための時間でもあります。ビジネス全体での行動が間違いを正すために必要かもしれません。
今日の、”マイクロ秒単位の時間”に支配され、常時オンが当たり前の世界で成功するためには、コミュニケーションチームは他のチームと一緒にデジタルオペレーションのエクセレンスの追及に”レーザーフォーカス”しなければなりません。これは、これまでと違う覚醒を意味するだけでなく、法外に優れた顧客体験を提供することを心の中の統一目標として、各機能部門を横串した新しい作業とコラボレーションのやり方を意味します。
Firefightに必要なインシデント管理ツール
火事が発生する前に適切なツール を用意することが重要です。適切なツール がないと、大規模な停止を認識し、整理し、解決することがはるかに難しくなります。事前にベストプラクティスが確立されていれば、困難なインシデントをよりスムーズに処理できます。
以下は、障害発生に備えたプランを網羅したリストではありませんが、問題の調整と準備のための組織の能力を大幅に向上させます。
- 内部コミュニケーション
内部のコミュニケーションは通常電子メールで行われます。これは、いくつかの理由で問題があります。電子メールは1対1のメディアです。つまり、送信者と受信者だけが読み取り可能であり、迅速なステータス情報が必要な場合は解析が困難です。SlackやHipChatなどのコラボレーション環境は、情報を伝達するために外部ホストを利用します。これらは、全員への公開チャンネル、登録者のみに公開されるチャンネル、あるトピックについてのチャンネルなどを提供します。クリティカルレベルでは、ステータスの更新(または問題が既に分かっており、作業中であることを伝えるメッセージ)を、主要なスタッフ(サポート、リーダー)にほぼリアルタイムで提供することができます。
- アプリケーションのパフォーマンスとインフラストラクチャの監視
本来、チームは顧客より先にアプリケーションに問題があることを知るべきです。アプリケーションやインフラストラクチャの監視技術は、修正や更新が必要なときに役立つかどうかの情報を提供します(New RelicやAWS CloudWatchなどがこれにあたる)。また、PagerDutyなどのソリューションを使い、アプリケーションのパフォーマンスとインフラストラクチャのパフォーマンスを監視することも重要です。問題が発生した場合は、全サービスの正常度データを単一のビューに統合し、緊急行動が必要な場合はオンコール担当者に通知します。アプリケーションとインフラストラクチャの両方が可視化されていれば、問題解決ははるかに簡単です。
- ステータスの更新
パフォーマンス上の問題が発生した場合、サポートチームに更新要求が殺到します。この流入を緩和するための主な方法は、Twitter、ステータスページなどを利用すること、またはPagerDutyのような製品を使うことです。これらは、主要インフラストラクチャとは別のインフラ上で稼働し、サイト全体が停止しても動き続けることが必要です。Twitter上では、ユーザーがピントゥイートと最近の返信を簡単に探すことができます。ユーザーはstatusapp.comで「黄色」または「赤」のステータスを確認することもできます。statuspage.ioのような読みやすいステータスページは、ダウンタイム中に情報を顧客に伝えるための重要なコンポーネントです。ユーザーはトラブルの際の情報が正確で更新が適切に行われている場合、そのページに信頼を置きます。そうすれば、彼らはあなたのビジネスにもっと信頼を寄せるでしょう。また、トラブル対応の最中にも情報の更新と各主要サブコンポーネントのステータスを知らせる必要があります。これらの更新は、完全な可視性を担保するために数分ごとに行われるべきです。最後に、PagerDutyのステークホルダーエンゲージメントのような機能により、インシデント担当者は、任意の優先通知チャネル(電話、SMS、電子メール、またはプッシュ通知)を介して、事前定義されたビジネス関係者のグループに到達するステータス更新を簡単に送信できます。ステークホルダーは、インシデント状況の更新を購読して、顧客に影響を与える問題についてリアルタイムの情報を得ることもできます。
- チケットソリューション
ZenDeskのようなチケットソリューションは、停電を管理するために絶対に重要です。重大な停止は破壊的であり、信用を失うことにつながります。チケット管理システムは、アプリケーションモニターが見逃した間欠的に起こる問題を特定するのに役立ちます。また、サポート要求に対して情報を公開します。問題のエスカレーションのワークフローは、特に大きなサポートチームにおいて、個々の判断に頼るよりも迅速な問題解決を導きます。あらかじめ用意されたメッセージは、システム停止中にメッセージの一貫性と正確性を維持するのに役立ちます。また、「related to」タグを使うと、問題が解決された後で簡単に報告することができます。
- プロシージャのトラッキング
適切な手順を講じることで、組織はアプリケーションから発生する可能性のある問題を予測できます。これらのシナリオは、事前に文書化する必要があります。トラブル対応、障害緩和、修復に関する情報は、チームのために文書化されるべきです。この文書には、誰が何をすべきかという職務チェックリスト、緊急連絡先電話番号とオンコール担当者の名前も入れておきましょう。もし可能ならば、模擬停電の訓練が、実際の停電が発生した際の対応に役立ちます。その後、訓練終了後、事後検証チームと一緒に検討し手順を改善してください。別のトラブルが発生した際、プロセスに追加できる情報があれば追加します。上記の他の項目と同様に、ローカルのインフラが利用できなくなる可能性があるため、これらのプロシージャを外部にホストされたリポジトリに格納するか、PagerDutyなどのソリューションで自動化することをお勧めします。
これらは一連のリストの最初のいくつかに過ぎません。トラブル時に有効だったことを記録しておくのは、事前に理解して準備するために費やされた時間と同じくらい貴重です。社内外のステークホルダーとのコミュニケーションはIT業界だけでなく、あらゆる業界にとって重要です。
インシデント管理のメトリックでタブを常時オンにする
およそ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が起きた場合でも。
コールを処理するのは誰?
今日の統合されたデジタルエコノミーでは、ほとんどの企業のITインフラストラクチャはもはやサイロ内に留まっていることはできません。統合の圧倒的なメリットは、新しいアイデアやソリューションを急速に発展させられることです。残念なことは、統合と接続性の向上は自分たちの会社とユーザーを、サイバー攻撃、コンピュータウィルス、インフラストラクチャの問題のリスクにさらすことにもなる、ということです。
組織がシステムを保護し、データと顧客を保護するための対策に投資することが不可欠です。組織は、何かが起こる前に明確なインシデント対応計画を策定しておく必要があります。侵害または顧客に影響を与えるインシデントの検出後には、応答チームを率いる人を探し、誰が関与する必要があるかを決めるのに時間をかけるべきではありません。必要なのは、包括的なインシデント対応計画であり、企業のリーダーシップを含む総合的な対応として事前に用意されていなければなりません。
インシデント対応チームはどこまで包括する必要がある?
インシデント対応チームを組織する際は、ITインフラ、開発、品質保証の担当者を含めるべきです。しかし、他にもその代表を含めるべき部門が多数あります。
会社のリーダーシップ
広報
法務
人事
顧客サービス
危機管理
インシデント対応チームは、インシデントに対する組織の対応を監督し指揮する責任を負うべきですが、リスクを軽減しインシデントが発生する前に予防することも義務付けられます。チームのフォーメーションは、まず適切な対応計画の策定に焦点を当てて、インシデントが発生しないように対策を実施する方向に移行する必要があります。インシデントの予防と対応にさまざまな部門が関与すべき理由と、その方法を決定するために各機能を見てみましょう。
会社のリーダーシップ
インシデント対応チームの創設と成功には、最高レベルの企業リーダーの積極的参加が不可欠です。リーダーの積極性は適切なサポートを可能にし、組織のあらゆる側面にわたるチームとの整合性を確保します。リーダーシップの関与は、インシデントのフォローアップにおいても重要です。インシデントに対応する各リーダーとビジネスの調整は、効果的で迅速に対応するために不可欠です。
広報
インシデントのフォローにおいて、広報担当者が企業とユーザーの主要な接点になります。広報活動の準備の中で重要な責務は、包括的な情報開示方針の策定と、他のチームと連携して、特定の種類のインシデントに対して実行可能なシナリオに沿って対策を実施することです。
法務
法務は、契約や企業責任を担当するチームとして、会社のデータと知的財産の完全性を保護するための法的枠組みを開発する重要な役割を担っています。インシデント発生直後の期間に、法務は会社の責任を決定し、開示および通知に関する法的義務が適切に処理されるようにリードします。
人事
人事には、インシデント対応チームの初期開発段階で、社内から来た人であろうと、組織外で雇用された人であろうと、適切な人材が適切に配置されるようにする責任があります。
人事にはさらに他のチームと協力して、機密データへのアクセスを含む従業員向けのポリシーを策定し、従業員にそのポリシーを教え、必要に応じて従わせる責任があります。
顧客サービス
企業の外向きの顔として、顧客サービスチームは、潜在的な脅威を見つけて報告し、ユーザーへ事態の状況を明確に伝えるという重要なポジションにいます。さらに、既存の情報開示方針に精通し、インシデントがいつ誰にエスカレートされるべきかを理解している必要があります。また、渉外担当者は、外部ユーザーとの作業の中で直面する可能性のあるデータセキュリティ要件と潜在的な脅威を熟知している必要があります。
危機管理
最後に、危機管理チームは、コンピュータセキュリティチームと協力して、リスクが発生する前にリスクを特定し軽減するポリシーを開発し実装します。また、他のチームと連携して脆弱性評価法を開発し、実施し、潜在的なインシデントの早期警告システムとして機能する脅威検出指標を設定して監視する必要があります。
強力な防御が効果的な攻撃を可能にする
インシデント対応はIT部門の責任ではありません。ITは、対応チームで重要な役割を果たしますが、組織全体の全チームの協調的な努力こそが、インシデントに対し統一され調整された対応を可能にします。企業がインシデントを処理するための強力な防衛戦略を策定したら、インシデントが発生する前にリスクを特定し、リスクを軽減することに焦点を当てるべきです。
クラウドへの旅、インシデント管理の改善
多くのIT組織は、クラウドインフラストラクチャ の活用はやむを得ずやることではなく、IT組織がビジネスニーズに即応するための最も効果的な方法だと悟りました。
しかし、クラウドには、ダウンタイムの最小化、運用コストの削減、社員の燃え尽き症候群防止など、新たな課題があります。企業がプロセスと手順を新しい現実であるクラウドベースのインフラストラクチャに移行するのに合わせて、これらの課題を解決するためにインシデント管理ソリューションを採用する必要があります。これはハイブリッド環境で運用する大企業の場合、つまり従来型のインフラストラクチャとクラウドベースのインフラストラクチャを混在させて、インシデント管理にもハイブリッドなアプローチが必要な場合に特に当てはまります。クラウドに移行するには時間がかかりますが、それは1回で済むものではありません。
組織がこの新しいパラダイムを受け入れてクラウドに移行する理由と、シームレスなクラウド移行のためにインシデント管理をどのように処理しているのかを見てみましょう。
なぜクラウドに移行するのか
組織がクラウドに移行するには多くの経路があります。クラウドネイティブアプリを担当する開発チームを、プライベートクラウドとパブリッククラウドの様々な組み合わせを担当するインフラストラクチャチームへと移行させ、2つのクラウドを相互接続するためのハイブリッドインフラストラクチャを構築する方法など、クラウドに移行するメリットのいくつかを見てみましょう。
インフラストラクチャ管理の削減**:クラウドサービスを活用することで、従業員は、下位レイヤーのコンポーネントをパッチして維持する必要がなくなり、ビジネス価値を提供することに集中することができます。 アジリティ(俊敏性)の向上**:クラウドインフラストラクチャ上でサービスを更新、追加、削除する機能は、企業が新しい機会に対応するスピードを大幅に加速します。 クラウドネイティブアプリ**:アジャイル開発のプラクティスと継続的インテグレーション、継続的デリバリー、マイクロサービスを組み合わせることで、チームはビジネス機能をスピードとスケールをもって提供することができます。 ディザスタリカバリとビジネス継続性**:クラウドインフラストラクチャのビルトインデータレプリケーション機能を活用することで、迅速なリカバリを目的としたセカンダリサイトの構築が可能になります。時間が経つと、これは複数のゾーンや地域に配置した冗長システムに変わります。 常時稼働**:クラウドサービスは、一般的に24時間365日稼働しており、サービスへの移行以外の余分な労力や人員を必要としません。 設備投資の無償**:クラウドサービスはサブスクリプションベースで機能するため、大きな設備投資が不要で、償却費や減価償却費を払う必要はなく、コストを運用予算に移行できます。クラウドサービスプロバイダは、資本投資を必要とする物理的環境を維持します。 市場投入までの時間短縮**:購買手続きが全くなくてもチームは新しいアイデアのテストを数日間で開始することができます。数週間または数カ月のリードタイムを必要とする従来のモデルとは異なる点です。
クラウドへの移行は、企業がより機敏に対応できる利点があるため、規模を問わず多くの組織にとって合理的です。クラウドへの移行は、やるかやらないかではなく、いつやるかという問題になっているのです。結果として、ITチームはこの新しいパラダイム内でアプリケーションを構築、運用、サポートする方法を学ばなければなりません。
クラウド環境でリアルタイムの可視性を得る
クラウドへの移行の前後にインシデント管理プロセスを導入していないと、問題が発生したときに盲点になり、インシデント対応が遅れることがあります。これらの問題は、ビジネスへのリスク、顧客への影響、および移行プロセスの遅延につながる可能性があります。また、ハイブリッドインフラストラクチャを使用したり、パブリッククラウドインフラストラクチャに完全に移行したりする場合に、これらの弱点を未解決のままにしておくと、実際のインシデント対応に支障をきたすようになります。効果的なインシデント対応でハイブリッドクラウド環境を管理することは非常に重要です。そうすればクラウドベースのアプリケーションで動作しているものをリアルタイムに把握し、移行中または移行後に問題が発生した場合に対処できます。
クラウド移行中のインシデント管理の課題
前述したように、クラウドに移行する際には、次のような新たな課題を克服する必要があります。
クラウドインフラストラクチャプロバイダとの統合と監視
クラウドネイティブアプリケーションを組織のアプリケーションポートフォリオに導入することで、複数のクラウドプロバイダー間でインスタンスを動的に追加または削除する場合でも、すべてのインスタンスを表示、レポートできることが不可欠です。現代のクラウドベースのツールからシグナルを引き出すことが重要ですが、従来のツールからシグナルを引き出せることも同様に重要です。組織がハイブリッド環境に存在する可能性が高いからです。すべてのアプリケーションが同時に移行されるわけではないため、これは移行中に大きなリスクになりますが、既存のサービスやアプリケーションを提供するには、オンプレミスとクラウドの両方のコンポーネントが必要です。
解決策:最新と従来のアプリケーションパフォーマンス管理スイートと、すべてのクラウドインフラストラクチャで使用可能なネイティブツールを理解し、統合できるインシデント管理プラットフォームを用意します。
常時オンは常時サポートが必要だという意味です
顧客は常時オンの経験に慣れてくると、自社のサービスは24時間いつでも利用できると期待しますから、問題を報告するために月曜日の朝まで待たずに声を掛けることを躊躇しません。
解決策:24時間365日のサポートを処理するために構築されたインシデント管理プラットフォームに投資し、監視ソリューションが事前に障害を検出したとき、またはクライアントがインシデントを報告したときに、どのチームに通知するかを知ることができます。その後、インシデント対応のライフサイクルを通してそのチームをサポートします。
クラウドの可視性
クラウドベースのプロバイダーから提供されるサービスが増えましたが、アプリケーション、ミドルウェア、インフラストラクチャからのイベントやアラートに必要な可視性を、顧客が影響を受けたり、あなたのプロジェクトが遅れる前に実現できるようにするにはどうしたらよいでしょうか。
解決策:複数の情報源からの情報を受け取れるソリューションに投資し、問題の影響を調査するチームの能力をサポートします。対応者が適切な情報を持って行動し、ビジネスチームやプロジェクトチームのリスクを最小限に抑えることが重要です。これにより、クラウドの移行ライフサイクルが迅速に回り、高品質なアプリケーションの変更が本番環境に導入されるようになります。
分散した労働力
クラウドにはモバイルフレンドリーなプラットフォームがあり、地理的に分散した複数のオフィスを持つ組織がますます増えていますから、単一の統一されたコミュニケーションチャネルを持つことが重要です。
解決策:従来の電話会議を使っているのか、それともSlackやHipChatなどの最新のコラボレーションソリューションを使っているのかどうかは関係ありません。目標は、あなたが話す必要がある人々を見つけられる場所を1つにすることです。SlackやHipChatのようなツールの利点は、会話を離れずにチャットに情報とアクションを持ち込めるようにインシデント管理と監視ソリューションにフックできる点です。
クラウドの移行の一環として、開発チームやビジネスユニットのニーズに合わせて、同じティアでチームをサポートする必要性を検討することが重要です。サポートチームが、開発者が展開しているものの背後にあって必要なすべてのプロセスとツールを持っていない場合、追加されたすべての複雑なレイヤは、信頼性の高い方法で使えないため、ビジネスにとっては無駄になります。
クリティカルなアプリとインフラを継続稼動させる
「インシデントのライフサイクル管理? ある事件から次の事件まで生き伸びさせることができれば、 良い一日。悪い日は何もかもパニックさ」
残念ながら、これは非常に多くのソフトウェアや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年ウォード・カニンガムが、技術的な複雑さと債務の比較を経験報告で初めて行った。(ウィキペディア)
小売業向けインシデント管理法
近年、1年で最も忙しいショッピングデー「ブラック フライデー」(注)にシステム障害が多発しています。
有名ブランドのWebサイトの停止やシステムトラブルの記事を目した管理者は、他人事とは思えないでしょう。大規模な小売業者でもスムーズにインフラストラクチャーを稼動させるのに苦労しているというのに、中小企業はどうすれば障害を防止できるでしょうか。
幸いにも、手はあります。適切なインシデント管理手順に従うことで、小規模のチームでも必然的に起こる業務の中断による影響を最小限に抑えることができます。
ここでは小売業者のニーズに焦点を当てて解決法を紹介します。
(注;ブラックフライデー(英語: Black Friday)とは、小売店などで大規模な安売りが実施される11月の第4金曜日のことである。 アメリカ合衆国では感謝祭(11月の第4木曜日)の翌日にあたり、正式の休暇日ではないが休暇になることが多い。当日は感謝祭プレゼントの売れ残り一掃セール日にもなっている。買い物客が殺到して小売店が繁盛することで知られ、特にアメリカの小売業界では1年で最も売り上げを見込める日とされている。また、年末商戦の幕開けを告げるイベントでもある。 )
小売業者の優先順位の定義
小売業者の効果的な監視とインシデント管理を行うために、管理者はまず、インフラストラクチャの可用性と稼働時間に関して小売業者の最も重要な要件が何であるかを理解しなければなりません。
実店舗とオンラインショップの両方を備えた最新の小売業者にとっては、以下を確実に行うことが不可欠です。
顧客がアクセスするWebサイトを常に正常に稼動させる。** 顧客が接触するサイトがパブリックなインターネット上にあり、DDoS攻撃など悪意のあるトラフィックスパイクからクラッシュする可能性や不正侵入の脅威があるからです。Webサイトは販売促進のために実店舗のみの小売業者にも不可欠です。顧客は通常、オンラインで購入するか店舗に足を運ぶかにかかわらず、購入を計画するためにWebサイトを使用します。
バックエンドシステムの稼動を維持する**。在庫の追跡やトランザクション履歴の保存などのタスクを処理するバックエンドサーバも、ビジネスオペレーションにとって不可欠です。一般にバックエンドサーバはプライベートネットワーク上で実行できるため、パブリックサイトよりも攻撃者から保護しやすいですが、一方で別の脆弱性も持っています。非常に機密性の高い情報が保管されていたりするので、効果的なモニタリングが不可欠です。
POSシステムの安定稼働を確保する**。小売業者はPOS端末がクラッシュした場合、販売を続けられなくなります。POSシステムを稼働させ続けるには、ローカルネットワーク接続から物理的なセキュリティ、さらに電源供給まで、複雑な変数の組み合わせを効果的に管理する必要があります。
IoT資産を保護する**。小売業もIoTを活用してワークフローをパーソナライズし、自動化することでデバイスとセンサーの安定稼働と接続性を保証し、業務を強化します。高度に自動化されたIoTデバイスベースのビジネスオペレーションへの移行は、システム監視の分野でも新たな課題となります。
これらは、取引完了を確実にするための小売業者の第一の要件です。ここでは、監視とインシデント管理を使用して重要な課題に対処する方法について説明します。
システムダウンの防止
小売業のシステムインフラの重要な部分を円滑に運用するためのガイドラインを紹介します。
インフラストラクチャ全体の可視性を最大化する**。非常に多くの要素があるため、小売業者は特に複雑で多様なITインフラを持つ傾向があります。それはWebサイトだけでなく、バックエンドシステムや各種専用デバイス、センサーなども含みます。このようなインフラストラクチャを把握するために、全面的な可視化が必要です。監視情報はそれを理解する唯一の方法であるため、1カ所に集中させる必要があります。
柔軟な監視ソリューションを導入する**。多様なインフラストラクチャには、多様な監視ツールが必要です。小売業者は、インフラストラクチャのさまざまな部分にすべて監視エージェントをインストールし、収集した監視情報を中央の管理プラットフォームへ転送し、正規化する必要があります。
リアルタイムに対応する**。小売業者にとっては、販売サイトやPOSシステムの数時間(またはわずか数分)のダウンタイムが非常にコストの高い影響を与えます。ダウンタイムの直接的な結果として失われた売上に加えて、企業も評判にも損害を与えます。したがって、影響は数カ月続く可能性があります。これらのリスクを軽減するために、インシデント管理システムとワークフローが鋭い洞察を基にしたリアルタイム応答を可能にし、サービスができるだけ迅速に復元されるようにする必要があります。
効果的コミュニケーションを図る**。小売業におけるインシデント管理の課題のひとつは、企業のインフラストラクチャが、特に店舗や倉庫の大規模なネットワークを持つ小売業者にとって、非常に大きく広く分散する傾向があることです。インフラストラクチャの稼動を維持する管理者も分散しがちです。この課題に取り組むには、シームレスなコミュニケーションツールを提供するインシデント管理システムが必要で、ChatOpsなどの共同作業ワークフローを活用すべきです。そうすれば、広範囲に広がった大規模な管理者チームでも、問題を解決するときに効果的にコミュニケートできます。
ダウンタイムをもたらす脅威を完全に排除することは決してできないと言っても過言ではありません。しかし、最新技術による監視とインシデント管理のソリューションは、小売業者が大規模なサービス障害の話題の提供者にならないために重要な役割を果たします。