ブログ

NetOps は可用性を実現するために MTTR に重点を置く SRE に注目

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2018年5月14日公開

サイト信頼性エンジニア (SRE) は、通常はエンジニアリングまたは運用部門内の比較的新しい役割であり、当然のことながら、サイトの信頼性の維持に重点を置いています。 これは通常、アプリケーションの可用性を意味しますが、パフォーマンスも含まれます。 これは当然のことです。なぜなら、応答しないアプリは、今日のほとんどのエンドユーザーによって使用不可とみなされるからです。

Catchpoint の 2018 SRE レポートを熟読していると、サービス レベル インジケーターと SRE メトリックを比較したグラフに驚きました。 通常、「可用性」を最上位のサービス レベル指標として見る場合、「稼働時間」または「停止時間」もメトリックとして見ます。 この調査では、SRE についてはそうではありません。 

自社のサービスにとって最も重要なサービス レベル指標は何かと尋ねたところ、圧倒的多数の 84% が「エンド ユーザーの可用性」を第 1 位と回答しました。 レイテンシは 61% で 2 位、エラー率は 60% で僅差で 3 位でした。 レポートではエンドユーザーの応答時間として説明されているパフォーマンスは、58%という驚異的な回答を獲得しました。

ここで、成功を定義するために使用される指標に注目してください。 インフラストラクチャと運用の世界では、「稼働時間」などの指標や「5 9s」などのキャッチーなフレーズを目にすることに慣れています。

SRE は、代わりにインシデント率と MTTR の観点から成功を評価する傾向があります。 同じレポートでは、SRE の 41% が SRE になる前は「DevOps エンジニア」の役割を担っていたと述べられているため、これは驚くべきことではありません。 DevOps 自体は、ダウンタイムがあることが想定されているため、アップタイムの計算よりも MTTR を重視します。 重要なのは、それを回避しようとして時間を無駄にするのではなく、迅速に解決してそれを最小限に抑えることです。

それでも、賢明な読者は、MTTR を最小限に抑えることでダウンタイムも最小限に抑えられることに気付くでしょう。 解決が速くなり、ダウンタイムが短縮されます。

両者の微妙な違いは、人間は評価されるものに合わせて最適化する傾向があるということです。 コードの行数で評価される場合、必要かどうかに関わらず、大量のコード行を書くことになります。 セキュリティ インシデントを評価する場合、すべてをロックダウンし、侵害を助長する可能性のある変更にはすべて「NO」を叫ぶことになります。 稼働時間で人員を測定する場合、運用部門はシステムの稼働状態と可用性を維持することに重点を置きますが、MTTR を短縮するシステムとアプリケーションの設計と実装には重点を置きません。

これは DevOps の「文化的」側面の 1 つであり、運用へのアプローチ方法の変更であり、NetOps にも引き継ぐ必要があります。 稼働時間を最適化し続けると、平均解決時間を短縮し、ダウンタイムを最小限に抑えるという目標を達成するアラートと可観測性（監視や堅牢なログ記録など）を導入する機会を逃してしまいます。

ログを徹底的に調べることは、たとえ集中管理されたものであっても、問題の本質をつかんで解決するための効率的な手段ではありません。 容量、接続性、パフォーマンスなど、データ パス全体 (ネットワーク、インフラストラクチャ、アプリケーション) の可用性に影響を与える主要な変数をリアルタイムで監視およびアラートすることで、システムやサービスが劣化したり突然障害が発生したりしていることに気付いた場合に、問題解決にかかる時間が確実に短縮されます。

NetOps は、生産パイプラインの信頼性に関してこのアプローチを採用する必要があります。これは、避けられない障害に対処するための全体的に優れたアプローチであり、 DevOps の対応するアプローチと一致しているためです。 結局のところ、私たちが 5 9 のみを達成したのには理由があるのではないでしょうか? なぜなら、どれだけ努力しても失敗は起こるし、完璧は不可能だと認識したからです。

成功の指標として稼働時間/停止時間から MTTR に移行すると、チーム間のコラボレーションと、生産パイプライン全体にわたる観測可能性ツールの使用が促進されます。 調査において、監視およびアラート ツールが SRE にとって「必須ツール」のトップに挙げられたのには理由があります。 可観測性 (エラー/インシデントに関するアラートを目標とする) とコラボレーションを組み合わせることで、NetOps、DevOps、App Dev など、すべての担当者がアプリの高速性と可用性を維持するという目標を達成できるようになります。