SRE について調べたことをアウトプットしてみる

# これは何？
SRE について何も知らなかった私が調べたことをまとめてアウトプットする記事です。

# 一枚の画像にまとめてみた
私の考える SER について一枚の画像にまとめてみました。
![SRE に対する解釈全体像-20240922-07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3892707/b74f6417-bce4-10e5-ad55-d2a878d732ba.png)



# SRE とは？
![01-SRE とは？-02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3892707/f314b2ff-5593-a73e-27ca-142e19440c0b.png)


上記の通りなのですが、重要なのは「信頼性」の部分です。

# 信頼性 とは？
## 一般的な「信頼性」
### JSI による定義
「アイテムが、要求された時に、その要求通りに遂行するための能力」

### IT 用語辞典 e-Words より
「一定の条件下で安定して期待された役割を果たすことができる能力」
https://e-words.jp/w/%E4%BF%A1%E9%A0%BC%E6%80%A7.html

## Google での信頼性の定義
SRE の提唱者である Google では信頼性について以下のように記載しています。

※ Google Cloud アーキテクチャ フレームワーク ​より
https://cloud.google.com/architecture/framework/reliability?hl=ja#reliability_is_defined_by_the_user​
>Reliability is defined by the user

> 信頼性はユーザーにより定義される​

# そもそもなぜユーザーからの信頼が必要なのか
IT の世界は進化が早く、次々に新しい技術やサービスが生まれます。

自社のサービスより他社のサービスの方がより魅力的であれば、ユーザーは他社のサービスに移ってしまうでしょう。

自社のサービスでビジネスを成功し続けるにはユーザーに継続的に利用してもらう必要があり、そのためにはユーザーかの信頼が必要です。


# どうしたらサービスはユーザーから信頼されるのか
例えば以下のようなことが満たされるサービスであればユーザーから信頼されると考えられます。

- 使いたい時にいつでも使える
- 使っていてイライラしない
- 不具合が放置されない、素早く修正される
- 魅力的な新機能が定期的に実装される

上記の要素を満たすこと and 満たせなかった場合に補償を行うことを約束するサービスは、ユーザーから一層の信頼を得られると考えられ​ます。

例えば「使いたい時にいつでも使える」ということが重要なサービスの場合、これからサービスを使おうとしているユーザーに「このサービスは信頼できるな」と思ってもらえるためには、サービスの可用性について約束ができれば信頼が得られると思われます。

サービスについてユーザーとの約束を交わすものとしてはサービスの契約書が該当します。
​
![02-信頼性からの目標の明文化-02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3892707/8bb8f3e5-d912-dad7-989f-e2342e2e96f5.png)



# ユーザーから信頼されるための約束 (SLA) と、その目標値 (SLO, SLI)
サービスにおける約束は契約書の中で交わされます。

例えば契約書の中に以下のような文章を含めます。

「**当社の Web サービスは 可用性 99% を水準としており、その水準を満たせなかった場合はサービスが利用できなかった期間に応じた返金を行います。**」

上記の文章の中で SLA, SLO, SLI に該当する箇所があります。

SLA (Service Level Agreement​) は サービス水準合意 と訳され、上記の文章全体に該当します。
ユーザーから信頼されるサービスとして達成すべき目標が達成できなかった場合にユーザーに対して行われる保証の約束です。

SLO (Service Level Objective​) は サービス水準目標 と訳され、ユーザーから信頼されるサービスとして達成すべき目標です。
上記の文章のケースでは「可用性 99%」が該当します。

SLI (Service Level Indicator​) は サービス水準指標 と訳され、ユーザーから信頼されるサービスとして達成すべき目標の指標となる項目です。
上記の文章のケースでは「可用性」が該当します。

![03-SLA,SLO,SLI.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3892707/1648bde3-3576-2ef6-dee8-783c0a9f6532.png)





# ユーザーの信頼を獲得するためには安定稼動だけでいい？
上記の SLO では可用性を目標としています。

ユーザーの信頼を獲得するためには可用性を高めて安定稼動させれば良いのかというとそうではありません。

IT の世界は進化が早く、次々に新しい技術が生まれます。

新しい技術を取り入れてよりユーザーにとって魅力的なサービスを提供することで生き残ることができます。


# 開発（Dev）と運用（Ops）のミッションの​相反
サービスを運営する会社としてのミッションは自社のサービスによるビジネスを成功に導く事です。

そこから各部門へのミッションが展開されます。

開発エンジニアのミッションはサービスの発展の加速であるため、サービスに新しい機能をどんどん追加したいと考えます。

一方で、運用エンジニアのミッションはサービスの安定稼働であるため、システムに何も余計な変更をかけたくないと考えます。

このように 開発 (Dev) と 運用 (Ops) の各自のミッションで相反が起きます。
![04-背景-01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3892707/5fa0e15a-7c98-980b-e992-0fce82dea29a.png)



# ミッションの相反を解決するエラーバジェット
こういった状況下の解決の手段として **エラーバジェット** という考え方があります。

エラーバジェットでは両者に共通のルールを作り 開発 (Dev) と 運用 (Ops) に共通認識を持たせてることで、両者のミッション達成のバランスを取り対立の解決に役立ちます。

例えば「可用性 99%」が SLO に設定されているサービスの場合、1カ月30日換算で7.2時間までサービスが停止することをが許容されることになります。

この 7.2 時間がエラーバジェットになります。

このサービスではサービスが利用できない時間に応じてエラーバジェットが消費されていきます。

例えばその月の 20 日の段階でサービスを利用できない時間が一切発生していなければ、エラーバジェットに余裕があると言えます。

こういった状況であれば、開発チームによる新機能のリリースでサービスを停止するとしても時間に余裕を持てます。

逆に、例えばサービスに障害が発生してしまい、その月の 20 日の段階でサービスを利用できない時間が 5 時間ほど発生していたとします。
こういった状況であればエラーバジェットに余裕がないので、開発チームは信頼性を高めるためのテスト作業を増やしたり、リリース速度を落とすといった対応をするでしょう。

このようにエラーバジェットによって 開発 (Dev) と 運用 (Ops) が共通認識を持つことで両者のミッション達成のバランスをとることができます。
![05-エラーバジェット-01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3892707/e09f6457-3152-b3aa-5b95-b6e3f2f88442.png)


# エラーバジェットを使い切らずにいかにしてにサービスを発展させていくか
開発 (Dev) と 運用 (Ops) のミッションの相反の問題の解決のためにエラーバジェットの概念を導入した環境下では、エラーバジェットの消費のバランスを見ながらサービスを発展させていくことになります。
そのためにはデプロイ時の障害を減らす取り組みをしたり、サービス開発に注力するための時間を確保するための活動が必要です。

そういった活動が SRE の仕事に含まれます。

例えばデプロイ時の障害を減らす取り組みとしてはデプロイ前の自動テストなどが考えられ、それを実現する方法として Jenkins や AWS の CodeBuild, CodeDeploy, CodePipeline などが挙げられます。

リリース作業の短縮としては、上記のデプロイ系サービスの他にコンテナ技術も手段として考えられ、具体的には docker などが該当し、AWS のサービスとしては ECS, EKS, ERC が該当します。

サービスの停止時間の短縮としては、上記のコンテナ技術のオーケストレーション機能の中での自動復旧関連の機能が該当し、またシステムの監視をすることで、障害の早期発見や障害が起きる予兆の検知をすることができ、監視の手段としては、DATADOG や AWS の CloudWatch が該当します。

サービス発展に注力するための時間確保する方法として、インフラ管理の効率化が考えられ、そのためのインフラのコード化の技術として Terraform や AWS の CloudFormation が該当します。
また、サービスの運用作業を効率化、自動化するさまざまなことを Python のようなプログラミング言語で実現するということも考えられます。
![06-エラーバジェットを使い切らずにサービスを発展させていく方法-03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3892707/440fe8b3-2460-e5e8-a339-514760506476.png)


# まとめてみて感じたこと
改めて全体像を見てみます。
すると一番下の赤枠の部分については「実行する手段はインフラエンジニアとやってることがそんなに変わらないのかも？」と思いました。
![07-02_インフラエンジニアと同じ？SRE に対する解釈全体像-02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3892707/b7e1d3a3-2d78-486e-e1d0-a511ace19230.png)

なので SRE とインフラエンジニアの違いとしては、実行する手段についてビジネス的な背景も含めて根拠を持って取り組むことが SRE であると感じました。
![08-03_SRE はここが違う_SRE に対する解釈全体像-01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3892707/0805344b-0505-2b9a-6fc1-fd0d6fe47c23.png)



以上になります。


# 参考
以下の本を参考にさせていただきました。
https://amzn.asia/d/7hnOl9C

以下の記事を参考にさせていただきました。
https://qiita.com/shin7446/items/58c173d30a08955f0a0d