1.1～1.2途中まで

SREの誕生背景

• 旧来は一つのエンジニアチームが開発もインフラ構築・運用も行っていたが、サービスの拡大に伴い、一つのチームで見きれなくなった（複雑化した）ことでシスアドと開発の役割が分断された。
• シスアドが抱えている課題を解決するためにSREが誕生した
  • シスアドの課題とは？
    • ①サービスが拡大するとともにシスアドの人数を増やす必要があった
    • ②シスアドと開発の組織サイロ化

課題① サービスが拡大するとともにシスアドの人数を増やす必要があった

• 基本的に運用の作業が手動になっていた
  • 例：システムの拡大に向けてサーバを増やす、ロードバランサの設定をする、監視の設定を入れるとかが必要
    • 特に大規模なシステムであればあるほど、これを手作業でやるのは限界があるよね
  • これを手作業でやることを前提に置くと、シスアドの人数を増やす必要がある

課題② 組織サイロ化（組織分断）

• なぜシスアドと開発が仲悪くなる（サイロ化する）のか？
  • 開発は好きなときに新機能をデプロイしたい（活発）
  • シスアドは変更を加えたくない（安定）※手作業が増えるし、機能リリースに伴う障害発生時に対応に追われてしまうため
• 組織を分断した初期からサイロになるのではなく、時間の経過とともに徐々にサイロ化が進む
• 事業レイヤの視点だと、どちらの視点も大事である
• チームごとに部分最適したが、その結果交わる点が少なくなり、交わったときに事故る結果となる
  • 活動の範囲が重なったところで衝突が起こるとコラボレーションが起きないので成長しない
    • 異なるチーム間でのコラボレーションは事業成長を加速させるので非常に大事

衝突の具体例

以下のシチュエーションが思いつく

• デプロイメントの観点

  • 開発：迅速なリリースを重視（高頻度でデプロイ）
  • 運用：安定性を重視（厳格な変更管理）
    → リリースプロセスが停滞

• インフラ更新の観点

  • 開発：新技術導入に伴い、バージョンアップや新しいミドルウェアの導入を希望
  • 運用：既存構成の安定性を優先
    → 技術的負債の蓄積

どちらも大事なんだけどトレードオフの構図になっている

SREによる解決アプローチ

• 開発と運用の境界をなくす
• 自動化で安定性と俊敏性を両立

1.2まで

SREとはなんなのか？

• SRE（サイトリライアビリティエンジニアリング）とは、SWE（ソフトウェアエンジニア）に運用の設計を依頼したときにできあがるものである

  • =SWEが運用をやろうとしたときに出来上がるもの
    • シスアドの日々の運用業務をSWを使って効率化・自動化するということ
  • シスアドは基本的に開発のスキルセットやプログラムを使う機会がない

• 手作業が減ったことにより、サービスが拡大するとともにシスアドの人数を増やす必要があった 課題が解消される。SWによって作業が置き換わるので。

• インフラをIaCで管理する手法もSWEがシスアド業務をする中で生まれたのかも

  • クラウドネイティブな時代においてインフラエンジニアもコードを書けないといけない世界線になってきた

• Googleはお互いのチームの役割をシャッフルした（SREは新しい役割として定義され、従来の役割の単純な混合ではないが）

  • SWEに運用の業務をやらせる一方で、シスアドもSWEの業務をやるようになった
    • これによりお互いSWの理解がある状態（SWを媒介にして）で、少しづつ組織の境界が曖昧になった。これにより、組織サイロが解消していった
  • 組織サイロを解消するには、組織の目的を重ねる必要がある（お互いが同じ方向を向いた）

具体的なプラクティス

• Googleの50%ルール。SREは50％の時間を開発業務に充てている
  • このルールを管理・徹底するうえでは、誰がいつなんの業務を行っていたのかを計測できるようにしないといけない

SRE誕生後の課題

• 運用とソフトウェアエンジニアリングの両方に精通した人材の希少性
  • 当時、SREのアプローチは斬新すぎるし、シスアドはソフトウェアをかける人が少ないので、採用に苦戦したらしい。
• 従来の職務区分やキャリアパスとの不一致
• 新しい評価基準の必要性

SREの採用・育成にあたっては、人事や経営層（非エンジニアリング組織）がSREの必要性を理解・協力してもらうのが必要不可欠。

コラム

DevOpsとSRE

• DevOpsの文脈で「運用の業務をアジャイルで回すにはどうすればいいのか？」がアジャイルカンファレンスで課題提起された
• DevOpsとSREの領域はかぶるところがある、棲み分けは難しいところ
• SREはDevOpsよりも具体的

1.3

どうやってSREに取り組んだか？

• Googleは50%ルールは厳格にやっている書きっぷり
• オンコールを受けたメンバーがポストモーテムを書いて次に活かすことはものすごい価値が高いとGoogleのSREエンジニアは言っている
  • ポストモーテムをするうえで重要なのは人の失敗を非難しないこと。再発しないようにするにはどうするか、次に活かすために何を改善するべきかを皆で建設的に議論することが大事
• 50%ルールが前提になったときに、ずーっとオンコール対応ばっかりやっているとすぐにバジェットを消費してしまう。なので、障害がそもそも起きないように根本対策するなり障害対応をSWを使って工数減らしていくなどの取り組みが必要

SLO/エラーバジェット

• イノベーションの加速とプロダクトの安定性はバランスをとりながらやっていきましょうが前提にある（安定性＝信頼性ではない）

  • これを実現するためにエラーバジェットの概念を導入した
    • これだけエラー起きてもいいよという予算
    • 100%安定性を求めてしまうとイノベーションは起きない
    • 90%安定していればいいので、残り10％はイノベーションの工数に使うとか
      • 上記の％指標がSLO。

• 事業領域でいうと、お金は使わないほうが利益は出るけど事業は大きくならない。この考え方をエンジニアリングにも採用した

• エラーバジェットの取り組みを通じて、サービスは成長しているか？長期的に改善していくにはどうすればいいか？を皆で考えることができる

  • SREの役割/カルチャーによって運用と開発、双方の活動の範囲がかぶる
  • 運用側はシステムを止めないことが使命だったが、サービスを止めてまで機能をリリースすることに価値を見いだせるし、視座が上がる

1.3.3 モニタリング

• 旧来の「しきい値を超えたらメール発泡する」は不適切。人間がメールを読んでなにかしらのアクションをとるのかとらないのか判断するのがダメ
  • 人間がアクションを起こすときのみ通知しよう。何でもかんでも送らないこと
    • オオカミ少年化してしまうので
  • 見なくていいものは非同期で溜め込んでおき、必要になったときに後で見ればいい
• システム障害の70％はシステムを変更したときに発生するという統計情報がある

1.4