新しいSREが自グループに参画した場合、どのようなオンボードを実施すればいいか迷う。
SREグループという名で活動が始まったのは2022年6月からであり、僕が弊社に入社したのは半年前のことである。
つまりSREグループのオンボードというものがない。僕がひとりで作業していたため体系だったものがないのだ。
言ってしまえば「とりあえずやりながら覚えるしかねえ」というパワースタイルである。 それをメンバーにやってもらうのは車輪の再発明でしかなく、無駄が多すぎる。
なんとかいい方法をと思って調べた。
資料1 -【SRE NEXT】パフォーマンスを最大化するための SRE のオンボーディング事例
メルペイさんのオンボーディング事例だ。見てもらえると分かる通り、オンコール担当できることをひとつのマイルストーンとして置くことにしているという。
確かにSREのオンボード=オンコール担当できるをマイルストーンに定めることで、オンボードの進捗を確認することができそうである。
このオンコールオンボードを通じて、技術的知識とドメイン知識に関する習得が体系化ができれば、SREだけでなくプロダクトチームにも最終的に横展開できると僕は考えた。
資料2 - Accelerating SREs to On-Call and Beyond
メルペイtkuchikiさんの資料で引用されていた元資料である、Accelerating SREs to On-Call and Beyondにはオンコール研修について詳細が書かれている。
時間軸とともに、やっていくといいプラクティスが図に示されている。
プロダクトのドメイン知識や、現場で使用されている技術知識を手に入れるために序盤でポストモーテムを読もうとあるのがわかりやすい。
障害対応は一番学びがあるものの、これをいきなり新人に実施させるのは大変だ。精神的な負荷もきついと容易に想像できる。
ポストモーテムであれば、障害に対する気付きと対策が記録されているのでキャッチアップが捗るはず。
なお、推奨パターンとアンチパターン表は参考になる。オンコールの演習をしようとすると、いきなり障害をぶつけて練習させようとしがちである（それが一番実践的と思うのはそう）。
けれど、理想的には練習環境であったり、そうでなくてもペアワークするなりしてクッションするほうが本人の負担軽減になる。 新人にいきなり戦場に行けという状況はなるべく避けるか、もしくは「あなたは一人ではない」という認識を付与してあげることが重要だろう。
引用: Table 28-1. SRE education practices ※日本語に読み替え
| 推奨パターン | アンチパターン |
|---|---|
| 生徒が従うべき具体的かつ連続的な学習経験を設計する。 | 学生を訓練するために下働き（例：警報・チケットのトリアージ）をさせる。"trial by fire（厳しい試練）"である。 |
| リバースエンジニアリング、統計的思考、基本原理からの作業を奨励する。 | 作業手順書、チェックリスト、プレイブックによる厳密な教育をすること。 |
| 失敗の分析を奨励し、学生に事後報告を提案する。 | 責任回避のために障害を秘密として扱うこと。 |
| 実際のモニタリングやツールを使用して学生が修正できるが、しかしリアルな壊れ方をした障害を作成する。 | 学生がオンコールになった後でないと、最初の修正の機会がないこと。 |
| グループでの理論障害のロールプレイングにより、チームの問題解決アプローチを交錯させる。 | チーム内に技術や知識が細分化された専門家を作ること。 |
| 学生がオンコールローテーションのシャドーイングを早期に行い、オンコール担当者とメモを比較できるようにする。 | サービスに対する全体的な理解を得る前に、一次オンコールに従事するよう学生を押しつけること。 |
| 専門家であるSREとペアを組み、オンコール研修プランの目標箇所を改訂する。 | オンコールのトレーニングプランを静的なものとして扱い、専門家以外には触らせない。 |
| 自明でないプロジェクトワークを学生に割り当て、スタックに対する部分的なオーナーシップを獲得させる。 | 新規プロジェクトの仕事はすべて上級のSREに任せ、下級のSREには残り物を割り当てること。 |
資料を踏まえて考えたこと
新しいメンバーが参画した際、伝えなければならないことは無数にあるように感じる。
- チームの働き方（大雑把）
- チームの目標
- 部署の目標
- アカウント回り
- メンバー相互理解
- ステークホルダーの把握
- 技術スタック
- ドメイン知識
実際はこれだけでなく、会社全体の研修があったりする。
一人のSREとして立ち上がるまで、本人も恐らく不安を抱いたまま進むことになる。 プロダクトチームであればgood first issueに着手してリリースするという流れで最初のcommitを完了させることができるが、SREグループでは必ずしもそういったissueがあるとは限らない。
メルペイtkuchikiさんの資料にもある通り、最初のマイルストーンをオンコールひとり立ちとすることで、以下のことが理解できるはずだ。
- 技術スタック
- ドメイン知識
- ステークホルダーの把握
方針
- まず一通り最低限の研修が完了するまで待ち、実際にプロダクトチームに参画となったタイミングで「オンコールひとり立ち」に関する目標を共有する
- オンコール担当は各チームでその週の担当がいるためプライマリで担当をすることはないことを伝える
- 実際の本番環境で作業するのは推奨されていないことを把握しつつ、しかし現実として練習環境を用意できていないことも伝える
- 異常系通知が来る前に、これまでのポストモーテムを一緒に読む時間を取る
- 進めながら各知識を収集してもらう
- カバーできてない手順や分かりづらい点はドキュメントを執筆してもらう（新規参画者にしかわからない新鮮な視点）
- ゴール！
「オンコール担当になれる」というのもなかなか曖昧なので、もう少し掘り下げて考えてみる
自プロダクトにおいてオンコール担当の責務とは
- 異常系メッセージを受けたら確認したというリアクションをつける（チーム文化）
- 調査開始できる場合はしている旨を表現する
- 調査開始できない場合はセカンダリにルーティングする（ステークホルダーの把握）
- 一次調査としてトリガーや原因となってそうな箇所を探す（技術スタック、ドメイン知識）
- すぐに対応すべきか判断する
- 緊急でないと判断した場合はチケット化
このあたりである。オンコール責務はチームによって異なるので、これは一例。
このようなことが担当できるようになれば完了としようではないか。
上記を実現するためにも、アカウント回りやポストモーテムは先んじて完了しておきたい。
おわりに
これはまだ、実際に運用していないので効果はどうなるかわからない。でもせっかくなので、考えたことは残しておいて半年後くらいに効果測定したい所存。
うちはこんな感じでオンボードしてるぞい、というのがあればぜひ教えて下さい
