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
再発防止策を考える技術 / #phpconsen
Search
Sota Sugiura
January 26, 2019
Technology
10
3.5k
再発防止策を考える技術 / #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
20220926_セキュリティチームの今_for_Drs._Prime_公開用.pdf
sota1235
0
39
How to choose the best npm module for your team?
sota1235
9
450
Realtime Database for high traffic production application
sota1235
7
3.7k
Road to migrate JP Web as a microservice
sota1235
4
1.4k
インターフェース再入門 / Think Interface again
sota1235
6
10k
再発防止策を考える技術 #phpconfuk_rej
sota1235
1
1k
Update around Firebase #io18
sota1235
3
4.1k
Introduction for sonarwhal
sota1235
0
470
JavaScriptユニットテストの理想と現実
sota1235
13
7k
Other Decks in Technology
See All in Technology
プレイヤーとしてのチームのテスト力UP/Improving team skills for testing
goyoki
2
220
Proposal for a fictitious company presented by JAWS-UG DE&I team 'Naniwa Musume'
hiroramos4
PRO
0
120
理想の組織も自分たちで作ろう! ―LayerXの「全員採用」を支える文化 / How to create our own ideal team
ar_tama
6
2.2k
PHPerKaigi 2024 - PHP 本体のバグを見つけたら適切に報告しよう
zeriyoshi
0
750
GitHub Actions Runner Controller
takesection
0
110
最速思考でバクラク品質を! スタートアップのリアルな課題とQAの実践
nakanao
1
440
履歴データテーブルとの向き合い方_PHPerKaigi2024
gennei
25
6.7k
SwiftUIのpropertyWrapperをふんわり理解する
jambo_develop_team
0
110
【OpenAI本出版記念】npakaによるOpenAI最新技術情報と技術情報キャッチアップ術
npaka
8
1.4k
Uniting Rust Servers and Clients through OpenAPI
ahl
0
430
We Fear Change, for DevOpsDays LA 2024
cote
PRO
0
130
Simplifying Data Analysis & Visualization with Developer Tools & AI
nitya
1
220
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
225
51k
Facilitating Awesome Meetings
lara
39
5.5k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.8k
How STYLIGHT went responsive
nonsquared
92
4.7k
What the flash - Photography Introduction
edds
64
11k
How to train your dragon (web standard)
notwaldorf
71
5k
Web Components: a chance to create the future
zenorocha
304
41k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
8
8.2k
Building Flexible Design Systems
yeseniaperezcruz
317
37k
GraphQLの誤解/rethinking-graphql
sonatard
48
9.1k
A designer walks into a library…
pauljervisheath
199
23k
The Pragmatic Product Professional
lauravandoore
24
5.7k
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