「本を読む会」と題して同僚とSRE本を読み進めています。このエントリは第1章を読んだメモです。ざっくりです。
- 参加メンバ
- missasanさん, syou6162さん, tomomii
- 第1章担当
- tomomii
SRE本を読む会の目的
- SREの思想や考えを知る
- GoogleのSREはどんな基準でものごとの判断や意思決定をおこない、開発実務をおこなっているのか理解する
冒頭でやったこと
本を読む会に求めることをそれぞれ共有しました。
- SREが使うツール Mackerelをサービス開発・運営している。SREを支援したり仕事がやりやすくすることを提案するポジションという観点で自分に何ができるかを考えたい
- インフラ技術や知見を勉強中。SREの考えを知ることで、サービスオーナーシップについて理解を深めたい
- SREというポジションの魅力、技術領域の幅の広さを知った。組織やチーム開発の視点で学びが多そうだ
- SREの思想や考えを知り、組織のあり方について考えたい
tomomii : 読み解きたいこと
- SREの役割
- SREの戦略
- Hope is not strategy. "願望は戦略にあらず" →どゆこと?
読書メモ
1.1
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
- だから'worked much closer with subset of devs' で 'more coding' が必要なんだな〜
- サービス特性ごとの "Site Reliability"が何かを見極め、システム基盤に最適な設計を決めてソフトウェアエンジニアリングでウェブシステム基盤を開発する
わかったこと
- SREの役割
- ウェブサイトの信頼性(スピード、落ちない、新機能開発しやすい等)を実現し維持する
- 結果としてエンジニアの生産性向上と開発効率化に貢献
- =ウェブサービスの成長とプロダクト開発エンジニアの生産性を担うエンジニア。ウェブシステム基盤全体のクオリティ責任者。かっこいい
- SREの戦略
- ウェブサイトの信頼性を維持する
- 信頼性をどう担保するかはサービスによって異なりそうだ
- システム基盤に必要な要素の優位性と優先度を決めてつくる
- SREが生まれたきっかけ
感想
- SRE = まるで航空機のパイロットのようだ (tomomii妄想)
- 信頼性を第一義に考える強い使命感、入念な準備、緊密な連携、刻々と変化する状況への対応など、奥深い世界
- 過去の知見と計器を頼りに変わりゆく外部環境をつどモニタリングしながら、最適な航路を進むべく判断を繰り返し、安全かつ最適な航路で目的地へ向かう
- 凄腕な庭師にも見えてくる (tomomii妄想)
- 京都の別荘群 碧雲荘や何有荘を預かる超スゴ腕庭師
- 外部環境、土、植物、デザイン、設計、季節の移ろいなど数多な条件を知り尽くし、訪れる人たちを楽しませることと庭の整備運用を両立させて息の長い美しい庭をつくることができる
- 参考資料にあげたLinkedInのSREが語るReliabilityのヒエラルキー構造は興味深い
ほか
- 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
戦略にこそ「戦略」が必要だ ―正しいアプローチを選び、実行する
- 作者: マーティン・リーブス,クヌート・ハーネス,ジャンメジャヤ・シンハ,御立尚資,木村亮示,須川綾子
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2016/02/16
- メディア: 単行本
- この商品を含むブログ (2件) を見る
- 作者: M.E.ポーター,土岐坤,服部照夫,中辻万治
- 出版社/メーカー: ダイヤモンド社
- 発売日: 1995/03/16
- メディア: 単行本
- 購入: 11人 クリック: 145回
- この商品を含むブログ (79件) を見る
- Martin Reeves: Your strategy needs a strategy | TED Talk
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- 作者: 澤田武男,関根達夫,細川一茂,矢吹大輔,Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/08/12
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
第2章 Google - Site Reliability Engineering へつづく
監修:y_uukiさん