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に参加された方も、ご覧いただけなかった方も、ぜひご覧ください。
はてなの「Mackerel」から始まったSLO運用の実践例
では、どのようにしてSLOを決めていくのか。古川氏のおすすめは「簡易的なものでいいので決めて、まずはさっさと仮運用を始めること」という。
「SLOは定期的に何度も見直すことになるので、ウォーターフォール的に行う必要はない。簡単かつ小さなことからアジャイル的に始めて、見直し、足りなければ追加するという方法だ。ただし、チーム内のライフサイクルの中にSLOの見直しを組み込むのは必須であり重要だ。スクラムをやっているなら、スプリント会などマネージャーを含めたステークホルダーが参加する会で見直すとよいだろう。まずは興味を持ってもらい、やってみようと思わせることが大切だ」
そして、SLOの仮運用の流れを次のように説明した。
（1）SLOを決める
競合サービスや明確な理由があれば、その数値を用いる。不明なら1カ月のエラーバジェットで99～99.9％で始めるのが妥当。
（2）SLIを決める
SLIは「サービスレベル指標（Service Level Indicator）」であり、500系のエラー率やレスポンスタイム、レイテンシなどが一般的。
（3）SLOの見直しをする期間と会を決める
スプリント会などで、プロダクトマネージャーと開発者、SREを含めた場で見直す。最初は1週間に1回、慣れてきたら1カ月に1回くらいの頻度が良い。
（4）上記の内容を明文化しておく
決めた理由は記載しておく必要がある（根拠がない場合は「根拠なし」と記載しておく）。また仮運用中はエラーバジェットポリシーでデプロイの禁止などはしなくてもよい。
なお、はてなのプロダクトであるサーバー監視サービスの「Mackerel」では、レスポンスタイムなどを取得し、500系エラー率を出して可視化・アラートで知らせてくれるため、気軽にSLOの仮運用ができる。そうしたツールを活用するのも良いだろう。その後SLOの運用については、改善や調整が必要になる。
「SLOを改善していくには、SLIの改善・調整が必要になる。その調整によって現実とのすり合わせができたら、エラーバジェットポリシーにデプロイの凍結なども盛り込み、実際の本運用を行っていくとよい」と古川氏は語った。
開発パフォーマンスと信頼性のベストバランスとは
SLOは、まずユーザーの満足度を満たす数値を定め、その上で、細かい調整が必要になる。その時、「開発パフォーマンス」と「信頼性」のトレードオフのバランスが重要なカギになる。たとえば、SLOを99.9％から99.8％に下げたら、どれだけ開発パフォーマンスが上がるのか。逆にエラーバジェットが大量に余っている場合、SLOが低すぎるのではないか。そうした問いに対し、定量的に測定し判断する方法があるという。
SLOの判断をする上で指標になるのが、「開発パフォーマンス指標」だ。エンジニアリングリーダー必読の書『LeanとDevOpsの科学』ではソフトウェアデリバリーのパフォーマンスとして記されており、「リードタイム」「デプロイ頻度」「平均修復時間」「変更失敗率」の4項目が挙げられている。これらの指標からは、変更した際に起こりうる障害の時間が予想できる。
そして、予測された障害時間を定量的に比較し、それを判断の材料としようというわけだ。古川氏は、開発パフォーマンス指標から変更起因障害予想時間（＝デプロイ頻度×変更失敗率×平均修復時間）について仮の数字を入れて計算してみせた。
たとえば、変更失敗が20回のうち1回で5％、1回の障害で30分かかるというパフォーマンスのチームだとする。その場合、稼働日30日として20回デプロイしたとすれば、失敗は1回、障害復旧に30分かかる。つまり、そのチームの変更起因障害予想時間は30日で30分ということになる。
では、SLO側から変更起因障害許容時間（＝（1－SLO）×ウィンドウサイズ×変更起因障害の割合）を計算すると、可用性が99.9％の場合、エラーバジェットが0.1％なので、稼働を30日とすると障害時間が43分。このうち変更起因障害の割合が60％とすると（「SRE Workbook」の障害原因の例を参考に仮定）、変更起因障害許容時間は30日で26分ということになる。これを古川氏らは「はてなSLOモデル」と呼んでいる。
つまり、このチームのパフォーマンス指標から算出される「変更起因障害予想時間」は30分、SLO側から算出される「変更起因障害許容時間」は26分となり、予想時間が許容時間を超えてしまうため、このチームではSLO違反する可能性があると判断される。
それでは、SLOに違反しないようにするためにはどうしたらいいのか。1つ目は変更起因障害予想時間を減らす方法だ。掛け算の数字の中で最も減らしやすいのが「デプロイ頻度」だろう。失敗率を減らす、修復時間を短くするのも限度があるが、デプロイ頻度を下げるにはデプロイしないだけでいい。つまり、エラーバジェットポリシーでデプロイを凍結するのがプラクティスになる。
逆に変更起因障害許容時間を増やす方法もある。その場合は、エラーバジェットや変更起因障害の割合を増やすことになる。というのも、ネットワークやハードウェアの障害はコントロールが難しいため、ある程度の割合は確保する必要がある。そこで、基本的にはユーザーの満足度を毀損しない範囲でSLOを下げることが一番楽な選択肢になり、この場合は、99.8％にすればデプロイの回数も変えずにクリアできる。むしろ、毎日デプロイしても大丈夫というわけだ。
古川氏は「注目してほしいのは、SLOを0.1％下げただけでもエラーバジェットが2倍になっているということだ。変更失敗率を下げるためにバグの発生を2分の1にする、平均修復時間を半分にするというのに比べて、デプロイ回数を2倍確保するバジェットを得られるというのはかなり大きい。こうした感覚をプロダクトマネージャーに理解してもらえるよう、こうした計算を行って協議をしている」と語った。
もちろんこうした数字はあくまで参考値で、予測に過ぎない。しかし、プロダクトマネージャーの目標がイメージしやすくなるのは重要であり、とりわけSLOよりも、「毎日機能をデプロイしたい」という方が伝わりやすい。そして、それを達成するために何をどうすべきなのか、ユーザーの満足度を下げないのか、開発チームのパフォーマンスと信頼性が矛盾した目標になっていないかなどを、具体的に確認できる。
ただし、こうしたことができるのは、あくまで開発パフォーマンス指標が計測できている場合に限られる。それについては、はてなのデベロッパーブログにも掲載されているので参考にするとよいだろう。
古川氏は「チーム構成については、インセンティブ設計や組織論など、ネットワークやシステム構成を考えるようで面白かった。また、アプリケーションエンジニア出身者にとっては、モジュール設計やクリーンアーキテクチャ、DDDのように感じられるだろう。SLOについても信頼性を定量化してモデルとして扱えるようにするのは、まさにソフトウェアエンジニアリングを感じた」と振り返り、「これによりDevチームに歩み寄れた気がした。議論ができたことも良かった。当然インフラ構築、運用、監視の面白さもあり、総合して、システムを扱う面白さがSREの面白さだと感じた」と語った。
さらに古川氏は、「人のシステムと機械のシステムの直列系が、Webサービス全体のシステムであり、両者の信頼性があって全体の信頼性が担保される。両方を見て、コントロールして信頼性を実現し、ビジネスに貢献していくことがSREの働き方ではないか」と続け、機械と人を結ぶ「ソフトウェアエンジニアリング」が必須であることを強調した。そして、人と人とを結ぶための「コミュニケーション」、さらに機械と機械を結ぶ「システムエンジニアリング」、その3つをうまく活用していくことがSREには大切だという。
「自分の得意な領域を発揮しながら、SREを組織に導入することは、大変チャレンジングで面白いこと。ぜひとも挑戦してほしい」と熱く語り、セッションのまとめとした。
本セッションの動画をMackerel Webサイトで無料公開中！
「Mackerel開発チームのリードSREが考える働き方と組織作り」と題し行われたセッションの模様を動画にし、一般公開中です。Developers Summit 2021 Summerに参加された方も、ご覧いただけなかった方も、ぜひご覧ください。
