「オンコール対応するエンジニアの睡眠時間を確保せよ」 GMOペパボSREチームの6つの取り組み：「Cloud Operator Days Tokyo 2022」セミナーレポート＃1

Cloud Operator Days Tokyo 2022のセッション「信頼性を落とさず効果的にオンコールを減らす取り組みを目指して エンジニアの睡眠時間を守ろう」にてGMOペパボの渡部龍一氏は、信頼性を落とさずに効果的にオンコールを減らした取り組みについて紹介した。

[谷川耕一，＠IT]

　サービスの信頼性を守るため、オンコール対応は重要な仕事だ。だが、夜中に何度も呼び出されるような状況ではエンジニアの肉体的、精神的な疲労は計り知れない。Cloud Operator Days Tokyo 2022のセッション「信頼性を落とさず効果的にオンコールを減らす取り組みを目指して エンジニアの睡眠時間を守ろう」では、こうしたオンコール対応におけるエンジニアへの負担を軽減させる取り組みを紹介した。

「常に何らかのアラート情報が流れている」

　GMOペパボの渡部龍一氏（技術部プラットフォームグループ）の役割は、GMOペパボの各種サービスの可用性を確保しビジネスの成長に合わせて適切な環境を提供することだ。そのためのさまざまな業務をこなす中で、オンコール対応は悩みの種になっていた。

GMOペパボの渡部龍一氏

　「私のチームで対応するサービスだけでも100を超えており、平均すると2、3日に1回のペースで何らかのアラートが発生していた。日に数回の呼び出しが発生することも珍しくなく、担当者の睡眠時間が削られていた。平日の10時から19時は通常の業務と並行してオンコール対応をしているため、そちらへの影響も懸念される状況だった」

　もちろんオンコールは複数人で担当しており、交代制も採用している。だが、それでも担当者の負担が積み重なっていたという。この背景にはGMOペパボならではの理由もある。GMOペパボは多くのサービスを運用しており、規模も大きいため、その全てをSRE（Site Reliability Engineering）チームが把握することは難しい。アラートを管理する仕組みはあったが、サービスごとの設定にしていたため「常に何らかのアラート情報が流れている状態で重要なものを見逃す危険性もあった」と渡部氏は説明する。

オンコール対応の課題

　また、オンコールで対応ができないことがある点も課題だった。1つのサービスであっても開発には複数チームが携わっており、どのチームがどのようなリリースや変更作業をしているのかを把握することは容易ではない。しかもそういったサービスが無数にある。SREチームで対応できない場合は、担当チームを調べてエスカレーションするが、そのやりとりに時間が取られてしまい、結果としてMTTR（平均修復時間）が伸びてしまう恐れもあった。

オンコールを見直す「6つのステップ」

　「オンコール対応が頻発して運用担当の負担が大きい」「オンコールでは対応できないアラートをどうするか」。これら2つの課題を解決するために、渡部氏は「オンコール対応の見直し」を行った。同氏が実施した取り組みは以下の6つだ。