トラブルシューティングはエンジニアの学びの宝庫！価値を生み続ける開発のためのオンコール実践術

【13-C-8】トラシューアニマルになろう ～開発者だからこそできる、安定したサービス作りの秘訣～

心理的安全性の高いオンコール実現のための工夫

オンコールに入ると、心理的な負担が大きいのでは

　呼び出しの頻度が減れば、先述したようなベロシティへの影響は少なく抑えられると予想できるものの、やはりスタンバイしているだけでも心理的な負担はあるだろう。ここは配慮が必要な重要なポイントだ。負担が積もると「燃え尽き」が起きてしまいかねない。

　対策としては無理のないローテーションにする、深夜対応の翌日は半休や休日にするなどのルールを整備していくといいだろう。何よりも「職場の雰囲気作りが大事」と草間氏は言う。何かあれば相談しやすい雰囲気、心理的安全性が保てることが重要だ。

• 　参考資料：燃え尽きエンジニアを救う「オンコール最適化、5つの教訓」

　あとオンコールでも監視画面をずっと凝視する必要はない。呼ばれたら対処すればいい。いざとなったら見る監視画面もできるだけ不要なノイズを除去できるものがいい。そうすれば不要な呼び出しを減らすことにもつながる。

家庭の事情で深夜・休日のオンコールに入るのは厳しい

　子どもが生まれたばかりや、親の介護などでオンコールに入るのが難しいメンバーもいるだろう。可能な限り対応したいものの、免除し過ぎると逆に不公平感を生んでしまい、士気や連帯感を損なってしまう。例えば一定期間だけ日中だけ担当、あるいはセカンダリ対応という分担にすることもできる。

　あるいは「インシデント対応ではなく、ポストインシデントレビュー（ポストモーテム）のファシリテーターを担当してもらうのはどうでしょう」と草間氏は提案する。インシデントがなぜ起きたか振り返る場合、インシデント対応していない人のほうが客観的に分析ができる。改善のフィードバックでは大事な役割になるので、オンコールに入れないメンバーの選択肢の1つとして考慮しておきたい。

　ポストモーテムでは、インシデントで起きたことを時系列に並べて分析したり、オペレーションミスがあったら関係者に事情を聞いたりする。ここで責めるように問いただしてはいけない。自動ではなく手動で作業しなくてはならなかったところに改善の余地があるからだ。例えば「マニュアルはあるけど、ボリュームがありすぎて該当箇所を探せず、記憶に頼って作業したら違うコマンドを打ってしまいました」なんてこともあるかもしれない。それならオペミスした人を責めるのではなく、やるべきはドキュメント整備ではないだろうか。

• 参考資料：間違いだらけのポストモーテム- ホントに役立つレビューはこうだ！

　最後に草間氏は「インシデントを減らし、価値を生み続けるソフトウェア開発にはライフサイクルすべての責任を持つフルサービスオーナーシップが重要です。敬遠されがちなオンコールを開発者も担うことで、開発から運用まで含めてライフサイクルの改善につなげることができます。この一連のサイクルを実現するためにPagerDutyも貢献しています。ぜひトラシューアニマルになり、一緒にやっていきましょう」と呼びかけた。

PagerDuty Operations Cloud