こんにちは。鈴木です。
ここにシステムを安定させる4000万円の魔法の壺があるとします。
あなたなら買いますか。
はじめに
この記事はSREを導入する方の後押しになればと思い書きました。
SREやればいいのに
SREを導入すると、システムを理解するときの解像度が上がります。
システムを開発する人、運用する人、企画する人、ビジネス側の人。多くの人がユーザへの価値提供という共通の視点で会話できるようになります。
システム運用のコストパフォーマンスを改善できます。ユーザ影響の無いアラートで深夜に起こされることも減らせます。
だから「SREやればいいのに」と思います。しかし、・・・
4000万円の魔法の壺
エンジニアが思う「やればいいのに」。それはビジネス視点だと4000万円の魔法の壺に見えるかもしれません。
例えば年俸800万円のエンジニア5人がSREの導入に取り組むとします。半年で2000万円、1年で4000万円の人件費がかかります。
会社はさまざまな活動に人やお金を投じます。事前に本当に価値があると断定できるものなどありません。ある対象に人とお金を投じると決めるには相応の覚悟が必要です。
SREを知らない人に向けられた「SREやればいいのに」。それは「4000万円の魔法の壺、買えばいいのに」と同じです。
相手は「SREとはサイトの信頼性のエンジニアリングで、えーと・・」という状態かもしれません。SREが特別理解されにくいのではなく、言語化して価値を伝える行動が必要ということです。
僕は、軽率に4000万円の壺を買うような会社は、かなり嫌です。
なぜモノタロウはSREに取り組むのか
システムを安定稼働させることがビジネス的に重要であり、効率的な運用が必須となるくらいに大規模だからSREに取り組んでいます。
10分落ちると数百万円、数千万円の影響が出る
モノタロウのシステムがピークタイムに10分落ちるとどうなるか。数百万円、数千万円という影響が出ます。障害対応に関わる多くの人の時間も奪われます。
ビジネスへの影響を考えると、システムの安定性は重要な関心ごとです。それは人とお金を投じる十分な理由になります。
不安定なシステムを札束でしばいたことがある
2年ほど前、システムが長期的に不安定になりました。負荷に耐えられなくなり、レイテンシーやリクエスト成功率が悪化しました。
暫定的にサーバを1.5倍に増やしました。札束でしばく、というやつです。エンジニアとしては技術で解決したいところです。
多くの人が「このままではいけない」と思う出来事でした。
大規模化・複雑化が旧来の運用方法を無効化する
ビジネスが成長すると、システムにも色々な変化が起こります。
- ビジネスが成長するとサービスの利用者が増えます。
すると、サーバ台数を増やすなどシステムが大規模化します。 - ユーザに多くの価値を提供するために機能開発します。
すると、さまざまな機能を実現するためにシステムが複雑化します。 - 冗長化したりエラー時のリトライ処理を入れたりします。
すると、システム内で発生したエラーとユーザ影響が直結しなくなります。
システム内のエラーとユーザ影響が直結しなくなるというのは質的な変化です。
今まではシステム内のどこかでエラーが発生したら障害対応を開始すれば十分でした。いつしか「障害対応に呼ばれたけど何もなかったな」と思うことが多いと気付きます。
システム視点からユーザ視点に頭を切り替える必要があります。システムはユーザに価値を提供できているのか。ユーザはシステムを満足して利用できているのか。
システムの大規模化・複雑化は旧来の運用方法を無効化します。今までの運用に対する考え方や取り組み方を変える必要があります。
SREの導入による効果
SREの導入によって、いくつもの変化がありました。具体例をいくつか紹介します。
会話の中に「SLO」が登場するようになった
会話の中に「SLO」が登場することが増えました。
- 「エラーは増えているけどSLO的にはどう？」
- 「SLOダッシュボードでユーザ影響が収まったことを確認できました」
SREにはSLO以外の用語も多くありますが、システムに関わる色々な職種の人が共通の言葉で会話できるようになったことに価値を感じます。
システムの状態を深く理解できるようになった
上記はバーンレート（Burn Rate）という指標のダッシュボードです。これを利用することで、障害対応時にユーザ影響が収束しているか素早く判断できるようになりました。
バーンレートのダッシュボードが無かったときは、メールや Slack の通知を見て判断することが多々ありました。
大規模な障害ほどエラーメールが大量に送信されることが多いです。そうすると受信が遅延します。遅延が解消されるまではエラーが収まったのか判断に迷うこともありました。
仮に障害対応に10人で60分かかっていたものが、10人で15分に短縮できたとします。障害対応で奪われる時間の合計は10時間から2.5時間に削減できます。
オンコールの初動対応が早く精緻になった
オンコール担当の体制を作ったことで、障害発生時の初動が速くなりました。
ミーティング中だったのでアラートに気付くのが遅れたことはないでしょうか。アラートに気付いたのに「ちょっと忙しいし他の人が気付いてくれないかな」と思ったことはないでしょうか。
障害が発生してから検知するまでの時間は上記のように変化しました。
SREの難しさ
SREの難しさには「SRE固有の難しさ」と「そうではない難しさ」があります。
SREを学ぶ過程で、いくつもの用語が登場します。CUJ, SLI, SLO, エラーバジェット、バーンレート、etc.. これらを理解することは、SRE固有の難しさです。
そうではない難しさもあります。
- 組織横断的な活動の難しさ
- 安定的に時間を使うことの難しさ
- 利用するツールやサービスの難しさ
いろいろな難しさがごちゃ混ぜになった「SREムズカシイ」は、戦う相手として強すぎます。直面している難しさがどのような性質のものなのか。それを理解した上で取り組むことが重要だと考えます。
組織横断的な活動の難しさ
SREは組織横断的な活動です。
関係者が多くなるので知ってもらうだけでも大変です。他部署の人がどの程度の時間をかけてくれるのか、直接コントロールできません。
たとえば、モノタロウは会社としてSDGsに取り組んでいます。これも組織横断的な活動なので、SREと共通する難しさがあるはずです。
ではどうするか。
関係する組織のマネージャを早めに巻き込みます。人のアサインが決まっている状態では、協力依頼を受けても調整できないことがあります。あまり協力してもらえない原因が「依頼が遅い」だったりします。
コミュニケーションを増やすことも重要です。理解してもらうために十分な説明をおこなうこと。期待する行動を具体的に伝えること。理解度が上がると積極性も上がるものです。
共通の課題が存在することもプラスに働きます。「ビジネスに影響が出るほどシステムが不安定」「運用負荷が高すぎて新規開発に入れるエンジニアがいない」などです。
安定的に時間を使うことの難しさ
「他の仕事が忙しくて動けませんでした！」
言ったことも言われたことも何度もあります。
新しい取り組みを始める時は、一部の人だけでも専任にできると良いです。全員が片手間に関わるだけだと、十分なチャレンジすらできない形で「時間が使えなかったから何もできませんでした」という失敗になりやすいです。
SREに最初に取り組むチームを「ヒーローチーム」と呼ぶことがあります。ヒーローと呼ぶだけで時間が使えるようにはなりません。兼務の仕事を減らす、組織上のチームにして専任化する、といった具体的な行動が必要です。
安定的に時間を使える状態を作ることは、ヒーローチームではなく組織の仕事です。
利用するツールやサービスの難しさ
GCPのCloud Monitoringを使ってSLOのダッシュボードを作るとします。当たり前ですがGCPやCloud Monitoringの知識が必要ですよね。もしTerraformで管理するならTerraformの知識も必要になります。
これらはSRE専用のツールやサービスではありません。経験のあるメンバーがいるなら心強いです。経験者がいない場合は、そこだけに絞って個別に学ぶ手もあります。
どのようにSREを導入したのか
Googleの最新SREを学んだ
Google社から直接、最新のSREを学びました。
SREが世の中に広まったきっかけは「Site Reliability Engineering（通称: SRE本）」です。SREの原典のような位置付けではありますが、2016年の情報です。
その後、Googleの中ではSREが磨き上げられています。最新のSREを学べたことは非常に価値が高かったです。
CUJを定義した
モノタロウにはサイトの機能開発を企画するプロデューサというポジションがあります。プロデューサとSRE導入メンバー（ヒーローチーム）が協力しながら、主要ページのCUJ（Critical User Journey）を定義しました。
CUJ（Critical User Journey）は聞きなれない言葉かもしれませんが、重要なユースケースだと考えれば良いかと思います。
上記はモノタロウの商品検索（サイト内検索）の主要な機能を洗い出したものです。この中からCUJとするものを選びました。
CUJを決めるときは、全てが重要だと言いたくなる気持ちを抑える必要があります。このとき、ユーザージャーニーごとの売上など、定量的な数字があると良いです。
SLIとSLOを定義した
CUJが決まれば、次はSLIとSLOを決めます。
SLI（Service Level Indicator）はサービスレベルを決める指標です。Webアプリケーションの場合はリクエスト成功率やレイテンシーを選ぶことが多いです。
SLO（Service Level Objective）はSLIの目標値です。直近の実績をベースに決めます。いきなり理想値を設定しないことが重要です。そうしないと、目標値を割った状態でスタートすることになってしまいます。
Cloud Monitoringでダッシュボードを作成した
GCPのCloud Monitoringでダッシュボードを作成しました。ダッシュボードは1つだけではなく、SLOを見るもの、エラーバジェットを見るもの、バーンレートを見るものなど、CUJに対して複数あります。
役に立つかもしれない話
可用性99.5%の世界で買い物する人々
可用性99.5%の世界を想像できるでしょうか。ブラウザでいろいろなサイトを表示すると1000回中5回がエラーになります。
これは日本のインターネットユーザの多くが住む世界だそうです。一般的なプロバイダと契約してインターネットを利用するなら、これくらい。モノタロウで買い物する人の多くも同じでしょう。
「エラーになったけど再読み込みしたら表示された。まあいいや。」と思った経験は何度もあるのではないでしょうか。それくらい。それくらいが日本のインターネット環境の相場です。
駅に近く、広くて静かで日当たりがよく、家賃が安い物件。そんなものはありませんよね。安価に運用できて可用性100%の絶対に落ちないシステム。そんなものもありません。
「ビジネス側とSLOを合意できません」「絶対に落とすなと言われます」。そんなときは合意を急ぐのではなく、一緒に相場を知る時間が必要なのかもしれません。
SREという名前がもたらすものと奪うもの
SREの導入において、SREという言葉を使えば使うほど、「SREという言葉を聞いたことがある」という人が増えます。SREの知名度が上がるということです。
一方、「SREという言葉を聞いたことだけある」という人が増えると、SREを深く理解する人の割合は下がります。SREという名前を使えば使うほど、組織の理解度を下げる。
SREは組織文化に導入するものです。名前を知ってもらうことも重要ですが、組織文化として広まる程度に理解してもらわなければなりません。
SRE固有の難しさについて先述しました。CUJ, SLI, SLO, エラーバジェット、バーンレート、etc.. これらの説明を最後まで聞いてくれる人は期待より多くはないかもしれません。それでも組織の理解度を上げるための重要な行動です。
知名度と理解度に着目することで、SREを組織文化に導入するという大仕事を成功させやすいはずです。
SREという言葉が消えた未来で語る過去のこと
多くの会社がSREに取り組んでいます。少し検索するだけでも、多くの事例が見つかります。数年単位でSREに取り組んでいる会社の場合、その会社の中での変遷が垣間見えることもあり、興味深いです。
- インフラメンバーが集まってSREチームになった会社が多数派です。モノタロウは開発メンバーが集まってSREチームを結成しました。
- SREに取り組む単一のチームから始めた会社が多く、そこから徐々に仕事が増え、グループや部門に昇格した会社もいくつもあります。
- CRE（Customer Reliability Engineering）やDBRE（Database Reliability Engineering）のように、SRE以外のReliability Engineeringが生まれている。
SREという名前が組織上から無くなっている会社もあります。将来、世の中からもSREという言葉が消える（使われなくなる）ときが来るかもしれないですね。
「かつてSREというものが・・」と昔話をするときに、我々は何を語れるでしょうか。「SREとはサイトの信頼性のエンジニアリングで、えーと・・」。これでは格好がつきません。
SREという名前が使われなくなったとしても、ユーザに提供する価値に着目するという考え方は有効であり続けると思います。
SREの導入に取り組む人は、SREを深く学び、本質を理解しやすい特等席にいます。もし、将来SREという言葉が使われなくなったとしても、それでも語れる本質を理解できると素敵ですね。
おわりに
この記事はSREを導入する方の後押しになればと思い書きました。
SREは価値のある取り組みだということが伝わったなら嬉しいです。
ここにシステムを安定させる4000万円の魔法の壺があるとします。
あなたなら買いますか。
Enjoy SRE!（SREやればいいのに！）
--
もしモノタロウのSREに興味がありましたらカジュアル面談にご応募ください。
