はじめに
昨今DevOpsの推進と銘打ってアジャイル開発（特にスクラム）の導入がスタンダードになりつつありますが、運用側の手法改善としてSRE（Site Reliability Engineering）の導入を検討し始める企業も増えてきました。
しかしアジャイル開発とは異なり、SREの導入はハードルが高いといった考えを持つ人が多い印象があります。
ここでは、その考えがどういった理由で生まれ、何が原因でSREに踏み切れずにいるのか、またそんな中でもSREを導入していくにあたり、どういったアプローチが有効なのかを語っていこうと思います。
なお、あくまでここに記載している内容は私個人の見解になります。「ここは違くね？」と思うことがあったり不快に思うことがあるかもしれませんが、どうかご了承いただければと思います。
SREの前提
世の中SREの定義もまだはっきりと決まっておらず、「SREって名乗った人はみなSRE」状態が続いている印象がありますが、ここではGoogleが提唱しているSRE、いわゆるSRE本の内容をSREと定義してお話します。
こちらにSRE本の表面をさらっと拾った内容をまとめていますので、ぜひご参照ください。
SREの導入にはなにが必要なのか？
まずSREの導入に必要な環境を考えてみましょう。
①開発チームがアジャイル開発を導入していること、またはSREと一緒にアジャイル開発を始めようとしていること
SREはDevOps推進のためのプラクティスなので、Ops側だけで検討を進めても導入効果は薄くなります。もしSREを始める場合は開発チームがすでにDevOps推進のための取り組みを実施しているか、あるいはSREと一緒に開発プロセスも改善していくような環境を準備してください。
②開発チームとの密で柔軟なコミュニケーションが取れること
こちらも当たり前になりますが、開発チームと疎結合なSREチームはあり得ません。開発チームと同じ財産（エラーバジェット）を使いながら運用していくため、どうすれば節約できるかを両チーム間で常に意識した形を取ることが重要です。
Google ChatやSlack、Mattermost、Teamsなどのチャットツールを活用して、お互いのタスクだけでなくパーソナリティや悩み事をオープンにして会話できるための土台を作っておいてください。
③チームメンバーにSRE導入に対するモチベーションがあること
SREでは普段の業務を徹底的に効率化していくことが求められます。複雑な手順によって期待通りの動作を実現すると達成感もひとしおですが、SREでは誰でもできる状態に昇華したり自動化で効率化を図ることが求められるため、自ら進んでSREのプラクティスの導入に励んでいく姿勢が必要です。
なぜSREの導入は難しいとされているのか？
みなさん、アジャイル開発はすんなり導入できましたか？
最近はエンタープライズ企業でもアジャイル開発を積極的に取り入れていますし、SIerの方々は発注先から「アジャイル開発で頼む」と依頼されることも増えてきたのではないでしょうか？
では一方でSREの導入はいかがでしょう？「SREチームを作って対応してくれ」とトップダウンでオーダーがきたことがありますか？発注先から「アジャイル開発やるならSREも当然やってくれるよね」と依頼されたことがありますか？
おそらくほぼないと思います。ではなぜアジャイル開発には積極的なのに、SREには興味がなかったり消極的なのでしょう？
アジャイルは開発のプラクティス、SREは運用のプラクティス
日本の、特にエンタープライズ企業においてSREが発展しない理由、それはアジャイルが開発のプラクティスで、SREが運用のプラクティスだからなんだと思います。
エンタープライズ企業は自社での開発を行わず、SIerに依頼することが多いと思います。その際に発注側が開発に対して思っていることはなんでしょう？
- 早く正確に開発してくれ
に尽きるかと思います。要はそれを実現するためにウォーターフォールでやろうがアジャイルでやろうがそこまで興味はありません。早く、正確に開発してくれればそれでOKなのです。
ただ最近はアジャイル開発がスタンダードになってきていて、なんとなくアジャイル開発が流行っているから「アジャイルでやってくれ」という依頼をするケースがあったりします。
その証拠に、「アジャイルでやるから納期短くていいよね？」とか「設計書はこっちでレビューするね」など、アジャイルにおける誤った認識に基づく指示を出された経験はありませんか？これは開発手法にそれほど関心が高くないことから来るものだと思います。
（もちろん、自身のプロダクトの特性を鑑みてアジャイルが適していると判断した上で指示するケースもあります。というかこれしかないと思いたい）
では運用面での新しい手法の導入についてはどうでしょう？こっちは開発とはうって代わり、導入障壁がぐっと上昇します。
なぜなら、運用で何かトラブルがあると会社としての責任を問われる（あるいはマネージャーとしての自分が追求される）からなんですね。システムが止まると原因を調査し、分析し、再発防止を検討し、報告書をまとめ、幹部説明の行脚を行う必要があるのです。
そこにSREの概念、特にエラーバジェットの考えを提言してみるとどうなるでしょう？
「SLOを予算として使うだと？システム停止が増えるってことじゃないか！それは（俺が責任追求されるから）困る！」と、こうなるわけです。
しかしシステムトラブルが起こる原因は必ずしも運用だけとは限りません。開発中のバグや、目に見えない時限式の作り込みもありえます。開発チームがきちんと対応することで発生しなかった問題だってあるんです。
なのに「多少開発で何かあっても、運用がフォローすればなんとかなる」という従来からの思い込みが、「トラブルが起こったら運用（フェーズ）の問題でしょ」と誤解を生み、運用機能の改善を阻むのです。「今なんとかなってる体制にエラーバジェットなんて概念を入れたら『壊れてもいいんだ』なんて大義名分を与えるだけだ！」と考えてしまいます。
で、この考えは超わかります。
私もはじめにSREチームを名乗ってエラーバジェットを導入しようとしたときは各方面への説明に苦労しました。まぁそうですよね、運用を支える実務者が「止まっても許してね」と言っても、はいそうですかとは当然いきません。エラーバジェットの考え方は、（ほとんどの場合において）第三者が伝えないと理解してもらうことが難しい概念なのです。
SRE導入に向けた合意形成
とはいえいきなり第三者呼んできて「SRE入れるようマネージャーを説得して」という進め方をとるのはとてもハードルが高いと思います。ではどうすれば第三者からのインプットもなく自分たちで社内のマネージャーにSRE導入を合意してもらえるのでしょうか？いくつか方法を考えてみましょう。
方法①：SRE本を読んでもらう
「それができれば苦労しねぇよ！」って話ですが、究極これが一番手取り早いかなと思います。第5章まで読んでもらえばある程度SREの全体像を理解してもらえるでしょう。ただまぁ上司に「本読んでよ」とは流石に言いづらいかと思うので、もう少し別の方法を探ります。ちなみに読んでも納得されないようなら、それはなぜなのかをちゃんと追求しましょう。
方法②：ネットの参考文献や事例などをまとめてSREの効果・メリットを訴求
一番正攻法と言えるのではないでしょうか。自分達と似たようなシステム・アプリにおいてSREの考え方を導入した事例を見つけられるとかなり説得力のある訴求ができるのではないかと思います。反面、チームの特色がかけ離れたところの事例を持ってきてしまうと「よそはよそ、うちはうち」状態になる可能性が高いので、この方法を取る際は参考にする事例をきちんと精査しましょう。そして、そこが掲げているSRE像に自分たちが共感できるかをしっかりと見極めましょう。
方法③：勝手に始めちゃう
個人的にはこれが一番効果的かと思います。ただし、表立って動くのではなく、通常の業務と並行して効果測定することがポイントです。
仕組みの理解も方法も整ってない中でいきなり大々的に宣言してもマネージャーはYesとは言いづらいでしょう。なのでまずは自分たちのできる範囲で自動化を導入し、モニタリングを始めてみて、仮置きでいいのでSLOを定義してみて下さい。最初にEnd to Endのレイテンシなど測定が難しいものを選択するのではなく、まずは可用性など比較的簡単なSLIを使ってエラーバジェットを計測してみて下さい。
そして一定期間取り組めたら、そのデータをしっかりと集めてマネージャーに本格的なSRE導入の提言をしてみてください。理想はこの期間で何かトラブルが発生していることです。
そのトラブルがなぜ発生し、そのために何分・何時間システムが停止してしまったか、そしてどのようにして再発防止するのかをSREの概念で整理（ポストモーテム）し、エラーバジェットを計算してみてください。エラーバジェットを測った結果に応じて、SREを導入しても問題ないのかをチームで判断し、データと共に上申していきましょう。データを持っていって納得できないのであれば、SREの必要性をトップに訴求するための第三者を召喚する手配を進めないと厳しいです。
SREの導入が決まったら
晴れてSREの導入が決まったら、2つの側面からのアプローチを検討します。
- ソフトウェアエンジニアリングによる環境改善・整備
- 運用からSREに進化するための文化の改善
個人的には、SREの理解が難しい背景に上記2つの面が複雑に絡み合っているところがあると思います。SREに関する講演を聞いても、どちらかを明言しているものは意外と少なかったりします。
また「SREの導入に向けてどこから手を付けるか？」を考えた時、ある人は技術からの側面を、ある人は文化からの側面を、あるいはその両方を謳うことが多いです。
SREの導入には、今自分たちはどちらの改善を取り組んでいるのかを把握することが重要です。
私の個人的な認識にはなりますが、SREが必要なタスクは以下のように分類できるかと思います。
インフラ担当者として当たり前品質を担保する取り組みは、ソフトウェアエンジニアリングで改善する取り組みを前提として検討する必要があるため、セットで考えていいと思います。
それとは別に、SREならではの文化やそれらを継続的に広め浸透させる取り組みが必要になります。
ちなみにこのどちらから取り組むのかは、現在の組織の状態によって変わると思います。
最後に、それぞれの切り口から最初に取り組むタスクのおすすめをご紹介します。
ソフトウェアエンジニアリングによる環境改善・整備
- SLO定義に向けたモニタリング環境の構築
- トイル削減に向けた自動化への着手
まずは上記2点を意識してみてください。モニタリング環境の構築については、いきなり新しいツールを導入する必要はありません。既存の監視ツールを元に、まずは今取得できていない項目に何があるのか、それらを取得するために追加で設定すべきことは何かを検討します。
SREではまずメトリクスをきちんと取得するところから始まります。そのあとユーザー体験に影響のある項目を抽出し、それらをSLOとして定義、最終的にエラーバジェットへの運用につなげます。
そのため、まずは広範囲のメトリクスの取得を検討してみて下さい。
あるいはトイルの削減から着手するのもアリかと思います。
これは半分文化の改善にもなりますが、自分たちが作業している内容を汎用化し自動化する取り組みは、今後の改善活動への稼働を確保するだけでなく、属人的な作業を廃止し誰でも同様のクオリティで作業ができる状態を作ることにもつながります。
まずはこの取り組みによって作業の自動化へのモチベーションを高めることも効果的かと思います。
運用からSREに進化するための文化の改善
- 心理的安全性の確保
「SREの文化といえばエラーバジェット」という印象がありますが、エラーバジェットは開発チームと連携が取れ、同じビジョンを持って取り組むことが大前提になっているため、ここから着手するのはおすすめしません。
まずは運用チームに閉じた範囲でSREの文化にアジャストしていく取り組みをスタートしましょう。
そのための最初としては、なにより心理的安全性の確保を最優先にして下さい。
SREではメンバーそれぞれが持つタスクの標準化、自動化が求められるため、自分のタスクを周りのメンバーに共有することが重要です。また逆に他のメンバーが行っているタスクを自分が請け負うことになります。その際になにか共有するたびに非難されてしまうと言いたいことも言いづらくなってしまいます。
その人が行っているタスクの内容が悪いのは、それを見つけ改善する仕組みがないことが悪いです。その人が悪い訳ではありません。
その人があるタスクを実施していること自体が悪いのは、そういうタスク分担になってしまっている仕組みが悪いです。その人が悪い訳ではありません。
人ではなく、プロセスや方法が悪いことを大前提とした関係を構築することを心がけてください。
心理的安全性についてはいろんな方がQiitaにまとめているので、ぜひご参照ください。
さいごに
かなり雑多に書き殴った記事になりましたが、こういう意見もある程度に参考にしていただければと思います。
別の記事にも書きましたが、プロジェクトの事情やチームメンバのスキルによってSREのアプローチの方法は千差万別です。「SREってこう言われているからこうしなきゃ」という考えに囚われず、「イノベーションと信頼性の両立」を実現するためにはどんなことをすればいいのかといった観点をブラさずに推進していってもらえたらと思います。