SRE本 11章と28章には、ざっくり言って「オンコールは一朝一夕にはいかない。高度なスキルが必要だが、属人化してはダメだ」、ということが書いてあります。
他の章と異なり、この２つの章は人間味あふれる内容となっています。
この章について、その昔ソフトウェア製品の保守サポートを担当していた当時の記憶をたどりつつ、各セクションを見ていきたいと思います。
- 11章
- タイトル：オンコール対応
- 概要：
- オンコール対応のGoogleのSREチームに対するガイドラインが記載されている。
- 28章
- タイトル：SREの成長を加速する方法：新人からオンコール担当、そしてその先へ
- 概要：
- 新人をSREチーム要員としてトレーニングしていく過程や注意点が記載されている。その中で、オンコールを担当することが立ち上げの一つのマイルストーンとしている。
注：SRE本の内容を引用、意訳している部分はこの引用表記で示します
11章 オンコール対応
サービスの信頼性と可用性を保つために、オンコール対応はきわめて重要な職務。しかし、オンコールを属人的にしてしまうと重大な結果（トラブル）を招きかねない。本章ではGoogleのオンコールを実現するアプローチを説明している。
11.1 イントロダクション
オンコールは、勤務時間内と勤務時間外のどちらも対応できなければいけない
私が製品サポート要員としてオンコール対応していた（24H戦う）時代は、「過労」「ブラック企業」などの言葉はなく、勤務時間外であっても常時会社支給の携帯電話を持たされていました。
帰宅後、深夜・休日に関係なく、トラブル発生でのページ(呼び出し)が来ました。特に休暇を取得しているときに限って、重大インシデントが起こっていた気がします。
- 京都旅行での三十三間堂の拝観中に携帯呼び出し。当時のマネージャから「どうしてノートPCを持っていない！」と不条理なお叱りを受けました。
- 夏休みに登山し山小屋にいるときに連絡あり。オンコールチームでは対処できず、私の上司も右往左往しているような状況。クレーム元のインテグレータから何とかしてほしいと言われたが、その日は下山すると100%遭難する時間であったため、次の日の朝、予定を変更して下山。
- 伊勢のスペイン村でコールがあり、アトラクションの待ち時間や歩きながら数時間トラブル対応実施
このように、自虐的には「勤務時間内と勤務時間外のどちらもオンコール対応」できていました。しかし、超属人的な状況であったこともあり、これ以降見ていく、Googleの考え方はできていなかったと思います。
11.2 オンコールエンジニアの日常生活
- オンコールエンジニアの役割
- 担当サービスの障害対処
- プロダクトの変更の実施と調査- オンコールプロセス
- ページの受付（メール、SMS、自動コール、監視アプリケーション）
- 問題をトリアージする
- 解決に向けた作業を開始
- 他のメンバ支援要請、エスカレーションの実施- ページの受付がない期間（非ページングイベント）
- 優先度の低いアラートチェック
- ソフトウェアのリリース- オンコール対応のローテーション
- プライマリとセカンダリの要員分担を行う（その役割はチームで定義する）
私は、オンコールの担当でもありチームリーダでもあったため、オンコール対応を自分で定義し改善することは可能でした。工夫をしていた一例として、ページの受付があったら、メンバへラウンドロビン方式で単純にコールを割り当てていきました。はじめのうちは、担当によってさばききれないような事態も発生しましたが、メンバを崖に落として這い上がってくるような教育をしていたことになります。
11.3 バランスの取れたオンコール
11.3.1 量におけるバランス
工数のバランス
- 最低でも50%はエンジニアリングに費やされるように努める
- オンコールは、25%以上にならないようにする
- 残りの25%は、様々な運用業務に割り当てる
24/7 のオンコールローテーション体制
- １サイトの場合
- 常に２名体制（プライマリとセカンダリ）
- 最小限８名となる体制が必要
- (8H勤務, 24H7d/8H = 21コマ, 21コマ2名 = 42コマ/週, 一人当たり 5コマ(日)/人週, 42コマ/週 ÷ 5コマ/人週 = 約８人必要)
- ２サイトの場合
- 最少人数６名
- チームを大きくする場合はマルチサイトにすべき
- 健康を重視して夜間シフトを回避できる（地球規模のマルチサイトの場合）
問い合わせの量が多いからと言って、一般的には要員の追加は容易ではありません。人が増えればコストが増加するため、論理的な計算式での体制を構築することはできず、既存のメンバが神経をすり減らし、残業も増えて、ストレスを抱えたままオンコール対応せざるを得ない、というのが多くの場合だと思います。
11.3.2 質におけるバランス
インシデント対応に要する時間は平均すると６H → オンコールシフトにおいて対応可能なインシデントは１日当たり高々２件程度となる
将来、AIエンジンが進化し一定レベルのオンコール対応ができるようになれば、量が増えてもその対応の質は変わらないでしょう。
しかし、人間がオンコール対応をする場合は、間違いなく量が増えればその対応の質は低下してきます。
11.3.3 補償
時間外のサポートについて適切な補償（給与）をすべき
補償の枠組みがあることで、チームが必要とするオンコールの負担を分かち合う動機づけのみならず、オンコールの作業配分バランスを高め、過度の疲労やプロジェクトへあてる時間の不足防止に役立つ
業務時間外（自宅等）でのオンコール対応の「待ち時間」は、給与的な補償がなされていませんでした。にも関わらず、業務外でのオンコール対応をしている場合、精神的には休んでいる気がしていませんでした。
なお、2000年問題 の対応のため、1999/12/31 - 2000/1/1 の夜間、社内オンコール待機をしました。その際は、時間外手当以外に年末年始特別手当が少額ですが出ました。
11.4 安心感
困難に直面した時に人が選択する考え方は２種類
- 直観的かつ反射的に即行動しようとする
- 理性的かつ集中を保ち、慎重な認識を働かせようとする
後者の選択肢が良い結果をもたらすことは言うまでもないが、そのためにはオンコール担当のストレスを減らすことが重要。
ストレスは、恐怖感も含まれ健康を損なう。ストレスによって、思慮不足で軽率な行動となる場合がある。
重要なのは、オンコールを担当するという負担を軽いものにしてくれるような以下のリソースを準備すること
- 明確なエスカレーションパス
- しっかりと規定されたインシデント管理の手順
- 非難を伴わないポストモーテム文化
不安感や強いストレスは、どんなに強靭な人でも体や心を害すると思います。私は、一時期ですがある意味自己犠牲でオンコールを担当していました。昼夜途切れることがないコールの発生、大きい声のSIerからの叱咤、製品担当として、お客様に説明に来いと言われて問題解決するまで、データセンターに数日間「拉致」されたこともあります。
このような状況下で、出勤時に過呼吸となったり、不整脈が出たりと体のほうが音を上げてきました。このような状況になってやっと、当時の上司は負荷の低減を考えてくれるようになり、私はそれ以上おかしくならずにすみました。
この章の「安心感」というのは非常に重要ということです。
11.5 不適切な運用負荷の回避
11.5.1 運用の過負荷
理想的には、過負荷を避けるという目標の達成度を数値化できるように運用の過負荷の兆候を計測できるようにすべき（例えば日々のチケット数＜５、シフトごとのトラブル対応＜２など）
SREとプロダクト開発チーム間でオンコールの分担をし直しを交渉できるようなチーム間パワーバランスが保たれていることが重要
経験上、問い合わせとなる要因として、８～９割は利用者側のミス。その他は製品の制限事項に抵触、重大インシデント化するバグは1%以下という感じです。
とは言え、利用者ミスが多いということは、何らかミスを誘発するような問題がその製品・サービスに潜んでいます。例えば、ドキュメントのわかりにくさ、操作や手順の複雑さなどです。
11.5.2 油断ならない敵：低すぎる運用負荷
オンコール担当の頻度が低すぎる（低すぎる運用負荷）のも望ましくない
インシデントが生じてはじめて知識のギャップが表面化する
Google では、年に１度全社規模のディザスタリカバリトレーニングを実施している
理論的・実践的な訓練となっている
インシデントの発生は、自分で制御できないため、発生の数が少ないときは、「改善活動」を実施していました。
一番有益だったのは、トラブルを特定するための 「情報採取ツール」 の開発でした。それまでは、トラブルの原因を調査するため、電話やメールで、OSの設定情報やコマンド実行結果、アプリケーションのログなどの採取を依頼していました。この場合、SEが採取ミスをしたり、タイムリーな情報が得られなかったりしたのですが、「情報採取ツール」 を製品にバンドルし配布したことにより、大幅な対応時間の短縮が実現できました。
当時は、実システムからの情報収集についてそれほどうるさくなかったので容易に機微なデータを得られたのですが、現在は、個人情報を含めて、情報の収集は難しいものと思われます。
28章：SREの成長を加速する方法：新人からオンコール担当、そしてその先へ
成功するSREチームは信頼の上に成り立つ
SREのトレーニングへの先行投資は、間違いなくその価値がある
SREとしてマシンをスケールさせるより速くチームメンバをスケールさせなければならない
28.1 自分の後継SRE（たち）を雇用した後にすべきことは？
ある一定レベルのスキルを持たせるために何をすればよいのか
画一的な教育メニューでは、多様な新人への対応はできない。ベストな教育メニューというのは存在しない。Googleでは、SRE教育のパターンとアンチパターンを定義していて、新人の特性に合わせてパターンを選択している。
図28-1のような、横軸（抽象的－実践的）、縦軸（時間軸）で書かれている新人立ち上げの設計図は、たぶん私も脳内で意識していたと思います。しかし、「オンコールを担当」というレベルに達しているかどうか、そのステップを踏めているのかは把握できていませんでした。このような定義をもっと早く見ていれば、もう少しスマートに後進の教育ができたと思います。
28.2 初期の学習経験：混沌ではなく構造を提供する
SREチームは予防的な作業と対処的な作業を自然な比率で行う。予防を重視して対処的な作業を減らすことが目標。これは新人に業務へ入ってもらうためのアプローチも対処を減らすことから入ってしまう。これは、「厳しい試練≒プールの深いところに放り込む」ことになる。這い上がってくる人もいるが、疎外感から離脱する人が多くなる（自信を失う）。
順序だてず目的も不明確にトレーニングすると、以下のような疑問を抱くだろう
- 私は何の作業をしているのだろう？
- 私はどれだけ前進できているのだろう？
- オンコールを担当するのに十分な経験を積むには、この活動をどのくらい続けなければいけないのだろう？
過去、新しく入ってきたメンバに上記のような疑問（不安）を持たせていたと思います。言い訳になりますが、トレーニングをしてあげる暇はなく、見よう見まねで覚えてくれ、という状況だっとと思います。
28.2.1 順序立てて積み重ねる学習の道筋
学習の仕組みには順序付け、新人に道筋が見えるようにすること
意識的に理論と実践を適切に組み合わせてバランスをとること
早く実践的な体験も積ませるべき
28.2.2 単純作業ではなく、目的のはっきりしたプロジェクトの作業を受け取ってもらうこと
解決すべき問題を実際に経験させましょう！
28.3 優れたリバースエンジニアリングと柔軟な思考の育成
28.3.1 リバースエンジニアリング：システムの動作を理解する
エンジニアは、システムの動作の様子に好奇心をそそられるもの
好奇心の意欲から、予想外のシステムアーキテクチャ内での問題にも効率的に取り組めるようになる
私は、元々ソフトウェア開発者でしたので、サポート担当の製品のバグは、ソースコードを追って問題を見つけることができました。しかし、他社からのOEM 製品をサポートするようなときは、外部仕様から内部実装を想定するようなことが必要でした。このような探索を好奇心持って行うことで、トラブルが発生した際、問題個所の「におい」をその製品の特定箇所から感じることができるようになってくると思います（これも超属人的なスキルです）。
28.3.2 統計的及び比較的思考：プレッシャーの下で科学的手法の活用
大規模なシステムのインシデントに対応するSREのアプローチは、目の前に広がる巨大な決定機をたどっていくもの
それを限られた時間の枠の中でいくつかのアクションを選択しなければならない
これらの要素をすべてコントロールし分析と比較を行うことがSREチームの役割
新人に対してすぐに分析や比較をうまく行えるように訓練しなければいけない
オンコール対応時は、日に１００件以上のメールが届いていました。コールが少ないうちは、１件ごとMS-Access のレコードとして手動で登録をしていましたが、数が増えることで現実的ではなくなりました。そのため、メールワイズというソフトウェアを購入して、メールの管理を行うようにしました。これにより、担当者以外（特に新しく入ってきたメンバで）も過去の記録を検索することができるようになりました。
28.3.3 即興の芸術家：予想外の事態への対応
SREが陥りかねない分析的な罠がたくさんあることを踏まえて「ズームアウト」して解決に向かうアプローチを取る、ということを早い段階で学ぶ価値のある点
28.3.4 総合的なトレーニング：プロダクションサービスのリバースエンジニアリング
リバースエンジニアリングで学習者が微妙な詳細をいくつか見落とすことがあるが、そこからたくさん議論が生じる
この訓練からシニアSREも何かを学ぶことができる
28.4 上を目指すオンコール担当者のプラクティス
オンコールを受け持つことができる ≒ 十分な知識を持ち、その知識の範囲外のことも解き明かせる
インシデントを投げてきた問い合わせ相手の逆鱗スイッチを入れる可能性がある、ワードや対応内容は以下のようなものです。
- 仕様通りです
- 製品の仕様通りなので、問題事項は「運用でカバーしてください」と回答
- 限りなくバグに近いことでも、製品担当からするとその仕様で開発している、ということが相手に伝わってしまう
- 数百ページもあるマニュアルの中に注意事項が記載してある
- 再現待ちとさせてください
- 製品側では再現ができない言い訳（ユーザ環境と完全に同じ状態にすることは不可）
- 次に問題が起こった場合に収集する情報を示すが、それでも原因不明となってしまう
- 問い合わせ内容に対して一問一答する
- 聞かれていることの本当の意図を読まずに聞かれたことだけに回答する
- 無応答（催促されるまで返答なし）
- TATの管理ができておらず、as-isでインシデントの対応をしてしまう
28.4.1 障害への渇望：ポストモーテムの読み込みと共有
ポストモーテムは、想像しうる障害の災害シナリオを考えるうえで素晴らしいエネルギーにもなる
私の組織体でもインシデントに対しての原因分析、根本分析、直近の対応策、恒久的な改善策などを作成する必要がありました。しかし、次のようなことから、過去には非常に後ろ向きな対応となっていたと思います。
- 個人やチームの非難を行う体質（責任を擦り付け合う）
- できそうな対応策や改善策から原因を作り出す、という意味のないことを行っていた（根本原因を明確にすると、とてつもない対応工数がかかる可能性があるため）
- 品質管理部門の発言力が大きいため、報告のための報告となってしまう
ポストモーテムは、人の非難に使ってはいけない（SRE本１５章）。１５章について、別途考察してみようと思います。
28.4.2 ディザスタロールプレイング
ディザスタRPGがうまくいけば、だれもが何かを学ぶことになる。
- 新しいツールや小技、問題解決の新たな視点が得られる
- その問題解決ができた、ということでチームに承認が得られる
28.4.3 本物の破壊と修復
Google では四半期ごとにこの訓練を行い、未知のバグをあぶり出している
28.4.4 徒弟関係としてのドキュメンテーション
変化の激しい環境では、ドキュメントはすぐに古くなってしまう
新メンバには、最も古くなっているセクションをオーバーホールしてもらう
ドキュメントが古くなる、というのはその通りです。昔は、MS-WordやExcel でドキュメントの作成を行っていましたが、最近は、気が付けばすぐに変更が可能なようにWikiなどでの情報共有を採用しているPJが多いと思います。
28.4.5 早期からの頻繁なオンコールのシャドウイング
業務時間に限り、受信したページを新人にも転送する（好奇心を刺激する）
この「シャドウ」オンコール勤務の効能
- オンコールの責任認識
- 学習者としては時間的なプレッシャーを受けずにすむ
- リアルタイムで最前列に座ってサービス障害が明らかになっていくのを見ることができる
ミッションクリティカルなシステムで発生したバグに対して、その日の定時後に、お客様から明日の朝のシステム開始までに直してください、と言われるような対応をしたことがあります。
- バグの原因が判明していた場合
- 要求通り、修正を行い提供する（ただし、社内の品質管理手順を取ることができない）
- （実際は修正可能であるが）朝までには提供できない、正しいプロセスを経て提供できる時期を調整する
前者の場合、必要な品質プロセスを経ないでリリースすることで、さらに最悪な事態に陥ることが考えられ、問題が拡大することが否定できません。
私の場合は、正しいプロセスを通しながら、要求通りに朝までにリリースしました。この際、品質管理者、製品のリリース責任者など、緊急な招集を上層部間が調整して特別対応を行いました。
28.5 オンコールの担当、そしてその先：通過儀礼と継続的な教育の実践
学習者がオンコールを受け持つことができた、という通過点を明確にすべき（そして祝うべき）
オンコールの地位に加われば終わりではない。チームの運用上の知識は歴史の遺物になっているかも
学習を継続し、その内容をSREにプレゼンしてもらいましょう
SRE本１１、２８章は、サービス提供インフラなどのオンコール対応ですが、20年以上前の製品サポートでのオンコールの経験をもとにコメントを記載してみました。
製品サポート対応は、営業・SE・開発と比べると地味で目立たない存在です。しかし、いざ事が起こるとこのSRE本セクションに記載されていたプレッシャーの中、「信頼性」のため戦います。このようなオンコールの仕事を属人性でカバーすることなく、本セクションのプラクティスを参考にしながら、対応できるとよいと思います。