稼働時間は忘れてください。 低いMTTRはITの新たな「5 9」です
停止はコストがかかります。 それが最終的に攻撃の結果なのか、ソフトウェアやハードウェアの障害の結果なのかは、それほど重要ではありません。 現代のデジタル経済では、API や Web アプリへの依存度が高まっているため、ダウンタイムの 1 分あたりのコストが増加しています。
一部の人にとって、それらのコストは驚くほど大きいです。 2013 年に Amazon が 40 分間ダウンタイムを起こし、264 万ドルの損害を被ったと推定されています。 計算したくない人のために言っておくと、これは1 秒あたり1,100 ドルになります。 それが恐ろしいと思うなら、同じ年に5分間のダウンタイムで1分あたり10万9千ドルの損失を被ったGoogleを考えてみてください。 （または1 秒あたり 1,816.67 ドル）、合計で 545,000 ドルという驚異的な額になります。 5分間。 技術的には、彼らが被った被害がそれだけであれば、それが IT 部門が達成すべき自慢の「5 9s」です。
停止はどのくらいの頻度で発生しますか? どうやら、あまりにも頻繁すぎるようです。 まだ見たことがない方は、 pingdom のライブ停止マップをご覧ください。 これは、世界中の 70 万人を超えるユーザーから収集されたデータから構築されています。 この不気味なほど興味深い地図には、過去 1 時間に世界中で発生した停電が表示されています。 停電を描写する明るいフラッシュは素敵な演出で、ユーザーに与える衝撃を本当に印象付けます。
つまり、望まれないものである。
デジタル経済はこの問題を悪化させます。 今年初め、 Amazon の S3 の障害により、多数の顧客のアプリや Web サイトが停止した。 しかし、この問題をパブリック クラウド プロバイダーのせいにしないためにも、 builtwith.com のサイトをちょっと調べてみれば、その考えはすぐに消え去るでしょう。 他のサイトの稼働時間への依存を考慮すると、CDN と API を活用しているサイトの割合は驚くほど高いと言えるでしょう。 少なくとも 1 つの外部 API またはサービスに依存していないサイトを見つけるのは困難です。そのため、外部サービスがダウンするとサイトもダウンするため、ダウンタイムの可能性が高まります。
基本的に、100% の可用性を達成することは不可能であるため、IT は「5 9s」に落ち着きました。 経済がデジタル領域に移行したことにより、1秒あたりのコストが急騰している今日、重要なのはダウンタイムを最小限に抑えることです。 言い換えれば、平均解決時間 (MTTR) を短くすることを要求する目標を設定することは、ダウンタイムをなくすことと同じくらい、あるいはそれ以上に重要です。
Puppet Labs の2016 State of DevOps レポートにおける「高パフォーマンス組織」の重要な評価基準の 1 つは MTTR です。これは、サービス インシデント (計画外の停止やサービス障害など) が発生したときにサービスを復旧するまでにかかる時間として定義されます。 最もパフォーマンスの高い組織（レポートの評価に基づく）では1 時間未満で完了しますが、中程度および低いパフォーマンスの組織では「1 日未満」で完了します。 「言い換えれば」とレポートは指摘し、「高業績企業は低業績企業よりも MTTR が 24 倍速かった」と述べています。
質問は「サービス インシデントがあるかどうか」ではなかったことに気付くでしょう。 それはサービスインシデントが発生したときです。 インシデントが発生することが前提であるため、解決までの時間を最小限に抑えることが重要です。 IHS による 2016 年の調査では、「平均して、調査回答者は 1 か月あたり 5 件のダウンタイム イベントと 27 時間のダウンタイムを経験している」と報告されており、平均的な中規模組織では 1 ドル、大規模組織では最大 6,000 万ドルのコストが発生しています。
マーフィーの法則がムーアとコンウェイに依然として当てはまると仮定すると、答えは、避けられないダウンタイムに関連する時間 (およびコスト) を削減するために MTTR を最小限に抑えることです。
つまり、可視性、つまり監視が重要になります。 監視はたくさん。 しかし、Web サイトや Web アプリ、API だけではなく、スタック全体を監視する必要があります。 ネットワークからアプリ サービス、アプリケーション自体まで。 それは誰もがやっていることではないし、やっているとしても一貫性がないように見える。
2017 年のxMatters|Atlassian DevOps 成熟度調査では、回答者の 50% が「運用部門が重大なインシデントを宣言するまで待つ」と回答しています。 驚くべきことに、企業の 3 分の 1 が「顧客からサービス中断について知る」のです。
デジタル経済では、一秒一秒が重要です。 お金がかかるからというだけでなく、将来の収益にも悪影響を与えるからです。 ブランド価値と顧客からの信頼が低下すると、購入数やユーザー数が減少し、最終的には成長が停滞します。 それは組織が進むべき方向ではありません。
監視は、停止の原因となる問題を検出するための最初のステップです。 しかし、監視だけでは MTTR の向上には役立ちません。 コミュニケーションはそうします。 関係する関係者にできるだけ早く警告し、問題のトラブルシューティングに必要な情報を提供することで、解決までの時間を短縮できます。 つまり、DevOps の 4 つの主要な柱の 1 つである共有がMTTR を向上させる鍵となります。 企業レベルで DevOps の他の側面をまだ取り入れていない場合でも、共有はトップレベルの取り組みに引き上げることを検討する必要があります。 ChatOps や電子メール、モバイル アプリ、動的に更新される Wiki ページなど、どのような手段であっても、監視を通じて収集された情報を組織全体で広く共有することが不可欠です。
スイッチやサーバーの一時的な問題は一見無害に思えるかもしれませんが、放置しておくと、重要なアプリが依存するサービスの半分が機能しなくなる可能性があります。 Viavi が実施した 2017 年のネットワークの現状に関する調査では、ネットワークおよびシステム管理者の 65% が、アプリケーションの問題のトラブルシューティングにおける最大の課題として「問題の原因がネットワーク、システム、またはアプリのいずれであるかを判断すること」を挙げています。 可視性を高め、フルスタックの監視を行うことは、根本原因の発見に責任を負う人が、データ パス内のすべてのコンポーネントの状態と健全性に関するできるだけ多くの情報を手元に確保できるようにすることで、この課題に対処する 1 つの方法です。
可視性は IT の将来にとって重要です。 これがなければ、停止が発生する前にそれを修復するために必要なレベルの自動化を達成することはできません。 可視性がなければ、MTTR を有意義な方法で削減することはできません。 それがなければ、持続可能な速度でビジネスを成長させ続けることはできません。
可視性は、セキュリティと同様に、IT を前進させる戦略スタックにおいて最重要視されるべきです。 障害は発生するものであり、可視性があれば、組織はブランドや収益へのダメージを最小限に抑えながら、迅速かつ効率的に復旧できます。