以为上云就是云原生
很多团队一听说要做云原生，第一反应就是把老系统搬到公有云上，比如从本地机房迁到阿里云、腾讯云。但其实这只是“上云”，不等于“云原生”。真正的云原生强调的是用云的方式去设计和运行应用，比如弹性伸缩、服务自治、持续交付。如果只是把单体应用原封不动地扔到云服务器里，出了问题还得人工登录重启，那和以前在机房没太大区别。
盲目追求微服务
一提云原生，不少人就想着拆微服务。结果业务还没复杂到那个程度，硬是把一个简单的后台管理拆成十几个服务，每个都要独立部署、写配置、配监控。开发效率没提升，运维成本反倒翻倍。就像家里煮个面非得请米其林厨师开火，流程一大堆，等出锅都饿过了劲儿。
微服务适合业务复杂、团队庞大的场景，小项目用单体+模块化更实在。Kubernetes 不是每个应用都非用不可，轻量级服务跑个 Docker 容器可能就够了。
忽视 DevOps 文化建设
技术可以买，工具能部署，但流程和协作方式改不了，云原生就容易“水土不服”。有的公司买了全套 CI/CD 工具链，但开发提交代码后还得等运维手动发布，中间卡半天。这就像给马车装了涡轮增压，可赶车的还是不肯松缰绳。
云原生不只是技术升级，更是协作模式的转变。开发要对线上负责，运维要前移参与设计，测试要自动化嵌入流程。没有这种配合，再先进的架构也跑不顺。
配置当代码？随便放 Git 里就完事
Infrastructure as Code 确实方便，但有人图省事，把数据库密码、API Key 直接写进 YAML 文件提交到 Git 仓库。这就好比把家门钥匙贴在楼道公告栏，还写着‘谁来都能开’。
正确的做法是用 Secret 管理敏感信息，结合 KMS 加密，配合 Kubernetes 的 Secret 或外部如 Hashicorp Vault。配置可以版本化，但绝不能裸奔。
apiVersion: v1
kind: Secret
metadata:
name: db-credentials
type: Opaque
data:
username: YWRtaW4= # base64 编码
password: MWYyZDFlMmU2N2Rm # 同样需编码日志和监控只看表面
上了容器平台后，很多人只关心 CPU 和内存有没有爆，服务是不是活着。但真正出问题时，往往是某个接口突然变慢，或者重试次数飙升。这些细节指标没采集，排查起来就得靠猜。
建议从一开始就接入分布式追踪（比如 OpenTelemetry），记录请求链路。别等到用户投诉‘怎么老是加载失败’，才想起去看调用成功率。
忽略应用自身的云原生适配
有些老系统改造时，只做了容器化打包，但程序本身还是依赖本地磁盘存文件、用静态 IP 做通信、启动超时长达几分钟。这种应用丢进 Kubernetes，动不动就被重启，像穿着棉袄跳水，适应不了新环境。
真正的云原生应用应该是无状态的，配置外置，快速启停。比如 Spring Boot 应用通过 ConfigMap 注入配置，临时文件走内存目录，健康检查接口返回真实状态。
livenessProbe:
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10