理系学生日記

おまえはいつまで学生気分なのか

「Site Reliability Engineering」を読んだ

Google - Site Reliability Engineering をようやく読み終わりました。 ぼくもいわゆる運用、保守にあたる業務をしていたこともありますが、それを踏まえると内容はすごく刺激的です。

訳本はこちら。

本の内容は、Google という世界最大規模のシステムを信頼性高くスケールする形で維持していくために、Google がどのようなエンジニアリングをしているのか、という話ではあります。

ただ、Dev と Ops の分断、リアクティブな対応しかできない体制、繰り返される単純運用と、巷の運用エンジニアが抱いているであろう問題を Google がどのように解決しているのかという観点で、 そのシステム規模に関係なく、いわゆる「刺さる」考え方がどこの章にも散りばめられていて、読んでいてすごく楽しかった。

実は内容として、ロードバランシングやリーダー選出アルゴリズムなど、技術的な内容も含まれていますが、どういう考え方で、どういうプロセスを組み、それを実現しているかという方が主体の本だと感じました。

世の中、運用に携わる人、SRE を名乗る人は多くいると思いますが、業務に鬱屈した思いを持っている人ほど読んだら良いんだろうなと思います。 ぼくも保守運用とかしていたときがありましたが、そのときに読んでたら、もうすこし違った仕事の回し方をしていたかもしれません。

もちろん、「自社ではこんなにうまくいかない」「社内事情がまったく違う」ってことはあるに違いありませんが、自分の目指すのがどういうエンジニアリングなのかというところに思いを向けるだけでも、 日々のモチベーションがまるで違ってくるんじゃないかなと思いますし、そういうキラキラしたところだけでなく、トラブルシュートの仕方とか、障害電話を受けるときとか、そのための教育とか、そういう ところもしっかり書いてあったりします。

SRE とは

まず Site Reliability Engineering、SRE とは何なのか、ということですが、一言で言うとソフトウェアエンジニアリングの知見を組み込み IT 運用の問題に適用するという考え方になります (wikipedia:en:Site_Reliability_Engineering より)。 そして、SRE に従事するエンジニアである Site Reliability Engineer の業務は、従来から言われているような運用業務とともに、ソフトウェア開発の専門知識を適用して、スケールしない業務をソフトウェアで解決することにあります。

印象的だったこと

SLO

計測可能で評価可能な指標がないと、物事は「Manage」することができません。 これ、あたりまえのことではあるんですが、その「あたりまえ」が「あたりまえに出来ないこと」があたりまえになっているところも多いですし、自分自身を振り返ってみても心が痛いかんじがします。

この本では、その SLO の決め方、気を付けることなどまで丁寧に説明していたりします。

また、そうやって定義される一指標である error budget の考え方も、今までの自分にはないようなものでした。

  • error budget は小さくすることが良いというわけではなく、使い切ってないからまだまだ「攻め」られるで
  • ユーザの回線品質がずっと低いんだから、サービスの可用性を 99.9999 % とかにしても意味ないやろ

みたいな。どうしても、値を向上すればするほど良いという感覚に陥りがちなんですが、メリット・デメリットあるんやから思考停止すんなや、みたいなかんじで頭を殴られたかんじがします。

Dev と Ops のパワーバランス

SREs には、いわゆる"オペレーション"には 50 % の時間までしかかけてはいけないという数値目標が掲げられています。 でも、対象とするサービスの品質がそもそも悪かったら、そりゃ障害対応だらけになって守るの無理やろってことよくあると思いますが、 50 % を超える状況になったら、開発チームにそれらの作業を移管するなど、SREs と開発チームが「双方で」守りつつ、イノベーションと信頼性のバランスを取る仕組みになっています。

「運用」チームってどうしても「開発」チームとは分断され謎の緊張関係を生じることが多くて、それがまぁ DevOps というところに繋がっていったと思うんですが、 SREs と開発チームとの間で、一緒に物事を進めていくための目標が設定され、両チームがそれを見つつ制御するように動け、それが守られる仕組み、パワーバランスが用意されているというのは、わりと制度設計の巧なんだろうと思いました。

他にも、SREs のレビューに耐えるサービスでないと SRE が引き継がないとか、単に引き継がないだけでなく、どうやったらそういうサービスにできるのかという 知恵を残りの 50 % で形にしているとか、チーム間の軋轢が生まれそうなところでそれがされないように作られているのって、働きやすさとしても素敵だなぁ…。