Site Reliability Engineering
https://www.oreilly.co.jp/books/images/picture_large978-4-87311-791-1.jpeg
avashe.icon今回は和訳版を読んだ
伝え聞くところによるとなんやかんや言ってGoogle SREは激務らしいし、宣伝的側面があるだろうから鵜呑みは禁物
またGoogleの業務内容specifiicが濃く出ているところもある
価値観と理想を共有する本という姿勢で読みます
1. イントロダクション
avashe.icon ンッン~ 名言だな これは
運用にかかわる負荷は増大し続けるため、それについていくための増員が必要
運用にのみに注力するチームはシステムの複雑度に比例して巨大化してしまう
SREはコードを書かなければならない
GoogleではSREは50%以上コーディングスキルを伴う開発を義務付けている
それ以上責任を追加せず、働き方の調整や人員の追加で対応する
開発チームにも品質を追及するインセンティブを設計する
ロールバックしてバグチケットとしての差し戻す
オンコールのページャーローテーションに開発チームを加える
2. Googleのプロダクション構造
舞台となるGoogleのプロダクションシステムと、その開発運用を支えるシステムの説明
avashe.icon とにかくでかいのと、この精密さで自動化するとしたら人手何人必要なんだろと思いをはせる
理想的には対応策のサジェストと共に通知されるべきである、という記述に驚いた
さすがに魔術的ではあるものの、障害時の調査を短縮することはできるかもしれない。テンプレな調査方法を網羅的にスクリプト化しておいて、アラートが出次第一気に実行して異常検知するとか...
3. リスクの受容
可用性をあげすぎるとある時点から無駄なコストになる
冗長化コストはシステムのスケールに合わせ大きくなる
機会コストも大きくなる
機会コストは制作物がユーザに見えないことによる損失
SLO決めてそれを達成する際の時間的余裕(エラーバジェット)を開発に回しましょうねというSREの原則なので、基準となるSLOは重要
SLOで標準的に使われる可用性をMTTFの割合以外で設定するのもあり
複数データセンターがある企業だと全断は珍しくなり意味を持たなくなってくるため、対象システムのリクエスト正常処理率を可用性とする
ユーザから見えないコンポーネントについても同様に有益なメトリクスをとれる
リクエストの重みを考慮してないのが欠点だが、そこそこ便利な指標
これを日単位などで可視化することで注力すべきコンポーネントを検出する
ビジネス側のオーナーと要件を話し合ってリスク許容度を決めてね
可用性を1桁変えることで収入がどう変化するか
この収入の変化は信頼性をそのレベルに変えるためのコスト(orメリット)に見合うか
レイテンシをはじめとした他のメトリクスについても要件定義しようね
多すぎると負荷がかかり少なすぎるとバーストを見逃す
SLOの値はパーセンタイルを使う
rpc呼び出しの99.9%が~ms以内に完了するなど
SLOは満たしすぎないこと
バジェットの減少速度がちょうど良くなるようにコントロールする
avashe.icon 大事なことなのでなんどもでてくる
行う必要のある管理上の雑務はオーバヘッドと呼ぶ
プロダクトに直接結びつかない可能性がある
ミーティング、ゴール設定と評価、人事の事務作業など
長期的な価値が含まれるならつまらない仕事でもトイルではない
アラート設定の見直しなど
トイルとは
プロダクトの動作に関係する
手作業である
自動化された仕組みを動かすための手作業
勝手に発火するようになればトイルは0と言える
繰り返される
1,2回程度ならトイルではない
そこから新たな知見を得られるならトイルではない
戦術的である
トイルは割り込みで始まり、問題が生じたことの対応として行われる作業
ページャの対応はトイル
完全になくせないが最小化する必要がある
長期的な価値を持たない
つまらなくてもプロダクトに改善が加えられるならトイルではない
古いコードや設定を清掃するなどはトイルではない
作業量がプロダクトの成長に比例する
プロダクト、トラフィック、ユーザ数に比例するなら恐らくトイル
これら全てが常にあてはまるわけではない
「人間の判断を必要とするのでトイルではない」を疑え
本質的に人間の認知を必要とするか良く考えよ
優れた設計で対応することはできないのか?
現状の仕組み、アーキテクチャが人間に複雑な判断を強いているのではないか?
トイルを生む温床に敏感であれ
Googleにおける作業の内訳(50%エンジニアリングであること)
ソフトウェアエンジニアリング
平たく言えばプログラミングとのそのレビュー全般
システムエンジニアリング
モニタリングシステムやロードバランサ、サーバーやOSのパラメータチューニングやセットアップ
開発チームに対し、プロダクション環境における設計を提案したりサポートする
ソフトでもシステムでも、ドキュメントを書くのは大事な仕事
トイル
オーバヘッド
採用、事務作業、ミーティングやピアレビュー、トレーニングなど
トイルによる弊害
多少のトイルは避けられないがでかくなると弊害がある
キャリアの停滞
モラルの低下
不平不満につながる
システムの改善だと思って新規に参加した人物は裏切られたと感じる
SREチームの目的の誤解
進捗速度の低下
習慣づけ
トイルに取り組むのに熱心すぎると、開発からトイルを押し付けられたり、トイル消化を期待されるようになる
摩擦の発生
チーム内最高のエンジニアに対し、他で働くように勧めているようなもの
6. 分散システムのモニタリング