MTTR は「平均再起動時間」ではありません
早く失敗することが、今日のスピードのモットーです。 DevOps であれビジネスであれ、デジタル経済で事業を運営する前提として、可能な限り完璧に近い稼働時間が求められます。
この哲学の理論は良いのですが、実際には結果は単なる失敗に終わることが多いのです。 根本原因 (MTTR) の発見に重点を置かず、可用性 (稼働時間) の確保だけに重点を置くことで、貴重なデータが前例のない速度で失われています。 現実を直視しましょう。稼働時間だけが重要であれば、 MTTR は平均解決時間ではなく平均再起動時間になります。 そして、解決策、つまりダウンタイムの理由がなければ、ダウンタイムの再発を防ぐことはできません。
このアプローチはビジネスに有害です。
ご存知のとおり、パケットを落とすのではなく、ペニーの一部を落とすのです。 そして、取引から小銭を吸い上げて何百万ドルもの金を蓄えるという古典的な犯罪の手法が教えてくれるように、小銭のどんな端数も大切なのです。 コンポーネント、サービス、サーバーが応答に失敗するたびに、経験的価値と存在的価値の両方が失われます。 消費者はパフォーマンスの低下やダウンタイムを許容しませんが、ビジネス元帳もどちらも許容できません。
スループットと帯域幅について少しでもご存知であれば、両方の計算の基礎は、基盤となるシステムで処理できる 1 秒あたりのパケット数にあることをご存知でしょう。 これはネットワークに限ったことではなく、トランザクションとやり取りするすべてのコンポーネントに当てはまります。 アプリ。applicationサービス。 ルーター。 スイッチ。 データベース。 ネットワーク接続がある場合、同じ計算が適用され、パケットを渡す能力によって制約されます。
警告： 数学はこれから
今日のネットワークの速度により、毎秒数百万パケットの速度でまさにそれが実行できるようになります。 もちろん、ビジネス トランザクションは主に (文字通り) HTTP トランザクションの Web を介して実行され、各トランザクションはビジネスの実行に不可欠な情報を渡します。 トランザクションを実行するために必要なパケットの数は、必要なデータの量によって異なります。 平均的なパケットは 1500 バイトのデータ (MTU) を運びます。 したがって、トランザクションを表す JSON ペイロードを運ぶ HTTP ベースのメッセージに 4500 バイト (もちろん暗号化後) が必要な場合、それは約 3 つのパケットになります。 したがって、寛大に考えて、典型的なデジタル ビジネス トランザクションには 5 つのパケットが必要であるとしましょう。 10Gbps ネットワークは、1 秒あたり 15M パケット弱を処理できます。 十分な計算能力が利用可能であると仮定すると、それは 300 万件のトランザクションに相当すると言えます。 すべての取引の価値が 1 ペニーの何分の 1 (3 分の 1) であると仮定しましょう。 それは1秒あたり100万ドルです。
現在、実際にその速度や量で取引を処理できる人はいません。 ほとんどの企業が必要としない速度で間違いなくデータを処理している Visa でさえ、その処理能力は 1 秒あたり約 24,000 件のトランザクションであると主張しています。 これらの取引の価値が同じだと仮定すると、1 セントの 3 分の 1 ですが、それでも 1 秒あたり 8,000 ドルになります。
重要なのは、ルーター、スイッチ、ネットワークおよびapplicationサービス インフラストラクチャ、アプリケーション インフラストラクチャ、およびコンポーネントで構成されるトランザクション チェーンの障害は、非常に悪いことであるということです。 障害が発生するとパケットが処理されなくなり、それによって得られるお金も失われるため、コストがかかります。 そして、デジタル経済には、パケットの通過に依存しない部分は存在しません。
これまでのところ、答えは「失敗を早く」というマントラにあります。つまり、X や Y や Z など、障害が発生したコンポーネントの新しいインスタンスを起動するだけです。 しかし、そのコンポーネントが故障したのは*何らかの理由*があり、その理由を明らかにして対処することが最も重要です。 素早く。 なぜなら、障害から復旧までの間にはビジネス価値を犠牲にする高価な数秒がまだあるからです。 一度失敗したら、また失敗する可能性が高いです。 そしてまた。
可視性: MTTRの基盤となるもの
これが、デジタル経済で成功するには可視性が極めて重要である理由です。 可視性があれば、すべての運用担当者が障害の原因を見つけて修復できるようになるからです。 残念ながら、速度のために視認性が犠牲になることがよくあります。 取引の文字通りのスピードではなく、価値が実現されるまでの時間です。 アプリをより早く、より頻繁に市場に投入しようと急いでいるため、障害を軽減するために必要な可視性を実現するための投資が十分に行われていませんでした。
実際、DevOps の「失敗を早くする」哲学は、その失敗に対する対応であると主張する人もいるかもしれません。 障害の原因を見つけて対処する能力がなければ、DevOps は時間を無駄にするよりも可用性を回復する方がよいと判断します。 組織がapplicationsの展開にマルチクラウド アプローチを採用するにつれて、その能力はますます実現が困難になっています。
2018 年には、マルチクラウドの可視性の課題を挙げた回答者は 3 分の 1 未満 (31%) でしたが、 2019 年には3 分の 1 以上 (39%) に急増し、パフォーマンスやセキュリティと並んでマルチクラウドの最大の課題となりました。 可視性は、監視、分析、アラートを統合して、いつでもシステムの状態に関する貴重な洞察を提供する包括的な「可観測性」の重要なコンポーネントです。 これは障害発生時に特に重要です。システムの状態が複数の IT 領域に分散しているため、再起動だけでなく迅速な解決につながる情報を共有できるかどうかわからないからです。
分散トレースを通じて価値を付加するサービス メッシュの機能は、可視性を実現する優れた例です。 しかし、コンテナ化された世界で実行されるapplicationsを拡張し、保護するapplicationサービスのチェーン全体を含めるようにこれを拡張する必要があります。 これには、実行チェーンの一部となる可能性のあるパブリック クラウドで実行される分散コンポーネントとapplicationsが含まれます。 ダウンタイムやパフォーマンスの低下を引き起こす問題を見つけて対処するには、環境、インフラストラクチャ、applications全体の可視性が必要です。
組織が MTT再起動ではなく MTT解決に基づいて成功を測定できるようにするには、可視性が不可欠です。