Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プロダクトのスケールによって顕在化しうるリスクをどう管理するか?

urahiroshi
August 02, 2024

 プロダクトのスケールによって顕在化しうるリスクをどう管理するか?

urahiroshi

August 02, 2024
Tweet

More Decks by urahiroshi

Other Decks in Technology

Transcript

  1. 自己紹介 2 浦⼭裕史 [@urahiroshi](https://x.com/urahiroshi) - Engineering Manager / Platform team

    @dinii - セコム => IIJ => メルカリ => dinii - やっていたこと / やっていること - マイクロサービス環境でのWebのリリースフロー - メルカリWebのマイクロサービス化、その4年 - インフラコストの削減ステップ - インシデントの「予防」「対応」「振り返り」を磨き込む! - 成⻑を加速する組織 - チャット型メモサービス “Duck” を開発‧運⽤
  2. 信頼性を上げるための取り組み 6 - Performance Review: 定期的にメトリクスをモニタリング - System Risk Records:

    スケールによって顕在化‧悪化するリスクを管理 - On-Call 制度: 開発メンバーがローテーションで⽇々のOn-Call業務にあたる - 緊急事態訓練: ⼤規模インシデント発⽣を全社でシミュレート - スタンドアロン機能: インフラが⽌まっても会計などは実施できるようにする - Postmortem: インシデントや本番環境で出たバグを振り返る インシデントの予防 インシデントの緩和 インシデントの振り返り
  3. 信頼性を上げるための取り組み 7 - Performance Review: 定期的にメトリクスをモニタリング - System Risk Records:

    スケールによって顕在化‧悪化するリスクを管理 - On-Call 制度: 開発メンバーがローテーションで⽇々のOn-Call業務にあたる - 緊急事態訓練: ⼤規模インシデント発⽣を全社でシミュレート - スタンドアロン機能: インフラが⽌まっても会計などは実施できるようにする - Postmortem: インシデントや本番環境で出たバグを振り返る インシデントの予防 インシデントの緩和 インシデントの振り返り 今回のトピック
  4. 怪しいメトリクスを見つけたときの対処フロー 9 1. 担当者をアサイン 2. 担当者が調査‧対応 3. 次の Performance Review

    の場で調査結果をレポート (解決 or 様⼦⾒の状態になるまで続く) 運⽤していくなかで、いくつかの課題が⾒えてきた
  5. 課題1. 潜在的なリスク対応が埋もれがち 11 例: 外部APIを呼び出している箇所でエラーが発⽣ 1. 原因を調べると、⼀定時間の外部APIの呼び出し回数が制限を超過していた 2. 1回のリクエストで外部APIを無駄に⼆重に呼び出しているところがあった 3.

    外部APIの呼び出しを1回に修正(暫定対策) 4. しばらくは⼤丈夫だが、リクエストが増えると確実にエラーになるので恒久対策 が必要 5. すぐやるのは難しいので開発チケットを作る 6. エラーが発⽣しなくなり、他の開発チケットも多く作られる中でチケットが埋も れ、リスクを忘れかける => 未解決のリスクを可視化したい!
  6. 課題2. 対応の属人化 13 例: メモリ使⽤量が上昇する問題を検出 1. 担当者にアサインされて調査を⾏い、怪しい箇所を発⾒ 2. 修正を適⽤し、メモリ使⽤量の遷移を確認 3.

    メモリ使⽤量が思ったより減らなかった 4. 改めて調査を⾏い、他の修正を適⽤ 5. 今度はうまくいき、メモリ使⽤量の問題が解消 6. 半年後、メモリ使⽤量の上昇が再発 7. 前回の試⾏錯誤の経験を踏まえて、また⾃分が担当する (以下繰り返し) => 試⾏錯誤のプロセスを共有したい!
  7. 課題3. 優先度がわからない 15 1. 怪しい問題を⾒つける 2. 少し調べたが、原因がよくわからない 3. もう少し時間をかけて調査することもできるが、今そんなに時間をかけられない 4.

    パフォーマンスレビューで報告し、様⼦⾒として対応終了 5. (あれ?実は深刻な問題の予兆だった可能性も...?) => 体系⽴てた⽅法で優先度をつけたい!
  8. System Risk Records に書いてあるもの (1) インパクト 22 現在のインパクト - 現時点でエラーやインシデントを発⽣させているかどうか

    潜在的なインパクト - 何も対処しないままスケールしていった場合、最悪どれだけのインパクトになりうるか
  9. System Risk Records に書いてあるもの (1) インパクト 23 ダイニーの場合: - <影響範囲>

    * <影響度> でインシデントをスコア付けしている - 影響範囲: どれだけ多くの店舗に影響したか (e.g. 数店舗 => 1, 半数未満 => 2, 半数以上=>3) - 影響度: 店舗に対する影響の重⼤さ (e.g. 店外業務のみ影響=>1, 店内業務に⽀障(代替可) => 3, 店内業務の遂⾏が困難 =>5) - 現在のインパクト、潜在的なインパクトもインシデントスコアをベースに算定 - 10 (score >= 10 のインシデント) - 6 (score >= 6 のインシデント) - 3 (score >= 3 のインシデント) - 1 (score >= 1 のインシデント) - 0 (なし) - 不明
  10. System Risk Records に書いてあるもの (2) 発生可能性、優先度 24 発⽣可能性 (潜在インパクト) -

    2: いつ発⽣してもおかしくない / スケールするとほぼ確実に発⽣ - 1: 発⽣する可能性がある 優先度スコア (= <潜在的なインパクト> * <発⽣可能性>) - 例: - 潜在的なインパクト=6 (score >= 6 のインシデント) - 影響範囲: 3 (半数以上) - 影響度: 3 (店内業務に⽀障) - 発⽣可能性=2: スケールするとほぼ確実に発⽣ => 優先度スコアは 6 * 2 = 12
  11. System Risk Records に書いてあるもの (3) Status, Next Visit 25 Status

    - 未着⼿: 初期状態 - 対応中: 調査 ~ 対策 ~ 結果確認の最中 - 様⼦⾒: いったんアクティブな対応は⾏っていないもの - 暫定対策済み: 暫定対策を実施したが恒久対策は実施していないもの (暫定対策でインパクトが減った場合は値を更新する) - 完了: 恒久対策実施済み、もしくは対策不要と判断したもの Next Visit - System Risk Records を次に確認するタイミング (⽇付を設定) - 対応中の場合は 1週間 ~ 1ヶ⽉先を設定 - 様⼦⾒や暫定対策済みの場合は 1ヶ⽉ ~ 3ヶ⽉先を設定
  12. System Risk Records に書いてあるもの (4) 詳細 26 - 概要 -

    リスクの概要を記載する - リスクの認知 ~ 原因特定までのログ - リスクを認知したきっかけとなったメトリクスのURLなどを記載する - 原因を特定するための対応の流れも記載していく。SlackのURLなどでもOK - 原因 - リスクの根本原因を書く - 対策⽅針 - 対策⽅針を書く - 代案があれば⽐較し、チーム内でレビューをするのもGood - 対策ログ - 暫定対策‧恒久対策のPR, リスクが収束したと確認できる情報などを記載する - Next Action - 次のアクションまで時間が開く場合などのためにメモを残す
  13. どうやって作るのか 27 - ダイニーでは Notion の Database を利⽤して作成 - Google

    Spreadsheet + Google Document のテンプレートも公開していま す:https://docs.google.com/spreadsheets/d/e/2PACX-1vT2LLgmkDfEWsRjspoPAuV dVzmGtDIRSbji-WOBqo8Du3S53IdQu3_dolzgzeDMAYW6A-lg0K2ikFK0/pubhtml
  14. 運用上のポイント: いつ作るか 28 - Performance Review で⾒つかる気になる箇所は毎週何個もある - 特定のサーバでエラーが増えている -

    特定のサーバのメモリ使⽤量が増えている - 特定のSQLクエリが重い - etc... - 全部 System Risk Records に記載すると管理しきれなくなるため取捨選択する必要が あるが、その問題のインパクトや発⽣可能性は調べてみないとわからない。主観的に 取捨選択すると System Risk Records の運⽤が属⼈化しがち => 以下の条件でSystem Risk Records に⼊れるようにした - まず Performance Review で検出した問題を1週間調査する - 問題が根本解決できず、潜在的なインパクトが3以上になりうる
  15. 運用上のポイント: ポストモーテムとの連携 29 - インシデントのポストモーテムを記載している場合、インシデントとなった事象をポ ストモーテムで扱うか、System Risk Records で扱うか悩ましい時がある -

    ポストモーテムに書くもの - 原因 - 恒久対応 - 再発防⽌策 - どうやって検知までの時間 (MTTA) や復旧までの時間 (MTTR) を短縮するか => ポストモーテムはポストモーテムとして書くのが良い。そのうえでSystem Risk Records としてウォッチしていく必要があるかが判断基準となる。 例えば、ポストモーテム⾃体は書き終わったものの恒久対応に時間がかかる場合は「ウォッ チすべきリスクがある状態」と⾔えるので System Risk Record を作り、詳細部分にポスト モーテムへのリンクを貼る
  16. まとめ 30 - 各種メトリクスを定期的に確認し、異常があれば担当者をアサインして調査を⾏ う運⽤フロー (Performance Review) を回す - 運⽤フローを回していると「潜在的なリスクが埋もれがち」「属⼈化する」「優

    先度がわからない」といった課題が出てきた - 潜在的なリスクのインパクトや、調査‧対応の流れを記録した “System Risk Records” を作ることで、未解決のリスクを優先度ごとに⼀覧できるようにし、 リスク対応の流れを組織的な学びにできた
  17. ② SREはじめ各エンジニア職種も絶賛採⽤中です。   気軽にカジュアル⾯談にお申し込みください!   https://hrmos.co/pages/dinii/jobs/9999 お知らせ 31 ① 飲⾷店でプロダクトを触りながら話す

     「ダイニー体験会」を毎⽉開催しています。  興味があればぜひご参加ください!  次回は 8/19 (⽉)です:  https://dinii.connpass.com/event/325689/