サイト信頼性エンジニア（SRE）は比較的新しい職種で、通常はエンジニアリング部門または運用部門に属し、その名のとおりサイトの信頼性維持に重点を置きます。一般に、これにはアプリケーションの可用性だけでなく、パフォーマンスも含まれます。現在では、応答しないアプリケーションはほとんどのエンドユーザーにとって利用できないも同然だからです。
Perusing Catchpointの2018年版SREレポートを読んでいて、サービスレベル指標とSREメトリクスを比較したグラフが目に留まりました。通常、「可用性」が最上位のサービスレベル指標として示されている場合、メトリクスには「稼働時間」または「ダウンタイム」も含まれます。しかし、この調査のSREについてはそうではありませんでした。
自社のサービスにとって最も重要なサービスレベル指標を尋ねたところ、84%が「エンドユーザーの可用性」を第1位に挙げ、圧倒的な結果となりました。第2位はレイテンシで61%、僅差の第3位はエラー率で60%でした。レポートでエンドユーザーの応答時間と説明されているパフォーマンスも、58%という高い回答率を記録しました。
次に、成功を定義するために使用される指標に注目してください。インフラストラクチャと運用の分野では、「稼働時間」のような指標や、「ファイブナイン」のような印象的な表現がよく使われます。
一方、SREはインシデント発生率とMTTRを成功の指標とする傾向があります。同じレポートによると、SREの41%がSREになる前に「DevOpsエンジニア」を務めていたため、これは意外なことではありません。DevOps自体も、ダウンタイムは発生するものという前提に立っているため、稼働時間の算出よりもMTTRを重視します。重要なのは、ダウンタイムを完全に回避しようとして時間を費やすのではなく、迅速に解決して最小限に抑えることです。
とはいえ、鋭い読者なら、MTTRを最小化することがダウンタイムの最小化につながるとお気づきでしょう。解決が早いほど、ダウンタイムは短くなります。
両者の微妙な違いは、人は評価指標に合わせて最適化する傾向があるという点です。コードの行数で評価されれば、必要かどうかにかかわらず、大量のコードを書くようになります。セキュリティインシデントで評価されれば、あらゆるものを厳重に制限し、侵害につながりかねない変更には声高に「NO」を突きつけるでしょう。稼働時間で評価すれば、運用部門はシステムの稼働と可用性の維持に注力しますが、MTTRを短縮するシステムやアプリケーションの設計と計測機能の実装には注力しません。
これは、運用への取り組み方を変えるというDevOpsの「文化的」側面の1つであり、NetOpsにも引き継ぐ必要があります。稼働時間の最適化だけを続けていると、平均解決時間を短縮し、ダウンタイムを最小限に抑えるという目標の達成につながるアラート機能やオブザーバビリティ（監視や堅牢なログ記録など）を導入する機会を逃してしまいます。
ログを調べるだけでは、たとえ一元化されていても、問題の核心を突き止めて解決する効率的な手段とはいえません。データパス全体（ネットワーク、インフラストラクチャ、アプリケーション）にわたり、容量、接続性、パフォーマンスなど、可用性に影響する主要な変数をリアルタイムで監視し、アラートを発することで、システムやサービスの性能低下や突発的な障害を把握でき、問題解決に要する時間を確実に短縮できます。
NetOpsは、本番パイプラインの信頼性に関してこのアプローチを採用する必要があります。避けられない障害に対処するうえで全体としてより優れたアプローチであると同時に、DevOpsチームのアプローチとも整合するためです。そもそも、目標をファイブナインにとどめたのには理由があります。どれほど努力しても障害は発生するものであり、完璧は不可能だと認識しているからです。
成功指標を稼働時間／停止時間からMTTRへ移行することで、チーム間の連携と、本番パイプライン全体でのオブザーバビリティツールの活用が促進されます。調査で、監視・アラートツールがSREの「必須ツール」の最上位に挙げられたのには理由があります。エラーやインシデントの通知を目的とするオブザーバビリティとチーム間の連携を組み合わせることで、NetOps、DevOps、アプリケーション開発の各チームが、アプリケーションの高速性と可用性を維持するという目標を達成しやすくなります。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。