はじめに
はじめまして。2024年10月にログラスにジョインした見形（mekka）と申します。
以前は某ToB系のSaaSでSREのEMをしていました。
現在はクラウド基盤チームにてインフラだったり、運用周りのあれこれを担当しています。
あれ、SREじゃないの？ というツッコミはブログの中でも記載していこうと思います。
ログラスはスタートアップの組織であり、運用周りはまだまだ整備が必要な状態です。
そんなところが楽しそう（大変なことも多いですが）と思いジョインしていますが、本当にやることは山積みです。
そんな中でも将来を見据えるとSREのプラクティスや文化を広めることはとても大切で、しっかりと地に足をつけて活動していかなければならないと考えています。
SREという切り口で我々の現状と将来に向けて考えていること、そのための活動を紹介させて頂こうと思います。
これからSREをやってみたいがどこから手を付けようか？と考えている方もいらっしゃるのではないでしょうか。その様な方の何かしらのヒントになればと思います。
SREとはなにか？
SRE（Site Reliability Engineering）という単語がバズワードになったこともあり、SREを名乗る方が増えましたが、イマイチ何をしているのか分からないという方も多いのではないでしょうか。
今回は、SREをはじめようという書籍の内容を引用しつつ、説明させて頂こうと思います。
先日、社内でSREとはなんぞやといった話をさせて頂いたのですが、そのときに書籍の中の文章を引用させて頂きました。
サイトリライアビリティエンジニアリングは、組織がシステム、サービス、製品において適切なレベルの信頼性を持続的に達成できるよう支援することを目的とした工学分野である。
適切、信頼性、持続的というのが重要なポイントであり、これを組織の共通認識として活動を推進していくことがSREのエンジニアに求められることと考えています。
私としては支援というところも重要視しており、信頼性を向上させる活動はSREチームだけで出来るものでなく組織の全員が理解して自発的に取り組むことが大切であり、SREチームはそのための支援をする立場と考えています。いうなればSREの民主化、SREはみんなのものである、というのが信条です。
ログラスで私達SREチームが目指すものも上記の通りで、プロダクトに関わる全員が当たり前にSREの概念を理解して、信頼性向上のために自律的に動けている状態ということになります。
ログラスのSREチームの現状とこれまでの歩み
最初にお伝えするのがログラスには現状、SREの看板がついているチームは存在しません。
以下で、弊チームのEMも表明している通り、現在はクラウド基盤チームという名称で活動しています。
ここについては勿論、その様に判断した理由があり、その時の組織の状態が関係しています。
私がログラスにジョインする前チームは2名で運営されており、その状態でインフラの管理、モニタリング、デリバリー周りの整備・・・etc、とだいぶ幅広く手を広げていました。
この状態で全てを満遍なく対応することは厳しく、インフラ管理に注力するといった取捨選択をすることでシステムの運用に支障が出ない様な判断をしていました。
その際にチームの名前とやることにズレがあるとチームを跨いだコミュニケーションに支障が出る（期待値のズレ）ことが懸念されたため、名称もクラウド基盤チームとなっています。
この名称については私も選考の中で確認しており、これまでの経緯を聞いたうえで、将来的にはどうするのか？ SREの分野を推進していく思いはあるのか？ といった話をしています。
その際、将来的にSREの推進は必要なことで絶対にやりたい、ただし、名前だけでやるべきことがやれない状態は望ましくない、しっかりと体制を補強して推進したい という話をしておりこれに納得してログラスへジョインしています。
この様な中で少しずつですがチームのメンバーが増え（現在4名）社内でのSRE分野への関心が広まってきたこともあり、改めてチームとしてやることを整理しつつ、SREチームと名乗ることも視野に検討を始めたという状況です。
なぜ「SREチーム」への変更を検討しているのか？
クラウド基盤チームのメンバーが増え運用が安定してきたことで、これまでなかなか手が出せていなかった運用以外の改善などに少しずつ手を出すようになってきたのですが、改善のために開発やCSとやり取りをすると色々と課題があることが見えてきました。
パフォーマンス問題、インシデント対応、デリバリ周りの課題・・・etc、組織が拡大したことでこれまで属人的にやっていたことが通用しなくなってきていること、プロダクトが成長したことで利用者が増え、より高いレベルのパフォーマンスやサービス運用体制が求められるようになってきていること このように、信頼性に関連する問題がいろいろと出てきていました。
問題に対して個別に対応する案もありますが、ログラスでは既存プロダクトに加え、新プロダクトの開発も並行して進めており、スケール可能な方法で検討しなければすぐにあちこちで同じ様な問題が発生することが予想できます。
そのため、個別最適ではなく、プロダクトを跨いでしっかりと信頼性に向き合える体制を構築するべく、改めてSREチームについて検討する運びとなりました。
SREチームとしての未来：どこを目指すのか？
この機会に改めてチーム内でSite Reliability Engineeringという単語を噛み砕いて、ログラスが目指す方向性をチーム内で再確認しました。
SREのプラクティスを元に注力すべきことを整理した結果、以下のような分類となりました。
一つずつの説明は省きますが、いずれも信頼性の向上に重要であり、SREチームとしてはログラスに所属する全員が、これらの改善に自発的に取り組める様な仕組み作りと文化醸成をリードしていきます。
また、目指す方向性と合わせて開発チームとのコラボレーションの仕方についても検討しています。
これまでは、クラウド基盤チームがデリバリーなどに関与する形を取ってきましたが、今後はSREを推進するための仕組み作りや利用のためのイネーブリングに重きを置き、開発チームの自走を促す方向でコラボレーションしていくことを目指していきます。
SREチームへの移行に向けた課題とアプローチ
実際にSREチームへ移行するとなった場合も、開発者としては何をしてくれるの？ 自分達を助けてくれるの？ という疑問は残ります。
チームの目的やSRE活動については社内の勉強会で時間を貰って話をしていますが、それだけでは腹落ちしていないと思っています。SREチームを仲間として認識してもらうため、日頃から協業して信頼貯金を貯めるのが大切だと考えています。
そのために小さな事から開発チームと協業を進めていますのでいくつか事例を紹介します。
注意している点としては最終的に開発者が自走できる形に持って行きたいので、全て巻き取って作業してしまうのではなく、フォローしながら開発者側でも作業してもらったり、クラウド基盤チームが用意したものを開発者が使えるように並走する期間を設けたりしています。
アラートの整理
創業当初に設定されたまま改善されていなかったアラートも多く、必要不要が入り混じった状態でした。
これに対して、不要なアラートを削除する対応を進めていますが、クラウド基盤チームでアラートを整理するのではなく、アラートに関する考え方やアクションの整理をフォローして、開発者が自分たちでアラートを選別するように進めています。
CI/CDパイプラインの再整備
複数のアプリケーションが同時にリリースされる必要があるなど、依存関係が生まれており、コンテナ周りの設定変更もクラウド基盤チームに依頼する形となっていました。
パイプライン自体はクラウド基盤チームで刷新をしていますが、コンテナの管理や設定については、開発者側で自由に設定できるように変更しています。
なお、コンテナ管理の責務を開発者に渡す事でコミュニケーションコストの削減に繋がることをしっかりと説明して、お互いのメリットが有ることを理解してもらう点は気を付けています。
また、使い始めの期間は不安が残る状態であるため、運用に乗るまでの期間はクラウド基盤チームにすぐ相談出来るようなフォローアップの体制を敷いています。
インシデント対応方針の再検討
プロセスは存在していましたが、対応をリードする人間によっては報告速度と情報の粒度がCSの期待とズレていたり、調査・復旧対応などの作業分担のコントロールがうまくいかなったりと、改善の余地がある状態でした。
CS・開発者など関係者と改めて取り組みについて協議した結果、インシデント対応の専門的な知見を有するロールとしてインシデントコマンダーを擁立することを決め、クラウド基盤チーム、開発チームからメンバーを募って専任のチームを結成しました。
上記のチームでは、コマンダーを始め関係者の役割の定義、対応プロセスの見直し、対応ツールとしてWaroomの導入などを進めています。
まずは専任チームのメンバーの習熟度を上げることに専念していますが、これが達成でき次第、次のインシデントコマンダーを育てるような育成のサイクルを回していく予定です。
まとめ：SREへの進化がもたらす価値
プロダクトの成長に合わせて利用者は増加し、信頼性の重要度はどんどん大きくなっていきます。
組織も、その成長速度に遅れを取らないよう進化し続ける必要があります。
クラウド基盤チームはSREチームへ移行することで、インフラ管理のスコープから脱却し、信頼性を軸により広いスコープで多様な施策にチャレンジして、プロダクトの信頼性向上へ寄与していきます。
おわりに
今回、SREへチャレンジするタイミングで、改めてログラスにおけるSREとは何かを深堀りし、SREチームとしての未来 に記載した軸に辿り着きました。
急がば回れで、自分達の立ち位置をしっかりと考えることが大切だと思います。
改めて自分達の目指すSREの形をチームで考えてみるのは如何でしょうか。
ログラスでは一緒に働くエンジニアを大募集中です！興味をもっていただいた方はカジュアル面談でぜひお話ししましょう！
Discussion