evalphobia/The_Site_Reliability_Workbook.ch01.md

## The_Site_Reliability_Workbook.ch01.md

      
    Raw
  

              The_Site_Reliability_Workbook.ch01.md
            
          
    Ch.1の前に、この本の簡単な説明。
SRE本が教科書/参考書とするとワークブックは問題集。
SRE本は主に原則や哲学を説明していたが、ワークブックはその原則をどのように適用していくかについて説明。
SRE本はGoogle内でのSREの実践例の話だったが、ワークブックはその他の企業（GCPユーザー）での話もあり。

Evernote, Home Depot, NY Times, Spotify

1. SREはDevOpsにどのように関わっていくのか

class SRE implements interface DevOps

オペレーションは難しい

システムをうまく運用する
ベストプラクティスが全ての環境で幅広く適用できるわけではないこと
オペレーションチームの運営


これらの分野の分析は第二次世界大戦中のオペレーションズ・リサーチによって始まったと一般的に考えられているが、
実際には何千年も前から物事をうまく回す方法を考えている。（らしい。 e.g. 古代ローマ帝国のプロバンス地方）

しかし、信頼性の高い生産活動は未だによくわかっていない

特にIT/ソフトウェアの運用性の分野


エンタープライズの世界では、オペレーションをコスト・センターとして扱っていることもある

(オペレーションの品質を落としてコスト削減しても、非常に大きな障害によって意味がなくなることもあり)
この考え方では改善活動が困難になってしまう
このアプローチがとても短絡的な考えというのはまだ広く理解されていない
これに対する不満が、IT分野で我々がしていることをどのように体系化するかの革命となった

最新のソリューション: DevOpsとSRE
別のものとして扱われるようだがどちらも似ている


DevOpsの背景


DevOps

IT開発, 運用, ネットワーキング, セキュリティにおけるサイロを無くすために設計された緩めのプラクティス、ガイドライン、および文化
CA(L)MS という頭文字が要点を表す

Caluture（文化）, Automation（自動化）, Lean（リーン）, Measurement（計測）, Sharing（共有）
by John Willis, Damon Edwards, and Jez Humble


共有とコラボレーション

DevOps的には、何かを改善して（多くの場合は自動化）, 結果を測定し、その結果を同僚に共有することで組織全体で改善がされる


CALMSは協力的な文化によって促進される
DevOps, アジャイル, その他の技法の全ては、現代世界において、最善な方法でビジネスを行う一般的な世界観の例
DevOpsの哲学は基本的に分離不可だが、いくつかの重要なアイデアは個別に議論可能のものもある


No More サイロ

サイロ化: 部門間で情報共有が全くされていなかったり、業務が連携されずにいて、別々で分断されている状態のこと

No More サイロ

オペレーションと開発が別々のチーム（昔はメジャーだったが今では古いスタイル）
ナレッジの極端のサイロ化, 個別最適, コラボレーションの欠如 は、多くの場合ビジネスにとって非常に悪い


アクシデントは平常


アクシデントは個人の独立した行動の結果というよりも、失敗時の安全対策がないから
例:

ダメなインターフェースのせいでうっかり間違えてしまう
設計ミスのせいで、間違った状況化で失敗が発生してしまう
計測機器が壊れているせいで、何かがおかしいことに気づかない


古い体質の企業では、間違いを犯した人を探し出して罰する文化を持っている場合がある

結果として、問題を混乱させ、真実を隠し、他者を責めるようになってしまう
生産性のない妨害になっている


アクシデントを防ぐことよりも、素早くリカバリすることに集中した方が有意義

変更は徐々にすべき


変更は小さく頻繁に行うこと

変更は、可能な限り小さいサブコンポーネントに分ける
CI/CDのような変更管理へのアプローチにつながる


ツールと文化は相関している


ツールはDevOpsの重要な要素

特に変更管理


ツールも重要だが、文化はもっと重要

良い文化は悪いツールを回避できる. 悪い文化では回避できない
"Culture Eats Strategy for Breakfast"

オペレーション同様、変化は難しい


計測はとても重要


計測はビジネス全体で超重要

例: サイロ化をなくしたり、インシデント解決


SREの背景


SRE

サイト信頼性エンジニアリング
Googleの VP of Engineering の Ben Treynor Slossによって作られた用語（＆関連する職務）
DevOpsは、プロダクト開発ライフサイクル全体におけるオペレーションチームと開発チームの間のコラボレーションに関する幅広い原則
SREは仕事上の役割であり、うまく機能することがわかっている一連のプラクティスであり、それらのプラクティスを生み出す信念
DevOpsを仕事への哲学とアプローチと考えると、SREはDevOpsの哲学のいくつかを実装しているということが出来る

"DevOpsエンジニア" よりも、("SREエンジニア"の方が) 仕事や役割の具体的な定義にいくらか近い


class SRE implements interface DevOps
SREを実行するために、カルチャー的な変化が必要なわけではない


オペレーションはソフトウェアの問題である


オペレーションをソフトウェアの問題として捉える

解決するためには、ソフトウェアエンジニアリングの手法を駆使する
幅広い視野を持って解決にあたる


SLOによって管理する


全可用性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とそれ以外のチームで別々のツールを管理するのは難しい

個々のツールの改善に対するメリットが少なくなる


比較対象


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の両方で以下のことが当てはまる
Narrow, Rigid Incentives Narrow Your Success

狭く、厳格なインセンティブは成功を狭めてしまう


インセンティブ

間違ったインセンティブは全体のパフォーマンスを悪化させる
厳密にリリースや信頼性に関連する成果と紐づけて定義・構造化してはならない.
数値目標があると、数字だけを良くするようにしてしまう

適切な妥協点を見つける自由を与える


システム設計に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
No results found