SREトレーニング直前のトレーニングを受けて

· SRESoftware

この記事は、2025年7月に、某所にてオンサイトで行われたSREトレーニングの復習のため、書いたものです。
ただの情報の羅列で、ほとんど生の情報なので、間違いがあるとおもいます。鵜呑みにせず、ご覧ください。

1

Productの規模とそれに必要な運用・保守の人数の関係

2. SREの原則

  1. いかなるシステムにおいえて、最も重要な機能は、信頼性である
  2. 監視が信頼性を決めるのではい。ユーザが決める。
    • 巧妙に設計されたソフトウェアはあ99.9%の信頼性
    • 巧妙に設計された運用は99.99%の信頼性
    • 巧妙に設計された〇〇は99.999%の信頼性 (<— 聞き取れなかった)

3. DevOpsとの違い

製品ライフサイクル

  1. コンセプト
  2. ビジネス
  3. 開発
  4. 運用
  5. 市場
DevOpsSRE
組織の壁を減らす責任を共有
失敗は普通のこと。受け入れるSLO & 非難のないポストモーテム　
段階的に変更　失敗のコストを下げる　
ツールと自動化を活用　ソリューションを構築し、xxx
全て測る影響の定量化、トイルも信頼性も定量化

4 SREの用語

信頼性とは

SLIとSLOの関係

CUJからSLIを決定し、そのSLIに対してSLOを設定する。Error Budgetを使い切らなければ、たくさん開発、たくさんデプロイ。Error Budgetを使い切りそうだったら、安定稼働。デプロイ戦略の指標の１つ。

SLI=OK eventAll evnets\begin{align} {\rm SLI} = \frac{\rm OK ~ event}{\rm All ~ evnets} \end{align}

SLIとSLOの関係

e.g.,
CUJ: xx msec以内に… （時間の情報必須）
SLIの種類: 可用性
仕様: 2xx, 3xx, 4xxはOKとする。429はX。
SLO: 99.9%が良いレスポンス　<—あまり良くない書き方。書き方は「過去28日で99.9%」のように想定時間を決める

SUJ —> SLIの種類 —> SLIの仕様 —> SLIの実装 —> SLO

SLOが高すぎても良くない。ユーザがアホみたいにリクエストする。ユーザが構築するシステムの耐障害性の観点。

コンテナを吹き飛ばそう。カオスエンジニアリングを実施しよう！

Error badget: 許容できる不具合の量。99.99%の可用性が30日間保たれるとすると、4.32分しかエラーが許されない。コンテナの再起動したら、この時間を使い切ってしまう。99.9%なら21.6分なのでなんとかなりそう！

SLOは社内向け。文書化する。メトリクスベースでまだ余裕があるエラーか、そうではないのか？

7 リスク分解

8 実践（文化超大事）