設計とケースの面接

まず要件を確かめます。1日に何通送るか、遅れてよい時間、重複して届くのはどこまで許されるか、配信の失敗をどう扱うか、です。設計は、各サービスがキューに通知の依頼を入れ、送信の担当（ワーカー）が取り出して外部のメール・プッシュのサービスに送る形にします。外部サービスの失敗に備えてリトライと上限を決め、同じ通知を二度送らないよう依頼ごとの ID で重複を防ぎます。送った・失敗したの記録も残します。

進め方は、最初の1か月でメールだけの最小の形（MVP）を作り、社内向けの通知から段階的に切り替えます。2か月目にプッシュ通知と、送信数・失敗率・遅れの監視とアラートを入れ、3か月目に負荷試験と主要な通知の移行をします。外部サービスへの依存が一番のリスクなので、早い段階で送信の上限や料金を確かめます。

体制は、4人のうち1人にこのシステムの設計の責任を持ってもらい、オンコールを誰が持つかもリリース前に決めます。足りない経験があれば、他チームの SRE に設計レビューを頼みます。

最初の30日は、聞くことに使います。メンバー全員と 1on1 をして、仕事の負担、オンコール、評価、キャリア、チームの雰囲気について聞きます。辞めた人の退職面談の記録があれば読み、上司や人事からも話を聞きます。この段階では大きく変えません。

60日までに、聞いた内容から原因の仮説を立て、すぐできることを1〜2個変えます。例えば、オンコールの負担が原因ならアラートを減らす、期待が不明確なら役割を書いて合意する、などです。90日までに、それを仕組みにし、1on1 の定着や評価の基準の共有などを進めます。効果は、メンバーのアンケート、オンコールの数字、離職の兆しの変化で確かめます。

まず、目的と期限、予算と人数、既存のシステムとの関係を確かめます。何を検証するためのチームか、いつまでに何を出せばよいかで、必要な人とやり方が変わるからです。

最初は少人数、例えば TL とエンジニア2〜3人で始め、最初に出す範囲を小さく決めます。技術の選択は、チームが扱えて運用の手間が少ないものを選び、やり直しにくい決定は ADR に残します。人は一度に増やさず、オンボーディングの準備をしてから順に増やします。開発の進め方、レビュー、リリース、オンコールの約束事は最初に決めておき、ふりかえりで直していきます。

まず、利用者ごとに1分何回までにするか、上限を超えたら HTTP 429 を返すか、多少の誤差は許すかを確かめます。構成は、入口のゲートウェイで回数を数え、全サーバーで共有するカウンターを Redis などに置きます。サーバーごとに数えると上限がずれるからです。方式は、簡単な固定窓か、なめらかなトークンバケットかを、精度の要件で選びます。

進め方は段階的にします。最初の1週間は計測だけして制限はかけず、誰がどれだけ使っているかを見ます。そのうえで一部の利用者に適用し、問題がなければ全体へ広げます。カウンターが落ちたときは制限をかけずに通してアラートを鳴らす方針にし、利用者への事前の告知や、上限を上げたい顧客の窓口を営業・サポートと決めておきます。