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
September 09, 2022
Technology
2
670
成り立ちから押さえるSRE
2022-09-09
ENECHANGE Tech Talk (社内勉強会)
iwamot
September 09, 2022
Tweet
Share
More Decks by iwamot
See All by iwamot
ECS on FargateへのSeekable OCI導入レポート
iwamot
0
350
サービスクォータ、ちゃんと監視してますか?
iwamot
0
670
AWS Well-Architected Toolで信頼性をレビューした結果
iwamot
0
340
テックカンパニーとしてのENECHANGEの中期目標
iwamot
0
58
AIの活用状況と今後の展望
iwamot
0
49
ENECHANGE社のAWSセキュリティ改革ストーリー
iwamot
0
120
ALBのアクセスログをAthenaで分析してSLOをゆるく決める
iwamot
2
1.1k
ChatGPT in SlackでAI Slackbotを楽しく運用する
iwamot
1
350
Function callingによるSlackbotの機能拡張
iwamot
2
170
Other Decks in Technology
See All in Technology
中年男性がメインフレームから クラウドへキャリアシフトしてみた
uechishingo
1
460
IaCからAWSに入門した初心者が CloudFormationを通して考えた「AWS操作」の使い分け
maimyyym
3
670
データ基盤を支える技術
chanyou0311
5
2.9k
RailsConf 2024 Keynote "Startups on Rails in 2024"
irinanazarova
0
730
テストコードを書きながらCompose Multiplatformを乗りこなす
subroh0508
0
140
CockroachDB はどのくらい「しぶとい」のか? / How tough is CockroachDB?
kota2and3kan
13
4.9k
「知的単純作業」を自動化する、地に足の着いた大規模言語モデル (LLM) の活用
nrryuya
8
8.1k
拓展QA日常工作的邊界
line_developers_tw
PRO
0
490
TanStack Routerで型安全かつ効率的なルーティングを実現
ytaisei
4
760
iThome2024 Wailing Wall of Enterprise Security
notsurprised
0
280
Secrets of a PowerShell "Guru"
guyrleech
1
120
データ分析力を高めるSQL研修サービス『SQL Everyone』
hikarut
1
370
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
76
4.9k
What's new in Ruby 2.0
geeforr
338
31k
Building Flexible Design Systems
yeseniaperezcruz
320
37k
Building an army of robots
kneath
300
41k
Documentation Writing (for coders)
carmenintech
60
4k
What the flash - Photography Introduction
edds
64
11k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
0
110
Writing Fast Ruby
sferik
622
60k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
242
1.2M
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.9k
Music & Morning Musume
bryan
41
5.6k
A Philosophy of Restraint
colly
197
16k
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)