midnight in a perfect world

webエンジニアのメモ

 「SRE サイトリライアビリティエンジニアリング」を読む。

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

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

 

 転職活動中も聞かれた一言「SRE的なことは出来ますか?」。勿論、やったことないけど興味ありますという回答しか出来なかったけど、当面インフラエンジニアとして生きていこうという現在、経験はなくとも設計思想だけでも脳内にインストールするために触りだけ読んでみた。さすがGoogleのエンジニアという感じで、地球上のあらゆるサービスがお手本に出来るような壮大なサービス設計の考え方や試行錯誤して作り上げてきた彼らのベストプラクティスを学べる。ちなみに、Borg(クラスとオペレーティングシステム)の子孫としてKubernetesがあるというのも初めて知った。500ページ以上ある大著で、まだ1/5位しか読んでないけどちょっとまとめておく。

・SREとは
ソフトウェアエンジニアに運用チームの設計を依頼した時に出来上がるもの。SREエンジニアのゴールは、サービスの取るリスクと、そのビジネスが許容できるリスクの歩調を意識的に合わせること。

→結構わかりみあった。IaCの思想にも通じるけど、いかにしてコードで運用体制や仕組みを表現できるか、という考えが強い。そして、サービスの可用性に関しても必要十分な体制を作るのが大事という。エンジニアリングへの継続的な注力の保証として、GoogleはSREが運用作業にかける時間に対して50%という上限を設けてるらしい。残りの時間はコーディングスキルを使うプロジェクトの作業にあてる。この位の配分を目指して日々タイムマネジメントしてなかなきゃね。

・エラーバジェットとは

「100%の信頼性を目標とすることは、基本的にいかなる場合でも間違っているという所見から生じている。」

本書の色んなレビューを観ても、この考え方がかなり学びになっている人が多そうな感じだった。勿論今の社内インフラを担当している自分としてもわかりみあるし。webサービスとしてのプロダクトの信頼性として100%を目指しても、ユーザとサービスの間に別のシステム(ISPとか、HWとしての端末とか、ブラウザとか)が介在しており、それらの総合的な可用性は100%にはならないから、SLAで提示した時間を満たせば、それ以外の時間はもっと積極的にサービス停止して、改善の時間に充てちゃおうという考え方。

例として、プロダクトマネージャがSLOを規定する。これは、四半期内に期待されるサービスの稼働時間を設定するんだけど、実際の稼働時間は、中立な第三者であるモニタリングシステムに寄って計測される仕組みを作る。この2つの値の差異が、「損失可能な信頼性」という「予算」の残分となり、余ってる時間は新しいリリースをプッシュしちゃえばいいじゃんという。現実的に、SLOは最初は緩めに設定して、後から徐々にきつくしていくのがやりやすいよねという。

・トイルの定義

SREエンジニアがなくしていくべき作業のこと。この辺の基準を常に頭の片隅に置いて作業していこう。

・手作業であること
・繰り返されること
・自動化出来ること
・戦術的であること
・長期的な価値を持たないこと
・サービスの成長に対してO(n)であること。→サービスの成長に比例するということ

・不整合のべき等な解消
「設定ミスを見つけ出すPythonユニットテスト」を「設定ミスを修正するPythonのコード」にすれば、バグをすぐに修正できるということに気づいた。→見つけてから人力で対処するより、そこまで自動化する方がいいよねという話。