みてね』(⁠以下みてね)のSREグループに所属している本間です。みてねは現在、1,500万人を超えるユーザに175の国と地域でサービスを提供しています(2022年8月現在)。そこで、より高い信頼性と可用性を担保するためにみてねのSREグループではオンコールエンジニア制度を設けています。今回はこの「みてねのSREグループにおけるオンコールエンジニア制度の取り組み」についてご紹介させて頂きます。オンコールの定義まず、どのような条件でアラートを設定しオンコールを実施するかの定義について簡単に触れておきます。現在はさまざまなソースから多種多様な情報を収集することができます。EKS)を採用しています。Kubernetesだけでも非常に多くのメトリクスが収集できますが、それだけではなくアプリケーションごとに様々なメトリクスを取得するAPMであったり、ユーザのクライアントからの情報であったり、ブラウザからも情報を多く取得できます。アプリケーション以外でもデータベースや各種ミドルウェアなどからもメトリクスを収集できます。これらすべてを監視対象とし、すべてに閾値を設定し、すべてをオンコールの対象として定義していては、とてもではないですが管理できないですし、オンコールエンジニアの負担がとても大きくなってしまいます。そこでみてねではオンコールを定義する際に4つのゴールデンシグナルを基準にしています。Controllerなど)が起動していることも併せてアラートの対象にして設定しています。オオカミ少年にならないために上記オンコール条件の定義に基づいて設定したとしても、時が経つにつれさまざまな要因からアラートの条件が風化しオンコールが意味をなさなくなってしてしまう場合があります。例1)エラー数を条件にアラートを設定したが、サービス拡大に伴うユーザ増加で頻繁に閾値を越えるようになった例2)memory使用率を条件にアラートを設定したが、自動でスケーリングするように設定したためオンコール発生後も特にやることはないこのようにあまりにもオンコールが多発したり、発生してもとくに対処方法がないケースが多くなるとオンコールそのものが形骸化してしまい、本当に障害が発生しているか判断しづらくなったり、担当者が疲弊してしまったりと多くの悪影響がでてしまいます。そのためオンコールに設定しているアラートの条件を定期的に見直す必要があります。先ほどの例1の場合であればエラー数ではなくエラー率に変更、例2の場合はそもそもアラート条件を削除してしまって良いかもしれません。みてねではオンコール発生後の翌営業日のミーティングの場でアラートの内容をチームで確認しており、その際に「削除するべきか」「⁠閾値を見直すべきか」「⁠アラートの条件を見直すべきか」と言った会話をしています。そこで必要があればチケットを作成し実際に対応することで、本当に対応が必要なオンコールだけにするよう心がけています。障害発生時にはポストモーテムを実施しており、ポストモーテム内の振り返りでアラート条件の見直しを実施することも多くあります。みてねでの実際の運用オンコールの定義を整理したので、次に実際の運用について紹介させていただきます。オンコールエンジニアの条件まず、入社してすぐのエンジニアがオンコールエンジニアになることはありません。GoogleのSRE本にもあるように、オンコールエンジニアには一定の能力が求められます。みてねでは基準を以下のように定義しています。繰り返しになりますが、この定義を満たすまではオンコールエンジニアになることはありません。障害対応時に適切なコミュニケーションができることできるだけ早く反応できる必要な連絡先を判断し円滑にコミュニケーションを行うことができる対応ログを適切な箇所に残しながら作業ができるAWSや各種モニタリングツールの扱いに慣れていること原因特定のためにモニタリングツールを利用しそのメトリクスを理解しているログの検索・保全ができる適切な負荷対策ができる自分のスキルに過度な自信を持っていないこと個人で判断せずエスカレーションポリシーを遵守できるトレーニングこれらの条件を満たせるようになっても実際のオンコールが発生した際は、ベテランエンジニアの経験や勘のほうが有用なケースがあります。Misfortune」を実施しています。こちらは新しく担当になるエンジニアが、ベテランエンジニアが出題する問題に回答しフィードバックを受けるという流れでオンコール発生時の対応スキルを向上させることができる施策です。簡単な流れは以下のようになります。以上の流れを何度か繰り返すことでより自信を持ってオンコール担当につけるようになります。Engineeringのようにコストをかけなくとも実際の障害を想定したトレーニングができる点がメリットだと感じました。出題者や回答者は複数人いても良く、むしろその方が色々な角度からの回答を聞けたり、そのままディスカッションに発展することもあるのでおすすめです。注意点としては回答者が試されるような形になるので、少しだけ不安になります。できるだけ明るい雰囲気で実施できるといいかもしれません。運用方法ここからは実際のオンコール対応の運用について紹介します。前提として、勤務時間内に発生したオンコールは担当関係なく、チーム全員で対応します。オンコールエンジニアは、発生したオンコールに可能な限り早く対応するため、以下のルールを遵守することとしています。即時対応可能な状況でいること電波がつながらない場所はできる限り避けること深夜に睡眠中であっても起きて対応すること中々負担が大きいですが、チームから1名をオンコールエンジニアとし1週間ごとにローテーションしていることと、オンコールエンジニアには振替休日と手当金が支給されることもあり、実際に感じる負担はそこまで大きくありません。以下の場合はチーム全員が2次担当者となります。1次担当者が一定時間内に対応できなかった場合1次担当者がエスカレーションした場合もちろん1次担当者がすべてのケースで即座に問題を解決できるに越したことはないですが、現実的にはそうはいきません。適切にエスカレーションしてチームの判断を仰いで対応した方が、担当者の精神的な負担が小さくなると言ったメリットがありますし、逆に相談できなかったがゆえにさらに大きな障害に発展してしまうなどと言ったリスクもあります。可能な限りエスカレーションは実施したいのですが、実際の状況になると深夜や休日にチームメンバーを呼び出すことに抵抗を覚えてしまうことがあります。そのために「対応できる気がする。1%くらいダメな気がする。」も必ずエスカレーションする。チーム内のドキュメントに明記しています。加えて、長期連休に入る前などにはチーム内で「少しでも不安だったらエスカレーションしましょう!」と声かけをおこなっています。些細な対策ですが、こう言った小さな積み重ねでチーム内の心理的安全性を構築していくことが、最適なオンコールを運用する上で大切です。仕組み次にオンコールが発生してから担当者に通知されるまでの流れを紹介させて頂きます。みてねではオンコールに関連して以下の技術スタックを採用しています。オンコールが発生してから担当者に通知されるまでの流れ先ほども紹介いたしましたが、みてねではEKSを採用しており、各種メトリクスの収集にはPrometheusを利用しています。Browserなどを利用しアラート条件を設定しています。Alertsの設定はWorkflowsを用いて定義しています。オンコールに関連するほぼすべてのリソースがコード化されているので、閾値の変更やアラート条件の変更などの際にコードレビューを通してチームの合意を取ってから変更を実施できる点に大きなメリットがあると感じています。最後に少しニッチな内容になってしまいますが、マルチリージョン化でのオンコールの設定について触れておきます。リージョンを増やして運用するシステムが増えると、その分だけオンコールの設定を増やさなければなりません。設定を増やすだけではなくどこのリージョンで発生した問題なのかも明確に通知しなければならないため、かなり複雑で煩雑になりそうですが、上記の構成ですと必要なalert条件に少し追加するだけで簡潔にオンコールの設定を追加することが可能でした。各RegionごとにそれぞれにAPMを起動しているため、entitiesの配列に新しいRegionのAPMのidを追加するだけで設定が追加されます。}}NRQLを利用したアラートの場合はクエリの最後にFACET句を用いてグループ化するだけで、アラートはグループ化の結果それぞれで管理されます。Alertsを利用することでマルチリージョンでもコピペなどの必要なく非常に簡潔にオンコールの設定を追加することができました。最後にみてねのSREグループ内でのオンコールエンジニア制度の取り組みについてご紹介させていただきました。一言でオンコールといっても対応するべき箇所や考えるべき箇所は多くあります。この記事が少しでも悩んでいる方やこれから始めようと考えている方の参考になれば幸いです。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。