Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
障害対応指揮の意思決定と情報共有における価値観 / Waroom Meetup #2
Search
Arthur
November 13, 2024
Technology
5
550
障害対応指揮の意思決定と情報共有における価値観 / Waroom Meetup #2
https://topotal.connpass.com/event/333892/
Arthur
November 13, 2024
Tweet
Share
More Decks by Arthur
See All by Arthur
AWS AppConfigとOpenFeatureで手早く機能フラグを導入する[LT size] / CloudNative Days Winter 2024 船上LT会
arthur1
0
86
go.mod、DockerfileやCI設定に分散しがちなGoのバージョンをまとめて管理する / Go Connect #3
arthur1
12
3.2k
Mackerel開発チームの障害対応演習 ──新卒エンジニアが障害対応指揮官を務めるに至るまでのステップ / Mackerel Drink Up 出張版@福岡
arthur1
0
270
slog登場に伴うloggerの取り回し手法の見直し / kamakura.go #6
arthur1
1
2.2k
otelcol receiver 自作RTA / Pepabo Tech Conference #22 春のSREまつり
arthur1
0
3k
見せ算をScalaで実装してみた / Scalaわいわい勉強会 #2
arthur1
0
2.1k
技術習得を支え続けた私の個人開発ヒストリー / Hatena Engineer Seminar #28
arthur1
1
1.7k
Scala の好きなところ 難しいところ / #scala_waiwai
arthur1
0
1.3k
学園祭Web開発の現場とPHPのこれまでとこれから ── 技術選定と教育から語る / PHP Conference Japan 2023
arthur1
0
1.1k
Other Decks in Technology
See All in Technology
マルチプロダクト、マルチデータ基盤での Looker活用事例 〜BQじゃなくてもLookerはいいぞ〜
gappy50
0
130
12/3(火)のBedrockアプデ速報(re:Invent 2024 Daily re:Cap #2 with AWS Heroes)
minorun365
PRO
4
130
B11-SharePoint サイトのストレージ管理を考えよう
maekawa123
0
130
論理レプリケーションを使ったDB統合
kkato1
0
130
How is Cilium Tested?
yutarohayakawa
5
220
プロダクトマネージャーは 事業責任者の夢をみるのか pmconf2024
gimupop
1
6.7k
開発者向けツールを魔改造してセキュリティ診断ツールを作っている話 - 第1回 セキュリティ若手の会 LT
pizzacat83
0
320
知らない景色を見に行こう チャンスを掴んだら道が開けたマネジメントの旅 / Into the unknown~My management journey~
kakehashi
6
920
ONNX推論クレートの比較と実装奮闘記
emergent
0
290
実践/先取り「入門 Kubernetes Validating/Mutating Admission Policy」 / CloudNative Days Winter 2024
pfn
PRO
1
150
日本全国・都市3D化プロジェクト「PLATEAU」とデータ変換OSS「PLATEAU GIS Converter」の公開
nokonoko1203
4
340
コーポレートデータマスター構築への道
kworkdev
PRO
0
120
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
Adopting Sorbet at Scale
ufuk
73
9.1k
Navigating Team Friction
lara
183
15k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
How to Think Like a Performance Engineer
csswizardry
21
1.2k
YesSQL, Process and Tooling at Scale
rocio
169
14k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
2
240
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
480
The Language of Interfaces
destraynor
154
24k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
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