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

046baac588d91fd78a85b189847a151d?s=47 Sota Sugiura
January 26, 2019

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

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

046baac588d91fd78a85b189847a151d?s=128

Sota Sugiura

January 26, 2019
Tweet

Transcript

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

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

  3. 会場、盛り上がってますか?

  4. 開発、してますか?

  5. システム障害、起きてますか?

  6. None
  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. システム障害とは、結果 原因 ・システムバグ ・オペレーションミス ・運⽤用ミス 結果 ・画⾯面にエラーが表示 ・レイテンシが2倍に ・テストPush通知

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

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

  20. セーフ?

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

  22. なぜ結果セーフでも システム障害?

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

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

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

    システム障害は学びのチャンス
  26. 1章まとめ • システム障害とは結果として以下につながったもの • お客さまに影響が出る • もしくは影響が出る可能性があった • 原因は必ずしもシステム的なものに限らない •

    オペミスや外部起因、ヒューマンエラー • システム障害は学びのチャンス
  27. 02 システム障害に⽴立ち向かう

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

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

  30. 現実は厳しい*

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

  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. 2章まとめ • どんな状況であっても⼈人が作業をする限りミスは起きる • そしてシステム障害も起きる • それを前提に仕組みを作る • 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. 3章まとめ • メルカリでは再発防⽌止策をチーム横断でレビューを⾏行行って いる • 再発防⽌止策の評価はAutomation & Karakuriをベースとした 3つの軸で⾏行行う

  69. まとめ

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

  71. Thank you! @sota1235