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
ほんとうの信頼性はヒーローが死んでからはじまる / True reliability begi...
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
VTRyo
September 17, 2026
Technology
41
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ほんとうの信頼性はヒーローが死んでからはじまる / True reliability begins after the hero dies
2026.9.16 Nokuchi.SRE#0 LT
https://nokuchi-sre.connpass.com/event/404411/
VTRyo
September 17, 2026
More Decks by VTRyo
See All by VTRyo
越境するなら専門用語を使うな高校校歌 / If you wanna cross border, you shouldn't use jargon
vtryo
0
140
なぜ私たちのSREプラクティスはなかなか機能しないのか 〜システムより先に組織を見る〜 / Why our SRE practices aren't really working
vtryo
4
6.2k
飲食店もAIで。レジ締めやハンディシステムをつくってる話 / Using AI for restaurant management
vtryo
0
320
そのSLO 99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜 / Is that 99.9% SLO really necessary? Design philosophy of shared responsibility through prioritized SLOs
vtryo
2
4.1k
あの職員室 / That teachers' lounge
vtryo
0
180
自分だけの、誰も想像できないキャリアの育て方 〜偶然から始めるキャリアプラン〜 / Career planning starting by luckly v2
vtryo
1
580
60以上のプロダクトを持つ組織における開発者体験向上への取り組み - チームAPIとBackstageで構築する組織の可視化基盤 - / sre next 2025 Efforts to Improve Developer Experience in an Organization with Over 60 Products
vtryo
3
3.3k
一体いつからSRE NEXTがSREだけのカンファレンスだと錯覚していた? / When did you ever get the idea that SRE NEXT was a conference just for SREs?
vtryo
1
930
一人から始めたSREチーム3年の歩み - 求められるスキルの変化とチームのあり方 - / The three-year journey of the SRE team, which started all by myself
vtryo
9
16k
Other Decks in Technology
See All in Technology
LLMに渡さなかった仕事
nanaism
0
170
LTのテーマ どうきめてる?〜5つの型と私のやり方〜
yama3133
1
110
Snowflakeのコスト最適化を支えるアーキテクチャ設計
ktatsuya
1
1.6k
ユーザー価値を届け続けるためにウォンテッドリーが大切にしている文化
kotaminato
0
160
10Xに技術的負債をもたらした「2つの境界の歪み」その構造と解消への営み
10xinc
0
1.9k
DEFCON34-Write-up_HYCu-MYCu
daikiokazaki
0
160
OpenTelemetryのメトリクスをCloudWatchに送ってPromQLで見てみた
ota1022
0
150
白金鉱業Meetup Vol.25 アウトカムが二値のデータに対するCausal Impact
brainpadpr
0
210
おい、エージェントを使って終わらせろ
nwiizo
0
270
空間オーディオで過去の 自分(ゴースト)と競うランニング 〜HealthKitのルートを足音に変える実装〜
nao_randd
0
220
Deployment の 先にある AI Agent 基盤 - kagent vNext、Agent Substrate、Hermes から読み解く Agent Runtime の現在地 / k8s-matsuri-2-ai-agent-platform-amsy810
masayaaoyama
3
570
30座EKS, 180次升級淬煉的EKS Upgrade Skill 的歷程
eric8230
0
160
Featured
See All Featured
Design in an AI World
tapps
1
320
How to Ace a Technical Interview
jacobian
281
24k
From π to Pie charts
rasagy
1
370
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
280
Ten Tips & Tricks for a 🌱 transition
stuffmc
1
230
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.6k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
23k
Exploring anti-patterns in Rails
aemeredith
4
510
Testing 201, or: Great Expectations
jmmastey
46
8.3k
Navigating Team Friction
lara
192
16k
How to Talk to Developers About Accessibility
jct
2
550
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
280
Transcript
~/VTRyo/presentation master vtryoctl describe presentation ほんとうの信頼性は ヒーローが死んでからはじまる Nokuchi.SRE#0 / VTRyo
~/VTRyo/presentation master presentation will be started...
10分枠ですが ”LT” だからと ミスって5分で終わる内容に してしまいました🙇 ~/VTRyo/presentation master Twitter: @3s̲hv
自己紹介 • Topotalという会社で SRE as a Service. “Cross company Embedded
SRE” • SRE NEXT, SRE Kaigi, CloudnativeKaigiなどで登壇 • 週末はカレーやってます • ビールの審査員資格有、チョットクワシイ ~/VTRyo/presentation master Twitter: @3s̲hv
組織のヒーロー 豊富な戦闘経験 ドメイン知識 エンジニアリングパワー ~/VTRyo/presentation master 著作権につき いらすとや Twitter: @3s̲hv
ヒロイズムの例 • たとえば障害発生時→超エキスパートが誰よりも早く対応 開始。後片付け(再発防止)もお手の物 • メンバーはその圧倒的な力に感謝🙏 • ヒーローは「私がいないと回らないかも」「常にシステム を良い状態にしておきたい」と思ったりする •
知識と経験Up・承認・査定Upなど ヒーローにはデメリットがほぼない ~/VTRyo/presentation master Twitter: @3s̲hv
実際に見た例 • あるチームのエースがerrorチャンネルにエラーをなんと 全部ひとりで見ていた(割と頻繁) (この人が自分をヒーローと思っていたかどうかは別) • しかしエース退職!メンバーが突然同じレベルの対応を始 めることになり、割り込みと不安が多発。 開発計画に支障が出かけていた ~/VTRyo/presentation
master Twitter: @3s̲hv
ヒーローに頼らなくなってからが ほんとうの信頼性向上 ~/VTRyo/presentation master Twitter: @3s̲hv
マンパワーに頼らないために • エラー一件ずつ全部対応するのは非現実。 一件ごとに一喜一憂してよいのか?しないとしたらどうす ればしなくて済むようになるのか • →監視設定、SLOなどを整備する(当時SLOなかった) →エラーがあってもリリースしてよいのだろうか? という問いにはSLOやエラーバジェットといった数値から 自信を持って実行できる
~/VTRyo/presentation master Twitter: @3s̲hv
マンパワーに頼らないために • 他チームからの割り込みタスク(Help wanted)を「気 づいた人のマンパワー」ではなく当番制に変更 全メンバーが経験できるように調整 • あるドメインに強い人はそうでない人をサポートする • 対応期日
is ベストエフォートをやめる(早いほどよいと なるとヒロイズムが起動してしまう)。期日を設定して当 番制でも成立するように他チームと調整 ~/VTRyo/presentation master Twitter: @3s̲hv
Google SRE資料では • 「ヒーローは個人・チーム・システムにとって有害である」 • 個人には燃え尽きリスク チームにはヒーローに引っ張られて非現実的な期待値を生 み出すリスク システムには長期的な改善ができないことや過剰な保守を 生むリスク
参照: https://sre.google/resources/practices-and-processes/no-heroes/ ~/VTRyo/presentation master Twitter: @3s̲hv
Google SRE資料では • コストに見合わないほどの対応をしなくとも、システムはいき なり壊滅しない事が多い • SLOの設定をするならエラーバジェットポリシーも設定する • ヒーローは豊富な知識と経験があるので、長期的な改善に取り 組むよう依頼する
• など 参照: https://sre.google/resources/practices-and-processes/no-heroes/ ~/VTRyo/presentation master Twitter: @3s̲hv
~/VTRyo/presentation master vtryoctl describe presentation ご清聴ありがとうございました Nokuchi.SRE#0 / VTRyo fi
~/VTRyo/presentation master presentation is nished...