変化の激しい成長加速フェーズを支えるSREのやりがい
SaaSやサブスクリプションビジネスをはじめとした継続課金ビジネスの事業成長を支援するSaaSプロダクト「Scalebase」を開発・運営しているアルプ。
今回は、SREの澤田と南川がどんなチャレンジや課題と日々向き合っているかを聞いてみました。
お客様に価値を提供するために、システム全体の安定性を担うSRE
アルプの開発体制とSREのミッション教えてください
澤田:現在、プロダクト組織は「Scalebase」の機能開発をメインミッションとするチーム(以下開発チーム)と開発を横断的にサポート・改善するチーム(以下横断チーム)、プロダクト戦略を担うチーム(以下戦略チーム)の3チームにわかれています。
その中でSREは、横断チームに所属し、システム全般の多岐に渡る課題解決をしています。
私たちSREのミッションは、大きく2つです。
1つが、開発チームがよりよい開発環境でプロダクトづくりを行い、お客様に素早く価値を提供できるようにすること。
もう1つが、お客様が安心してサービスを利用するために、システム全体の安定性を担うことです。
南川:開発チームが機能開発により集中し、開発全体で改善が必要な内容についても推進していけるよう、SRE/QA/バックエンドの専任メンバーで横断チームを立ち上げました。
日々開発を進めていく中で発生する課題の中でも、開発体験に関わるものや、運用面といった非機能的な課題の解決をSREがメインで担当しています。
具体的には、お客様の日々のアクセス状況を見たり、カスタマーサクセスチームと適宜連携しながらお客様への影響が大きい課題から着手し、サービスを安心してご利用いただけるよう、安定したシステムの提供に努めています。
澤田:Redash / Jenkinsなどの社内向けオペレーションツールのメンテナンスやサポートも行っており、運用上の負荷を下げることで、社内メンバーがよりプロダクトづくりに集中できる環境づくりもSREの大切な仕事の1つと考えています。
南川:横断チーム内では、毎朝チーム朝会を行い、タスクの状況や進捗の共有をしています。また、週1でチーム内で振り返りMTGを実施しています。1週間の成果共有や次週やることのプランニング、チームとしてのKPTなどを行っています。
他部署やチーム間の垣根はなく、解決する課題に対して、必要なメンバーと適宜コミュニケーションをとりながら業務を進めているので、コラボレーション機会が他のチームと比べても多いチームだと思います。
プログラムや開発チームにも踏み込んで問題の本質を解決
現在特に注力して取り組んでいることがあれば教えてください
南川:2つお話ししますね。
1つ目は「インフラの管理を自動化する」です。
ツールを利用するユーザーや、そのツールの権限の追加・削除は都度手動にて対応している状況でした。小さい組織では問題もそれほどなかったのですが、手動での管理では権限を統一的に管理できていないなど、管理面での課題を感じていました。組織が拡大してきた中で一元管理をし作業を効率化する観点から、昨年、ユーザー管理と権限管理の整理を始め、コードでの管理を進めました。
Terraform をメインで使用する決定をし、監視ツール周りの設定やGitHub のユーザー管理など、様々なツール設定の管理をコード上で行うように整理を実施しました。Terraform という1つのツールで広い範囲を管理できるようにしており、作業者による設定の違いをなくし、誰が行っても同じ設定になる仕組みを構築することができました。
澤田:Kubernetes の環境設定自動化も行っています。Kubernetes は、設定を宣言的に行えるといった利点がありますが、その設定項目の管理は、CLIコマンドから手動で行っているというところも多いと思います。アルプでは Flux CD の導入を行うことで、GitHub の Pull Request ベースで Kubernetes の設定管理が行えるようになりました。まだ全環境への適用はできていないため、今後も適用範囲を拡大できればと思っています。
南川:2つ目は「アラート整理」です。
今までは、全てのエラーが同じ緊急度でアラートされていたため、エラーのレベルを正しくわけて通知させるように整理をしました。
重要な内容が見落とされがちという課題があり、以前から導入していた監視ツールである Sentry の設定見直しを行い、漏れがでないような仕組みづくりも行いました。
澤田:南川が入社前からツールの導入はされていましたが、適切なルール化がされていませんでした。設定の見直しを行い、エラーのレベル整理を行うことで、開発メンバー1人ひとりがアラートの緊急度に合わせた適切な対応が可能となり、生産性向上に繋がったように感じています。
南川:整理に加え、可能なものについては起きたエラーそのものが起きないようにコードの改修を行い、エラーを回復する仕組みをつくるなど、改善の範囲を広げています。
1つのエラーに対応するにあたって、アーキテクチャ全体の見直しやレビュー体制の見直しなど、問題の本質を解決するために多岐に渡る視点で改善案を提示し実行できる点は、幅の広い経験となっており、SRE ならではといった面白さを感じますね。
澤田:アラートについては、お客様の環境設定変更次第で出てきてしまうものもあります。通常のアラートとして開発者が対応するものなのかどうかなどの整理にも取り組み始めています。ベストプラクティスはまだ模索している状況ですが、仕組みをつくり、改善を積み重ねていくことができるという点ではやりがいもあります。キャリアの幅も広げやすいフェーズなのかなと感じています。
SREとして顧客体験の向上に寄与
今後はより力を入れていこうとしている分野はありますか
南川:アラート整理の話に繋がりますが、そもそもエラーが起らないようにすることが一番と考えており、よりよい方法について模索中です。
潜在的な課題を見つけるため、現在の構成を把握し、プログラム自体にも言及を行ったり、開発運用体制の見直しにも踏み込んでいくことも必要があると考えています。
基盤技術の開発だけではなく、開発チームの課題解決にも踏み込むなどの経験が積めているように感じています。
また、アルプに入社後SREとしての動き方を模索する中で「SREって実はお客様に一番近い存在なのかも?」と感じるようになりました。
例えば、お客様の目に留まるエラーを取り除くことや、そもそもそういったエラーをなくすといった取り組みを通じて、お客様が本来感じなくてよい不安やサービスに抱く不信感を減らし、顧客体験の向上に寄与できているように感じています。機能開発をしていなくても、自分が関わっているプロダクトでお客様の役に立っていることや、自社の成長に寄与できているという実感が持てることに大変やりがいを感じています。
澤田:デプロイ周辺についてはまだまだ課題があり、今後も改善していく必要があるように感じています。SREとして、開発チームがよりよく開発し、お客様により便利で使いやすい「Scalebase」を届けられるよう体制づくりを進めていきます。
成長加速フェーズへ。過渡期を支えるSREのやりがい
どんな人にアルプを勧めたいですか?
澤田:アルプは5期目を迎え「Scalebase」の提供社数は100社を超えました。事業としてはこれから更に伸ばしていくフェーズですが、事業成長を支えるためにはまだまだ解決すべき課題が多くあるのが現状です。
たとえば「Scalebase」のアプリケーション側のエラーの改善/「Scalebase」本体のデプロイの改善などの課題は早めに解決していく必要があると考えています。
今お話した課題はほんの一部です。
SREとして、お客様・開発チーム、そして自社の今後の成長のために提供できる価値はたくさんあります。まだまだ思い描いたレベルまで到達できていないと考えていますし、一見カオスな側面も正直あるかと思います。しかしながら、整っている環境より取り組める課題がたくさんあるとも言えるかと考えています。課題を一つひとつ解決し、結果をだしていくトライをしたい、そういった環境のほうがワクワクする、という方がよりフィットする環境であると感じています。
経験したことのない新しい課題にも臆することなく一緒に進めていただける方だと心強いですね。
南川:まだまだサービスを成長させていくフェーズで、システム全体の安定性を担うために、システムの設計の見直しや、開発チームの体制・開発フローの見直し等、SREとして踏み込んで改善を進めていけるは今のアルプのフェーズだからこそと思います。
アプリケーションエンジニアのスキルを生かして、多方面で開発に関わりたいと思われている方などにもぴったりの環境かと思います。ご自身のエンジニアとしてのキャリアの中でSRE領域にもチャレンジしたいという方は、チームで全力でサポートしますので、チャレンジいただけたら嬉しいです!
最後に
今回の記事で、アルプのSREチームの現状がおわかりいただけると嬉しいです!
弊社のSREに少しでもご興味を持っていただけた方がいましたら、ぜひお気軽に下記カジュアル面談ページからご連絡ください。
この記事が気に入ったらサポートをしてみませんか?