イベント概要
2023年12月5日に「Next Year Con for SRE〜来年の登壇を応援する勉強会〜」と題してSREに関するトピックでタイミー、ココナラ、ビットキー、マジックモーメントの4社合同で勉強会を開催しました。 その中でタイミーバックエンドエンジニアの岡野さん（@Juju_62q）の講演をイベントレポートにまとめてお届けします。
チーム分割においていかれたアラートをチームで責任を持てる形に再設計した
自己紹介＆想定聴衆
2020年にタイミーに入社し、現在では3年半ほどエンジニアをしている岡野と申します。 主にストリームアラインドチームの機能開発を担当しており、その一方でサイトリライアビリティエンジニアリングも行っています。
想定聴衆
- 「よくあるアラート」に困っているエンジニア
- 組織分割を考えているEMやCTO
- EnablingをやっていきたいSREs
今日お話しないこと
- どのようなアラートを設定すべきなのか
- アラートから繋がるオンコール対応周辺の話
アラートとFBサイクルとチーム
私が最も優れていると考えるアラート（右の図）は、問題が発生したら、エンジニアが問題を解決すると宣言し、リカバーするアラートです。理想的には、問題が自動的に解決することが望ましいですが、今回の話の範囲では、アラートの責務を超えていると捉え、理想的なアラートの形をこのように考えています。
次によくあるアラート（左の図）は、CPU使用率がN%を超えると、エンジニアが介入せずとも時間と共に回復したり、500エラーがy回を超えると何もせずとも回復するようなアラートです。このようなアラートは、時間が経過すると自然に解決し、次第に無視されがちです。
本来アラートはアクションを要求するための通知であるべきであり、アクションなしにアラートが鳴ることは無意味です。実際にタイミーにも、このような無駄なアラートが長期間存在していました。
現状、完全な解決には至っていませんが、タイミーがアラートを少しずつ改善した話を共有していきます。
タイミーではどのようにして「よくあるアラート」ができたのか
前提条件
1. 開発と運用を同じチームでやっていること
タイミーでは、CTOが開発と運用を一つのチームで行うことを重視しています。CTOが好んでいるチームトポロジーの書籍では、「運用は開発への最大のフィードバック源である」と述べられており、私たちの組織でもこれを大切にしています。2. エンジニアはアラートがなっていることを好ましく思っていないこと
エンジニアはアラートが鳴る状況を好ましく思っていません。行動を起こすかどうかは別として、アラートが鳴っていること自体は好まれていませんでした。3. エンジニアは機能開発以外にある程度の時間が使えること
タイミーのエンジニアは、10%から20%の時間を技術改善に充てることができます。実際には、少なくとも10%の時間をこれに割り当てることが求められています。
2〜3年前、我々のチームは以下のような横割りの構造でした。
- バックエンドチーム
- Webフロントエンドチーム
- モバイルチーム
これらのチーム間では、バックエンドチームがアラートの設定を行い、障害経験を基にアラートシステムが構築されました。この時期には、ユーザー数も少なく、アラート対応の難易度も低めでした。赤く表示されるアラートに対しては、チーム文化として積極的に対応していました。
しかし、この横割り組織では、一つのチームだけで機能を完全に提供することが難しく、これが課題となりました。そのため、職能を横断する縦割りの組織構造への移行を進めました。この新しい形では、モバイルやWebフロントエンドなど、異なる専門分野のメンバーが同一チームに所属するようになりました。
ただし、この組織変更の際に、アラートシステムの見直しは行われず、バックエンドエンジニアが引き続きアラートの責任を担うことになりました。
アラートが鳴った際の反応はどうだったかというと、以下のような反応が一般的でした。
Aチーム「アラート鳴ってるけど、よくわからんな」 Bチーム「アラート鳴ってるけど、うちのチームとは関係無さそう」
チーム間で分断されていると、特定の機能についてどのチームが対応すべきかの判断が難しくなります。特に、人員が増加するにつれて、過去の経緯も失われ、このような問題は増えていきます。
いつも鳴ってるし今日も大丈夫だろう
『いつも鳴ってるし、今日も大丈夫だろう』という感覚が常態化すると、アラートが頻繁に鳴るようになります。アラートが放置され、対応が行われないため、アラートの数は増加の一途をたどります。
改善したいけどハードルが高そう
仮に意欲的なエンジニアが現れても、「何とかしたいが、どう変えればいいかわからない」という状況に陥りがちです。Aチームの同僚は協力的ですが、Bチームは相対的に距離があるため、意見を述べるのが難しいと感じることがあります。同じ会社に属していても、日常的に顔を合わせていない人に対し、合意を得る必要があるかもしれないという懸念が生じます。
なぜこのようなことが起こるのか
なぜこのような状況が発生したのか、その原因を考察します。
アラートの作成は元々、バックエンドチームが責任を持って設定していました。当初、アラートに対するフィードバックはバックエンドチームに集中しており、このチームだけでアラートの削除や修正が行われていました。しかし縦割り組織への移行後、アラートに関するフィードバックは複数のチームに分散し、単一のチームだけでの削除や修正が難しくなりました。アラートに対する対応が不明確になり、長期間勤務している経験豊富なメンバーに相談することや、アラートに関する変更の承認を得るまでのプロセスが必要になることもありました。このように、フィードバックが機能しなくなった結果、アラートの数は増加し、特に新入社員にとっては理解しづらいものとなりました。この状況が、「よくあるアラート」の誕生に繋がったのです。
「よくあるアラート」を改善するためにしたこと
結論を述べると Aチーム・Bチームそれぞれにフィードバックと意思決定権を与えました。
具体的な行動
- 各チームで対応の必要があると思われるアラートを選んでもらう
- アラートに対してチームメンションをつける
- アラートはメンションのある単一チームで変更していいと周知する
- アラート対応に関する振り返りを実施
各チームで対応の必要があると思われるアラートを選んでもらう
すべての問題を即座に解決するのは難しいため、Slackに「問題なし」または「問題あり、オンコール対応が必要」というコメントを残すことを最低限行うことにしました。このとき、多くのアラートのうち、選ばれなかったアラートは一旦すべて削除しました。
アラートに対してチームメンションをつける
次に、アラートに対してチームメンションをつけることにしました。以前はアラートにメンションがなく、全てのチャンネル通知をオンにする運用でしたが、これではどのチームが対応すべきか不明確でした。そこで、アラートにメンションを付与し、「このメンションのチームがオーナーです」と伝えるようにしました。
メンションのある単一チームで変更していいと周知する
次に、バックエンドのアラートに関しては、バックエンドチーム全体の許可がなければ変更できないと考えられていました。しかし、メンションのある単一チームでの意思決定による変更を推進しました。これにより、各チームは素早く意見を反映できるようになりました。
アラート対応に関する振り返りを実施
最後に、アラート対応に関する振り返りを実施しました。最初の改善はできるだけサポートするため、メンション付きのアラート対応について1ヶ月後に第1回の振り返りを各チームで行いました。これは、必要に応じて2回、3回と続けました。この流れで、チーム内での改善が少なくとも1回行われるところまで改善できました。
今、どのような変化があったのか
現在、アラートシステムにおいて以下のような変化が生じています。
アラートに反応する人やチームの増加
アラートに反応する人数やチームが明確に増えました。
アラートの定期的な変更や見直し
アラートに対応しないと自分たちが困難な状況に陥るため、変更や見直しを定期的に行うようになりました。
Runbookの整備
チームごとにRunbookが整備され、アラート対応のプロセスが民主化されています。この分野にはまだ改善の余地があると感じていますが、良い変化が見られていると思います。
これらの変化により、「よくあるアラート」から徐々に脱出していると感じています。ただし、不要なアラートが多いことや、復旧の自動化がまだ十分ではないことは、今後の大きな改善ポイントです。
まとめ
- アラートは組織構造とFBを受ける人が不一致の場合に機能しなくなっていく
- アラートは単一チームで変更の意思決定ができないと硬直化する
- 組織が変わった際に、アラートの組織に合わせて変更するのが大切
最後に、アラートシステムのまとめです。アラートは、チームの構造とフィードバックが不一致になると、効果を失ってしまう可能性があります。フィードバックを受ける人々が明確でない場合、アラートの機能性が低下する傾向があります。またアラートに関しては、「単純接触効果」のとおり、日常的に顔を合わせる人々に対して意見を伝えやすいことが多いです。そのため、単一のチームで意思決定ができない場合、アラートシステムは硬直化しやすいと思われます。
結論、組織が変化した際には、アラートシステムの構造も組織の形態に合わせて変更することが重要です。
