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

PHPカンファレンス仙台 2019@2019/1/26
https://phpcon-sendai.net/2019/

Transcript

1. 再発防⽌止策を考える技術 @sota1235 2019/1/25 PHPカンファレンス仙台2019
2. Sota Sugiura / きりん Backend Engineer@Mercari, Inc. 最近JavaScriptに魂を売りました 2 @sota1235
3. 会場、盛り上がってますか？
4. 開発、してますか？
5. システム障害、起きてますか？
7. テーマ システム障害
8. テーマ システム障害に⽴立ち向かう話
9. アジェンダ 01 システム障害に⽴立ち向かう 02 実践！再発防⽌止策 03 再考 システム障害とは
10. 01 再考 システム障害とは
11. 定義 “システム障害とは、情報システムが何らかの不不具合によっ てその機能に⽀支障を来たし、本来の機能が利利⽤用できない状態 のことである。” 引⽤用: https://www.weblio.jp/content/システム障害
12. 定義 “システム障害とは、情報システムが何らかの不不具合によっ てその機能に⽀支障を来たし、本来の機能が利利⽤用できない状態 のことである。” 引⽤用: https://www.weblio.jp/content/システム障害
13. 誰が利利⽤用する機能か • to Cならサービスを利利⽤用するお客さま • to Bなら契約先の社員さん • 社内システムなら⾃自社社員
14. 意図しない挙動
15. お客様に影響の出る 意図しない挙動
16. これらは… • オペレーションミス • メールやPushの誤配信 • 仕様どおりだが、お客さまに影響の出る機能
17. システム障害とは、結果 原因 ・システムバグ ・オペレーションミス ・運⽤用ミス 結果 ・画⾯面にエラーが表示 ・レイテンシが２倍に ・テストPush通知
18. システム障害とは、結果 原因 ・システムバグ ・オペレーションミス ・運⽤用ミス 結果 ・画⾯面にエラーが表示 ・レイテンシが２倍に ・テストPush通知 お客様に影響の出る 意図しない挙動
19. じゃあこれらは？ • バグだが、影響範囲外 • お客さまにエラーは表示されないが、ログが荒ぶる • 不不要な情報がレスポンスに混ざっている
20. セーフ？
21. • 影響が出る可能性がある、もしくはあった • 潜在的なシステム障害 • たまたまセーフだっただけ • (※⼀一概にアウトとは⾔言えないが、必ずセーフではない) アウト
22. なぜ結果セーフでも システム障害？
23. 障害は収束しても サービスは続くから
24. • 問題発⽣生したリリースでサービスが終了了ではない • 新規でも改修でも開発が続いていく • 利利⽤用する技術スタックや開発メンバーは変わっていくかも しれない • それでもだいたいのケースで本質は変わらない サービスが⾛走り続けるということ
25. • 結果、問題が無かったものを⽔水に流すのはもったいない • 半年年後に同じ問題が起きて、次はお客さまに影響が及ぶ かもしれない • 同じ、ないしは類類似の問題を防ぐ⽅方法を考えるきっかけと なる • また、その取組みで技術的な知⾒見見を得られることも システム障害は学びのチャンス
26. １章まとめ • システム障害とは結果として以下につながったもの • お客さまに影響が出る • もしくは影響が出る可能性があった • 原因は必ずしもシステム的なものに限らない • オペミスや外部起因、ヒューマンエラー • システム障害は学びのチャンス
27. 02 システム障害に⽴立ち向かう
28. どう⽴立ち向かうか • お客さまに影響を出さないためには障害を出さなければよい • つまり、障害が出ない開発をすればよい
29. 障害出さずに開発できる⼈人
30. 現実は厳しい*
31. 受け⼊入れるべきたった１つの事実 どんなに優秀な⼈人でもミスをする
32. 障害は「起きる」 • ⼈人がサービスを作る限り、 ミスは起きる • つまり障害は無くならない • 障害を無くす⽅方法は開発を やめることだけ 画像引⽤用: http://cartoontester.blogspot.com/2013/10/field-of-dreams-rip-off.html
33. どうすべきか • 障害が起きるという事実を受け⼊入れる • どうすれば障害が起きる確率が減らせるか考える
34. https://speakerdeck.com/mercari/ja-mercari-tech-conf-2017-keynote?slide=67
35. Automation & Karakuri
36. Automation Karakuri ⼈人がしなくてもいいことをしない ⼈人がミスしてもいい仕組みをつくる
37. • 静的解析による⾃自動レビュー • 再発防⽌止の⾃自動テスト Automation
38. • PushツールのValidation強化 • プログラム上のロジックで論理理的に起きないよう改修 Karakuri
39. ⼈人間というコンポーネントを 再発防⽌止に⼊入れない 引⽤用: https://qiita.com/hirokidaichi/items/f9f4549c88aaf8b38bda
40. ２章まとめ • どんな状況であっても⼈人が作業をする限りミスは起きる • そしてシステム障害も起きる • それを前提に仕組みを作る • Automation & Karakuri思想を元に考えていく
41. 03 実践！再発防⽌止策
42. 現場の話をします
43. 障害発⽣生 メルカリの障害対応フロー 情報共有・対応 解決 1 2 3 振り返り 4
44. 障害発⽣生 情報共有・対応 解決 1 2 3 振り返り 4 メルカリの障害対応フロー 今⽇日はここの話をします
45. 振り返りでしないこと • 責任の追求 • 反省⽂文の読み合わせ
46. 振り返りですること • Automation & Karakuriを実現する再発防⽌止策の検討 • 問題の深掘り
47. 障害収束後 フローごとのOwnershipの持ち⽅方 1 • 収束後、対応関係者で報告書を書く • 振り返りをするのに必要な情報を書く
48. 障害収束後 当事者、チームで考える 1 2 • まずは当事者、チームで再発防⽌止策を検討 • 必要に応じて他チームにも相談する フローごとのOwnershipの持ち⽅方
49. 障害収束後 当事者、チームで考える チーム横断で振り返り 1 2 3 • 完成した報告書をチーム横断でレビュー • 様々な視点からアイディアを募る フローごとのOwnershipの持ち⽅方
50. どうやって振り返りをするか • 週に2度、Slack上でオンラインで実施される • 職種や役割に関係なく誰でも参加可能 http://tech.mercari.com/entry/2018/04/10/090453
51. どうやって振り返りをするか • 以下のことを⾏行行う • 新規に作成されたレポートのレビュー • 再発防⽌止対応中のレポートの進捗確認 • レビューが完了了したら「お疲れ様でした」 • [検索][メルカリの3つのValudeで取り組むインシデント対応] http://tech.mercari.com/entry/2018/04/10/090453
52. なぜチーム横断でレビューするのか
53. なぜチーム横断でやるのか • 社内の歴戦の猛者から知⾒見見がもらえる • 別職種の視点が得られる
54. 歴戦の猛者からの知⾒見見 • 社内には⾮非常に様々なバックグランドを持つエンジニアが 在籍する • Slack channelをpublicにすることでそのエンジニア達から フィードバックをもらうことができる • チームで解決できないことが振り返りで解決することもあ る
55. 別職種の視点 • Slack channelはプロダクトに関わる全員にJOINを推奨 • システム障害の種類類によってはProducerやCustomer Success、時にはCorporateの意⾒見見も役に⽴立つ • より多くの意⾒見見を得られるよう、ファシリテーションを⾏行行 う
56. 再発防⽌止策の評価指標
57. Automation Karakuri ⼈人がしなくてもいいことをしない ⼈人がミスしてもいい仕組みをつくる おさらい
58. 再発防⽌止案の評価指標 • Karakuri • 新⼈人が同じことをしても再発しないか • ⼆二度と起きないようにできているか • Automation • ⼈人が作業しなくてもいいようになっているか
59. ユースケース：Backend編 • ⾃自動テストの改修 / 追加 • 独⾃自チェックスクリプトをCIで実⾏行行 • メンテナンスモードの実装
60. ユースケース：社内ツール編 • 権限制御の実装やValidationの追加 • ⼿手運⽤用の⾃自動化
61. ユースケース：その他 • フェールソフトへの⾃自動以降の実装 • 外部サービスの細かいモニタリング
62. 全部完璧に再発防⽌止できるのか • 不不可能ではない • が、コスパが悪いものもある • そして現実問題の⼤大半はたいていコスパが悪い
63. どうすべきか
64. 64 現実的な再発防⽌止策を考える技術 ⼈人間の関わる範囲 を最⼩小限に 何のための機能か ⽴立ち返る トレードオフを 意識する 2 3 1
65. 65 現実的な再発防⽌止策を考える技術 1 ⼈人間の関わる範囲 を最⼩小限に ⼈人間はミスをすること を前提に考える 2 3 何のための機能か ⽴立ち返る トレードオフを 意識する
66. 66 現実的な再発防⽌止策を考える技術 1 ⼈人間の関わる範囲 を最⼩小限に ⼈人間はミスをすること を前提に考える 2 再発防⽌止策のクオリティ とコストのトレードオフ を考える 3 何のための機能か ⽴立ち返る トレードオフを 意識する
67. 67 現実的な再発防⽌止策を考える技術 1 ⼈人間の関わる範囲 を最⼩小限に ⼈人間はミスをすること を前提に考える 2 再発防⽌止策のクオリティ とコストのトレードオフ を考える 3 何のための機能か ⽴立ち返る 誰のためなのか、機能 の⽬目的は何なのか トレードオフを 意識する
68. ３章まとめ • メルカリでは再発防⽌止策をチーム横断でレビューを⾏行行って いる • 再発防⽌止策の評価はAutomation & Karakuriをベースとした 3つの軸で⾏行行う
69. まとめ
70. 障害報告書は資産 • 障害はサービスが⾛走り続ける限り起き続ける • ⼤大事なのは起きた事に対しどう向き合うか • チーム横断で向き合うことで知⾒見見を共有する • 価値のある再発防⽌止策を考えることでサービス改善につ なげる
71. Thank you! @sota1235