福建
部署变慢，团队崩溃，迁移ArgoCD的七个坑与真相。
我们团队三十个人，管着二十多个微服务，之前一直用Jenkins。Jenkins用了三年，越来越吃力，部署一次要等十五分钟，有时候点错了还得找人手动回滚。大家觉得不能再这么凑合下去了，就决定迁移到ArgoCD，搞GitOps。
本来以为换个工具就能省心，结果踩了七个大坑，差点把团队搞散。今天把这些坑写出来，算是给想迁移的人提个醒。这些教训不是从书上看来的，是实打实熬了几个通宵换来的。
第一个坑是授权配错了。我们一开始按照Jenkins的那套思路，想着给不同人设不同角色，结果ArgoCD的RBAC跟Jenkins完全不一样。搞了两天，权限还是乱的，该看到的看不到，不该看到的反倒能改。后来想通了，别一开始就设计完美模型，先跑通核心流程，让团队看到效果再慢慢细化。
第二个坑是Helm Chart版本管理搞得一团糟。GitOps要求所有配置放Git里，我们就把Chart也塞进去了，但没管版本依赖。自动同步一开，测试环境升级了Chart，结果依赖的服务全挂了。后来强制生产环境锁死Chart版本，测试环境放开但要走PR审批，这才稳住。
第三个坑是密钥怎么放。GitOps讲究一切皆代码，但密码明文放Git里谁敢啊。我们试了Sealed Secrets，折腾半天才把加密解密流程跑通。关键是让团队接受一个观念：密钥也是基础设施的一部分，Git里只存密文，密钥由集群内部管。
第四个坑是自动同步太猛了。我们开了Self Heal，想着一出问题自动修复。结果运维手动改个配置排查问题，刚改完就被ArgoCD恢复成Git里的样子，改半天白改了。后来学会了，生产环境关掉Self Heal，用Manual策略；测试环境开Auto Sync，但明确告诉所有人手动修改只用于临时调试，不会保存。
第五个坑是多集群管理。我们想着一个ArgoCD管所有集群，省事。结果配置复杂得要命，而且安全风险大，一个集群出问题可能影响其他集群。后来每个集群独立部署ArgoCD，用ApplicationSet统一管理多环境配置，虽然管理成本高了，但安全多了。
第六个坑是健康检查的坑。部署完服务一直显示“Progressing”，半天不变成健康的。查了半天才发现是readinessProbe配置不对，超时时间太短，初始延迟不够。ArgoCD的健康检查依赖K8s的探针，探针没配好，它就觉得服务永远没就绪。后来我们重新审视了每个微服务的探针配置，把超时和延迟调合适了。
第七个坑是回滚的坑。Jenkins回滚是重新跑一次构建，ArgoCD回滚是回退Git commit。一开始不习惯，觉得回滚就是修复Bug，但ArgoCD的回滚本质是还原状态。这就要求Git历史必须干净，每次发布都要打标签，commit message写清楚。后来我们养成了习惯，每次发布打Tag，回滚就指向上一个成功的Tag，再同步，再也没出过新Bug。
这些坑踩完后，我们总结了一些经验。迁移其实不是换工具，而是换一种治理方式。以前Jenkins是任务驱动，运维要盯着构建任务；现在ArgoCD是状态驱动，所有人都盯着Git仓库。Git仓库成了唯一真相源，谁改了什么东西，什么时候改的，为什么改，全都有记录。
效果也很明显。部署时间从十五分钟降到了三分钟，但更重要的不是快，而是稳。以前部署靠运气，经常出问题还得半夜拉起来重启；现在只要Git没问题，部署就不会出岔子。新人上手也快了，不用学复杂的Jenkinsfile，只要会改Git仓库、提PR、同步就行。
现在团队里大家不再讨论“怎么部署”，而是讨论“怎么改代码”。运维的工作也从“救火”变成了“体检”，日常就是审查Git历史、优化健康检查配置。回滚也不再心惊胆战，一键还原搞定。
如果你们团队也在考虑迁移，建议先别急着搞复杂的权限和自动化，先从最简单的流程跑通，让团队看到GitOps的好处。然后慢慢踩坑，踩完一个解决一个。记住，GitOps不是万能药，但它能帮你把混乱变成有序，前提是你们愿意改变习惯。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
