インシデント対応ルール作成で大事だと感じたこと
はじめに
レバウェル開発部アドベントカレンダー2日目です。
こんにちは。最近Embedded SREをやり始めた、エンジニアの高倉です。
最近レバウェル開発部のインシデント対応ルールを作成したので、そこから個人的に感じたことを記していきたいと思います。
まだSRE周りの知識や経験が乏しいので、その前提でお読みいただけたら幸いです。
また、内容は抽象度が高めで必ずしもインシデントマネジメントに特化した内容ではないこともご承知いただけますと嬉しいです。
目次
- なぜルールを作ったのか
- ベースにすべきはGoogleの原典
- なぜルールが必要なのかを常に念頭に置く
- 挫折しないように周りを巻き込む
なぜルールを作ったのか
そもそもルールが存在しないことで、レバウェル開発部では大きく2つの問題が発生していました。
課題① 担当者が不明確
担当者が明確になっていないことに起因するものです。
誰も手をつけず対応が後手に回り気味になったり、特定のメンバーに負担が集中したりしていました。
課題② 連絡先が不明確
報告体制が不明確であったことに起因するものです。
報告漏れのリスクが高い状態でしたし、その場で報告先を考えるのでそのタイムロスも大きいものでした。
これらの課題から、インシデント対応ルールがあった方がいいという声が、開発部内の複数のグループからあがりました。 私はSRE系の業務に以前から興味があったこともあり、作成を担当することにしました。
もう一人の有志のメンバーと共に、二人体制でコツコツ作成を進めていきました。
2ヶ月ほど本筋の業務と平行して作成を続け、現在は開発部内に公開してFBを受けている最中です。
部分的にですが、運用も開始しています。
現時点での反省点も踏まえて、学んだことを3つに絞ってご紹介させていただきたいと思います。
ベースにすべきはGoogleの原典
レバレジーズの他事業部には、既に同じようなインシデント対応ルールが存在していました。
既に運用しているものがあるならそれを参考にしない手はないと考え、それらをベースに作成を進めていきました。
この方針は間違いではなかったのですが、今思えばそれらに影響を受けすぎたと感じています。
事業や開発組織の規模が異なれば、当然ルールも変わります。
既に運用されているルールを参考にしすぎると、自身の事業部にとっては何が大切なのかという観点で考えることが無意識に難しくなっていきます。
後になって、自分の事業部にとっては運用が難しかったり、観点が足りていなかったりすることに気づくことが度々ありました。
まず、GoogleのSRE本の中で少なくともインシデントマネジメント関連の章は、説明できるレベルまで読み込んでから、それをベースに事業部が目指す姿に沿うように内容を取捨選択・修正していくべきだったと感じています。
この本の詳細については、最後の「補足」の章にリンクを記載します。
GoogleはSRE文化の原点ということもあり、現代の多くの企業のインシデントマネジメントや信頼性向上のための取り組みの多くは、これをベースに考えられていると思います。
少なくとも、私の会社はそうです。
この原典の落とし込みを十分にせず、他のチームで既に改変・運用されているルールを参考資料として重きを置いてしまったのは、よくなかったと感じています。
なぜルールが必要なのかを常に念頭に置く
これは、当たり前といえば当たり前のことですし、普段のタスク全てに当てはめることです。
私自身の改善点ではありますが、作業をしているときになぜその手段を取っているのかが頭から抜け落ちる状況に陥ってしまうことが度々あります。
今回のルール作成も、私にとってはその類の作業でした。
なぜなら、今回のルール作成は、チーム内の「あったほうがいい」という声から作業開始に至っているからです。
しかし、「あったほうがいい」を「なぜ今なければならないのか」までの落とし込みが自分の中で足りないまま作業を進めてしまいました。
これでは、いかにいい参考資料があっても意味のあるものは作れません。
そしてこの落とし込みは、開発部の目指す姿を見据えていないとできないものだと実感しました。
なぜなら、これらをあまり見据えずとも、教科書的な文言の組み合わせでルール自体はある程度形にはなりますが、成果物が本当に運用しやすいものになるか、意味のあるものになるかには、大きく差が出るからです。
SREは視座が高くないと務まらないのだということを、様々な同僚からFBを受ける中で実感しました。
より開発部や事業部の目指す形に沿うように改善していきたいと思います。
挫折しないように周りを巻き込む
インシデントマネジメント系は、重要度は高いことを誰もが認識しているが、緊急度は上がりにくいタスクだと思います。
今回のルール作成も、普段のプロダクト開発タスクの空き時間で行いました。
そのため、途中で挫折しないように以下のことを意識しました。
- 毎週MTGを設定してそれまでに進捗を必ず出す
- 6, 7割くらいの完成度まで達したら、まずは公開してFBをもらう
- 部分的にでも運用を開始してもらって所感を得る
一緒に作成してくれたメンバーには本当に感謝です。
毎回、勝手にMTG突っ込んですみませんでした（笑）。
おわりに
Embedded SREとして、そしてプロダクトを開発するいちエンジニアとして、視野を高めていく必要があることを実感しました。
それに気づけただけでも、担当してよかったと感じています。
反省点は多くありますが、メンバーからのFBを受けて改善していきたいと思っています。
ここまで読んでいただき、ありがとうございました。
明日は、レバウェル事業部の信頼性の要を支える、Product SREの投稿です！
補足
Site Reliability Engineering - Managing Incidents
SRE本の理論編の中の、インシデントマネジメントの章です。
SREといえば、まずこの本を読むべきだと言われます。英語のみですが、無料公開されています。
The Site Reliability Workbook - Incident Response
SRE本の実践編の、インシデント対応の章です。
こちらも英語のみですが、無料公開されています。
Discussion