SRE本読書録
https://gyazo.com/bddb0353911937337ff08f7acf8ee870
会社でSREの本を買ってもらったのでシコシコ読んでいるkeroxp.icon2018/7/14
1章
SRE(Site Reliability Engineering)とはなにか?
サイトを安定させるためのエンジニアリング(開発)を行うことである
チケット、オンコール、トイル(後述)などの開発でないことに人員の時間を取られないようにするための仕組みづくり
GoogleのSREは各員「運用」の手作業を作業時間の50%以下に抑えるように努力している
エラーバジェット
開発チームと運用チームが別れていると、往々にして対立が起きる
開発:早く新しい機能デプロイさせろ。落とすな。
運用:知るか。仕事増やすな。何も変えたくない。
エラーバジェットは、サービスに関わる全ての人員のサービスを安定的に提供する指標として導入された
“100%を信頼性の目標とすることは、基本的にいかなる場合にも間違っている”
100%を達成することは絶対にできない。100%計測できるツールがなければ。
それでも100%を目指し始めると、残り0.xxx1%の溝を埋めるために指数的なコスト増大が起こる
そしてその労力はユーザに何ももたらさない
99.99%と99.999%の可用性の違いは誰にもわからない
サービス稼働時間の100%使い続けているユーザはいない
“企業やプロダクトは、システムの可用性のターゲットをはっきりさせなければなりません。”
サービスがどれくらいの可用性を必要とするかは、企業の規模とサービスの質、ユーザの種類によって変わる
こういう変数を考慮しないと、「100%がいいに決まってるだろ」という間違いが起こる
“そのターゲットがはっきりすれば、エラーバジェットはその可用性のターゲットを1から引いたものになります。サービスの可用性が99.99%ということは、0.01%は利用できないということです。利用できないことが許容されるこの0.01%が、このプロダクトのエラーバジェットです。”
エラーバジェットは予算である
チームは、期間ごとにそのエラーバジェットを使い切ることが許される
逆に言えば、ギリギリ使い切る努力をするべきでもある(keroxp.icon解釈)
サービス開発者は、エラーバジェットを予算内に収めることを目標に各人の作業を行う
障害が起こること自体は悪いこととはみなさない
エラーバジェットを超過することが好ましくない事態である
そういう場合は開発のサイクルやシステムの複雑度を見直したり、エラーバジェットの割合を増やしたりする
エラーバジェットを引いた可用性の割合をSLO(Service Level Object、サービスレベル目標)という サービスがこの割合で安定していることを目標とする
何の割合を指標にするかによってやることも変わるが、基本的には単一の指標を用いる
OOがXXしていたらサービスは安定している。さもなくばエラーバジェットが消費される
hr.icon
“SREは、およそ70%のサービス障害は、動作中のシステムの変更によって生じていることを発見しました。この領域におけるベストプラクティスは、自動化によって以下を実現することです。
漸進的なロールアウトの実装
高速かつ正確な問題の検出
問題が生じた際の安全なロールバック
この3つで1組のプラクティスは、問題のある変更にさらされるユーザーや運用の総数を効率的に最小化します。”
2章
Googleのすごい分散システムの話
3章
SLOの評価は大抵以下の2つのどちらかで行う
計画外停止時間: 稼働時間 / (稼働時間 + 停止時間)
リクエスト成功率: 成功したリクエスト / 総リクエスト数
Googleは時間に関してSLOを評価していない
全サービスが一度に落ちることはほぼ無い
ということは動いてるのか落ちてるのか評価できない
それよりもリクエストの数と成功数は常に正確に計測できるので、そちらを可用性とするほうがいい
企業向けのG Suite(loilo.tv)は99.9%を設定している
YouTubeはもっと低い
SLOは四半期ごとに設定し直す
エラーバジェットがあると、今チームが取るべき行動がわかりやすくなるメリットがある
エラーバジェットが減ってきている場合は新しいデプロイは避ける
エラーバジェットが潤沢に残っている場合はリスクを取って新機能を導入する
新規のデプロイでエラーバジェットの消費が激しくなってしまったら余裕があったとしてもロールバックする
デプロイごとのエラーバジェットの消費率で四半期のリリースサイクルを考え直す