- 成功するSREチームは信頼の上に成り立つ。
- オンコール担当が、システム動作の理解/異常な挙動の診断/進んで助けを求める/プレッシャーの下でも対応できると信じる必要がある。
- 信頼の要求を踏まえると、技術的な教育以外に以下のようなことも考える必要がある。
- 新人がオンコールになる準備ができているかをどのように評価するか
- 新人の熱意や好奇心が既存のSREにメリットをもたらすにはどうするか
- 自分がどんな活動を行えば全員の教育に役立つか
- 学習者が学びたいことや方法はさまざまで、万能でベストな教育スタイルはない。
- GoogleのSREの推奨/アンチパターン
| 推奨 | アンチ |
|---|---|
| 具体的で順序立てられた学習体験を設計する。 | 下働きのような作業で手一杯にさせる。厳しい試練を与える。 |
| リバースエンジニアリング、基本原理に基づく作業。 | 運用手順、チェックリスト、作業手順書に厳密に従う訓練。 |
| ポストモーテム/障害分析の推奨。 | 非難を避けるためサービス障害を隠す。 |
| リアルな障害を発生させ、実際に修復させる。 | オンコールで初めて経験させる。 |
| 障害のロールプレイをして、複数のアプローチをチームで試す。 | チームで技術や知識が細分化されたエキスパートを作る。 |
| オンコールローテにシャドウで入り、ノートを比較する。 | サービスを理解する前に担当に入れてしまう。 |
| SREのエキスパートとペアで、学習計画の目的を見直す。 | 計画を分野ごとのエキスパート以外は変更できない決まりとして扱う。 |
| 単純ではないプロジェクトの作業を渡し、スタックの一部を受け持たせる。 | 新しい作業ははシニアSRE、新人は断片的な作業。 |
- SRE立ち上げの設計図(p413の図参照)
- オンコール担当は、新人SREのマイルストーン。ここを超えると学習は漠然とした物になり、自ら方向性を決めることになる。
- プロジェクトの作業担当作業は、小さく初めて時間と共に積み上げていくもの。複雑さを増しながら続けていく。
- 具体的な学習体験は、SREがオンコールを担当するようになるまでのすべての期間に渡って行うべき。
- 抽象的/受動的/実践的/能動的なものがあるので、幅広い学習様式をもっておくのが良い。
- SREチームは予防的な作業と対処的な作業を自然な比率で行い、予防的な作業により対処的な作業を減らしていくことを目標にしなければならない。
- 予防的な作業: 自動化、設計コンサルティング、ローンチ調整
- 対処的な作業: デバッギング、トラブルシュート、オンコールのエスカレーション
- 新人にも同様なアプローチがあてはまり、「厳しい試練」メソッドは最善なやり方とは言えない。
- 順序立てて積み重ねる学習の道筋:
- 学習の仕組みにはある程度の順序をもたせ、新人SREに道筋が見えるようにする。
- 意図的に理論と実践のバランスを取るようにする。
- 単純作業ではなく、目的のはっきりしたプロジェクトの作業を受け持ってもらう:
- SREは問題解決者なので、解決すべき問題をたくさん渡しましょう。
- サービスを担当していることを少し感じられるだけでも、学習には驚くほどの効果がある。
- 逆の視点からも、担当意識は経験豊富な同僚からの信頼を得るために役立つ。
- Googleでは新人に小さな初心者用プロジェクトを渡して経験を得る。
- SREが発揮しなければいけない特徴:
- 優れたリバースエンジニアリングのスキル: 見たこと無いシステムに出会うことになるため。
- 統計的に考える能力: 大規模な環境では検出が難しい異常が生じるため。
- 完全に臨機応変に行動: 標準的な運用手順が破綻することがあるため。
-
- 優れたリバースエンジニアリングのスキル:
- 自分の会社のシステムの動作の様子を最低限理解しており、デバッキングツール/RPCの境界/バイナリの出力するログを深掘りしてその問題を明らかにする意欲があれば、SREは予想外のシステムアーキテクチャ内での予想外の問題にも効率よく取り組めるようになる。
- 推論する訓練が未来の障害に対応する際の自然な行動の助けになる。
-
- 統計的に考える能力:
- 大規模なシステムのインシデントに対応するSREのアプローチは、巨大な決定木を辿っていくものと考えることができる。
- この能力は時間をかけて幅広いプロダクションシステムに対応して初めて得られる。
- とはいえ、新人SREが仕事に就いたらすぐに分析や比較をうまく行えるように訓練しなければならない。
-
- 完全に臨機応変に行動:
- 障害に対して手順を重視し過ぎて分析を怠ると根本原因を逃すことになる。
-
障害への渇望: ポストモーテムの読み込みと共有
- 過去を思い出せない者は、それを繰り返す運命にある。
- ポストモーテムはサービス障害の根本原因に、非難
を行うことなくたどり着く方法。
- ポストモーテムを最も活用するのはまだ雇われてすらいないエンジニアかもしれないことを念頭に置く。
- ポストモーテムは想像しうる将来の災害のシナリオを考える上でエネルギーになる。
-
ディザスタロールプレイング
- ゲーム感覚で仮想的な障害に対応するロールプレイをする。
- 新しいツール/小技/問題解決の新たな視点など誰もが何かを学べる。
- メンバーは、問題を出すGM/プライマリオンコール担当/セカンダリオンコール担当に分かれる。
- 問題は、最近のメンバーが関わってなかった障害や、みんなが忘れてる過去の障害などを用いる。
-
本物の破壊と修復
- プロダクションの破壊と修復に勝る経験はない。
- 可能であればステージングにリアルなユーザ/クライアントのトラフィックをかけると学べることがたくさんある。
-
師弟関係としてのドキュメンテーション
- 多くのSREチームでは、メンテナンスを受け持つシステムに関する技術や概念についてまとめた「オンコール学習チェックリスト」を管理している。
- このチェックリストを理解するまでオンコールのシャドウになることが認められない。
- Googleでは、チェックリストの古いセクションのオーバーホールを新人がしてシニアSREがピアレビューする。
- 学習者に対して早い段階からエキスパートとつながりが持てる。
-
早期からの頻繁なオンコールのシャドウイング
- 基礎を学び終えたら、業務時間内に限りページを新人にも転送しシャドウさせて、自信と信頼を築く。
- チームによっては逆シャドウも有効。
- 学習者はサービススタックのほとんどを苦もなく理解できるとこに到達し、臨機応変に進めるようになる。
- 最後にもう一度だけ学習者をテストして、オンコール担当としてチームで祝う。
- オンコール担当になってもサービススタックは変更され拡張されていくため、学習は続く。
- チーム全体として定期的な学習の機会を設け、サービススタックに対する変更や今後についてSREにプレゼンしてもらう。
- SREのトレーニングへの先行投資は、学習者にとってもチームにとっても価値がある。
- 本章の実践により、成熟したSREを素早く生み出しながら、チームのスキルを常に研ぎ澄ましておけるようになる。
- SREとして、マシンをスケールさせるよりチームメンバーをスケールさせなければならない。