Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
成り立ちから押さえるSRE
Search
iwamot
PRO
September 09, 2022
Technology
2
800
成り立ちから押さえるSRE
2022-09-09
ENECHANGE Tech Talk (社内勉強会)
iwamot
PRO
September 09, 2022
Tweet
Share
More Decks by iwamot
See All by iwamot
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた CODT 2025 クロージングイベント版
iwamot
PRO
1
47
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた
iwamot
PRO
3
67
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
13
9.5k
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
1k
名単体テスト 禁断の傀儡(モック)
iwamot
PRO
1
510
クォータ監視、AWS Organizations環境でも楽勝です✌️
iwamot
PRO
2
510
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
PRO
22
22k
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
PRO
3
1.3k
始めないともったいない!SLO運用で得られる3つのメリット
iwamot
PRO
1
160
Other Decks in Technology
See All in Technology
PRDの正しい使い方 ~AI時代にも効く思考・対話・成長ツールとして~
techtekt
PRO
0
570
LLM翻訳ツールの開発と海外のお客様対応等への社内導入事例
gree_tech
PRO
0
440
【 LLMエンジニアがヒューマノイド開発に挑んでみた 】 - 第104回 Machine Learning 15minutes! Hybrid
soneo1127
0
260
「魔法少女まどか☆マギカ Magia Exedra」の必殺技演出を徹底解剖! -キャラクターの魅力を最大限にファンに届けるためのこだわり-
gree_tech
PRO
0
450
AI時代に非連続な成長を実現するエンジニアリング戦略
sansantech
PRO
3
940
allow_retry と Arel.sql / allow_retry and Arel.sql
euglena1215
1
150
コスト削減の基本の「キ」~ コスト消費3大リソースへの対策 ~
smt7174
2
330
実践アプリケーション設計 ①データモデルとドメインモデル
recruitengineers
PRO
5
1.5k
退屈なことはDevinにやらせよう〜〜Devin APIを使ったVisual Regression Testの自動追加〜
kawamataryo
4
1.2k
2025年になってもまだMySQLが好き
yoku0825
8
3.4k
新規案件の立ち上げ専門チームから見たAI駆動開発の始め方
shuyakinjo
0
660
生成AI時代のデータ基盤
shibuiwilliam
4
2.6k
Featured
See All Featured
Making Projects Easy
brettharned
117
6.4k
Scaling GitHub
holman
463
140k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
For a Future-Friendly Web
brad_frost
179
9.9k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Become a Pro
speakerdeck
PRO
29
5.5k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.6k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Navigating Team Friction
lara
189
15k
YesSQL, Process and Tooling at Scale
rocio
173
14k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
How to Think Like a Performance Engineer
csswizardry
26
1.9k
Transcript
成り立ちから押さえるSRE 2022-09-09 ENECHANGE Tech Talk (社内勉強会) CTO室 岩本隆史 (@iwamot)
SRE略史 2003: Ben Treynor (Benjamin Treynor Sloss) 氏がGoogleに入社 Productionチームのマネジメントを担当 DevとOpsの対立を解決する「エラーバジェット」を発案
運用プラクティスを「Site Reliability Engineering (SRE)」と命名 2014: SRECon14にて同氏が基調講演 (YouTube) 2015: メルカリのインフラチームがSREチームに名称変更 2016: 『Site Reliability Engineering』出版 2018: 『The Site Reliability Workbook』出版
DevとOpsの対立 Dev: 好きなものを好きなときに邪魔なしにローンチしたい 信頼性が軽視されすぎ Ops: いったん動いたシステムは一切変更したくない 信頼性が重視されすぎ
Ben Treynor氏の気づき 100%を信頼性の目標とすることは誤り ユーザー~サービス間の可用性は99.999%よりもはるかに低い PC・Wi-Fi・ISP・電力網など多くの別システムが介在する 岩本註:CloudFrontのSLAは月間稼働率99.9%
エラーバジェットの発案 信頼性の目標が99.9%なら、0.1%のエラーは許容できる この0.1%をエラーの予算とみなす 予算を超えない限り、機能をローンチしてよい 予算を超えたら、信頼性の回復にのみフォーカスする DevとOpsが同じ目標を共有できる
SRECon14基調講演で示されたSRE (1) Hire only coders SREにはソフトウェアエンジニアリングのスキルが必要
SRECon14基調講演で示されたSRE (2) Have an SLA for your service Measure and
report performance against SLA Use Error Budgets and gate launches on them
SRECon14基調講演で示されたSRE (3) Common staffing pool for SRE and DEV Excess
Ops work overflows to DEV team Cap SRE operational load at 50% Share 5% of ops work with DEV team 運用作業 (トイル) が勤務時間の50%を超えたらDevに差し戻す トイルの例:割り込み対応・オンコール・リリース 残りの時間は主にトイル削減に費やす トイルはサービスの成長に比例する (採用では追いつかない)
SRECon14基調講演で示されたSRE (4) Oncall teams at least 8 people, or 6x2
Maximum of 2 events per on-call shift 多ければ忙しすぎ、少なければ時間の無駄
SRECon14基調講演で示されたSRE (5) Post mortem for every event Post mortems are
blameless and focus on process and technology, not people 学びがなければインシデントが繰り返される 非難は問題を隠蔽する文化を醸成する
Googleでの実例 (2011) ネットワーク運用チームの人的リソースが不足し始めた トイルが原因と気づき、自動化を進めた 1年後、手動対応は例外となった システムの信頼性がはるかに向上した 出典:ごく普通のエンジニアリング運用チームを強力な SRE チームに 変える
各プラクティスの関係性 (岩本の理解) 信頼性の目標 (SLO, Service Level Objective) 策定が最重要 信頼性を維持・改善する施策 トイルの削減
(50%ルール) 非難のないポストモーテム 適切な負荷のオンコール
参考記事 e34fmの#3からSREについての概要を文字起こししてみた Introducing Google Customer Reliability Engineering (CRE)