Beatrust で SRE をやっている Yuta（中川 裕太）です．運用がラクにできるように色々と改善したり，セキュリティ向上したり，インフラ作ったり API 開発したりしています． 世の中的には SRE NEXT 2022 が開催され SRE に対する機運が高まってきているこのタイミングで，ブログという場を用いて Beatrust にジョインしてから約1.5年間 SRE として実践してきた筆者自身の Try とその振り返りをしたいと思います．
創業期スタートアップに SRE は必要なの？
SRE はある程度成熟した企業が持つもので，そもそも創業期スタートアップに SRE を設置する必要があるのかという問いはあるかと思います． Beatrust は創業3年目のスタートアップで，確かに同様なフェーズにあるスタートアップではシステムの安定性よりもまずは PMF を達成するために機能開発を優先することが多く，一般的には SRE を設置するには時期尚早と思われるかもしれません． 一方で，Beatrust は大企業のお客様を主軸にユーザ数が1年間で10倍になるなどの成長をしており，お客様が求める可用性やセキュリティなど高信頼性を満たすことがそもそもプロダクトを使ってもらう第一歩になることが多いという性質があります． つまり，高信頼性を保ちつつプロダクト開発の速度を高めることが求められており，創業期ではありつつも SRE を置いています．
SRE としての Try
筆者は，創業1年目のタイミングで SRE として Beatrust にジョインして様々な試行錯誤を繰り返し，時には失敗もしながら色々と学んできました． 創業期スタートアップにおける SRE のノウハウはパブリックになっているものはほとんどなく，自ら考え試す中で振り返って改めて重要だと思うポイントは以下3つです．
- システムや開発メトリクスのダッシュボード，アラートなどを用いて今の自分たちを可視化する．
- セキュリティのベースラインは率先して整える．
- ポストモーテムなど振り返りを徹底して文化として根付かせる．
システムや開発メトリクスのダッシュボード，アラートなどを用いて今の自分たちを可視化する
Beatrust にジョインした当初から，システムのメトリクスが見れたり，アラートが定義されている状況ではありました． 一方で，それらを一覧化できるダッシュボードがなかったり，アラートも意図を持って定義されているものは少なく，「何となく」設定されているものが多い状況でした． 例えば，一見するとシステムの負荷を監視しているような項目であっても，よくよく設定を見返すと，ユーザアクセスが単純に増えただけで発報するアラートなどもある状況でした．
そこで，まず Cloud Monitoring でシステムの状況を一覧化できるダッシュボードを作りました． また，アラートに関しても「発報されたら確実に Next Action が取れるもの」とその定義を明確にし，それが不明瞭なものやある種のワーニングとして出されていたアラートの整理，再設定を実施しました．
さらにシステムの運用状況だけではなく，開発状況についても可視化することで自分たちを定量的に評価できるようにしました． 具体的には，DevOps の Four Keys の主に開発速度に関わるメトリクスである Deployment Frequency と Lead Time for Changes を実装しています．
セキュリティのベースラインは率先して整える
次に重要だったと考える Try はセキュリティのベースラインを整えることです． Beatrust にはシニアなメンバーが多く，セキュアコーディングの実施は十分にできており，アプリケーションレイヤーに脆弱性を埋め込みにくい体制ではあります． とはいえ，完璧ではありませんし，多重でセキュリティを向上させることには意味があると考え，Web Application Firewall (WAF) や database レイヤーの Row Level Security (RLS) などを導入しました． これにより，セキュリティのベースラインを向上させ，アプリケーションレイヤーで何かミスがあっても問題化しにくい構成にしました． RLS の取り組みについては以下を参照ください．
また，サービス価値向上のためのユーザ行動分析に対して，セキュリティガードレールを整備しました． 具体的には，Google Workspace Group の権限に基いて閲覧できるデータ種別をコントロールできるようなデータ分析基盤を実装し運用しています． より詳細な実装については以下を参照ください．
ポストモーテムなど振り返りを徹底して文化として根付かせる
最後は何かあるごとに振り返りを徹底し文化として根付かせることです． プロダクトを運用する上で，システム障害はつきものです． それをネガティブなものとして捉えるのではなく，次につなげるポジティブなチームとしての学びとなるよう率先してポストモーテムを実施するようにしました．
また，大きめの機能リリースの際には事前に何を KPI とするのか，お客様にどういう状態になってもらいたいのかを議論し，リリース後に振り返るようにしました． 定常業務においても，振り返りを重視し，当たり前といえば当たり前ですが，2週間に1度チーム全体で集まって KPT を実施するようにしました． その中で，振り返りのやり方の振り返りなども状況に応じて実施し，チームとしてよりよい振り返り方法を議論するようにしています．
Try に対する振り返り
振り返りの文化を体現するため，SRE としての Try に対する振り返りを実施していきます．
システムや開発メトリクスのダッシュボード，アラートなどを用いて今の自分たちを可視化する
システムの運用状況や開発状況を可視化し，ここを見れば運用と開発の状態が分かるという場所を整えたことで，自分たちを定量化して捉えることができるようになりました． また，以前はアラートが鳴っても何をすべきか分からず静観することも多かった自分含めチームに，アラートが鳴ったら対応しなければならない，という意識を根付かせられたことも非常によかったと思います． 特に筆者自身が忙しくてアラートを見切れていないタイミングで，他チームメンバーが率先してアラートを見て対処してくれたことは非常によい経験でした．
一方で，運用と開発のダッシュボードを見るタイミングは定期的な振り返りの場や障害発生時だけに限られており，日々リアルタイムに自分たちの状況を見れているわけではありません． さよなら、ありがとう Belle ちゃん - April Fools' Day 2022 Wrap-up の中で軽く紹介しましたが，オフィスという物理的な場でダッシュボードをチーム全体で見るという体験は今の状況をリアルタイムに捉えるという意味で非常に有益でした． コロナ禍の中で物理的に集まることはなかなか難しいですが，以前ならばオフィスという物理的な場で容易に実現できていたようなリアルタイムに自分たちの状況を確認できる場をどう設計していくかが次の Try と考えています．
セキュリティのベースラインは率先して整える
WAF や RLS，データ分析のセキュリティガードレールを整えることで，大企業のお客様が求める水準までセキュリティを高めることができたと自負しています． また，ベースラインがあるからこそ，新しいことをする際にそのレベルをどう担保するのか，どう改善するのか，逆にどうリスクを取るのかで議論できていることは非常によいポイントだと考えています．
一方で，高すぎるセキュリティが業務遂行上の妨げになってしまっては元も子もなく，セキュリティレベルと利便性の間でバランスをどう取っていくかが今後の課題だと考えています． 具体的には，アプリケーション実装やデータ分析において，セキュリティを厳しくしたがために，ある種の抜け道を作らざるを得ない状況になってしまっています． この抜け道はコントロールされたものでリスクとしては顕在化していませんが，セキュリティレベルを保ったまま抜け道を作る必要がない仕組みに作り変えていくことが次の Try と考えています．
ポストモーテムなど振り返りを徹底して文化として根付かせる
システム障害や大きな機能の開発，日々のチーム運営の中で振り返りを徹底することで，誰が言うこともなく何かあった際にチームで振り返りが実施できる状態，ある種振り返りの文化を醸成できたと思っています． また，どんなに忙しくても2週間に1回のタイミングで地に足をつけて振り返りを実施する，当たり前のことを当たり前に実施できるサイクルを根付かせることができました． さらに振り返りを実施して終わりということはなく，そこで議論した結果を開発やリリース，運用のプロセス，顧客対応へと反映しドキュメント化できていることも非常によいポイントだと考えています．
一方で，システム障害が頻発してしまった時や忙しいタイミングでポストモーテムの開催が数週間後などになってしまったことが数回あったことは改善ポイントです． 振り返って根本対処を完了するまでがシステム障害だという認識をよりチームメンバーで共有し，自然とポストモーテムが数日以内に実施できるようなサイクルを作り込んでいくことが次の Try と考えています．
まとめ
創業1年目に SRE としてジョインして約1.5年間で実施してきた Try を振り返りました． その中で最も大事だと学んだことは，SRE をチームとして実践できるようにベースの仕組みを整えていくこと，そしてそれを文化として根付かせていくことです． プロダクト開発の優先順位上，どうしても一人では信頼性のための活動に時間を割けないタイミングはあります． そんなタイミングで，チームが信頼性を意識してフォローに回ってくれたことは非常によい経験であり，そのための仕組み作りや文化作りは改めて重要だと学びました．
Beatrust にジョインした当初は，SRE として何をすべきか右も左も分からない状況でオープンになっている事例も少なく，いろいろと悩みながら試行錯誤を繰り返してきました． この記事が同じような悩みを抱えた人たちに多少なりとも貢献できたらよいなと考えています．
ちなみに，SRE NEXT 2022 の当日は同僚と ノーザンホースパークマラソン2022 に参加しハーフマラソンを楽しんでいたので，後で SRE NEXT 2022 のアーカイブを見てさらに振り返りを深化させていこうと考えています．
大企業のお客様に求められる高信頼性を満たしつつ一緒に開発速度を爆速に上げる仲間や，仕事も遊びも一緒に死ぬ気で楽しむ仲間を募集中です！
