会社に新しい SRE チームができた?私が 2 回実際に使った 90 日プランです。成功の理由は「即時価値を示す」と「長期的な基盤を築く」のバランスにあります。
Days 1-14: Observe
すぐに何かを変えようとする衝動を抑えましょう。現在のシステムを観察し、既存のポストモーテムを読み、オンコールをシャドーイングし、エンジニアたちに彼らの課題について話を聞きましょう。
Output: 「1 週間あたりに失われたエンジニアリング時間」で順位付けした、上位 5 つの信頼性問題のリスト。
Days 15-30: Quick wins
リストから上位 2 つを選び、それらを修正しましょう。修正内容を可視化し、エンジニアリング全体会議で発表してください。
良いクイックウィン例: 不安定なアラートの削除、繰り返しのランブックの自動化、みんなが不満を言う壊れたダッシュボードの修正。
悪いクイックウィン例: デプロイメントパイプラインの全面書き換え。規模が大きすぎ、90 日だけでは完了しません。
Output: 可視化された信頼性改善とエンジニアリングチームからの信頼。
Days 31-60: Foundations
得られた信頼を活かし、基本的な取り組みを始めましょう:
- 上位 3 つのクリティカルサービスの SLO 定義
- エラーバジェットダッシュボードのセットアップ
- 週次信頼性レビューの確立(10 分程度、1 時間は不要)
- インシデント対応ランブックテンプレートの作成
Output: エンジニアリングチームが目指せる、測定可能な信頼性目標。
Days 61-90: Programmatic change
信頼性業務を継続的なプログラムへと変えていきましょう:
- アクションアイテム追跡付きのポストモーテムプロセス
- 月次 toil 調査(今月、エンジニアが行った自動化可能な作業は何か?)
- リーダーシップとの四半期信頼性レビュー
- 明確なハンドオフプロセス: 信頼性業務がいつプロダクトエンジニアリング業務になるのか?
Output: 休暇を取っても継続して機能するプロセス。
The trap
「問題ない、1 週間で全部できる」——そんなことはできません。試みたチームはすべて、燃え尽き症候群か反発を招きました。90 日が最低ラインです。それ以上かかるのが普通です。
The real goal
91 日目に、エンジニアリングチームが貴チームの価値を 1 文で説明できるようにしましょう。できなければ、90 日を無駄にしたことになります。
Written by Dr. Samson Tanimawo
BSc · MSc · MBA · PhD
Founder & CEO, Nova AI Ops. https://novaaiops.com
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.