SREという名のインフラエンジニアがSREになった日
SREになった日
ある日、SREになった。
昨日までインフラチームに所属するインフラエンジニアだったが、気がついたらSREチームに所属しSREになっていた。
とりあえずSRE本の存在は知っていたのでSRE本を読んでSREについて学んだ。
信頼性という指標を作り、SREはその指標に責任を持ち、維持・向上していく責務を持つと雑に理解した。
せっかくSREになったのだし、SREとして人に名乗って恥ずかしくないようにコツコツとやっていこうと思った。
しかし、実際にはSREらしい業務をすることはなかった。
当時の業務を振り返ると大きく3つの業務があった。
- 現在から将来にかけてサービスの死を回避するための業務
- レガシーなシステムによりチームの業務が鈍化していくのを改善する業務
- 開発チームからの依頼を行う業務
はっきり言って信頼性を作り、そこにコミットする余裕なんて全くなかった。
もちろん指標を作りたかったのでいろいろ動こうとしたが、私自身の知識不足や、レガシーなシステム群に阻まれて指標を可視化し、そこにコミットするような動きとれる状況を作ることはできなかった。
もちろん、世の中でSREがやるような業務もいろいろやった。
例えばKubernetesを導入し、古いアプリケーションをKubernetesに対応させるなどだ。
私の考えではKubernetesを導入し、運用するのは別にSREの業務だとは思っていないが世間的に言えばこれもSRE業務の一環だろう。
このあたり、広義のSREとしてはSREをおこなってきたと言っても良いとは思ってはいる。
良くも悪くもサービスの死という絶対的に信頼性が下がるものを回避し、具体的な指標はないがおそらく信頼性と呼ばれるであろうものを改善するような業務をいくつもやってきた。
しかしだ。私の中では信頼性を持たず、そこにコミットしないSREはSREではないと考えている。
気がつけば私は私を紹介するときにSREとは名乗らなくなった。
新規システム構築をはじめた日
ある日、新しいシステムを構築するチームでインフラ、SRE要員として参加することになった。
このプロジェクトでは最終的に高い生産性を作れるシステムと組織を作ることを目的にしており、しがらみもないということで、私は一つのことをやると決断した。
徹底的なDevOpsを行い、開発チームにオーナーシップを委譲しきることだ。
信頼性を作り、SREをやるチャンスではあったが、正直この頃には疲弊していたし、真にSREを行うには開発者チームに入って開発者から信頼を得た上で開発チームとして信頼性を作るしかないのだろうというような考えを持っていたので後々チームの一員になってからやろうと思っていた。
ここでオーナーシップを委譲しようと思ったのにはいくつか理由がある。
まずは、これまで開発チームから依頼を受け作業を行ってきたが、これには限界があることがわかってきていた。
インフラといった専門知識を持つ人材はまず転職市場に出てこないし、出てきても滅多に採用することができない。
そうなると、SREチームはスケールしないのに、開発チームはどんどんスケールしていくという状況ではっきり言って依頼を捌けなくなり、依頼から数日、長いと数週間かかってようやく依頼を完了するという状況で、開発チームの生産性を低下させている
そうなると果てにはどうなるのか。
開発者に「SREチームは大変そうだから自分たちで完結できるこの方法でやろう」と言われるようになってしまうのだ。
私はこの開発者たちとは別のチームで、開発者たちからの依頼を受けて作業を行うスタイルをゲートキーパーパターンと読んでいる。
このゲートキーパーパターンは会社のフェーズや製品によっては有用なケースもあるとは思っている。
しかし、生産性を高く、新しい機能をどんどんリリースしたいという要求とは致命的に噛み合っていなかった。
次に、開発者たちにオーナーシップを委譲することで、自分たちのシステムと意思決定に責任を取って欲しいと思ったからだ。
SREチームが運用に責任を持っていたのはシステムのインフラ周り全般になる。
例えば開発者たちがこのシステムにおいて最適だと選定したDBが気がつけばSREの管理下になったり、開発者たちが日々の機能追加で寿命を減らし、たまに発作を起こすDBなんかもSREの持ち物になる。
こういったインフラ全般に対しシステムが死を迎えないように延命し続けるというのは、はっきり言ってスケールしないSREチームでやり続けるのが難しくなっていた。
余談だが、SREチームだけがシステムのアラート対応を行っていたときに、開発者たちにアラート対応としてページを受け取って欲しいという話をしたさいに、DBなどのインフラ起因のアラートとアプリケーション起因のアラートを分けてもらわないと難しいと言われたことはとても心に残っている。
この考え方が間違っているわけではなく、権限がないということは責任がないというので、インフラ起因で夜間に起こされるのは困るというのはよくわかる話だ。
私にとって従来のSREチームでの進め方は緩やかな死を迎えるものとしか思えなかった。
それが成功するかはさておき別の道に進む必要があった。
仕事がなくなった日
オーナーシップを委譲すると決めたはいいが、どう委譲するかは問題だった。
一番簡単な方法は権限をまるっと開発者に渡してしまうことになる。
しかし、大多数の企業でこの方法は取ることができない。セキュリティやガバナンス、信頼性といった問題が出てくるからだ。
例えばデータベース一つとってもいくつか引っかかるポイントが出てくる
- 開発者が自由にデータベースのデータを読み取ってはならない
- 業務上必要なケースがあるとしても誰が、何時、何のデータを読み取ったのか記録しなければならない
- 不用意なクエリ実行でデータベースが停止してはいけない
こういったあたりを全てを無視するわけにはいかないので、開発者たちの機能開発を妨げないラインで、開発者たちが安全に実行できる方法を見つけてひたすら実現していった。
基本的なやり方はDevOpsの手法を用いて、開発者たちに直接権限を渡さないが、それを実行できる自動化した仕組みを開発者たちが実行できるようにしていく形だ。
また、やってはいけないことはできないようにしたり、どうしても制限できないところは後からよくない状況を検知して是正を促せるようにガードレールを設営していった。
こういった取り組みを1年と少しやり続けた結果、インフラ、SRE要員としての私の仕事はなくなった。
もちろん、完全になくせたわけではなく数ヶ月に1度、開発者ができず急ぎでやらなければいけないことを代理で行ったり、インフラやSREといった面で相談があれば受けることはあった。
他にも私がやった方が効率がよく、これができれば開発者たちの開発体験をよりよくできると思っている作業なんかもまだまだある。
しかし、私がいなければ開発や運用が止まってしまうということは一切なくなった。
私はオーナーシップを委譲しきったのだ。
SREになった日
そうして私は開発者として日々を過ごしつつ、たまにインフラ・SRE要員として改善活動をおこなっているとき。
ふと、私は思い立って本当にオーナーシップを委譲できたのか確認しようと思った。
手法としては2つで、1つは開発者たちにアンケートを取って主観的にオーナーシップを持って開発できているのか、2つ目は客観的な指標として今見ることができるメトリクス群からオーナーシップを阻害している要因はないかという形でこれをレポートとしてまとめてみた。
結果としては主観的にも客観的にもよく回っておりオーナーシップを委譲できたと言っても過言ではないことを確認することができた。
もちろん完璧な運用を行えている訳ではなく、レポートをまとめ掘り下げていく過程でもっとこうした方が良いものは発見されたので、そういったものは開発者たちに伝え、チームで改善していくことにはなる。
このレポート自体は好評で、とりあえず開発者たちに何を見て、何を改善していかないといけないのか伝えるために毎月レポートをまとめていくことにした。
そして今日、2回目のレポートをまとめていて気づいた。僕は今、SREをやっている。
きっかけは1回目より深く掘り下げている形でレポートをまとめているときだ。
運用について洗い、足りてないと思われる箇所に対して、なぜそれが必要で、なぜ今それができていないかを考えたときに、指標がなくそこに対してコミットする必要性が見えていないことに気づいた。
開発者側に寄って最近流行りのFour Keysと言ってもいいし、プロダクトに寄って信頼性と言ってもいい。
システム運用を詰めていくのはそういった指標を悪化させず、維持、向上するために必要になると私は思っている。
逆説的に言えばそういった指標を持たないから運用で足りない部分が出てくるわけで、それならどういった支援を行って開発者たちに指標持たせることができるか、どういった支援をすればその指標を維持、向上していけるかと考えはじめていた。
そう、これははじめにSREとなったときに思い描いていたSREとしての活動になる。
ただ、当時は開発者→SREとシステムの変更に依頼を必要とするSREがオーナーシップを持ったゲートキーパー型の組織だったのが、今は開発者がオーナーシップを持ちSREが支援を行い、開発者たちが持つ指標を維持、向上させるサポーティブな組織となっている。
このオーナーシップの所在が移り変わったことで、意図的に信頼性を作り、運用できる状態にしようとしているところから、開発チームが自然に信頼性を産もうとするところに辿り着いていた。
もちろん、これはオーナーシップの所在だけが問題になる話ではないとは思っている。
他にも開発者たち自身がそういった指標を欲しがっているという状況や、開発者たちへの信用の話で支援すればよりよくしていけると確信、システム的にも支援ができることが見えている状態になっているというのもある。
とはいえオーナーシップがSREにある状態ではここに辿り着けなかったのは間違いない。
これはまだようやく芽が見えたというレベルの話だ。
しかし、ここで適切に支援を行っていけば指標を確立し、そこの維持、向上に寄与できるとついに確信できた。
まだ、SREと名乗るには実績が足りないので恥ずかしいと考えているが、そう遠くない将来に私はSREだと名乗り始めると思う。
未来の話：SREがいなくなる日
一つ未来の夢の話をしたい。
開発者たちを支援するSREチームの実現する目処はたったが、それは私が理想とするSREの姿ではない。
私は開発チームの一員として機能開発に従事しながら、機能開発の速度、つまりアジリティの維持、向上するために信頼性などの指標にも寄与する開発者になりたい。
つまりSREと呼ばれない開発者になりたい。
もっと言えば、特別な役職を作らなくてもチームの能力として信頼性などの指標を維持、向上できるチームを作り上げたい。
もちろん、開発者の能力差異はあるので比重としてそういった業務を多くやることはありえる。
しかし、個人の能力頼りで特定の専門家を置くというのはチームの継続性が下がっていってしまい、いつかは破綻してしまう。
この破綻を回避するにはとても大きな労力がかかるのだ。
だからこそ、SREチームを解散し、SREという役職を廃止したいと強く思っている。
夢物語のような話だが、私が今進んでいる道はこの夢に繋がっているように思う。
いつかちゃんとSREと名乗り、堂々とSREを辞めましたと言えるように私はなりたい。
Discussion