OnCallについて

この記事を通じて全てのシステムには24時間365日どこかの誰かがOnCallの担当をして、インシデントを減らすために苦悩していることを知ってもらえたら幸いです。

はじめに

2025年の4月からOnCallを担当するようになってしばらく経ちました。最初は正直、精神的に辛い時期もありましたが、考え方を変えることで少し楽になってきました。この記事では、OnCallを知らない方に向けてOnCallとは何か、そしてやってみて感じた良いことや大変なことについて、率直に書いていきたいと思います。

OnCallってなに？

OnCall(オンコール)とは、システムやサービスに障害が発生した際に、業務時間外でも対応できる体制を整えることです。
担当者は当番制で、割り当てられた期間中は24時間365日、いつでも対応できる状態を維持します。

よって、OnCall担当の週は社用携帯と社用PCを持ち、いつでも対応できるようにする必要があります。休日も電話を取って対応できるようにしておく必要があります。

OnCallの仕組み

• 当番制: チーム内でローテーションを組み、一定期間(例:1週間)ごとに担当者が交代
• 多段階体制: 1st、2nd、3rdといった複数の担当者を配置し、1stが対応できない場合は次の担当者にエスカレーション
• 通知方法: 監視システムからのアラートや電話で障害を検知
• 対応内容:
  • システム障害の初動対応
  • 手順書に基づく復旧作業
  • 適切なエスカレーション判断
  • 顧客影響の調査と報告

スケジュール例

ここでは12月のスケジュールを例にします。

• 12/21(土)の0時~12/27(日)の0時までは2ndのOnCallを担当します
• 12/28(日)の0時~1/3(日)の0時まで1stのOnCallを担当します

このように、OnCallメンバー内で1st、2ndを週替わりでローテーションしています。1stが対応できない場合は2ndへ、2ndも対応できない場合は3rdへと電話がかかる仕組みです。
3rdはずっと社用携帯と社用PCを持ちランダムで電話がかかってくるシステムです。

なぜOnCallが必要なのか？

サービスが使えない状況にいち早く復旧させるために必要です。

DevOps文化が浸透する中で「作ったものは自分たちで運用する」という考え方が広まっています。
DevOpsを導入したチームでOnCallをすると下記のような効果があると思います。

• 開発チームがサービスに対してより強い責任感を持てる
• 障害時の初動が早くなる(システムを熟知した人が対応できる)
• 運用を意識した設計・実装が促進される
• サービスの信頼性を守る最後の砦となる

OnCallをやってみて良かったこと

レビューの観点が深くなる

良いコード・悪いコードや仕様を満たせているかといった観点でのレビューはしていました。
OnCall担当になってからは、一歩踏み込んで以下のような観点を持つようになりました。

• サービスを止めてしまうような破壊的なコードにならないか?
• 監視しやすい設計になっているか?
• ログは適切に出力されているか?
• エラーハンドリングは適切か?
• 障害時に原因を特定しやすい実装になっているか?

実際に夜中にアラートで起こされる経験をすると、「この実装だと障害時に困るな」という視点が自然と身についたと思います。

OnCall用の社用携帯に救われる

OnCall用の社用携帯があると、こんな場面で役立ちます。

• 電車遅延の時に連絡しやすい
  • 満員電車では社用PCを開いて連絡することは難しいので、OnCall用の携帯があると連絡しやすい
• 社用PCを使わなくても勤怠の打刻ができる
  • 緊急時にも柔軟に対応できる(ほぼ使ったことはありませんが)
• 緊急時の連絡手段が増える
  • 使用している携帯が使えない緊急事態に備えられる
  • 災害時にも役立つ

OnCallの大変なところ

精神的な負担が大きい

OnCallを始めた当初は、必要以上に気を張って余計に疲れていました。

OnCall開始当初の考え方:

• 1stの時は電話が取れるようにすることが最優先
  • 1stの日は予定を入れず家で電話を取れる状態にしていました
  • むしろ、普段の業務で進められなかった改善活動や工数のつかない社内有志活動などのほぼ仕事に近い作業をしていました
• インシデントが起きたら即座に対応しなければならない
  • 深夜のOnCallで2ndを叩き起こすようなことをしたくない
• お客様影響を出す前に必ず復旧 or エスカレーションしなければならない

この考え方だと、OnCall期間中は常に緊張状態で、プライベートの時間も気が休まりませんでした。飲み会やイベントに参加することもためらってしまい、生活の質が下がっていました。
また、見えない負担もかかっていると思います。

見えない負担:

• 常に気を張っている精神的コスト
  • 「いつ電話が来るか分からない」というプレッシャー
  • 深酒や遠出を避けるなど、プライベートの制約
• 睡眠の質の低下
  • 夜中のアラートに備えて浅い眠りになる
  • 実際に起こされなくても疲労が蓄積する
• 集中力の低下
  • OnCall期間中は開発業務に集中しきれないことも

DevOps化による新たな負担

社内全体でDevOps化が進んでいますが、それに伴いインフラも開発者側へ委譲されていくため、当然OnCallもチーム内で対応することになります。
これにより開発者は自分が携わるサービスに対してより責任感を持ち、障害の件数を減らそうという意識が芽生えます。上記のレビュー観点を得られる機会にもなるでしょう。
しかし、新規開発に集中していたところに保守や監視体制の整備、復旧手順書の整備などの業務も加わることになり、新規開発と保守・監視体制の整備の両方に板挟みになって頭を抱えることになると思います。
(グロースプロダクトのOnCallが始まったら、この監視体制の整備と復旧手順書の整備などに苦しめられると思います。)

専任体制の難しさ

OnCallで感じたのが専任体制の難しさです。下記の記事に記載してあることがとても刺さりました。
私たちのサービスは複数のサブシステム(認証、データ管理、デバイス管理等)を扱っており、全てのシステムに精通している人は限られているため、特定メンバー(エキスパート)に依存していると感じました。

オンコール対応を担うには、システムのワークロードや構成を理解している必要があります。
そのため、理解度が浅いメンバー(ビギナー)は対応を避けがちになり、結果的に知識を持つ特定メンバー(エキスパート)に依存する傾向が生まれます。

考え方を変えることで楽になった

大変なことばかり書いてきましたが、最近では考え方を変えることで少し楽になってきました。

現在の考え方

• どんな改善や施策をしてもインシデントは起きる時は起きる
  • 完璧な予防は不可能。起こることを前提に備えることが大切
• OnCallではインシデントを減らすことはできない
  • 普段の開発やレビューの方がインシデント削減には重要
  • OnCallは「起きたことへの対応」に専念すれば良い
• OnCall担当者に求められることを明確にした
  • アドホック対応が本質
  • 手順書に対応方法がない場合は、適切なエスカレーション
  • インシデントによる顧客影響がある場合の影響調査
  • 電話に取れないこともあるから3rdまである。だから、取れなかった時はしょうがない

この考え方に変えてからは、「できる範囲で最善を尽くす」という姿勢に切り替わり、精神的な負担が軽減されました。

特に「電話に取れないこともある。取れなかった時のための3rdまでのOnCall体制」と割り切れたことが大きかったです。完璧を求めすぎず、多段階体制の意味を理解することで、気持ちが楽になりました。

まとめ

OnCallは確かに大変な業務です。精神的な負担も大きく、プライベートにも影響します。

しかし、OnCallを通じて得られるものもあります。

• サービスの安定運用に貢献できる責任感
• 運用を意識したコードレビュー観点
• システム全体への深い理解

そして何より、考え方を変えることで負担を軽減できることが分かりました。完璧を求めすぎず、「できる範囲で最善を尽くす」姿勢が大切だと思います。

この記事が、これからOnCallを担当する方や、OnCallについて知りたい方の参考になれば幸いです。