ども。2020年、弊社はSREチームを4名3名にしてパワーアップしました*1。
その取り組み備忘録を小出しにしていきます。細かいテクニカルな話は長くなるのでまた別途にします。
2019年まで
2019年はSREチームという名前はなく、クラウドインフラを扱っていた僕を含めた2名が『基盤チーム』という名前でモニタリング、運用、基盤開発などを行っていました。
メインタスクはKubernetesによるプラットフォームの構築だったため、本来SREとして取り組みたいことには注力していなかった状態です。
2020年SREチーム概要
4名体制3名体制のチーム編成を取っています。
- AWSやKubernetesを扱っているクラウドインフラエンジニア: 2名
フロントエンドエンジニア: 1名- バックエンド兼iOSエンジニア: 1名
で構成しています。
SRE本にもある通り、チームメンバーのバックグラウンドが様々な方が良いと思っています。
2019年までの課題に『エラーを検知するが、検知するだけで修正するリソースがない』というものがありました。 バックエンドエンジニアやフロントエンドエンジニアがSREの構成員になることで『エラー検知後、修正までする』を実現していくことも期待されます。
なんのサービスのSRE？
BtoB SaaS業界で、営業支援ツールと呼ばれるシステムを開発しています。
レガシーな営業活動（口頭報告・Excel管理）から脱却し、現場の営業職の人が『本来取り組むべき価値のある仕事』に取り組むための支援ツールです。
これはITエンジニア界隈で言うところのDX（Developer Experience）のようなものと考えるとわかりやすいです。
『気持ちよく営業活動できる』ための営業支援ツールを開発しています。
昨年5億円の資金調達をしたばかりで絶賛成長中です。
キックオフ
1月営業日初日。チームのキックオフ会がありました。
集まったメンバーで、「我々は何をするためにいるのか」を確認しています。
【責任範囲】
- 可用性
- レイテンシ
- パフォーマンス
- 効率性
- 変更管理
- モニタリング
- 緊急対応
- キャパシティプランニング
- セキュリティ
【前半戦（1Q）で取り組むこと】
- SLI・SLOの決定
- （フロントを含む）モニタリングの整備
- トイルの削減
それぞれの役割の納得感
弊社は人数がそこまで多くないので、お互いの得意分野（専門分野）については知っている状態でした。 また、異なるバックグラウンドの人を敢えて集めていることを理解していたので誰がどこに強いかも明白です*2。
とはいえ、バックエンド・フロントエンドの人は本当にSREとして納得感と理解を持っているのだろうか……とちょっと心配になりました。 僕は元々、運用寄りのタスクもやっていたのでSREに対する抵抗感はない（むしろ積極的にやっていきたかった）ですが「他の人はわからないなあ」と漠然と思ったりしてました。
ということでいわゆるチームビルディング的なことをしたほうがいいのか？などと見様見真似で考えたものの、そもそもメンバーはそこまで必要と考えているのか？と裏読み先読みになってきたので
「もし納得感とかそういうのなければ言ってほしいんですがどうですか」
と素直に聞きました。すると「問題ないぜ！」という主旨の回答が返ってきました。
個人的にも「走りながら擦り合わせたり、ふりかえりしながら修正できる」とも考えていたので、キックオフ時から「う〜ん」と思っている人がいないことをヨシとしました（チームビルディング詳しい人からしたらもっとやることあるだろと突っ込まれる可能性）。
ともあれ、メンバー全員まずは前を向いていることを確認できたので一歩前進です。
情報共有
バックグラウンドが違うメンバーが集まっているメリットはそれぞれが持っている知識が違うことです。
ということで、意識的にドキュメントを書き込むようにしています。 SRE本内の自チームに関わりそうなところを要約（それ以外は自身で読んだほうがいいです）したり、監視アンチパターンを抜粋しておくなどです*3。
先日参加したSRE NEXTでの学びもしっかり共有。ここで得たことを参考に自社の取り組みにも落とし込めました。
スプリントとふりかえり
2週間のスプリント期間で開発してます。
ただし問い合わせやアドホックなタスクが発生するのは避けられないので、余力を残してタスクを積んでいるイメージ。
この余力を積んであるタスクが負えられない場合、トイルの増加を認知できると考えています。 次回スプリントにそれらのトイル撲滅活動を積んでいく想定です。
ふりかえりはKPTではなくYWTにしました。KPTのほうが良くなる可能性もあるので、これは走りながら柔軟に変えていけば良いと考えてます。
・KPTだとこの２週間で何をやったかが含まれない。
・YWTはY(やったこと)、W(わかったこと)を振り返るので、成長感を得られやすそう。
・KPTはProblemに引っ張られてできていないことに目を向けてしまう。
設定したSLOのレビューもこのふりかえり時に設定するようにしました。 これは先日のSRE NEXTで発表されていた内容を参考にしています。
Datadogでモニタリングしてるのですが、うまいことNginxエラー率のSLI/SLOをダッシュボードで表現できてないです。 どなたかよい方法をご存知でしたらご教授ください。
こんな感じで
始めました。まだ本格始動一ヶ月程度なので、これからどんどん良くなると思います。
成熟したらしたで、またまとめてみたいですね。
キックオフ以外の取り組みも随時まとめていこうと思います。
