SRE本を読んでみた2

こんにちは長い間ブログをサボってました。 色々あってなかなか取り組むことができなかったです。 その話はまた別の機会にでもは書いてみます。

長い間SRE本を読むこともサボっていました。というのも、現在はSREとは少し遠いことをやっていたので、そちらの取り組みを主に行なっていました。(サボり)

また所属会社では来Qからproduct teamへSRE Practiceを注入するためのSREチームへ移動することが決まりまた読まなきゃなっていう気持ちで読み進めています。読んだことをまたアウトプット行きたいと思います

第四章

この章は前章のSLIを設定するがその目標値(SLO)を定め管理するのと、その目標値の測定と評価法を述べている。

SLI(サービスレベル指標)

サービスの信頼性の指標。特に重要にしているのがサービスSLIがリクエストのレイテンシである。もう１つ重要な指標としては可用性である。処理に成功したリクエスト数の比率をもとにすると説明があるが、サービスの特性を考えて、userが何を期待いているのかを加味した上でSLIを設定することが大切なのだと感じた。 サービス特性を考慮しメトリックスを収集するのが望ましいし。また、その値を収集していない場合はいったんそれを収集して観察すること。 ここでメトリクス取集として大切なことは平均値ではなく中央値で取集することらしい。 平均値は突発的な変化をマスクしてしまうので可視性の観点で向いていないためである。

実際のSLIの取り決め方はCUJを割り出して、そのエンドポイントに対してサービスの特性を加味した上で、レイテンシ、可用性、スループットなどを取り決める。あくまでサービスの特性を加味するので、必ずしもレイテンシ、可用性、スループットの指標を導入しない。サービスの特性を考えて取捨選択する。 これらの指標を取り決め、その値を取集する。

SLIはテンプレート化しておくこと、また設定メトリクスごとにテンプレート化しておいくこ方が良い

SLO(サービスレベル目標)

SLIで計測されるサービスレベルのターゲット値あるいはターゲット値の範囲。 SLIに対する目標値。下限 <= SLI <= 上限となる。 本書ではシェークスピア検索の検索リクエストに対する平均レイテンシを100ms以下にするというSLOを紹介されている。 設定したSLOは常に満たし続けることを求めるのは現実的ではない。それを追い求める代償として過剰な保守、リリースのペースが落ちて顧客へ価値提供が遅延されるなどが起こりうる。
大切なのはエラーバジェットを設けて、消費しつずけなければリリースを行い顧客へ価値を届けることが大切。
またSLOの未達比率を示すエラーバジェットを日ごと、週ごとなどに追跡をした方がよく、SLOに関しても同様に観察を行なっていくこと。
SLOは完璧なものでなくて良い。それよりもSLOを定期的に見直して育てていく活動の方が大切。