サマリ
状況
- 自社SaaSは新しくリリースされたばかり
- 新規機能追加に忙しい
- 専任のSREエンジニアがいない
- チーム全体の経験は受託開発が主
課題
- 監視・運用・保守の方法がわからない
- 新規機能開発に圧力を感じて保守開発がおろそかになっている
解決策
- チーム全員で通常の定例とは別でSRE定例を行うことにした
アクション
- 週に1度のSRE定例を開催する
- サービスの品質、運用方法、手作業の改善について議論する
- 次回までに各自ができる小さなタスクを決めて実行する
結果
- 2ヶ月以上の取り組みで、不安が減り、後回しにされがちなことを進めることができた
- メトリクスアラートの設定と改善
- 監視シフトの決定
- 運用ドキュメントの整備
これから
- 継続して取り組み、後回しの部分を解消していきたい。例えば、ロガーの整備など。
雑記
背景
弊社は2023年10月に新しいバーティカルSaaSをリリースしました．3DCAD図面をアップロードすると図面解析を行い自動レビューしてくれる自動車関連メーカーや電機メーカー向けサービスです．
PdMが数年間かけて構想したサービスで，そのリリースはとてもめでたいことなのですが，一つ大きな課題があり，それが今回の記事のネタです．
サービスリリースしたばっかりということもあり，主体としている機能が市場に受ける，いわゆるPMF（ProductMarketFit)しているかわからない現在の状況は，市場探りと並行して第二第三新規機能を次々と開発するビジネス側の圧力として存在します．
ありがたいことに，そんな状況のなかで，お客様にサービスを契約していただき，利用数も伸びてきました．そうなると，ユーザーがいるということになり，ユーザーがいるということは，サービスの監視運用保守をしていかなければなりません．
しかし，我々の開発チームは，これまで受託開発でさらに保守経験も少ないというチームであり，SaaSをリリースしたものの，どのように監視運用保守をしていけば，イマイチわからないというのが今回の課題です．
対応
いまどき(?)の流行りとしては，例えば，SRE専任のエンジニアを採用してSREを行ってもらうというのがひとつあるかもしれません．
厳密にはSRE専任というのは存在しないという声もあるかもしれないし，スクラムだDevOpsだというのは，各々が自分の得意領域を活かしつつも全方位に対して新規開発から運用保守まで担えるようになるのが理想的です．
まぁそういう，あるべき論はどうだというのとは関係なしに，そもそもSREの経験値が少なくともチームとしては圧倒的に不足しているのが私たちのチームなので，全員野球でやるしかないのです．
そこで全員野球をするために考えたのが，今回のテーマであるSRE定例を行うという解決策になります．
リリース前の開発時からデイリーミーティングを30分~60分ほど行っていました．デイリーとは別で，SRE定例をウィークリーで30分行うとなかなか良かったというのが今回の話です．
具体的にその定例で何をやるかというと，バグがある，ドキュメントが不足している，サーバーが時折止まっている，深夜対応は誰がするんだといった，できればワキに置いておきたいデイリーミーティングでは後回しにしがちだったものにフォーカスするミーティングにしました．
そして，哲学としては,小さなことからコツコツとで，次の開催までつまり１週間でできることをTODOとして決めて，各自持ち帰って消化するとして，新規機能開発の合間に取り組めるような枠組みにしました．
大きな痛みを伴うハードルが大きな取り組みは，ガツンとやらないといけないので,おそらくそれは通常のデイリーのほうで計画しないといけないことで，そうではない，小さくて面倒くさいけど必要な斧を研ぐことにフォーカスしたいというのが理由になるかと思います．
結果
取り組みを始めて２ヶ月がすぎたところですが，成果は表れています．
監視アラートはちゃんと設定されているし，それを誰が確認するかは決まっているし，どのような初動対応をすればよいのかもドキュメントが整っています．
こう文章に書くと，とても当たり前なことなんですけど，我々のような未熟で小さなチームでは，これはとても大きな成果で，このSRE定例の取り組みがないといつまでたってもできなかったことだと思います．
今後
書いた通り，まだ当たり前を整えるということに重きを置いた取り組みではありますし，それがとても大事なことではあるのですが，さらにもう一歩をこの取り組みの中で取り組めたらいいかもしれません．
まぁ，この取り組みが役目を終える可能性もありますけど．