本記事は、SRE Advent Calendar 2019の20日目の投稿です。@katsuhisa__ がお送りします。
今年の6月に登壇した際に、Self-Serviceで物事を進めることの大切さと、SREがSelf-Serviceを構築することに責務の一端を持つことについてお話しました。
「class SRE implements DevOps」という言葉もありますが、私はSREがDevOpsを実装するにあたって大切なことの1つは、開発者によるSelf-Serviceを構築することだと考えています。
Envoy開発者のMattが「DevOpsとは、開発者が24/365でサービスの運用に対する責任を負う慣行である」としたことは有名です。私もその言葉に影響を受け、SREが開発者による運用を支えるツールやPlatformを開発することは、SREにおける責務の1つであると考えています。（もちろん、自分たちが掌握する範囲におけるOps業務を効率化・自動化するための実装も大切です。）
The human scalability of “DevOps” - Matt Klein - Medium
本記事では、これまでの経験をふまえつつ、体験の良いSelf-Serviceを構築するために必要な3つの心構えについて意見を述べたいと思います。「うちではこうやってるよー」「こうすると良いですよー」といった意見があればTwitterでご意見いただけると嬉しいです。エゴサします。
1. 学習コストが低くなるよう工夫する
私が働く会社では、開発者自身がTerraformでInfra構築できる環境が整っています。具体的には、Pull Requestをつくれば、CIで、 terraform plan の実行結果が分かるようになっているため、「開発者によるPull Request」と「CODEOWNERSであるSREによるレビュー＆マージ」の2ステップを踏めば、誰でもInfra構築ができるようになっています。
皆さんの働く企業の中で、開発者自身がTerraformのコードを書いてPull Requestを送ってくれる会社はどれくらいあるでしょうか。または、その割合はどのくらいでしょうか。…私たちの会社では、数人の有志がTerraformを書いてPull Requestを送ってくれることはあれど、開発者全体にその文化が広まっているとは今の所言えません。
では、なぜ開発者自身でInfra構築できるにも関わらず、従来通り、環境構築を依頼するのでしょうか。その理由の1つに、学習コストの問題が挙げられると思います。当初、SREの私たちは、「開発者自身でTerraformによるInfra構築できる環境を整えた！これでSelf-Serviceを推進できる！」と思い込んでいました。というのも、Infra環境の大半は、SREがTerraform化をすでに行ったため、開発者は既存のTerraformを参考にコピペするだけで思い通りのInfra環境を手にすることができると感じていたためです。
しかし、実際はそうではありませんでした。もちろん、その理由はTerraformのせいではありません。実際は、私たちの環境におけるTerraformの学習コストの大半は、既存のInfra構成に関する学習コストでした。既存のTerraformもコードをコピペすればできる！と思っているのは私たちSREだけで、大半の開発者は、既存のInfra構成に関する理解度がそこまで高くないため、どこまでをコピペで流用して良いかが分からない状態でした。
もちろん、私たちSREも開発者に対してSystem Architectureを伝えるトレーニングを行ってはいるのですが、限られた場では、業務で自分たちに必要なTerraformをスムーズに書けるほどの理解度には達しませんでした。これらの経験から、学習コストが高いものはワークしづらいことを実感しています。ということで、学習コストを下げられるようなチームでの取り組みが大切だと感じています。
2. Self-Serviceをどのように使うべきかの思想をチームで対話する
私たちのチームでは、開発者がボタンをクリックするだけで、ProductionへのDeployやロールバックを簡単に行うことができるように実装しています。このDeploy Pipelineを使うことで、開発者はSREの手を借りずともProduction Deployを完了させることができます。さて、この自動化されたDeploy Pipelineをつくるにあたって、SREは1つ大きな願いを込めていました。それは、手作業時代には、（SREのリソース都合で）頻度を増やせなかったDeploy回数を、大幅に増やしたいというものでした。先日、社の開発ブログにも書きましたが、私たちは、チームで対話を行うことにより、この変化を実現することができました。
つまり、「リリース頻度を高めつつ、障害発生頻度の極小化」を目指すことが私たちにとって求められる姿勢です。スタディスト開発チームでは、過去に、リリース頻度に関して問題意識のあるメンバーの発案をきっかけとし「リリースサイクルと開発スタイル」に関する意識統一の話し合いが行われました。現在も「リリース頻度を高めつつ、障害発生頻度の極小化」を目指す道半ばではありますが、少なくとも今のスタディスト開発チームには「障害を起こさないためにリリース頻度を減らしさえすればよい」と考えるメンバーはいません。こういった文化の1つ1つがユーザー価値の最大化につながると考えています。
単にSelf-Serviceをつくる以上に、「class SRE implements DevOps」は奥が深いものだと思っています。
3. サービス開発者とSREの間に壁がないこと
2の内容とも通じるのですが、サービス開発者とSREの間には、壁がなく日頃から継続的に対話できる環境が整っているべきだと考えます。また、その結果として、Self-Serviceが普及したり、次のSelf-Service化する対象を考えるアイデアを得たりするのがよいのではないでしょうか。
私が働く会社では、チームで働く仲間が、サービス開発者とSREの間の壁をつくらないような活動に熱心に取り組んでいます。
某社のSREは役割が多岐に渡るため、組織が急激に成長するといつか破綻してしまうというリスクがありました. そういったリスクに対して事前に対策を打つための1手段として、SREが持っている知識や経験則を共有、SREと一緒に悩む場として「SRE Office Hours」という活動を毎週金曜日に枠を設けて実施しています. この活動はマイクロサービスについて何でも聞けるOffice Hoursに参加したよ！ #メルカリな日々に影響を受けて企画し、今も開催し続けています. ※2 技術書の輪読もそういった活動の一環で、「仕組みはどうなっているのか」「弊社ではどうなのか」「これを改善していけるのではないか」といった疑問を持つきっかけだったり、議論をする場として活動しています. 社内勉強会のLT枠でも、SREが持っている知識を共有する場の1つとして利用させてもらっています.
キャッキャウフフ会とは 名前だけ聞くとただただ楽しそうなだけの会ですが、実態は至ってまじめ。 WebチームとSREチームがチームの垣根を越え、互いの知見を活かしてチーム横断的な課題をモブワークで解決する会 です。
Self-Serviceとカッコよく言っていますが、突き詰めると、Self-Serviceを構築する人と、使う人（プラクティショナー）がいるだけです。その間に溝があれば、お互いに「あいつらがつくった自動化イケてねーわー」のようにギクシャクするのではないかと思います。繰り返しになりますが、「class SRE implements DevOps」の言葉の裏には、そういったわざわざ明文化されていないけれど、チームで働く大切な前提条件がいくつも含まれているのだと私は信じています。
皆さんも良いSelf-Serviceライフを！
