SRE との “壁” を取り除くには : CRE が現場で学んだこと

今回の連載記事のパート 2 では、サービスのサポートを引き継ぐにあたって SRE チームが知りたいことは何なのか、引き継ぎまでにサービスをどう改善してほしいと考えているのかを説明しました。また、パート 1 では SRE が新しいアプリケーションを担当する（または担当しない）と判断するときの理由を挙げました。今回は、ページャーを担当することになった SRE とのやり取りについて見ていきましょう。

サポート担当の準備

このフェーズでは、開発者はやるべきことに対処し、SRE チームはサービスについて学び始めます。サービスに関する知識を身につけ、既存のモニタリング ツールやアラート、危機対処法などを学ぶのです。その方法は、以下のようにさまざまです。

• 教育 : 技術トークや討論会、“Wheel of Misfortune”（不運のルーレット）のシナリオなどを通じて、新サービスをチームの他のメンバーに紹介する。
• ページャー担当を少し体験 : 1 週間にわたって開発者とページャーを共有し、アラートごとにその重要度（ユーザーに影響を与える問題がサービスで発生していることを示すアラートかどうか）と、対応の可能性（オンコール担当者が問題を根本的に解決するにあたって明確な方法があるかどうか）を評価する。これにより、SRE チームはサービスの運用負荷がどれくらいなのかを定量的に測定できる。
• オンコールの同時担当 : オンコールの第 1 担当者である開発者と SRE を同時に呼び出します。この段階での緊急対応の責任者は開発者だが、開発者と SRE は協力してデバッグや問題解決に努める。

成功かどうかの判断基準

開発者と SRE チームがサービスの担当変更を合意するにあたっては、この変更が成功だったかどうかを評価する基準についても（その時間枠も含め）合意していなくてはなりません。評価基準には以下のようなものがあります（適切な数値も必要です）。

• 呼び出しの数や停止の数が絶対的に減少した。
• （拡張中の）サービスの規模や複雑さに比べて、呼び出しの数や停止の数の割合が減少した。
• グローバルにデプロイする新コードのテストに合格した時点から、時間や労力が減少し、ロールバックの比率は変わらない（または減少している）。
• （CPU、メモリ、ディスクなどの）予約済みのリソースを活用することが増えた。

ページャー担当を引き継ぐ

理論上は、SRE チームが事前レビューの段階でほとんどの課題を特定していたはずですが、サービスを実際に引き継いで担当してみないと見えてこない問題もあります。

中期的に見ると（1～2 か月）、SRE は、モニタリングやリソース消費などにおけるシステム上の欠陥や最適化できる部分のリストを作る必要があります。

このリストの一番の目的は、SRE の手間（手作業や何度も発生する作業、限定的な作業といった持続的価値のない作業）を減らすことです。また、2 番目の目的は、システムのパフォーマンスに影響を与えるようなリソース消費や雑な作りの部分などを修復することです。さらに、システム サポートの担当になった SRE の手助けとなるよう、ドキュメントを更新するといったことも 3 番目の目的として入れておくとよいでしょう。

長期的には（3～6 か月）、SRE は上述したような担当変更の成功基準をほとんど、もしくはすべて満たしている必要があります。

Q : すばらしいですね。これで開発者はページャーの電源を切ってもいいんですよね？

そんなに急がないでください。過去数か月にわたり SRE チームはサービスについて多くのことを学びましたが、まだ彼らはエキスパートではありません。サービスが不可解な動きを示し、オンコール担当の SRE ではどこに不具合があるのか把握できなかったり、修復方法がわからなかったりすることが必ず出てきます。

開発者の存在以上に頼れるものはないので、通常は開発者にもオンコール担当のシフトに継続して入ってもらい、必要に応じて SRE のオンコール担当者が開発者を呼び出せるようにします。ただし、呼び出しの頻度は低いと思われます。

ページャー担当を元に戻すという究極の選択

SRE チームが担当できるサービスの数には限りがあり、1 つのサービスが SRE の時間を大幅に消費してしまうと他のサービスにも影響が出る危険性があります。このようなときは、SRE チームは開発チームに対して問題を抱えていることを積極的に伝え、具体的なデータを示して次のように中立的に説明します。

過去 1 か月の間に S1 サービスには週に 100 回のページャー呼び出しがありましたが、その前の数週間は呼び出しの回数が週に 20～30 回でした。S1 は SLO の基準内に入っていますが、このように頻繁に呼び出されると運用作業にかかりきりになり、サービス向上のための作業が滞ってしまいます。そのため、以下のいずれかを行う必要があります。

1. S1 の変更率を減らし、S1 の呼び出し率を以前の値にまで下げる。
2. S1 のアラートを調整し、ほとんどのアラートは呼び出しがかからないようにする。
3. S2 と S3 のサービスについては SRE を担当から外し、全体の呼び出し率を一定に保つ。
4. S1 のサポートから SRE を外す。

運用負荷が正常値の範囲内であったとしても、開発者と SRE の双方が、開発者にページャーを返すほうがよいという意見で一致することがあります。たとえば、SRE がサービスのサポートを担当していて、開発者がそのサービスのすばらしい高パフォーマンス バージョンを思いついた場合などです。

この場合は、まず開発者が新バージョンのサポートを担当して不備を調整し、ユーザーを徐々に移行させます。最終的に新バージョンが最も安定して使用されるようになると、SRE が新バージョンのページャー担当となり、旧サービスのページャーを開発者に返すのです。その後、開発者はユーザーの移行を完了させ、都合のよい時点で旧サービスを停止させます。

SRE チームと開発チームの融合

開発チームは、SRE チームが何をしているのか、なぜそんなことをしているのか、また SRE の各個人についてもよく知ることができますし、SRE がなぜそのようになったのかを把握できるかもしれません。

SRE チームのほうも、開発チームの仕事や心配事などについて、より深く理解できます。共感する点が増えることはそれだけでも良いことですし、うまくいけばアプリケーションを改善するきっかけにもなります。

ここまで来れば、開発チームが新しいアプリケーションやサービスを設計するときには SRE チームも議論に参加してもらうよう招待するべきです。SRE チームは設計段階で信頼性に問題があることを簡単に見つけ出すでしょうし、開発者に最初からアドバイスもできます。アドバイスの範囲は、サービス運用の簡素化はもちろん、すぐれたモニタリングのセットアップや適切なロールアウト ポリシーの設定など多岐にわたります。

同様に、SRE が新たなツールの計画や設計に携わる際には開発者を巻き込むべきでしょう。開発者は今後のローンチやプロジェクトに関してアドバイスできますし、ツールの操作性やニーズに関するフィードバックを提供することもできます。

SRE チームと開発チームの間に大きなブロック壁が立っている場面を想像してみてください。サービス引き継ぎの当初のやり方は、サービスを壁の向こう側に投げて祈ることでしたよね。

今回の一連の記事では、壁に穴を開け、そこから双方向のコミュニケーションを通じてサービスを引き渡し、さらに戸口を開いて SRE が開発者の敷地に入り、開発者が SRE の敷地にまでやって来ることを説明しました。最終的に、開発者と SRE は壁を完全に取り壊し、低い垣根ときれいな庭のアーチに置き換えることになります。SRE も開発者も、お互いの庭で何が行われているのかを見えるようにし、必要に応じて相手側の庭に入っていく必要があるのです。

まとめ

引き継ぎのプロセスをじっくり計画しておけば、クエリも順調に流れ、ページャーも（ほとんど）鳴ることはないでしょう。

* この投稿は米国時間 7 月 7 日、Customer Reliability Engineer である Adrian Hilton によって投稿されたもの（投稿はこちら）の抄訳です。

- By Adrian Hilton, Customer Reliability Engineer