Googleが解説 - 他社のSRE実践はなぜ誤りなのか

GoogleのCRE(Customer Reliability Engineer)であるStephen Thorne氏が先日のDevOps Enterprise Summit Londonで講演し、SRE(Site Reliability Engineering)とは何か、その基本的な前提とメリットを理解できていない組織がいかに多いか、などについて解説した[スライドのPDF]。氏がこれまでに他の組織で見たおもな誤解は、早期の障害検出に重点を置いたSLO(Service Level Objective)や、あるいは過去のインシデントの金銭的保証に使用するSLA(Service Level Agreement)との混同、エラー予算を執行しない、SREチームの活動の少なくとも50パーセントをシステムやツールの改善に費やさず、“消防活動”という名の運用上の苦役に没頭させる、といったものだ。

SLOは障害を早期に、理想的にはユーザの目に留まる前に発見する上で、基本的な役割を果たす。優れたSLOは、ユーザのメリット(サービスの可用性や応答時間など)と連携することにより、システム(の動作)がユーザニーズを満たしているかどうかを反映する。CPU使用率やネットワークスループットなどのリソース使用率の監視も必要ではあるが、それがSLOの本質ではない。Thorne氏はこれを簡潔に、“ユーザが満足すればSLOの役目は果たされる”、と表現している。Googleの典型的なSLOは次のようなものだ。

• 1ヶ月間99.9パーセントの稼働率(1ヶ月のダウンタイムが43分)
• 1ヶ月間のHTTP要求の99.99パーセントが200 OKで成功する
• 50パーセントのHTTP要求が300ms以内に返答される

一方のSLAは、一般的にはユーザがすでにサービスに対して不満を抱いている場合に意味を持つものであるため、システムの信頼性を積極的に向上するものではない。さらにSLAは、誤ったインセンティブにつながる可能性もある。例えば、Eメールの障害修正に2時間のSLAを設定し、重大な運用障害の修正に1日のSLAを設定した場合、運用上の問題が優先されるべきであるにも関わらず、1件(あるいはそれ以上)のEメールの問題が先に対処される可能性があるのだ。

SLOを定義するだけでは不十分だ、とThorne氏は警告する。(金銭的保証ではなく)対処方法のルールを明確に設定しておけば、システムがSLOのしきい値に近づく前に、エラー予算を執行してSLO会議を招集することが可能になる。これはまた、システムがユーザニーズを満たせなかった場合の運用と開発の対立を最小化する。“エラー予算とは、完全な信頼性と私たちのSLOとのギャップなのです”、とThrone氏は言う。Googleの典型的なエラー予算ポリシは、エラー予算を使い果たした(例えば、今月のダウンタイムが43分を越えた)アプリケーションには新機能のローンチを許可しないか、あるいは、前回の事後解析で明らかになった修正作業を特別なスプリントを用意して実施する、というものだ。

しかしながらThorne氏は、Googleでうまくいったことがどの組織でも有効だとは限らないと強調する。“SREには、所定のコストにおいて許容可能なレベルの障害と、デリバリ速度とをバランスさせた結果を伴ったSLOが必要です。”正確なSLOとポリシは、- Googleからのコピー・アンド・ペーストではなく — 組織にとって満足のいくものであると同時に、高尚な目標を設定したり、非生産性をもたらす可能性のあるような厳しい処罰ではなく、ユーザエクスペリエンスの継続的な改善を重視したものでなくてはならない。Throne氏はその例として、レコメンデーションシステムの処置時間削減に取り組んでいるある組織を紹介した。そのシステムでは、ユーザがこれらのレコメンデーションを見るのはサイトを再度訪れた場合のみであり、それは平均で6時間後であることが判明した。必要なSLOは、すべてのレコメンデーションを6時間以内に終了する、というものだったのだ。これにより、それまでレスポンス時間が遅いという既知の“問題”に取り組んでいた3人の技術者を半減することができた。

SREチームに対して、“毎日”(多くの場合は計画外)の運用作業と、雑務(あるいは“消防活動”)に対する計画内作業とをバランスする権限を与えること、それがSREの第3のキーだ、とThrome氏は言う。Googleにおいては、SRE活動の少なくとも50パーセントがプロジェクトの作業 — 新たなシステムのアーキテクチャに対する早い段階でのコンサルティングによるレジリエンス上のアンチパターンの指摘(と後段での労力の回避し、監視機能の改善、反復的なタスクの自動化、あるいは事後的な是正措置の実施の調整 — に費やされている、という意味となる。

Throne氏はさらに、SREを実施する上での明らかなアンチパターンとして、運用チームからSREチームへの単なる名称変更、SREの思想や成功メカニズム(SLO、エラー予算ポリシ、ワークロードのバランス)を最初に導入せずにSREエンジニアを雇用すること、などをあげている。

Throne氏によると、SREへの正しい道を歩むための重要なステップは次の５つである。

1. 状況に対応した、ユーザ重視のSLOを定義する
2. 賢明なエラー予算ポリシを定義する
3. SREを(内部ないし外部から)雇用し、リーダシップによるサポートを通じて権限を付与する
4. SREに対して、SLOの微調整とエラー予算ポリシの実施を許可する
5. ミッションクリティカルなシステムの信頼性に対する責任をSREチームに割り当て、その他のシステムは対応する開発チームの責任とする

Googleは、このSREの規律を数年前から社内的に開発および拡張し、そこで学んだ教訓をthe SRE bookとして結実させた。Thorne氏によると、付属書となるSREワークブックが今月下旬にリリースされる予定である。

最新情報: 新しいSREワークブックは2018年8月23日まで、このリンク(PDF)から無償で入手できる。