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
250
障害対応指揮の意思決定と情報共有における価値観 / 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
Deno+JSRでパッケージを作って公開する
askua
0
110
What to do after `laravel new`
mattstauffer
0
140
AWS パートナー企業でテクニカルサポートに従事して 3年経ったので思うところをまとめてみた
kazzpapa3
1
220
株式会社ログラス − エンジニア向け会社説明資料 / Loglass Comapany Deck for Engineer
loglass2019
3
28k
スクラムチームを立ち上げる〜チーム開発で得られたもの・得られなかったもの〜
ohnoeight
1
290
Railsで4GBのデカ動画ファイルのアップロードと配信、どう実現する?
asflash8
1
210
エンジニアが一生困らない ドキュメント作成の基本
naohiro_nakata
2
140
10分でわかるfreeeのQA
freee
1
3.5k
Team Dynamicsを目指すウイングアーク1stのQAチーム
sadonosake
1
210
SREによる隣接領域への越境とその先の信頼性
shonansurvivors
1
400
dev 補講: プロダクトセキュリティ / Product security overview
wa6sn
0
1.6k
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
409
22k
Rails Girls Zürich Keynote
gr2m
93
13k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
A better future with KSS
kneath
238
17k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
A Modern Web Designer's Workflow
chriscoyier
693
190k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Making Projects Easy
brettharned
115
5.9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
Documentation Writing (for coders)
carmenintech
65
4.4k
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