ZOZOの駆け出しSREの半年を振り返る

# はじめに
社内異動を通じて、2023年度の4月にバックエンドエンジニアからSREにジョブチェンしました。
駆け出しSREの半年ちょっとを振り返ってみます！
同じような挑戦をしている方、検討している方の参考になれば幸いです。

なお、ジョブチェンするまでの話は昨日の [ZOZOのバックエンドエンジニアがSREにジョブチェンするまでの話]() を読んでいただけると幸いです。

# 担当した業務
時系列順に担当した主な業務をまとめてみました。
オンボーディングなどの細かい作業、セキュリティ的なタスクの記載は省略しています。

## 【4月頃】会員マイクロサービスの年齢認証機能リリース（サブ担当）
- 負荷試験
  - ZOZOがOSSとして公開している [Gatling Operator](https://github.com/st-tech/gatling-operator) を使ってGatlingの負荷シナリオを作成し、負荷試験を実施しました。
- 障害試験
  - stg環境にて特定のパターンで障害を故意に発生させて、想定通りのエラーやアラートの発砲がされるかを試験しました。
- k8sのCronjobの構築

## 【4~5月頃】バックオフィス用認証マイクロサービスへのIstio/Flaggerの導入案件（サブ担当）
- IstioとFlaggerの導入
- 関連監視項目の追加
  - Terraform + Datadogでistio-ingressgatewayなどに関する監視設定を追加しました。
- 障害試験の準備と実施
  - 上記で追加した監視（アラート）が期待通りに動作するかをテストしました。

## 【4~5月頃】新マイクロサービス（Session基盤）の初期構築案件（サブ担当）
- AWSリソースの作成
  - GHA用IAMユーザ
  - ECR
  - Firehose
  - Pod用SG
- Sentryの構築
  - プロジェクト作成

## 【6~7月頃】zozo-api-gatewayへのFlagger導入検証案件（リード）
- バックエンドチームとの調整
  - Flagger導入により、自分が開発した既存機能への影響があるのでその調整。
- Flagger導入の検証
  - 他のgatewayと絡んだ通信で想定通りの経路にならず、稼働の都合もあり、未だに検証未完了です。。。

## 【8月頃】とあるマイクロサービスのデータ不整合解消（サブ担当）
- k8sのJobの構築
- 手順書の作成
- stg環境での素振り実施

## 【8~9月頃】Kubernetesのコンテナランタイムdockershimの廃止に伴うContainerdへの移行（リード）
- 詳細は明日の記事にて公開予定です。

## 【8~9月頃】EKS Upgrade to 1.24（リード）
- 2クラスターのEKS Upgrade
- 上記案件のContainerd移行と並行して進めました
- サービス障害なく完了しました
- 詳細は明日の記事にて公開予定です。

## 【9月頃】Gatling Operatorの保守（リード）
- ZOZO製のOSSであるGatling OperatorのGatling Versionを最新の3.9.5にUpgradeしました。
  - https://github.com/st-tech/gatling-operator/pull/96
- 上記の対応に伴い、社内の負荷試験クラスターにデプロイされているGatling Operatorを最新にしました。

## 【10月頃】メンテナンスに伴うZOZOTOWNのサイト停止業務（リード）
- k8sのingressでメンテナンス情報を返すようにしました。
- PagerDutyのメンテナンスウインドウを設定しました。
- 作業自体は難しくないですが、prdでサイトの停止と再開を深夜に行うので、少し緊張しました。

## 【10~11月頃】会員マイクロサービスのAurora Upgrade（リード）
- EOLを迎える `8.0.mysql_aurora.3.02` を `8.0.mysql_aurora.3.04.0` にUpgradeしました。
- 事前に、検証環境にて本番環境のDBをマスク化したものを用意し、ダウンタイムの発生時間の計測をしました。
- 万が一に備えたスナップショットからのリストア検証も実施しました。

## 【10~11月頃】Session基盤の構築（サブ担当）
- AlertProviderと関連Secretの作成
- Istioによるretry/timeoutの追加
- Kustomizationのbaseを使った実装へのリファクタリング
- Datadog Dashboardの追加
- dev環境の構築

## 【11月頃】EKS Upgrade to 1.25（サブ担当）
- 1クラスターのEKS Upgrade

## 【通年】運用業務・問い合わせ対応
- アラート対応
- カスタマーサポートチームや他開発チームからの問い合わせや依頼の対応
- 定期手動業務
- スケーリング対応
- 運用業務の改善

# 振り返ってみて
## 1にも2にも、チームへの感謝
担当した業務を並べてみると、多くのことをそつなくこなしたように見えるかもしれません。しかしながら、特に上期に関しては、ほぼ全て簡単に進んだものはありませんでした。
手厚いサポートがあったからこそ、なんとか達成できたものばかりです。困っている時に何度も何度も助けていただきました。チーム全員が技術力が高く、みんな親切で、本当に感謝しています。

## 成長したこと
ハードスキルに関しては、Kubernetes / Istio / Flagger / Flux / AWSあたりの知見が向上しました。
Kubernetesは事前に学習していた内容（完全ガイド、CKADなど）がかなり活きました。加えて、実務ではさらに、k9sの使い方やEKS Upgradeを実践を通じて学べました。
Istio / Flagger / Fluxに関しては、公式ドキュメントを軽く読んだ程度の知識しかなかったため、最初は理解に時間を要しましたが、だんだんと理解度が向上しました。ただし、Fluxは自身による導入経験がないため、まだ理解が不十分な部分が多くあり、今後トライしていきたい部分です。

ソフトスキルに関しては、調整能力、スケジュール能力、コミュニケーション能力、提案能力、社内人脈などが向上しました。また、pf-sreに所属したからなのか、「共通的に困っている課題を解決したい」という気持ちをこれまでよりも持つようになった気がします。

つまり、トータルで、めちゃめちゃ成長しました。

## 新しい挑戦は辛い
やる前から辛いことは想像していましたし、きっとうまくいかないことが何度もあるだろうと覚悟していました。正直なところ、分からないことだらけで、キャッチアップはかなり苦労しました。
しかしながら、仕事に限らず、新しい挑戦というのはうまくいかないことがほとんどだと思います。
例えば、私は最近キックボクシングを始めました。運動能力は人よりも自信がありますが、経験者に比べてミット打ちやマススパーリングで圧倒的なレベルの差を感じています。なんなら、うまい中学生や中年の方にも余裕で負けます。それでも、確実に少しずつマシになっている自分がいます。そこに喜びややりがいを感じています。
そうやって苦しんでもがいているということは、たくさん成長できる場にいるということです。その瞬間は精神的に辛いですが、めげずに、必要な勉強や練習を継続し、真面目に取り組み続ければ、いずれは点が線として繋がり、解放される時が来ると自分信じています。

新しい挑戦をする際に、同じように悩んでいる方も多くいらっしゃると思いますが、何かの励みになれば幸いです。正直なところ、自分はこの半年、何度も挫折しそうになりました。しかし、それでもなんとか今日まで頑張っています。それができているのは、成長することが楽しいのと、恵まれたチーム環境だからだと思います。

SREにジョブチェンして、挑戦してよかったと思っています。

# 明日の記事
明日は、この半年で自分が最も頑張った担当案件のEKS UpgradeとContainerd移行対応に関する記事です。よろしければ読んでください。