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
Incident Response / infra study 3
Search
tjun
June 16, 2020
Technology
3
3.5k
Incident Response / infra study 3
Infra Study Meetup #3の発表資料です。
https://forkwell.connpass.com/event/176885/
tjun
June 16, 2020
Tweet
Share
More Decks by tjun
See All by tjun
SREとしてスタッフエンジニアを目指す / SRE Kaigi 2025
tjun
17
16k
CloudNative環境におけるトラブルシューティングガイド / CloudNative Days Tokyo 2023
tjun
6
2.3k
2023-12-07 SRE Talk クラウドと長く付き合う
tjun
0
210
インシデント対応を改善しよう/2024 TechFeed Experts Night 17
tjun
1
480
メルペイにおけるマイクロサービス運用の苦労と改善 / CloudNative Days Tokyo2020
tjun
16
4.5k
絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長 / SRE Next 2020
tjun
6
19k
メルペイのマイクロサービスとCloud Native / CloudNative Days Kansai2019
tjun
22
23k
メルペイを支えるGKEとCloud Spanner / 2019 Google Cloud Architect Night 1
tjun
1
2.5k
メルペイのマイクロサービスの構築と運用 / CloudNative Days Tokyo2019
tjun
27
15k
Other Decks in Technology
See All in Technology
AIとともに歩んでいくデザイナーの役割の変化
lycorptech_jp
PRO
0
550
Copilot Studio ハンズオン - 生成オーケストレーションモード
tomoyasasakimskk
0
150
Digitization部 紹介資料
sansan33
PRO
1
5.6k
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
43k
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
940
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
OpenTelemetry が拡げる Gemini CLI の可観測性
phaya72
2
540
「改善」ってこれでいいんだっけ?
ukigmo_hiro
0
370
LLMプロダクトの信頼性を上げるには?LLM Observabilityによる、対話型音声AIアプリケーションの安定運用
ivry_presentationmaterials
0
620
物体検出モデルでシイタケの収穫時期を自動判定してみた。 #devio2025
lamaglama39
0
240
[VPoE Global Summit] サービスレベル目標による信頼性への投資最適化
satos
0
140
RDS の負荷が高い場合に AWS で取りうる具体策 N 連発/a-series-of-specific-countermeasures-available-on-aws-when-rds-is-under-high-load
emiki
7
4.3k
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
115
20k
How STYLIGHT went responsive
nonsquared
100
5.8k
How GitHub (no longer) Works
holman
315
140k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
The Straight Up "How To Draw Better" Workshop
denniskardys
238
140k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Scaling GitHub
holman
463
140k
Transcript
Incident Response Infra Study Meetup #3 LT Merpay SRE @tjun
Junichiro Takagi https://speakerdeck.com/tjun/infra-study-3
「インシデント対応やってますか?」
今日のテーマ Incident Response • できればやりたくない • でもSREをやるなら避けられない • どうすれば、より健全なIncident Responseができるか
今日の話は https://response.pagerduty.com/ の超ざっくりしたまとめ なので、詳しくは読んでほしい
はじめに Incident とは 予期せず提供しているサービスが利用できない状態になったり、 期待している機能が提供できない状態
はじめに Incident とは 予期せず提供しているサービスが利用できない状態になったり、 期待している機能が提供できない状態 Incident Response とは Incidentを解決・管理するための組織的なしくみ。 問題を解決するだけでなく、被害を減らしたり解決までの時間やコストを減らす
取り組みも含まれる。 エンジニアだけじゃなく、Customer Support、PM、PRなども関わる。
Incident 前に やること • 心構え: Incidentは必ず起きる…! • Incident, Severity を定義する
• Trigger を用意する • 役割を決める(Incident Commander等) • コミュニケーションの仕組みを 用意する
Incident 中に やること • 心構え: 慌てない • 必要なメンバーを招集する • 役割ごとに必要な対応を行う
◦ Incident Commander 関係者に連絡しSlackで指示を出す ◦ エンジニア 問題を調査し解決方法を提案・実行する
Incident 後に やること • 心構え: Blameless ( 人を責めない ) •
Post-mortem(振り返り) を行う ◦ What Happened? ◦ Impact ◦ Resolution ◦ Timeline ◦ うまくできたこと、だめだったこと ◦ Action Items
Incident Response をはじめよう 1. インシデントを定義する 2. コミュニケーションの仕組みを作る ◦ アラート設定、Slackで集まるChannel、などを用意 3.
インシデント対応の役割を決める ◦ Incident Commanderを決める 4. Post-mortemのテンプレを作る ◦ https://landing.google.com/sre/sre-book/chapters/postmortem/ などが参考になる 5. 練習する 6. 実際のインシデントで実行する
まとめ • Incident Response はSREだけのものではない、組織的な 仕組みづくりが必要。できるところから始めよう • 適切な準備をして、健全な運用を作りましょう