セッション動画

どうぞよろしくお願いします。「現場がさき、プラクティスがあと、原則はだいじに」というお話をさせていただきます。

馬場といいます。@netmarkjp というIDでやっております。基本的に運用系、クラウドとかインフラ中心のエンジニアリングとか、コンサルティングとか、組織レベルのあれこれとか、事業レベルのあれこれみたいなのを仕事にしています。あとは、ISUCONとかモニタリングとかでいくつか本を書かせてもらってます。会社でもAWSを中心に現場から組織まで幅広くいろいろやっております。最近は、「入れたはいいけどうまく使えていないDatadogを一緒に使い倒す」などを伴走型でやってます。

今日は、現場でよくある話をしたいと思います。

SREに走りたくなるには理由がある

よくありますよね、「"SRE"みたいな3文字タイトルカッコいいよね」と。カッコいい、わかります。

「強そう」もそうですね。なんかいろんなキーワードが出てくるわけです。ここにも3文字プラクティスとかいろいろ出てきます。

「みんなSREしてます」 - 仕事柄、求人などをよく見るのですが、多くの求人がSREに変わっていますね。本当にここ1、2年ぐらいかな、かなり大きく変わってると思います。

ボスも、ボスのボスもSREって言ってることが多くなってきたかなと思います。運用の会社とかインフラの会社、SIer、事業会社などなどですね。最近は非ITの事業会社さんでも、デジタルトランスフォーメーション(DX)の流れでコンサルさんからSREとかDevOpsといったキーワードを聞くわけです。

「だからSREしましょう」 - でもそれは「ちょっと待って!」です。勢いはすごく大事なので、それはそれでいいです。でも、典型的なSREというものにこだわらないほうがうまく行くと思うよというのが、今日、私が言いたいことです。こうなってしまうのは、鉄板コースから外れる不安があるからなんじゃないかと思うんですよね。でもそんなことは決してないです。ポイントを押さえたいならばむしろ王道ですよというのが今日言いたいことで、スライドのタイトルにあるように「現場がさき、プラクティスがあと、原則を大事に」という話をしたいと思います。

成果に近づくために進捗を出すのでなく、進捗を出すと成果に近づく

さっそく事例なんですけど、「SRE NEXT 2022」という去年のイベントでもお話した内容です。非ITの事業会社に「SREと言わずにSREを持ち込んだらうまくいったよ」という話です。

やったこととしては、いろんなステークホルダーの皆さんと関係性を構築して整理して、開発担当会社さんもインフラの担当のSIerさんも、もちろん事業会社の皆さんも、みんなが能力を発揮できる状況を作れました。うまくいったっぽいので、現場の課題を整理して、「成果より進捗ですよ」と言って、実際にそういう態度も見せて、振る舞いを見せてやってみて、実際それができるようになったので、うまく回るようになりました。成果って一直線上にあるのではなくて、いろんな模索の先にあるんですよね。運用はとくにそうだと思うんですけど、会社とか状況とか事業のフェーズとか人間性とか関係性とかによって前提条件がみんな違うので、どうしても探索的な取り組みをして成果にたどり着くということをしなきゃいけない。正解ルートがないところを進まなきゃいけないので、進捗を出すほうが実は大事です。「成果に近づくために進捗を出すんじゃなくて、進捗を出すと成果に近づく、そういうものです」と言いながら実際にやりました。

ポイントとしては、DevOpsといえば壁を壊すということで、座組の壁をぶち壊しました。インフラ担当、開発担当、事業会社がそれぞれ「僕らは○○なのでこれはわかりません」と言うのを「いやいや大丈夫、ほんとはわかるでしょ」みたいな話をして、いろいろ硬軟織り交ぜてやっていくと、だいたい皆さんできるんですよね。できるし、やっているし、興味もあるんだけれども、いろんなしがらみとか遠慮とかルールがある。ルールも定められた時と今とで前提条件が違って「それ今有効なルールじゃないですよね」みたいなこともあったりします。そういうのを技術的な方法だったり、あるいはノリだったり勢いだったり、いろんな方法で乗り越えて現場を作っていくということをやったらうまくいきました。

非常に良かったのは、スムーズに始められたことです。よくあるんですけども、SREといえばSLIで、SREをするんだったらSLIを決めなきゃいけない、じゃあSLI検討会議をしよう、みたいなのがあるんです。こうなるとなかなかその次に行きません。進捗が出ないから、成果にも全然たどり着かない。なにしろ妥当なSLIを決めるための基礎情報すらない状態なので、決めようがないんです。なので、進捗を出す以外に私はその手法がないと思うんですけど、でも失敗したくないとかいろんな事情があって、進捗よりも成果という気持ちになってしまう。そうするとうまくいかないんです。でも私は進捗のほうが少なくともこのときは大事だと思ったので、進捗を出していきました。

ゼロコンフィグレーションにはならない、でもそれでいい

残念だったことというか、伸びしろの部分としては、属人性が非常に高いということです。ステークホルダーと言っても人で構成されているので、人が入れ替わったときにノリを掴んでもらうのに時間がかかったり、ロールバックしやすいというところはまだ手がつけられていません。あとは、ゼロコンフィグレーションって書いてますけど、ルールに則ればうまくいくというようなことにはならないですね。全然なりません。運用の特性みたいな話だとは思ってるんですけど、結局無理というか、それは叶わないだろうなと思っています。

レベル感とか程度にもよると思うんですけど、それこそWebアプリケーションフレームワークとかでもそうですよね。規約に則って、規約ベースでやればうまくいくんだと言いつつ、それだけでうまくいっているWebサービスはあんまりないですよね。何だかんだいろいろとカスタマイズしたりして、ちょっとずつ自分たちの事情に合うようにやっていく、というのが実態かなと思っています。規約でばらつきを少なくすることは非常に価値があると思うのですが、だからといってそれだけでは完璧に行けないと思っています。

これは私が言ってるだけじゃなくて、あのGoogleも言っています。

SREエンタープライズロードマップというものがあります。これはGoogleから今年出たドキュメントなんですが、「SREを導入するには、こういうふうにするといいですよ」みたいなことが書いてあるんですね。Googleが言うことを盲目的に信じればいいというわけではないのですが、私だけじゃなくてほかの人も言っていることは覚えていておいてほしいです。GoogleがSREについて語っていると、SRE＝Google発のワードなので王道という感じがしますよね。とくに一番下に書かれていることに注目してください。「あなたのSREのバージョンがGoogleのものと完全に一致する必要はありません。原則だけは一致させてください」 − ほら、Googleも言っています。

というわけで、あらためて、プラクティスから考えないと鉄板コースから外れる不安があるんじゃないかとは思うのですが、決してそんなことはない、むしろ王道ですよというのが今日言いたいことです。「現場がさき、プラクティスがあと、原則はだいじに」ともう一度お伝えして、今日は以上にさせていただきます。ありがとうございました。

本記事は、TechFeed Experts Night#17 〜 事例で学ぶSRE 〜 ツール、プラクティスから組織づくりまでのセッション書き起こし記事になります。
イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。