およそ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が起きた場合でも。