最初に

プロダクトをリリースしていざ保守・運用フェーズに入ったときに、「バグがたくさんあるから潰さなきゃ」「でも機能追加も色々していきたい」といった想いが混在してあれもこれも状態なときに、どうやって保守って進めたらいいんだ？となっている方もいるのではと思います。

そんな方に向けてSREに基づいて保守を進めるアプローチを、自分の過去の実践などもベースにしながら書いてみました。

SREを知っている・SRE本を読んでいる方には基本中の基本のお話であまり面白味はないかもしれませんが、まとめる機会があったのでせっかくなので記事にしました。

（※以前同じ内容の記事を書いたのですが、少し修正して再掲しました。）

SRE（Site Reliability Engineering）とは

"サイト・リライアビリティ・エンジニアリング (SRE)とは、回復力の高い分散システムを構築・運用するために使用される、システムおよびソフトウェア・エンジニアリングの複数の原則から成る方法論のこと" (出典：ガートナー)

Googleが提唱する、信頼性の高いシステムを構築するためのエンジニアリングの方法論
- オライリー書籍『Site Reliability Engineering』が有名
class SRE implements DevOps と表現することが多々ある
- DevOpsを実現する一つの手法
- 従来のオペレーション(Ops)をソフトウェアエンジニアリング(Dev)の手法で対応するという意味でDevOpsと近い
  - トイル（手作業・ムダな作業）をなくしていく
  - あくまでSREの仕事のメインはコーディングである

SREでどうやって保守するのか

→SLI・SLO・エラーバジェット（エラー予算）を用いる

①SLI（Service Level Indicators）とは

SLI = サービスレベル指標
- 何に基づいて計測するか、といった指標・項目
例
- 可用性（稼働率）
- レイテンシー
- スループット
- エラー率
- etc...

②SLO（Service Level Objective）とは

SLO = サービスレベル目標
- SLIに基づいて計測されるサービスレベルの目標値
- SLA(Service Level Agreement)とは違うので注意(SLA = 合意・保証)
例

SLI	SLO
可用性（稼働率）	99.9%
レイテンシー	平均0.5秒
スループット	秒間100トランザクション
エラー率	0.01%

③エラーバジェット（エラー予算）とは

※これがSREの一番の目玉といっても過言ではないくらい重要な考え方

「SLI＝可用性（稼働率）、SLO＝99.9%」とした場合のエラーバジェットの考え方
- 「~~99.9%稼働しないといけない」~~
- →★「0.1%はサーバが落ちてもいい」という考え（逆転の発想）
年間＝60 * 24 * 365（分）のうち、0.1%(60 * 24 * 365 * 0.001 = 525.6分)は落ちてもいい
- ＝「月43.8分」は落ちてもいい
- ＝「週10分」は落ちてもいい
- →この数値がエラーバジェット（エラー予算）

★具体的な保守ステップ

SLI・SLOを定義しておく
- SLOからエラーバジェットが決まる
  - SLI＝可用性（稼働率）・SLO＝99.9%
  - →エラーバジェット：0.1%
  - →週ごとのエラーバジェット：約10分
SLI・SLOをモニタリング・集計する仕組みを構築しておく
- AWSでの例
  - モニタリング
    - CloudWatch
    - Amazon Managed Grafana
    - Amazon QuickSight
    - etc...
  - 集計
    - CloudWatch Logs Insights
    - S3 + Athena
    - AWS CLI + シェルスクリプトやLambda
    - etc...
定期的に（毎週など）計測した値をチェックし、「エラーバジェットを超えているかどうか」を基準に開発方針を決める
- エラーバジェットを超過していたら、バグ修正・リファクタを行う（守りの開発）
  - 例：週20分サーバが落ちた > 10分（エラーバジェット）
- エラーバジェットを抑えられていたら、機能追加を行う（攻めの開発）
  - 例：週5分サーバが落ちた < 10分（エラーバジェット）
- ※100:0で攻め・守りを分割しなくても、70:30とか80:20でもOK
3.をループで繰り返し、都度SLI・SLOの見直しも行う

近年のおすすめSLI

エラー率
- 単位例：「エラー数/リクエスト数」
  - エラーを踏んだユーザ数の割合などを単位にすることもある
- 近年の開発ではおすすめ
  - よくあるのは可用性（稼働率）だが、最近の開発で使用するサーバーレス・マネージドサービスは何もしなくてもあまり落ちないので、ずっと攻めの開発になってしまう
  - エラーはとにかく無くしたいという気持ちはみんなあるので認識が揃いやすい

ただ、エラーはとにかく0件にしたいプロダクトの場合はずっと守りの開発になってしまうので、レイテンシーなどを選択するのもおすすめです。

具体的な保守例（SLI : エラー率）

SLI＝エラー率、SLO=0.01%
- エラーバジェット=SLOとし、エラー数がリクエスト数の0.01%を超えるかどうかを目標値に
今週のリクエスト数が100万、エラー数が500件だった場合
- 500 / 100万 = 0.0005 = 0.05% (> 0.01%)
- → ×予算オーバー
- → 来週は「守り」の開発（やばいのでエラー潰そう😱 ）
今週のリクエスト数が600万、エラー数が300件だった場合
- 300 / 300万 = 0.00005 = 0.005% (< 0.01%)
- → ○予算内
- → 来週は「攻め」の開発（まだまだいけるぜ😎 ）

上記保守方法のメリット・デメリット

メリット

数値に基づいた定量的な判断・データドリブンな意思決定が可能
- やるべきことが明白である

デメリット

スケジューリングがしづらい・見通しが立ちづらい
- スプリントごとでやることが決まる（変わる）ので
- SLOを満たせない限り機能追加が中々できない
  - 品質・信頼性より機能数などを優先するプロダクトではSREの考えはおすすめできない
  - SREのRはReliability(信頼性)

デメリット（スケジュールのしづらさ）の解消方法

ある程度運用していくと、過去の実績からSLOの目安が出るので、実現可能なSLOを設定しやすくなる
- エラーバジェット超過の割合を見積もってバッファを組んでスケジューリングする

最後に

基本的なSREの考え方と、それに基づいた保守の方法を書いてみました。

SREを知っている方にとっては基本中の基本かと思いますが、意外と「保守ってどうやって進めるんだ？」というような意見も聞くことが多いので、改めてご紹介させていただきました。

365歩のテック

SREに基づいた保守の進め方

最初に