Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
SRE study group 1st slide
Search
Korenaga Makoto
April 12, 2020
Technology
79
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
SRE study group 1st slide
Korenaga Makoto
April 12, 2020
More Decks by Korenaga Makoto
See All by Korenaga Makoto
SRE study group 4th slide
hapoon
2
130
SRE study group 3rd slide
hapoon
1
82
SRE study group 2nd slide
hapoon
1
83
Slackアプリを使ってデイリースクラムを効率化
hapoon
1
620
モノリシックからマイクロサービスへ
hapoon
0
130
Other Decks in Technology
See All in Technology
検証フェーズはAIの回答を判断するための学習機会
toru_kubota
2
490
Meet AgentCore Identity Consent Portal
hironobuiga
3
190
[2026 Oracle Technical Deep Dive] Apache Iceberg × Oracle AI Database -Oracle Autonomous AI Lakehouseが実現するAI時代のデータ基盤- (2026年9月17日開催)
oracle4engineer
PRO
0
100
DAMOS - The Smart Cruise Control for RAM
ennael
PRO
1
130
サーバーフルコンピューティング?AWS Lambda
iwatatomoya
1
240
LLM機能を自作して分かるSnowflake Cortex AIの強み
nayuts
0
280
個別開発で終わらせない。 現場の課題をプロダクトの強さに変える StockmarkのFDE
ktkrhr
0
580
ミイダス株式会社 テックチームのご紹介 / MIIDAS Tech Team
miidas
0
140
Apache Iceberg が拓く AI 時代のオープンレイクハウス
tomtanaka
0
220
More Freedom on the Same Shared GPU Cluster: A Small Team’s Experience with vCluster
nttcom
0
130
AI 時代の Azure エンジニアリング ~ 私たちは何を磨き、何を任せるのか ~
chack411
1
430
生成AIを使って「人が」考える技術 ― AI時代の人機共想と実践ノウハウ|UNITT AC2026
ishiirikie
0
550
Featured
See All Featured
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
570
Context Engineering - Making Every Token Count
addyosmani
9
1.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
550
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
350
The Mindset for Success: Future Career Progression
greggifford
PRO
0
520
The Invisible Side of Design
smashingmag
301
52k
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
540
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.9k
How to train your dragon (web standard)
notwaldorf
96
6.8k
What does AI have to do with Human Rights?
axbom
PRO
1
2.4k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
320
Transcript
Site Reliability Engineering Introduction DevOps unit study group Makoto Korenaga
アジェンダ 1. サービス管理へのアプローチ 2. SREの責務
サービス管理へのアプローチ
システム管理者 役割 既存のソフトウェアコンポーネントを組み合わせサービスを運用・管理 DevOpsにおける「Ops(運用)」を担当 (プロダクト開発者は「Dev」)
システム管理者 メリット 1. 業界で馴染みのあるパラダイムで比較的実施しやすい 2. 既存のツールやソフトウェアコンポーネントを利用すれば、熟練していないチー ムでも車輪の再発明やゼロからの設計なしに運用可能
システム管理者 デメリット 1. 手作業に頼るチームだと、サービス成長や負荷増大に伴いコストが増加していく 2. サービスに障害が発生しないよう、極力新機能リリースをしたくない (開発チームとの対立)
サイトリライアビリティエンジニアリング 役割 1. 手作業でこなしてきたタスクを代替するソフトウェアを書くのに必要なスキルセッ トを持ち、人手による管理を自動化する 2. 運用業務と運用自動化の開発業務の両立
サイトリライアビリティエンジニアリング メリット 1. システム自動化の為に直接コードを修正できる 2. SREの人数はシステムのサイズに比例しない(自動化により人手を離れる為) 3. 開発と運用の分断による機能不全を回避し、プロダクト開発チームとSREチーム 間の異動も容易
サイトリライアビリティエンジニアリング デメリット 1. 採用が難しい(開発と運用の両面で基準を満たす人間が少ない) 2. 新しい概念なので、構築や管理に関する情報がまだ少ない
SREの責務
継続的なエンジニアリングへの保証 運用作業だけでなくコーディングを行うことが求められる 運用作業量をモニタリング、超過作業はプロダクト開発チームへ差し戻す等してコー ディングによる自動化に注力できる時間を保証する
SLOを維持しつつ変化速度を最大化する エラーバジェットの導入 100%の信頼性を目標とすることは、基本的にいかなる場合にも間違っている 達成の為に、 1. 段階的ロールアウト(新機能を利用できるユーザーを徐々に増やす) 2. 1% experiment(トラフィックの1%のみを対象とした実験) などの方法を導入する
モニタリング ソフトウェアが解釈を行い、通知は人がアクションを行う必要がある時だけ行うように する 1. アラート 人が即座に状況を改善する必要がある 2. チケット 人がいずれ状況を改善する必要がある 3.
ロギング 普段人が見る必要はないが、診断、フォレンジックの為に記録
フォレンジック セキュリティ事故など発生時に残された 証拠から調査・分析・報告することを指し ます。
緊急対応 信頼性 • 平均故障時間(Mean Time To Failure) • 平均修復時間(Mean
Time To Repair) MTTRの改善 • オンコール手順書 • ディザスタロールプレイング
変更管理 70%のサービス障害は、動作中のシステム変更によって生じる • 漸進的なロールアウトの実装 • 高速かつ正確な問題の検出 • 問題が生じた際の安全なロールバック 上記を自動化することで、慣れ、軽視、不注意による障害やメンバーの疲労などの問 題を解消することが可能
需要予測とキャパシティプランニング 予想されている未来の需要に対して必要な可用性を提供できるキャパシティと冗長 性を保証する • 自然な成長(顧客によるプロダクト導入と利用から生じるもの) • 突発的な成長(新機能のローンチ、マーケティングによるキャンペーン)
需要予測とキャパシティプランニング キャパシティプランニング • 自然な需要の正確な予測とキャパシティのリソース確保に必要なリードタイム • 突発的な需要の発生源を正確に把握すること • 計算リソースのキャパシティとサービスキャパシティの関連を把握する為の定期 的なシステム負荷テスト
プロビジョニング 変更管理とキャパシティプランニングの組み合わせ 必要な際に素早く、かつ正確に実施する必要がある
効率とパフォーマンス リソースの効率的な活用 = 費用(コスト)の最適化 需要(負荷)、キャパシティ、ソフトウェアの効率性を考慮 モニタリングと改修に努め、サービスのパフォーマンスを改善する
「願望は戦略にあらず」 - SREの格言
次回予告
SREの観点から見たGoogleの プ ロ ダ ク シ ョ ン 環 境
第弐回
ありがとうございました 参照: SRE サイトリライアビリティ エンジニアリング Googleの信頼性を支えるエンジニアリングチーム (オライリー・ジャパン)