本を読む会 - SRE サイトリライアビリティエンジニアリング #1

「本を読む会」と題して同僚とSRE本を読み進めています。このエントリは第1章を読んだメモです。ざっくりです。

• 参加メンバ
  • missasanさん, syou6162さん, tomomii
• 第1章担当
  • tomomii

ページ

• Google - Site Reliability Engineering

SRE本を読む会の目的

• SREの思想や考えを知る
• GoogleのSREはどんな基準でものごとの判断や意思決定をおこない、開発実務をおこなっているのか理解する

冒頭でやったこと

本を読む会に求めることをそれぞれ共有しました。

• SREが使うツール Mackerelをサービス開発・運営している。SREを支援したり仕事がやりやすくすることを提案するポジションという観点で自分に何ができるかを考えたい
• インフラ技術や知見を勉強中。SREの考えを知ることで、サービスオーナーシップについて理解を深めたい
• SREというポジションの魅力、技術領域の幅の広さを知った。組織やチーム開発の視点で学びが多そうだ
• SREの思想や考えを知り、組織のあり方について考えたい

tomomii : 読み解きたいこと

• SREの役割
• SREの戦略
  • Hope is not strategy. "願望は戦略にあらず" →どゆこと？

読書メモ

1.1

• 大規模かつ複雑なウェブシステムの歴史
  • システム管理者（シスアド）の役割
  • 開発と運用（DevとOps）の分断によるコストやデメリットに着目
    • Dev : サイトの成長に寄与
      • 新機能を開発し、ユーザーさんがそれを使っている様子を見てみたい
      • 自分でコードを書いて動くものを作る人
    • Ops : ユーザーさんが成長したサービスを安定的に適切な速度で障害発生なく運用し障害発生時の対処をする
      • すでに存在するものを組み合わせて（システムの癖やバグを理解しながら）安定的にシステムを運用する
• 障害はどんなときに発生するの
  • システムになんらかの変更が生じたとき。人為的変更⇄システム変更、両方ある
    • 新機能や新設定をローンチ
    • 機能を追加したことで発生
    • 新しい種類のユーザトラフィックなど
• Dev「好きなものを好きな時に邪魔なしにローンチしたいんジャー」 vs Ops「いったん順調に動いたシステムに変更を入れたくないんジャーー」
  • ↑ 対立的で病的なバトル

1.2

• SREとは、ソフトウェアエンジニアに運用チームの設計を依頼した時に生じる（力を発揮する）エンジニア組織である
  • SRE is what happens when you ask a software engineer to design an operations team.
• SREの業務領域
  • 50~60% : ソフトウェアエンジニア
  • 残り： + Unixシステム +システムネットワーク
• SREチームを立ち上げてから
  • 運用チームが行なっていたことを自動化
  • SREは自動化やソフトウェアを開発を厭わない人を充てる
  • そしてSREチームとして、ソフトウエアエンジニアリングに注力することを求めた
• どんな人がSREの適性にフィット?
  • 手作業のタスクに飽きる、自動化したい ≒ 運用に頼らない、システムで解決できるようにする
  • 自動化できるスキルセットを持っている ≒ 運用に頼らない、システムで解決できるようにする
  • ソフトウェア開発に適したアカデミックな知識経験 ≒プロダクト開発の効率化、生産性向上に貢献できる
• SREチームをつくって見込める効果
  • 開発/運用の分断による機能不全を回避
  • 加えてプロダクトチームの停滞も改善。SREとプロダクト開発エンジニアを異動させることで相互トレーニングを実施。Reliability 向上の循環を促す組織構造をつくる
  • 結果として 分散システムの構築方法を学ぶ機会を醸成 > エンジニア全体が幅広い技術領域を扱える理想のすがたに
• SREの採用難易度
  • 高

DevOps ? or SRE?
・DevOpsの定義はいまだに固まっていない
　・システムの設計と開発のフェーズに役割を持たせる
　・人手ではなく自動化を進める
　・運用タスクにエンジニアリングのpracticeとツールを適用
つまり DevOps ≒ SRE??
 DevOpsはSREの中核的な方針のいくつかを幅広い組織、管理の構造、個人に対して一般化
 SREをDevOpsに独特の拡張を加えたプラクティス

1.3

• SREの信条
  • サービスの可用性、レイテンシ、パフォーマンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任をもつ
    • ↑Ops の概念に近い

1.4

始まりの終わり

「願望は戦略にあらず」の意味が見えてきた気がする

• SREはDevとOps 双方の「こうなればいいな」を実現するためのエンジニアではなさそうだ
• SREのお仕事
  • サービス特性ごとの "Site Reliability"が何かを見極め、システム基盤に最適な設計を決めてソフトウェアエンジニアリングでウェブシステム基盤を開発する
    • だから'worked much closer with subset of devs' で 'more coding' が必要なんだな〜
      • fullset ⇄ subset

わかったこと

• SREの役割
  • ウェブサイトの信頼性（スピード、落ちない、新機能開発しやすい等）を実現し維持する
  • 結果としてエンジニアの生産性向上と開発効率化に貢献
    • ＝ウェブサービスの成長とプロダクト開発エンジニアの生産性を担うエンジニア。ウェブシステム基盤全体のクオリティ責任者。かっこいい
• SREの戦略
  • ウェブサイトの信頼性を維持する
  • 信頼性をどう担保するかはサービスによって異なりそうだ
  • システム基盤に必要な要素の優位性と優先度を決めてつくる
• SREが生まれたきっかけ
  • Googleが思い切った判断をした
  • ウェブシステムの基盤開発に何を重視するかを新たに定義したのがすごい
    • DevでもOpsでもなく、SREのミッションはウェブサイトの Reliability. Reliabilityに必要なことはなんでもやる
    • Ops はなるべく自動化し、システムの課題はソフトウエアエンジニアリングで解決する
    • Dev と Ops の対立構造を脱却、ソフトウエアエンジニアリングを重視

感想

• SRE = まるで航空機のパイロットのようだ (tomomii妄想)
  • 信頼性を第一義に考える強い使命感、入念な準備、緊密な連携、刻々と変化する状況への対応など、奥深い世界
  • 過去の知見と計器を頼りに変わりゆく外部環境をつどモニタリングしながら、最適な航路を進むべく判断を繰り返し、安全かつ最適な航路で目的地へ向かう
• 凄腕な庭師にも見えてくる (tomomii妄想)
  • 京都の別荘群 碧雲荘や何有荘を預かる超スゴ腕庭師
  • 外部環境、土、植物、デザイン、設計、季節の移ろいなど数多な条件を知り尽くし、訪れる人たちを楽しませることと庭の整備運用を両立させて息の長い美しい庭をつくることができる
• 参考資料にあげたLinkedInのSREが語るReliabilityのヒエラルキー構造は興味深い

Hierarchy of Reliability

SRE Hierarchy of Needs

1. Metrics and Monitoring
2. Reproducible Builds
3. Stable/Predictable Releases
4. More Communication
5. Dev Ownership (including testing)
6. Build a Team

• 一人で黙々と読むのとは違い、複数メンバーかつ別のバックグラウンドを持つ方の視点をいただけて勉強になりました

ほか

• Mackerelの役割
  • MackerelはSREヒエラルキーにおいて上位とされている Metrics and Monitoring, Capacity Planning そして Testing&Release Procedure (システムに異常がないか正常であるかそしてこのまま飛び続けて問題ないのか、修正するならどこか）のデータを蓄積し監視する
  • SREがシステムをみて判断する際に「なにをもって異常とみなすか、正常とみなすのか」をMonitoring してくれる

参考資料

www.youtube.com

SREcon16 - SRE at a Start-Up: Lessons from LinkedIn

INFRASTRUCTURE & OPERATIONS - How Google Does Planet-Scale Engineering for Planet-Scale Infra

このあと読みたい本と動画

戦略を決めるための道筋や方法論をおさらいしておきたい。

• SREcon18 Americas - If You Don’t Know Where You’re Going, It Doesn’t Matter How Fast You Get There - YouTube

• 戦略にこそ「戦略」が必要だ ―正しいアプローチを選び、実行する

• 競争の戦略

• Martin Reeves: Your strategy needs a strategy | TED Talk

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

第2章 Google - Site Reliability Engineering へつづく

監修：y_uukiさん