はじめに
SRE NEXT2025に参加してきました！
SREに関するイベントになりますが、私自身はSREエンジニアではなくインフラエンジニアとなります。AWSで基盤構築やリリースパイプラインの作成等の経験はありますが、SLOの策定等いわゆるSREとしての案件従事の経験はありません。今後インフラエンジニアからSREエンジニアにキャリアチェンジする可能性を考えてイベント参加しました。
その為、知り合いはおらずソロで特攻してきましたが、皆様暖かくコミュニケーションを取ってくださいました。会話させて頂いた皆様本当にありがとうございました！！
そんな私が現役のSREエンジニアの方々に伺った話から学んだ事を記載しようと思います。
特定のセッションで学んだことというより、イベント全体を通じて感じたことを記載します。
SREをこれから目指そうとしている方等の参考になればと思います。
目次
参加したセッションなど
セッション
本当はもっと聞きたかったセッションもあったのですが、家の都合等でオンデマンド配信も見逃してしまいました。アーカイブ動画出てくれないでしょうか。。。
DAY 1
- Fast by Friday: Making performance analysis fast and easy
- モニタリング統一への道のり - 分散モニタリングツール統合のためのオブザーバビリティプロジェクト
- ロールモデルなき道をゆく、女性SREキャリア談義（パネルディスカッション）
- SREを知らずにSREマネージャーになった話 〜求められたのは技術力より◯◯だった〜』（LT）
- SREがコストセンターではないことを大きな声と実例で伝えたい（LT）
- インフラ寄りSREの生存戦略（LT）
- システムから事業へ 〜SREが描く“その先”のキャリア〜（資料参照のみ）
DAY 2
- すみずみまで暖かく照らすあなたの太陽でありたい
- 数万リソースのCI/CDを爆速に！Terraform・ArgoCD改善の全記録
- Four Keysから始める信頼性の改善
有難いことにセッションの資料については、以下記事にて整理してくださっている方がいらっしゃいます！
スポンサーブース
SRE NEXTではスポンサーブースを回るごとにスタンプをもらえるスタンプラリーが開催されていました。私は全てのスポンサー様を巡りました！タイミー様のところだけ汚れてしまいすみません。。。
モニタリングツール体験パーク
主要なモニタリングツールのデモ環境を一挙に見ることができる素敵な企画です。
私はDatadog,New Relic,Splunk,Grafanaのブースでお話を伺いました
現職SREエンジニアの方々から得た教訓
上記のイベント参加を通じて、印象に残った内容や重要だと私が感じた事を教訓として記載します。
信頼性は利益に直結する
一見するとSREはビジネスを直接的に実現するアプリケーションではなく、それを支える仕組みとなるのでノンプロフィットにも見えてしまう。
しかし実際はSREは単なるコスト削減や障害対応を担う存在ではない。障害を未然に防ぎ、サービスの継続的な提供を保証することで機会損失を防ぎ、ユーザーの信頼を獲得する。結果として継続利用や新規獲得に寄与し、長期的な利益創出につながる。
↓
SREはプロフィットセンターである。
技術よりマインドセット
現役SREエンジニアの方々が特に仰っていたのは、単なる技術力以上に以下の様なマインドでした。
-
責任感
信頼性という言葉は曖昧だが、そこに対して責任を持ちビジネス層に向けた説明を果たす責任感が必要。SREはインフラやコード周りの専門家であると同時に、プロダクトマネージャーやカスタマーサポートなどと連携し、信頼性基準を合意形成する役割も担う。技術的な説明をビジネスサイドに噛み砕いて伝え、ステークホルダーを巻き込むコミュニケーション力が、サービス全体の成長を支える鍵となる。
-
事業貢献への思い
SLI/SLOを定義することがSREの仕事ではない、ユーザーにとってより魅力的なプロダクトを提供し続ける為に指標を定義し、それを活用していく必要がある。常にビジネスを視野に入れて何を為すべきか考えていく必要がある。
例えばKubernetesのバージョンアップはエンジニアとしては為さねばならない事である一方で、それをしたからといって利益を生み出すわけではない。その為、エンジニアとして為さなければならない事は当然行いつつ、コスト削減の施策などビジネスインパクトのある行動を心掛ける必要がある。
また、新規サービスと成熟サービスでは、求められる信頼性レベルが異なる。ビジネスが成熟する前の頻繁にリリースを回したいフェーズでは多少の障害を許容しつつフィードバックを得る一方、安定稼働期には信頼性を重視する。ビジネスのフェーズに応じたバランス感覚もSREの設計力に関わってくる。
-
周囲を巻き込む力
IaCや監視ツール、CI/CDパイプラインなどを導入できたとしても、使い方が社内に浸透しなければ価値は半減する。勉強会を企画したり、ドキュメントを整備したりしてツールを組織に浸透させること。それを加速させる行動力こそが、SREとしての価値を高める事になる。
教訓以外の学び
どういった人がSREエンジニアになっている？
私がお話を伺った限りでは、SIerから転職している方もいれば事業会社から転職されている方もいました。インフラエンジニアからキャリアチェンジされた方もいればバックエンドエンジニアから転職された方もおり、多様なルートがあるようでした。
転職活動の場ではないのでここについてはあまり詳しく話していませんが、辿り着くルートは多そうであること、何かしらの強みを持って転職でSREになっている人が多そうな印象を持ちました。
また、皆様コミュニケーション能力が非常に高いと思いました。非SREの私にも優しく対応頂いたこともありますが、知っている情報はどんどん互いに共有していこうという気持ちを強く感じた事と、SREの方同士の横の繋がりも広そうだなと思いました。SREという職種についてのイベントが開かれるくらいなので、職種の特徴として積極的に社外にも出てコミュニケーションを図ろうとするポジティブな方が多くて素敵だと思いました。
必要な技術要素
教訓として「技術よりマインドセット」と記載しましたが、マインドセットだけでSREになれるわけでは当然ありません。セッションを聞いていても他のイベントと比較して非常にレベルが高い内容が多いと私は感じました。発表の内容ももちろんですが、ブースで会話させて頂いた方々も一人一人のツワモノ感が凄いです笑
以下はイベント主催者が行っていたSREチームの担っている役割に関するアンケートで、私が帰宅前に撮影した断面の情報です。FinOpsやパフォーマンスチューニング、監視/オブザーバビリティ、共通基盤やインフラ対応等が多そうです。ここでは明確な表現がありませんが、トイル削減の為のプログラミングも発生する場合があると思っています。
非常に多岐に渡る技術要素が必要になりますが、インフラエンジニアの私としてはプログラミングレベルがどの程度求められるのかを特に気にしていました。
Embedded SREとして働く方は開発チームとの信頼関係醸成の為にご自身もアプリケーションコード作成に携わっているという方もいらっしゃいました。一方で、SREになる前はゴリゴリのインフラエンジニアでbash経験のみだったという方もいらっしゃいました。また、オブザーバビリティ確保の為にアプリケーションのソースレベルで手を加える必要があるケースもあるので、会社によってまちまちですが一定のプログラミングスキルはやはり必要と考えた方がよいと感じました。
パフォーマンス面で優れているGoを重要視している方もいらっしゃいましたが、言語面では特定の言語でなければならないというよりもこちらも会社によりけりという印象を受けました。
AIとの関わり
生成AIが普及していく事でものづくりの部分は効率化がどんどん進みます。そうした中でも他者を巻き込んでいく力や意思決定は継続して人が担う必要がある部分となります。AIは選択肢を提示してくれるが、判断はできない。論理的な最適解ではなくチームのモチベーション等、人の思いも踏まえて人が最終的に判断を行っていくという観点が重要というお話を伺いました。
以下はMIXI様が集計していたアンケートを私がブース訪問した際に撮影させていただいたものです。
青丸が既にAIを実際に使っているという集計結果になりますが、もう既に多くの分野で活用が進められているようです。私の身の回りでは日頃の相談等では使われている一方それ以上の活用は進んでいなかったのでこの結果には衝撃を受けたと同時に学ばなければならないという危機感を強く感じました。
今後SREエンジニアになる為に
インフラエンジニアとして業務をしているとどうしてもビジネス目線からは遠くなりがちです。しかし、SREエンジニアであればインフラエンジニアとしての経験を活かしつつ、ビジネス目線を意識する機会を増やす事ができる事、また、オブザーバビリティやプログラミング等現在の業務範囲から更に幅を広げていくことができそうだと感じました。
ここまでを踏まえて自分が今後SREエンジニアを目指すにあたり、以下を意識していこうと思います。
マインドセットの強化
日々の業務でもこのタスクは何のために行うのかを常に意識して対応しています。この目的意識の目線の視座を高めていくことが重要だと思いました。つい技術屋目線でこの技術を使ってみたいからとか、こっちの方が面白そうだからという気持ちが私は先行してしまいがちだったのですが、価値ある選択ができるように意識改革が必要だと思いました。
また、月並みですが以下の様な外へのアウトプットという事も今後より強く意識していく必要があると思いました。
- 社内勉強会や技術ブログで情報を発信する機会を増やしていく
- SREのコミュニティやイベントに参加して横の繋がりを増やしつつ、様々な方とコミュニケーションを図る
技術力強化
私の場合はインフラエンジニアとして実務でAWSやTerraform、リリースパイプラインの設計/構築の経験はある状態です。この前提を踏まえて、これからSREエンジニアになるのであれば重要順に以下要素を磨いていく必要があると思いました。インフラの経験がない方はAI学習の次くらいの位置づけで勉強が必要になるのではないかと思います。
- AIについての学習
- オブザーバビリティの実践
- PythonやGo等の言語学習
AIについての学習
最近は猫も杓子もAIの話題で持ち切りという事もありますが、これを学ぶことでその他の事項の学習効率を飛躍的に高めてくれるので第一優先はAIについて学ぶ事だと思いました。まずはプロンプトエンジニアリング等を通じて効果的に情報を引き出す方法を学ぶことで学習効率を高める。その後どの様なAIが存在しているのかを調査し、開発効率を高めるためのAIや、システム開発で組み込むAIについての理解を進めていくのが重要だと思いました。
オブザーバビリティの実践
オブザーバビリティはSREの主要な対応項目の一つです。Python等の言語学習の必要性はポジションによりきりですが、オブザーバビリティはSREとしてまず間違いなく必要となる要素なので優先的に学んでおいて損は無いと思いました。概念としては机上でもある程度理解できますがモニタリングパークで色々なダッシュボードを見て、自分でこういったダッシュボードを作ってみたいと純粋に好奇心が湧きました！学びに好奇心は非常に重要だと思っています。
様々なツールがありますが、多くの有償ツールは一定の無償期間が過ぎたら機能が制限されるのに対して、New Relicは期間無制限でほとんどの機能を使い続けられるそうです。Grafanaの様なOSSを使って学ぶというのも手ですが、本来有償で多機能なツールを無償で勉強できるのであればこちらで勉強するのが良さそうに感じました。
New Relic フリープランで始めるオブザーバビリティ！
PythonやGo等の言語学習
こちらについては一定レベルは必要だと思いますが、自身が完璧にプログラミング能力を身に付けずともプログラミング能力を備えているAIを使いこなす事で代替性が高い分野だと思ったのでオブザーバビリティの方を優先すべきかと思いました。とはいえ、AIの出力内容の妥当性を判断するためにも一定の理解は必要だと思うので少しづつ学んでいければと思います。
まとめ
SRE NEXTを通じて多くの学びがありました。インフラエンジニアが次の一歩を踏み出すためにSREの概念や技術を学ぶことはとても意義のある事だと思いました。
SREをこれから目指す人の参考になればと思います！
この記事が少しでも参考になったなら、次はあなたが何か一歩を踏み出す番かもしれません。
もし自身がいつかSREエンジニアになった場合は、この記事に記載した内容が実際どうだったかのアンサー記事とか書けたら面白そうだなと思ったりします。