为什么你的‘完美’架构正在扼杀你的 Velocity

Source: Dev.to

作为一名高级 DevOps 工程师，我花了多年时间打磨“终极 Kubernetes 部署”。我构建的服务网格复杂到可以映射人类基因组，CI/CD 流水线抽象到开发者甚至不知道自己在使用它们。而且你知道吗？其中一半其实是浪费时间。

如果你想从 Senior 晋升到 Staff 或 Principal，必须停止做“技术纯粹主义者”，转而成为“价值流动者”。以下是你对技术完美的执念为何实际上成为瓶颈的原因。

“简历驱动开发”的陷阱

我们都见过：一个三人团队在构建一个 CRUD 应用，却使用了多区域、多集群的 Istio 实现。

高级视角： 仅仅因为某个工具是“行业标准”（比如 Kubernetes），并不意味着它适合你当前的阶段。如果可以用托管服务（如 AWS App Runner 或 Vercel）解决问题，就应该使用它们。

“效率是把事情做好；效能是把正确的事做好。” — 彼得·德鲁克

为“未来规模”过度工程

“我们需要把这个系统建成能支撑 1000 万用户，”一位拥有 500 名客户的创业公司工程师如此说。

当你为尚不存在的规模进行过度工程时，会提前产生技术债务。为两年后才会到来的负载配置自动伸缩组的每一个小时，都是从今天可以获取用户的功能开发中偷走的时间。

“非我所创”综合症

一位初级工程师想构建自定义内部门户。高级工程师则倾向购买 SaaS 或使用开源工具，以便专注于公司独特的业务逻辑。

你作为 DevOps 工程师的价值不在于你能构建多么定制的监控工具，而在于你能为业务提供多好的可观测性。如果 Datadog 或 New Relic 能在 10 分钟内帮你实现目标，就付费使用，然后去解决更难的问题。

如何转向：务实的高级框架

为了获得更广的影响和更好的结果，在每一次架构决策之前先问自己这三个问题：

1. “延迟成本”是多少？
   如果我们花三个月时间去构建“完美”的基础设施，业务在这段时间会损失多少？

2. 初级人员能维护吗？
   如果你构建的系统如此复杂，只有你自己能修复，那么你并没有真正交付解决方案，而是制造了一个保住自己工作的陷阱，甚至让你永远无法休假。

3. 这是“单向门”吗？（亚马逊概念）
   我们能否轻易回滚此决定？如果可以，快速推进。如果不行（例如更换主数据库），只有在这种情况下才需要过度分析。

残酷的真相

最优秀的 DevOps 工程师并不是工具最多的人，而是知道哪些工具应该留在架子上的人。

我们的工作是让基础设施“隐形”，让产品本身发光。如果基础设施成为舞台的明星，那说明你可能走错了方向。

你曾经实现过哪款工具，后来因为其复杂性而后悔？在评论区坦诚分享吧。

#career #architecture #devops #productivity #cloud #softwareengineering