SRE へのサポート移行で失敗しないために : CRE が現場で学んだこと
Google Cloud Japan Team
このブログ記事のパート 1 では、SRE チームが新規アプリケーションのサポートを担当するかどうかを判断するときのポイントについて説明しました。今回は、SRE のサポートによってサービスに大きなメリットが生まれると想定したうえで、そのサービスのサポートを SRE が自信を持って担当できるようにするにはどうすればよいのかを見ていきます。
サポート移行前のレビュー
Q : SRE がサポートを担当したほうがよいと思われる新しいアプリケーションがあります。とりあえず SRE チームに渡して、「はいどうぞ。これからこのサービスを担当してください。がんばってね」と言えばよいのでしょうか？すばらしい方法ですね。目的が失敗することである場合に限りますが。
最初の段階では、開発チームが考えるサポートの重要性や、アプリケーションがサポートできる状態にあるかどうかという判断は SRE チームの考えと異なることが多く、サービスのサポートを勝手に SRE チームに強要してもうまくいきません。
考えてみてください。このサービスに時間を割くことは有益だと SRE チームをまだ説得できていませんよね。人は、自分でこうだと信じていないものに対しては熱意を持って取り組めないものです。したがって、サービスの信頼性を実質的に高めようとしても、SRE チームが積極的に関与してくれない可能性があります。
Google の場合、SRE にうまくサポートを担当してもらうには、SRE チームがサービスを理解して評価し、事前に解決すべき重要な問題を見つけ出すプロセスがあるということを、サービスの所有者と SRE チームの双方が合意していなければならないと考えています（実は、Google Cloud のお客様のアプリケーションを Customer Reliability Engineering プログラムに入れるかどうかを決める際にも、同様のプロセスを踏んでいます）。
Googleでは通常、このプロセスを次の 2 段階に分けて行っています。
- SRE entrance review（SRE による事前レビュー）: 開発者がサポートしているサービスを SRE チームが担当すべきかどうか、また担当するにあたっての条件は何かを SRE チームが評価する。
- SRE onboarding/takeover（SRE への担当引き継ぎ）: SRE チームがサービス運用の第 1 責任者となることに開発チームと SRE チームの双方が原則として合意し、SRE への移行に備えて詳しい条件の交渉を始める（いつ、どのような形で SRE がサービスのサポートを開始するか、など）。
- 開発者はサービスのサポートを誰かに任せ、できるだけうまく稼働させたいと考えています。サービスが適切に稼働しているとエンドユーザーに感じてもらいたいためです。うまく稼働していなければ、ユーザーは別のサービスに移ってしまいます。
- SRE チームは、サポートしにくいサービスを押しつけられたわけではないことを示したいので、稼働中のサービスをより使いやすく強固なものにしたいと考えています。
- 企業の経営陣は、開発に時間をかけすぎない範囲で、サービスの停止といったみっともない事態の回数を減らしたいと考えています。
SRE による事前レビュー
SER（SRE entrance review : SRE による事前レビュー）は PRR（Production Readiness Review : 稼働準備レビュー）とも呼ばれており、この段階で SRE チームは現在稼働中のサービスを評価します。SER の目的は以下のとおりです。- SRE チームがサポートを担当することでどのような効果が見込まれるかを評価する。
- SRE チームが担当する際に障壁となるようなサービスの設計、実装、運用上の欠陥を特定する。
- SRE チームがサポートを担当したほうがよいという結論に至った場合、サポートを担当する前に修復しておくべきバグやプロセスの変更、サービス上必要な動作などを特定する。
SRE はサービスをありのままの状態で見定めます。パフォーマンスやモニタリング、関連する運用プロセス、最近発生した障害の履歴などを調べ、「いま自分がこのサービスの担当だとしたら、どの問題を修復したいか」を考えます。それは、1 日に発生するページ数が多すぎるというような目に見える問題の場合もあれば、1 台のマシンに依存しすぎていつか必ず障害を起こすというように潜在的な問題の場合もあります。
SRE の分析においてどの段階でも重要となるのが、サービス レベル目標（SLO）と、関連するサービス レベル指標（SLI）です。
SRE は、サービスが SLO を満たしていればアラートは滅多に発生しない、もしくはまったく発生しないと考えます。一方で、サービスが SLO を満たさない危険があるときは、アラートの音が大きくなり対応が必要だと考えるでしょう。こうした考えが現実と異なっている場合、SRE チームは SLO の定義や SLO の測定値を変更しようとします。
事前レビューにおける SRE チームの目的は、以下を把握することです。
- どんなサービスなのか。
- 日々サービスがどのように稼働しているか（トラフィックの変動、リリースの数、実験管理、設定のプッシュ配信など）。
- サービスはどういった状況下で停止する傾向にあるのか、それがどのようにアラートで示されるのか。
- モニタリングやアラートの粒度は均等に保たれているか。
- サービス設定において SRE チームのやり方と異なる点があるか。
- サービスにおける重大な運用リスクがあるか。
- サービスが SRE チームのベスト プラクティスに沿っているか、もしそうでない場合はどうやって改良するか。
- サービスをどのようにして SRE チームの既存ツールやプロセスと統合するか。
- 望ましい関与モデルと、SRE チームと SWE チームの責任分担はどうあるべきか。稼働中に重要な問題が発生してデバッグする際に、オンコール担当の SRE はどの段階で開発チームのオンコール担当を呼び出すべきなのか。
SRE への担当引き継ぎ
SRE による事前レビューでは通常、修復が必要とされるサービスの問題が優先順位別にリスト化されます。そのほとんどは開発チームが担当しますが、SRE チームが担当したほうがよい問題もあります。また、問題のすべてが SRE への移行にあたって障壁となるわけではありません（SRE が推奨する、サービス強化を目的とした設計やアーキテクチャ変更の中には、実装までに何か月もかかるようなものが含まれるかもしれません）。サポート移行のプロセスにおけるサービス改善の主軸は、実在するバグ、信頼性、自動化、モニタリング / アラートの 4 つです。それぞれの軸には、移行前に（障壁となる）解決すべき問題がありますが、一部には重要ではないものもあります。
実在するバグ
SRE への移行にあたって障壁となる主な問題は、以前のサービス検証時に対応すべき項目として挙げられたものであることが多いようです。SRE チームは最近の検証結果を踏まえたうえで、a）障害の根本的原因を解決するために提案された対応策が想定したものであるかどうか、b）その対応策が実際に完了しているかどうかを確認します。さらに、最近検証が行われていない場合は、SRE チームの多くはこれを警告と見なします。
信頼性
信頼性に関する変更のリクエストが SRE への移行の直接の障壁となることはないでしょう。信頼性改善の多くは、設計や大幅なコード変更、バックエンド統合の変更、必要のないインフラ コンポーネントの移行に関するもので、求められる信頼性確保に向けた長期的なシステムの進化を目指しているからです。
信頼性関連の変更事項の中で、移行の障壁になることがあるとすれば、大規模なダウンタイムの原因となることがわかっている問題を軽視したり取り除いたりすることや、将来的に停止の要因となることが予期されるリスクを緩和することです。
自動化
サポートを担当しようとする SRE が特に気にするのが自動化です。日々担当するサービスを運用するうえで、設定のプッシュ配信やバイナリのリリース、その他似たような時間のかかるプロセスにどれだけ手作業が必要かということです。
どれを自動化するのがよいのかを見極める一番の方法は、SRE が開発者の世界を実際に経験してみることです。つまり、開発チームの一般的な 1 週間の作業を真似てみて、オンコールに至るまでに日々の手作業がどれだけあるのかを SRE が体験するのです。
サービスをサポートするための手作業が大量にある場合でも、自動化によって問題はだいたい解決できるでしょう。
モニタリング / アラート
SRE への移行にあたって主な懸念事項となるのがページャーの呼び出し率です。つまり、就寝中のオンコール担当者を何度起こすことになるかということです。
Google では、「トレイナーの最大値（Treynor Maximum）」という指標に従い、12 時間のシフトの中でインシデントが（オンコール チーム全体で）平均 2 回となるようにしています。そのため、SRE チームは新サービスに対する過去 1 か月の平均的なインシデントの負荷を調査し、現在のインシデントの負荷にどう入れ込むのかを判断します。
ページャーの呼び出し率が異常に高い場合、その要因は一般に以下の 3 つのうちのいずれかでしょう。
- タスクの再スタートやディスク容量が 80 % に達したなど、本質的に重要でないことでもページャーが鳴ること。こうした場合、（重要でないものは）ページャーをバグと見なすか、完全になくしてしまいましょう。症状ベース（ユーザーが実際に問題に直面している、など）でモニタリングすれば、この状況は改善できます。
- 小規模なインシデントや停止によって多くのアラートが発生し、ページャーの嵐に見舞われること。1 つのインシデントに関連するアラートは単独の障害としてグループ化し、システム停止の指標を明確に把握しましょう。
- システムが真の問題を数多く抱えていること。このようなケースでは、すぐに SRE へと担当を変更することはないと考えられます。ただし、問題の根本的原因を診断し、解決することを SRE が支援できるかもしれません。
このほか、サービスを向上させる一般的な方法は以下のとおりです。
- ロード シェディングやリリース プロセス、設定のプッシュ配信など、標準的な SRE ツールやプラティクスをサービスに統合する。
- 開発チームの知識に依存しすぎないよう、戦略を充実させ改善する。
- サービスの設定を SRE チームの一般的な言語やインフラに合わせる。
スムーズな移行に向けて
SRE は開発者のサービスを理解する必要がありますが、SRE と開発者がお互いを理解し合うことも重要です。開発チームがまだ SRE チームと仕事をしたことがないのであれば、SRE チームは開発者に対して、モニタリングやカナリア リリース、ロールアウト、データ統合など、SRE に関するネタを簡単に説明するのもありです。そうすることで、なぜ SRE がそんな質問をして、特定の懸念事項についてうるさく言うのかを開発者は理解してくれるでしょう。ある Google の SRE はこう言っていました。「自分を開発チームの新人だと思って開発者と接するのがコツ。彼らにコードベースを見せてもらい、その履歴を解説してもらって、main() 関数の機能がどこにあるのかを見せてもらえばうまくいく。」
同様に、SRE は開発者の視点や経験も理解する必要があります。SRE による事前レビューの段階では、最低 1 人の SRE が開発者と行動を共にし、週会議や立ったままのミーティングに出席したり、オンコール担当時の作業を非公式に真似したり、日々の作業を手伝ったりすることで、サービスの全体像やサービスがどのように動いているかを把握します。
また、これによって両チームの距離も縮まります。Google では経験上、このレビュー段階で開発者と SRE の関係が改善されることもわかっており、事前レビューが終了してもこの状況を続けることがあります。
最後になりましたが、SRE による事前レビューの報告書には、SRE がサポートを担当することによってメリットが生まれるのかどうか、またその理由も（メリットのあるなしにかかわらず）きちんと書かれていなくてはなりません。
ここまで来れば、開発チームと SRE チームの双方が、SRE チームに担当を変更してサービスを継続させるには何が必要かをきちんと理解できているはずです。このブログ記事のパート 3 では、サポート移行の具体的な方法について見ていきます。
* この投稿は米国時間 6 月 29 日、Customer Reliability Engineer である Adrian Hilton によって投稿されたもの（投稿はこちら）の抄訳です。
- By Adrian Hilton, Customer Reliability Engineer
