以为上了容器就是云原生
不少人觉得，只要把应用打包成 Docker 镜像，再跑在 Kubernetes 上，就算是迈入云原生了。其实不然。就像买了一辆电动车，不代表就会节能减排——如果还是用燃油车的思路去驾驶，频繁急加速、长时间怠速开空调，那和油车也没太大区别。同样，把传统单体应用直接搬进容器，却不做服务拆分、配置管理、弹性设计，只是“穿着云原生的衣服走老路”。
真正的云原生不只是技术工具的替换，更是一整套开发、部署、运维理念的转变。比如服务要无状态、可水平扩展，配置要外置化，日志要集中采集，故障要能自动恢复。
盲目追求微服务拆分
有些团队一听微服务好，立马把原本结构清晰的单体系统大卸八块，拆出几十个服务。结果呢？服务之间调用链复杂，一个接口变动要通知五六个团队，发布一次得拉群对齐半小时。这就像家里做饭，本来一个人能搞定的事，非要分成买菜组、洗菜组、切菜组、炒菜组，沟通成本反而拖垮效率。
微服务适合业务边界清晰、团队规模较大的场景。小项目或初期产品，单体架构可能更轻便高效。拆不分早晚，而看实际需要。
忽视可观测性建设
系统上云之后，问题排查不能靠登录服务器 top 一眼看了。但很多团队只关注部署流程自动化，却没搭好监控告警、链路追踪和日志查询体系。一旦出问题，就像在黑夜里找开关，只能凭感觉重启服务碰运气。
一个典型的例子是，某个接口突然变慢，没有链路追踪的话，你根本不知道卡在哪个服务。加上 Prometheus 做指标收集，Jaeger 做分布式追踪，ELK 收集日志，才能做到“看得清、查得快、定位准”。
把 CI/CD 当作一次性工程
不少公司花大力气搭建了一套 Jenkins 或 GitLab CI 流水线，跑通第一次构建部署后就搁置不管了。YAML 配置写死环境地址，测试环节手动跳过，回滚机制缺失。久而久之，流水线成了“展示品”，每次上线还得人工干预。
CI/CD 不是建完就完的事，得持续优化。比如通过 Git Tag 自动触发发布，集成单元测试和安全扫描，设置灰度发布策略。让代码合入主干后，能自动走完测试、构建、部署全流程，才叫真正的持续交付。
过度依赖托管服务，失去掌控力
公有云提供了各种托管 Kubernetes、消息队列、数据库服务，用起来确实省心。但有些团队完全依赖厂商控制台操作，连基本的 kubectl 命令都不熟悉。一旦出现网络波动或平台维护，连查看 Pod 状态都不会，只能干等客服回复。
托管服务是工具，不是拐杖。核心能力还是要掌握在自己手里。比如关键配置要代码化（Infrastructure as Code），用 Terraform 或 Helm 管理资源；运维操作要有命令行预案，不能只点鼠标。
忽略安全左移
安全常被当成最后一步，等到渗透测试才发现镜像里带着高危漏洞。有人还在 Dockerfile 里用 alpine:latest，也不管基础镜像有没有已知 CVE。这就像装修完房子才想起来检查电线是不是裸露的。
正确的做法是在 CI 流程中加入镜像扫描，比如用 Trivy 检测依赖漏洞，用 OPA Gatekeeper 校验资源配置是否合规。把安全检查嵌入日常流程，比事后补救靠谱得多。
FROM alpine:3.18
USER nonroot
COPY app /app
EXPOSE 8080
CMD ["/app"]哪怕只是一个简单镜像，指定固定基础版本、使用非 root 用户、明确声明启动命令，都是基本的安全习惯。