SRE 11章
オンコール対応
オンコールとは
緊急事態の発生時に迅速な対応ができる状態で待機する、勤務形態のこと。
医療業界でも使われますね。
ITではインシデント(障害など)発生時に監視ツールなどからの電話アラート対応のこと。
- オンコール対応は、サービスの信頼性と可用性を保つためにエンジニアリングチームが行う重要な職務
- しかし、オンコールのローテーションと責任の構成には、サービスやチームにとって重大な落とし穴がある
そこで、GoogleのSREが発展させてきたアプローチと、それによって信頼性の継続可能な運用を保ち続ける理由を説明する
1.1 イントロダクション
- 勤務時間内、勤務時間外のどちらでもコールに対応できなければならない
- 従来では、専用の運用チームが対応してきた
- SREでは
- SREは、重要なサービスと信頼性に対して責任を負うのでSREチームが対応すべき
- 運用チームとの違いは、問題のアプローチにエンジニアリングの活用に非常に重きをおいているところ
- 前章で説明したようにSREは純粋な運用業務に費やす時間を50%という上限を設定している
- サービスの改善だけでなく、トイルの撲滅をしてチームの影響力を増加していきたい
11.2 オンコールエンジニアの日常生活
オンコールエンジニアはプロダクションの守護者
- 障害対応共にプロダクトの変更の実施、調査をする
- サービスによるが、問題解決までにかける典型的な時間は
- ユーザーが利用するシステムで時間に対する要求が厳しい場合は、５分
- それ以外で、要求が厳しくなければ、30分
- オンコールに対する1次反応は、サービスの可用性に関係する
- 例えば四半期に4ナイン(99.99%)の場合、停止時間は13分
- なので、数分以内に反応しないといけない
- ページ[1]が受信、応答されたら、オンコールエンジニアは問題をトリアージ[2]し、解決にむけた作業を開始
- 勤務時間内は、優先度の低いアラートやリリースを行う
- ページへの対応は、他のどのタスクよりも優先される
- 運用の負荷となる割り込みやその他の非ページング対応は29章で
- プライマリとセカンダリのオンコールローテーションをもつ。負担配分はチームによって異なる
- プライマリチームが見過ごしたページの受け皿をセカンダリチームが持つ
- プライマリチームはページだけを対応し、セカンダリは他のタスクを受けもったり
- 両チームがセカンダリオンコールを受け持つ
11.4 バランスの取れたオンコール
- オンコールシフトの質と量について制約をもっている
- 量は、費やす時間のパーセンテージで計算
- 質は、インシデント数で計算
- マネージャーは、負荷のバランスを取って、適切な量と質を保つ責任を負う
11.3.1 量におけるバランス
- 運用で50%なので、残り50%でエンジニアリングを行う
- 運用の割合
- オンコールは25%以上にならないように
- 他の運用業務を25%
25％オンコールルールを使えば、ローテーションを維持するのに必要な最低人数が割り出せる
- 常に2人がオンコールにあたるようにする場合
- 1サイトだけであれば、オンコールを担当するのに必要な最小人数は8人
- 週単位のシフトなら、毎月1週間をオンコール担当として受け持つ
- 2サイトに跨るチームの場合
- 最小人数は6人
- 1サイトだけであれば、オンコールを担当するのに必要な最小人数は8人
11.3.2 質におけるバランス
どんなインシデントの場合でも、対応とポストモーテム[3]の執筆に十分な時間をとるべき
- 下記対応に平均6時間
- 根本原因の分析と改善
- ポストモーテムの執筆などのフォローアップ
- バグの修正
12時間のオンコールシフトにおいては、1日にで対応できるインシデントは最大で2件
シフト中に発生する平均件数は2件以上の場合は、その他の部分でもいつかは障害が発生して
受け入れられる以上のインシデントを抱えることになる
四半期の間に超えてしまたっら、是正対応をすべき
11.3.3 補償
時間外のサポートに対して適切な補償をすべき
- googleの場合
- 代休時間
- 上限を設定して給与で調整
補償の上限は、オンコールの業務量
上限を設けることで、チームの負担を分散、作業配分のバランスを高め、エンジニアの疲労軽減を目的として
過剰なオンコール作業による潜在的なデメリットを制限する
11.4 安心感
人は困難に直面したときに選択する２つの考え方がある
- 直感的かつ反射的に即行動しようとする
- 理性的かつ集中を保ち、慎重な認識を働かせようとする
SREとしては、2を選択するほうが良い結果がでる
そのためにはオンコール担当者のストレス軽減が重要
インシデント対応は精神的負荷が高くなりがち
ストレスがかかっている時には、経験則の誤用に基づく行動をとってしまうことがある
- 同じアラートが4回発生
- 過去3回は、外部のインフラストラクチャが原因だった
- 4回目も、過去の原因と安易に関連づけてしまう
前述した１の「直感的かつ反射的に即行動しようとする」の選択の場合、欠点がある
- 直感の判断が間違っていることがある。データの裏付けが取りにくい
- 間違った判断のまま進んでしまい時間の浪費になる
- 習慣化すると大きな失敗を生む可能性がある
なので、理想のインシデント対応は、妥当な判断を下せるだけのデータが揃った時点で
適切なペースで手順を踏むこと
並行して、その推定と批判的に検証をすること
重要なのはオンコールを担当する負担を思ったより軽いものにしてくれるようなリソースがあること
- オンコールのリソース
- 明確なエスカレーションパス
- 他のチームへいつでもエスカレーションできるようにする
- 不明な部分が大きい深刻なサービス障害対応にて、適切なエスカレーションは理にかなっている
- しっかりと規定されたインシデント管理の手順
- 困難なインシデントに直面したとき規定に基づいた対応ができるようにする
- google内部では、WEBベースのツールがある
- 非難を伴わないポストモーテム文化
- インシデント発生時には、同じエラーが将来繰り返さない様にする
- 個人の非難をするべきではない
- ミスは起こるもの
- 明確なエスカレーションパス
11.5 不適切な運用負荷の回避
運用作業が50%を超えた時、どうなるのか
11.5.1 運用の過負荷
SREを過負荷になっているチームに一時的に貸し出すことがある
理想的には、過負荷にならないように目標の達成度を数値化できるように
過負荷の兆候を計測する
- 例えば
- チケット数 < 5
- アラート数 < 2
1時間毎に優先度の低いアラートが頻発するようであれば、オンコール対応の生産性を下げる
1つのインシデントに対して、受け取るアラートの数をコントロールすることも重要
- １つの異常が複数のアラートを発生させる場合がある
- アラートシステムの出力数を調整する
- 重複するアラート、対応不要なアラートは出力させないようにする
アラートとインシデントの比率は1:1に近づくようにすべき
SREチームのコントロール外で行った変更が過負荷を招く場合がある
- 例えば、アプリケーション開発者が影響範囲の大きい不具合を生む修正を行ってしまうことがある
- その場合は、システム改善を両チームの共通目標とする
- 極端な場合は、プロダクト開発チームに当該システムのオンコール対応を依頼する
- SREチームの基準を満たすまで[4]
- とはいえ、そんなに頻繁に行われるものではない
11.5.2 油断ならない敵：低すぎる運用負荷
システムがあまりにも静かすぎたり、オンコールが少なすぎるとどうなるか？
- プロダクトと関わりを持たない期間が長くなると、自信に関する問題が生じる
- 自信過剰 or 自信喪失どちらもあるが、インシデント発生時に知識ギャップの問題がでる
対応するためには、チームを縮小して、四半期に1~2回はオンコール対応するべき
まとめ
オンコール対するアプローチは、SREチームに対するガイドラインとなっている
高い可用性と信頼性を保つために必要な手段である
googleのアプローチがそのまま、全ての企業に適用できないかもしれないが
モデルケースになるものだと信じている
Discussion