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

Transcript

1. 実録！一人SREが直面して いる技術的負債
2. 名前　　　　　　：井上 翔太 X（旧：Twitter）：@syossan27 会社　　　　　　：株式会社MIXI コミュニティ活動として「ゆるSRE勉強会」ってのを やってます！！ SRE MagazineというWeb雑誌も始めようとしてます 自己紹介 2
3. ゆるSRE勉強会 #5 参加者、絶賛募集中です！！ ※ ゆるSRE勉強会 #5 しくじりSRE - 俺みたいになるな！ connpassページ - https://yuru-sre.connpass.com/event/312943/
4. 本題に入る前に・・・
5. スポーツ観戦ができる飲食店に特化した 飲食店検索・予約サービス （2021.04 リリース） サッカーはJ1~J3、野球はパ・リーグに 対応！（2023年9月時点） 様々な施策も実施中！！ ユーザーにとっては … スポーツ観戦できる飲食店をエリアやチーム、上映予定から 検索し、予約できる お店にとっては… お店でスポーツ観戦ができることを告知し、集客すること ができる
6. 皆さんは一人でSREingしてますか？
7. ・リソース不足 ・観点の擦り合わせができない ・新しい視点の取り入れがない ・さみしい
9. 膨れ上がる技術的負債・・・
10. そもそもSREにおける技術的負債ってなに？
11. 「Defining, Measuring, and Managing Technical Debt」 → 技術的負債にはどのようなものがあり、 どのように測定・管理するか？について述べた論文 ※ Defining, Measuring, and Managing Technical Debt（2023）Ciera Jaspan, Collin Green - https://ieeexplore.ieee.org/document/10109339
12. 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に当たるような負債。
13. 6. コードの劣化 時間経過とともにリファクタリングが必要なコー ドが存在している 7. チームに必要な専門知識が不足 離職・移動による人材不足、またはチーム内での 知識の共有場所がない 8. 依存関係 依存関係における依存先の不安定さ・変化に対す る耐性・管理不足 9. 移行の失敗か、放棄 ２つのバージョンが並列で動いている 10. リリースプロセス リリースプロセス・リリースの監視を更新、移 行、またはを保守していない ※ Defining, Measuring, and Managing Technical Debt（2023）Ciera Jaspan, Collin Green - https://ieeexplore.ieee.org/document/10109339 より引用 先程の負債よりもインシデントに繋がる危険性はまだ低 い。 7の専門知識が不足していることが技術的負債にカテゴ ライズされていることが面白い。 → これは6のコード劣化と密接な関係にあり、単純にリ ファクタリングするための専門知識が足りていない可能 性
14. これをSREの文脈に照らし合わせてみよう
15. 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 より引用
16. 6. コードの劣化 SREが管理しているプラットフォーム・ツールなどに関するコードの劣化、コード劣化に対する仕組みづくりが不 十分 7. チームに必要な専門知識が不足 離職・移動による人材不足、またはチーム内での知識の共有場所がない 8. 依存関係 依存関係における依存先の管理不足 9. 移行の失敗か、放棄 利用用途が類似するツールの乱立 SREが管理しているプラットフォーム・ツールなどが２つのバージョンで並列に動いている 10. リリースプロセス リリースプロセス・リリースの監視を更新、移行、または保守をしていない ※ Defining, Measuring, and Managing Technical Debt（2023）Ciera Jaspan, Collin Green - https://ieeexplore.ieee.org/document/10109339 より引用
17. 直面している技術的負債を割り当ててみよう
18. 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 より引用
19. 4. コード品質 問題：品質自体に原義のようなレベルの品質のコードはない。しかし、SRE・開発チームともにコード品質への仕組 み作りは正直ほとんど出来ていない。 処方箋：品質に対する静的解析結果をPRに貼り付けるなどを考え中・・・ 5. 廃止・放棄されたコード 問題：利用されていない仕組みはない・・・はず 処方箋：とはいえ定期1on1を走らせて、開発チームが必要としていない仕組みはないかお尋ねするようにし、必要の ないものはバサッと削除・改善するようにしている。（対話、大事 ※ Defining, Measuring, and Managing Technical Debt（2023）Ciera Jaspan, Collin Green - https://ieeexplore.ieee.org/document/10109339 より引用
20. 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 より引用 （もし時間があれば）
21. まとめ
22. • 一口に技術的負債といっても様々な種類がある • SRE文脈に照らし合わせてみると「SREに対しての視点」と「他チームに対しての視 点」の２つの視点が必要そうなことがわかった • カテゴライズに当てはめることで出来てるところと出来てないところの明確化ができ、 どこから手をつけるべきかもわかりやすくなる • とはいえ一つの説の上での話なので、マーティン・ファウラー氏の「技術的負債の四象 限」※ とか他の説も目を通そう ※ Technical Debt Quadrant（2009）Martin Fowler - https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
23. ご清聴ありがとうございました 23