前回はSREのアプローチについて、学びました。
運用時に手作業で行っていた作業を行うシステムを構築することで、手作業のコストを軽減し、さらにプロダクト開発チームとの関係性が良くなる効果があることを学びました。
今回は、SERチームの信条についての説明になります。
SREの信条
それぞれのSREの状況に応じて、日々の運用は、異なりますが、中核的な信条は、すべてのSREに共通していると書かれています。
概して、SREチームは、サービスの可能性、レイテンシ、パフォーマンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任を負います。また、私たちは、SREチームはどのように環境とやり取りすべきか、業務規範を明文化しました。この環境には、実働環境のみならず、プロダクト開発チーム、テスティングチーム、ユーザーなども含まれます1
運用というと、サーバー管理のことばかりに頭が行ってしまいますが、他のチームやユーザーを環境の一部であると初めから受け入れておくとことは、運用面でも、システムを開発する上でもとても重要だと思いました。
もっと言えば、サービス自身にとっては、開発チームもユーザーもSREもすべて環境です。文句も言わずに動いてくれているサーバーのことをもっと考えるべきでした。
上では、SREの共通の信条が挙げられていますが、次からは、Googleにおける中核的な信条を見ていきます。
GoogleSREの信条
エンジニアリングへの継続的な注力の保証
これは、前回でも触れらていますが、運用システムの構築、そのためにリソースを費やすことを示します。
運用負荷を50%以下にする。超過した場合は、開発チームに差し戻すことことで実現しています。
サービスのSLOを下回ることなく、変更の速度の最大化を追求する
これは、前回挙げられた開発と運用の対立による間接的なコストに関係しています。このコスト解消の為にエラーバジェットを導入も行っています。エラーバジェットとは、エラーに対する予算であり、損失可能な信頼性です。この考え方は「100%の信頼性を目標とすることは、基本的にいかなる場合にも間違っているという所見から生まれたもの1」であると書かれています。
理由としては、可能性が100%と99.999%のシステムの違いを指摘できないからです。サービスとユーザーの間にはさまざまな他のシステムが存在し、0.001%の可能性を上げる労力はユーザーへほとんど利益がありません。
では、何が正しい信頼性の目標になるのでしょうか？
この問題は、プロダクトの問題で以下の点を考慮すべきであると書かれます。
- プロダクトの利用方法を踏まえて考えたとき、ユーザーが満足する可用性のレベルはどの程度か。
- プロダクトの可用性に満足できなかったユーザーにとって、どのような代替策があるか。
- 可用性のレベルを変更したとして、ユーザーのプロダクトの利用の仕方に何が起こるか。1
以前の回で、信頼性の適正な値はどの程度なのかという疑問を持ちましたが、上のような点を考慮して、算出すべきということでした。
モニタリング
従来のモニタリングでは、ある特定の値を閾値として、設定しそれを超えた際はメールのアラートを上げるという方法にしていますが、このような人間がメールを読み、何かしらの対応をするというシステムは、根本的に欠陥があると書かれています。
アラートのどの領域においても人間の解釈が必要であってはならず、ソフトウェアで解釈を行い、必要な時だけ通知を行う形であるべきだそうです。
効果的なモニタリングの出力には、3つの種類があると書かれています。
アラート：人間が即座にアクションを起こして対応し、状況を改善しなければならないことが生じている、あるいは生じようとしていることを知らせる
チケット：人間がアクションを起こさなけえればならないことを知らせます。ただしチケットの場合は、即座である必要はありません。システムが自動的に対処できない状況が生じているものの、人間が対応に数日かかったとしても、その結果障害が引き起こされることはありません。
ロギング：この情報を見る必要はないもの、診断もしくはフォレンジックの為に記録されるものです。ログは、何かが起きない限り、誰かが読むことは期待されません。1
内容に応じて、どのような通知形態をとるべきかという考えはなかったので、考える機会があるときに使っていこうと思いました。
また、何をアラートとすべきかは、システムによって、異なるかもしれないですが、それについても見ていこうと思います。
緊急対応
緊急対応は、人間の手が加わるほど、レイテンシが生じます。なので、人の手が介在しないシステムであれば、可用性が向上します。また、人の手が必要な場合でも、手順書を用意しておくことで、即興で行く場合よりも3倍の改善があるそうです。また、Googleでは手順書を用いた練習も行っているそうです。（やろうと思いますが、28章、遠い。。）
変更管理
SREはおよそ70%のサービス障害は、動作中のシステムの変更によって生じることを発見しました。
この領域におけるベストプラクティスは、自動化によって以下を実現することです。1
- 漸進的なロールアウトの実装
- 高速な正確な問題の検出
- 問題が生じた際の安全なロールバック1
変更管理に関するベストプラクティスの概要です。変更管理のみを扱う章もあるので、そこで具体的な考慮事項を学びたいと思います。（13章。。。）
需要予測とキャパシティプランニング
顧客が増加することによる自然な需要とローンチやマーケティングのキャンペーンなどの突発的な需要の双方を考慮して、プランニングを行うべきと書かれています。
キャパシティプランニングをSREチームが受け持つ理由は、キャパシティが可用性において、重要な要素だからです。可用性は信頼性に影響します。
プロビジョニング
プロビジョニングは、変更管理とキャパシティプランニングの組み合わせになります。キャパシティは、高価なので、必要な時に素早く、正確に行う必要があります。また、新しいキャパシティを追加した時、それが正しい結果を返すことを検証する必要もあります。
効率とパフォーマンス
SREはプロビジョニングを最終的にコントロールすることになるので、利用率に関係する仕事にも関わらなければなりません。1
SREは、需要を予測し、キャパシティをプロビジョニングし、ソフトウェアを変更できます。この3つの要素は、サービスの効率性の（すべてではないものの）大きな部分を閉めます。1
SREは、システムの一生を見守ることが必要なので、これもSREの役割の範囲となります。
この観点で、システムを見たことは、あまりなかったので、学びつつ、機械があるときに確認してみようと思いました。
また、どのくらいリソースが使われている状態が効率がいいと言えるのかについても今後見ていこうと思いました。
まとめ
今回は、SREが持つ信条、責任の範囲やそこで考えるべきことの概要についてみていきました。
今後は、それぞれの項目の詳細についてを学んでいこうと思います。
雑感
ようやくイントロダクションが終わりました。概要のみを一記事とする必要はないんじゃないかと途中思いましたが、今回はとりあえず一通りやり切りました。
毎日投稿のペースは、まだ掴めてないです。1日1記事+次の記事を最後までざっくり書くくらいじゃないと難しい。これを3時間くらいでできるようにするのを目標にしようと思います。
引用
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 7-12