地道に積み上げるSRE 目的合意から進めたSREの探求と実践
今回の記事では、SREとは何なのかについて根本から考えながら活動してきた、グロービス SREチームの探求と実践について紹介します。
はじめに
グロービス・デジタル・プラットフォーム SREチームでチームリーダーを務めている沼田（@chroju）です。
突然ですがSREとはどう定義されるでしょうか。この問い、存外に難しいのではないかと感じています。インフラエンジニアは「インフラ領域を担当しているから」そう呼ばれますが、ではSREは「サイト信頼性を担当しているから」そう呼ばれるのでしょうか。サイト信頼性を担当する、とは、具体的にはどういうことなのでしょうか。
SREチームの業務内容や責任領域は広範囲に渡り、おそらく会社によって様々な形を取っているのではないかと思います。2021年9月に日本語版が発売された『SREの探求』は、まさにそういった様々なSREの実践をまとめた書籍であり、冒頭の「はじめに」において、以下のように書かれています。
この分野自体が今もなお進化、拡張、変革、新たな発見の真っ只中にあると考えています。ある意味では私たち全員がずっと、SREを探求し続けているのです。
ここでは、SREとは何なのか、何をするべきかという根本から考えながら活動してきた、グロービス SREチームのこの1年ぐらいの探求と実践について紹介していきます。
マニフェストでSREの共通認識を作る
私たち、グロービス SREチームでも、「SREとは何か」という問いへの答えは、最初から明確だったわけではありません。国内で同様の事例は多いと思いますが、私たちの前身は「インフラチーム」であり、当時から引き続いている業務内容も多くあったため、なぜSREである必要があるのか、インフラチームとどう異なるのか、という問いには答えておく必要がありました。
そこで私たちのチームでは、『サイトリライアビリティワークブック』（以下、SRE ワークブック）を全員で読み合わせた上で、チーム・マニフェストと、そのタグライン（tagline、標語のように一言で言い表したもの）を定めることで、チームの目的を摺り合わせる作業を行いました。
『SRE ワークブック』はご存知の通り、Googleによる「SRE Books」の第2弾です。第1弾の『SRE サイトリライアビリティエンジニアリング』（以下、SRE book）でもよかったのですが、より実践のイメージを持ちたかったことからこちらを選びました。400ページ超の厚さを半年近くかけてじっくり読み進め、自分たちの実践にどう活かすかを話し合いました。
その上でマニフェストとタグラインの策定を行いました。マニフェストは、自分たちのチームの存在理由を文章で書き表したもので、タグラインはそれを一言にまとめたものです。当時の上長がマニフェスト策定ワークのノウハウを持っており、「SREチームでやってみないか」と提案いただいたものに乗っかる形で始まりました。事業領域上、チームビルディングの手法やノウハウに長けた社員が多数在籍しているのは、グロービスの強みかもしれません。
できあがったのが 「ユーザーのために開発速度と安定性を向上する」 というタグラインです。プロダクトの数や規模が増大すれば、運用コストも比例して増大し、開発速度や安定性は毀損されます。これを単なるマンパワーではなく、ソフトウェアエンジニアリングを始めとした、何らかの手段でレバレッジを効かせて抑制していくことで、ユーザー価値を安定して提供できるようにすることが、SREの本質ではないかと考えています。
一見するとごく普通の内容にも思えますが、「信頼性」ではなく「安定性」という単語を選んだことや、「ユーザーのため」だと目的を明記したことなど、一つ一つの言葉選びに意味があります。そして、これを数日間かけて練り上げた過程を通し、チームでの共通認識が出来上がったことが何よりの価値です。
タグラインが決まってからは、チームでOKRを決める際など、必ず「タグラインに寄与した活動なのか」を考えながら業務を進めるようになりました。ここからはタグラインに掲げた「開発速度と安定性」のうち、「開発速度」の向上を例に取り、この1年ぐらいの活動を振り返ってみます。
Toil計測による問題発見
開発速度上の問題は、バリューストリームマッピングで考えると、大きくプロセスタイムの問題とリードタイムの問題に分けられます。このうち、大きな課題感を覚えていたのがリードタイムです。
グロービス SREチームは独立した1個のチームであり、各プロダクトの運用作業を横断的に担当しています。また、先にも触れた通り前身は「インフラチーム」であり、インフラレイヤーの設定、構築などの作業も経緯的に担い続けてきました。そのためプロダクトチームからSREへの「作業の受け渡し」がそれなりの頻度で発生していました。
問題を見つけて対処するには、まずはどの程度「受け渡し」が発生しているのかを客観的に見定めなくてはなりません。そのために、Toilの計測を活用しています。
グロービス SREチームではタスク管理に ZenHub を用いており、チケットにToilかそうではない（Toil以外は大きくEngineeringと呼んでいます）かのラベルと、所要時間の目安であるストーリーポイントを付与して、Toilを計測しています。 Toilの目標割合は作業全体の50%で、それより多いようであれば原因を確認して対処することにしました。
Toilの定義は、ほぼ『SRE book』に則っています。他のチームから依頼される、非戦略的なタスクはToilになります。まずはこういったタスクを炙り出し、それぞれを「SREが担う必然性があったのか？」という観点から考え直していきました。
依頼作業をセルフサービスに替えていく
グロービス SREチームは特権アクセスを持っているため、中にはSREにしかできない作業もありますが、習慣的にSREが担っているだけで、そこに必然性がない作業もあります。そういった作業は、なるべく開発者自身だけで完結できるよう、セルフサービス化を図ることで改善しています。
GitHub Actionsによるデプロイトリガーの管理
従来、デプロイパイプラインはほぼCode Pipelineで統一されていました。当然ながら設定の変更においてはAWSの権限を用いた操作が必要になります。しかし、例えば開発環境で一時的にフィーチャーブランチからのデプロイに切り替えたい場合など、日常的なちょっとした操作のためだけに AWS へログインするのが面倒という声がありました。
2021年頃より、CodeBuildだけで完結するようなパイプラインであれば、 aws-actions/aws-codebuild-run-build を利用し、 GitHub Actionsを使ってトリガーする形式へ徐々に切り替えています。これによりトリガーは .github 内のYAMLファイルで明記され、Pull Requestベースで簡単に変更できるようになりました。tag pushをトリガーにしたり、複数のブランチをトリガーにしたりなど、より柔軟なトリガー設定ができるようになったことも開発体験の向上に繋がったと感じています。
秘匿値の管理権限開放
環境変数に設定するAPIキーのような秘匿値は、従来ansible-vaultや mozilla/sops を用いて、SREだけが復号できる形でGitにcommitしていました。しかし、値の中には開発者が払い出した上で、 SREに設定を依頼しているものもあり、そういったものまで「SREだけが復号できる形」にする必然性はありませんでした。
そこで暗号化対象のファイルを、開発者でも復号可能なものと、従来通りSREしか復号できないものに分割し、開発者に開放可能なものは前者へと移行しました。その上でAnsibleやTerraformに馴染みのないエンジニアでも触れるようドキュメントを準備し、 開発者が自発的にPull Requestできるようにしました。
『SRE book』には、「SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの」という一節があります。これを元として、 SREはソフトウェアを書ける必要があるとの声もよく聞かれますし、実際にグロービス SREチームでも Slack + AWS WAF でサービスをメンテナンス画面 (Sorry Page) に切り替える - Qiita のように自動化で対処している例ももちろん存在します。
ただ、必ずしもあらゆる問題の解決にソフトウェアを書け、使えという意味ではないはずです。ここに挙げた例はいずれもワークフローの見直しと、「ドキュメントを書く」といういささか泥臭い手段だけで成り立っています。ですが、それだけで十分にリードタイム削減には成功しています。ソフトウェアを書き、メンテナンスしていくよりも、30分でざっくりとでも良いので手順をドキュメントに書いた方が、時間対効果でも保守性でも優れているケースはありえます。「ソフトウェアエンジニアリング」と言われると、手段としてのプログラミングをそのまま想定しがちかもしれませんが、より力点を置くべきは、ソフトウェアエンジニアリングの知見やプラクティスを応用できているかという点のほうだと捉えています。
さらに重要なのは、タグラインのような自分たちの目的、責務に資することができるかどうかです。目的にフォーカスすることができていれば、手段はある程度幅を持たせて良いはずです。
Kubernetesの導入による長期的改善
とはいえ、開発速度の向上に必要なのは、こういった小さな工夫だけではありません。長期的に実施しているのがアーキテクチャ自体の見直しです。EC2 + Ansible + Packerを使った環境から、Kubernetes (EKS)を使った環境への移行を少しずつ進めています。
EKSへの移行は、リードタイム、プロセスタイム双方の改善を期待しています。コンテナはPacker + EC2よりビルドや起動が速いため、単純にプロセスタイムの改善を見込むことができ、すでに10分以上の改善に成功したデプロイもあります。また、開発、ステージング、デモ、本番といった複数環境を管理していくなかで、既存のAnsible Playbookはかなり複雑化していました。これをKubernetes manifestsを用いて、シンプルな書き方に改めようともしています。コードの読み書きにおける認知負荷の軽減は、プロセスタイムの削減に繋がりますし、リードタイム削減を目的とした、開発者によるセルフサービス化も推し進めやすくなります。
アーキテクチャの見直しと移行は長期的に大きな価値を持ちますが、数か月の工数をかけなければならず、即効性はありません。目の前にある開発速度の問題を解決するには、ドキュメントを書くような、効果がすぐ現われる施策もまた必要です。長期的な改善と短期的な改善の、その両輪をバランス良く進めるのが重要と考えています。
一方で、 Kubernetesは年間で複数回のバージョンアップを求められるなど、 Toilがかさみやすいプロダクトでもあります。 宣言的 Blue/Green デプロイで EKS バージョンライフサイクルに立ち向かう話｜グロービス・デジタル・プラットフォーム｜note に書いているように、適切にToilを抑えながら運用することを意識しています。
SRE の組織論
先に挙げた「作業の受け渡し」によるコストですが、これはそもそも組織体制に端を発する問題でもあります。『チームトポロジー』や『LeanとDevOpsの科学』では、チーム間のコミュニケーションパスを適切な数に収めること、機能のデリバリに必要なスキルが1つのチームに揃っていることなどが繰り返し強調されており、チーム間の「作業の受け渡し」が発生しない状態がベストと言えます。
SREチームの組織体制について SRE at Google: How to structure your SRE team | Google Cloud Blog では6種類の実装が書かれています。ここから3つほどピックアップしてみます。
Kitchen Sink a.k.a Everything SRE : 1つの SRE チームですべてのサービスを対象とする
Infrastructure : Kubernetes Cluster や CI/CD といった共用されるコンポーネントに SRE は注力する
Embedded : 開発者チームの中に SRE が参画する
この中で言えば、現状のグロービス SREチームの体制はKitchen Sink SREとInfrastructure SREの複合パターンと言えそうです。 Infrastructureは、個人的には「プラットフォーム」と言い換えたほうがしっくりきます。
現状のプロダクトの数や状況においては、この組織体制でもSREチームで作業がスタックするほどには至っておらず、大きな問題になっていないのも事実です。しかし、将来的なプロダクトの規模、数の成長を考えるにあたり、Embedded SREを目指すべきか、という議論がチーム内でたびたび持ち上がっています。
Embedded SREの形は、私たちが問題としていた「作業の受け渡し」がそもそも発生しなくなるわけですから、見るからに理想的です。 タグラインにあるもう一つの注力領域である、「SLOの策定・運用」においても、プロダクトチーム内にSREがいたほうが話は進めやすいでしょう。実際、 SREチームから多くのプロダクトチームへ個別にSLOの必要性を説明し、開発優先度の決定にエラーバジェットを使ってもらう只中にいますが、1チームから全チームへ業務の進め方自体の変革を迫るわけですから、なかなかに歯ごたえがあります。
ただ、 Embedded SREも銀の弾丸というわけではありません。何より、非常にマンパワーを必要とする体制です。Embedded SREのほかに、プラットフォームの管理を担当するためのInfrastructure SREも別途必要となりますし、プロダクトの増加に合わせて、Embedded SREの増員も図らなくてはなりません。
個人的には、必ずしもEmbedded SREを目指す必要はないと考えています。SREの組織体制については『SREの探求』10章でも言及がありますが、ここでは以下のように書かれています。
どのモデルを選ぶ場合も、従来の開発しかしないチームと運用しかしないチームの間にある壁が壊されるとなれば、やはりカルチャーショックは避けられません。SREは、これまで開発しかしてこなかったチームに運用のスキルと経験をもたらすための本質的な役割を果たします。
「作業の受け渡し」コストを抑制するために、Embedded SREとは別の方向として、開発者が運用スキルを身につける、という手段も取れるわけです。
何も全員がフルスタックエンジニアになれと言うわけではありません。先のドキュメント整備もその一つではありますが、より運用業務を抽象化し、シンプルにし、最小の認知負荷で開発者やプロダクトチームがセルフサービスできるようにすることで、「運用」というコストは圧縮できます。あるいはサービスやツールによっては、 SREからのレクチャーなどを通じて、より多くの人が触れる状態を目指すべきかもしれません。SREが現状特権的に担ってしまっている業務を少しずつ委譲し、薄く広くSREの文化が浸透した状態にしていくのが理想ではないかと考えています。
想定に近いものとしては、『SREの探求』における OaaS (Operation as a Service) の考え方や、 The Developer Experience and the Role of the SRE Are Changing, Here's How の内容が挙げられます。 SREと開発者の関係が、単なる作業の受け渡しではなく、適切なコラボレートに変化し、 SREチームはすべての開発者の作業が円滑に進むよう、プラットフォームや文化の拡充に注力するような形です。
まとめ
グロービス SREチームの取り組みを、マニフェストの設定から計測、短期的、長期的改善、そして組織論に渡って紹介してきました。冒頭の引用にあるように、SREの実践は、やはりそれ自体が「SREの探求」と同義だと捉えています。自分たちは何を責務とするのか。そのための最適解は何なのか、状況の変化も鑑みつつ、常に考え続けなければなりません。そして解は必ずしも高度に技術的なものにはならず、ドキュメントを書いたり、ちょっとした設定値の変更だけで済む場合もあれば、組織的な力学や行動心理、ワークフローまで考えなくてはならない場面もSREには多くあります。手段を選ばず、コツコツと地道に積み上げるのがSREの在り方なのかなと思っています。
露骨な宣伝のようにはなりますが、このような組織、社会、心理といった知識も求められる職種を、ビジネススキル教育を事業とするグロービスで実践できていることは非常に面白く感じています。例えば『SRE ワークブック』21章で記載されている、レヴィンの変革プロセスや、コッターの8段階プロセスについては 組織変革を進めるための2つの重要アプローチ | GLOBIS 知見録 に記載があるなど、SREの実践ノウハウの一部は、弊社が提供する学習コンテンツと重なります。SREの実践を通じて、自社の事業に一段と興味が持てたのも事実ですし、自社のコンテンツがSREの実践にも役立つという、面白い循環が出来上がっています。
広く組織全体のことを考えながらSREを探求していきたいエンジニアの方がいましたら、グロービスで学びながら実践してみるのはいかがでしょうか。 SREチームは現在積極的に採用活動を実施していますので、私のTwitterアカウント @chroju までDMなどでお気軽にご連絡ください。
この記事が気に入ったらサポートをしてみませんか？