言葉の認識合わせ

ゆるやか成長スタートアップとは

SREないしインフラメンバーが1,2名ほどで、メンバーが抜けない限り採用してない状態
上記メンバーの状態 + 現在のインフラ構成で現在の事業成長ペースに”なんとか”追従できている
- 手は多い方に越したことはないが、費用とのバランスでもう少しこの人数で。。的な
シリーズ的にはPMFを達成したシリーズB以降あたり〜非上場まで
スタートアップなので事業会社

と本記事では定義します。（異論は認めます）

Enabling SRE

SREの知見を有効化する活動
- 開発チームに対してSREの知見や文化を浸透させて実践できるようにしていく
対してEnabling SREは横断的なチームで、各開発チームにJoin（埋め込んで）活動したりする
対してPlatform SREはメインのPlatformにフォーカスする。

この辺が大きい企業だと、チームに分かれてXXXチームとされている場合が多い。（個人的には違いがわからなくなったりする）

Enabling SRE的活動

他の開発メンバーにSREの知見を有効化する活動をEnabling SRE的活動と呼ぶ。詳しい内容は次の項で紹介。

局所的に見るとインフラのスキルトランスファーな面も否めないが、開発メンバーがインフラ改善できる状態というのは信頼性向上に繋がるので、Enabling SRE”的”活動に含めるということでご了承願いたい。（ある意味、名称揺れということで🙏）

目指す状態

信頼性向上（ないしインフラ改善）を開発メンバー自身が提案、あわよくば実施できる

ある意味インフラエンジニアの領域となってしまっている部分に開発者に少し寄ってきてもらう。極端に言ってしまうと少し前で言うDevOpsエンジニア育成

※弊社の場合は自分+（たまにマネージャー）の2人がインフラを管理している状態です。しかもデータエンジニアと兼務。。
理想は全員インフラ管理できればいいですが、インフラ専任を置いたあたりから徐々に分担するようになっていくと思います。

Enabling SRE的活動の紹介

いかに準備時間を下げてゆるくやりつつ、他のメンバーに与えられる価値を最大化できるかがキーになってきます。
参加自体もソフトウェアエンジニア等を対象に任意参加として、一応録画だけしておくスタイルです。

どの会もなるべく最後に参加者全員に一言感想をもらったり、Googleフィームでアンケート（理解度、次回も似たような会に参加したいか、自由記述）を取って開催側のモチベーションを確保しています。

犬を愛でる会（Datadogを眺める会）

犬を愛でる会
datadogをチームメンバー全員で見ながら、パフォーマンス・エラー傾向・負荷状況などを議論する会です。こちらも、誰か一人のタスクではなく、メンバー全員で一緒に同じ情報を見ます。

https://moneyforward-dev.jp/entry/2021/12/01/one-small-commit-for-team/

SREと一緒に「メトリクスを眺める会」のススメ

記事の通り、datadogを自分が主導で諸々眺めています。

頻度：半年に1回、1時間

所感：サービスの成長や、レイテンシーの改善がふりかえることができて良い。（要所要所で各々見てたりして改善ポイントはすでに解決済みだったりする）

スキルマップ（星取表）の作成

詳しくはこのあたりを

スキルマップ作成のすすめ

開発チームは星取表を作れ

チームのマネジメントの場面で登場しがちなやつですが、Enabling SRE的活動をやっていく中でも参考になります。

ゆるやか成長スタートアップでは、ソフトウェアエンジニア自体の数が少なく、SREないしインフラへの興味も人によってまちまちです。

SREないしインフラに対して「空欄：できない」人は対照にせず、できる人を含めつつ「今後習得したい」となっている人をメインにEnabling SRE的活動をしたほうが双方メリットがあります。

ない場合は、人のJoinのタイミングでオンボーディングも兼ねると行いやすいのでおすすめです。

ちなみにうちの星取表はSREという分類は用意してないです。このへんはノリで良いと思います。

CircleCI, CI/CD全般
Docker
Kubernetes
Terraform
AWS全般

ポストモーテムとは + ポストモーテム輪読会

SRE界隈では当たり前なポストモーテムですが、そもそも認知度が曖昧なので、勉強から行いました。

イチからスライドを作ると日が暮れてしまうので、公開資料をお借りしました。ここで御礼申し上げます。

ポストモーテムは学びの場！〜組織のより良いポストモーテムを目指してやったこと〜

一般的知識の勉強会は公開資料を積極的に活用しつつ、話の中で社内事例を軽く出すスタイルが主催者の負担なく継続できる。

一発目はポストモーテムとは(30min) + 輪読会(20min)でした

この辺も新しいメンバーがJoinして少し立った後に企画したり、他のエンジニアの様子を見て企画すると良さそう。

一度勉強会が終われば、後は輪読会を障害の頻度に合わせて定期開催すれば良いと思います。弊社だと半年に1回程度で良さそう。読み直すと放置された是正対策があったりする。。

PlatformのCI/CDの仕組みをざっくりと紹介する

システムによってCDの仕組みはまちまちですが、メインのPlatformのCI/CDの仕組みはKubernatesを使ってる関係上若干複雑なので、紹介する場を50分枠で設けました。

Github / CircleCI
Codebuild
EKS

あたりを既存の構成図を用いつつ、コードベースでざっくりと紹介しました。
若干グダってしまった部分もありましたが、開始前に比べれば理解度は深まったかと思います。

CDがコケたときにのトラブルシューティングや、新たにサービスを生やすときとか、スペック変えたいときとかの取っ掛かりには多少なっているかと思います。

インフラ整地部

AWSから来る細かいアップデート対応や、ちょっとした改善事項に先述のインフラに興味を持っているメンバーとモブプロ方式で取り組む会をやってます。週1回1時間。
実際の環境を題材にすることでスキル的な部分と実環境の知識の両面を獲得できはずですが、実際に取り組む内容次第な部分とメンバーのスキル次第な部分がありハンドリングが難しいです。結局期限が近づくと一人でやってしまうタスクもあったり。

タスクの内容によってはやれそうなら持ち帰りでやってもらいますが、メイン業務との兼ね合いで各々の判断の中で細く長くやれるようにしています。

先々やりたいもの

Terraform入門
監視入門
データ基盤入門

どれもイチから資料は作らず、ぬるっと開催したい

おわりに

SRE NEXTにもちらっと書きましたが、SREの取り組みも企業規模によって変わり、ゆるやか成長スタートアップにフォーカスしたSRE活動は中々無い気がしたので書いてみました。
1つ1つは小さな内容ですが、この積み重ねがサービスの信頼性向上の一歩に繋がっています。

弊社現在エンジニア採用しているので興味があれば覗いてみてください。