はじめに

first book のオンコールについて、「ここの記事」 でサポートエンジニア視点での考察をしてみました。しかしfirst book を読んだだけでは、オンコール対応についてのもやもやとした課題は残ったままとなっています。これらの課題が、Workbook で解決できるか（語られているか）見ていきたいと思います。

`first book` の考察で残存した課題について

「ここの記事」 では以下のような課題について私は明確な解決策をfirst book から得ることはできませんでした。

オンコール要員を簡単に増員できない
時間外対応の保証が十分ではない
強いストレスで健康を害する可能性がある
問い合わせのほとんどは、ユーザミスで不毛な時間を使ってしまう
トラブルの根本原因を見出す高い属人性
官僚的なポストモーテム処理となってしまう

Workbookで語られていること

Workbook の８章 On-Call には、次の内容が書かれています。

オンコールの事例２点
- Google 内部の事例
  - 4人のNooglers(新規採用者) がオンコール対応を行う前までのトレーニングロードマップを主に説明
- Evernote の事例
  - オンコールポリシーとプロセスの構築の事例
オンコール対応の具体的な実現にあたって
- ページャー(オンコールによる呼び出し)のコントロール
  - 適切な応答時間（トリアージの必要性）
  - 呼び出しをSLOに応じたしきい値で制御する
  - 多くの呼び出しに取り組む最初でかつ重要なステップは、その原因を明確にすること
- オンコールの柔軟性（負荷分散）をするには
- オンコールチームの原動力
  - モチベーションの源泉

`Workbook`で解決したことと、まだ「もやもや」していること

first book から得ることができなかった点について、Workbook にて解決できたのかを説明します。

オンコール要員を簡単に増員できない

[解決]
- シフト体制の明確化
  - "On-Call Flexibility" の節にシフトのための次のTIPSが記載されています
    - オンコールスケジューリングの自動化（ツール利用により人為的な意図が入り込まず、公平に割り振りを行える）
    - 週次レベルでの変更計画（急用、病気などへの対応）
    - 長期的な要員計画（長期休暇の設定など）
    - パートタイムジョブアサイン
[もやもや]
- 個人の事情に応じたオンコールのスケジューリング調整が（臨機応変に）本当にできるのか
- オンコールシフトの人の切り替え（作業の引き継ぎ）がうまくいくのか

時間外対応の保証が十分ではない

[解決]
- オンコールプロセスの定義（Google SREの事例のような）
- 対応優先度の設定(Evernote 事例）
[もやもや]
- 「待機時間」に対する報酬をどう扱うか（各企業次第だと思うが。。）

強いストレスで健康を害する可能性がある

[解決]
- モチベーションの源泉を確保する（後述のマズローの欲求との対比参照）
[もやもや]
- 組織内の理解が進まず、SRE チームとしての役割を明確に定義することができず、ある意味『何でも屋』となってしまう可能性がある

問い合わせのほとんどは、ユーザミスが原因で不毛な時間を使ってしまう

[解決]
- オンコールが発生したその根本原因を特定しよう
  - プロダクトのバグだけでなくプロセス面の課題も明確にする
[もやもや]
- システムで見つかった問題に戦略的に対処するために時間をメンバに与える必要がある（根本原因を見出すような時間を確保する）、という点が現実的には難しい

トラブルの根本原因を見出す高い属人性

[解決]
- オンコールチームの原動力を見出す
  - opsエンジニアの地位向上
  - チーム内の関係性を向上
- トレーニングロードマップ
  - オンコール対応可能になるまでのトレーニングロードマップを規定する
- Playbooks（定石集）の整備を行う
[もやもや]
- プロセスの定義だけではうまくいかない。その心を込めていく必要があるだろう

官僚的なポストモーテム処理となってしまう

[解決]
- フォローアップの難しさ
  - 呼び出し発生時の根本的な原因を見つけるけるのに役立つ十分な監視とログ収集を行う
- 品質データ
  - とにかくデータを集めること。データからバグの根本原因を見出そう
[もやもや]
- 「原因不明」と判断してはいけないとあるが、解析に必要な情報が無いと「再現待ち」となってしまう。
SRE Advent Calendar 2018 の参考となる記事
- @katsuhisa__ さんによる、1日目記事：監視システムの特徴から考える監視設計のポイントにて、監視システムの設定に対するポイントが参考になります。
- @t-okibayashi さんによる、6日目記事：監視の通知とメンテナンスについてにて、アラート・チケット・ロギングの整理が参考になります。
- @kabaome さんによる、3日目記事：ポストモーテムにおける根本原因分析にて、根本原因に到達するための問答例が参考になります。

まとめ

整理してみると、鉄板ネタとなってしまいますが、マズローの欲求５段階とWorkbook のオンコール記載内容を対比することでまとめてみます。
Workbook では、オンコールを「システマティックな仕掛と組織体制」で解決せよ、と言っています。マズローの欲求５段階をざっくり上下に分け、Workbook 記載内容キーポイントを配置すると、下図のようになると思います。

要求の上段を満たすための対応策：「PJへ費やす時間の保証」
要求の下段を満たすための対応策：「オンコールポリシーとプロセスの定義」

上段は言い換えると「チーム自身のスキルアップ」、下段は「オンコールのストレス軽減」に対応した施策を実施するようなことでマズロー要求を満たすことができるのではないでしょうか。

オンコール要員はトレーニングだけで作り出せるものではなく、多くの経験と健全な学ぶ機会が必要ではないかと考えます。さらにオンコール要員となれる素質というものもあるのではないかとも思います。オンコールは、属人性の高い業務であるのですが、できるだけシステマティックに可能な個所では自動化して、健康な生活を送れるようにできるとよいと思います。

参考

メルカリのオンコール対応記事より

「まとめ」で図示したマズロー欲求との対比に記載したメルカリの事例は以下の記事を参考にしています。
「hbstudy#75 SRE大全：メルカリ編」 - Mercari Engineering Blog　記事のスライドからOnCall関連部分を引用

Workbook に記載されていることが、メルカリでは実現できていることが読み取れます。

メルカリSREチームの障害対応に対するモチベーションが高い　→　オンコールチームの原動力がある
アラート対応当番と電話当番というロールがある　→　オンコールの柔軟性がある
- 1週間での交代（4名体制）
オンコールを支える技術　→　インシデントの原因を収集・分析・対処できるシステムができている
- 監視：Mackerel, slacklog
- 通知：Slack, PagerDuty, Twillio

IPA 情報処理技術者試験「ITサービスマネージャ試験（レベル4）」シラバスより

ITサービスマネージャ試験シラバスの大項目「4 サービスの運用」がオンコールに関連すると思います。以下の３項目に対して、要求される知識と能力が定義されています。
- 4-1 システム運用の管理　→　障害時の運用
- 4-2 運用オペレーション　→　監視などのツールの活用、要員の管理
- 4-3 サービスデスク　→　SLO指標管理

「オンコール」をネット検索すると

「オンコール」をネット検索すると医療従事者のオンコールが検索結果が多く表示されます。医師、看護師、その他医療関係者が緊急時に呼び出したあった場合に職場（主に病院）へ向かえるように職場以外で待機すること、と記載されています。
医療従事者のオンコールも過酷な状況であることがいくつも読み取れます。IT業界のオンコール対応と安易に比較はできませんが、どちらも人が高いストレスを抱えて対応していることへの対策が重要（急務）ということになります。