デブサミ2019の2日目のSite Reliability Engineering at Googleというセッションを聞いてきました。

背景をいうと、僕はバックエンドエンジニアの経験が強めで、3年くらい前にモダンフロントエンドに目覚めた人間です。インフラは多少触ったことがある、個々の技術に興味があるという程度です。

SREについても単語を聞いたことがあって、以前調べたような気がするけど、すっぽり頭から抜けていた感じです。（これもアウトプットの便秘か）

感じたこと

SREも、アジャイルな開発やDDDと同じように銀の弾丸は無く、自社に合わせたエンジニアリングが必要だなと感じました。そして何よりその会社のエンジニアリング文化がちゃんと確立されていなければ実現は難しいでしょう。

発表でも「これはGoogleという組織でのSREの話なので、他でそのまま通じるものではありません。是非色々な場でのSREについて議論が深まればいいと思っている」とおっしゃってました。

SREとは

Googleが提唱したもので、雑にいうと、インフラ、運用を、ソフトウェアエンジニア主導でシステム開発しつつカイゼンしていこうぜというものです。

DevOpsやInfra as a Codeに近いですが、それをより推し進めたものでしょうか。

Googleではborgという分散プラットフォームが根底にあって、他にも様々な標準化された世界規模の分散システム（ミドルウェア）があります。これとほとんど同じ機能を持ったものがGoogle Cloud Platformとしてサービス提供もされています。

SREチームはそういった分散プラットフォームのプロフェッショナルであり、運用も行う、ソフトウェア開発者なのです。

インフラエンジニアも、コードを書け、というかGoogleの技術者なら全員優れたソフトウェアエンジニアであるという文化が根底にあります。

・ 社内のソースコードは技術者なら誰でもアクセスできる
・ なんなら他のチームのコードをカイゼンできる
・ SREの理想は、運用ゼロにすること（もちろん現実的には難しいが、そのために必要なことはやるという文化）

50%ルール

運用保守というと「泥臭い」という言葉が速攻で連想されるはずです。ぶっちゃけつまんないと感じる人が大半でしょう。

ところが「人がやりたくないことをするのが仕事だ」「つまらなくても仕事なんだからやれ」みたいな考え方を持っている人も多いでしょう。これは特に古い体質の企業で顕著です。

Googleは世界中から優秀なエンジニアが集まった組織なので、古い企業のような言葉を投げつけると、どっかステキな仕事をできる会社に好条件で転職できてしまいます。

そもそもそうやってNTT研究所など日本のトップクラス（であるはず）の会社からGAFAに人が現在進行形でどんどん流出しているのですから。

そこで、SREがつまらない仕事になってしまわないための施策が「50%ルール」です。運用業務が50%を超えないようにする。残りは技術的にわくわくできるもの、基盤プラットフォームの開発とかやっていくというもので、つまらないと感じがちな業務は50%以下に抑えるというものです。

Googleではこれを成立させるために、50%を超えるのであれば、システム側が不安定なので、安定化のための改修が必要であると、定義しているのです。

安定性が悪くて運用業務が大量に発生してしまうようなシステムは、SREチームが、開発チームに「これ安定化させよう」と提言でき、開発チームにさしもどす権利があるとしています。

・ SREチームが開発チームに協力する
・ 開発チームは新機能の開発をフリーズして安定化をしなければならない

少なくとも開発チームに対して一方的に弱いということは無く、対等な立場であるという文化なのです。

エラーバジェット

Google SREでは「エラーバジェット」というものがあります。目標安定稼働率を定義してそれを元にエラーバジェットという仮想的な予算が決まります。

実際にエラーが生じるとバジェットがどんどん減っていき、ある一定期間でバジェットを使い果たしたら、新機能開発はフリーズになるというルールです。

エラーに限らず、応答時間の遅れなんかもこのバジェットで管理します。

これも面白い考え方ではありますが、必ずしも他社で導入する必要があるか？というとそういうわけではないと思います。

Postmortem

障害対応の結果は社内でPostmortem（検死結果）というものを残します。これは障害対応が終了して、記憶が新しいうちに、関係者全員がGoogle Documentの同時編集でわちゃわちゃ書き込むものです。

・ Postmortemも技術者なら誰でもアクセスできる
・ Postmortemでは個人を非難する、責任を追及することは絶対に禁止
・ Postmortemは失敗をナレッジにするための手段である

障害報告というと嫌な記憶が掘り起こされる人も多いかもしれませんが、そういったものを排除して、純粋にナレッジにするという文化なのです。

社内にはPostmortemを読む同好会すらあるらしいです。感情を排除して、状況を改善するための純粋なナレッジなので、多大な価値があるからです。

もう一度感想

つまらないと感じがちな状況を、「イマのシーズンだけだから」というふうに期間限定だからという言葉でなぁなぁにやっていく会社は多いでしょう。

特定の人に運用保守案件を押しつけて、花形エンジニアはもっと楽しそうな仕事をしているというような会社も多いでしょう。

でも「業務のn%に抑えてそれを超えるなら、その状況はマズいからカイゼンする」という風に、日々の仕事の比率として定義しているのは素晴らしいです。

純粋なナレッジを残すPostmortemという考え方もとても素晴らしいです。余計な感情や責任追及という負の要素を排除して、どういう時に障害が生じるのか、どうすればそれを解決できるのか？を科学的に対処していくというのが、とても素晴らしいです。

ソフトウェアエンジニアがやるべきことは、ソフトウェアで問題を解決する、サービスを提供する、未来につながる研究開発をするなど、バリュー（いってみれば金）を生み出すことが一番のミッションであるはずです。

そこには個人を責めるという情緒的な問題は絡むべきではありません。どうしても責任を追及しなければいけない局面はそうそうあるものではありません。

短期的・直接的に見て金を生み出していないように見えても、実際にはとても大切な安定稼働ということに、ちゃんと人の心理を見据えたルールを作っているという点にGoogleの強さが現れています。

SREはまさに文化によって成り立つものであり、DDDと似たような難しさがあるなと感じました。