「SREって言葉は知ってるけど何してる人達なの？」
「SREとして業務を始めるけど何を目指していけばいいの？」
SREは他のエンジニアと比較して「考え方」が重要な職種であるように思います。正しい考え方で、正しい対応を取っていかなければサービスは死んでいき、エンジニアはすり減っていきます。歯止めをかけるのはSREです。
そんな正しい考え方を理解してもらうために、Googleが掲げているSREチームの信条をシンプルにまとめました。
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
※こちらの書籍からの要約になりますが、分かりやすさ重視のため表現を一部変えています。
クソシステムは開発チームに突き返す
私は「開発チームが運用チームへプロダクトを引き渡したらおしまい」なレガシーな会社に勤めていますが、Googleは違います。
Googleでは、SREの運用作業に掛ける時間が「全体の50%を超えてはいけない」という掟を定めています。
「SREは運用するのが仕事なんだから100%運用作業でいいんじゃないの？」
こんな風に思われる方はもういないと思いますが、SREの仕事では、その運用作業をなるべく軽減するツールを開発したり、デプロイ自動化を実装するなど、コーディングを伴う作業も非常に大切で、Googleでは、そのための時間を50%確保しています。
どうやって確保するのかというと至ってシンプルで、50%からはみ出した運用作業は開発チームにやらせるのです。そうすると、彼らは開発に専念できなくなるので初めから運用負荷を最大限に減らすよう努力してプロダクトを作るのです。
サービス障害をゼロにするは間違っている
世の中には「SLOは100%にするのが当然だろう！」と平気な顔で言うお偉方がおりますが、それはSLOを定義する意味を全く理解できておらず、「2つの理由」により根本的に間違えていると言えます。
1つ目は、SLOを本当に100%にしたところで大して意味がないからです。
ユーザがとあるサイトにアクセスするとき、スマホや家のWiFiなど別のシステムを経由することで可用性は99.999%よりはるかに低くなります。つまり、サイトの可用性を100%にしたところで、他部分のノイズに紛れてしまってユーザからは分からないのです。
どうせノイズに紛れて分からないのであれば、その0.001%高めるための莫大な努力をユーザに還元できる機能開発や改善に充てた方がハッピーでしょ？ということです。
ピンとこなければ、テストを例に出すといいかもしれません。
0点から80点をとるまでの勉強時間と、80点から100点をとるまでは同じくらいの時間がかかりませんか？私は実感としてあって、歴史で80点以上取るためには、教科書の太字じゃない人物も覚えとかないといけないんですよね笑
だったら、その時間を使って三平方の定理を覚え、数学の赤点を回避するという、もっと価値のあることができますよね。
2つ目は、SLOとエラーバジェットはセットで語られるべきだからです。
『エラーバジェット = 1 - SLO』
これが公式です。もし、SLOが99.99%であればエラーバジェットは0.01%になります。エラーバジェットとは、「そのシステムが使えなくなってもOKな時間」を意味します。エラーバジェットが0.01%であれば、月に4.3分はサービス断となってもいいんです。
このエラーバジェット、何に使うのかというと、機能リリースのリスク的予算にするのです。もし、バジェットが0.01%より大きければ機能をリリース、小さければバジェットが回復するまで待ちます。
機能のリリースにはリスクが伴うので、このようにして上手に可用性とリリースのバランスを取っているのです。
もしSLOが100%であれば、エラーバジェットは0%ですので永遠にリリースができなくなってしまいます。したがって、そんなSLOを定めているシステムは存在し得ないのです。サービス障害を0にする姿勢自体はとても大切ですが、現実的に考え、リスクと上手に付き合っていくことが結果的にはユーザ満足に繋がるのではないでしょうか。
バカアラートとスマートアラート
世の中には2種類のアラートがあります。
「バカアラート」と「スマートアラート」です。※私が勝手に名付けました
悲しいことに、世の大半のシステムにはバカアラートが仕掛けてあるんじゃないでしょうか。
バカアラートは、閾値超過や条件一致をトリガーにアラートを発砲します。しかし、この手のアラートは人間がメールを読み、アクションが必要か判断する必要があり、全くイケてないのです。基本的に、「人が判断できることはシステムでも判断できます」し、もし人間によって判断が異なるのであればそれは是正しなければなりません。また、「人間は慣れる生き物」なので同じアラートが3日連続で発砲されると「あ、またこれか」と対応を怠ります。4日目にはサービスに影響が出るかもしれません。
一方のスマートアラートは、システムの状態をソフトが解析して「人間がアクションを取らないといけないときだけ」アラートを発砲してくれます。だからといって、やばくなるまで放置かというとそうではなく、段階に応じて通知しシステムの傾向を教えるようにします。人間を夜中に叩き起こすのは本当に人間じゃないと対応できないときだけです。人に優しいシステムです。
Googleでは3段階で通知を分けています。
アラート・・・人間のアクションが今すぐ必要
チケット・・・人間のアクションが必要だが今すぐじゃなくていい
ロギング・・・人間は見る必要はないがもしものための記録
スーパーエンジニアより練られた1つの手順書
どこの会社にも「あの人がいなかったらうちは回らない」と周囲に一目置かれるスーパーエンジニアがいるかと思います。彼らは、いかなる時も冷静に状況を判断し、適切な対応で緊急事態を解決へと導いてくれるでしょう。
ただ、障害対応においては、スーパーエンジニアによる即興対応よりも、手順書に基づく平凡エンジニアの対応の方が「3倍も早く障害から復旧できた」というデータがあります。
「手順書がないからスーパーエンジニアのキレキレ対応が必要なんだろ！」という声が聞こえますが、全くその通りです。ですが、彼らが辞めてしまったらそれこそ問題ですので、普段から障害を模擬した検証を重ね、いざというときのために手順書やノウハウを温めていく営みが大切になります。
2つの成長に備えたキャパシティプランニング
サービスをローンチし順調にグロースしていくことを誰もが期待しますが、需要予測に基づくキャパシティプランニングをできていない組織は意外と多いようです。
キャパシティプランニングにおいては、「自然成長」と「突発的成長」の2つを考慮に入れておかねばなりません。
ユーザ拡大と機能拡充によって自然増加していくトラヒック（自然成長）は考慮していても、CMやキャンペーンの打ち出しによる突発的なトラヒック（突発的成長）に対しては見積もりが甘く、サービス影響が発生することも少なくありません。
これに対してGoogleはどんな画期的な対策を打ち出しているのでしょうか？
つまり、トラヒックとシステムが持つキャパシティとの関係を把握し、適切なタイミングで適切なプロビジョニングを実施するための最善策はあるのか？
答えは、「負荷テストを定期的にやる」です。
拍子抜けされるかもしれませんが、キャパシティプランニングに近道はなく、システムのキャパシティとサービスのトラヒックの関係を把握するために、定期的に負荷テストを実施し、プロビジョニングされたリソースが数カ月後、数年後のトラヒックに対応していけるのか（あるいは意図したようにスケールするか）、また、突発的な需要が見込まれるなら十分な可用性を担保できるのか、地道な検証によって材料を集めるしかないようです。
需要予測→プロビジョニング→検証→需要予測→プロビジョニング...
このサイクルを回しながら、サービス全体として、品質、スピード、コストのバランスを取りながらシステムや環境をコントロールしていくのがSREの仕事です。
さいごに
SREの思想は、サービスを開発するエンジニア、ひいては、非エンジニアまで関わる全員で共有しておくべき思想だと思います。サービスをこれから立ち上げる方はもちろんですが、すでに運用されている方もSRE本を輪読してみるのはいかがでしょうか。