SRE本の1冊目を読んだ
こちらを読んだ。
最初の数章を半年前に読んで、積読になってたが時間ができたので残りを読んだので。ハイライトしてた箇所を拾い出し
特に良いと思った章
- 3章 リスクの受容: エラーバジェットとか出てくる
- 7章 自動化: 自動化の重要性と、あまり触れられないデメリットについて書かれている
- 9章 単純さ: 引き算の美学
- 12章 効果的なトラブルシューティング: 問題解決のアプローチ/記録方法について
- 26-30章 : システムというより働き方であったり教育方法などが書かれている
エラーバジェット（予算)という考え方とSLO
SLOで99.999%のサービス稼働率と設定すると、復旧にかけれる時間は・・・と計算してしまうが
この本では、逆に0.001%の時間は停止しても良い(エラーを起こしても良い予算）という考え方をしている
まだ予算が残っている間は、新しい機能のリリースを問題なくできるが
予算が残ってなければ、次の期間（予算が回復する次の四半期など)まで新機能的なリリースは控えるなどの戦略を取るなど
実戦に勝る学習方法はない
いろんな箇所でこれが出てきます。
自動化の章では、全てを自動化するとオペレーターはシステムに触る時間がなくなっていきいざ自動化で対応できない障害が発生した際に対応できなるなるや
新人SREが入る際の教育プランとして、過去に発生した障害を実際に起こして、それを体験してもらうというものなどがありました
コメントで昔のコードを残すな
エンジニアは自分が作ったモノを残したがるモノであり(耳が痛い)
コードベースで自分が書いたコードを大幅に消すことになった際に、「また戻すかも・・・」とコメントアウトするだけでファイル内に残そうとする
Gitで管理すれば、コミットに残るんだから潔く消せ
そのコメントで認知負荷が上がるんだから、消したほうが絶対に良いという主張
昔同じ論争を仕事場でしたことを思い出した。当時これを知ってればなぁ
これが書かれていた9章の「単純さ」は全体的に引き算の美学を感じて特に良い章だった
障害発生しても落ち着いて適切な対応を
インシデントが発生している間は、アドレナリンに負けて、アドホックな対応をやってしまいがちです
大きなサービス障害に対しては、いきなりトラブルシューティングを始めて、根本原因をできるだけ早く突き止めようとしてしまうかもしれません。しかし、その本能は無視しなければなりません！
グヘェ・・・耳が痛い
ポストモーテムの重要性
ポストモーテムは、障害発生後に記録するレポート的なもの
その都度何を考えて、どういう行動をしたか、その結果どうなったかを残すことがとても大切
考えていること、実行したテスト、得られた結果は、はっきりと記録しておきましょう
うまくいかなった結果も非常に大事!それもちゃんと記録に残そう
次に別の人が同じ障害に遭遇した際に、この線はないか・・・と選択肢から落とすことができる
また否定的な結果も書かれたレポートは信頼性が高まる。いいことしか書かれてない報告書って信用できる？
ポストモーテムは他にも新人SREが過去の障害を追体験できる意味でも助かります。
Googleでは定期的にポストモーテム輪読会的なこともしてるらしい
プロダクト導入前後のビジネス的な価値変化を計測しよう
18章で書かれてた。そりゃそうだけども
どうやって・・・？となった
"プロダクトの有用性を数値化することは、さらに大きなメリットがあることも分かりました。私たちがGoogleのあるビジネス組織をオンボードしたときに、そのチームはそのプロセスの詳細と、導入前後の結果の比較を含むケーススタディを作成してくれました"
バックアップとアーカイブは違う
"バックアップをしたい人はいないのであり、人々が本当に求めているのはリストアです。"
バックアップとアーカイブは違うぞ、監査目的でアーカイブしとけばおっけー！と思ってないか
Discussion