SREエンタープライズロードマップを読んでみた

目的

読んだうえで、自分の考えや、今後何ができるか書いてアウトプットする！

序文

企業にSREを導入する課題について掘り下げてくれる
信頼性は大きな差別化要因なので重要
　→信頼性がなく、よく落ちるサービスは使いにくい

第1章 エンタープライズSREことはじめ

進化は革命に優る

今までの蓄積があるのだから、それを無視して革命的にSREを導入しても反発に遭う可能性が高い
既存のフレームワークを改善する過程でSREを導入していくべき！
　→それはそうよね。今のやり方で売り上げが立っているなら、それは正しい

SREの実践はITILフレームワークと共存できる

ITIL：ITサービスの構築と運用方法をまとめている？
ITILはフレームワーク、SREはプラクティスの集合体なので、結果は同じでも経路が異なることがある
　→大きくずれているものではないので、良いところを使っていこうってことかな

DevOps、アジャイル、リーン

SREとDevOpsは補完関係にあるので、重複する部分がある。
そもそも、SREの導入前提にDevOpsの多くの機能（バージョン管理やレビュー）は必須になっている！
ただし、SREの取り組みをしていくには、現実的であることが必要！
　→理想論だけ語って大幅に変更をするのではなく、実践できることを少しづつやっていこうと理解

今いる場所から始める

→ 現在の状況を把握して、なぜSREを導入するのか説明できないとそもそも提案できない

期待することと目指す姿を概説する

SREの目標は信頼性の達成
これをするために、いろんなことをやる
　→何を期待して導入するかを論理的に言えないと、効果が出ないよねと理解。
　　仮のゴールを決めて、それで何が得られるかということ

SREは「人」から始める

SREを成功させるには文化を作っていくことが必要！
SREは文化的な要素と技術的な要素がある
なので、文化を機能させるには、人が大事！
　→一人でやればいいというものではないので、文化作りやトレーニングが必須！

自分らしさを大切にする

→前提が全員異なるので、SREを導入する正しい方法は、その組織で成功した方法だけ！
改善の好循環を続けていかないといけない

第1章自分的まとめ

組織には既存のやり方がある以上、全部ひっくり返してSREの導入は不可能
だから、今の状況を把握して、現実的に考えて、できる改善としてSREのプラクティスを導入していくのが良い
また、SREは文化も大事なので、文化作りをやっていく必要がある！
文化を作るっていまいちイメージがつかないので、LTや勉強会などあさって見た方が良さそう

第2章なぜ信頼性のためにSREというアプローチをとるのか？

SREが謳われる前から、信頼性・品質・稼働率は改善されてきた。
SREとは何が違うのか？

信頼性を製品の主要な差別化要因にする

セキュリティと信頼性が差別化要因なので、力を入れるべき！
欲しい時に使えなければどんな良い製品でも価値が出せないため、製品で最も大事な機能

いつ信頼性を重視すべきか

スタートアップなら、PMF（Product Market Fit）を作った後、早めに信頼性に力を入れるべき！
セキュリティや信頼性の観点のサービスやツールもコモディティ化してきているので、活用しよう
　→具体的に思いつくのはNew RelicやDatadogなどO11yとか、Snykとかかな
「成長の3つの地平線（ホライズン）」モデルを利用して、信頼性への投資計画を作ると良い？
信頼性を確保したとしても、変更しにくいシステムではマーケットについていけないし、競合に負ける
ホライズン１(0~18ヶ月)ではSREを適用して目の前の課題を解決しつつ、ホライズン２でSREをベースに成長を考え、ホライズン３で事業を拡大していく？
　→ホライズンモデルがよくわかってない

なぜ今SREなのか？

従来のインフラは全てのコンポーネントが動いている前提だったが、今は故障を想定したアーキテクチャになる
　→可用性が100%のサービスはほぼない以上、落ちることは前提として設計しなければならない！
　だから、信頼性を確保することをしていかなければならない？

Googleの後光を超えて

Googleはスケールアップではなくスケールアウトできるようにして、一部のマシンが壊れても良いようにソフトウェアで対処した。これなら、台数の増加に伴って運用チームとコストをスケールさせないでいい。SREの原点
　→頭いいわ...
SREの人員配置 ：サブリニアスケーリング。システムの使用量が２倍になっても、運用担当者は２倍になってはいけない！
　→これ重要
　→少ない人数で、大きな成果を求める。Googleでよく聞く10X思考？かな
システムの成長や追加に伴って作業を増やさないように積極的な防止が必要　→　toilの削減につながる！

なぜ伝統的なオペレーションを増やさないのか

SREを活用することで、規模の拡大とコスト削減を同時に達成する！
安い労働力を探してコスト削減という方法は一般的だが、システムの成長が阻害され、障害発生時の予期せぬコストが増えやすい
そのためにはSREチームに適切な人材（SREやプラットフォームエンジニア）が必要で、高いコストに見えるが、未熟な人を多く雇うよりは良い。そもそも、昔からやっているからと、経験になりにくいことをやらせない方がその人のためになる。
SREチームの拡充方法

• 既存のチームを進化させる：良い
  • 適切なインセンティブを与え、既存従業員の変革する。人は資産
  • コアビジネスをわかっている人がやるのが一番速い
  • →採用はコストだから、離職ではないということ？
• 専門家を雇う：効果が低いかも
  • どうしても、コアビジネスの理解が浅くなるから
• スタッフの増員やオフショア：効果が低いかも。コストは高くなるもの

→信頼性は競合との差別化ポイントなんだから投資を惜しむな！ってことなのか？
ホライズン２の目標として、プラットフォームを計画して、将来を見据えた信頼性の改善をしよう

第2章自分的まとめ

信頼性は競合との差別化要因だから、ちゃんと投資しろ！
チームの人員もそうだし、ホライズンモデルを活用して、目の前の課題も解決しつつ、プラットフォームなど長期的な計画も立てて推進していくべき！
今の世の中、落ちないシステムはないので、落ちる前提でアーキテクチャを設計していかないといかない

ただし、システムの規模に対して運用は線形に増やすな
少ない人数で最大の成果を求めよ

第3章SREの原則

意思決定の指針となるものだから、SREの原則とその精神を理解しとけ！
原則をもとに、あらゆる人がリーダーシップを発揮してやっていこう
Googleのポリシー：「ユーザーに焦点を絞れば、他のものは後からついてくる」
ポリシーは結果に焦点をあて、従業員が安全に活動できるガードレールとなる
　→細かな意思決定まで仰ぐマイクロマネジメントだとスピードが出ないから、個々で判断してやれ。ただし、ポリシーはあるから、それに則っていること！
壮大な計画で進めていくのはアンチパターンなので、フィードバックループの好循環を構築していくことがおすすめ
　→例えは良くないかもだけど誘導ミサイル的なイメージ。対象まで、細かく軌道を制御しつつ進んでいく必要がある。大砲のように、最初に狙いを定めて撃っても、最初の些細なずれが着弾時には大きなずれとなってしまう。大砲は最初以外軌道修正が不可能

以降、SREの原則の概要を説明して、どのように組織に反映させるか

リスクの受容(SRE本 第3章)

最も困難な最初のステップ
　→変化にはリスクもあるってことかな？
❌信頼性と速度はトレードオフ
SREはメンテナンスしていないサービスには不向き
　→継続的な改善をしていないから。塩漬け系システムとか。

• アンチパターン
  • 信頼性100%のサービス
    • →信頼性の9の数を増やすだけで予算の桁が増えるのに100を目指すと膨大な投資がいる。それよりフィードバックループを作る方が大事
  • 「平常時」の運用で99.99%を達成する
    • →障害発生も含んでちゃんと達成しろってこと？

サービスレベル目標(SRE本 第4章)

SLI(サービスレベル指標)を作成し計測する。SLIはサービスレベルの実測値
顧客が必要なものを目標にすることが大事。
　→都合の良い指標に意味はなく、顧客視点がいるってことかな
SLO/SLIを定めても信頼性への効果がないなら、SREも効果が出ないことになる
また、SLOに違反した場合に改善できないなら、意味はない

• アンチパターン
  • SLO＝SLA
    • SLAは顧客との約束
    • SLOはサービス提供側の目標。なので、SLAより厳しくしないとSLAを満たせないことが発生しうる
  • SLI＝OKR(Objectives and key results)/KPI(key performance indicator)
    • グッドハートの法則：数値を目標にすると、それを満たすために本来の目的を忘れてしまうこと
    • →SLIではなく、SLOが大事ってこと？

トイルの削減(SRE本 第5章)

最も大事な原則！
正しいことを早くしたいなら、忙しい仕事(トイル)を50%未満にすべき
技術的負債とは異なるもので、溜め込んで後で返済するものにしてはいけない！
トイルがチームを圧倒すると、改善ができなくなるため、組織にとってのトイルを決めよう
　→トイルってなんだ？要は忙しい仕事を半分以下にして、改善活動ができる余裕を持とうということ？

• アンチパターン
  • 補足的な原則としてのトイル
    • トイルの削減のための時間がなければ、SREを導入する時間もない
    • →それはそう。改善のループを回したいのに、忙しい仕事に忙殺されては進められない
  • トイルの削減が皆で共有されず、１人/1チームの仕事になっている
    • その仕事をしている人が解決する必要がある。オフロードすれば間違う
    • →いまいち意味が掴めないので、SRE本読んだ方が良さそうかも
  • トイル削減週間
    • トイルをなくすには、より継続的なアプローチにしないといけない
      • トイルが忙しい仕事なら、仕事は無限に増えるので、ずっと削減し続けないといけないってことか？

分散システムのモニタリング(SRE本 第6章)

オブザーバビリティのこと
専門分野なので、十分な配慮と検討が必須
システム間の論理的接続を診断して解決するために必要となるので、自分に合ったツールを見つけよう
完璧なダッシュボードより、使い勝手の良いツールを重視しよう！
過剰なアラート＝過小なアラート、どちらも悪い。アクションが必要&できるものだけにアラートを設定すべき
アラートも改善していこう。出ないと疲弊する！
　→今のチームがそんな感じ。学習できていない。

• アンチパターン
  • 無視されるアラート
    • ノイズが多すぎると、本当に大事なアラートにも反応しなくなる。オオカミ少年
    • →これも実際に起きている。なるべく見ているけど、全部は無理
  • SREを置き換える「NoOps」ツール
    • あくまでツールはSREを補強するものなので、置き換われない
    • 運用はどこまでいっても必要
  • 原因に基づくアラート
    • 必要なのは症状の対してのアラート
    • →例えばアクセス数が多いは原因になるけど、それでレスポンスが悪化しているなど症状が出ていなければ、ユーザーから見たら何も問題がない

Googleにおける自動化の進化(SRE本 第7章)

信頼性を極めて高いレベル(99.99%以上)を目指す場合、人間の介入が必要だとほとんど必ずSLO違反（信頼性を満たせない）ことが発生する
　→そうだよねという感じ。99.99%は年間停止時間が 50 分なので、人の手だけではほぼ不可能。
だから、自動化が最も重要
介入はグレースフルフェイル（計画的なノードの削除）、リトライなどプロアクティブ（すでに発生した状況に対して反応するのではなく、その状況を能動的につくるような行動）なメンテナンスに移行していく
自動化は常に、簡単にメンテナンスできる必要がある
　→改善のためにってこと？

• アンチパターン
  • プロセスの品質や適合性に関係なく、自動化を規定している
    • 頻度の低いプロセスなら、プレイブック（運用手順書的なもの）を作成するのがよい解決策になりうる
    • →なんでもかんでも自動化が最適解ではない。投資対効果が得れるものにしようという感じか
  • 「本当に重要な」部分への不必要な人手の介入
    • 人間が関与するのは、意思決定が必要で、その権限を持っている場合にすべき
    • →人手が必要な場合だけに人を呼ぼう。人件費は高いんだ

リリースエンジニアリング(SRE本 第8章)

DevOpsチームの取り組んでいる継続的インテグレーション/継続的デリバリー(CI/CD)と広範囲に重なるもの
ここでも、上からこううやれと押し付けるのではなく、CI/CDを活用することが大事。
　→今いる場所から始める
プラットフォームチームに投資し、リリースサイクルの中でテストを前の段階までシフトしよう
ただし、開発者に過度の負担をかけずいこう
リリースパイプラインはSREの問題の解決策なので、オンコールやメンテナンスのスタッフと密な連携がいる

• アンチパターン
  • DevOps/SREチームがあらゆるもののリリースを行う
    • 職種名が違うだけの運用者
    • →どういうことだ？全員でやれよってことか？
  • リリースエンジニアリングはCI/CDを導入しなければアンらない
    • 継続的デリバリーには、プラットフォームチームと開発チームで基盤を構築する必要がある
    • →これも、いまいち思い浮かばない。SRE本を確認しないと...

簡潔性(SRE本 第9章)

チームの認知負荷も重要な問題
認知負荷に合わせて、チームの合併や分割ができるのが良い
複雑さを減らし、小さく管理しやすくすしよう！
重要な概念は、ローコンテキストとハイコンテキストの比較
SREのコンセプト（プレイブック、ドキュメント、ディザスタリカバリテスト演習）は、、物事をローコンテキスト化するためのもの

• アンチパターン
  • シンプルであれば、理解できる
    • エグゼクティブダッシュボードは、全てを表示できないので、無理に表示させないで良い
    • →どういうことだ...?
  • 年次レビューに基づく静的なチーム
    • ダイナミックなチーム編成は年に１回以上必要！
    • →現実は変わり続けるのだから、それに合わせて変化も必要ってことかな

これらの原則をどのように既存の組織に当てはめるか

この原則を全部を合意できている組織はそうそうない。
Googleと同じにする必要がないが、原則だけは一致させよう！！！
ただし、何をやっていくかは意図的に選択して、意味がない指標がないか再確認しよう
　→原則が指針となるので、原則は認識を合わせよう。あとは、フィードバックループの構築で改善していく！

組織破壊のミスを防ぐ

新しい原則を採用する際、うまくいかないこともある
元に戻すのが最も困難な変更が、まずいことになることもある
元に戻すのが簡単な変更に焦点を当てましょう！！

• アンチパターン
  • コーディングできない運用担当者は全員クビにする
    • クビにした人員は戻せない
  • すべての開発者にrootや本番環境のアクセスを許可する
    • 最小権限であるべき。
    • 自動化でまかなう？
    • →ここも理解はできるが、自動化の文脈がいまいち理解できていない。
  • 業務で最も重要なシステムを選ぶ
    • いきなり大きなゴールは目指せないよ。小さく成功しよう

SRE採用の旅をフェイルセーフにする環境作り

失敗を想定して、そこから学び、改善するのが大事。
　→全て成功は無理
厄介なことをするときは専門家を呼び、複雑なことをするときは失敗の予算を確保しよう！
うまくいったことで評価しよう
→失敗をある程度許容するってことね

• アンチパターン
  • 成功するかぎり、どんなリスクもサポートする
    • 本当のリスク予算は、ある程度の失敗を受け入れること！
    • →成功するならサポートする＝失敗は許さんだから、それだと挑戦しにくいよね

優先順位の相違に注意

信頼性を求めながらも、変化とコストに対する正当性は疑問を持たれる可能性が高い。
変化すると、始めは効果を感じられないこともあるかもしれない。Jカーブ
　→小さな成功をしつつ、大きな成功を狙うってことか？

• アンチパターン
  • あきらめるのが早すぎる。例えば、SREを６ヶ月間試した後、すぐに成果が出ずにやめてしまう
    • 数四半期後に正しい方向へ向かうための明確なシナリオが必要
    • →始めは成果が出ていなくとも、長期的にシナリオを立てておけばOKってことか？

これらの原則に賛同してもらい、必要な同意と支援を得るにはどうしたらよいか

リーダーシップチームが、あなたのやろうとしていることを十分に信じられなくとも大丈夫。
最低限、変化を起こす緊急性を実行する動機があれば良い
　→最低限、信頼性を高める必要がある何かが起きていれば話しやすいってことかな
ただ、SREは信頼性を高めることなので、問題を未然に防ぐと報酬につながりにくい。
SREの取り組みが数ヶ月後に「効果が不十分」という理由で打ち切られないように、明確な投資対効果の測れる指標が必要
継続的な価値を可視化しよう！
　→それはそう。会社に貢献できていないなら意味がないが、問題を未然に防ぐはわかりづらい。
ただし、指標は業態はサービスの内容に依存する！

第4章 SREのプラクティス

２章３章で、SREチームを作って原則を理解したら、次はプラクティスを開発する番！
多くの場合で、開発チームがやっていないこと全部になるが、これは危険。
チームの能力を増やすには、教育が必要。
障害発生の対応など知識の共有など、そういう場は用意すべき
運用チームは、開発チームからシステムに関する知識を得るように推奨すべき
　→今の自分のチームに必要だわ。全体的な統制はしていても、個別のシステムの知識が不足している

何から始めるか

信頼性とSREは領域が広大なので、全部は同時にできない。
チームに能力を追加する場合、チームが次に取り組むべきことを学べるような一連のプラクティスから始めよう！
　→できる、できそうなところからやっていくのがいいよね

どこへ行くのか

何かをする場合、目標設定が大事！
全てのシステムがファイブナイン（99.999%）の高信頼性を目指す必要はない。金もかかるので、投資のレベル設定をしよう
高信頼性が必要ないところに投資をしても意味がない
成功への道は、目標へ向かって少しづつ前進するようにしよう！一度に革命的に物事は進まない！
　→現実いる場所から始めるだわ。
チーム内で新しい何かをする場合、得られる利益を提示しよう
そして、成果は大きく広めようようね
　→嬉しいもんね

どうやって行くのか

長期的な計画は持たず、目指すべき方向性をよく知ろう
　→始めに計画を立てても、途中で色々変わるからだと思う
　　正確な道順が分からずとも、北極星を知っていれば少しづつ向かっていける
特に初期は、短期間で成果をあげ、効果を示し、プラス効果をもたらすことが大事
小さく成功して、複数チームで利用できる汎用的な機能にしていき、プラットフォームを構築までどんどん広げていこう！そうすれば投資効果が拡大する
組織の全てのチームが同じではないので、SREの導入には柔軟にやっていく必要がある
開発チームの現状を把握すれば、日々の問題を解決しつつ、組織全体の規範やベストプラクティスを導入できるチャンスとなる！
　→

SREを可能にするものは何か