仕組み化とドキュメンテーションで CTO の1人 "Always On-Call" 状態をなんとかする

著者：tk3fftk
目次

はじめに

株式会社primeNumber で データマネジメントを支援するSaaS TROCCO と COMETA の SRE をやっている髙塚 (@tk3fftk) です。
SRE Magazine 第5号はインシデントとか On-Call ネタが多そうな雰囲気を感じたので乗っかって On-Call 改善ネタを書いてみます。

TL;DR

CTO の1人 Always On-Call 状態をなんとかするために、 On-Call ローテーションを整備しました。
また、単にローテーションを組むだけでは今後スケールしないことが予想されたため、以下の3つの施策を行いました。

  • On-Call への補償の導入
  • On-Call 担当者の責務を明確にする
  • On-Call 担当者のハードルを下げる

読むといいかもしれない人

  • On-Call の仕組みや On-Call ローテーションを導入したい人、改善したい人
  • 1人 Always On-Call 状態をなんとかしたい人
  • 改善話を読むのが好きな人

On-Call とは

システム運用の文脈において、勤務時間外も含めて緊急対応が必要な事象が発生した場合に即座に対応できるように担当者を決めておくことです。

元ネタとして、医療文脈でも勤務時間外でも呼ばれれば患者の急変や急患などの緊急対応ができるように待機していること、という概念があり、IT業界に適用し使っている概念です1。「患者」を「担当システム」と置き換えればもうそのものですね。

ちなみに、本記事の Always On-Call とは、下記の画像のように PagerDuty で常に On-Call シフトに含まれている場合に表示されるテキストから拝借しています。

改善前の状態

  • ツールとして、PagerDuty は導入済み
  • CTO の @kekekenta が1人 Always On-Call として1次請け、自分含め3名ほどのエンジニアで2次請け
    • ただし、深夜対応も含めエスカレーションされることはほぼなかった(≒ほぼ CTO が対応してくれていた)

何が課題なの？

エンジニア組織が小さいうちは、そもそもローテーションを組めなかったり、組んだとしてもすぐ回ってくるような状況は発生します。そのような場合は「頑張るしかない」とシステム運用アンチパターンの “6章 アラート疲れ” にも記載があります2。
弊社の場合も、上記の状況に該当していた時期の運用のまま改善されないままだった、という感じだったのでしょう。

この体制には、明らかにいくつかの課題があります。

  • CTO 以外の障害対応スキルが上がらない、知見が貯まらない
  • そもそもアラートに対応できず、ユーザーや事業に悪影響を与える可能性
    • CTO が対応できなかったらどうするの
    • CTO が体調不良とかで中長期で抜けてしまったらどうするの
  • CTO の アラート疲れ3 リスク

何をしたか

On-Call ローテーションを整備しました。
また、単にローテーションを組むだけでは今後スケールしないことが予想されたため、以下の3つの施策を行いました。

  1. On-Call への補償の導入
  2. On-Call 担当者の責務を明確にする
  3. On-Call 担当者のハードルを下げる

それぞれについて、説明していきます。

1. On-Call への補償の導入

On-Call への補償の導入を打診し、会社の制度として On-Call 担当日数に対して手当がつくようになりました。

On-Call 担当というのは基本的にはつらいものです。
アラートが鳴れば、深夜3時で眠りについていても飛び起き、遅くとも数分後には PC を開き対応を開始せねばならず、家庭がある場合は家族にも負担をかけます。仮にアラートが鳴らなくても、休日の外出時にも PC 持ち歩きによる筋トレを強いられます 4。

これらのつらさは世界共通であり、参考にした書籍でも散々言及があります。

オンコールは、睡眠の質や家族との時間など、生活の多く部分に対してよくない影響があります。この業界の悪しき部分に対して補償金を出すのは、公平なことだと言えるでしょう。
Mike Julian. 入門監視

オンコールの頻度が少なかろうが多かろうが、正式な補償を求めるのであれば、それは当然のことであり、彼らにはその検知があることを忘れてはいけません。
Jeffery D. Smith. システム運用アンチパターン

また、医療業界のオンコール担当にも手当が存在するケースが多いようです。

💡 On-Call への補償を会社の制度にできない場合

On-Call 担当をやっている/指示していて心苦しいと感じている、けど会社から補償はされないし、補償が出る形に会社を動かすのも難しそう、という方がもしいれば、金銭でなくてもマネージャーの裁量で補償する形にできるとよいかもしれません。

例えば、オンコール当番を1週間やったらどこかの日で半日仕事したことにしていいよ、1日ちょっとメインの業務から離れて好きな技術触る枠にしていいよ、のような、コントロールできる範囲で休暇や時間的な補償は生み出せるものだと思います。もちろん、勝手にやるのではなく人事や上長を交えた相談は必要です5。

2. On-Call 担当者の責務を明確にする

On-Call 担当者の責務をドキュメント化し明確にすることで、担当者が具体的に何をすればいいのか分かるようにしました。
責務の一例としてはこんな感じです。

  • 休日も可能な限り PC を持ち歩いてね
  • PagerDuty の設定はちゃんと通知に気付けるようにしておいてね
  • 営業時間中は Slack に通知される Critical ではないアラートも見てね
  • 交代の際、再発しそうな問題がもしあったら、その概要と対応方針などを共有してね

新しい On-Call 担当者がローテーションに加わったときに疑問やハマリポイントが出てきたタイミングで更新することが多い印象です。

3. On-Call 担当者のハードルを下げる

On-Call 担当者になってほしい、と頼んでも「No」と言われてしまってはローテーションを組むことはできません。
そのため、担当者のハードルを下げるために行動方針のようなものを責務と合わせてドキュメント化しました。

  • あくまで1次請けであり、初動対応を行うまでが責任範囲と明文化
    • 初動対応については、別途 インシデント対応マニュアル として対応フローを準備しています
  • 仮に対応できなくても、エスカレーションされるから気負い過ぎなくてもOK
  • わからなければ遠慮なくエスカレーションしてOK
  • (主に営業時間中の対応向け) 対応開始時に On-Call ユーザーグループにメンションして対応するようなルールに
    • 他のメンバーが状況を把握できるようにしたり、対応者をサポートしやすくする目的

また、 アラートが何を示しているものなのかを分かりやすくしたり、可能なものは対応内容をアラート文に含めてコピペで状況の確認や対応ができるよう改善しました。

どうなったか

無事に CTO の Always On-Call 状態を剥がせました。
剥がしてから約1年半、現在は SRE + ソフトウェアエンジニア計6名で On-Call ローテーションを組んでいる状態です。
幸いなことに、On-Call 担当 2週目のエンジニアからも「マニュアルや対応の Tips が豊富でハードルが低く、他の経験豊富な On-Caller が頼りになるので、そこまで心理的負担もなくやれています」というフィードバックもいただいています。
また、 On-Call 担当を通じて自分ごととしてアラートを見ることで、アーキテクチャ理解やシステム改善、アラート改善の機会に繋がっています。

おわりに

On-Call ドキュメントの履歴を漁っていたらドンピシャな記載がある版が発掘されました。懐かしいですね。

primeNumber では、プロダクトだけなく会社の文化も一緒に implementes してくれる SRE を募集しています！とりあえず話だけ聞いてみたい、という方は DM いただくかカジュアル面談フォームからお問い合わせください！

参考文献

  1. そのため、医療業界の人には IT における On-Call 担当の説明が一瞬で終わるという tips がありますが、本文とは関係ありません ↩︎

  2. システム運用アンチパターン p117-118 ↩︎

  3. 大量のアラートに対応する担当者の感覚が鈍化して、アラートの見逃しまたは無視、対応の遅れが発生する状態 ↩︎

  4. 筆者は高尾山までならPCを担いで登ったことがあります ↩︎

  5. 詳しくはシステム運用アンチパターン p119-121 を参考にしてみてください ↩︎