$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
再発防止策を考える技術 / #phpconsen
Search
Sota Sugiura
January 26, 2019
Technology
10
3.7k
再発防止策を考える技術 / #phpconsen
PHPカンファレンス仙台 2019@2019/1/26
https://phpcon-sendai.net/2019/
Sota Sugiura
January 26, 2019
Tweet
Share
More Decks by Sota Sugiura
See All by Sota Sugiura
内製したSlack Appで頑張るIncident Response@Waroom Meetup #1 / Incident Response with Slack App in 10X
sota1235
0
1.2k
20220926_セキュリティチームの今_for_Drs._Prime_公開用.pdf
sota1235
0
78
How to choose the best npm module for your team?
sota1235
9
550
Realtime Database for high traffic production application
sota1235
7
3.9k
Road to migrate JP Web as a microservice
sota1235
4
1.5k
インターフェース再入門 / Think Interface again
sota1235
6
10k
再発防止策を考える技術 #phpconfuk_rej
sota1235
1
1.1k
Update around Firebase #io18
sota1235
3
4.2k
Introduction for sonarwhal
sota1235
0
550
Other Decks in Technology
See All in Technology
リモートだからこそ 懸念だし1on1
jimpei
1
340
Amazon CloudFrontを活用したゼロダウンタイム実現する安定的なデプロイメント / 20241129 Yoshiki Shinagawa
shift_evolve
0
120
Entra ID の基礎(Japan Microsoft 365 コミュニティ カンファレンス 2024)
murachiakira
3
2.1k
セキュリティベンダー/ユーザー双方の視点で語る、 Attack Surface Managementの実践 - Finatextパート / cloudnative-architecture-of-asm
stajima
0
2.6k
RDRAとLLM
kanzaki
4
490
2024年のAmazon Bedrockアップデート一挙おさらい 〜まだ間に合う! re:Invent直前までの重大ニュースを速習しよう〜
minorun365
PRO
3
160
Bytebaseで実現する データベース管理の効率化
shogo452
1
280
GPUと画像生成AIが拓くマーケティングとビジネスの未来:次世代の可能性
iotcomjpadmin
0
300
Nutanixにいらっしゃいませ。Moveと仮想マシン移行のポイント紹介
shadowhat
0
240
Kubernetes だけじゃない!Amazon ECS で実現するクラウドネイティブな GitHub Actions セルフホストランナー / CNDW2024
ponkio_o
PRO
6
410
Engineer Recruting Deck
siva_official
PRO
1
3.2k
共創するアーキテクチャ ~チーム全体で築く持続可能な開発エコシステム~ / Co-Creating Architecture - A Sustainable Development Ecosystem Built by the Entire Team
bitkey
PRO
1
3.9k
Featured
See All Featured
Code Review Best Practice
trishagee
64
17k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
44
2.2k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
Become a Pro
speakerdeck
PRO
25
5k
Building Better People: How to give real-time feedback that sticks.
wjessup
364
19k
How to Think Like a Performance Engineer
csswizardry
20
1.2k
Making Projects Easy
brettharned
115
5.9k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Transcript
再発防⽌止策を考える技術 @sota1235 2019/1/25 PHPカンファレンス仙台2019
Sota Sugiura / きりん Backend Engineer@Mercari, Inc. 最近JavaScriptに魂を売りました 2 @sota1235
会場、盛り上がってますか?
開発、してますか?
システム障害、起きてますか?
None
テーマ システム障害
テーマ システム障害に⽴立ち向かう話
アジェンダ 01 システム障害に⽴立ち向かう 02 実践!再発防⽌止策 03 再考 システム障害とは
01 再考 システム障害とは
定義 “システム障害とは、情報システムが何らかの不不具合によっ てその機能に⽀支障を来たし、本来の機能が利利⽤用できない状態 のことである。” 引⽤用: https://www.weblio.jp/content/システム障害
定義 “システム障害とは、情報システムが何らかの不不具合によっ てその機能に⽀支障を来たし、本来の機能が利利⽤用できない状態 のことである。” 引⽤用: https://www.weblio.jp/content/システム障害
誰が利利⽤用する機能か • to Cならサービスを利利⽤用するお客さま • to Bなら契約先の社員さん • 社内システムなら⾃自社社員
意図しない挙動
お客様に影響の出る 意図しない挙動
これらは… • オペレーションミス • メールやPushの誤配信 • 仕様どおりだが、お客さまに影響の出る機能
システム障害とは、結果 原因 ・システムバグ ・オペレーションミス ・運⽤用ミス 結果 ・画⾯面にエラーが表示 ・レイテンシが2倍に ・テストPush通知
システム障害とは、結果 原因 ・システムバグ ・オペレーションミス ・運⽤用ミス 結果 ・画⾯面にエラーが表示 ・レイテンシが2倍に ・テストPush通知 お客様に影響の出る
意図しない挙動
じゃあこれらは? • バグだが、影響範囲外 • お客さまにエラーは表示されないが、ログが荒ぶる • 不不要な情報がレスポンスに混ざっている
セーフ?
• 影響が出る可能性がある、もしくはあった • 潜在的なシステム障害 • たまたまセーフだっただけ • (※⼀一概にアウトとは⾔言えないが、必ずセーフではない) アウト
なぜ結果セーフでも システム障害?
障害は収束しても サービスは続くから
• 問題発⽣生したリリースでサービスが終了了ではない • 新規でも改修でも開発が続いていく • 利利⽤用する技術スタックや開発メンバーは変わっていくかも しれない • それでもだいたいのケースで本質は変わらない サービスが⾛走り続けるということ
• 結果、問題が無かったものを⽔水に流すのはもったいない • 半年年後に同じ問題が起きて、次はお客さまに影響が及ぶ かもしれない • 同じ、ないしは類類似の問題を防ぐ⽅方法を考えるきっかけと なる • また、その取組みで技術的な知⾒見見を得られることも
システム障害は学びのチャンス
1章まとめ • システム障害とは結果として以下につながったもの • お客さまに影響が出る • もしくは影響が出る可能性があった • 原因は必ずしもシステム的なものに限らない •
オペミスや外部起因、ヒューマンエラー • システム障害は学びのチャンス
02 システム障害に⽴立ち向かう
どう⽴立ち向かうか • お客さまに影響を出さないためには障害を出さなければよい • つまり、障害が出ない開発をすればよい
障害出さずに開発できる⼈人
現実は厳しい*
受け⼊入れるべきたった1つの事実 どんなに優秀な⼈人でもミスをする
障害は「起きる」 • ⼈人がサービスを作る限り、 ミスは起きる • つまり障害は無くならない • 障害を無くす⽅方法は開発を やめることだけ 画像引⽤用:
http://cartoontester.blogspot.com/2013/10/field-of-dreams-rip-off.html
どうすべきか • 障害が起きるという事実を受け⼊入れる • どうすれば障害が起きる確率が減らせるか考える
https://speakerdeck.com/mercari/ja-mercari-tech-conf-2017-keynote?slide=67
Automation & Karakuri
Automation Karakuri ⼈人がしなくてもいいことをしない ⼈人がミスしてもいい仕組みをつくる
• 静的解析による⾃自動レビュー • 再発防⽌止の⾃自動テスト Automation
• PushツールのValidation強化 • プログラム上のロジックで論理理的に起きないよう改修 Karakuri
⼈人間というコンポーネントを 再発防⽌止に⼊入れない 引⽤用: https://qiita.com/hirokidaichi/items/f9f4549c88aaf8b38bda
2章まとめ • どんな状況であっても⼈人が作業をする限りミスは起きる • そしてシステム障害も起きる • それを前提に仕組みを作る • Automation &
Karakuri思想を元に考えていく
03 実践!再発防⽌止策
現場の話をします
障害発⽣生 メルカリの障害対応フロー 情報共有・対応 解決 1 2 3 振り返り 4
障害発⽣生 情報共有・対応 解決 1 2 3 振り返り 4 メルカリの障害対応フロー 今⽇日はここの話をします
振り返りでしないこと • 責任の追求 • 反省⽂文の読み合わせ
振り返りですること • Automation & Karakuriを実現する再発防⽌止策の検討 • 問題の深掘り
障害収束後 フローごとのOwnershipの持ち⽅方 1 • 収束後、対応関係者で報告書を書く • 振り返りをするのに必要な情報を書く
障害収束後 当事者、チームで考える 1 2 • まずは当事者、チームで再発防⽌止策を検討 • 必要に応じて他チームにも相談する フローごとのOwnershipの持ち⽅方
障害収束後 当事者、チームで考える チーム横断で振り返り 1 2 3 • 完成した報告書をチーム横断でレビュー • 様々な視点からアイディアを募る
フローごとのOwnershipの持ち⽅方
どうやって振り返りをするか • 週に2度、Slack上でオンラインで実施される • 職種や役割に関係なく誰でも参加可能 http://tech.mercari.com/entry/2018/04/10/090453
どうやって振り返りをするか • 以下のことを⾏行行う • 新規に作成されたレポートのレビュー • 再発防⽌止対応中のレポートの進捗確認 • レビューが完了了したら「お疲れ様でした」 •
[検索][メルカリの3つのValudeで取り組むインシデント対応] http://tech.mercari.com/entry/2018/04/10/090453
なぜチーム横断でレビューするのか
なぜチーム横断でやるのか • 社内の歴戦の猛者から知⾒見見がもらえる • 別職種の視点が得られる
歴戦の猛者からの知⾒見見 • 社内には⾮非常に様々なバックグランドを持つエンジニアが 在籍する • Slack channelをpublicにすることでそのエンジニア達から フィードバックをもらうことができる • チームで解決できないことが振り返りで解決することもあ
る
別職種の視点 • Slack channelはプロダクトに関わる全員にJOINを推奨 • システム障害の種類類によってはProducerやCustomer Success、時にはCorporateの意⾒見見も役に⽴立つ • より多くの意⾒見見を得られるよう、ファシリテーションを⾏行行 う
再発防⽌止策の評価指標
Automation Karakuri ⼈人がしなくてもいいことをしない ⼈人がミスしてもいい仕組みをつくる おさらい
再発防⽌止案の評価指標 • Karakuri • 新⼈人が同じことをしても再発しないか • ⼆二度と起きないようにできているか • Automation •
⼈人が作業しなくてもいいようになっているか
ユースケース:Backend編 • ⾃自動テストの改修 / 追加 • 独⾃自チェックスクリプトをCIで実⾏行行 • メンテナンスモードの実装
ユースケース:社内ツール編 • 権限制御の実装やValidationの追加 • ⼿手運⽤用の⾃自動化
ユースケース:その他 • フェールソフトへの⾃自動以降の実装 • 外部サービスの細かいモニタリング
全部完璧に再発防⽌止できるのか • 不不可能ではない • が、コスパが悪いものもある • そして現実問題の⼤大半はたいていコスパが悪い
どうすべきか
64 現実的な再発防⽌止策を考える技術 ⼈人間の関わる範囲 を最⼩小限に 何のための機能か ⽴立ち返る トレードオフを 意識する 2 3
1
65 現実的な再発防⽌止策を考える技術 1 ⼈人間の関わる範囲 を最⼩小限に ⼈人間はミスをすること を前提に考える 2 3 何のための機能か
⽴立ち返る トレードオフを 意識する
66 現実的な再発防⽌止策を考える技術 1 ⼈人間の関わる範囲 を最⼩小限に ⼈人間はミスをすること を前提に考える 2 再発防⽌止策のクオリティ とコストのトレードオフ
を考える 3 何のための機能か ⽴立ち返る トレードオフを 意識する
67 現実的な再発防⽌止策を考える技術 1 ⼈人間の関わる範囲 を最⼩小限に ⼈人間はミスをすること を前提に考える 2 再発防⽌止策のクオリティ とコストのトレードオフ
を考える 3 何のための機能か ⽴立ち返る 誰のためなのか、機能 の⽬目的は何なのか トレードオフを 意識する
3章まとめ • メルカリでは再発防⽌止策をチーム横断でレビューを⾏行行って いる • 再発防⽌止策の評価はAutomation & Karakuriをベースとした 3つの軸で⾏行行う
まとめ
障害報告書は資産 • 障害はサービスが⾛走り続ける限り起き続ける • ⼤大事なのは起きた事に対しどう向き合うか • チーム横断で向き合うことで知⾒見見を共有する • 価値のある再発防⽌止策を考えることでサービス改善につ なげる
Thank you! @sota1235