こんにちは。データ・AI戦略部 SREチームの小野です。2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。
ここ一年ほど、DAOという組織改善プロジェクトを推進してきました。このプロジェクトは組織内で発生するあらゆるイベントを「機能」として定義・実装し、それらを束ねてサービスとして組織内外に提供するプロジェクトです。 ※ 詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください
これまでの通常業務をサービスとして提供するという考え方は、我ながらとてもユニークかつ俊逸な発想だったと感じています。なぜなら、このサービスベースな考え方により組織にSLI/SLOを導入しやすくなったためです。
SLI/SLOの導入は個人的に難しいと考えています。導入するためにはさまざまな「ハードル」を突破する必要があるためです。しかし一方で、SLI/SLOを導入したいと考えている方も多いのではないでしょうか。そこで今回は「SREエンジニアのSLI/SLO導入への挑戦」というタイトルで、私がデータ・AI戦略部で取り組んできたSLI/SLO導入への道のりをお伝えしたいと思います。
<目次>
SLI/SLOが重要だと思う個人的な理由
冒頭の自己紹介の通り、私はSREエンジニアです。SREとは「Site Reliability Engineering」の略で、元々Googleが提唱したシステム管理とサービス運用に対するアプローチです。
SREエンジニアの責務は会社によって若干異なるかもしれませんが、私にとってのSREエンジニアとは、「サービスの信頼性を向上させるためのエンジニアリングを実行する人」です。
サービスの信頼性について
サービスの信頼性とは一体何を指すのでしょうか。私も長年腹落ちしていませんでしたが、DAOサービスを作っていくうちに一つの答えを見つけました。
サービスの信頼性とは、「このサービスはユーザーが求めている動作を実行しているのか」です。
具体的に、蛇口を例にサービスの信頼性について考えてみましょう。
例えば、多くのユーザーは、蛇口を捻ったら水がでると考えています。オレンジジュースやコーヒーが出るのではなく「水」がでます(お湯かもしれませんが)。これは蛇口(サービス)を捻ったら水が出るだろうというユーザーからの信頼の表れともいえます。
一方、サービスの信頼性が損なわれる事態を考えてみましょう。
例えば、蛇口を捻った際、水道が爆発したらユーザーはどのように感じるでしょうか。きっと怒ったり悲しんだりして、蛇口(サービス)に対する信頼を大きく損なうことになるでしょう。
このような状態に陥ったとしても、ユーザーは蛇口というサービスを使わなくなることはあまり考えられません。しかし、他の製品に乗り換えたり、契約しているメンテナンス会社を変える可能性はあります。
これは一般企業が提供しているサービスでも同じことがいえます。むしろ競合の多いサービスを展開している企業ほどサービスの信頼性には気を配るべきです。
サービスの信頼性を損なうということは、ユーザーがそのサービスの利用をやめて、他のサービスを検討したり、実際に乗り換えられてしまうことに繋がるからです。
SLI/SLOが最重要SREプラクティスな理由
ここまで書くと、こんな声が聞こえてきそうです。
「サービスの信頼性が重要なのはわかったけど、どうやってそれを観測したり、改善したりすることができるの?」
サービスの信頼性を可視化し、向上させる道筋を作るSREプラクティスが「SLI/SLO」です。これらはサービスに対して設定する指標値になります。
SLI(Service Level Indicator)は、ユーザーがそのサービスに満足するかどうかを評価する指標値です。例えば「Webページが1秒以内に読み込まれればユーザーは満足すると判定する」のようにサービスに求めるスペックを定義します。
一方、SLO(Service Level Objective)は、SLIに対する具体的な目標値(閾値)です。例えば「28日間で、Webページが1秒以内に読み込まれた割合を99%とする」などのようにSLIに対するハードルを設定します。
指標値として設定したWebページの読み込み速度などは、通常、サービスのメトリクスやログから収集します。この値をNew Relicなどの監視ツールで可視化し、SLOに違反していないかチェックします。
SLIに対してSLOの違反が継続して発生する場合は、サービスの信頼性が著しく下がっていることになります。これは早急なサービス改善が必要であると判断するトリガーになります。また、SLOに違反していないからと言って、それで安心はできません。設定したSLIが適切でない可能性があるためです。
SLI/SLOは一度設定したら終わりではなく、サービスが運用されている間は定期的に見直す必要があります。そのためには、サービスの全体を把握し、適切な値を設定できるエンジニアが必要です。
個人的な見解ですが、SREエンジニアの最重要ミッションはSLI/SLOの導入・推進だと考えています。あまたのサービスがひしめく昨今、自社サービスがユーザーから信頼を得て、さらなる発展を遂げるには、どのような企業においてもこの考え方は重要なはずです。
<SLI/SLO運用のモチベーション>
- サービスをより多くの人に使ってもらいたい
- そのためには、ユーザーから多くの信頼を獲得する必要がある
- 信頼を獲得するためには現状の可視化とそれを改善できる取り組みが必要
- つまり、SLI/SLOの導入・推進が必要
SLI/SLO導入・推進のハードルと乗り越え方
ここまでの話で、ユーザーや企業にとってSLI/SLOはとても重要なものであると感じていただいたと思います。しかし、言うは易し行うは難しと言いますか、SLI/SLOの導入・推進には多くのハードルが存在します。ここでは、そのハードルと乗り越え方についてお伝えします。
STEP1: SRE文化の構築
SLI/SLOを導入・推進するにあたり、SREプラクティスを実践できる組織作りが重要になります。ちなみに、SREプラクティスには、SLI/SLO以外にも以下のプラクティスがあります。
<SREプラクティス例>
- トイルの撲滅(自動化)
- IaC推進
- 障害対応・セキュリティの向上
- 新技術のテックリード
私にとって、SREは文化のようなものです。上記のプラクティスはSREエンジニアだけが実践すればよいものではなく、サービス作りに関わる全ての人が共通の認識の元、実践する必要があると考えています。私はこれを「SREを組織にインストールする」と呼んでいます。
SLI/SLOを実践するためには、このSRE文化を組織に根付かせる必要があり、それには以下のハードルがありました。
<ハードル>
- SREプラクティスの重要性を組織内に広める
- SLI/SLOの知見を展開し、実践するように関係者に説得を行う
- 監視体制の構築やワークの実施を行う
SREを知ってもらうこと。それが重要です。
私の所属する部署は、「事業部に対し専門性に基づく支援を行い、全社的なデータ・AI活用をリード・推進する」と言う組織目標があったため、上長や他のチームの役職者に対しては、ビジネス寄りの観点でなぜSLI/SLOの実践が必要なのか説明しました。
チームメンバーに対しては、教育用のドキュメントを作り、SLI/SLOの重要性や設定する理由、New Relic(監視ツール)の使い方などをレクチャーしました。
正直泥臭い仕事ですが、このような一歩一歩の積み重ねが、ハードルを乗り越えるための答えであると考えています。
STEP2: SLI/SLOの導入・推進
SLI/SLOを定義するためには、対象となるサービスが必要になります。
最初は既存サービスに対して、SLI/SLOを定義・導入することを考えるかもしれません。しかし、以下のハードルがありました。
<ハードル>
- 既存サービスには様々なステークホルダーが存在しており、SLI/SLOを導入するためには、関係者にその重要性を理解してもらう必要がある
- システムが複雑化しており、SLI/SLOの定義が難しい
SLI/SLOの定義・導入経験が豊富にあればこれらのハードルを乗り越えることは可能だと思います。しかし、そうでない場合はハードルを高く感じてしまい、SLI/SLOの実践を諦めてしまうでしょう。実際に私も既存サービスに対してSLI/SLOの導入を試みましたが、何度か挫折を経験しています。
大切なことはSLI/SLOの定義・導入経験を積み、どんなサービスでもユーザーの信頼性を獲得できる状態にすることです。そのため、最初はハードルを下げてでもSLI/SLOを導入し、改善を繰り返し経験を積み上げることが重要です。
そこで発想を変えてみることにしました。
まず、対象ユーザーに関しては、以下のように定義します。
<対象ユーザー>
- サービスを利用する顧客
- ぐるなび社員/パートナー
- サービスを利用するサービス(システム)
世の中に出ているサービスを利用するユーザーだけを対象とするのではなく、社内のユーザーも対象としました。また、人だけではなくサービス(システム)もユーザーと見なします。サービス(システム)は連携させて活用することが多いため、呼び出し元はユーザーになるだろうという発想の元、このように定義しました。
次にサービスに関してですが、先述の通り、通常業務をサービス化するDAOプロジェクトを推進しています。 ※ 詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください
例えば先日「SREエンジニアがヘルプデスク体制を作ってみた話」と言う記事を出しましたが、これも通常業務のサービス化の一つです。
ヘルプデスク体制は、組織内外からの問い合わせに対するソリューションを提供するために新規で作成したサービスであり、かつ、ステークホルダーも存在せず、かつ、システムも複雑でないため、SLI/SLOの定義・導入がしやすいです。 ※ 優先度が低いため、ヘルプデスク体制にはまだSLI/SLOを導入していません
このように業務をある一定の単位に分解しサービスとして定義することで、SLI/SLOの導入を容易にし、経験を蓄積することが可能になりました。どのようなハードルであっても問題を細かく分解することで、対処しやすくなります。
STEP3: SLI/SLO運用体制の構築
SRE文化の構築、SLI/SLOの導入・推進のハードルを乗り越えたら、次は運用フェーズに入ります。ここにもハードルが存在します。
<ハードル>
- SLI/SLOが形骸化してしまう
- SLI/SLOが何の拘束力も持たない
SLI/SLOを定義したあとは運用を徹底し、違反時は改善に尽力する強い拘束力が必要になります。そのため、部署内のマネージャークラスを巻き込んだ運用体制を組織に提案しました。
運用体制を作るために、まず運用体制のロールを定義します。
ドキュメントオーナーは、SLI/SLOの設計をおこなうサービスの担当者です。
弊社ではワークスペースとしてConfluenceを使用しているので、SLI/SLOの定義テンプレートを作成し、設計負担を軽減する対策をとっています。
SLI/SLO定義ドキュメントはConfluenceの機能で以下のように一覧化できるので、他案件での利活用やメンバー教育、SLI/SLO定義の見直しなどに活用できます。
また、SLI/SLOの導入はマネージャー以上の承認を必要とする設計にしました。チーム内で自主的に承認するよりも拘束力をアップさせる狙いです。
運用フローは、以下のようになります。
<フロー説明>
- SLI/SLOの設定
- ドキュメントオーナーがSLI/SLOの設定を行う
- マネージャーに対して、SLI/SLOの有効性のチェックを依頼する
- マネージャーからの承認後、メンバーへSLI/SLOの共有を行う
- エラーバジェットの超過
- SLI/SLO定義文章に記載されているエラーバジェットポリシーに基づき対策を実施する
- SLI/SLOの再考日経過
- マネージャーより、SLI/SLOの妥当性をチェックする
- 妥当であれば、何もせずに完了する
- 妥当でない場合、ドキュメントオーナーにSLI/SLOの再考依頼を実施する
- ドキュメントオーナーは、SLI/SLOの再設定実施後、マネージャーに承認依頼をする
- マネージャーからの承認後、メンバーへSLI/SLOの共有を行う
- マネージャーより、SLI/SLOの妥当性をチェックする
エラーバジェットポリシーについて補足すると、SLI/SLOに違反した際、どのような対応を行うか定めたものになります。
この運用フローはまだ実践投入できておりませんが、近いうちに導入する予定です。これによりSLI/SLOの形骸化を防げると考えています。
ダッシュボードを導入してみた
SLI/SLOを導入する際、ダッシュボードも重要になるので最後に紹介します。
弊社では監視ツールにNew Relicを使用しています。New Relicには、ダッシュボードを構築する機能があるため、SLI/SLOの可視化に利用しています。
ダッシュボードは、「全体サマリーダッシュボード」と「テーマ別ダッシュボード」に分けて管理しています。
全体サマリーダッシュボードは、SLI/SLOやKPIなどサービスの信頼性を表す指標を一元管理するために存在します。一方、テーマ別ダッシュボードは、サービスの状態や分析をより深ぼって調査するために存在しています。
全体サマリーダッシュボードでサービスの信頼性の状態を確認し、違反があればテーマ別ダッシュボードに遷移して状態を調査するといった使い方をします。
以下の図は、全体サマリーダッシュボードのサンプルです。SLI_StatusがSuccess(緑)の状態であれば、「異常なし」としています。
一方で、Error(赤)の場合は、テーマ別ダッシュボードで状態の分析を行います。
信頼性が可視化されるとそれだけでモチベーションがアップするので、ダッシュボード運用はとても重要だと感じています。
おわりに
SREエンジニアになってはや3年、ようやくSLI/SLOの運用まで漕ぎ着けました。SRE文化の構築はまだまだこれからだという感じですが、少しずつ理想の状態に近づきつつあります。
今後は、SLI/SLOの導入推進を進める一方で、ユーザーの満足度調査を実施したいと考えています。SLI/SLOで定めた指標値がユーザー満足度に繋がっているか調査する必要があるためです。その結果をSLI/SLO運用の土壌にしたり、サービスの新規開発やグロースの判断基軸として活用していきたいです。
サービスの進化に直結するSREエンジニアは、変化の激しい時代において企業が進むべき道を示す重要なポジションだと感じています。そのため、日々SREプラクティスを勉強し、実践に活かすことで事業に貢献していきます。
ここまでお読みいただき、ありがとうございました。
