NTTドコモ様 事例
NTTドコモのシステムにおける
「DevOps推進と運用効率化」
NTTドコモが提供するサービスのシステム開発・運用では積極的にDevOpsを推進しています。
「オブザーバビリティの強化、PagerDutyの導入」により初動対応の迅速化や運用の効率化を実現。
サービスの価値を高める活動に多くの時間を割けるようになった事例をご紹介！→ PagerDutyの資料をみる（無料）
DevOpsの導入によって、開発エンジニアがサービスの信頼性と可用性に対する責任を負い、オンコール対応に携わるようになりました。オンコールは重要な職務ですが、精神的な負荷が大きいため不安を感じる方も多く、いわゆる「燃え尽き症候群」に陥る方も生じます。
そこで今回は、PagerDutyコミュニティのメンバーから寄せられた、オンコール対応の不安を取り除く方法や、オンコールローテーションに臨む際のアドバイスをご紹介します。ぜひ、今後の参考にしてください！
目次
インシデント管理における「オンコール対応の重要性」
オンコールとは、勤務時間外を含めて緊急対応が必要なインシデントに対応できるように、対応者や担当時間を決めておく仕組みです。
現在は、24時間365日稼働が前提となるシステムが多いなか、サービスの信頼性を守るには迅速なインシデント対応が求められます。仮にサービスが停止することになれば、機会喪失や顧客満足度低下を招くことになりかねません。そのため、インシデント管理においては速やかに対応が行える、オンコール対応が重要です。
なお、システムで起こり得るインシデントの種類は、以下の記事でも解説しています。
「インシデント対応」とは？
〜効率的な体制構築のポイントを解説〜
また、インシデント管理については以下の記事で解説しているので、ぜひ併せてご覧ください。
「インシデント管理」とは？〜システム障害を未然に防ごう〜
エンジニアがオンコール対応に不安を感じる理由
エンジニアによるオンコール対応は、早期の問題解決に加え、運用面の問題などを開発時点で改善することにもつながるなど、さまざまなメリットがあります。しかし、オンコール対応では、担当者が問題の切り分けや対処・エスカレーションなどの判断を行う必要があり、不安に感じるエンジニアも少なくありません。
エンジニアがオンコール対応に不安やストレスを感じる理由には、次の3点が挙げられます。
深夜のオンコールに気付けないかもしれない
オンコール担当中は、いつインシデントが発生し、呼び出しがあるかわかりません。
呼び出し時にはすぐに対応が必要ですが、深夜の場合は眠ってしまい、気付けない可能性もあります。そのため、オンコールに慣れるまでは、深夜に即時対応できるのかという不安を感じやすいでしょう。ストレスが大きく、睡眠障害につながる例もあります。
重大なインシデントが発生する可能性がある
インシデントには短時間で解決できるものもありますが、解決に数時間かかるものもあります。オンコール対応時に重大なインシデントが発生するかもしれない、という不安も大きなものです。
さらに、重大なインシデントに適切な対応ができなければ、大きな損失につながりかねない点にも、ストレスを感じるでしょう。
未知のインシデントへの対応を求められるかもしれない
オンコール担当時に、未知のインシデントに遭遇する可能性もあります。適切な対応を迅速に行わなければならないため、ストレスになるでしょう。
また、未知のインシデントであるためプレイブックやランブックに適切な解決方法が書かれていません。そのため、特に経験の浅いエンジニアは、過去に経験したことのないインシデント対応に対して、不安を感じる傾向にあります。
オンコール対応の不安解消に有効な組織の取り組み
オンコール対応への不安は、発生したインシデントに対して適切な対処ができるのか、という点に集約されます。オンコール対応は経験がものを言う部分もありますが、対応を仕組み化することで、担当者の負担を軽減できます。
ここからは、PagerDutyコミュニティのメンバーから寄せられた、オンコール対応の不安を取り除くために有効な組織の取り組みを紹介します。
1️⃣ プレイブックの作成
インシデントに対して、迅速に対処するために役立つのがプレイブックです。プレイブックにすべての答えが書かれている必要はありませんが、少なくとも、次の情報を記載しておくべきです。
- チームがサポートしているサービスおよびその存在場所（Git／デプロイ先／リンク）
- 各サービスの専任者と正常性の確認方法（モニターへのリンク）
- 過去のすべてのエラー事例とその解決方法
オンコール担当者が経験したことのないインシデントも、プレイブックを参照すれば対処方法がわかります。
2️⃣ 責任範囲の明確化
インシデント対応において担当者に責任を持って対処させることは重要です。しかし、その責任の重さがストレスや不安につながりやすいため、責任範囲を明確にしておくことが不安解消に役立ちます。また、責任はチームにあることを担当者に自覚してもらうことも大切なポイントです。
3️⃣ 再発の防止
再発防止策を講じることもオンコール担当者のストレス軽減に効果的です。同様のインシデントが繰り返されることは、エンジニアの疲弊や燃え尽きの要因となります。
そのため、組織がインシデントを再発させないように取り組む必要があります。
初めてオンコール対応に臨む人へのアドバイスは？
インシデント管理で未知の問題が起きた場合に備えて、各担当者が自分に合った対処方法を準備しておくことも必要です。ここではPagerDutyのコミュニティのメンバーから寄せられた「特に初めてオンコール対応に臨む方に役立つアドバイス」を紹介します。
✅ 自分で対処できないときはチームを頼って良い
オンコール時のインシデントには、速やかに対処しなければなりません。
しかし、インシデント対応は担当者個人のみではなく、チームによって成り立つものです。自分で対処できないときには、チームに頼ることで解決を導けます。PagerDutyコミュニティメンバーであるソフトウェアエンジニアのJohn Miller氏は、次のようにアドバイスしています。
「あなたは一人ではないし、すべてを理解している必要もありません。連絡の窓口としてきっとうまくやれるはずです。チームの知識が蓄積されたプレイブックも使えますし、もし答えが見つからなければ専任者に連絡をすれば良いのです」
NOCエンジニアのEhsan Ebrahimian氏も同様に「どのオンコール担当者も、最初は初心者でした。チームで動いているのだから、孤独ではありません。誰かが見守ってくれているはずです」と述べています。
✅ インシデント対応のプロセスを理解しておく
インシデント対応では、何をすべきかわからないときに不安やストレスを感じやすくなります。
NOCエンジニアのNathaniel Swanson氏は、インシデント対応のプロセスを理解することの重要性を、次のように述べています。
「一にも二にも記録です！それほど記録は重要です。アラートへの対処方法や、必要な際にサポートを受ける方法を理解していれば、ストレスは大幅に緩和できます」
✅ 監視と可観測性の閾値を事前相談しておく
必要以上のアラートも、オンコール対応の疲弊やストレスの原因です。PagerDutyコミュニティメンバーのJ.S.氏は、次のようにアドバイスしています。
「関係者に、監視と可観測性の閾値を事前に相談しておきましょう。サポートを求める範囲を決める際に、当事者である彼らを巻き込めば、オンコール対応の担当範囲を相談する際に非協力的な態度を取られることを避けられます」
オンコール対応におけるストレスへの対処法については、燃え尽きエンジニアを救う「オンコール最適化、5つの教訓」でも紹介しています。ぜひ参考にしてください。
まとめ：PagerDutyを活用したインシデント管理でオンコール対応の負担を軽減しよう！
本記事を通じて、少しでも「オンコール対応の不安」の解消に繋げて頂けると幸いです。また、オンコール対応におけるエンジニアの負担を軽減するには、インシデント管理ツールの活用が有効です。PagerDutyは、インシデントの検知・トリアージ・動員・解決・予防をサポートし、オンコール対応を効率化します。オンコール後も対応手順が自動化されていれば、解決までの時間を短縮可能です。PagerDutyは蓄積されたデータをもとにした、オンコール対応のベストプラクティス実践にも最適のサービスです。オンコール対応の経験が浅いエンジニアも、適切な対処やエスカレーションが行えるようになります。
PagerDutyに関する資料や導入事例は、以下のページからダウンロードいただけます。
https://www.pagerduty.co.jp/resources/
NTTドコモ様 事例
この記事が気になったら
PageDuty公式アカウントをフォロー
この記事の著者
関連ブログ記事
人気記事
検索
タグ目次
