Ch.1の前に、この本の簡単な説明。
SRE本が教科書/参考書とするとワークブックは問題集。 SRE本は主に原則や哲学を説明していたが、ワークブックはその原則をどのように適用していくかについて説明。 SRE本はGoogle内でのSREの実践例の話だったが、ワークブックはその他の企業（GCPユーザー）での話もあり。
- Evernote, Home Depot, NY Times, Spotify
class SRE implements interface DevOps- オペレーションは難しい
- システムをうまく運用する
- ベストプラクティスが全ての環境で幅広く適用できるわけではないこと
- オペレーションチームの運営
これらの分野の分析は第二次世界大戦中のオペレーションズ・リサーチによって始まったと一般的に考えられているが、 実際には何千年も前から物事をうまく回す方法を考えている。（らしい。 e.g. 古代ローマ帝国のプロバンス地方）
- しかし、信頼性の高い生産活動は未だによくわかっていない
- 特にIT/ソフトウェアの運用性の分野
- エンタープライズの世界では、オペレーションをコスト・センターとして扱っていることもある
- (オペレーションの品質を落としてコスト削減しても、非常に大きな障害によって意味がなくなることもあり)
- この考え方では改善活動が困難になってしまう
- このアプローチがとても短絡的な考えというのはまだ広く理解されていない
- これに対する不満が、IT分野で我々がしていることをどのように体系化するかの革命となった
- 最新のソリューション: DevOpsとSRE
- 別のものとして扱われるようだがどちらも似ている
- DevOps
- IT開発, 運用, ネットワーキング, セキュリティにおけるサイロを無くすために設計された緩めのプラクティス、ガイドライン、および文化
- CA(L)MS という頭文字が要点を表す
- Caluture（文化）, Automation（自動化）, Lean（リーン）, Measurement（計測）, Sharing（共有）
- by John Willis, Damon Edwards, and Jez Humble
- 共有とコラボレーション
- DevOps的には、何かを改善して（多くの場合は自動化）, 結果を測定し、その結果を同僚に共有することで組織全体で改善がされる
- CALMSは協力的な文化によって促進される
- DevOps, アジャイル, その他の技法の全ては、現代世界において、最善な方法でビジネスを行う一般的な世界観の例
- DevOpsの哲学は基本的に分離不可だが、いくつかの重要なアイデアは個別に議論可能のものもある
サイロ化: 部門間で情報共有が全くされていなかったり、業務が連携されずにいて、別々で分断されている状態のこと
- No More サイロ
- オペレーションと開発が別々のチーム（昔はメジャーだったが今では古いスタイル）
- ナレッジの極端のサイロ化, 個別最適, コラボレーションの欠如 は、多くの場合ビジネスにとって非常に悪い
- アクシデントは個人の独立した行動の結果というよりも、失敗時の安全対策がないから
- 例:
- ダメなインターフェースのせいでうっかり間違えてしまう
- 設計ミスのせいで、間違った状況化で失敗が発生してしまう
- 計測機器が壊れているせいで、何かがおかしいことに気づかない
- 古い体質の企業では、間違いを犯した人を探し出して罰する文化を持っている場合がある
- 結果として、問題を混乱させ、真実を隠し、他者を責めるようになってしまう
- 生産性のない妨害になっている
- アクシデントを防ぐことよりも、素早くリカバリすることに集中した方が有意義
- 変更は小さく頻繁に行うこと
- 変更は、可能な限り小さいサブコンポーネントに分ける
- CI/CDのような変更管理へのアプローチにつながる
- ツールはDevOpsの重要な要素
- 特に変更管理
- ツールも重要だが、文化はもっと重要
- 良い文化は悪いツールを回避できる. 悪い文化では回避できない
- "Culture Eats Strategy for Breakfast"
- オペレーション同様、変化は難しい
- 計測はビジネス全体で超重要
- 例: サイロ化をなくしたり、インシデント解決
- SRE
- サイト信頼性エンジニアリング
- Googleの VP of Engineering の Ben Treynor Slossによって作られた用語（＆関連する職務）
- DevOpsは、プロダクト開発ライフサイクル全体におけるオペレーションチームと開発チームの間のコラボレーションに関する幅広い原則
- SREは仕事上の役割であり、うまく機能することがわかっている一連のプラクティスであり、それらのプラクティスを生み出す信念
- DevOpsを仕事への哲学とアプローチと考えると、SREはDevOpsの哲学のいくつかを実装しているということが出来る
- "DevOpsエンジニア" よりも、("SREエンジニア"の方が) 仕事や役割の具体的な定義にいくらか近い
class SRE implements interface DevOps- SREを実行するために、カルチャー的な変化が必要なわけではない
- オペレーションをソフトウェアの問題として捉える
- 解決するためには、ソフトウェアエンジニアリングの手法を駆使する
- 幅広い視野を持って解決にあたる
- 全可用性100%を目指さない
- プロダクトチームと共同で適切な可用性目標を決める
- ビジネスサイドとの協力が必須
- 構造的に、やらなきゃならない手作業は憎い
- （そういうものが全くないわけではなく、ただただ嫌い）
- 人間ではなく機械ができるなら機械がすべき
- それが職業・仕事になっている場合もあるが、GoogleのSREにとってはトイルは仕事ではない
- オペレーションタスクに費やした時間はプロジェクトに費やした時間にはならない
- プロジェクトに費やした時間こそがサービスの信頼性とスケーラビリティを向上させる
- トイルの原因は、撲滅したり低減したりできるためには識別可能でなくてはならない
- オペレーション量が多いと感じる場合は、担当しているサービスの仕組みにエンジニアが精通するために、新機能や変更を頻繁にプッシュする必要があるかも
- 何を、どのような条件で、どうやって自動化するかを決定する
- GoogleのSREでは、チームメンバーがトイルに費やしていい時間の上限は50%
- SREチームは自動化できる全てのものを自動化し、できないものを残す
- 自動化できないものが大きくなっていく
- Googleでは50%上限を維持したまま担当サービスを増やしたり、自動化できて代わりのことができたりする
- 「信頼性の向上」
- SREの主な利点というわけではないのに、明確にある
- 通常の障害のMTTR（平均復旧時間）の短縮が、開発者の時間を無駄に取らないから
- 発見が後になればなるほど修復が難しくなる
- 問題発見が遅れないようにするのがSREの義務
- アプリケーション開発とプロダクション（運用？）との厳密な線引きは逆効果
- 特に責任の分離や、コストセンターとみなしての職務の分離は力関係の不均衡や尊敬・賃金の不一致を引き起こす
- プロダクション上の問題では、ソフトウェアツールが関係がある場合がある
- プロダクト開発チームとスキルセットを共有する
- SREは 可用性/レイテンシ/パフォーマンス etc... のような専門性を持っている
- SREと製品開発チームの両方が、システムスタックの全体の把握をすべき
- フロントエンド, バックエンド, ライブラリ, ストレージ, カーネル, 物理マシン
- どこかのチームが専有のコンポーネントを所有すべきではない
- 境界線をぼかすと多くのことができるようになる
- SREの道具としてのJavaScript
- プロダクト開発者のカーネル
- 特定の職務に固執しない
- SRE本では、Googleのプロダクト開発チームがサービスを所有していることを明確にしていなかった
- SREの原則はGoogle全体で管理されている方法の情報を提供するけれども、SREは大部分のサービスについて利用可能でも保証もしない
- SREとプロダクト開発チームが協力するときのオーナーシップは共有モデル
- ツール利用は行動のとても重要な決定要因
- GoogleのSREの有効性はツールに支えられている
- 統一され、広くアクセス可能なコードベース
- 幅広いソフトウェアとシステムのツール
- 非常に最適化された独自のプロダクションスタック
- この前提をDevOpsとして共有している
- 全員が同じツールを使用する
- SREとそれ以外のチームで別々のツールを管理するのは難しい
- 個々のツールの改善に対するメリットが少なくなる
- GoogleのSREの有効性はツールに支えられている
-
DevOpsとSRE
- DevOpsとSREは両方とも、改善のためには変更が必要ということを受け入れること
- DevOpsではコラボレーションが一番の肝だとしていて、同様にSREでは組織を横断した共有に重点を置いている
- 変更管理は最低限に小さく、継続的なアクションをしていて、そのほとんどが理想的には自動テストと自動適用されること.
- 適切なツールは非常に重要で、行動の範囲がある程度決まってしまう.
- 計測はDevOpsとSREの両方の働きにとって重要. SREではSLOがサービス改善の行動を決定する際にとても重要で、そのSLOには計測が必須.
- サービスを運用していると悪いことはたまに起きる. SREとDevOpsは両方ともその後処理をうまくするために訓練する.
- DevOpsの実践やSREは全体的な行動となる. 双方ともにチームや組織全体を良くすることを望んでいて, ベロシティ向上がその結果になる.
-
共通するものも多いが、大きな違いもある
-
DevOps
- 広い哲学とカルチャー
- より広い変更が影響するため、それぞれのコンテキストに依存する
- 細かいレベルのオペレーションについてはあまり気にしていない.
- サービスの正確な管理について規定していない
- それよりも幅広い組織の障壁を壊すことに集中
-
SRE
- 比較すると狭い責任範囲
- ビジネス全体ではなく、サービスやエンドユーザーを指向
- サイロ化や情報の障壁についてはあまり気にしていない
- ビジネスのためではなく、オペレーション慣行の改善のためにCI/CDをサポートする
-
DevOpsとSREは同じことを信じているが、その理由が違う
DevOpsとSREはその活動が概念的に非常に重複している.
- そもそも実装可能である
- その実装から最大の利益を得る
効率的な運用アプローチはすべて似ているが, ダメなアプローチは全て独自のやり方で壊れている インセンティブは部分的にこれがなぜかを説明している
- 組織のカルチャーがDevOpsのアプローチの利益に値し、そのコストを喜んで払う場合
- 人の採用が難しい
- チームの流動性と責任を維持するために多くのエネルギーが必要
- 必然的によりレアなスキルセットを補うために費やされる費用の増加
If an organization’s culture values the benefits of a DevOps approach and is willing to bear those costs - typically expressed as difficulties in hiring, the energy required to maintain fluidity in teams and responsibilities, and increased financial resources dedicated to compensating a skill set that is necessarily more rare— then that organization must also make sure the incentives are correct in order to achieve the full benefit of this approach.
具体的には、DevOpsとSREの両方で以下のことが当てはまる
- インセンティブ
- 間違ったインセンティブは全体のパフォーマンスを悪化させる
- 厳密にリリースや信頼性に関連する成果と紐づけて定義・構造化してはならない.
- 数値目標があると、数字だけを良くするようにしてしまう
- 適切な妥協点を見つける自由を与える
- システム設計にSREが初期から関わると、リリース後、誰が担当するかにかかわらずうまくいくことが多い
- システム障害の責任を他のチームへ投げるようなインセンティブは良くない
- 非難を避ける動きは、開発者と運用担当者が分離する大きな原因となる
- 組織レベルで以下のプラクティスを採用すること
- エンジニアがコードや設定の変更を必要なときにすることを、許可するだけではなく積極的に推奨すること.
- またチームのミッションの限界範囲内で、抜本的な変更の権限を与えること. そうすることで、徐々に進むことを排除する.
- 非難をせず事後処理をサポートする.
- 問題を軽視したり、隠すことがないようにする
- エンジニアがコードや設定の変更を必要なときにすることを、許可するだけではなく積極的に推奨すること.
- GoogleではSREとプロダクト開発は別の組織
- チームごとに各自の関心事やプライオリティがある
- プロダクト開発チームはプロダクトが成功した際に、SREの採用を支援してくれる
- お互いがお互いのチームの成功に関わる
- DevOpsとSREの実践者にはメリットあり
- 同僚のコミュニティによるサポートとキャリア開発
- 同僚のユニークなスキルや視点
- 組織やプロダクトが一定以上成長したとき、SREがサポートするプロダクトや優先順位を自由に発揮することができる
- GoogleではSREとプロダクト開発との強力なパートナーシップがとても重要だということがわかった
- サービスサポートの撤回や提供といった決断は、比較可能な運用上の特徴に基づいて行うべき
- そうすることで無駄な会話を避ける
- SREとプロダクト開発との生産的な関係
- プロダクト開発チーム未熟な状態でリリースしなければならないアンチパターンを避けることにも役立つ
- SREが開発チームに協力して、メンテナンスの負担が最も詳しい人の手を離れる前に、プロダクトを改善することができる
- DevOps/SREをプロダクト開発と同じように尊重（高く評価）してほしい
- ほぼ同じ方法で評価され、同じ金銭的インセンティブを受け取る
-
DevOpsとSREは実践と哲学の両方で非常に近い
- ともにディスカッションや経営層からのサポート、そして実際に作業をしている人からの同意を必要としている
- どちらを行うことも簡単ではなく長い工程がかかる.
- SREは特定の順応が必要だけれども、早い段階で仕事の慣習を変えるための具体的な提案がある
- DevOpsは幅広い焦点を持っており、具体的な手順へと落とし込むのは難しいが、最初の抵抗は薄いかもしれない
- どちらも多くの同じツールを使い、変更管理に同じ手法を用い、データ志向による意思決定の考え方を持っている
- 同じ永続的な問題に対処している: プロダクションとそれをより良くすること
-
以下の本が参考になる
- Site Reliability Engineering
- Effective DevOps
- The Phoenix Project
- The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2
- Accelerate: The Science of Lean Software and DevOps
2018/08/22 ディスカッション時のメモ
サイロ化
アクシデント
小さな変更: リリース頻度
変更管理
アラート