SRE サイトアビリティエンジニアを読んで, 2

※SRE本のトカゲはモニタートカゲなので画像のものとは違います。

SREとしての作業を「希望は戦略にあらず」「通常運用中のシステムに人手が必要なら、それはバグだ」を心がけて頑張りたい
まあ、SREという役職ではないのですが・・・・

４章　サービスレベル目標

一通り読んで分かったが、この箇所が一番重要である

SLO　 ＝＞　サービスレベル目標
SLI　　＝＞　サービスレベル指標
SLA  　＝＞　サービスアグリーメント

これだけでは分かるにくいので

可用性と信頼性 — クラウドのためどのように変えるか  — Part 2, キーコンセプト

SLIを時系列にトラッキングするを確認するとよく分かる

社内でAという製品を売っているとする
SLOは社内でのA製品の品質99.95％
SLIは毎日測っている実際の指標
SLAは購入者と約束したA製品の品質99％
とする

SLIがSLOより下回れば調査など必要になり、SLIがSLAより下回ればお客様に何らかの賠償がかかるかもしれない

SLOは、SLI＜＝SLO もしくは　下限 <= SLI <= 上限になります。

ではSLIという指標は何にするのか？

・リクエストのレイテンシ
・エラー率
・システムのスループット
・可用性

ここはユーザー体験にインパクトのある指標をチョイスすれば良いだろうなと思いました

5章　トレルの撲滅

まずトイルとは何なのか？

トイルとは、プロダクションサービスを動作させることに関する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦略的で長期的に価値を持たず、作業量がサービスの成長比例を持つ傾向を持つものです。
Site Reliability Engineering　5章より

流石にこれだと覚えられないのでもう少しまとまってないかなと
SRE の原則に沿ったトイルの洗い出しとトラッキングの資料には下記のように書かれている

トイルとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業です。

「サービスの品質を妨げる作業」のことを言うのかなと納得した

Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（後編）に詳しくはまとまっている

6章　分散システムのモニタリング

モニタリングにおける4大シグナルは下記である。
ユーザーの利用するシステムはこの４つに集中するのが良い

・レイテンシ　　　　：リクエストを処理してレスポンスを返す時間
・トラフィック　　　：システムに対するリクエストの量
・エラー　　　　　　：処理に失敗したリクエストのレート
・サチュレーション　：サービスがどれだけ「手一杯」になっているか？　※1

※1 最も制約のあるリソースの利用率　→ Elasticsearchはインメモリデータベースなのでメモリ利用率とか

まあ、SER本にもあったがやり過ぎは良くないですよね

アラートは
Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（後編）に詳しくはまとまっているのでこっち見れば良いかなと

7章　Googleにおける自動化の進化

恐らく、自動化の状態を徐々に良くしてけば良いのかなと思えました

❶自動化以前
ロケーション間でのデータベースマスタのフェイルオーバーが手動で行われる状態。

②外部でメンテナンスされるシステム固有の自動化
SREが自分のホームディレクトリにフェイルオーバーのスクリプトを持っている状態。

❸外部でメンテナンスされる汎用の自動化
誰もが使用する「汎用フェイルオーバー」スクリプトにSREがデータベースのサポートを追加した状態。

④内部でメンテナンスされるシステム固有の自動化
データベース自身にフェイルオーバーのスクリプトが同梱されてリリースされている状態。

❺システムが自動化を必要としない
データベースが問題を検出し、人間の介入なしに自動的にフェイルオーバーを行う状態。

終わりに

一通り読んでみて、この前半部分がほぼ重要で後は実践例が続くので後々読んでいく上でのノウハウが詰まった箇所でした。