アドベントカレンダー3日目：SREを読んでみた「イントロダクション」編②

前回はSREの「イントロダクション」の途中までを読みました。今回はその続きからです。
前回の内容を振り返ると、従来のシスアド方式でのサービス管理は、手作業による運用の為、システムの巨大化に伴い、運用コストが増大していくこと、そして、シスアドと開発の分断が生まれてしまうことがわかりました。
特にチームの分断は対立を生み、病的な状態に陥ることさえあることがわかりました。
では、それらの問題を解決するためのSREのアプローチはどういったものなのでしょうか？

選ばれたのはソフトウェアエンジニアでした

Google内で規定されることになったサイトリライアビリティエンジニアリングとは、いったい何なのでしょうか。私の説明は単純明快です。SREとは、ソフトウェアエンジニアに運用チームの設計を依頼した時に出来上がるものです。¹

運用の手作業のコストが増大していくなら、その作業を自動化すればいい。運用システムをエンジニアに書かせればいい。というのがGoogleの回答でした。

サービス管理に対するGoogleのアプローチの主要な構成要素は、SREチームのチーム編成にあると書かれています。

（チームの）50から60％は、Googleのソフトウェアエンジニアです。 <中略> **残りの40%から50%は、Googleのソフトウェアエンジニアリングの必要条件をほぼ満たしている（すなわち、必要なスキルセットの85%から99%）候補者であり、加えてSREにとって有益でありながら、ほとんどのソフトウェアエンジニアが持っていないような一連の技術的スキルを持っているエンジニアです。私たちがさらに求めている技術的スキルの中で最も代表的な物を2つ挙げるなら、間違いなくUNIXシステムの内部とネットワーキング（レイヤー１から３）に関する専門知識です。**¹

そして、すべてのSREに共通するのは、複雑な問題を解決するソフトウェアシステムの開発に対する信念と適正です。¹

SREの手法がGoogleで上手くいったのは、Googleのエンジニアが優秀であることも大きな要因だと思いました。
そんな人たちの知見を得られることは、とてもうれしいですが、今後、読み進めるのが不安になりました。頑張っていこうと思います。

もちろんSREはエンジニアの優秀さだけで成り立っていたわけではなく、SREチーム独自のルール設定もあります。

Google SREチームルール

GoogleではすべてのSREに対して、チケット、オンコール、手作業といった「運用」業務の合計を50%以下にするよう、上限を設けました。¹

Googleにおける大まかなルールは、SREチームは残りの50%の時間を実際に開発を行う為に使わなければならないというものです。¹

この50%という数字が何を根拠としているのかは、ここでは書かれていませんが、運用のコストを増やし続けないためにその上限を設けるというのは、重要なことだなと思いました。

上のルールをどのように実行していくのかが書かれます。

まずは、SREがどのように時間を使っているかを計測しなければなりません。計測ができれば、常に50%以下の時間しか開発作業に費やしていないチームの習慣を変えることができます。これは運用の負担の一部を開発チームに差し戻りたり運用上の責任を増やすことなく、追加の人員をチームに加えることを意味します。¹

これはチーム単位の割合の話ですが、実際に自分がどの程度運用に時間を掛けているのか、（チケット管理など含めて）を計測したことはなかったので、少し書き留めてみようかなと思いました。
また、ソフトウェアエンジニアに運用をさせる強みは、ここにあると思います。
SERチーム内では、運用も開発も両方できる人たちが集まっているので、開発と運用のタスクを人数で管理できます。

SREのメリット

SREの直接的なメリットは、運用システムの構築により、手作業のコストが減ることは、明らかですが、シスアド方式にあった間接的なコストの解消も行うことができると書かれています。

Googleのシステムを自動的に動作させることを追求するために直接コードを修正するので、SREチームは、素早いイノベーションを変更を広く受け入れる特徴を持つこととなります。¹

昨日のまとめで相手のことを考えようとと書きましたが、相手のことを理解するための方法の一つは、相手と同じことをしてみることでした。

そして、運用チームがコード修正できることは、プロダクト開発チームも改善してくれると書かれています。

プロダクト開発チームとSREチームとの間の移動が容易ないことで、グループ全体を相互にトレーニングすることになり、開発者のスキルを改善できるのです。¹

GoogleSREの課題

従来のシスアドによるサービス管理モデルの直接的なコストや間接的なコストをSREは改善できるメリットがありますが、SREにも独自の課題があるそうです。Googleが継続的に抱えているのは、GoogleSRE採用基準が高いため、採用の対象者が少ないこと。そしてSREのアプローチは新しい試みの為、管理層からのサポートが必要であることだそうです。

例えば、エラーバジェットの消費状況によって四半期の残りの期間はリリースをやめるという判断は、管理層が要求しない限りプロダクト開発チームには受け入れられないでしょう。¹

まとめ

• SREチームは、運用システムの開発を行う。
• SREルール：運用コストの上限は50%、そして、全体の50%は開発に当てる。

雑感

今回の内容は管理側の視点で書かれており、エンジニアの経験しかない自分にはまとめるのが難しい感がありました。
今日までのアドベントカレンダーで連載の漫画家は、必ずストックをつくってから、連載すべきと思いました。
イントロダクションは、後一回分ありますが、それで最後です。今度は嘘じゃないっす。

引用

1. Betsy Seyerほか　SRE サイトリライアビリティエンジニアリング　オライリー　5-7