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

バグの分析から見えた巨大な技術的負債を生まないためにできること / Bug Analysis tells how to avoid tech debt

Taichi Oshiumi
November 21, 2023
4.6k

バグの分析から見えた巨大な技術的負債を生まないためにできること / Bug Analysis tells how to avoid tech debt

2023/11/21 「技術的負債に向き合う Online Conference / LT 選手権」登壇資料

Taichi Oshiumi

November 21, 2023
Tweet

Transcript

  1. © 2023 Wantedly, Inc. PUBLIC 前提: Wantedly の特徴 • バックエンドはだいたい

    Ruby • モノリシックな Rails アプリから Ruby の gRPC サーバが主流に • サービス開始から10年以上が経過 詳しくは https://docs.wantedly.dev/introduction/technical-overview
  2. © 2023 Wantedly, Inc. PUBLIC 前提: ウォンテッドリー vs 技術的負債 負債返済日

    • 1ヶ月に1日全エンジニアで技術的負債の返済タスクを行う 技術領域の横断組織 • 最大 20% の時間を使って大きな負債を組織的に解決する
  3. © 2023 Wantedly, Inc. PUBLIC 前提: ウォンテッドリー vs 技術的負債 負債返済日

    • 1ヶ月に1日全エンジニアで技術的負債の返済タスクを行う 技術領域の横断組織 • 最大 20% の時間を使って大きな負債を組織的に解決する これだけでは足りなかった → プロダクトの品質のために専門チームを設立
  4. © 2023 Wantedly, Inc. PUBLIC 前提: Quality Control Squad の役割

    1. 老朽化したアーキテクチャを刷新する 2. 見つかったバグを優先度高い方から潰す 3. 品質を高める文化を作る
  5. © 2023 Wantedly, Inc. PUBLIC 前提: Quality Control Squad の役割

    1. 老朽化したアーキテクチャを刷新する 2. 見つかったバグを優先度高い方から潰す (今日の話) 3. 品質を高める文化を作る
  6. © 2023 Wantedly, Inc. PUBLIC 本題: 対応したバグを分析して負債の発生箇所を特定する • サンプル数: 86

    ◦ 優先度の高い Issue のみを集計対象にした • Issue が作成されてからクローズするまでのリードタイムを計測 • App/System/Data の 3つで分類 ◦ System: バックエンドのコード修正で直るもの ◦ App: フロントエンドのコード修正で直るもの ◦ Data: データ修正が必要なもの ▪ RDB のデータ修正、ログのデータ修正等
  7. © 2023 Wantedly, Inc. PUBLIC 本題: 分析結果 days ヒゲの長さは (Q3-Q1)*1.5

    を上限とし、その範囲外を外れ値とした。
  8. © 2023 Wantedly, Inc. PUBLIC なぜデータ修正系のバグはリードタイムの分散が大きくなるのか • 参照の数によってかかる時間が大きく変わる ◦ 参照が多いデータは重要度が高いが、網羅的に調べるのが難しく時間がかか

    る ◦ 逆に言うと参照が限定的なデータの修正だと一瞬で終わる • データが壊れていることに対してのモニタリングが十分でなく発見が 遅れる • ユーザーへのコミュニケーションのリードタイムがかかる
  9. © 2023 Wantedly, Inc. PUBLIC 巨大な技術的負債を生まないためにできること • 早期に発見、対応すること ◦ 負債を得て一次的な速度を得ることも状況によってはあるが、

    データの負債は高利子であることを忘れない ◦ モニタリングできる仕組みを作る • 無駄な負債を生まない ◦ 負債である認識を持って生んだ負債は悪化したときに気付きやすいが、負債 の認識がないもの、途中で負債化したものは気付きにくい ◦ データ設計、ログ設計の重要性