$30 off During Our Annual Pro Sale. View Details »
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
コーポレートデータマスター構築への道
kworkdev
PRO
0
120
実践/先取り「入門 Kubernetes Validating/Mutating Admission Policy」 / CloudNative Days Winter 2024
pfn
PRO
1
150
PostgreSQL Conference Japan 2024 A4 Comparison of column-oriented access methods
nori_shinoda
0
110
GitHub Actions의 다양한 기능 활용하기 - GitHub Universe '24 Recap
outsider
0
120
深層学習のリペア技術の最新動向と実際 / DNN Repair Techniques for AI Performance Alignment for Safety Requirements
ishikawafyu
0
340
プルリクが全てじゃない!実は喜ばれるOSS貢献の方法8選
tkikuc
17
2.2k
pmconf2024_UPSIDER
upsider_tech
0
5.6k
ゆるSRE勉強会 #8 組織的にSREが始まる中で意識したこと
abnoumaru
2
990
データカタログを自作したけど 運用しなかった話@Findy Lunch LT「データカタログ 事例から学ぶメタデータ管理の実態」
ryo_suzuki
2
640
間違いだらけのポストモーテム - ホントに役立つレビューはこうだ!
jacopen
5
960
開志専門職大学特別講義 2024 オープニング
1ftseabass
PRO
0
220
Amazon ECSとCloud Runの相互理解で広げるクラウドネイティブの景色 / Mutually understanding Amazon ECS and Cloud Run
iselegant
19
2.4k
Featured
See All Featured
BBQ
matthewcrist
85
9.3k
Docker and Python
trallard
40
3.1k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
24k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Adopting Sorbet at Scale
ufuk
73
9.1k
A better future with KSS
kneath
238
17k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
4 Signs Your Business is Dying
shpigford
181
21k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
150
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
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