Googleが提唱するSREとは何か。SREの信頼性とは
xOps領域のプラットフォーマーを目指して幅広いサービスを展開しているテックカンパニー、スリーシェイク。例えば、藏本氏が携わっている「Sreake」もその一つ。SreakeはGoogleが提唱するSREの考え方に従って、AWSやGoogleクラウドを利用しているお客さまサービスの技術戦略、設計、構築、運用までをワンストップで支援するサービスである。
「クラウドネイティブな技術領域に強みを持つエンジニアが、お客さまチームのメンバーという立ち位置で最新技術の提案から運用までをトータルに支援する」と藏本氏は説明する。しかも技術的な対応に閉じるのではなく、SREチームの組成や文化の定着化、技術者の採用・育成コンサルティングなども合わせてサービスすることができるのだ。
Googleが提唱するSREの考え方に従っているとはいえ、SRE本の序章に書かれたベンジャミン・トレイナー・スロス氏によるSREの定義をイメージするのは難しい。そこでスリーシェイクではSREを「効率的なサービス運用をベースにサービスの信頼性とイノベーションスピードとのバランスを取りながら、ユーザーに提供する価値を最大化すること。またはそれを行うチームだと考えることにした」と藏本氏は語る。
SREの信頼性について、Googleでは次の3点を提唱している。
1点目は、「いかなるシステムにおいても最も重要な機能は信頼性である」こと。「これは信頼性を損なわない範囲で機能提供をしようという考え方です」（藏本氏）
2点目は、「監視が信頼性を決めるのではない。ユーザーが決めるのだ」。SREの考え方が浸透してきているので、信頼性＝CPU使用率と考える人は少なくなっているが、「信頼性はシステムの状態ではなく、ユーザー経験に基づいて定義されるべきだ」と藏本氏は語る。
CUJ（クリティカルユーザジャーニー：重要な顧客体験）という言葉にあるように、対象とするサービスにおいて、重要な顧客体験に焦点を当て、その顧客体験に及ぼす影響をもとに、監視項目は定義されるべきだとアドバイスする。「システムの状態ではなく。ユーザー影響に基づいて監視を行うことで。不要なアラート対応の削減や、稼働時間の確保が見込めます」（藏本氏）
3点目は、「可用性100％を信頼性の目標とすることは間違いである」。過度の信頼性はコストに跳ね返るからだ。「仮にフォーナインからファイブナインに可用性を高めたとしても、その効果をユーザーが気づくのは難しいことからもわかるでしょう」（藏本氏）
システム運用において信頼性と機能開発はトレードオフの関係にある。運用側は安定したシステム提供を優先するため、できるだけ変更したくないという考えになる。なぜならシステム障害の7割は変更により発生すると言われているからだ。
一方の開発側はビジネスサイドの要望に応えて、新しい機能をより早く提供したいと考える。つまり運用と開発ではそれぞれが求めるインセンティブが異なる。だからバランスを取ることが難しいのである。
信頼性とイノベーションスピードのバランスを取るためのカギを握る考え方が、SRE原則でうたわれている「リスクの受容」と「SLOの定義」である。「信頼性を定量化し、定量化された信頼性に基づき、開発と運用が同じ基準でリスクを管理する。こうすることで信頼性とイノベーションスピードのバランスを取ることができる」と藏本氏は説明する。
信頼性の定量化はSLI（サービスレベル指標）、SLO（サービスレベル目標）、エラー予算を定義することから始まる。SLIとはシステムの善しあしを判断するための指標である。SLOとはサービスレベルに対する内的な目標値で、SLIを基に定義される。エラー予算は許容できる不具合の割合で、1-SLOで表すことができる。「エラー予算を基にエラー予算ポリシーを定め、ポリシーに従って対応することで、開発、運用が同じ基準を用いたリスク管理を実行できる」（藏本氏）
