SRE book から学んだことと、献身と愛情、2018 年の行動指針について
Tweet
📕 SRE book を読んだ
SRE という肩書で仕事をしはじめてそろそろ 2 年たとうかというところで、いつか読もう読もうと思って読んでいなかった Site Reliability Engineering、いわゆる SRE book の日本語訳版を年末年始にかけて読みました。
オライリージャパン
売り上げランキング: 8,696
SRE という肩書で業務に取り組んでいる人はもちろん、そうでないインフラエンジニアやサービス開発に取り組んでいるエンジニアの皆さんにも、ぜひオススメしたい一冊です。わたしは最初から最後まで通読しましたが、章ごとに扱っているテーマは分かれているため、興味のある章を拾い読みするのもよいでしょう。一部他の章の知識が必要なところもありますが、そのような章へのリファレンスがキチンとついているので良心的なつくりになっています。
💡 どのような事柄が学べるか
この本がカバーしている内容は非常に広範です。まず「Google における SRE とはなんぞや」というところから始まり、サービスレベル目標、トイルの撲滅、サービス開発チームとの連携の仕方、従来の運用を中心とするチームとの違いといった文化的、マネージメント的な側面から、リリースエンジニアリング、モニタリング、Paxos (とその変種) や Raft などの分散アルゴリズムの概要と分散システムの運用、オンコール、インシデント対応およびカスケーディング障害への対処方法、人を非難しないポストモーテム文化の重要性、データの完全性・可用性の考え方まで、非常に幅広いテーマを扱っています。
章ごとにエモさが中心のものと技術的な解説が中心のものがあります。ここでは、エモいパートを読んで 2018 年のやっていきが膨らんできたこともあり、その気持ちを文章として記録しておこうと思います。
👷♀️ Google における SRE とは?
従来の運用を中心としたインフラエンジニアの集団ではなく、徹底した自動化と高度なインフラ基盤や開発基盤を作り上げるなど、人間はスケールしないという問題を乗り越えて、エンジニアリングによって安定したサービス運用を実現するエンジニア集団です。といっても緊急対応のオペレーションはどうしても発生しますし、サービスのローンチから関わる場合にはアプリケーションのコードを書くこともあります。
🐰 SRE book とわたし自身の経験を照らし合わせて考えたこと
ここからは、SRE book に書かれていることと、わたし自身の経験に照らし合わせて、考えたことや想いをつらつらと書き綴っていきます。
チームや組織の在り方によってベストプラクティスは変わってくるので、本の中で出てくるすべての事柄が Google 以外のチームに適用できるというわけではありません。しかしながら、その内容は新たな気付きに富むものでした。
50% の時間をエンジニアリングにあてる
興味深いのは、Google の SRE の基準では就業時間の最低 50% はエンジニアリングにあてるように、日々仕事に取り組んでいるそうです。
「50%? 思ったより少ない..? わたしももっとやってる気がするし、天下の Google のエンジニアならなおさら..」
というのが、わたしの最初のナイーブな感覚でした。
この感覚が正しいのかどうかを確かめるために、試しに新年明けてからの業務において、「これはエンジニアリング」「これはエンジニアリングではない」というように、進めている作業をハッキリと分類して意識するようにし、日報に書いていくようにしました。
その結果、一日あたり 50% 以上エンジニアリングに充てられたと確信できた日数が、そうでない日数よりも少ないことに気づきました。思っていたよりもエンジニアリングにあてている時間が少なかったのです。
SRE book では トイル という概念が紹介されており、以下のような特徴を持つタスクである、とされています。
- 運用に関係する作業である
- 手作業で繰り返し行われる
- 自動化できる余地が十分にある
- 長期的な価値をもたらすものではない
- 作業量がサービスの成長とともに比例して増えていく
トイルを放置していると、サービスの成長とともに人員の数を増やさざるを得なくなり、それにはいつか限界がきます。チームがスケールしなければ、トイルをこなすことに追われてしまい、人間が必要な知的で本当に価値のある仕事をすることができません。
先ほど思ったよりエンジニアリングができていないことに気づいたと書きましたが、わたしも例外ではなく、意識していなかっただけでトイルは確実に存在していて、思っていたよりも時間を奪われていたのでした。
開発チームと対等な関係で緊密に連携するということ
Google ではエラーバジェットという考え方で開発チームとの対等な関係を維持しているそうです。エラーバジェットとは、1 - あるサービスの SLO (サービスレベル目標) で表される数値です。もし SLO が 99.99% ならば、エラーバジェットは 0.01% ということになります。
エラーバジェットとは、すなわちどの程度エラーやインシデントによる計画されていないメンテナンスを許容するかということです。エラーバジェットが残っている限り、開発チームは新しい機能をリリースしてよく、もしエラーバジェットが尽きてしまったら、新しい機能のリリースは禁止となり、システムを安定化させることに注力することになります。
ここで興味深いのは、エラーバジェットによる対等な関係を築いていることはもとより、開発チームの一部のメンバーもサービスのオンコールローテーションに加わることがある、ということです。エラーバジェットが尽きた際には、場合によってはページャを開発チームに返すこともあるそうです。
わたしの所属している SRE チームでは、プロダクション環境は原則として SRE チームがすべて預かっている状態です。わたしが現 SRE チームに加わった当時からそのような体勢であったため、そもそも開発チームがオンコールに加わるという発想がとても新鮮に感じられました。このような体勢にすることで、サービス開発者の運用面への意識が高まるという効果もあるそうです。反対に、SRE がアプリケーションコードの改修やアーキテクチャの再構築によってパフォーマンスを改善する、というようなことも積極的に行われているそうです。
SRE book を読みながら、わたしの所属する SRE チームは、Google の SRE チームのように開発チームと緊密に連携できていないのではないか? と考えるようになりました。開発チームと SRE チームの間には、普段誰も声を出して言わないものの、見えない壁のようなものがあるのではないか、と。
風のうわさで聞こえてくる「インフラ部や技術基盤のメンバーに相談するのは恐れ多い感じがする」という声や「ある問題を解決するために、インフラ部に相談を持ちかけるのにコストがかかるし反発されそうなので、そうしなくてもいいような対応でお茶を濁すこともある」といった本音があることから、この直感はおそらく正しいです。
良い SRE であるために、プロダクトと開発チームへの献身と愛情
この際なので大真面目に断言して気持ちを表明しますが、ひとりの SRE として成果を出して組織やプロダクトに貢献するための鍵は、プロダクトと開発チームへの献身と愛情だと考えていて、今年は献身と愛情の精神を軸に様々な改善に取り組んでいこうと考えています。そして、SRE チームとしてもそうあるべきです。
そうして開発チームとより近い場所でプロダクトのパフォーマンス改善や運用の省力化に力を注ぎ、その一環で出てきた技術的課題を、共通のプラットフォームや社内ツールの作成、便利ライブラリの作成のようなエンジニアリングで解決していくべきです。
そのためには、ときには問題を抱えている開発チームに SRE として出張し、アプリケーションコードの修正によるパフォーマンスの改善に取り組む必要もあるでしょう。また、それなりに大きな規模のプロダクトであれば専属の SRE がついていることがあるので、開発チームのメンバーと定期的にミーティングを行い、パフォーマンスや運用について定期的にレビューするような機会も必要でしょう。このような機会を持つことで、SRE もプロダクトそのものに詳しくなり、さらなる改善点や運用の助けにもなるでしょう。
SRE は技術的な面でも、人間的な面でも博愛主義的であるべきです。
技術的な切り口では、SRE は広範な技術スタックについて深い理解を持っていて、かつソフトウェアの実装と設計も素早く無駄なくこなすことが求められます。そのためには常にアンテナを張って技術選択の幅を広げておくべきです。広い視点で技術を愛している SRE は間違いなく大きな価値を発揮できるでしょう。
人間的な切り口では、SRE は常にコンサルテーションのための間口を広げておき、開発チームと協力できる体制を整えて、それをしっかりと周知していく必要があるでしょう。我々はいつでも惜しみない協力をするよ、だからサービスの立ち上げや技術的な懸念点やトラブルが起こったときには気軽に相談してほしい、と言い続ける必要があります。ここには銀の弾丸はなくて、地道に周知してサービス開発チームの人々を振り向かせるしかありません。そして、SRE はアーキテクチャに関する深い知識を持っているために、ときに開発チームの「ヤンチャな」設計やコードに対してうんざりしてしまうこともあるでしょう。しかし開発チームを信じて忍耐強くアドバイスをすべきです。これは一種の母性のようなものかもしれません。
ここにきてようやく Google の SRE チームが実践しているエラーバジェットやローンチ調整エンジニアリング、コラボレーションといった取り組みを実践するスタートラインに立つことができます。開発チームとの信頼関係が強固になるにつれ、SRE が持っている時間がそのようなコラボレーションに消費されることになり、トイルも多く発生することになり、だんだんとスケールしなくなってくることでしょう。そうなってきたら、次はトイルの撲滅や自動化、技術要素の標準化や詳細で広範なドキュメンテーションを行うことでスケールさせていくことができるでしょう。
つまり、SRE book に書かれている様々なテクニックは、すべて SRE の献身と愛情をスケーラブルにして開発チームと良好な関係を築き、最終的にユーザに素早く価値を届けて十分な可用性を実現する、というところに本質があると思っています。その本質が達成できるのであれば、Google のやり方にこだわる必要はなく、最終的には我々の組織にとって最善のやり方に落ち着いていくことになるでしょう。
まとめ: 結局は人間、人間、人間である
わたしの好きなフレーズに「一行のログの向こうには、一人のユーザがいる」 というものがあります。アプリケーションコードについても同じことが言えて、一行のコードの向こうには、一人の開発者がいます。ピンとこない人は、git blame してみましょう。一行のログの向こう、そして一行のコードの向こうを見つめながら、献身と愛情を持ってそれをスケールさせることのできる SRE としてやっていけたらなあ、というのが今年の行動指針です。