この記事は 10X アドベントカレンダー2022 28日目のエントリーです。
シリーズ共通のお題、「好きなスーパーと商品は？」について。好きなスーパーはクイーンズ伊勢丹です。高輪に住んでいたとき最初はほかに選択肢がなく利用しはじめたのですが、通うたびに気になる商品に出会うことが多く好きになりました。好きな商品は石野味噌です。天明元年から続く歴史ある白味噌です。
今回のエントリーの投稿に際し、ちょうど転職をして1年になるので入社から今までのタイムラインの振り返りと、来年以降の自分の考えについて書き留めておきます。
2022/1 チームづくり
退職と転職。人生の振り返り
今年の1月に 10X へ転職しました。10X では初の SRE Job description での採用ということで、チーム作りや Stailer 事業の拡大を支えるインフラづくりやそのビジョンを描くために入社しました。詳しくは上のエントリにあります。
入社してから4月ころまではチームビルディングやロードマップづくりなどから始まり、今後さらに広がっていく Stailer 事業のパートナー展開をインフラ面からどのように支えられるのか、スケールに耐えられる基盤のデザインが中心でした。
- Datadog 導入
- Kubernetes Cluster のデザイン
- Kubernetes manifest management のデザイン
- Incident 対応のワークフロー整備
- Terraform 導入検討
- デプロイの高速化、リリースフローの刷新
- …
10X に SRE Team ができるまでとこれから - 10X Product Blog より抜粋
2022/4 大きな種まき
4月からは新しい FY がスタートし、前 Q に設定したロードマップをベースに事業マイルストーンから逆算した種まき的な施策を進めました。前 Q はチーム作りを筆頭としてデザインやコトモノの言語化、文化づくりなどが主でしたが、4月からの Q1 はシステム構成に手を加えるような施策や前 Q で PoC したデザインなどを実装・導入するなど、SRE チームとしては大きなインパクトを残すことができた3ヶ月となりました。
- Istio の削除
- Too much な構成からよりメンテナブルな構成に変更
- メインクラスタの Namespace 設計
- パートナーごとの isolation を意識して分割、リソースの引っ越し
- Terraform の導入
- 既存インフラのコード化と apply ワークフローのデザイン・構築
- Terraform module の作成
- パートナーローンチごとに設定していたインフラのリソースセット (GCP/PagerDuty/GitHub/…) を一撃で準備できるように
- SLI/SLO の策定
- オーナーシップづくり
- 各パートナー開発部が開発と運用、両方にオーナーシップをもてるような構成変更
- また、オーナーシップを持つことがどのように重要なのかを全社的に説明
事業スケール確実のタイムラインが見えている中、中長期的に効いてくるものから優先的に着手しました。エンジニア全体に広めに付与されていた権限を整理し、権限ください依頼やリソース作成の依頼など SRE がボトルネックになっていた作業を自分たちでできるようにするために Terraform によるインフラのコード化を行い、またパートナーの横展開がしやすいように module による自動化を進めたり、過去の歴史的経緯によって生まれそしてそのまま残ってしまっている直したい部分をきれいにするなどをすすめました。
また、サービスにおけるオーナーシップとはなにか？というものをドキュメントに落として、サービスチームは自身のサービスの開発だけではなく運用にもオーナーシップを持つことが健全であるとしました。10X にはさまざまなパートナーがおり、パートナーごとにサービスをもっています。そして様々な Deployment や Job が動いていました。ドメインロジックはもちろん開発チームのほうが長けているため、SRE チームに飛んだ開発に起因するアラートを開発チームにエスカレーションすることが多く、これを最初から開発チームが見るように（見れるように）することで、アラート対応にかかるオーバーヘッドを減らし SRE が全アラートに忙殺されるということを解消しました。
また自分の書いたコードによって夜中起こされたくないというモチベーションが発生させることでコードの品質があがるという狙いがありました。この考え方に従って、PagerDuty を使ったインシデント対応のフロー（労務周りや待機手当などの設計を含む）や Kubernetes クラスタの Namespace 設計や権限設計を行いました（責任は権限付与とセットでなくては意味をなさない）。
2022/7 チームの拡大
7月は Leader role の明確な transition がありました。SRE チームは SRE JD で採用された自分とこれまでのインフラを見ていてくれたメンバーと SRE チームアサインされた SWE によって組成されました。僕のオンボーディングをふくめて、これまでインフラを見ていてくれたメンバーが Lead を担ってくれていたのですが、このタイミングでバトンタッチしました。チーム初期の段階からスイッチすることを念頭にチームビルディングをしていたのでサプライズではなかったですが、より一層チームをドライブさせていくぞと意気込む Q 始まりとなりました。
- Monitoring 改善
- コスト見直し
- 採用
- ローンチサポート
- この Q では複数のローンチが控えていたので SRE サポートが求められました
- Terraform コードカバレッジを上げる
- Terraform module の機能追加
- パートナーローンチにかかわる共通化部分をどんどん module に取り込んで自動化の限りを尽くしました
この Q は複数のローンチのサポートが山を迎えてました。前 Q で撒いた種を急いで芽吹かせながらローンチをバックアップしました。それとこの時期は何よりも採用でした。イベントや Podcast 公開なども併せて行ったのですが、功を奏してカジュアル面談や面接まで来てくれる方がとても増えました。採用は両方向のマッチングです。お互いハッピーになるようにはかるのはとても難しいことでしたが、なんとか新しいメンバーを迎え入れることができました。
2022/10 Engineering Manager に
10月は大きな組織改変と人事制度 (評価/報酬/等級) の刷新があり、このタイミングで SRE/Security div の EM となりました。これまでのエンジニア人生ではすべてを IC として働いてきましたが、EM はどうかという打診があったときに両方知っていることが強みになるなと思い挑戦の意味を込めて引き受けることにしました。
EM となることでより LB として機能しやすくなりました。すべての一旦の口になることで SRE/Security へ流れ込んでくる interruptive なタスクが見えるようになり、全体のリードを取りやすくなったことと、ある種それに先回りしてチームの Focus を計画できるようになったなと感じました (reactive → proactive)。
取り組んだこととして前 Q に撒いた種に水をやりつづけるように手を入れました。また、組織変更に影響されないサービス管理ができるようにサービスとメンバーを直接紐付けるのではなくチームというレイヤでワンクッション置けるようにしました。
- Datadog の利用拡大
- manifest 管理の刷新
- デプロイ高速化
- Kubernetes manifest をどのように扱うべきか、抽象化するべきか
- manifest の共通化
- パートナー展開をスケーラブルにするための施策
- チームの概念を整備
- サービスとは別にチームという単位でインフラリソースをグルーピングできるように整備
- PagerDuty “team”、GitHub “team”、Google “group”…
- 検証環境の改善
2023/1~ 来年の抱負
怒涛の1年でした。荒野を耕すところからはじまり、大きなものから小さなものまでたくさんの種まきをし、ようやく小さな芽がではじめたのではないかなという1年でした。これが大きく芽吹くのは2023年以降だと思っています。より Stailer 事業が大きくなるにつれてやっておいてよかったと思えることに集中的に投資できました。来年が楽しみです。僕自身 Stailer というサービスに可能性を感じるし、大きくしていきたいと思って今の仕事をさせてもらっています。とても良いチームメンバーにも恵まれました。Lead や EM といったチャンスももらうことができました。あとはやっていくだけです。
明日は YamasakiYuji さんで「ワインへの愛を語ります」です。