SREって本当に素晴らしいですね！ これはSRE Advent Calendar 2018の19日目の記事です。
昨日はkazumax55さんのWebセキュリティ対策例でした。失敗談も踏まえた脆弱性診断の事例が紹介されていて学びがありましたが、個人的ハイライトとしては文面が全体的に紳士のように丁寧にも関わらず、唐突に出てくる「あざーーーす！！」の箇所から開発チームに対する絶大なHRTが感じられて良かったです。新規オープンされたと言うLaig(ライグ)と言うサービスもデザインがスタイリッシュで素敵です。
さて本記事では「SRE本の素晴らしさについて語ってみる」と言う題でつらつらと書きます。
SRE本とは
正式なタイトルは「SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム」で、原著が2016/4に、翻訳版が2017/8にオライリー社より出版されています。
内容としては副題の通り、世界でも有数なエンジニアリング組織であるGoogle社の中で提唱された"SRE(Sitre Reliability Engineering"と言うシステム管理とサービスの運用の方法論について、”SRE(Sitre Reliability Engineer)チーム”のメンバーが知見をまとめた物になっています。この書籍は日本では"SRE本"の通称で親しまれており、SREを学ぶバイブルとして今後も多くの方に読まれていくと思います。
SREと言う組織については国内ではメルカリ社、Cybozu社が早くから組織化しています。（特にメルカリ社は原著発売前の2015年代に取り組まれているところからもエンジニアリング組織としての感度の高さが伝わります)
SRE本との出会い
エンジニア界隈でSREが騒がれていることは感じつつも、私が実際にSRE本を手に取ったのは2017/12末でした。動機としてはパブリッククラウドやIaC(Infrastructure as Code)やDevOpsなどのワードが日々業界を席巻しているように感じ、インフラエンジニアとしてのキャリアに漠然とした不安を抱き、インフラエンジニアの上位クラス（と勝手に思ってたが誤解ですね）のSREについて正月休みに読んでみようと思ったからです。
結果、読み終わったのは3月の半ばでした。正直言ってSRE本、物理的に分厚いし内容も分厚いしで生半可な気持ちで読むことはできませんでした。購入された人の中で全部読み通した方の割合は決して高くないのではないでしょうか。"積ん読になりやすい技術書ランキング"があればまず上位に食い込むと思います。運用設計ラボの波田野さんが運用現場におけるSRE本の「正しい」読み方と言う素晴らしい発表をされていますが、"読み方"がテーマになるくらいにはヘビーな書籍です。
それでも素晴らしいので読んで欲しい理由
SRE本はヘビーなのですが、それでも運用に携わる全ての人にできる限り読んで欲しいと今でも思っています。その理由を書き出してみます。
SRE用語を知ることでSREと言う役割を知ることができる
何かを語るにはそれが何かを知る必要があります。逆にすれば言葉を知ることでそれを語れるようになり、理解できる(しやすくなる）訳です。SRE本ではSREを語るための多くの用語を学ぶことができます。数々の用語の中で個人的に印象深いものを挙げると以下になります。
- トイル
- エラーバジェット
- SLI,SLO,SLA
- ポストモーテム
- パーセンタイル
特にトイルとエラーバジェットは日常的な会話でしばしば登場するほどです。 退屈で繰り返しのある作業を"トイル"として意識することで「これはトイルだから改善しよう」という言葉にすることができ、それをチームで共有することができるのはとても価値のあることと実感しています。
"エラーバジェット"についても漠然とした「インフラエンジニアは絶対に失敗してはいけない（ただし人間は失敗する）」と言う矛盾した存在であることを理想として持っていた自分にとって、サービスの稼働率を定量化することで得た「チャレンジによる失敗のリスクのためのバッファ」と言う概念は青天の霹靂でした。
"SLI,SLO,SLA"もとても重要な気づきを得た言葉です。読み始めた当時、私はSLAは知っていても残りの二つは知りませんでした。このあたりの用語についてはGoogleCloudJapanBlogに大変良い記事がありますのでそちらもオススメします。特に「原則可用性は SLO を大きく超えるものであってはならないことから、SLA は通常、SLO より緩めの目標を定めます。」の下りはとても分かりやすい説明をしてくれています。
強いGoogleな人たちのノウハウを学べる
Googleでは...、Googleなら...と言った文脈は「そうは言っても自分たちはGoogleじゃないので人材も予算も規模も何もかも違う」と言うネガティブな言葉で流されてしまう事もありますが、それは実にMottainai事だと思います。
読みながら首がもげる勢いでうなづきながら読んだ章の一つに「29章 割り込みへの対処」があります。日々の運用をやる気を出して向き合えば向き合うほど新たな課題（改善点とも言える）の発見に繋がります。そして自分で増やした課題は並行したタスクとして襲いかかってくる事があり、運用負荷に押し潰されそうになる事がありました。29章では運用負荷にメスを入れ、気が散って全く進捗のないFredさんの例も挙げつつどのように対応していくかのメソッドが書かれており大変参考になります。（「一人で大変ならもう一人足しましょう」みたいな正論すぎだろって話もあったりしますが）
順番が前後しますが「28章 SREの成長を加速する方法：新人からオンコール担当、そしてその先へ」も非常に面白い内容となっています。SREとして活動するためにはどう言ったトレーニングが行われると良いかを知る事ができ、ポストモーテムを読む事で過去障害の内容を学び、ロールプレイングでそれを体感し、オンコールについては先輩SREとバディを組んで一人前を目指していくという道筋を知る事ができます。
ただこの本の重すぎる部分もノウハウに関してで、23章ではPaxosアルゴリズムを用いた分散合意と言った一般人にはヘビーな内容が出てきますが、無理せずスルーしていくことをオススメします。
SRE本を読んだ実績を解除することで自信を得る
見方によっては馬鹿げたことかもしれませんが、SRE本を読み、SREと言う役割について学んだ事実は少なからず自信に繋がります。それは言葉通りの「分厚い本を読みきった俺、えらい」と言う意味ではなく、今後SREとして活動して行く上で立ち帰ることのできる原点を見つける事が出来たと言う感覚でしょうか。
国内においてもすでにSREと言う言葉は広く認識されているように感じますが、SREを取り扱った書籍というのはSRE本と今年発表されたSRE WorkBook(未翻訳)の2つしかないように見えますので、SREの共通フレームワークとして機能していると感じています。上述した"SRE用語を知る" ことがこのSRE本一冊で出来てしまう訳ですね。本の選択で迷う必要は無いのです！＞＜
SRE本を読んだことで、自分で実践できた事
「XX本を読んだらYY出来ました！」という良くある煽りでは無いのですが、SRE本を読んだ事で自分に起きた変化について振り返ります。
粒度にこだわらずにCI/CDするようになった
CI/CDという言葉、それまでは大規模なシステムの開発、STG、本番環境における重厚なデプロイシステムみたいな印象を持っていましたが、今では「トイル撲滅システム」として些細なタスクの自動化にも意識的に適用するようになりました。結果として"ちょっとSSHして1コマンド打てば数分で終わるようなタスク"も、GitLabへPushすればテストとデプロイが自動で行われるようにすることで、利用者側に一任する事ができるようになりました。そもそも割り込みが発生しない状況を作る事ができたのです。 これは「トイル」という言葉を学び、日頃から意識する事で行えるようになったものです。
失敗を恐れないマインド（余裕）がより高まった
もともと停滞よりは変換を、既存よりは新規を選びたいというマインドは持っていましたが、失敗をして大きく凹むようなケースも多々ありました。エラーバジェットという考え方は、目標値としての安定性を達成できているのであれば、一定の失敗は許容する（むしろ改善のための変革に使う）と言う思考に繋がります。ここから「今回は失敗したがエラーバジェット範囲内なのでOK」と言う前向きに失敗する事ができるようになりました。心理的安全性を持った失敗というやつです。結果として気持ちの切り替えが容易になり、挑戦を恐れない精神状態を維持しやすくなりました。
まとめ
とりとめの無い感はありますが、SRE本の良さについて語りました。
SRE本は分厚いし高いし難しい（部分もある）しで手強い本であることは確かですが、学びの多い本である事も間違いありません。年末年始という節目のタイミングで挑戦してみるのはいかがでしょうか。（私も読み返そうと思います）
