11章 オンコール
2018/05/22
背景
- オンコール対応は、サービスの信頼性と可用性を保つためにエンジニアリングチームが行う重要な職務です
- しかし、オンコールのローテーションと責任の構成には、サービスやチームにとって重大な落とし穴があります。
- そこで、GoogleのSREが発展させてきたアプローチと、それによって信頼性の継続可能な運用を保ち続ける理由を説明する
イントロダクション
1.1イントロダクション
- ITの分野はオンコール担当専用の運用チームによって行われており、Googleも専用のSREチームがいる(Gmail, Ads..など主要)
- SREチームは純粋な運用のチームと大きく異るのは、問題に対するアプローチにおいてエンジニアリングの活用に重きをおいている
- (全作業時間のうち、SRE活動を50%以上 行い, 純粋な運用は50%以下になるようにしている)
オンコールエンジニアの日常生活
オンコールエンジニア = 本番システムの守護者
可用性: 99.99%
Googleの問題が起きてから治すまでの時間の典型的パターンは
* ユーザが使用するもの: 5分
* そうでない緩い所は :30分
もし、四半期に99.99%の可用性を達成しなければならないとすると...
オンコールエンジニアが察知してから治すまでたった 13分 しかない
そのため、ユーザ影響のある障害は
メール、SMS、その他アプリケーションなど複数のデバイスにアラートを受信してすぐに対応できるようにしなければならない
業務時間内
基本的な業務内容
* 優先度の低いアラートの対応
* ソフトウェアのリリース
* ...etc
しかし、これらの作業よりも障害対応が最優先される
(運用の負荷となる割り込み、その他のユーザ影響のある障害対応は29章で詳しく)
２つのチーム (プライマリ・セカンダリ)
アラートを受け取るのは プライマリ・セカンダリ の体制で行う
※ 必ずしも最初に取る、取りこぼした時の受け皿という物ではない
文献: The Practice of Cloud System Administration
２つのチーム (プライマリ・セカンダリ)
-- A --
* プライマリ: 一番最初に対応する
* セカンダリ: プライマリが取りこぼし時の受け皿
-- B --
* プライマリ: ユーザ影響のあるWebページの対応
* セカンダリ: 緊急ではない他の全ての対応
-- C --
* プライマリ: セカンダリの担当範囲の取りこぼしの受け皿
* セカンダリ: プライマリの担当範囲の取りこぼしの受け皿
11.3 バランスの取れたオンコール
11.3 バランスの取れたオンコール
オンコールシフトの量、質について固有の制約を持っている
* 量: オンコール担当に費やす時間の割合で計算
* 質: オンコールシフト中に生じたインシデント数
SREのマネージャはオンコールの負荷のバランスを取り、持続可能な状態を保つ責任を負う
11.3.1 量におけるバランス
SREの"E"は組織の特徴を定義しているもの
* エンジニアリング: 50%以上
* オンコール対応: 25%未満に、
* 他の運用業務: 25%
11.3.1 量におけるバランス
オンコールを25% = SREの最小人数が割り出せる
* 1つのサイトからなるチームのオンコール担当
* 1人1週間持つ
算出
* 稼働時間(12h) ✕ 30日 ✕ 25% = 90h
* オフ時間(12h) ✕ 30日 = 360h
* 360 / 90 = 4人
* 4人 ✕ 2 = 8人: (プライマリ、セカンダリ構成)
= 8人
11.3.2 質におけるバランス
オンコールシフトを受け持つたびに以下の時間が割り当てられるべき
* 根本原因の分析
* 改善
* ポストモーテムの執筆
それらの対応は 平均6時間 であることがわかった
つまり一日に最大二件まで対応可能
11.3.2 質におけるバランス
つまり...
if インシデント回数 / 一日の中央値 >= 2
許容以上のインシデントが発生
else
許容範囲内
許容以上なら、運用負荷を見直す必要がある
(11.5.1へ)
11.3.3 補償
11.3.3 補償
時間外のサポートは適切な補償を検討すべき
Googleではその補償に上限を設けている
これは、特定の人に対応が集中しないように分散するため
11.4 安心感
11.4 安心感
オンコール受け持つということは、
収益に直結したシステムやその他大事なものに
責任を持ち欠かせないもの
困難に直面した時人が選択する考え方
- 直感的かつ反射的に即行動しようとする
- 理性的かつ集中をたもち、慎重な認識を働かす
Q. 障害対応にはどちらが向いていますか？
A. サービス障害を扱う人は後者が良い
なるべく他のストレスをなくし、
障害に対して集中させなければならない
なぜ「直感的かつ反射的な即行動」はだめなの？
3回連続で発生したアラートが外部要因だった
さて、次飛んできた時
あなたは外部要因を関連付けたくなりませんか？
ストレス下では、特にその行動をとってしまう
オンコールの負担を軽くするリソース3選
- 1.明確なエスカレーションパス
- 2.しっかりと規定されたインシデント管理の手順
- 3.非難を伴わないポストモーテム文化
1.明確なエスカレーションパス
オンコールローテーションに加わる
↓
パートナーチームへエスカレーションはいつでも可能
(プライマリ・セカンダリ)
2.しっかりと規定されたインシデント管理の手順
複数のチームでの対応が必要なものほど複雑
14章で使用する「インシデントの管理」のプロトコルで定義されている手順
インシデント対応に集中できる
3.非難を伴わないポストモーテム文化
インシデントが発生した時、適切に評価し、
同じエラーが再現されないようにすることが重要
大きなインシデント → ポストモーテムを記述する
ミスは起こるものでり、
分析を行い、自動化を行うべき
11.5 不適切な運用負荷の回避
SREが運用業務に費やす時間は50%が上限とあるが
この上限を超えた場合はどうなるのでしょうか？
11.5.1 運用の過負荷
まず、
過負荷になっているチームにSREの人をレンタルすることはある
しかし過負荷を避けるためにレンタルを記録する
(例)
* 日々のチケット数 < 5 、
* 本番サイトのアラート数 < 2
一時間(それ以上)に飛ぶアラートが招く疲労
重大なアラートの対処に必要な注意を損なわせる原因になる
(29章で詳しく解説する)
複数のアラートが一つの原因であるなら、 アラート数を制限すべき
理想
インシデント:アラート = 1:1
運用の過負荷がSREチーム外が要因の場合
アプリケーション開発者と共同でシステム改善の共通目標を設定し、削減させる
最悪、「Webページ」そのもののオンコールをSREチームが行わないようにする
その代わり、アラートの一部や全てを期間を決めてオンコール担当に回すなど開発チームと交渉すると良い
それほどSREチームは過度な運用負担を負うべきではないが、
SREとプロダクト開発チーム間で発生する緊張関係 (第一章)
が起こらないようにすることが大事
Googleに大きな貢献になる
11.5.2 油断ならない敵: 低すぎる運用負荷
逆に運用負荷が低すぎるときは？
SREチームにとって望ましくない
プロダクトと関わりを持たない期間が長くなる
↓
自信がなくなる
全てのエンジニアが四半期に1or2回オンコール担当できるようにするべき
11.6 まとめ
11.6 まとめ
オンコールのアプローチ = Googleのガイドライン
Googleが高い信頼性、可用性を保つための
主な手段がオンコール対応である
ここで述べたアプローチはそのまま使えないかもしれない
けど、適応できる様なものだと信じています。