聊聊云原生之系统架构稳定性与成本管理

前言

从私有云到公有云、从一朵云到多朵云，从虚拟化到容器化，从传统架构到云原生，我们见证和参与了软件服务交付模式从安装包到云原生SAAS的转变。云原生带来了极致的效率提升，给业务带来了更多可能，但同时因架构更复杂、运维难度更大，也对企业的管理水平提出了更高的要求。

今天，我想跟大家分享一些关于如何在云原生技术架构下如何做好稳定性的浅见。这些想法均源于我在云原生领域多年的实践经验，希望能给各位提供一些参考。

1、云原生架构下的稳定性：以SLA为导向

稳定性建设从来都是结果导向，作为toB企业更要注重用户体验，这里面有个关键指标即服务级别协议（SLA），里面明确规定了软件提供商对客户关于服务可用性、性能等方面的承诺，是稳定性保障的最低目标。在这个大的OKR背景下，我们提出了0-2-5-10的内部SLA，也就是常态化预防（0）、快速感知故障（2分钟内）、快速定位故障（5分钟内）和故障快速恢复（10分钟内），所有稳定性架构和场景建设都围绕这个目标进行。

0：预防为主，构建坚实根基

云原生极大提高了业务发展的速度，同时也让软件系统架构的复杂度呈指数级增长，所以故障预防已经不是仅靠运维团队单打独斗就能做好的，运维这个兵种也在向”技术运营“转变 ，需要用体系化的视角将研发工作的整个生命周期串联起来，实现架构级的故障预防体系。

（一）应用和基础设施加固

云的好处是用户不再需要关注硬件设备、网络资源的健康情况，云架构自身的弹性伸缩（横向纵向）即可满足云用户面对硬件故障、网络波动等情况时的抗风险能力。

我们考虑的是利用容器化技术，在应用层面提高抗风险能力，这需要严格的应用生命周期管理，从代码审查、制品管理、镜像构建到容器化发布，都需要严格标准化，小到系统内核参数、服务器的规格、JVM参数等，大到环境一致性（测试环境、压测环境、灰度环境、生产环境）等，都需要实现可控，避免环境因素导致的应用不可用。

在应用的架构层面，依托容器化和云原生网关，核心应用可以很快搭建出多region部署方案，结合灰度发布体系，保证业务不会同时大面积故障，在紧急情况下也可以快速将用户转移，实现业务的高可用。

（二）常态化混沌工程

通过引入故障，能够验证很多假设（包括参数是否合理、容量是不是足够、是不是存在强依赖），也能验证系统的韧性（有没有止损方案？已有的止损方案能不能正常生效？），这是非常重要的一环。我们对内的要求是所有核心业务线，每周至少进行一次混沌工程演练，日积月累下来的演练记录将是非常珍贵的财富，对于螺旋提升系统稳定性有非常重要的作用。

（三）数据治理

整个稳定性体系中，从预防到监控，从定位到止损，都离不开数据。所谓的数据治理，实际上就是把不同的数据关联起来，这绝对是一个苦差事。大家都在说数据治理，业界也有很多数据治理的方案，我认为数据治理必须以结果为导向，先有大的场景，才能有明确的需求，数据治理的成效才能显现出来，进而对需求形成反哺，实现内部自循环。没有最好的数据治理方案，只有最适合自己的，要边治理边使用，不能为了治理而治理。

2阶段：云原生可观测，快速感知

（一）监控中心

所有企业都一样，内部会使用不同的监控工具，也包括不同公有云的云监控产品。为了打造全局的可观测性体系，就需要解决监控项和报警信息的标准化问题。统一监控中心也是业界常提的概念，我们的做法是将来自不同工具的报警进行了统一纳管，这里对所有报警源的要求是必须提供最小字段集，通过这些字段，我们自研的CMDB系统就能将报警、变更等消息自动关联到业务。监控是MTTR体系的入口，如果监控消息不能携带业务属性，后面的定位和止损操作就会相对麻烦，所以底层实际上还是数据治理在发力，监控是数据治理的试金石。

（二）巡检体系

监控的特点是高频，针对关键指标，为了能实时发现问题。而巡检则是为了防患于未然，需要全面的检查，相对低频。最开始我们的巡检由人工完成，经过不断的积累，形成了丰富的巡检仪表盘，单次巡检的耗时也越来越长，有时需要耗时一上午，人工的方式逐渐开始力不从心。后来我们通过对巡检模型（主要是机器学习），对仪表盘的各类数据进行异常检测，落地了智能巡检，因为巡检数据量太大，不能像监控一样做到实时（也没必要做到实时），后来我们定为工作时间内，每半小时机器自动巡检一次，相对人工的方式更加高效，频率也更高，能够及时发现潜在的隐患。

（三）变更管理

80%的故障始于变更，基础设施层面的加固其实是故障快速止损的基本盘，但实际生产中绝大部分故障都跟变更有关。做好变更管理可以大幅提高系统稳定性，包括授权机制、回滚机制、变更可视化机制、违规变更识别等，既要制定好”交通规则“，又要装好”摄像头“，让相关人员对生产环境常怀敬畏之心。

5阶段：根因分析，高效溯源

（一）人工分析看板，可靠的手动档，最后的稻草

传统的运维手段，排查问题的过程无非是基于报警确定事情的影响范围，然后通过各类指标、日志等逐渐锁定“嫌疑人”。运维问题往往来势汹汹，根本来不及打开那么多工具，业界主流的做法是以业务可用性和性能为出发点，结合资源使用情况、访问日志和错误日志等制作统一的看板。但是不同看板的侧重点是不同的，一个看板解决不了所有问题，一般需要多个看板组合，就像飞机的驾驶舱里有许多精密仪表一样。想象一下你正在驾驶一架飞机，当飞机突然失控的时候，需要根据驾驶舱的数个看板来判断问题所在，这个时候你一定已经高度紧张了，如果看板太多或者专业性太强，人为分析就会存在一定的门槛，而且也比较低效。但无论如何，仪表盘都是必要的，它就像手动档汽车，笨重但是可靠，是智能化手段失效后的最后保障。

（二）自动化诊断，自动挡，相对可靠，但保养成本高

自动化诊断是根因分析的第二阶段，SRE根据不同的业务场景和架构，编写一些分析的脚本或者调用一些工具，比如查日志或者查监控，总体上还是对相对固定范围的数据做一个快速的，有逻辑顺序的批量检查，再把结果反馈出来。它的好处是可以替代运维人员快速完成“分析仪表盘”这件事，把仪表体现出的异常罗列出来，从而快速进行决策，从分析问题的角度是一个加速的过程。但它的缺点也显而易见，就是开发维护成本比较高，不同的报警，不同的业务，不同的数据源，不同的数据结构，都需要通过代码的方式实现出来，整体的扩展性较差，且SRE的经验也无法沉淀下来，就像自动挡汽车，能自动，但不智能，且维护成本较高。

（三）智能诊断，自动驾驶，可靠度相对低，但迭代快，易维护

智能诊断是根因分析的3.0版本。随着大模型技术的不断成熟，Agent作为一个可推理，可执行任务的智能体，与根因分析的场景天然吻合。我们是怎么做的呢？借助大模型自身广域的IT知识（比如网络知识、数据库知识等），和2.0时代SRE们自动化过程中积累的经验，让AI自动根据当前业务情况和报警信息进行诊断分析，从工具库中选择性执行，并汇总结果。其好处是大大降低了诊断的开发成本，要知道开发这些分析工具，之前是需要做非常多数据处理的工作，因为程序只能处理结构化的数据，而大模型是可以看懂非结构化数据的，且在组织调用工具执行任务时，也能自主选择合适的参数填入，就像现在的智能驾驶汽车，其实就是在调教的过程中，让他变得更像一个“老司机”。现阶段这个方案的缺陷是大模型本身的幻觉，所以智能化当前是我们提速的手段，解决99%的问题，但是我们保留了手动档的选择，来应对可能的1%自动驾驶失效的情况。

10阶段：及时止损，快速恢复

上一个阶段讲根因分析，其实并不是真的“找到根因”，而是找到关键线索，从而依靠关键线索快速进行止损操作，比如重启，重启谁？扩容，对谁扩容？降级，对谁降级？等等……

实际上依托云原生的能力，可以相对容易的搭建起”一键恢复平台“，对于资源层的单节点扩容、水平扩节点、重启，以及基于网关的限流、拦截、接口熔断等能力。实操下来，实际的过程是5阶段找到关键线索，先快速止损，稳住之后找到原因，从而根本解决问题。

2、成本管理：看清、拴住“失控”的成本

国际调研机构 Flexera 发布的《2023 云状态报告》显示：在过去十年间，企业用云所面临的最为突出的挑战始终是安全问题，然而从 2023 年开始，成本管理已然跃升成为企业用云的最大挑战。2016至今，我所在的企业平均每年公有云占比增速为30%，近三年来平均每年增加云资产投入更是达到达600万元以上，而且随着存量客户数据的高速增长，这个比例还在不断提高。从公司视角看，成本的失控主要体现在两个方面： 1、产品成本核算苦恼：每个产品的实际成本到底如何，是个未知数，云厂商提供的账单和实际的产品成本之间仿佛隔着一层迷雾，云成本管理较之传统模式的难度成倍增加。 2、云账单费用失控：全面上云完全改变了新产品上线和老产品扩容的流程，新项目不再需要提前上报预算采购设备，而是可以在云上“一键”启动相关的资源，极大提升了产品迭代的效率，来支持公司应对行业的竞争。在带来便捷性的同时，这也导致了云账单的“失控”，在结账时就很容易被“成本刺客”所伤，让人防不胜防。 传统的成本治理是站在IT的视角进行的，这是因为云资源实际的部署架构、公司的人力组织架构、产品线还有财务视角的成本组成（更关注单个客户的平均成本）这些维度的数据之间存在鸿沟，难以关联。为了精确得到各产品中每个付费用户的实际成本，我们构造了一个统一的成本管控平台–畅云管账，这个平台集成了跨多个维度的数据，能够服务于多种业务场景，提高决策的效率和准确性。平台实现了对多朵公有云资源的全面集成，包括资源使用情况、成本分配和消费数据。通过多维数据看板和自动化分析任务，确保了对云成本和资源浪费的全面可见。

云资源和数据的标准化

通过各大公有云提供的SDK，对云资源进行标准化生命周期管理（从资源的新增到下线），对于企业内部而言，不同云的区别对于用户而言是无感的，用户通过统一的工单体系进行申用，后台通过对不同SDK的包装实现标准化的资源下发和响应操作。

从数据角度而言，不同云平台的账期，账单数据的原始结构都不同，需要对这些数据进行标准化。另外就是在上面运维场景中提到的CMDB数据，这是将账单跟云资产、业务线、组织架构等信息进行串联的桥梁。第三部分就是资产的监控指标，包括性能监控、使用率监控等。

云成本最佳实践，预防成本刺客

我们上云比较早，跟国内的公有云平台也都有过合作，在云的使用上也有了一些心得，比方说使用池化资源（类似cdh）比弹性资源更省钱、长期使用情况下后付费比按量付费省钱等等，这些最优解其实都通过配置放进了资产的生命周期管理当中，当然平台层面也有定时的检测，每当发现某云资产对象没有使用“最佳配置”，则会进行提醒，并告知按照最佳配置的话，每天能省多少钱。

另外，我们也对云资产的成本趋势进行了监控，当某个资产出现成本异常波动的时候（比如暴涨），都能够及时收到反馈，推进我们进行分析，找出原因。

两者相结合，就是我们目前预防成本刺客的最佳实践，能够有效避免意外和未知带来的巨额云成本浪费。

预防成本浪费

刚才提到我们的云成本都通过组织架构细化到了部门和负责人，那么我们就可以对这些数据进行组装，形成各种维度的看板，并通过实时通知、红黑榜的设计，能够有效避免正常使用云资源过程中产生的资源浪费，比如资源闲置、长期低负载运行等。

云成本治理，更多还是数据治理的工作，要让云账单说人话，就要把账单关联到业务上，关联到具体的人，这是一个体系化的工作，非一朝一夕可成，尤其是对于一些经历过IDC时代的企业，在云化转型的过程中肯定会有阵痛，但阵痛之后，就会是星辰大海。

写在最后

今日所分享的云原生稳定性与成本管理，只是我们实践历程的简要缩影。随着云原生领域持续演进，我们也将不断深入探索。后续找机会针对上述要点，进行详细解读，为大家勾勒出更清晰、更完整的我们云原生实践路线图，一同迈向技术进阶新高度。