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

実録!一人SREが直面している技術的負債

syossan27
March 22, 2024
3.1k

 実録!一人SREが直面している技術的負債

syossan27

March 22, 2024
Tweet

More Decks by syossan27

Transcript

  1. 「Defining, Measuring, and Managing Technical Debt」 → 技術的負債にはどのようなものがあり、 どのように測定・管理するか?について述べた論文 ※

    Defining, Measuring, and Managing Technical Debt(2023)Ciera Jaspan, Collin Green - https://ieeexplore.ieee.org/document/10109339
  2. 1. 移行が必要なモノ、または進行中のモノ スケーリング、依存関係、非推奨などの要因によ る移行をしていない 2. ドキュメント プロジェクト、サービスに関するドキュメントの 探索容易性が低い、欠落、または不完全である 3. テスト

    テストが欠落している、不十分、脆弱である 4. コード品質 適切な設計がされておらず、プロトタイプ/デモ版 の可能性 5. 廃止・放棄されたコード 廃止されていたり、利用されていないデッドコー ド ※ Defining, Measuring, and Managing Technical Debt(2023)Ciera Jaspan, Collin Green - https://ieeexplore.ieee.org/document/10109339 より引用 技術的負債の中でもインシデント要因になる可能性の高 いとされる負債。 ドキュメント・テストが高い位置にいることが、Google でもそうなんだな〜という謎の親近感が湧いた。 これらはPrudent-Deliberateに当たるような負債。
  3. 6. コードの劣化 時間経過とともにリファクタリングが必要なコー ドが存在している 7. チームに必要な専門知識が不足 離職・移動による人材不足、またはチーム内での 知識の共有場所がない 8. 依存関係

    依存関係における依存先の不安定さ・変化に対す る耐性・管理不足 9. 移行の失敗か、放棄 2つのバージョンが並列で動いている 10. リリースプロセス リリースプロセス・リリースの監視を更新、移 行、またはを保守していない ※ Defining, Measuring, and Managing Technical Debt(2023)Ciera Jaspan, Collin Green - https://ieeexplore.ieee.org/document/10109339 より引用 先程の負債よりもインシデントに繋がる危険性はまだ低 い。 7の専門知識が不足していることが技術的負債にカテゴ ライズされていることが面白い。 → これは6のコード劣化と密接な関係にあり、単純にリ ファクタリングするための専門知識が足りていない可能 性
  4. 1. 移行が必要なモノ、または進行中のモノ k8sなどのインフラも含めたサービス、SREが作成したツール群の依存性・非推奨の管理がされていない 非推奨になったライブラリ等の移行先を決めていない 2. ドキュメント SREが管理しているプラットフォーム・ツールなどに関するドキュメントが存在していない、メンテナンスしていな い 3. テスト

    SREが管理しているプラットフォーム・ツールなどに関する不十分なテスト、テストに対する仕組み作りが不十分 4. コード品質 SREが管理しているプラットフォーム・ツールなどに関する不十分なコード品質、品質に対する仕組み作りが不十分 5. 廃止・放棄されたコード 開発チーム向けに作成した仕組みが既に使われていないなど利用用途に沿わなくなっている ※ Defining, Measuring, and Managing Technical Debt(2023)Ciera Jaspan, Collin Green - https://ieeexplore.ieee.org/document/10109339 より引用
  5. 6. コードの劣化 SREが管理しているプラットフォーム・ツールなどに関するコードの劣化、コード劣化に対する仕組みづくりが不 十分 7. チームに必要な専門知識が不足 離職・移動による人材不足、またはチーム内での知識の共有場所がない 8. 依存関係 依存関係における依存先の管理不足

    9. 移行の失敗か、放棄 利用用途が類似するツールの乱立 SREが管理しているプラットフォーム・ツールなどが2つのバージョンで並列に動いている 10. リリースプロセス リリースプロセス・リリースの監視を更新、移行、または保守をしていない ※ Defining, Measuring, and Managing Technical Debt(2023)Ciera Jaspan, Collin Green - https://ieeexplore.ieee.org/document/10109339 より引用
  6. 1. 移行が必要なモノ、または進行中のモノ 問題:Google Cloudに存在するリソースの一部はIaCで管理、Google App Scriptなどそれ以外のツールなどについて は管理できていない。 処方箋:開発チームに勉強会等でTerraform/k8sを広め、管理を進めている。gcloudのTerraform一括エクスポートな どツールをフルに使おう。 2.

    ドキュメント 問題:ドキュメントのメンテナンスは頭を悩ませているところで、スマートな解決方法が見つけられておらず技術的 負債になっている。 処方箋:何かしらを変更した際には必ずドキュメントも変更するよう心がけ、開発チームにも「ここを見れば分かり ますよ」という共有も都度行う。とはいえもしかしたらヌケモレがある可能性も・・・(心配になってきた 3. テスト 問題:SREのツールなどはテストが欠けているものが多い、開発チームへの仕組み作りもまだ。 処方箋:開発チームへの仕組みづくりとしてはテストカバレッジをPRに表示させる。SREのツールは簡単な作りなも のが多いので、GitHub Copilot Chatにガッと書いてもらうとかできる・・・かも?(未実施 ※ Defining, Measuring, and Managing Technical Debt(2023)Ciera Jaspan, Collin Green - https://ieeexplore.ieee.org/document/10109339 より引用
  7. 6. コードの劣化 手を付けられていない。リファクタリングをやりたい欲求はあるものの、ビジネスインパクトや開発チームへの影響などを考えると優先度が 低くなってしまっている。 また、プロダクションコードに対しては開発チームに一任しているものの、SRE側で何かしらの仕組み作りが出来ていない。 7. チームに必要な専門知識が不足 一人でやっているのでチームがいません・・・ そういった意味では専門知識が自分の視界から広がらないので、不足していると言えるかもしれません。 とはいえ泣き言を言っていられないので、逆に開発チームにSREや関連技術に対する勉強会を開いて知識共有をしていたりします。

    8. 依存関係 Renovationで依存関係のバージョン更新を監視している。但し、更新作業はSRE主導でやっているため緊急度の低いものに対しては1年に1 回ガッとやっている。(よろしくない) 9. 移行の失敗か、放棄 これは幸いにも一人でやっているので起こっていない。 巨大な組織でEmbedded SREが各所に存在しているところは起こりそうだなとは思う。 10. リリースプロセス 更新・移行・保守は都度行っている。しかし、リリース監視については甘いところがあって、ArgoCDでのSyncが失敗した場合の通知や、ス テップ毎の失敗時の通知は行えていない。 ※ Defining, Measuring, and Managing Technical Debt(2023)Ciera Jaspan, Collin Green - https://ieeexplore.ieee.org/document/10109339 より引用 (もし時間があれば)