新卒でSaaSの事業会社のバックエンドエンジニアになって約2年半、Go言語を使ってマイクロサービスのバックエンド開発をやってきましたが、 今期からSREに転向しました。 最近バックエンド:SREで9:1で兼業はしていたのですが、本格的にSREをやっていきます。

これまで

これまでバックエンドエンジニアとしては、サービスのフルリプレイスに伴うマイクロサービスの開発、 その後の新機能開発、運用などをやってきました。 今思えば、バックエンドエンジニアとしての新機能開発や運用の仕事以外にもフルリプレイス後のEKS基盤の構築だったり、 CI/CDの構築や開発者が使うツールの整備などインフラ、開発基盤よりの仕事も割と最初から好んでやっていましたね。

こうして働いているうちに、やっぱり開発基盤やクラウドインフラ、運用の自動化、最適化、信頼性を担保するための仕組みづくりなど、SREの業務領域に興味が出てきたことでキャリアの方向をSREに向けることにし、少しだけSREの業務もやりはじめました。

兼業メンバーで回していたSREチーム

転機となったのは唯一の兼業なしのSREだった同僚がR&Dを兼務してSREを専属でやる人が誰もいなくなってしまったことです。(自分もバリバリ機能開発していました。) 自分を含む兼業メンバーで運用は回していましたが、開発チームへの人員の追加などで新機能の企画の速度が上がり、順調に機能開発速度が上がってきた状況でした。

開発速度とシステムの安定性というのは、トレードオフの関係にあります。 究極に運用を重視し安定したシステムでは新機能の追加や改善が一切されず、究極に開発を重視したシステムではいつシステムが止まるかわかりません。どちらかが欠けていては、信頼性のあるサービスにはならないのです。

開発速度が上がる中、専業SREがいないこのままではまずいと強い危機感を感じたのと、幸いバックエンドエンジニアも増えて来ている状況でしたし、今やっている機能開発が終わったら興味のあったSREに転向してSREチームを再構築し、今やっているインフラ管理、運用に加え、SREとしてより信頼性へ取り組むことができるチームにしようにしようと考えました。

SREへの転向

ということでバックエンドエンジニアとして担当していた開発業務が終了した後、正式にSREに転向しました。 SREチームの役割、ミッションをSREとして明文化し、信頼性を担保するためのエンジニアとしてSREチームを再立ち上げするところからはじめています。 SREチームがSREとしての価値を十分に発揮できるようにするため、技術的な課題に加えて、開発プロセスの改善や他チームとの連携などの組織的な問題にも取り組まねばなりません。 また、これまで個人技の集まりだったSREをチームにするための施策にも取り組んでいく予定です。

SREが実践する信頼性への取り組みは技術的、組織的の両面から広範囲に行われます。 それによって、信頼性に取り組む文化を開発組織に定着させることを目指しています。 もうちょっと書くと、組織が以下のような状態になるのが理想です。

  • プロダクトマネージャーや経営陣などとともに、事業視点を踏まえてサービスの信頼性の目標を定めることができる
    • 信頼性の目標は本来SREのみで決めるものではなく、ユーザーに対して提供したい"信頼性"という機能を事業視点で決定するもの。
  • プロダクト開発チームが主体となって信頼性目標を運用することができ、データ駆動で開発と運用どちらにリソースを使うかの意思決定ができる
    • 開発と運用、どちらに偏りすぎても信頼性は損なわれます。その自己診断能力を開発組織に実装したい。
  • 組織的に信頼性に対する投資が継続して行われており、信頼性が高く魅力あるプロダクトを発展させている。
    • 潜在的な信頼性リスク(機能開発速度のボトルネックやシステムの安定性に関する課題など)が事前に特定され顕在化する前に対処、改善される組織にしたい。
    • 開発と運用の力がバランスよく高まりプロダクトは安定して発展していく。

理想のためにやるべきことは山積みで、一気に解決する銀の弾丸はありません。 一歩ずつ理想に向けて挑戦していきます。

そんなほぼ立ち上げ期のSREチームでGo,k8s,Microservices等で構成されたプロダクトの開発プラットフォームの開発やサービスの信頼性向上のための仕組みづくりとエンジニアリングをやっていくのに興味がある人、ぜひ連絡ください!