SREの第一歩は非エンジニアも含めた「SREの理解」から
Googleが提唱した「SRE」は、いわばDevOpsの実践法であり、ツールや考え方の共通化、チーム構成などによって組織のサイロを減らそうというものだ。さらにサービスレベル目標（SLO：Service Level Objective）などの設定により「失敗を受け入れる」こと、カナリアリリースや小さいことから始める「段階的な変更の実装」、ツールの有効利用などによる「自動化の活用」、Observability（可観測性）などの「測定」と、意識すべきポイントは多岐にわたる。
それらを踏まえつつも、SREを始める時にまず行うべきこととして、Mackerelチーム リードSREの古川氏は「SREの理解」と「SLOの設定・運用」の2点をあげた。その際、非エンジニアのメンバーにSREを身近に感じてもらうには、分厚い専門書を渡すだけでは難しい。多岐にわたる項目の中から、最初にSREの根幹となるSLOやエラーバジェットなどを紹介すると比較的理解してもらいやすいという。
「その際、最も重要なのが『開発パフォーマンス』と『信頼性』のトレードオフについて理解してもらうことだ。SREは信頼性に責任を持つことといわれるが、Opsだけでは達成できず、他部門や経営陣の協力が欠かせない。もしDevは『開発パフォーマンス』だけ、Opsが『信頼性』だけと、それぞれの目標に邁進すれば、相互に邪魔し合う関係になってしまう。これがDevOpsがうまくいかなくなる大きな原因の一つになっている」と古川氏は強調する。
これを解決するには、「開発パフォーマンス」と「信頼性」のバランスをとりながら、双方を高めてユーザー価値を最大化するという目標の共有が不可欠となる。DevとOps、そしてビジネス、セキュリティにも広げ、みんなでインセンティブを揃えてプロダクトに貢献する。古川氏は、そのように“仲間”をつくっていく流れを重視しているという。
こうした理解を得た上で、プロダクトに対して自社のサービスレベル（サービス品質）に関する目標・評価基準としてSLOを定めることになる。SLOは、DevとOpsで共通の評価指標・インターフェイスとなり、議論する際の重要な手がかりとなる。
プロダクトマネージャーにSLOのオーナーシップをもってもらうのが望ましいが、はじめはSLOの目標値をどのくらいで設定すべきなのか見当もつかないだろう。そこで、SREはSLO導入においてプロダクトマネージャーを支援する必要がある。たとえば、体制の運用を支援しやすいチーム構成を考えたり、SLOの定量的な判断基準の参考情報を提供したりして、プロダクトマネージャーがSLOの運用をする文化を作っていくというわけだ。
はてなにおける組織づくりと文化形成の進め方
では、SREを運用しやすいチーム構成とはどのようなものなのか。古川氏は「人数やプロダクトの規模や数、性質、社内でのDevOpsの理解度など、組織によって全く違う。結論としては、組織にあった方法を自分たちで見つけるほかない」と前置きした上で、はてなの事例を紹介した。
まず状況として、はてなは取り扱うプロダクト数が多く、さらにtoC向け自社開発やtoB向けSaaS、受託開発など多様化が進んでいる。2001年に開始された「人力検索はてな」などレガシーなサービスがあり、現在はAWSメインながら、一部はオンプレミスで運用されるなど考慮すべき事項も多い。
2017年以前は、SREs（当時はSREという職種ではないが、便宜上SREsと表記）がいるOpsチームでプロダクトの運用を担当していた。オンプレ環境の基盤が古く、しかも自動化が不十分で、長年Opsチームしか知らない・触れられない状態にあった。そのためDevチームはアラートやインフラを自前で設定できず、OpsチームにはタスクがToil（労苦）として溜まり、基盤を改善できずにますます古くなり……という負のループに陥っていた。
「なおSREのプラクティスでは、エラーバジェットポリシーを設定し、Toilを50％以下に抑えることが重要とされている。実際、負のループに陥ると抜け出すのが難しい。はてなも、運用が開発のボトルネックになって、負のループを断ち切るのに約3年を費やすことになった」と古川氏は語り、「抜け出すには、Opsチームの時間を確保する必要があり、そのためにはDevチームがある程度自分で運用できることが望ましく、不要なアラートの抑止はもとより、クラウド移行・コンテナ化によってクラウドネイティブ化も重要になる」と強調した。
その際に行ったのが、プロダクトチームにSREが入って、内側から変えるという「Embedded SRE」と呼ばれる形態への構成変更だ。はてなではまずMackerelチームから実施した後、他プロダクトチームにも展開、その後は前述のような「SREの理解を得る活動」をチームごとに行っていった。
「Devチームが自律的に運用できる箇所が増加するとOpsチームの余裕ができ、レガシー基盤の撤退や基盤改善、クラウド化に時間を費やせるようになった。さらにOpsチームが基盤開発をするようになれば、Devチームの自立的な運用負荷が軽減され、開発パフォーマンスに寄与できる。そうしたチーム運用で、互いにサポートし合うことで利益が自ら得られるループができ、SREのルールづくりにも積極的になっていった」と古川氏は経緯を語り、「いいループを生むためにはインセンティブの設計が重要」と語った。
そして一連の取り組みを振り返り、古川氏は「チームの中にSREsが入る『Embedded SRE』は、外からではなく中から変える形となりDevOps文化形成に大変に有効だった。外からだと、Devチームは『運用を押し付けられた』という印象を持ちがちだが、内側に入ることで『一緒に変えていこう』という意思表示を示せた」と評する。
実際、Devチームが自分たちでアラートを設定・確認するようになり、スプリント会ではSLOを確認するようになった。さらにロードマップで運用タスクが議論されるようになり、チーム内で自主的にやっていくことが当たり前になったという。
ただし、「Embedded SRE」はデメリットもある。チームごとにSREsが配置されるため、人数がある程度必要になり、ともすればそれがボトルネックになる可能性がある。そして、自立的に運用できるようになったことで、Devチームだけで情報が閉じやすくなるため、独自ルールやサイロ化には注意が必要だ。
今後の組織づくりについて、古川氏は、「まずはOps＆プラットフォームチームを、プロダクトOpsを担当する『プロダクトSREチーム』と基盤開発およびその運用を担う『プラットフォームチーム』に分けることで運用しやすさを高めたい」と語る。また、チーム内の「Embedded SRE」に加え、組織全体を横断的に見るSREを配置して二層構造とすることで制御しやすさを高めることも検討中だ。その場合、Devチームの自立度・運用成熟度やSREsの人数、ビジネス上の優先度で判断しながら、数の問題を解決しながら進めていくという。
本セッションの動画をMackerel Webサイトで無料公開中！
「Mackerel開発チームのリードSREが考える働き方と組織作り」と題し行われたセッションの模様を動画にし、一般公開中です。Developers Summit 2021 Summerに参加された方も、ご覧いただけなかった方も、ぜひご覧ください。
