都说运维开发要往平台化走，需要搞一套完整的CI/CD，最好再让Kubernetes成为底座。 我在那个岗位待了六年，一开始也信这套。 直到去年我把一套服务从K8s迁回到普通云主机，用systemd加一个二百行的Python脚本，监控和告警全在Shell里跑，整个运维开发的工作量反而少了一半。 我说这话不是想倒退，而是想让大家停下来想想，我们到底是在解决故障，还是在制造需要解决的故障。 说实话，整个行业现在都有点像装修爱好者，不停地往墙上钉柜子，结果墙壁都快要塌了。
先说对比：我有一个高并发推送服务，按官方最佳实践放到K8s，三个节点，每个节点需求2核4G。 实际监控发现K8s组件占了差不多1.2GB内存，我业务容器只占了500MB。 更糟的是，有次网络抖动导致节点NotReady，集群自动迁移Pod花了差不多8分钟，而业务本身是无状态的，真正需要的是快速摘掉坏节点。 后来我把同样的服务放在三台4G的云主机上，nginx负载均衡加systemd守护，重启连一秒都不到。 最讽刺的是，之前用K8s时要为它专门维护一套镜像仓库、Ingress控制器和RBAC权限，现在这些全删了，我的工作反而更聚焦在业务健康检查上。 如果你不需要动态扩缩容，K8s带来的复杂度就是纯负债，不是资产。
不过我的结论不是要抵制工具，而是要把决策变成一种筛选。 我把手头的服务分成三类：第一类是稳定的无状态API，只在固定时间刷新缓存，这种我用systemd+keepalived，五分钟能搞定一套；第二类是有状态数据库，极少数需要弹性，主从复制加cron备份就够了；第三类是真正有突发流量且无法预测的，比如活动上的推送，这种我才会去考虑K8s。 这样分类之后，我的运维开发工作变成了一堆非常具体的小脚本：检查主从延迟的、自动清日志的、验证证书过期日期的。 每个脚本都短小但直接，不需要调一堆参数，出问题的时候看输出就能知道哪里挂。 我最近甚至开始把一些监控逻辑写进crontab，每五分钟跑一次curl，然后拿结果跟阈值比较，如果不对就执行恢复动作。 不少同事觉得我这样太原始，但我觉得这恰恰是经过了三年平台化折腾之后，我能想到的最稳的方案。
如果说真有什么全新观点，那就是：运维开发的本质不是自动化，不是平台化，而是对抗复杂度。 很多团队一提运维开发，先想到用Ansible、Terraform、K8s把事情“抽象”起来。 可抽象是有代价的——每个工具都是一个需要持续学习的新世界，而这个世界的Bug并不会因为你是运维开发就绕开你。 我见过太多故障不是脚本写得烂，而是团队把简单事情包装成了平台：一个需要理解网络策略、服务网格、HPA的多层系统，出了事连定位都要开好几层页面。 所以我会在代码评审里直接拒绝那些引入新组件的提案，除非你能证明它能省下大于它带来的维护时间。 运维开发应该敢于说“不”，并且敢于用awk加一个函数去解决别人想用开源框架解决的小问题。 没有银弹，只有约束的边界，那个边界就是你的服务真正需要什么。
