こんにちは！ ACS事業部Cloud InfrastractureチームでEngineering Managerをしている谷合です。
弊社エーピーコミュニケーションズは、SIerとして日々皆様の内製化やお困りごとの支援を行っています。
ですが、実は通常のSIとしての設計/構築的な案件でなく、一年以上前よりSREとして、お客様のシステムの可用性や信頼性向上、運用のご支援も行っています。
その中で、Terraformを使ったAzure、AWS、Google Cloud、New RelicのIaC化、難解なアーキテクチャの整備、GitHub ActionsでのCI/CDパイプラインの実装、自動化などを通じたトイル削減といった技術を提供しています。
普段私はManagerとして、エンジニアやチームの管理、チームや事業部の戦略策定、採用など幅広く動いています。
SREとしてはエンジニアのメンバーが動いてくれていますが、私もSREとしての知識は欠かさずに仕入れてはいるつもりです。
そんな私が今まで得た知識や、見解を述べてみます。
私自身今から述べることが正解だとは思っていないので、もし間違っていたら、ご指摘お待ちしています！
なお、「SRE本」や、「SREをはじめよう」などの素晴らしい技術書もあるため、本記事は技術書の内容に可能な限り触れずに、考えの整理に徹したいと思います。
- そもそもSREとは何をするロールなのか
- 信頼性向上のためにすべきこと
- トイルは本当に悪か
- 運用チケットとトイル削減の時間配分
- SLI/SLOとエラーバジェット
- SIerが提供するSRE
- SREの楽しさややりがい
- さいごに
そもそもSREとは何をするロールなのか
これについて述べる前によく比較されるDevOpsとの関係性を明らかにしてみます。
正直なところ、私から見てもあやふやな関係性のように見えます。
- DevOpsはソフトウエアのリリースまでを責任を持つ
- SREはリリース後の運用や、ソフトウエアの信頼性や可用性について責任をもつ
これが違いなのかなと思ってます。
また、DevOpsはCI/CDパイプラインを駆使しリリースサイクルを短縮するのが主なミッションなのに対し、
SREはObservability（以降 O11y）ツール、Infrastructure as Code (以降 IaC)、コーディングを駆使し、可用性や信頼性を担保するのが
主なミッションであると思います。
じゃあ、SREの可用性や信頼性を担保するのが主なミッションであるならば、何をするのか？
私の考えでは、以下のことをするのがSREであると捉えています。
- 可用性や信頼性を担保するために、開発者との関係性を築き、運用方針を決定したり運用の改善をする
- SLI/SLOを取り決め、エラーバジェットの許す限りリリースを行う
- 運用でなく、反復作業などのトイルを可能な限り削減する（トイルはもしかしたら悪ではないのかも）
- 開発者の困りごとをチケットとして処理する
- 開発者に運用スキルを伝授する
- 運用だけでなくコストの削減にも切り込む
なお、開発者にセルフサービスなインフラやCI/CDパイプライン、インフラのガードレール整備を提供するのもSREなのでは？と思いましたが、
それはPlatform Engineeringに譲ります。
信頼性向上のためにすべきこと
信頼性向上はお客様のご支援をする際に特に重要視するポイントです。
常に気を付けるポイントを以下に記載します。
このポイントは特にSRE初学者が気にすべきポイントを解説します。
- O11yツールのアラートやインシデント
- 開発者からのチケット
- 著しいパフォーマンス低下
その中でも、アラートやインシデントは気にすべきでしょう。
特にアラートから、システムのパフォーマンスの状況は拾えると思います。
とはいえ、アラートは過去の情報なので、未来に備える必要があります。
アラートから読み取れる情報から常にチューニングを意識しましょう。
トイルは本当に悪か
はい。これは賛否両論ではないでしょうか？
一般的にはトイルは以下を定義として撲滅だ！と言われるのではないでしょうか？
- 手作業であること
- 繰り返されること
- 自動化できること
- 戦術的であること
- 長期的な価値を持たないこと
- サービスの成長に対してO (n) であること
現在複数社でEmbedded SREや、プロダクトに属さないSREとして支援させていただいていますが、以下のトイルがあったりします。
- アラートのトリアージ（Azure SQL DatabaseのDTUやCPU/メモリの閾値超過アラートなど）
- 新規参画者用アカウント払い出し&権限付与
- 退職者用アカウントの削除＆権限
- VMのセキュリティパッチ適用
- チケットの進捗確認
ですが、本当にトイルは悪なのでしょうか？
確かに信頼性向上といった面では、繰り返しが発生するオペレーションは避けたいですよね。
しかし、ことSRE初学者や、運用初学者に目を向けてみると、トイルが何もない世界は得るものがあるのでしょうか？
私は多少のトイルは許容し、トイルとともに信頼性や若手を育てていくといった世界線があるといいなと思っています。
そのため、トイルは悪とは言えないよなと考えています。
とはいえ、トイルがあると運用に支障をきたす現場もあるのはそうですよね。
その場合は徹底的にトイルの削減をするのがいいかと思います。
ただ、そうでない場合はトイルを許容しつつ、付き合っていく運用でもいいかと思います。
むしろ今まで気づかれていないトイルに気づいた人を称賛するくらいでもいいと思っています。
運用チケットとトイル削減の時間配分
スプリントを導入している組織ではチケットを捌いていくと思います。
Embedded SREやEnabling SREといったプロダクトともにあるSREであれば、なおさらで、チケット化されたインフラの払い出しや、仕組みづくりで日々の時間を消費するのではないでしょうか？
とはいえ、トイルとも向き合う必要がありますよね。その場合、時間配分はどのようにすべきでしょうか？
実はこれは私が今まさに悩んでいるところであります。
この場合、トイルをある程度貯めておき、一定期間はスプリントをストップし、皆でトイルを片付ける方法が良いのでは？と考えます。
または、1日の内の特定時間はトイルに向き合うなどの時間配分もありますよね。
そもそも、トイルに優先順位をつけて、優先度低のものは無視または拒否するといった方法もあると思います。
他にもこんな方法あるよ！という方いれば、教えてください！
SLI/SLOとエラーバジェット
個人的にSREと言えばな指標であるSLI（Service Level Indicators：サービスレベル指標）とSLO（Service Level Objectives：サービスレベル目標）です。
最初にSLIを決めていきますが、何を指標にすればいいのかの明確に決まっているものはなく、各社で独自に指標を設けているところが多いのではないでしょうか？
ただ、主には以下のメトリクスを基に決めている会社が多いのではないでしょうか？
- 稼働率
- 遅延
- エラー率
- スループット/パフォーマンス
SLIを決める場合は、まずCUJ（Critical User Journey：クリティカルユーザジャーニー）を定義する必要があります。
CUJとはユーザがサービスを利用するときに、通る道や頻繁に行われる操作などを指します。
この時、SREだけでなく開発者も交えて、議論する必要があります。
以下CUJの例です。
- Webサイトの○○というボタンを押す
- ログインする
- 検索窓から商品を検索する
- 商品をカートに入れる
- 決済する
この一連の操作の中から、重要な操作にSLIを設けていくのがいいでしょう。
例えば、「検索窓から商品を検索する」際に画面ロードや描画スピードが遅かったらイライラしますよね。
また、決済する際もなかなか決済が終わらずインジケータがクルクル回りっぱなしになると、購入する気が一気になくなりますよね。
こうした操作に99.9パーセンタイルでレイテンシ500ms以下などのSLIを設けます。
次にSLOです。
SLOはSLIを基に、どの程度SLIを遵守するかを決める目標値を設定します。
最初のSLOの導入はキッチリではなく、結構ザックリでいいのでは？私の考えです。
運用をしていく中で常にSLOは改良を重ね、自社の信頼性を担保するための目標を決めていけばいいと思います。
また、重要なのがSLOはSREだけでなく、経営層や開発部門とも握る必要があります。
というも、経営層と握っておかないと、信頼性が脅かされている際の報告のタイミングや、事業を止めてまでSLOを担保するといった意思決定ができません。
また、後述するエラーバジェットを定義することで、開発部門が開発を続けるための意思決定にもつながります。
エラーバジェットは、サービスの信頼性が損なわれても許容できる指標を指します。
例えば、サービスレベル目標（SLO）が「99.9%」のリクエスト応答率を維持することである場合、エラーバジェットは、エラー応答率を「0.01%」以下に抑えることになります。
この場合、月間43分程度はダウンタイムが許容できます。これがエラーバジェットです。43分を超過した場合はすべてのリリースを中止し、問題解決に全力を注ぎます。
このようにCUJ → SLI → SLO → エラーバジェットの順で決めていけばいいと私は考えます。
SIerが提供するSRE
SREは事業会社であれば事業をスケールするためにSREをどう扱うのか？取り入れるのか？を考えるかと思います。
私はSIerに所属しているので、SIer目線で語ってみたいと思います。
SIerとしては、SREをお客様に提供する立場となります。
この場合、通常の設計/構築などのSIと異なり、信頼性や、トイル削減、組織の課題感なども考慮してご提案しております。
また、SREとご支援させていく中で、新たな課題が見つかった場合は積極的に改善案を提案させていただいたり、情報をお渡しするなどしています。
現状弊社では、以下を対応しています。
- チケットの消化
- 各種自動化
- パブリッククラウドの監視ツールからO11y特化ツールへの移行
- インシデント対応およびポストモーテム作成
- SLI/SLOの策定
とはいえ、まだまだ道半ばでありますが、やりたいことはあるのでSIerでSREを提供するメニューは今後も強化していきたいと思っています。
SREの楽しさややりがい
今までインフラエンジニアとして、仕事をしてきて、SREはアプリケーション開発やインフラの総合格闘技のように感じます。
私個人としては今まで業務で培ってきた知識や経験と、趣味で得たコーディングが活きているなと感じています。
とはいえ、どちらもエキスパートである必要はなく、徐々に両方が自然にできるように身に着けていけばいいと思っています。
SREとしては、インフラ環境の構築や、コストモニタリング、アプリケーションやネットワークをツールでの可視化を通じた監視やAPM/NPM導入、インシデント対応など、対応が必要な領域が多種多様であることから実に挑戦し甲斐のある仕事です。
そのため、日々対応するタスクも異なるため、飽きることなく非常に楽しくエンジニアリングできます。
また、その活動を通じてインフラの安定稼働ができた時は非常にやりがいを感じることができます。
安定稼働ができていると、積極的なトイルの洗い出しや安定稼働を叶えるためのツールの開発に時間を使うこともできるようになります。（エラーバジェットを消費していないSREチームは不要との見方もありますが...）
私の管轄しているCloud InfrastractureチームではSIerでSREを実践したい方を募集しています。
カジュアル面談からでも可能であるため、是非お声掛け下さい！！
さいごに
今日は12月27日、最終営業である会社も多いのではないでしょうか？
弊社も今日が最終営業日です。本年も大変お世話になりました。
また、来年2025年もよろしくお願いします！
それではみなさん、良いお年を！
ACS事業部のご紹介開発者ポータルBackstage、Azure AI Serviceなどを活用し、Platform Engineering＋AIの推進・内製化のご支援をしております。 www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
我々の事業部のCultureDeckはコチラ。
www.ap-com.co.jp
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
