2020年の1月から立ち上がったSREチームの取り組みをふりかえります。
※これらはSREチームの成果であり、記載された内容のすべてが筆者だけの成果というわけではありません
価値でみる
結局の所、SREチームは事業にどのような価値をもたらしたのでしょうか。
まず課題として
- プロダクトのパフォーマンス向上の必要性
- セキュリティ向上
- （競合に勝つための）より高速な開発体制
がありました（これはどの組織でもあるでしょう）。
そこで弊SREチームの役割は、以下のような側面をもって活動しました。
- 信頼性に関連する運用開発（モニタリング、セキュリティ、自動化、高速化、Deploy信頼性、トイル撲滅、改善の仕組み）
- プラットフォーム運用開発（開発環境の性能・使い勝手の向上）
- 他チーム依頼の運用開発（AI, Mobileチーム）
- コストカット
パフォーマンス向上と一口に言っても様々な観点での取り組みが必要です。 その土台づくりから取り組んだのがこの6ヶ月だったと思います。
おおまかにその内容を振り返っていきます。
信頼性の向上
SLO/SLI
立ち上げの時点で、インフラのコード化やCI/CDはすでに成立していました。
反対に、SLOという形で信頼性を見ることができていなかったのでまずはここから着手をはじめました。
- SLI
- HTTP Success
- Latency
- SLO
- 決められた目標値を達成しているか
なお、このSLOは2月中旬から2週間ごと（スプリントふりかえり時）にレビューを実施して数値を記録しています。
現在まで目標値を下回ることなく達成できています。
（※SLAは設定していないため、SLOも非公開としておきます）
これまで、プロダクト利用可能の判定はサーバのダウンタイムでなんとなく測っていた（あるいは測っていない）状態でしたが、
数値で見えるようになったことはひとつ大きな進歩です。
モニタリング
SLIの設定に紐付いて重要なモニタリングの改善です。
よりよいモニタリングは、より正確にプロダクトの状態を判断したり、ある地点と今を比べてプロダクトが劣化していないか確認するのに不可欠でした。
これまでのモニタリングでは
- しきい値を超えたらアラートが飛ぶ
- システムリソースが確認できるダッシュボードがある
といったシンプルなものでした。
SLOがある以上、それを計測するための仕組みが必要となります。
- ダッシュボード
- エンドポイント別レイテンシ
- ユーザ（ドメイン）別レイテンシ
- アラート
- 一定以上のエラー
- 水準以上のレイテンシ
現時点でのパフォーマンスはどのようなものかを知ることで、理想状態への改善につながり始めます。
他にも、これまで転送していなかったRDSのスローログをDatadogで検索できるようになったことで、開発者のログ確認はほぼDatadogで完結するように変化してきました。
このような最低限とも言える土台もなかったので今回ベースができたことは良い点でした。
Terraformによる設定
このモニタリングのトリガー設定についてはTerraformでコード化しました。
これまで自分ひとりで設定していたのですが、チームとなったので設定のレビューも必要と考えての実施です。
- 誰かが変更したとき何から何に変更されたのかわかりにくい
- しきい値などをGithub上でレビューすることができる
- つまりバージョン管理できる
これにより、SREチーム以外の開発者がプルリクエストを作成してトリガー設定をすることもできるようになったのは大きいです。
実際に新機能開発チームからプルリクエストを受け付けたことで、SREチームのレビューを通した形で設定を反映することができました。
かつて自分ひとりで設定していたときは「あれ、なんでこれこの設定にしたんだっけ……完全に忘れた」なんてことがよくありました。
変更も追加もプルリクエストに説明が入ることで、こういうことはなくなります。比較的すぐに効果の出る運用改善でした。
セキュリティ
SREチーム全体でセキュリティ面の向上にも取り組みました。
- バージョンアップ
- 脆弱性検知
- VPN経由のアクセス
- GuardDuty導入
バージョンアップ対象はRuby, MySQL, MongoDB, EKSなど多岐に渡りました。
といっても一回やれば終わりではないのでこれは随時アップデートしていく予定です。
脆弱性検知は、ECRのコンテナ脆弱性検知結果やNodeの脆弱性検知結果をSlackに送らせたりし始めました。
いずれも最低限設定しておくべき内容でしょうが、これまでできてなかったのでこのタイミングでできてよかったと思います（こなみかん）。
Deploy改善
DeployはKubernetesとCircleCIを組み合わせることで継続的デリバリーしています。
この実装の細かい部分で不完全な箇所があったため改善に取り組みました。
- 失敗時クラスタにアクセスしなくてもCircleCI上でエラーログを確認したい
- Deploy Workflow同士の排他制御
小さいことではありますが、長くなりすぎているCircleCIのconfig.ymlを削ったりしてました。まあこの辺はおまけです。
ボーイスカウトルールというやつです。
xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com
トイルの撲滅
どうしても発生する、無価値な運用作業を根本から滅する活動もやりました。
自動化は基本的にできていたため、SREチームを苦しめたのはほとんどがアラートを起因とするものでした。
発生するたびに、SREチームのバックエンドスペシャリストが淡々と原因を根絶やしにしてくれました。
改善の仕組み
SLOやモニタリングに関しては、設定したそのときが完成形ではないため、決めた期間でレビューをして改善するように取り組んでいました。
参考にしたのは@chaspyさんのこちらの発表でした。Datadogにダッシュボードをつくるあたりも大変参考になりました。
SLOはスプリント計画時にチェック。
モニタリングは金曜の朝会時に、アラートの妥当性や発火したアラートを元にシステム健全性を確認しています。
違和感のあるアラートがあれば、その時々に相談結果をTerraformに反映して修正をします。
その成果もあり、現在では本当に重要なアラートしか流れてきません。
定期的に見直す会は今までやってこなかったのですが、これを定期開催するように提案してみてよかったです。
コード化や自動化をする組織は増えてきました*1が、。
さらに深ぼりして専門的に改善サイクルを回す文化を育てやすいのはSREチームならではかと思います。
他の開発チームにも知ってもらえるよう、モニタリングレビューをSREチーム以外でも参加できるように広げていきたいです。*2
プラットフォーム改善
主に開発環境の使い勝手改善です。
弊開発環境についてはこちらにもあります。
- 開発環境をより本番に近い構成に変更
- SREチームが介入せず開発者が柔軟にスペックをカスタマイズできるようドキュメント整備
- Deployフロー改善
- コストカット
細かく書くと終わらないので割愛しますが、開発者の運用コストになりそうな面でも貢献できました。
数字でみる
トイル対応（撲滅含む）以外の作業に68%割くことができました。
ロードマップストーリー内に機能改善や信頼性向上のタスクが積まれていることが多いため、グラフ上はロードマップストーリーの割合が多いです。
そこに含まれずに実施できたものについては『パフォーマンス改善』『機能改善』といった形で表現しています。
チームで判断して、プラスαで対応したものとします。
その他：社外活動
これはチームというよりは自分個人で実施したことです。
SRE座談会
SREという職種にだけ縛り、業界を固定せず、知り合いのエンジニアを誘って4名で開いてみました。
各社のSREさんと情報交換できて非常によかった。
— VTRyo (@3s_hv) 2020年5月27日
ToC,ToB, 大手, スタートアップみたいな立場によっても全然観点違ってておもしろいし、共通の部分は共通である。
思えばじっくり同業者とこの話題で語るというのはしたことがなかったので僕は非常に楽しかった😃#SRE座談会
業界やユーザの特性によりSREの在り方が異なる点が非常に面白かったですね。
肩肘はらない気軽な情報交換会がしたかったので個人的に満足度高めです。
SREに関連するイベントは最近複数存在します。登壇者の方はかなりつよつよだと思っていて、等身大のSREの話しが聞きたかったのも理由でした（集まってくださった方もつよつよでしたが身近な存在だったので助かりました）。
もし私も参加してみたいという方がいましたら、こちらに連絡をください。人数が集まるようならまたやってみたいと思います。
（レベル感はお気になさらず。情報交換はいろんな方がいるほうが有益です）
登壇
登壇もしていました。CircleCI Meet upオンラインです。
社名のPRにもなるし、登壇は効果が大きいですね。オンラインだったので全国の方に見てもらえて嬉しかったです。
Podcast
しがないラジオに再出演しました。
SREに関しても話しました。メインはキャリアの話しなのでここでは割愛します。
sp.85【ゲスト: 3s_hv】10年小説を書き続けてきたエンジニアのかつて想像できなかった楽しいキャリアを公開しました！
— しがないラジオ公式 (@shiganaiRadio) 2020年6月8日
VTRyo @3s_hv さんをゲストにお迎えして、マツリカでの働き方、SaaS、SREチーム立ち上げ、執筆業、老害化、などについて話しました。
https://t.co/PdfMhef4hZ #しがないラジオ
今後の展開
スタートアップなので状況によって簡単に方向性は変化しますが、 この半年で作った土台を活かしてパフォーマンス改善やKubernetes運用改善に取り組むと思われます。
Kubernetes本番運用が開始されたのは2019年の年末でもあり、まだまだ手間のかかる部分があります。
それもまたレポートが書けたら良いなと思います。
副業もぼちぼち探てたところですが、副業でSREを探しているところはあまりないみたいですね。
本ブログを見てピンと来た方はいつでもお気軽に相談ください。
