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
障害対応指揮の意思決定と情報共有における価値観 / Waroom Meetup #2
Search
Arthur
November 13, 2024
Technology
5
760
障害対応指揮の意思決定と情報共有における価値観 / Waroom Meetup #2
https://topotal.connpass.com/event/333892/
Arthur
November 13, 2024
Tweet
Share
More Decks by Arthur
See All by Arthur
オブザーバビリティプラットフォーム開発におけるオブザーバビリティとの向き合い / Hatena Engineer Seminar #34 オブザーバビリティの実現と運用編
arthur1
0
420
デフォルトの16:9(960*540px)のケース / Google Slide Size Test
arthur1
0
3.2k
1920*1080pxに設定したケース / Google Slide Size Test
arthur1
0
3.2k
Scalaから始めるOpenFeature入門 / Scalaわいわい勉強会 #4
arthur1
1
780
AWS AppConfigとOpenFeatureで手早く機能フラグを導入する[LT size] / CloudNative Days Winter 2024 船上LT会
arthur1
0
430
go.mod、DockerfileやCI設定に分散しがちなGoのバージョンをまとめて管理する / Go Connect #3
arthur1
13
4.6k
Mackerel開発チームの障害対応演習 ──新卒エンジニアが障害対応指揮官を務めるに至るまでのステップ / Mackerel Drink Up 出張版@福岡
arthur1
0
390
slog登場に伴うloggerの取り回し手法の見直し / kamakura.go #6
arthur1
2
3.7k
otelcol receiver 自作RTA / Pepabo Tech Conference #22 春のSREまつり
arthur1
0
3.6k
Other Decks in Technology
See All in Technology
あとはAIに任せて人間は自由に生きる
kentaro
3
1.1k
R-SCoRe: Revisiting Scene Coordinate Regression for Robust Large-Scale Visual Localization
takmin
0
430
知られざるprops命名の慣習 アクション編
uhyo
10
2.4k
Preferred Networks (PFN) とLLM Post-Training チームの紹介 / 第4回 関東Kaggler会 スポンサーセッション
pfn
PRO
1
180
Figma + Storybook + PlaywrightのMCPを使ったフロントエンド開発
yug1224
4
210
会社にデータエンジニアがいることでできるようになること
10xinc
9
1.6k
Goss: Faiss向けの新しい本番環境対応 Goバインディング #coefl_go_jp
bengo4com
0
1.4k
ドキュメントはAIの味方!スタートアップのアジャイルを加速するADR
kawauso
3
340
モダンフロントエンド 開発研修
recruitengineers
PRO
2
260
認知戦の理解と、市民としての対抗策
hogehuga
0
310
RAID6 を楔形文字で組んで現代人を怖がらせましょう(実装編)
mimifuwa
0
300
Amazon Bedrock AgentCore でプロモーション用動画生成エージェントを開発する
nasuvitz
6
420
Featured
See All Featured
KATA
mclloyd
32
14k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Balancing Empowerment & Direction
lara
2
590
Being A Developer After 40
akosma
90
590k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Embracing the Ebb and Flow
colly
87
4.8k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
What's in a price? How to price your products and services
michaelherold
246
12k
Fireside Chat
paigeccino
39
3.6k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
How to Ace a Technical Interview
jacobian
279
23k
Transcript
障害対応指揮の 意思決定と情報共有 における価値観 id:arthur-1 株式会社はてな 2024-11-13 Waroom Meetup #2 現場の声から学ぶインシデント対応
1
Arthurと申します 株式会社はてな Mackerel開発チーム 「オブザーバビリティの実現」チーム テックリード 𝕏: @Arthur1__ 昔のポケモンカードのデッキを落として ヘコんでます 2
Mackerel作ってます 3
今日の話題 「障害対応指揮の意思決定と情報共有における価値観」 障害対応指揮官を担う機会が多い私が、障害対応にお いて気をつけていることを色々話します という内容ですが、ついお堅くタイトルをつけてしま いました 4
おしながき • ケーススタディで学ぶ障害対応 • 障害対応中こそ気をつけたい情報共有 5
ケーススタディで学ぶ 障害対応 6
ケーススタディ 障害対応の事例※を眺めながら 指揮官としてどういう判断をするか 皆さんも一緒に考えてみましょう! ※実話かもしれないしフィクションかもしれません 7
Case: 1 リリース完了後にサービスの調子が悪くなったことを確認 このタイミングから、IAMの権限不足のエラーログが出は じめているのが分かった ログから、どの権限が足りないかが分かっている さあ、どうする? 8
Case: 2 前触れもなくサービスの調子が悪くなった メトリックやトレース、ログを見ても原因が分からない 再デプロイしたら治りそうだと第六感が言っているが、 明確な根拠はない さあ、どうする? 9
Case: 3 障害対応フォーメーションが組まれ、業務中のエンジニ アがたくさん集まってきた ところが、並行してできるオペレーションや調査の数が そこまでなく、ただ見ているだけの人が多い状況だ さあ、どうする? 10
障害対応でやること 以下の2つを(多くの場合)並行して進める: • 障害から復旧させ、サービスを利用可能にする • 影響範囲の調査・ユーザーへの連絡 11
障害対応でやること • 障害から復旧させ、サービスを利用可能にする • 影響範囲の調査・ユーザーへの連絡 ユーザーができる限り早くサービスを利用できる状態にするの が最重要課題である 多くの場合、原因に辿り着いた上で対応が取られる その場しのぎの暫定対応でも一旦は構わない 12
サービスが利用可能? サービスが利用可能と一言で表したけれど • 例えば重大なセキュリティの問題が発生した時、そのままサー ビスを提供するわけにはいかないから、結果としてサービスが 利用不可能になる • 機能は使えるけど、過去のデータが全部消えちゃってもOK?そ んなこともない 何をMUSTとするか、現場だけで判断できないケースもある
13
障害対応でやること • 障害から復旧させ、サービスを利用可能にする • 影響範囲の調査・ユーザーへの連絡 影響範囲が分かっていなければ、復旧させようがないこ ともある 監視SaaSとしてはユーザーへ事象を素早く連絡できるか という点も大事にしている 14
[再掲] Case: 1 リリース完了後にサービスの調子が悪くなったことを確認 このタイミングから、IAMの権限不足のエラーログが出は じめているのが分かった ログから、どの権限が足りないかが分かっている さあ、どうする? 15
Case: 1 私はこう選択する リリースのロールバックをしようとする 障害と権限不足のエラーの因果関係が不明なため 権限を直しても、他の原因でサービスが不安定なままかも しれない 16
ロールバックの利点 Binary Push※ が原因の障害では、よくある対応として ロールバックがまず挙げられる コンテナイメージを過去にビルド済みのものに差し替え ることで、手間や時間をかけずにロールバックができる ※ cf.) https://sre.google/workbook/postmortem-analysis/
17
安易なロールバックに注意 安易に選択しがちだが、リスクの評価を必ずすること • 一緒に巻き戻る機能やデータがあっても大丈夫か? • そもそもロールバックの手順は整っているか? ロールバックを検討しているとき、実行を指示する前にロール バックして良いリリースかを確認してもらっている Pull Requestにラベルつけて「ロールバック可能」であることが
一目で分かるようにできると素早く判断できそう 18
ロールバックを安全に行うために デプロイと機能のリリースのタイミングを分けるフィー チャーフラグが有効 問題が起こった機能だけをロールバックできるため、 オペレーションによる影響範囲が小さくなる Canary Releaseとテレメトリの分析・自動ロールバック を組み合わせたProgressive Deliveryも手札に入れたい 19
[再掲] Case: 2 前触れもなくサービスの調子が悪くなった メトリックやトレース、ログを見ても原因が分からない 再デプロイしたら治りそうだと第六感が言っているが、 明確な根拠はない さあ、どうする? 20
Case: 2 私はこう選択する とりあえず再度デプロイしてみる 他に打つ手がなく、再デプロイすることで新たに起こる 問題もさほどないと想定されるため リスクを評価した上で許容されるかを判断する 指揮官が何かを決めて動かなければ状況は変わらない 21
現実を理想に近づける場 勘や経験に頼った対応ではなく、テレメトリをドリルダウ ン探索して障害原因に辿り着きたいという理想はある しかし、そんなことを嘆いていても、障害対応中はどうし ようもない 障害対応が終わったら、後日ふりかえりを実施して、 理想に近づくためのアクションを提案しよう 22
障害対応ふりかえり Mackerel開発チームでは、障害対応後のふりかえり で、以下の観点で対策を整理している: • 障害原因を確定させるためのアクション • 一時的な処置を恒久対応にするためのアクション • 再発防止するためのアクション •
障害発生を素早く検知するためのアクション • 収束までの(調査&復旧)時間を短くするためのアクション 23
[再掲] Case: 3 障害対応フォーメーションが組まれ、業務中のエンジニ アがたくさん集まってきた ところが、並行してできるオペレーションや調査の数が そこまでなく、ただ見ているだけの人が多い状況だ さあ、どうする? 24
Case: 3 私はこう選択する 調査や復旧対応がアサインされていない人は解散 して良いと伝える 障害対応フォーメーションにいる間、普段の仕事は止まって しまう やるべき仕事が終わらなければ、やりたい仕事の優先度はど んどん下がっていき、障害が増え、負のループに 25
アサインの明示 指揮官は障害対応フォーメーションにいる人が何を やっているか、どういう状態なのかを定期的に把握し なければならない 何かの作業を依頼する際には、「何の目的で、何をす るのか」を、特定の人を決めて明示的に指示する 宣言的に管理して、watchする状態を減らす 26
障害対応中こそ 気をつけたい情報共有 27
障害対応中のコミュニケーション 障害対応フォーメーションが組まれていて、指揮官や作 業実施者は同期的に会話している フォーメーションにいない人に向けて、Slack上に現在の 対応状況がポストされている 時には現場のエンジニアだけでは意思決定できず、チー ムのディレクターや事業責任者に判断を仰ぐこともある 28
気をつけていること 情報の確からしさと詳細度を意識する 情報もたくさん飛び交い、異常事態で焦っているので、 コミュニケーションのすれ違いが容易に起こり得る 情報の受信者(エンジニア?マネージャー?)が受け取 りたい情報を意識する 出所が不明な情報を横に流して混乱を生まない 29
具体例: 障害対応フェーズprefix Slack上での状況共有では、障害対応のフェーズを見 出しとしてつける 詳細に踏み込みたい人だけ文章を読めば良いという構成 例:【復旧完了】メトリックが平常時に戻ったのを確認し、 14:00に復旧完了としました。現在はユーザーへの復旧連絡 を進めています。 30
障害対応フェーズprefixの現在 啓発しているけどチームにはまだ浸透していない どのフェーズでも一貫して【状況共有】という見出しがつ けられているのを見る なぜ大事かを伝えきれていないと同時に、仕組みが必要 なのだろうと思う 31
まとめ 32
まとめ 障害対応は障害の迅速な復旧、具体的にはユーザーがサー ビスを利用できる状態にすることが最重要目標である 状況に応じてそれ以外の目標も大事にしなければならない 良い塩梅に多目的最適化できるように指揮官が決めて導く 異常事態だからこそ、整理された情報のやりとりが大事 33
作業者として関わるみなさんへ 障害対応指揮官だって完璧ではない一人の人間です 障害対応時に大切にしたい価値観の理解者として声を上げ ることで助けることができるかもしれません そして、その価値観の重みづけは、プロダクトによって異 なると思います。プロダクトを知りましょう 様々なポジション・ロールがあると思いますが、一つでも 持ち帰れるものがあれば幸いです 34
おしまい 35