サービスの安定性より優先されるベロシティに意味はない
開発者が運用をするだけではなく、緊急事態発生時に対応できるように待機するオンコールまで担うとなるとなかなかハードルが高い。なお、この呼び出しに使われるのがPagerDutyだ。もし開発者がオンコールのローテーションに入るとなると、いくつかの課題・疑問が生じる。
開発者がオンコールに入ればベロシティが悪化するのでは
この答えは「確かに、悪化する」。タスクが増えるのだから、当然といえば当然だ。草間氏は「ベロシティはあくまで目安であり、目標にしてはいけません。ベロシティを上げるために運用には携わらないとなると本末転倒です。サービスの安定性よりも優先されてしまうようなベロシティには意味はありません」と言う。
問題は特定の人に負荷が集中してしまうことだ。草間氏によると、組織規模にもよるが月に3〜4日程度が理想とされる。適切にスケジュールを組み、担当をばらしていくことが大事だ。
なおPagerDutyでは過剰に通知しなくてすむように、各種サービスから必要なアラートだけ絞り込み、本当に大事なインシデントの時だけ担当者を呼び出す。通知方法は電話やSMS、プッシュ通知、Slackなど選べる。また一次対応者が応答しない場合、二次対応者に通知するといったようにエスカレーションを設定することができる。こうした工夫により関係者に一斉通知することなく、負荷を最小限にすることができる。
オンコールはSREだけでやるべきでは？
この質問に対して草間氏は「ノー。SREは信頼性を高めるエンジニアリングの専門家であり、オンコール専任ではない」と答える。もちろんオンコールのローテーションには入ってもらう。企業によってはプロダクトに関するインシデントはプロダクトチーム、プロダクトをまたぐインシデントはSREチームというように、分担しているところもある。
草間氏は「大事なことは『開発者に運用もやらせる』のではなく、『ライフサイクル全体に責任を持たせる』という考え方です」と強調する。改善を続けることで、呼び出しの頻度を減らすことができる。
改善については開発者のコードだけではなく、SREが適切なSLI/SLOの設定や自動化なども行いながら協力して進めていくのが理想だろう。
