听说，整个鹅厂都在卷这张表
现在，客户们每次来鹅厂，必问：
“你们是怎么推动全公司搞云原生的？”
其实，上云初期，鹅厂自己也走过弯路——
业务习惯把物理机原封不动搬到云上，或者直接把容器当虚拟机用。
当实例变得又大又复杂，就没法快速启停，大大影响了弹性扩缩容的效率。
因为尝不到弹性扩缩容的甜头，所以大家还是习惯「堆机器」：
业务规模越大，资源浪费的问题就越突出。
而且，不少业务的技术栈都是老黄历了——
一台机器上运行着N个进程，各种连接、缓存等都是进程级别的。连接数经常打满，链路稳定性的问题很多。
总之，单靠叠床架屋，云计算的甜头还是尝不到。
其实鹅厂内部对上云早就有明确定义——
不止要上云，更要全面云原生！
并且，总办领导拍板：
自研上云，必须基于腾讯云TKE容器服务。
如果说，上虚拟机就像换底座；那么，上容器更像脱胎换骨，得各个业务部门亲自上手，重构架构逻辑。
涉及这么多部门，「推不动」是难免的：
为了让云原生进度条持续往前走，我们拉了个「云原生成熟度」表格。
说是表格，其实更像个「评估模型」。每个季度都打分，还要抄送给总办领导。
作为一项牵引机制，它在确保业务稳定的前提下，主抓三大项：
一是，可调度。
以前，为了确保运行安全，大部分业务都是不可调度的。
甚至平台侧一旦调度，业务就会报故障单。
想要提升整体利用率，每个业务都得「可调度」。
（在资源利用层面，这相当于指哪打哪）
现在，鹅厂超过95%的集群都是公共集群。
依托腾讯云的分布式云操作系统遨驰，业务不需要关注底座，选择地域后，平台会自动调度到有资源的集群里。
实现「可调度」后，业务反而更稳定了。
以前，任务固定在指定机房里，数据中心一旦跳闸停电、网络堵塞，上层业务也受影响；
现在，底层的故障可以直接无视、无感另起，稳定性大大提升。
二是，微服务
如果业务的「颗粒度」太大，会浪费不少碎片空间。
我们推动业务把单体应用拆小、改造成微服务架构，各个模块独立运行。
这个看颗粒度的指标，在鹅厂叫装箱率：
（顾名思义，装箱率高了，资源利用率也就上去了）
更重要的是，由于每个微服务都是独立的，新的特性不需要等整个系统更新，就能快速部署到生产环境里。
一句话，通过业务架构的微服务化，实现了降本和增效的双丰收。
三是，弹性伸缩
流量来的时候，能不能快速接住？走的时候，资源有没有及时回收？
只有平台和业务两侧同时实现弹性伸缩，才算实现了应对突发、降低成本的双收益。
2021年起，「上云就上云原生」成了鹅厂街头巷尾的热词。
从那年起，我们就在通过这套模型，去量化评估每个部门的云原生成熟度。
云原生一路狂飙，也把腾讯整体的资源利用率和研发效能拉了起来。
这个表，不仅总办会看、部门之间还会比：
云原生，甚至成了鹅厂的一项文化：
答辩评审标准，也会偏向云原生落地成果，做得好的答辩还能加分。
这套机制也在持续迭代：
- 半自动的弹性扩缩容，如何实现真正的自动化？
- 负载均衡、稳定性能不能再提升？
每年，公司都会微调具体维度，推动云原生走的更深。
作为鹅厂「全面云原生」的技术底座，腾讯云TKE容器服务也在一路进化，跟这项机制打好配合：
- 打造TKE Serlverless 形态，主打微服务、小核心场景，实现高效运维；
- 推出TKE原生节点，落实 FinOps 理念，助力业务降本；
- 孵化应用管理平台，结合业务容器可调度，实现整体资源最优化运营。
我们也希望，用这条鹅厂走通了的路，帮助更多客户提升资源利用率、降本增效。