-
Ben Treynor SlossがSREの名付け親
-
Chapter 1ではBen Treynor SlossがSREについて話す
- 旧来のIT産業で行われていたことの違いについても
-
でかくて複雑なシステムはそれ自身では動かない！
-
システムはどのように動くべき？
- 歴史的に会社は複雑なシステムを運用するためにシステム管理者を雇ってきた
- システム管理者は現在あるソフトウェアを解析してそれらをデプロイする
- システム管理者はサービスを運用し発生するイベントやソフトウェアのアップデートに対応する
- システム管理者の方法はよく知られており、真似る先もたくさんあるのでシステム管理者初心者チームでも車輪の再開発を行う必要がない
- システム管理者アプローチは関節費用と直接費用の両面で問題がある
- 直接費用は、システム管理者は手作業で事象に対応するのでトラフィックの増加等により人がたくさん必要になる
- 間接費用の増加は、分かりづらいが直接費用よりもコストがかかる部分でもある
- devとopsの分離により、背景やソリューションに対するリスクの見方等が異なる2つのチームでの対立が発生する(ここの訳文がよくわからなかった)
- "The split between the groups can easily become one of not just incentives, but also communication, goals, and eventually, trust and respect. This outcome is a pathology."
- 素早くリリースする vs 安定性のためにリリースを減らす等
- 過去に発生した全ての大障害に対応する、デプロイ時の非常にたくさんのチェックが必要とされ、するとdevチームはlauncheを減らしflag flipsを増やす方向に走る(flag flipsとは？)
- launchレビューを減らすために少ない機能をもったサービスの分割にはしる(マイクロサービスdis？)
- SREとは、ソフトウェアエンジニアにops teamのデザインをお願いした時にできるもの、という説明がシンプル
- 自分がソフトウェアエンジニアであり、自分がSREチームをデザインした
- SREの5~6割はソフトウェアエンジニアとして雇われた人、残りはソフトウェアエンジニアとしてのスキルは必要に満たずスキルは85%-99%だったけど、ソフトウェアエンジニアの持ってないUNIX system internalやnetworkingのスキルを持っている人
- 上記どっちのSREも、同じくらいいい感じに働いてる
- 多様なバックグラウンドがいい方向に働いてる
- SREは手作業は退屈だから手作業を機械に置き換えるためのソフトウェアスキルを持っている
- SREは自動化を行う
- そうしないと、サービスの成長にともなって人をたくさん雇う必要が出てくる
- opsには50%の時間を割いて残りはコードを書く
- とにかく自動化。何かが起きても勝手に復旧するような自動化
- 計測したりあらたに人を雇ったりしてops50%以下を守っている
- サービスの成長に対してsublinearlyにしか人は不要
- 非線型？log n的な？
- SREはいろいろな課題がある
- 雇用が大変
- Googleにおけるソフトウェアエンジニアの獲得との競合
- 高いコーディングスキルと高いシステムエンジニアスキルが要求されると、雇用できる人は限られる
- アプローチがオーソドックスではないため、高いレイヤによるサポートが必要とされている。例えば、エラーバジェットが上がってしまったので四半期のリリースをやめるなどは、product development teamからは反発されるので、managementなしでは不可能
- DevOpsとSREの中心となる原則は近い
- DevOpsの方がより広範な範囲を含んでいる。組織、管理機構等
- SREはops作業が50%を超えたら、ops作業を開発チームにredirectする
- それによって開発者も手作業調査が不要なシステムを作るように向けることもできる
- 休日対応的なon-call shiftで、1回のon-callでは平均的には障害2回までとしている。それ以上だと自体の収束やpostmortemの作成に十分な時間が充てられなくなるし、疲れる
- それ以上だと、疲れてしまう。逆に1回以下だと、彼らの時間を無駄にしてしまう
- 重要な問題が発生した場合はpostmotrtemsを作成する。それらは次回の事象をなくすもしくは小さくするために作る
- blame-free postmortem culture
- error budgetによってイノベーションとstabilityのコンフリクトを防ぐ
- 稼働率100%を追うのは大抵の場合無駄
- 以下を見て目標稼働率を決める
- どのレベルの稼働率だとユーザは幸せか
- 稼働率に満足しなかった場合に代替のサービスはあるか
- 稼働率の違いでユーザによる製品の使い方には何がおきるか
- error budgetが決まったのであれば、大障害は悪いことではなく、innovationのためのプロセスの一つとなる
- むしろ、error budgetを使い果たす範囲でより高速なローンチを目指したりする
- モニタリングの結果をメールで飛ばすのでは弱い。人間が介在する必要が出てきてしまう
- 理想はアラートを飛ばさずに自動で復旧すること
- monitoringのoutputとしてはalerts, tickets, loggingの3つがある。
- 70%の大障害は変更によって発生する
- 変更の際に、IMplementing progressive rolloutと問題の早期検知、及び変更のroll backが自動でできることによってoperationに関わる人を減らすことができる
- capacity plannningは自然増と、イベントや機能追加などによる非自然増があり、それらに対応できるように考える
- リードタイムを考える
- 非自然の需要増を自然増の予測に加える
- システムのテストをする
- SREは、稼働率を確保するため、自然にcapacity plannningの担当となる。これはまたprovisioningおｎ担当になることも表している
- プロビジョニングはcapacity planningの一部。サーバ購入してもprovisioningによって投入できないと意味が無い
- リソースの効率的な使用はめっちゃ大事
- サービスのスローダウンはcapacityの減少と等価
- monitorしてサービスを変更してperformanceを上げる
- SREは旧来型の、大きなサービスをメンテする方法とは違うよ