はじめに
私はSRE部のカート決済SREブロック（私含め現在6名）というチームのマネージャーを務めています。
カート決済SREブロックはZOZOTOWNのカート決済に関することを中心に環境（クラウド・オンプレミス）問わず信頼性を向上し続けるMissionを掲げて活動しています。
立ち上げから3年目となるチームなのですがこの3年でSREチームとしてのカルチャーも成熟されてきたように感じたため、この場で自チームで導入しているODDRを振り返りながらチームの変遷を振り返りたいと思います。
ODDRとは
Organization Development Decision Recordsの略です。
Architecture Decision Record（ADR）がシステムの設計における意思決定を文書化して残すことだとすればODDRは組織施策の意思決定を文書化して残すものです。
社内ではADRを残す文化が浸透しておりなぜそのアーキテクチャになっているのかという背景をキャッチアップしやすい状態が整っていました。
ADRとシステムの変遷については弊社CTOも先日登壇しておりドキュメントも公開されておりますので是非ご覧ください、でもこの記事は、個人的なオマージュというかインスパイア系なので会社としてどうこうという話では無いのであしからず。
私たちカート決済SREブロックが記録しているODDRも基本的なフォーマットはADRとほぼ同じで以下項目を社内ツールに記載しています。
- Title（タイトル）
- Status（ステータス）
- Context（文脈・背景）
- Decision（決定事項）
- Consequences（結果）
なぜODDRを残すことにしたのか
チームとしての活動はODDRを残す前から諸々試行錯誤していたのですが、人員体制などに変更があるとなぜその慣習があるのかが分からないといったシーンがあったり、決め事としてやっていることの背景の共通認識が揃わないままチームとしての取り組みがいる・いらないの議論に発展してしまう可能性がありました。
そういったコミュニケーションのズレを最小限にしたいという狙いからODDRを活用してみることにしました。チームはみんないいやつなのでそういうコミュニケーションのズレが問題になることはほぼないんですが、長期的に考えた際のリスクヘッジとして始めてみた感じです。
ODDRから振り返るチームの変遷
立ち上げ期
2022年4月に結成されたチームでしたが立ち上げ当初は私含め3名というメンバーでのスタートでした。
我々が担当するドメインのカート決済というシステムは当時それなりに問題を抱えており正直立ち上げ1年目はまったく手応えを感じられないまま悔しい気持ちで日々が過ぎていったように思います。当時は来たボールを打ち返すことに必死で本来SREとして取り組むべき業務が疎かになっていたなと今でも反省します。
そんなタイミングでしたが1つの組織としての意思決定をしました。
ODDR: 毎日必ずPRD/STG環境のアラートを確認し即座に対応方針を決める
なぜこのODDRを残したか
毎朝チームで30m程集合して朝会を行っていました。当日のタスク共有であったり相談連絡を行う時間として使っていました。
この時間に必ず参加者全員で当日その時間までの本番（PRD）、事前（STG）環境のアラートを確認し以下を確認することにしました。
- アラートがなぜ起こったのか
- アラートが発生することで起こりうるサービスへの影響
- アラートの発生条件は適切か？
基本的にはその場で対応方針を決め担当者をアサインし、そこからは担当者のタスクとなります。
上述した通り当時はかなり様々な業務と、それに合わせて日常的に発生するシステムトラブルに忙殺されていました。
しかし実態としては古に設定されたアラートの閾値がそのままになっているものが暴発していたり、事前環境など本番環境以外でのアラートがそれまで形骸化してしまっている状態だったのですが、そこを意識していれば防げたトラブルなどが続いたためです。
よってアラートへの意識を向上し継続的に閾値等を見直していくためにこのODDRを残しました。
結果
毎朝全員で発生しているアラートを確認し対応方針を決めるという取り組みですが、2024年今現在も毎日継続しています。
得られた効果としては、まず放置気味だったアラートの見直し等が頻繁に行われているため2022年下期から2023年上期にかけてアラート（オンコールを伴う）発生数が54％削減されました。
またそのアラートが発生することでサービスに起こる影響などを確認できる場にもなるため、メンバーの増員等があった際のオンボーディング代わりとしてもいい効果がありました。結果的に早いサイクルで輪番当番に入れるなどのメリットもあったと思います。
人員増員期
2022年末から2023年夏にかけて素晴らしい縁に恵まれ3名立て続けに採用することができました。
この頃からリプレイスや日々のチューニング効果を実感できるようになりシステムの安定稼働率が非常に上がってきたフェーズでした。人員増加もあり運用改善タスクにがっつり踏み込めるようになるなどチームとしてできることが増えていくフェーズに突入していきました。
一方でこの頃は一気にチーム人数が倍になっているためどのように新メンバーをフォローしていくかということで試行錯誤していたODDRがいくつか残っています。
ODDR: 優先的にPRs Review Reminderに上がったPRをレビューする
なぜこのODDRを残したか
現状我々の環境は大半の管理リソースがGitHub上でIaC管理されている状態です。巨大なモノレポ構成のため自チーム以外のPull Requestをまで入れると毎日数十レベルのPull Requestが作成されています。また私たちの場合はマージを行う条件としてチーム内から最低でも１人のApproveが必要という運用をおこなっています。
新しく入社したメンバーによっては大量のPull Requestの中から優先的に見るべきものが何なのかわからなくなると言う悩みがある声も上がっていました。
また、タイミング的に開発生産性について考えていた時代でもあるため、Approveがついたまま埋もれて放置されているPull Requestの量などが気になってきているフェーズでした。
そこで、チーム内でPRs Review ReminderというWorkflowを作成し営業日は毎朝業務開始時間頃にSlackにチームメンバーが関連しており承認済みのPull Requestおよび承認前のPull Requestが通知される状態にしました。
今回はWorkflowの仕組みについては割愛しますが以下のような通知がチーム宛に届きます。
またまたここからも朝会になっていくのですが、朝のタイミングで未レビューのものは誰がレビューを行うかを決め、すでにApprove済みのPRに関してはマージを妨げる要因があるのかどうかをその場で話し合う運用になっていきました。
結果
大量のPull Requestの中から自チームに関連するものを速やかに抽出し、優先順位を付けて対応していくことができるようになりました。
また、ものによってはレビュワーのスキルが追いつかずどうレビューすればいいのか分からないという場合もあります。
そういった場合に朝のタイミングの会話があることでスキルが追いついていないケースなどに気が付きやすく、そういったシーンでは別途時間を設けレビュー会などを実施していくチームのカルチャーが出来ていきました。
ODDR: 半期に1度オペレーションの訓練会を実施する
なぜこのODDRを残したか
システムの安定稼働率が上がりアラート件数も相当数少なくなっていったことは素晴らしく喜ばしいことなのですが、その一方でオペレーションの経験を積む機会が減っていきました。
メンバーによっては不安の声等も上がっており、確かに有事の際に対応ができない、なんてことがあった日には目も当てられません。
そこで、全員統一したオペレーションが出来るように半期に一度全員でこれまで発生した有事の際のオペレーションの確認（実際に手を動かせるものは動かす）という会を実施するようにしました。
いくつか具体的に手を動かしているオペレーションを記述すると
- EKSのWorkerNode不調時のNode Drain対応
- SQL Serverのフェールオーバー
など（その他色々）を全員必ず1回はオペレーションする時間を設けています。
その会が終わる頃にまた次の半期でやる予定とその会のメイン進行役をざっくり決めて登録しておき、時期がきたら進行役が進めていくという流れでなんとかうまく回っています。
結果
これは私含めてなのですが半年経つと意外と手順書を見ないと不安になるものがあるんだなと感じています。
実際に活用して対処するシーンなどもあり有事の際のオペレーションは全員できるようにしておくことは属人化を防ぐ意味でも非常に重要かと思います。作業の大半が自動化されていて自分はキックするだけだとしても影響が大きい作業で実際には自分はやったことがない、は大きな心理的ハードルにつながるためです。
個々がオーナーシップを持って進めていくフェーズに
2024年はチーム全員がカート決済という枠組みを超えて様々な取り組みが出来た一年でした。
コスト最適化に向けてチーム一丸となり取り組むところからはじまり、リリースフローの整備、秘伝のタレ化してきたリリースシステムの刷新、そして組織内からテックリードの誕生など思い出深い一年となりました。
これまでは基本的に何か自チームで作業が発生する場合は私が窓口となり様々な調整を行ってきていたのですが、これをそろそろメンバー等に委譲していかなくてはいけないフェーズだと感じるようになっていきました。そこで今年残したODDRの1つが以下です。
ODDR: リリース準備シートを使いリリース管理を行う
なぜこのODDRを残したか
主に以下2つが大きな理由です。
- 私たちはZOZOTOWNのカート決済ドメインに関するリプレイスおよびマイクロサービス化も行っています。
新規マイクロサービス立ち上げ時には社内でリリースのための正規のフローやSRE内でのチェックリスト等も用意されており一定の水準を満たした上で新マイクロサービスが世に放たれていきます。
一方で一度世に出たサービスも継続して事業案件などの関係で改修が入ったりするのですがその修正内容のリリースにおいては初回程シビアなフローが存在せず、個人の裁量に委ねられている部分があります。 - 上述したように2024年はカート決済という枠組みを超えて様々な取り組みをしてきました。
挑戦できるステージが増えた一方で調整業もとても増えてきており、私自身の問題かもしれないのですが至る所に顔を突っ込み過ぎて立ち上げから今までのように全部を自分が窓口としてやっていくことが近い将来ボトルネックになる可能性があると考えたためです。
そこでチームでリリース管理シートを作成し、他チーム由来で発生する仕事の請負方を一本化することにしました。
リリース管理シートには以下のような情報を記載してもらい、最低限ここは担保したいという項目を全員が意識できる状態にすることにしました。
- 依頼者が記載する内容
- 改修内容
- スケジュール感
- 関連リソースの情報
- DBに対する改修の有無
- 依存APIの有無
- リクエスト数の見込み、既存エンドポイントの場合はその増加数
- リリース方法と切り戻しの判断基準
- SREが記載する内容
- 担当者
- 上述した情報を経て、負荷試験・障害試験の実施有無判断
- 実施の場合のエビデンス
上述した内容の項目の中で依頼者への負担が大きいようにも見えますが、実態としては現時点では不明な場合はSREも一緒にそのあたりは考えましょうというニュアンスで使っており、あくまでも担保したい部分を死守するための役割としてこのリリース管理シートを使っています。
結果
開発・SRE合意の上で一定の品質を保った上でリリースすることが可能になりました。これは結果的にお互いの心理的安全性にもつながります。
また依頼の仕方やもらえる情報の粒度などもある程度水平化できるようになったためリーダーが窓口に立ち様々なヒアリングを行う必要もなく、メンバーや依頼者がが不足している項目はどう埋めるかを考えてくれるようなフォーマットになっているためそういう意味では調整役の属人化排除の実現ができたと思っています。この取り組みはまだ一年も経っていないため今後ブラッシュアップしていく可能性はありますが、その時はまたODDRにそのブラッシュアップの歴史を刻みたいと思います。
ODDRをやってみて
ODDRを振り返りながら我々カート決済SREブロックの変遷を振り返ってみました。似たようなことをしている組織も多いでしょうし何か斬新なことは書けていないかもしれないですが、組織の決定を文書化して残してきたことでカルチャーとして染みつけることができたと思う部分もあり、個人的にはODDRは非常に有用だと考えています。
もし今後このカルチャーに意味があるのか？となったときに当時の背景を記録しておけばそれを基準にできるため議論が発散しすぎることを避ける役割になるのではとも考えています。
最後に
ZOZOアドベントカレンダーのシリーズ５はカート決済SREブロックの6名で1シリーズ分完走させてもらいました。
どれも読み応えがあり面白い内容となっていますため、是非他の記事も見てみてください。
本当に最後に（自己満足）
ここからはただの自己満足かもしれないですが、日々の業務がある中でアウトプット活動をしていくことは大変だけど個々の価値を上げていくことに繋がると思っています。
こういったアウトプット活動も楽しみながら取り組んでくれるカート決済SREのメンバーたちには毎回驚かされますし、本当に自慢のチームです。そんなカート決済SREのメンバーと縁あって今一緒に働けていることを嬉しく思います。この場を借りて、みんないつも本当にありがとう。皆に感化されて自分もすごく頑張りたい気持ちになります。皆とこのODDRに記載したようなカルチャーを作ってきたことも1つの誇りです。
これからもチーム一丸となってワクワクする取り組みを行なっていこーぜ！
参考文献