Site Reliability Engineering: How Google Runs Production Systems の読書メモ
最近Site Reliability Engineer（SRE）という職種やチームがよく話題になります。当初は、コードをよく書けるインフラエンジニアがふつうにやっていたことに名前を付けただけと思っていましたが、Googleの出しているSRE本（Site Reliability Engineering: How Google Runs Production Systems）を読むと、考え方としても従来とは異なる面がありそうと思ったので、そのあたりをメモしておきます。主に1部のIntroductionと2部のPrinciplesを参考にしています。
SREとは
Site Reliability Engineeringとは
- ソフトウェアシステムのライフサイクル全体をカバーする分野。投入から運用、改良、退役まで。
- Software Engineering（≒ソフトウェアの設計から構築までをカバーする分野）との対比から。
Site Reliability Engineerとは
- 設計開発から構築までやるエンジニア。ソフトウェアも書くし、ロードバランスやバックアップの仕組みづくりもやる。
- 信頼性にフォーカスする。サービスの可用性、レイテンシ、パフォーマンス、効率性、変更管理、監視、障害対応、キャパシティプランニングに責任をもつ。
- ソフトウェアをより信頼できるものにするために、手続き、プラクティス、ツールを作る。ただし、これらが開発スピードを落とさないようにする。「システムのAgilityとStabilityのバランスを取る仕事」
Site Reliability Engineerのスキルセット
- Software Enginnerとしてのスキル
- UNIXシステム内部やL1-L3ネットワークの専門性
SREの考え方1: 開発と運用の時間配分
業務時間の50%以上は開発につかう。逆に、運用の仕事は50%までにする。そうなるように、自動化の仕組みを作る。結構シビアな数字らしく、運用が50%を超えるときは開発者に運用タスクを頼むこともある。
SREの考え方2: Error Budget
スピードを重視したい開発者と安定性を重視したい運用者の間の緊張はありがち。どれぐらい障害に備えるか、どれぐらいテストするか等の方針がぶつかりやすい。データを元にそこを判断するために、Error Budgetの考え方を導入した。
サービスのSLO (Service Level Objective)からError Budgetを計算する。SLOが99.99%ならError Budgetは0.01%。障害等があるとError Budgetが減っていく。これがなくならないうちは、リスクをとって早いペースでリリースする。なくなりそうになったら、テストや安定化に時間をかけ、リスクを避ける。
面白いのは、Error Budgetが全然減らないのを問題と考えるところ。Error Budgetが減らない → 品質に必要以上の時間をかけている → 他のことに使えた時間を無駄にした、という理屈。
Googleの場合、エラーは稼働時間で計算しないらしい。システムが地理的に分散しているので、時間ベースの指標だと正確な稼働率にならないため。代わりに、成功したリクエストの割合をつかう。
SREの考え方3: 自動化
5段階の自動化がある。単に自動化スクリプト作りましたというだけでは不十分。
- 自動化なし。手作業。
- 自動化スクリプトがある。でも個人が管理していて、他の人が使えない。
- 誰でも使える自動化スクリプトがある。スクリプトの作成はSREチームの担当。課題としては、開発チームとして自動化しやすいシステムを作る動機が弱く、自動化に関する技術的負債がSREチームに来やすいところ。また、他チームが入れたシステム変更をフォローして自動化スクリプトを更新していくのは大変。
- 自動化スクリプトがプロダクトの一部として同梱される（開発チームが自動化スクリプトを作成する）
- 自動化スクリプトの実行まで含めて自動化。システムが自分で問題に気づいて、自動で修正する。また、管理サーバがあり、そこからシステムの各種操作ができる。そのサーバはRPCインターフェースをもっていて、必要なときに他のシステムから叩ける。
本文には書いてないけど、AWSとかGCPのサービスは、5段階目に到達したシステムの例と考えてもいいのでは。
まとめ
GoogleのSRE本を読んだときのメモでした。内容も参考になりましたが、「できるだけがんばる」という考え方に陥りやすいところを、数値や体系を使って具体的な目標に落としていく姿勢が特にいいなと思いました。
