DevOpsやSREが浸透し、開発チームもオンコール担当に
オンコールとは、システム上でインシデントやアラートといった想定外のイベントが発生した場合に、一部の従業員へ通知される状態・対応を意味する。オンコールプロセスが標準化されていない場合、問題発生時に状況を知っていそうな人物に手当たり次第に連絡することで解決を図るケースが多い。そこで、オンコールの標準化したプロセスとスケジュールが重要となるとMandi Walls氏は語る。
「オンコールにおいては、適切なタイミングに適切な人材が対応する環境を整え、インシデントが顧客やユーザーに与える影響を最小化しなくてはいけません。しかし、システムやアプリケーションの多くは複雑な問題を抱えており、そこで何が起こっているのか、状況を常に把握しておくことは困難です」
近年、DevOpsやSRE（サイト信頼性エンジニアリング）モデルが探求されるようになり、オンコール担当者の範囲が広がっている。以前であれば、アプリケーション開発チームが開発したコードは、オペレーションチームに引き渡され、そこで管理が行われていたが、現在は問題発生時の一次対応者として、アプリケーション開発チームのオンコール責任が増しているのだ。
「問題への対応や修復にかかる時間を短縮するには、一次対応者としてコードを書いた本人、もしくはそのコードを熟知している開発者をオンコール担当とします。そこで重要なのは、各開発者が熟知している領域に注目し、本番システムを細かく分割統治すること。それぞれの専門領域に基づいて、オンコール担当を分割することです」
また、オンコールでは「対応すべき日時」「担当者」「担当する呼び出し内容」を明確にし、シフトは定期的なローテーション、「担当する役割で期待されること」「目標を明確に定めること」を推奨するとMandi Walls氏は言う。
「予定外の問題に対応するオンコール対応者のために、想定外の要素を減らすこと。そして、マネージャーは全メンバーの健康状態、呼び出されたメンバー、夜中に起こされたメンバーを把握してください」
チームにとってのオンコールのメリット
オンコールのベストプラクティスに必要なことは？
続いて、ベストプラクティスに向けた3つのポイントが紹介された。1つは「引き継ぎミーティング」である。オンコール対応の終了時、次の担当者と交代する前に、何らかの引き継ぎをすること。正式な会議を行う必要はなく、立ち話でもメールやSlackでメッセージを送るだけでもいいので、現状を伝えることが重要となる。
2つ目は「設備」。担当者が自宅からログインしてオンコール対応ができるように、ノートパソコン、電話、インターネット接続が可能な手段を提供すること。ただし、これはコロナ禍以降のリモートワーク推奨により、解決している企業も多いと考えられる。
3つ目は、アカウントとアクセス権について「チェックリストを作ること」。オンコール時に必要な事柄をまとめてチェックリスト化しておくことで、よりスムーズな対応が可能となる。
アカウントとアクセス権のチェックリスト
オンコール文化構築に向けたコミュニケーションのポイント
オンコールチーム内において、オンコール文化を構築することはとても重要なベストプラクティスとなる。その際にポイントとなるのがコミュニケーションのとり方だ。以下にて、重要な要素をいくつか紹介する。
共感
最も重要な要素は「共感」だ。可用性の高い本番システムの運用には、多くのストレスが伴うため、協力的な文化を築くことは欠かせない。インシデント発生時には、それまで「全く問題ない」と思っていたことが覆されることも少なくない。メンバーの気持ちに寄り添うことは大切だとMandi Walls氏は強調する。
「メンバーの心理的負担を軽減したいのであれば、インシデント対応について責めるべきではありません。『誰も責めない』ポストモーテムの原理と同様です」
心理的安全性
心理的安全性が確保された組織であることも重要だ。積極的な取り組みや行動変化を促し、「質問しても問題ない」「結果を恐れず提案しても問題ない」と感じられる職場環境を築く必要がある。Mandi Walls氏はパイオニア的存在であるAmy Edmondson教授のホワイトペーパーを紹介し、その重要性を語った。
心理的安全によるメリット
新人研修
新人には「聞くだけ」の状態で参加し、新たな業務内容について学べる場となる新人研修を用意する。新人にとってオンコールはなじみのない業務であり、誰しも初めから良い仕事はできない。実際に体験することで、現場の状況を知ることで自信も生まれる。
「PagerDutyでは新人はまずシャドーローテーションに組み込まれます。聞くだけの状態ですが、オンコール担当者と同様に通知を受け取り、あらゆる情報を吸収し、全体的な現場作業について学びます。インシデントコマンダーの導入もお勧めです」
振り返りと改善
オンコール業務の目的は信頼性を高めること、そしてユーザー体験の向上。インシデントを解決すると同時に、学びを得る必要がある。その一環として行うのが、インシデントを振り返るポストモーテム（事後検討）だ。
インシデントが発生した経緯、得た教訓、他のツールの問題などを検討し、システムの信頼性を明確に向上させる方法を探ること、平均修復時間（MTTR）や平均確認時間（MTTA）などのメトリクスを管理することなどが推奨される。サービスレベル目標（SLO）の達成に向けた進捗や、インシデントのエラー予算を管理することも役立つ指標となる。
他チームへのエスカレーション
必要であれば、他のチームにエスカレーションすることもベストプラクティスの1つ。PagerDutyでは行動指針として、「エスカレーションをためらわないこと」を掲げているという。
重大インシデントの宣言
「重大」の定義は各社で異なるが、状況に応じて重大インシデントを宣言することも重要だ。影響を受けた顧客数やアプリケーション内のサービス数、インシデント継続期間などが指標になる。チャットアプリ機能を利用して、エスカレーションを自動化するのも良い。また、状況に応じたエスカレーションや重大インシデントの宣言を躊躇なく行える文化と慣習を確立することも推奨される。
睡眠時間は特に大切！ オンコールのマナーと期待されること
オンコールチームには、夜間でも対応を迫られることがある。その際、企業や管理者はマナーを守る必要がある。以下にて、オンコールチームの行動に関するベストプラクティスも紹介する。
従業員に配慮したオンコール
夜間にオンコール勤務に就くメンバーの睡眠時間に配慮することは、何より大切なマナーである。出勤要請を受けて徹夜したメンバーや数時間しか寝てないメンバーなどには、翌日の出勤時間を遅らせることを認めるルールを策定しておきたい。具体的には、以下のような対応が挙げられた。
- シフトの変更を認める
- 支援要請の通知を早めに出す
- 睡眠時間を確保する
- 燃え尽き症候群に注意する
チームで協力する
オンコールのシフトを組む際は、勤務時間や夜間・休日出勤などに偏りがないように公平性を重んじた分担を留意する必要がある。燃え尽き症候群の予防法にも繋がる。オンコールに期待されることや行動規範を伝えておくことも重要だ。
時間管理
人間には限界があるため、オンコール勤務期間は、通常の生産性を期待できない。そのため、オンコール担当週は、通常の仕事量を減らす必要がある。例えば、担当するチケット対応数を減らす、ドキュメントやバグ修正、自動化管理などの事務的な作業を担当するなどの対策などが考えられる。
オンコールチームが明日から行える、実装面に関するベストプラクティス
ここまでは、文化やマナーなど、組織に求められる部分について語られた。Mandi Walls氏は終盤に、オンコールチームが明日からでも始められる、実装面のベストプラクティスについても紹介してくれた。
アラートの精査
まず可能な限り、アラートを精査して抑制すること。通知するのは重要なアラートのみとし、些細な問題、重要度の低い問題、修正不可能な問題は通知しないことを徹底させる。特に夜中にアラートでメンバーの睡眠を邪魔しないようにするためにも、可能な限り自動化することが勧められた。
「PagerDutyでもプラットフォーム全域からアラートが発信されていますが、人間に通知されるアラートの約20％は5分以内に解決されています。5分以内ということは、デバッグは行われていません。そのような問題は自動修復するべきです。再起動や容量の追加などで解消されるので、自動化しましょう」
また、常にすべてのドキュメントとソフトウェアを最新状態に保つこと。そして、外部との依存関係がある場合は、そのベンダーの連絡先や関係性、ライセンス期限、支払い時期、その依存関係が該当システムに影響を与えた場合に起こり得る事柄について、あらゆる情報を全員に伝えることも推奨された。
プロジェクトの優先順位付け
初心者はまずは、最も安定しているサービスから始めること。長い間提供されており、問題なく稼働しているサービスから慣れていくことが大切だ。次に、顧客の売上に直結するサービスやその機能など、自社サービスポートフォリオの中で、最も重要なサービスを優先することが重要となる。また、自分が担当しているシステムの優先度を上げすぎることも悪影響を及ぼす可能性があるため、留意したい。
従来型のNOCの活用
従来型のネットオペレーションセンター（NOC）がある場合は、活用すべきである。すでに24時間365日体制で対応しているチームがあれば、オンコールチームに代わり、ランブックの実行、基本的なトリアージや自動診断などの初期対応を担ってもらうことができる。
また、NOCにインシデントコマンダーや顧客窓口などのインシデント管理サポート役を担ってもらい、オンコールチームの負担を軽減することも可能である。
柔軟なモデル
忘れがちなことであるが、オンコールはとても柔軟で調整可能なもの。例えば、オンコールに1週間単位という決まりはない。チームや仕事のスケジュールに合わせて区切ることもできる。「PagerDutyでは担当を交替する曜日はチームごとに異なる」とMandi Walls氏は語る。
「担当者間の引き継ぎを考え、交代は平日に行うべきです。PagerDutyには、その上位チームとも呼べるチームもあり、そのオンコールスケジュールは全く異なります」
PagerDutyのインシデントコマンダーのオンコール勤務時間は1回あたり48時間。交代は午前11時に行われる。勤務時間に引き継ぎが行われるため、状況を理解してからオンコール勤務に入り、その後48時間、責務を担うことができる。必ず日中の時間帯にあるチームが主な責務を担う「フォロー・ザ・サン」モデルを採用しているのだという。
最後にMandi Walls氏は以下のように語り、セッションをまとめた。
「オンコールは信頼性を高めるための取り組みですが、人間には仕事以外の生活もあります。睡眠を優先させましょう。そのためには柔軟に対応し、担当者に寄り添うこと、期待されることや責務を明確にすることが非常に重要です」
