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
3
260
障害対応指揮の意思決定と情報共有における価値観 / Waroom Meetup #2
https://topotal.connpass.com/event/333892/
Arthur
November 13, 2024
Tweet
Share
More Decks by Arthur
See All by Arthur
go.mod、DockerfileやCI設定に分散しがちなGoのバージョンをまとめて管理する / Go Connect #3
arthur1
10
2.5k
Mackerel開発チームの障害対応演習 ──新卒エンジニアが障害対応指揮官を務めるに至るまでのステップ / Mackerel Drink Up 出張版@福岡
arthur1
0
240
slog登場に伴うloggerの取り回し手法の見直し / kamakura.go #6
arthur1
1
2k
otelcol receiver 自作RTA / Pepabo Tech Conference #22 春のSREまつり
arthur1
0
3k
見せ算をScalaで実装してみた / Scalaわいわい勉強会 #2
arthur1
0
2k
技術習得を支え続けた私の個人開発ヒストリー / Hatena Engineer Seminar #28
arthur1
1
1.7k
Scala の好きなところ 難しいところ / #scala_waiwai
arthur1
0
1.2k
学園祭Web開発の現場とPHPのこれまでとこれから ── 技術選定と教育から語る / PHP Conference Japan 2023
arthur1
0
1.1k
仮説検証サイクルでユーザーの声を 高速に叶える「キカク組」の取り組み / Mackerel Drink Up #11 arthur-1
arthur1
0
1.1k
Other Decks in Technology
See All in Technology
徹底比較!HA Kubernetes ClusterにおけるControl Plane LoadBalancerの選択肢
logica0419
2
140
Team Dynamicsを目指すウイングアーク1stのQAチーム
sadonosake
1
210
これまでの計測・開発・デプロイ方法全部見せます! / Findy ISUCON 2024-11-14
tohutohu
3
250
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
28
12k
いざ、BSC討伐の旅
nikinusu
2
600
End of Barrel Files: New Modularization Techniques with Sheriff
rainerhahnekamp
0
280
Microsoft MVPになる前、なってから/Fukuoka_Tech_Women_Community_1_baba
nina01
0
170
Datadog RUM を用いた UX 指標の監視・顧客対応への活用
imamura_ko_0314
0
110
Postmanの日本市場におけるDevRel (的) 活動 / Postman's DevRelish activities in Japan
yokawasa
1
120
FOSS4G 2024 Japan コアデイ 一般発表25 PythonでPLATEAUのデータを手軽に扱ってみる
ra0kley
1
130
AWS Lambdaと歩んだ“サーバーレス”と今後 #lambda_10years
yoshidashingo
1
110
Lexical Analysis
shigashiyama
1
130
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
360
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Scaling GitHub
holman
458
140k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Writing Fast Ruby
sferik
627
61k
Building an army of robots
kneath
302
42k
A better future with KSS
kneath
238
17k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Facilitating Awesome Meetings
lara
49
6.1k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.3k
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