ようやくSRE本を読み終わりました

はじめに

読み終わりました。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

英語の原著が出た時点でkindleで購入していたにも関わらず読み通せなくて、その後英語版は無料公開されました。

Google - Site Reliability Engineering

ほどなくして翻訳版が出て、読まないわけにはいくまいと購入。2ヶ月ほどずっとリュックやバッグにいれて持ち歩いていました。重かった。。。

SRE、信頼性エンジニアはGoogleで古くからあり、日本でもメルカリをはじめ、現在は様々な企業でSREポジションが存在します。（言葉だけ広がって流行っているとも、見える。）

GoogleのSREにはなれなくても、SREのような考え方を大事にする場所で働きたいと思います。せっかく読み通したので振り返りをしておきましょう！

まず、Google SREのコアな考え方は9章の第2部までに集中しています。まずはここをおさらい。

原則

エラーバジェット

Google SREの中でも大切な考え方の1つ。単純に、サービスが保証する信頼性目標(SLO: Service Level Objectives)を超えているのであれば新機能のリリースができ、下回っている場合は新たなリリースができないことを開発・運用双方で合意しています。

これによって新たなリリースという障害リスクを抑制することと、信頼性向上のための施策を行うことができます。

SLO、SLA、名前はあれどそれを明確に顧客と約束したり、計測して結果を振り返ったりすることは非常に難しい。そして計測しなければこのエラーバジェットによるリリース制約はできません。

SLOの指標

では何を指標にし、どう収集すればいいのでしょうか。

これは多すぎてもいけないし、見当違いのものでもよくなく、これを決めるのはかなり経験が必要ではないかと思いました。

また、「最初から完璧でなくてもよい」とある通り、継続的な見直し、修正が基本的な考え方なんでしょう。

トイル

これもSRE本での重要な考え方の1つ。本書によれば、

プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向を持つものです。(p51)

ここでもっとも重要なことは"作業量がサービスの成長に比例する"ということでしょう。単純な手作業だとしてもサービスの成長＝機能追加の数が増えるだけで、その作業は指数的に増えるかもしれません。

本書34章まとめで、SREの進化を航空業界に例える例がありますが、まさに「サービスが数百、数万のオーダーで成長しても、"同じ人数"で信頼性を維持することが、SREでもっとも重要な考え方の1つだと思います。そのためにトイルは絶対撲滅しなければなりません。

SREの業務

SREの業務はおおよそ以下の4つに分類できます。

• ソフトウェアエンジニアリング
  • コード作成や修正、ドキュメンテーション、設計、自動化スクリプト、ツール作成など
• システムエンジニアリング
  • システムの設定変更、システムに関するドキュメント作成。1回の作業で改善が持続するようなもの。
• トイル
  • サービスを稼働させることに直結している作業で、繰り返されたり、手作業だったりするもの
• オーバーヘッド
  • サービスを稼働させることに直結していない管理的な作業。採用、人事、ミーティング、バグ整理、レビュー、自己評価、トレーニング

なるほどこの4分割は、現状の自分の業務でも納得できます。（もっとも、これらに含まれない本当にやりたくない仕事もたまにあるが）

トイルを減らし、エンジニアリングの割合を増やすこと、これがSREがいる組織と、従来のDev & Opsが分かれている組織との違いですね。

モニタリング

レイテンシ、トラフィック、エラー、サチュレーションが4大シグナル。モニタリングの設計をした経験がないので、今後やる場面になったときにもう一度読み返したい。

自動化と自律性

7章、Googleにおける自動化の進化ですが、ちょっと内容かわかりづらいんですよね。

自動化の進化は以下のような経過を辿る。

1. 自動化以前
2. 外部でメンテナンスされるシステム固有の自動化
3. 外部でメンテナンスされる汎用の自動化
4. 内部でメンテナンスされる汎用の自動化
5. システムが自動化を必要としない

最終的には5、つまりシステムが自律的に問題を解決する(自動化した何らかの解決手段を必要としない)ことを理想としています。現実的に身の回りでは2か、頑張って3ぐらいですね。。。

例えば、今の職場では共通のSSL-VPN接続端末があって、そこを経由して検証環境につなぐのですが、最初は各クライアントで使うための自動接続スクリプトを作ったんですね。(2)　それを共通基盤として使うようになって、(3) 切断を検知して(よく切れる)自動再接続するようにしました。(4)　この順序は正しいですね。

リリースエンジニアリング

いわゆるCI/CDと言われている領域に近い話ですね。

哲学として高速性、密封ビルド(一貫性と再現性の保証)があげられています。

これは継続的ビルドとデプロイメントで紹介されているビルドの速度と、パッケージ化ですね。ubuntu系のdebやrhel系のrpmのようなパッケージシステムによって一貫性と再現性を保証します。

アプリケーションやインフラのソースコード管理、そしてビルド、デプロイの自動化は最近では当たり前のようにされるようになったと思いますが、設定管理はどうでしょうか。通常、ソースコード管理で管理しない、いわゆるconfigのようなところです。

本書でもバイナリ(と呼ぶ、アプリケーションをパッケージとしてビルドしたもの)と設定は別管理をするが、フラグを使ってひも付ける例があげられていました。例えばansibleのような構成管理のタグとrpmのバージョニングを合わせて管理するのがベストといえそうです。

実践編

ここからは実践編で、理論というよりはポエムとなります。googleの社内ツールの話は理解が難しかったのであまり深く読んでません。オンコール対応も(SREとしては重要な話ですが)現職ではそのポジションにないので飛ばしました。

中でも面白かった章を紹介します。

トラブルシューティング

トラブルシューティングって、みなさんどうやって習得しましたか。ぼくはいきなり障害番号投げつけられて「これ見て」からはじめました。ひどいよね。

今思えば当たり前のことですが、

• 一般的なトラブルシューティング手法の理解(すなわち、特定のシステム知識とは関係ない)
• システムに関するしっかりとした知識

この2種類あるが、それよりは、本来そのシステムのあるべき姿を知っていることが大事だと言います。本当にそうだと思います。

システムの本来の動きも知らない、一般的なトラブルシューティング手法も知らない、特定のシステム固有の話も知らない状態で振るなんて悪手でしかないので絶対に自分より下にはそんな思いをさせたくない。この章を2年前に読みたかった。

問題のレポート、トリアージ(システムがその環境下でできる限りうまく動作するようにすること、すなわち暫定対処や復旧のこと)、検証、診断、テスト/対処という流れでトラブル対応していくことになります。最初はこの流れすら知らなかった。のちに仮説/検証のサイクルで詰めていくことが大事と自ら学んだ。悪くない経験とはいえ、遠回りしてしまった。

この章はトラブルシューティング初心者にはかなりおすすめですね。

ポストモーテム

ポストモーテムも、SREとしてかなり重要なことですね。

しばしばインシデントはドキュメント化されるというよりは、報告が義務付けられるので、何らかの形で残ってはいるのですが、それを「次への学び」に活かすという視点での活用は今の職場にはないところです。

ポストモーテムで批判を行ってはいけないことは繰り返し述べられています。

「今月のポストモーテム」や「ポストモーテムニュースグループ」「ポストモーテム読書会」はすごいいいですよね。個人的にはやってみたいな、今のチームでできないか考えてみたいと思います。ちょうど勉強会やってるし。

データの完全性

特にバックアップとアーカイブの違いについてが面白かったです。アーカイブは完全に保管するものの、リカバリ2時間がかかってもさほど問題はないでしょう。逆にバックアップはリカバリが素早くできないのであれば意味がありません。ユーザから見て対象のデータが長期にわたって使えないのであればバックアップがあっても無意味です。それが「データの完全性は手段であり、目標とするのはデータの可用性である(p363)」ということでしょう。

そしてやはり重要な学びは"多層防御"でしょう。複数のレイヤーで可用性を確保しておかねばなりません。

そして必ずリカバリの検証をすること。「バックアップできてるはず」「リカバリできるはず」ではいけません。"願望は戦略にあらず(p387)"の通りです。

管理

4章ではSREの後継の育成や、割り込みと対処、SREチームと他の開発チームとのコミュニケーションなど、より人間的な面での実践アプローチが語られています。これも今後機会があったときに読み返したいです。

おわりに

何とか通読したものの、「ウォーこれはこういうことだったのかーこの考え方は大事にしよー！」ってものと、あまりピンとこなかったものがありました。自分自身の経験に合わせて再度読み返すときっと新しい気づきがあるでしょう。システムの信頼性に関することなら、何かしらのヒントがこの本にあるはずなので、壁にぶちあたったときに手を伸ばせるように手元に置いておきたい本です。

私個人としてもSREというポジションになりたいと思っているので、読み通したかった本がちゃんと読めて、こうやってブログで振り返れてよかったです。

直近の業務で活かすことといえば、インシデントを一手に受けているので、トラブルシューティングの一般化を後輩に伝えていくこと、勉強会を主催しているのでポストモーテム読書会はやりたいということと、モニタリングについて自分自身で設計したことがないので何かしらでやってみたいです。

さて、次は同じくUberのSREが執筆した「プロダクションレディマイクロサービス」も買ったので、読んでブログ書きたいと思います。

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化