再発防止策を考える技術 / #phpconsen

by Sota Sugiura

Slide 1

Slide 1 text

再発防⽌止策を考える技術 @sota1235 2019/1/25 PHPカンファレンス仙台2019

Slide 2

Slide 2 text

Sota Sugiura / きりん Backend Engineer@Mercari, Inc. 最近JavaScriptに魂を売りました 2 @sota1235

Slide 3

Slide 3 text

会場、盛り上がってますか？

Slide 4

Slide 4 text

開発、してますか？

Slide 5

Slide 5 text

システム障害、起きてますか？

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

テーマシステム障害

Slide 8

Slide 8 text

テーマシステム障害に⽴立ち向かう話

Slide 9

Slide 9 text

アジェンダ 01 システム障害に⽴立ち向かう 02 実践！再発防⽌止策 03 再考システム障害とは

Slide 10

Slide 10 text

01 再考システム障害とは

Slide 11

Slide 11 text

定義 “システム障害とは、情報システムが何らかの不不具合によってその機能に⽀支障を来たし、本来の機能が利利⽤用できない状態のことである。” 引⽤用: https://www.weblio.jp/content/システム障害

Slide 12

Slide 12 text

Slide 13

Slide 13 text

誰が利利⽤用する機能か • to Cならサービスを利利⽤用するお客さま • to Bなら契約先の社員さん • 社内システムなら⾃自社社員

Slide 14

Slide 14 text

意図しない挙動

Slide 15

Slide 15 text

お客様に影響の出る意図しない挙動

Slide 16

Slide 16 text

これらは… • オペレーションミス • メールやPushの誤配信 • 仕様どおりだが、お客さまに影響の出る機能

Slide 17

Slide 17 text

システム障害とは、結果原因・システムバグ・オペレーションミス・運⽤用ミス結果・画⾯面にエラーが表示・レイテンシが２倍に・テストPush通知

Slide 18

Slide 18 text

システム障害とは、結果原因・システムバグ・オペレーションミス・運⽤用ミス結果・画⾯面にエラーが表示・レイテンシが２倍に・テストPush通知お客様に影響の出る意図しない挙動

Slide 19

Slide 19 text

じゃあこれらは？ • バグだが、影響範囲外 • お客さまにエラーは表示されないが、ログが荒ぶる • 不不要な情報がレスポンスに混ざっている

Slide 20

Slide 20 text

セーフ？

Slide 21

Slide 21 text

• 影響が出る可能性がある、もしくはあった • 潜在的なシステム障害 • たまたまセーフだっただけ • (※⼀一概にアウトとは⾔言えないが、必ずセーフではない) アウト

Slide 22

Slide 22 text

なぜ結果セーフでもシステム障害？

Slide 23

Slide 23 text

障害は収束してもサービスは続くから

Slide 24

Slide 24 text

• 問題発⽣生したリリースでサービスが終了了ではない • 新規でも改修でも開発が続いていく • 利利⽤用する技術スタックや開発メンバーは変わっていくかもしれない • それでもだいたいのケースで本質は変わらないサービスが⾛走り続けるということ

Slide 25

Slide 25 text

• 結果、問題が無かったものを⽔水に流すのはもったいない • 半年年後に同じ問題が起きて、次はお客さまに影響が及ぶかもしれない • 同じ、ないしは類類似の問題を防ぐ⽅方法を考えるきっかけとなる • また、その取組みで技術的な知⾒見見を得られることもシステム障害は学びのチャンス

Slide 26

Slide 26 text

１章まとめ • システム障害とは結果として以下につながったもの • お客さまに影響が出る • もしくは影響が出る可能性があった • 原因は必ずしもシステム的なものに限らない • オペミスや外部起因、ヒューマンエラー • システム障害は学びのチャンス

Slide 27

Slide 27 text

02 システム障害に⽴立ち向かう

Slide 28

Slide 28 text

どう⽴立ち向かうか • お客さまに影響を出さないためには障害を出さなければよい • つまり、障害が出ない開発をすればよい

Slide 29

Slide 29 text

障害出さずに開発できる⼈人

Slide 30

Slide 30 text

現実は厳しい*

Slide 31

Slide 31 text

受け⼊入れるべきたった１つの事実どんなに優秀な⼈人でもミスをする

Slide 32

Slide 32 text

障害は「起きる」 • ⼈人がサービスを作る限り、ミスは起きる • つまり障害は無くならない • 障害を無くす⽅方法は開発をやめることだけ画像引⽤用: http://cartoontester.blogspot.com/2013/10/field-of-dreams-rip-off.html

Slide 33

Slide 33 text

どうすべきか • 障害が起きるという事実を受け⼊入れる • どうすれば障害が起きる確率が減らせるか考える

Slide 34

Slide 34 text

https://speakerdeck.com/mercari/ja-mercari-tech-conf-2017-keynote?slide=67

Slide 35

Slide 35 text

Automation & Karakuri

Slide 36

Slide 36 text

Automation Karakuri ⼈人がしなくてもいいことをしない⼈人がミスしてもいい仕組みをつくる

Slide 37

Slide 37 text

• 静的解析による⾃自動レビュー • 再発防⽌止の⾃自動テスト Automation

Slide 38

Slide 38 text

• PushツールのValidation強化 • プログラム上のロジックで論理理的に起きないよう改修 Karakuri

Slide 39

Slide 39 text

⼈人間というコンポーネントを再発防⽌止に⼊入れない引⽤用: https://qiita.com/hirokidaichi/items/f9f4549c88aaf8b38bda

Slide 40

Slide 40 text

２章まとめ • どんな状況であっても⼈人が作業をする限りミスは起きる • そしてシステム障害も起きる • それを前提に仕組みを作る • Automation & Karakuri思想を元に考えていく

Slide 41

Slide 41 text

03 実践！再発防⽌止策

Slide 42

Slide 42 text

現場の話をします

Slide 43

Slide 43 text

障害発⽣生メルカリの障害対応フロー情報共有・対応解決 1 2 3 振り返り 4

Slide 44

Slide 44 text

障害発⽣生情報共有・対応解決 1 2 3 振り返り 4 メルカリの障害対応フロー今⽇日はここの話をします

Slide 45

Slide 45 text

振り返りでしないこと • 責任の追求 • 反省⽂文の読み合わせ

Slide 46

Slide 46 text

振り返りですること • Automation & Karakuriを実現する再発防⽌止策の検討 • 問題の深掘り

Slide 47

Slide 47 text

障害収束後フローごとのOwnershipの持ち⽅方 1 • 収束後、対応関係者で報告書を書く • 振り返りをするのに必要な情報を書く

Slide 48

Slide 48 text

障害収束後当事者、チームで考える 1 2 • まずは当事者、チームで再発防⽌止策を検討 • 必要に応じて他チームにも相談するフローごとのOwnershipの持ち⽅方

Slide 49

Slide 49 text

障害収束後当事者、チームで考えるチーム横断で振り返り 1 2 3 • 完成した報告書をチーム横断でレビュー • 様々な視点からアイディアを募るフローごとのOwnershipの持ち⽅方

Slide 50

Slide 50 text

どうやって振り返りをするか • 週に2度、Slack上でオンラインで実施される • 職種や役割に関係なく誰でも参加可能 http://tech.mercari.com/entry/2018/04/10/090453

Slide 51

Slide 51 text

どうやって振り返りをするか • 以下のことを⾏行行う • 新規に作成されたレポートのレビュー • 再発防⽌止対応中のレポートの進捗確認 • レビューが完了了したら「お疲れ様でした」 • [検索][メルカリの3つのValudeで取り組むインシデント対応] http://tech.mercari.com/entry/2018/04/10/090453

Slide 52

Slide 52 text

なぜチーム横断でレビューするのか

Slide 53

Slide 53 text

なぜチーム横断でやるのか • 社内の歴戦の猛者から知⾒見見がもらえる • 別職種の視点が得られる

Slide 54

Slide 54 text

歴戦の猛者からの知⾒見見 • 社内には⾮非常に様々なバックグランドを持つエンジニアが在籍する • Slack channelをpublicにすることでそのエンジニア達からフィードバックをもらうことができる • チームで解決できないことが振り返りで解決することもある

Slide 55

Slide 55 text

別職種の視点 • Slack channelはプロダクトに関わる全員にJOINを推奨 • システム障害の種類類によってはProducerやCustomer Success、時にはCorporateの意⾒見見も役に⽴立つ • より多くの意⾒見見を得られるよう、ファシリテーションを⾏行行う

Slide 56

Slide 56 text

再発防⽌止策の評価指標

Slide 57

Slide 57 text

Automation Karakuri ⼈人がしなくてもいいことをしない⼈人がミスしてもいい仕組みをつくるおさらい

Slide 58

Slide 58 text

再発防⽌止案の評価指標 • Karakuri • 新⼈人が同じことをしても再発しないか • ⼆二度と起きないようにできているか • Automation • ⼈人が作業しなくてもいいようになっているか

Slide 59

Slide 59 text

ユースケース：Backend編 • ⾃自動テストの改修 / 追加 • 独⾃自チェックスクリプトをCIで実⾏行行 • メンテナンスモードの実装

Slide 60

Slide 60 text

ユースケース：社内ツール編 • 権限制御の実装やValidationの追加 • ⼿手運⽤用の⾃自動化

Slide 61

Slide 61 text

ユースケース：その他 • フェールソフトへの⾃自動以降の実装 • 外部サービスの細かいモニタリング

Slide 62

Slide 62 text

全部完璧に再発防⽌止できるのか • 不不可能ではない • が、コスパが悪いものもある • そして現実問題の⼤大半はたいていコスパが悪い

Slide 63

Slide 63 text

どうすべきか

Slide 64

Slide 64 text

64 現実的な再発防⽌止策を考える技術⼈人間の関わる範囲を最⼩小限に何のための機能か⽴立ち返るトレードオフを意識する 2 3 1

Slide 65

Slide 65 text

65 現実的な再発防⽌止策を考える技術 1 ⼈人間の関わる範囲を最⼩小限に⼈人間はミスをすることを前提に考える 2 3 何のための機能か⽴立ち返るトレードオフを意識する

Slide 66

Slide 66 text

66 現実的な再発防⽌止策を考える技術 1 ⼈人間の関わる範囲を最⼩小限に⼈人間はミスをすることを前提に考える 2 再発防⽌止策のクオリティとコストのトレードオフを考える 3 何のための機能か⽴立ち返るトレードオフを意識する

Slide 67

Slide 67 text

67 現実的な再発防⽌止策を考える技術 1 ⼈人間の関わる範囲を最⼩小限に⼈人間はミスをすることを前提に考える 2 再発防⽌止策のクオリティとコストのトレードオフを考える 3 何のための機能か⽴立ち返る誰のためなのか、機能の⽬目的は何なのかトレードオフを意識する

Slide 68

Slide 68 text

３章まとめ • メルカリでは再発防⽌止策をチーム横断でレビューを⾏行行っている • 再発防⽌止策の評価はAutomation & Karakuriをベースとした 3つの軸で⾏行行う

Slide 69

Slide 69 text

まとめ

Slide 70

Slide 70 text

障害報告書は資産 • 障害はサービスが⾛走り続ける限り起き続ける • ⼤大事なのは起きた事に対しどう向き合うか • チーム横断で向き合うことで知⾒見見を共有する • 価値のある再発防⽌止策を考えることでサービス改善につなげる

Slide 71

Slide 71 text

Thank you! @sota1235