大家有没有遇到过这种情况公司已经把应用一股脑塞进了容器里Kubernetes集群也跑了一年多但每次搞大促或者业务突发流量还是熬夜扩容、手工重启、到处救火。说白了这只是完成了“云部署”离“云原生”还差得远。我这些年帮不少团队做过架构演进和平台上云的工作见过太多类似案例。很多人把云原生理解成一堆技术名词的堆砌容器、K8s、微服务、Serverless、Service Mesh……学了一堆工具落地的时候却发现处处是坑。其实云原生不是某一种具体技术而是一整套从设计、开发、交付到运维的全链路生产方式的重构。它的核心是让应用天生就适应云的环境充分利用云的弹性、分布式和自动化能力而不是把传统的物理机思维原封不动搬过来。这篇内容就是基于我自己的实战经验把云原生从入门到深入的核心逻辑、落地路径、平台建设、资源管理、排错技巧以及最容易忽略的组织协作问题系统地整理一遍。不管你是刚接触云原生的开发、运维还是正在推动团队做架构升级的技术负责人都可以照着这篇文章的脉络去规划自己的路线少走一些我当年走过的弯路。1. 云原生底层逻辑为什么我们总说“上云不等于云原生”先聊一个老生常谈但始终没被重视的问题到底什么是云原生云原生计算基金会CNCF给出的定义是云原生技术帮助企业在公有云、私有云和混合云等动态环境中构建和运行可弹性扩展的应用。它的典型特征包括容器化、微服务、声明式API、服务网格和不可变基础设施。这个定义比较官方我用大白话翻译一下云原生是一套让应用和基础设施“解耦”的方法论让应用跑在任何地方行为都保持一致并且能根据流量自动伸缩、自动修复。很多团队以为上了Kubernetes就等于云原生这是最大的误解。Kubernetes只是云原生技术栈里的一个底座它帮你解决了容器编排和资源调度的问题但应用本身如果是“云生地”的迁上来一样跑得别扭。我见过不少项目把单体应用直接打个镜像扔进K8s环境变量用硬编码日志写到本地文件数据存本地磁盘配置文件靠手工改。结果Pod一重启就丢数据扩容三五个副本有一半启动失败最后运维天天手动上去清理、重启比物理机时代还累。要理解云原生得抓住几个底层逻辑。第一是不可变基础设施。传统模式下服务器是“可变”的软件出问题了运维会上线打补丁、改配置、装依赖修修补补继续用。云原生下基础设施是“不可变”的镜像构建完成之后就固定下来任何修改都通过重新构建、重新发布来完成而不是在线修改运行中的容器。这个理念的好处是环境完全一致测试没问题生产基本就不会因为配置漂移出问题。第二是声明式API。你告诉系统你期望的最终状态是什么比如“我要3个副本每个副本需要1核2G”系统自己负责去达成这个状态。打个比方传统方式是打电话给运维说“帮我装个tomcat再改个端口顺便配个nginx”声朋式的方式是你写一份部署清单提交上去平台自动帮你完成。你对系统说“我要这个结果”而不是“你要执行这些步骤”。第三是可观测性。云原生应用是高度动态的容器随时启停实例随时迁移你再也不能用“登录服务器看看”的方式来排查问题了。一切都需要通过日志、指标、链路追踪、事件这些手段来观测系统内部状态而且应用层面需要主动暴露这些信息而不是等出了问题再说。第四是弹性。云原生设计的目标之一就是按需伸缩应用组件要支持水平扩展无状态的扛流量有状态的数据要能平滑迁移让资源使用效率最大化。这四点不是独立的技术而是相辅相成的架构约束。云原生本质上是把应用从“依赖特定环境”变成“平台无关的、可以随时弹性伸缩的一组服务”这一点想通了后面所有工具选型、架构设计、运维模式才有方向。提示判断你的系统是不是真的云原生最简单的测试是——把整个环境从头到尾重建一遍包括集群、镜像、数据库、配置你能不能在几个小时内用自动化手段恢复全部服务如果答案是做不到那说明你的系统离云原生还有距离。2. 演进路线从传统“IOE”架构一步步走向云原生很多人一听“云原生改造”就头大觉得要把现有系统推倒重来。实际上成熟的做法是从传统架构渐进式地演进而不是一刀切重写。尤其是很多传统企业还跑在“IOE”这套经典技术栈上这套组合曾经非常稳定但扩容全靠堆硬件成本高、弹性差、交付周期长和如今业务快速迭代的需求越来越不匹配。IOE这个说法有点年头了是IBM小型机、Oracle数据库、EMC存储的缩写。放着好好的老系统非要把数据库从Oracle换成MySQL或者PostgreSQL这其实不是云原生的第一步。云原生改造并不等于“换数据库”而是先解决应用层的问题。我习惯把演进路径拆成四个阶段每个阶段有明确的目标和验证标准。第一阶段基础设施容器化把应用从物理机/虚拟机迁移到容器里跑。这个阶段不用一上来就上K8s可以先用Docker Compose在单机环境跑起来积累镜像构建、环境隔离、依赖打包的经验。关键是应用要改造成符合12要素配置外置、日志标准输出、无本地状态。这个阶段的目标是“应用可以不可变地交付了”也就是同一个镜像在开发、测试、生产跑出来的行为完全一致。第二阶段编排与调度应用上Kubernetes解决弹性伸缩、滚动更新、故障自愈的问题。这个阶段是坑最多的时候后面我会专门讲。这里想强调一点不是所有应用都适合马上拆微服务但所有应用都适合容器化。单体应用容器化之后同样可以利用K8s的滚动更新和故障恢复能力先把平台能力用起来微服务改造可以按业务的痛点逐步推进。第三阶段服务化与微服务治理这个阶段开始考虑拆分应用。拆分的依据不是“别人都拆了”而是业务模块独立演进的需求。比如某个模块的发布频率明显高于其他模块某个模块的流量峰值特别陡某个模块的故障会拖垮整个系统这些都是拆分的信号。拆分之后要配套上服务注册发现、配置中心、网关、链路追踪这些微服务治理组件。如果团队规模不大、业务复杂度不高硬拆微服务只会让运维成本暴涨这一点务必冷静评估。第四阶段Serverless与按需资源当容器化微服务化都成熟了可以考虑把一部分业务下沉到Serverless形态。比如计算密集型的短任务、事件驱动的数据处理、突发流量大的API都可以用Serverless平台托管做到真正的按调用次数付费和零闲置成本。这个阶段的核心收益是让开发者只关注业务代码基础设施的细节完全交给平台。四个阶段里面最难的既不是技术也不是架构而是如何让团队在改造过程中还能正常交付业务。我对接的传统企业里比较有效的办法是采用“绞杀者模式”用一个新的云原生应用逐步从一个老系统的边缘模块开始替换每次替换一小块流量验证没问题了再继续下一块最终让新应用慢慢“绞杀”掉老系统。整个过程不需要大爆炸式的重写业务一直在跑团队的风险可控也容易获得管理层支持。每个阶段的转化都要有一个明确的“验收指标”不能含糊阶段核心指标典型动作容器化镜像构建成功率、环境一致性12要素改造配置外置日志标准化编排调度故障恢复时间、发布效率上K8s滚动更新存活性探针资源配额微服务化独立发布频率、故障爆炸半径服务拆分注册发现网关链路追踪Serverless闲置成本、弹性伸缩速度事件驱动函数按量付费自动扩缩注意演进过程中最容易翻车的地方是“先让代码在容器里跑通就行”忽视了有状态应用的数据问题。数据库、缓存、消息队列这类有状态组件在容器环境里处理起来要小心很多后面我会单独讲资源管理和存储的坑。3. 平台底座怎么搭从零到生产可用的Kubernetes集群如果决定自己搭建Kubernetes集群而不是用云厂商托管的K8s服务我强烈建议先想清楚一个问题你的团队有没有专门的平台工程师来维护这套东西如果没有就老老实实用云厂商的托管服务多花点钱换省心是值得的。自己搭集群节点升级、证书轮换、etcd备份、网络插件的调优、安全组策略这些日常维护工作量真不小。如果团队里有愿意钻研基础设施的“狠人”那自己搭也能收获极大的掌控力。生产级集群的规划我一般按下面几个维度来考虑。3.1 集群架构与高可用设计首先是Master节点的规划。一个生产集群至少要有3个Master节点部署etcd、API Server、Controller Manager、Scheduler这几个核心组件。3个节点可以容忍1台故障5个节点可以容忍2台故障。Master节点的硬件不需要特别高端但磁盘IO一定要好因为etcd对磁盘延迟非常敏感建议用SSD并开启独立的etcd磁盘分区。Node节点是真正跑业务负载的机器规格选择你要看业务类型。如果是CPU密集型的计算任务选择高主频的机器如果是内存密集型的缓存类应用选择大内存的机器如果是常规Web服务通用型机器就行。这里有个容易被忽略的问题不要在一个集群里混合跑太多差异巨大的工作负载。比如把离线大数据任务和在线交易任务放进同一个集群资源竞争和故障隔离会变得非常难搞。3.2 网络插件的选择Kubernetes本身不实现网络需要外挂CNI插件。最常见的几种Flannel简单易用性能尚可适合小规模集群和追求低运维成本的场景。Calico支持NetworkPolicy网络策略性能好适合对安全和网络控制要求较高的生产环境。Cilium基于eBPF技术性能最好可观测性极强适合大规模集群和需要细粒度网络策略的场景。我个人早期用的是Flannel图它简单后来规模上来之后发现网络策略做不了只能被迫迁移到Calico。如果你是新规划集群从第一天开始就用Calico甚至一步到位上Cilium省得后面迁移的麻烦。网络策略是生产安全的重要组成部分没有它你的集群里任何Pod都能和任何Pod通信哪怕是不该通的。3.3 存储与有状态应用云原生最核心的一个矛盾是容器是无状态的但企业的数据必须有状态。Kubernetes里有PV和PVC的抽象存储插件CSI可以对接云厂商的云盘、网络存储、对象存储等。我的经验是数据库这类高IO、强一致性的组件能不容器化就不容器化。直接用云厂商的关系型数据库托管服务把存储和计算都托管掉你省下的是整整一个专业DBA团队才能搞定的运维工作。如果非要容器化跑数据库一定要用StatefulSet 本地SSD盘 定期备份的方案并且做好充分的压测。非数据库类的有状态应用比如消息队列、缓存集群可以考虑用Operator机制比如Kafka的Strimzi、Redis的Spotlight Operator来管理。Operator相当于把运维专家经验写成了自动化代码它能帮你处理集群的扩容、故障转移、备份恢复等操作这是云原生运维的高级形态。3.4 镜像仓库与制品管理应用容器化的第一步是把代码变成镜像所以镜像仓库是平台底座的重要组成部分。常见的方案方案适合场景备注Docker Hub个人学习、开源项目拉取频繁有限制云厂商镜像仓库生产环境首选和内网打通安全可靠Harbor私有化部署、安全合规要求高支持镜像签名和漏洞扫描镜像仓库除了存镜像还要做好几件事镜像的版本管理用tag而不是latest、漏洞扫描在CI阶段集成、访问权限的控制。很多团队生产环境出事就是因为某个开发者取错了镜像tag或者把含敏感信息的镜像推到了公开仓库。镜像安全是供应链安全的第一道门。平台底座建好之后应用部署的方式也要规范化。一套成熟的部署流程至少包含这些步骤代码提交 - 单元测试 - 镜像构建 - 镜像扫描 - 推送到仓库 - 部署到测试环境 - 自动化测试 - 灰度发布到生产 - 健康检查确认 - 流量切换。这个流程跑通之后你才真正尝到云原生带来的甜头——发布变成了一件低风险、可回滚的日常操作。4. 弹性伸缩与资源配额别让GPU和CPU成了稀缺品云原生最吸引人的特性之一就是弹性。但弹性是一把双刃剑配好了业务突增时系统自己扩容没人需要半夜起床加机器配不好资源被无节制地抢占整个集群被打爆所有应用一起遭殃。说到资源管理我想到最近总能看到“GPU配额已不够预冻结”这类问题。GPU资源有个特点昂贵、稀缺、不能超卖。CPU你可以让多个Pod争抢一个核但GPU的显存和计算单元一旦分配出去别人就用不了。所以GPU集群的资源管理比CPU要严格得多必须靠配额和调度策略来硬性约束。4.1 理解requests和limits的区别Kubernetes里每个容器都可以声明两类资源requests请求量调度时保证和limits限制量运行时上限。很多人一开始搞不清这两者的关系踩过不少坑。用大白话解释requests是交给调度器的“简历”告诉它我这个Pod最少需要多少资源才愿意跑在这台机器上。调度器看到Node剩余资源不够就不会把Pod调度过去。limits是运行时“封印”进程最多只能用到这么多资源多了会被限制CPU被节流或者杀掉内存OOM。对于CPUrequests和limits一起设可以保证Pod优先拿到requests的CPU时间超出requests但低于limits的部分属于“尽力而为”的突发资源。对于内存limits设置多少就是硬上限超了内核会杀进程。所以我经常跟团队强调内存的limits要基于真实的峰值需求留足缓冲设太低会引发OOMKilled设太高会浪费资源。4.2 资源配额与LimitRange的落地配置生产环境一定要做资源配额管理否则某几个大应用可能会把整个集群的节点资源吃光。Kubernetes原生提供了ResourceQuota和LimitRange两套机制。ResourceQuota是命名空间级别的资源配额限制整个命名空间中所有Pod的总资源量apiVersion: v1 kind: ResourceQuota metadata: name: dev-team-quota namespace: dev spec: hard: requests.cpu: 20 requests.memory: 40Gi limits.cpu: 40 limits.memory: 80Gi persistentvolumeclaims: 10 pods: 50这样一来dev命名空间最多只能使用20核CPU请求、40Gi内存请求如果超了新的Pod和PVC就创建不了会直接报配额不足的错误。配额的核心作用是把资源按团队或项目预先“切好蛋糕”防止一个项目拖垮所有项目。LimitRange是用来约束单个Pod的默认值和极值的apiVersion: v1 kind: LimitRange metadata: name: default-limit-range namespace: dev spec: limits: - default: cpu: 500m memory: 512Mi defaultRequest: cpu: 100m memory: 128Mi max: cpu: 4 memory: 8Gi type: Container这个配置的意思是dev空间里的容器如果没有显式声明资源自动获得默认值单个容器最多申请4核8G防止有人误设了离谱的资源请求。这套组合拳打下来集群资源的使用就处于一个可控的边界内。4.3 水平伸缩方案从HPA到KEDAKubernetes内置的HPAHorizontalPodAutoscaler可以根据CPU、内存或自定义指标自动调整副本数。比如apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-server-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web-server minReplicas: 3 maxReplicas: 30 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 behavior: scaleDown: stabilizationWindowSeconds: 300这里有一个很重要的参数behavior.scaleDown.stabilizationWindowSeconds它设置了缩容的冷却时间。很多团队刚开始用HPA时发现Pod数量抖动得很厉害——流量一降副本数立刻减下来流量稍一高副本数又冲上去。这个“伸缩震荡”对系统稳定性非常不友好。设置一个5到10分钟的稳定窗口让副本数在流量下降后保持一段时间可以避免频繁启停Pod带来的性能损耗和资源浪费。对于更复杂的弹性场景比如基于消息队列积压数量来扩容HPA就有些捉襟见肘了这个时候可以上KEDAKubernetes Event-driven Autoscaling。KEDA可以监听外部系统的指标比如Kafka消息积压数、RabbitMQ队列长度、数据库连接数等到达阈值就自动扩容消息处理完了再平滑缩容。这本质上是把弹性的触发源从“资源使用率”扩展到了“业务负载”本身更贴近真实需求。4.4 GPU场景的资源管理GPU资源比CPU更需要配额管理因为它的稀缺性和不可超卖性。如果你的集群有GPU节点可以考虑用节点池隔离的方式GPU节点打上污点和标签只有声明了需要GPU的Pod才能调度上去。然后配合ResourceQuota限制每个团队最多能申请多少块GPU避免某个团队一次把所有GPU都“预冻结”了导致其他团队的任务饿死。这里还要特别注意GPU的requests和limits通常都是直接设为完整的GPU数量比如1、2、4没有小数。原因是目前主流的GPU调度器都按整卡分配而且显存隔离在容器层面还不像CPU那样规整。所以做GPU配额的时候预留量要比实际需求高一些因为显存碎片会导致卡利用率上不去。建议不管是CPU还是GPU集群里的资源配额一定要结合业务预测定期调整。我见过不少团队建了配额之后就没人管了结果业务增长配额成了瓶颈开发找到运维说“我明明申请了不少配额为什么这周又满了”一查发现真正的瓶颈往往不是配额而是某个服务内存泄漏或者上游流量异常放大。先把监控数据拉出来再谈加配额。5. 生产环境排错实战那些“玄学”问题根因其实都相似云原生应用跑在生产环境出问题的时候你的定位手段和逻辑跟传统方式完全不同。传统方式是登录服务器查进程、看端口、看磁盘容器化之后你得学会通过描述信息、日志、事件、监控曲线来拼出完整的故障链路。我挑了四个最容易让人抓狂的高频问题分享一下完整排查链路。5.1 Pod一直Pending调度器到底在说什么问题现象创建一个Deployment后Pod状态卡在Pending好几个小时不变化。很多人第一步就是删掉重来或者看日志但多半看不出什么东西。正确的第一步是kubectl describe pod pod-name -n namespace输出里面会有一段Events信息直接告诉你调度失败的原因。最常见的几种Insufficient cpu节点没有足够的CPU请求量。这时候你要去查看集群节点资源kubectl top nodes看看是哪个节点满了或者是不是所有节点都满了。Insufficient memory同理。0/3 nodes are available: 3 node(s) didnt match node selectorPod上打了nodeSelector或用nodeAffinity但没有任何节点匹配。0/3 nodes are available: 3 node(s) had taint {xxx}, that the pod didnt tolerate节点打了污点Pod没有容忍这个污点。还有一种情况容易被忽略PVC创建不出来。比如存储类StorageClass不存在或者PVC请求的容量超过了可分配的阈值Pod也会Pending。我的排查顺序是describe看事件 - 看节点资源top - 看PVC状态 - 看是否有网络/存储插件异常。按这个链路走大多数Pending问题都能在三五分钟内定位。5.2 CrashLoopBackOff容器反复重启到底卡在哪一步CrashLoopBackOff的意思是容器启动后崩溃然后被Kubernetes反复重启退避时间逐步增加。这个问题的排查要分启动阶段看如果容器启动后立刻退出看日志kubectl logs pod-name -n namespace --previous--previous参数非常关键因为容器崩溃后当前日志可能已经空了只有上一个容器的日志里才保留了崩溃原因。常见的原因有启动命令找不到或执行失败比如路径写错、环境变量没配置配置的探针失败容器被判定不健康而重启内存超出limits被OOMKilled日志最后是Killed或者OOMKilled状态对于探针失败你要用另一个命令看事件kubectl describe pod pod-name -n namespace然后定位到Readiness或Liveness探针的失败信息。很多情况下探针路径配置错了或者服务绑定的监听地址不是0.0.0.0导致探针请求失败。检查完日志和事件还没找到原因就进入容器里手动复现kubectl exec -it pod-name -n namespace -- /bin/sh在容器里手动跑一下启动命令看看报什么错。这一步往往能暴露真正的依赖问题比如缺少动态库、连不上数据库、配置文件读取不到等。5.3 CPU限流引发的“假慢”有一个很隐蔽的性能问题Pod的CPU是设置了limits的比如500m0.5核而Node上的CPU核心数很多。当Pod实际使用CPU超过limits时Kubernetes不会杀掉Pod而是会对CPU进行节流throttling就像限速器一样把Pod的CPU使用速率压到上限值。表现就是服务整体变慢延迟升高但CPU使用率从容器视角看一直顶着上限你又找不到明显的报错。这个问题的排查靠日志和事件是看不出来的。你需要去监控系统里看容器的CPU Throttling指标比如cAdvisor提供的container_cpu_cfs_throttled_periods_total。如果节流次数很高说明这个Pod的CPU limits设得太低了要么增加limits要么优化代码降低CPU消耗。我遇到过最经典的案例一个Java服务在物理机时代跑得好好的容器化之后每隔几分钟就有一波高延迟。查了很久最后发现是JVM默认的GC线程数量是根据宿主机CPU核数来算的而容器的CPU限额只有2核JVM却以为有32核导致GC线程启动过多CPU资源在GC上消耗殆尽。解决方法是给JVM设置-XX:ActiveProcessorCount2让它和容器的CPU限额对齐。这类“容器感知”的坑在把传统应用搬进容器时特别常见。5.4 存储卷挂载失败与权限问题有状态应用常见的故障是PVC挂载不上。现象是Pod处于ContainerCreating状态describe可以看到类似FailedMount的事件。排查思路先看存储类是否存在、PV是否已经绑定kubectl get pvc -n namespace kubectl get pv如果PVC状态是Pending说明存储供给有问题要看StorageClass是否创建存储后端是否可用如果PVC是Bound但Pod挂载失败重点检查文件系统权限特别是非root用户运行容器时宿主机的挂载目录往往权限不对导致读不了写不了。另外如果多个Pod挂载同一个底层存储要注意底层的冲突比如两台Node同时以读写方式挂载同一个卷会引发文件系统损坏。排查这类问题最终手段是看Kubelet的日志。在对应Node节点上执行journalctl -u kubelet -n 200 | grep namespaceKubelet日志里通常会有挂载失败的细节比如mount.nfs: access denied或者filesystem has duplicate mount point这些信息会直接指向根因。经验之谈生产环境的故障排查第一原则是“看事件、看日志、看监控”而不是“重启试一下”。重启有时候确实能解决临时问题但不定位根因同一故障会在三个月后以同样的方式再来一遍。花二十分钟彻底排查比花两小时反复重启更有价值。6. 组织与流程云原生落地的隐形卡点技术层面的内容聊得差不多了最后想聊聊一个很多技术文章不怎么涉及、但恰恰是云原生落地成败关键的维度组织和流程。云原生改变的不仅是技术栈更是团队协作方式。在传统运维模式下开发负责写代码运维负责运维发布靠文档交接出了问题两边互相推诿。到了云原生时代这种模式完全跑不通了因为基础设施能力已经被平台抽象掉了开发和运维的边界变得模糊。一个比较普遍的做法是开发团队要对自己写的服务在线上运行的质量负责也就是所谓的“开发自运维”或者“You build it, you run it”。具体到落地层面有几个很实际的要求。第一个是“谁开发谁OnCall”的制度。服务的开发者对线上告警第一时间响应而不是等用户反馈才知道系统出问题。刚开始推这个制度一定会有阻力开发会说“我跑在容器里监控告警我还没来得及写线上环境的问题我怎么处理”实际上正是因为开发要负责线上才会倒逼他把日志、指标、链路追踪这些基础能力在开发阶段就做好而不是等上线了再让运维去“接锅”。一个好的团队会为开发提供一套标准化的可观测性模板新服务上线前填好告警规则和应急预案这个门槛其实不高但能极大减少线上事故的处理时间。第二个是SLO文化。SLO是Service Level Objective即服务等级目标比如“API请求的平均响应时间小于200ms99%的请求在500ms内完成”。定义清晰SLO的价值在于团队对系统的“健康”有一个量化共识。故障发生时优先保障核心业务SLO不滑坡牺牲一部分非关键功能而不是所有团队各自为战把所有指标都当成“不可碰的红线”。我见过不少团队第一天就立了十几个SLO天天被告警轰炸最后大家麻木了反而漏掉了真正的故障。SLO刚开始精挑细选两三个关键指标就够先把核心链路稳定下来再逐步扩展。第三个是混沌工程。云原生系统太复杂了故障模式多到无法靠人力全预判。混沌工程的核心思想是主动、有控制、小范围地向系统注入故障比如刻意杀掉一个Pod、模拟一个节点宕机、注入网络延迟然后观察系统是否按预期降级、自愈。它不是用来“搞破坏”的而是用来验证和完善系统的韧性。比较务实的第一步是在测试环境定期做故障演练比如拔掉一个可用区的一台机器、杀一个数据库的从节点观察系统表现并沉淀出改进清单。演练成熟了再逐步进入生产而且一定是要有严格的“爆炸半径控制”只影响一小部分流量。团队协作方式的改变比技术栈迁移难得多。这也是为什么很多公司买了K8s、用了容器、上了Jenkins却依然觉得“云原生”和之前没什么两样。技术是工具组织是使用工具的人。工具选对了人的协作方式不改变落地效果会大打折扣。我个人在实际操作中的体会是云原生转型最怕的不是技术债而是“既要又要还要”既想让开发快速上线又想让运维严格管控还想要基础设施零故障。这套标准在传统架构下都做不到云原生时代更不现实。先把核心业务链路的稳定性守住把小范围故障的自愈能力练出来把发布和扩容变成低风险操作云原生的价值就会慢慢显现。等你习惯了“系统自己会修复大部分问题、线上故障的定位以分钟计”的节奏之后再回头看就会觉得这套折腾是完全值得的。