AI 驱动云上运维革命：腾讯云如何用“云顾问”重塑 SRE

发布日期： 2025-06-18 阅读量： 作者： 小编

　　开云网站在 InfoQ 举办的 AICon 全球人工智能开发与应用大会上腾讯云安灯、腾讯云顾问产品总经理许小川做了专题演讲“腾讯云顾问：从人到数智平台，用 AI 重塑 SRE”，演讲围绕腾讯云 SRE 组织变革展开。在主动服务体系遇瓶颈时，腾讯云依托 AI 和云计算推出「腾讯云顾问」可视化云上架构治理平台，涵盖架构梳理、卓越架构评估、一站式架构治理等功能。还分享了技术、组织等多方面经验，用 AI 重塑 SRE，助力 SRE 工作的数智化升级。

　　收获前沿行业认知，明晰云 SRE 组织发展趋势与 AI 重塑 SRE 的方向

　　更可借鉴多维经验，涵盖技术、组织、管理、协作、技能等方面，提升个人与团队竞争力

　　首先，我介绍一下 IT 服务领域的基本背景。所谓 IT 服务，简单来说就是为客户提供专业的 IT 服务的团队，它实际上是技术和业务之间的一座桥梁。在云计算领域，我们通常将其分为用户生命周期的三个阶段：上云前、上云中和上云后。在每个阶段，我们分别提供售前咨询、售中实施、售后服务等 IT 服务工作。

　　在 IT 服务领域，有许多成熟的方法论。其中，ITIL 是目前在 ToB 领域应用最为广泛的一套方法论。此外，还有 DevOps、精益、敏捷等方法论，这些方法论在实践中被广泛应用。实际上，现代企业中很少有组织不依赖 IT，也很少有组织是独立存在的。

　　以腾讯云为例，我们的上游是风、水、电、软硬件的服务提供商，它们向腾讯云提供 IT 服务；而腾讯云则向数百万企业客户和开发者提供 IT 服务。即便在企业内部，如果存在 IT 团队和业务团队的分工，那么 IT 团队也需要向业务团队提供 IT 服务。

　　只是服务的规模、类型和复杂度不同，一些企业可能没有系统地引入方法论或建立体系。对于我们而言，由于规模庞大、服务量大且内部组织复杂，我们必须进行系统化、标准化的建设与治理。

　　在海外，与我们规模相当的 ToB 企业通常会采用外采解决方案或 SaaS 服务。国外有许多比较成熟的 IT 服务管理 SaaS 平台，如 ServiceNow 和 JIRA 等。在国内的生态中，我们更多地依赖于自建平台。

　　我们也采用了这种模式，建立了两套平台。第一套是腾讯云安灯，主要用于解决被动式的响应性 IT 服务。该平台已经运行了大约五年时间。第二套是腾讯云顾问平台，则专注于主动服务，旨在规避问题，我们将其称为“消防性”平台，通过主动解决隐患来提供服务。

　　尽管如此，我们仍然面临着诸多挑战。首先，尽管腾讯安灯平台已经运行了五年，并且实现了流程化、数字化、智能化，我们仍然面临着来自客户和内部管理的朴素诉求，比如希望服务能够更快、更好、更省。

　　但 IT 服务直到目前仍然是人力密集型和知识密集型的领域，需要大量的人力专家参与。无论是响应速度、解决质量还是成本控制，都难以线性的持续改进，这和客户预期是有 GAP 的。

　　在大模型出现之前，我们一直在使用深度学习、神经网络。但由于服务体系中存在大量非结构化数据，大模型的出现为我们带来了新的希望。

　　其次，除了被动式服务外，我们还有大量的主动式服务需求。例如，帮助客户梳理架构、进行稳定性治理，或者在即将到来的 618 大促期间，协助客户进行架构治理、重保和护航。

　　这些工作大多需要我们派遣专家到现场或通过远程会议完成，属于人力劳动密集型工作。此外，与被动式服务不同，主动式服务缺乏一套完整的、成熟的平台作为参考。

　　虽然我们可以借鉴一些质量管理、项目管理的方法论，但目前尚未形成体系化的工具平台来支撑其数字化升级。

　　我们一直在思考如何利用 AI 重塑我们的服务体系。这一体系已经建立五年，经历了三个发展阶段。最初，我们没有这样的平台，大家通过拉群来解决问题。这种方式虽然简单，但随着人数不断增加，事情却越来越难以落实。在云服务体系中，这种问题同样存在。

　　因此，我们在 2019 年迅速构建了一套平台，将所有流程从群聊转移到标准化的线上流程中，实现了流程的标准化和线年，我们进一步将所有流程全面 AI 化，逐步用 AI 替代人工，以提高效率。

　　未来，我们看到了清晰的发展路径，即不断提升 AI 的提效比例，最终实现类似汽车自动驾驶的全自动化，从 L2 逐步迭代到 L3、L4 级别。

　　在这个过程中，我们总结了许多经验。首先，我们发现 IT 团队在组织内部的角色已经发生了变化。过去，IT 团队更多是支撑型的，但现在我们已经成为一个驱动型团队。

　　这是因为 IT 已经成为企业的核心生产力，而这种核心生产力掌握在 IT 团队手中。如何通过 IT 驱动组织变革？有时需要 IT 人员主动站出来，像 CEO 一样思考问题。组织变革的方法论有很多，经典的理论从文化、人才、组织流程等多个维度进行体系化推进。

　　对于我们这样拥有数千名员工和数百万客户的庞大组织来说，每一套方法论都有适用的场景。我想分享一些个人体会，尤其是我认为最重要的三点。

　　聚焦干系人价值。我们不能为了变革而变革。变革的目的是什么？谁会从变革中受益？谁又会受到损失？这些问题必须首先弄清楚。同时，要找到变革真正解决的痛点是什么。

　　找到变革的主线。变革不能一蹴而就，不能一开始就全面推翻重来，否则组织可能在变革的上半场就宣告夭折。我们强调要找到变革中始终贯穿的那条主线，然后沿着这条线循序渐进的推进。

　　将干系人和主线用价值链串联起来，形成一个循环，我们称之为“变革飞轮”。这个飞轮首先从业务切入，通过将业务流程 IT 化获取数据，然后对数据进行治理，用数据驱动业务改进，从而形成一个循环。

　　如果深入展开，这里面的内容其实非常丰富，短短几句话就涉及了精益生产、系统论、控制论等方法。但我更想回到我们自己的实践，希望能给大家一些启发。

　　在被动支持领域，我们首先找到干系人，包括客户服务的一线、二线、三线及其管理者，明确他们的痛点是什么。客户希望得到快速、优质的服务，而我们内部则需要降低成本、提高效率，减少客户投诉。

　　从客户提出问题到问题解决，始终围绕客户的问题展开。在业界，通常会用工单（work order）这种电子流程来串联整个过程。我们也采用了工单的方式，但不同的是，我们将人工流程通过变革飞轮串联起来，找到第一个突破口，利用 ITIL 方法中的事件管理流程，从客户提出问题到最终的解决，实现整个过程的线上化。

　　这个过程看似简单，但其实包含了咨询、故障处理、原因分析、变更解决等多个层次。我们不是简单地照搬 ITIL 的 30 多个最佳实践和流程，而是根据业务需求逐步迭代。

　　在 AI 方面，我们过去三年的做法也是类似的。AI 的干系人和痛点与之前是一样的，但轴线变成了 ITSM。我们在 ITSM 中找到可以 AI 化的点，插入相应的 AI 代理。

　　最初，我们发现服务一线最担心客户投诉，因为一旦被投诉，内部就会启动复盘流程，可能还会影响绩效考核。于是，我们首先帮助一线人员进行客户情绪分析，一旦客户催单、不满，就加快升级到更专业的二线处理。经过这一轮改进，大家发现 AI 并不是来取代他们的，而是来帮助他们的。于是，一些一线人员从观望甚至抵触，逐渐转变为接纳、拥抱 AI。

　　一旦接纳，后续的改进就越来越顺利。我们逐步将 AI 应用于智能客服、事务流程优化以及共性问题分析等方面，全部用 AI 替代。

　　从客户提出问题到最终解决的整个流程，是一个最具挑战性的流程，尤其是当问题升级到三线时。

　　在智能客服的辅助下，目前 70% 以上的问题已经能够由客户自行解决。如果客户无法解决，转人工后，AI 能力已经能够替代一线% 的效率。三线处理的问题相对复杂，目前 AI 的替代比例在 5% 到 10% 之间。虽然已经取得了一定进展，但 AI 化的空间仍然非常广阔。

　　主动服务对我们来说无疑是一个极具挑战性的领域，它需要我们创造性地去解决问题。

　　然而，我们的方法论始终如一：首先，找到干系人和痛点；其次，明确变革的主线；最后，形成一个价值闭环。对于主动服务而言，无论是上云前、上云中还是上云后，我们发现一个贯穿始终的现象——技术人员总是需要绘制架构图。过去，这些架构图要么在白板上画，要么在白纸上画，要么写进项目文档里，它们是分散的、零碎的，往往也是一次性的，缺乏重复利用的价值。

　　于是，我们思考，是否可以像曾经将群聊中散落的消息整合成工单那样，找到一种新的方式，将这些架构图信息化，从而实现更高效的管理？这便是我们思考这一问题的原始突破口。

　　在业界，数字化改造架构图的方式还相对初级，无非是将线下白板变成电子白板，但这种方式并未从根本上解决问题，依然是人工的、临时性的，与 IT 系统的工作负载缺乏真实的对应关系。

　　然而，作为云服务提供商，我们拥有得天独厚的优势：业务系统运行在云端，强大的工程师团队和丰富的经验积累，同时还有 AI 技术的加持，以及产品化思维。基于这些优势，我们经过一年多的建设，开发出了腾讯云顾问平台。

　　目前，该平台的核心价值定位是可视化一站式架构治理平台，它是一个云原生的 SaaS 平台，可供内部和外部客户自行使用。

　　平台分为四大板块：首先是云端软件架构图；其次是卓越架构指标（我们有一套名为“卓越架构”的方法论体系，就像人们每年需要体检一样，通过这套体系对架构进行全面评估）；第三是一站式 SRE Agents 工具；第四是云原生的 IaaS、PaaS、MaaS 底座。

　　这套系统的核心目标并非仅仅是 IT 手段的应用，而是通过 IT 手段实现业务目标。我们希望将过去全人工提供的主动服务模式，转变为未来由平台主导的模式，让人员更多地负责目标设定、指挥、监督和赋能。目前，我们正处于这一转变的中间阶段。

　　我们对腾讯的产品化能力充满信心。尽管 IT 服务管理或 IT 运维领域给人的印象可能较为传统，但我们依然努力将 B 端复杂逻辑和 C 端用户体验完美融合。

　　目前，该系统的主要界面左侧是一个架构图，有 2D 和 3D 展示，视觉效果较为炫酷。第二个重要部分是卓越架构指数，它会从不同维度评估云上软件系统的健康状况。第三个部分是治理 Agents，而第四个价值在于它正在改变组织内部和跨组织之间的沟通模式，它是一个在线互动白板，帮助我们将复杂的想法转化为一线人员易于理解和操作的形式。

　　首先是架构图。如果架构图不够智能，使用者仍需手动绘制云上系统的架构图，这不仅需要专业知识，还需要大量时间，违背了我们减少人力投入的初衷。

　　因此，我们投入了一年时间，基于云上业务系统的调用关系链、网络拓扑结构以及风险巡检等得到的资源清单，实现了自动绘图功能，同时也支持用户手动修改和补充。目前，这一功能在业界属于比较创新的产品和体验。

　　其次是卓越架构理念。我们认为云上架构就像一栋房子，需要分层和支柱。我们提出了三层×六支柱的架构模型，并且正在与相关行业组织合作，即将发布相应的标准，用于评估客户在云上使用云服务的合理性。

　　该标准从性能、成本、可靠性、安全性等多个维度进行评估，例如，如果某个架构的健康度为 70 分，那么安全、成本、可靠性可能是其短板，接下来就需要进行治理。传统运维人员需要每天制作报表、分析日志，而我们的平台通过自然语言处理，让这一过程变得简单高效。

　　此外，根因分析功能可以从现象直接追溯到根因，这得益于我们整体的产品设计理念——按图索骥。因为平台旁边有一张架构图，所有分析都基于图的上下游关系进行，有目的地定位问题，而不是像传统运维那样在海量日志中大海捞针。

　　以混沌演练为例，虽然混沌工程的理念很好，但在实际应用中却面临两个困难。首先，混沌工程需要专家设计演练方案，有技术门槛；其次，如果演练导致系统故障并造成真实损失，责任难以界定，有心理门槛。

　　因此，混沌工程虽然备受好评，但实际应用不广。为此，我们利用大模型设计了一套安全护栏逻辑，通过 AI 控制演练参数，确保注入的破坏恰到好处、点到为止，从而降低了用户的技术门槛和心理门槛。目前，已有数百家客户在使用这一功能。

　　同时，我们希望改变传统的沟通模式。过去，客户与云厂商沟通时，虽然每个通道都保证得很好，但沟通渠道分散，难以将信息串联起来。未来，我们将基于云顾问体系，在统一的平台、统一的话术和统一的语言下进行沟通，从而提高沟通效率和效果。

　　在实际工作中，两个案例充分证明了我们协作机制的有效性。以“618”护航为例，许多重要客户会邀请我们的专家协助他们进行护航工作。过去，护航前的准备工作全靠人工完成，往往需要一周时间。

　　然而，自从有了我们这套完善的体系，仅需一天时间，甚至当天就能交付护航方案。在护航过程中，由于采用了在线可视化的操作界面，各方协作变得井然有序，不再像以往那样在群里混乱地沟通。护航结束后，总结工作也变得顺理成章，因为 AI 大模型在这方面有着独特优势，数据都已整合好，项目总结可以迅速生成。

　　另一个案例发生在去年年初。当时，一位客户遇到了一个问题，他们自己的团队，从前端到网络，再到存储和逻辑的工程师，花了整整一个多小时都没能定位问题。

　　后来，他们也向我们的一线工程师求助。在一线工程师的建议下，客户开通了云顾问，很快便发现问题所在。原来，他们一直专注于前端和后端的排查，却忽略了整个链路中间有一个环节——弹性 IP。由于业务增长，弹性 IP 的容量不足，导致概率性丢包。客户将容量调大后，问题便迎刃而解。

　　在当今时代，我们身处一个充满变数的环境，技术的飞速发展带来了前所未有的机遇与挑战。我想借此机会与大家分享一些我们的经验和思考，希望能够引发更多交流与启发。

　　正如前面几位提到的，世界似乎被分成了两部分：一边是硅基生物（人工智能）大步向前，另一边是碳基生物（人类）焦虑难眠。它们的发展节奏并不一致，而面对这样的现实，我们作为当下的组织，应该如何思考和应对呢？

　　经验 1，在技术层面，我们坚决拥抱人工智能（AI）。尽管并非所有人都能立刻接受 AI，但在大规模的组织中，这种差异是不可避免的。从 CEO 的急切期望到基层团队的不同反应，我们看到有人热情拥抱，有人表示疑虑，有人选择观望，人们的态度并不一致。

　　但我们坚信，我们需要塑造一种拥抱 AI 的文化和信念。AI 并非要取代人类，而是帮助人们提升效率。正如前面提到的两个案例，我们正是沿着这一思路不断推进的。

　　经验 2，在组织架构上，我们需要变得更加敏捷。敏捷思想其实已经推广了 20 多年，腾讯从一开始就倡导敏捷开发，但在过去三年 AI 浪潮的冲击下，我们意识到自己还得更加敏捷。

　　以软件开发为例，过去我们采用的是基于“feature”的迭代，即产品团队和业务团队提出需求，然后经过策划、开发、测试、发布、验收和使用等一系列流程。然而，现在我们已经进入到了基于“Case”的迭代。使用方直接向聊天机器人提问，如果回答不够理想，问题就会直接反馈给算法工程师，工程师迅速调整后，使用方再次验收，看是否有所改善。

　　整个流程大大缩短，这也导致了内部研发团队角色的微妙变化。产品经理和开发工程师的界限逐渐模糊，开发工程师需要具备更多元的技能，不仅要懂技术，还要懂产品和业务。未来的产品经理可能直接由开发工程师担任，开发和测试的角色也在不断融合。

　　过去的测试主要是功能测试，结果非黑即白，但现在测试变得更加复杂，需要评估结果的好坏程度，功能的边界也难以穷举。AI 的泛化能力使得我们无法穷尽其边界条件，这对测试人员来说无疑是一个巨大的挑战。

　　经验 3，对于管理者而言，我们建议采用可视化管理。如果大家对精益生产有所了解，就会知道看板管理是精益生产中一种重要的拉动管理理念。

　　在当前这种复杂、混沌且脆弱的环境下，可视化管理是一种简单而有效的管理方式。它可以帮助我们更好地了解团队的工作进展和成果。我们将数据可视化管理分为五个层次，从 L0 的原始数据到 L4 的数据去掉业务，我们基本进入了交互式可视化和局部的数据驱动业务阶段。

　　例如，在技术研讨会上，用腾讯云顾问的开会时长会减少一半；同时，因为所有事情都是可视化的， 70% 的问题都能提前发现和规避；还有一个隐含的收益：一线员工的工作被上级领导看到，本身就是一种激励和成就感的来源，能推动整个组织更加良性地发展。

　　经验 4，在协作方面，我们建议采用以业务为中心的需求拉动模式。如果大家对供应链管理有所了解，就会知道推动式（push）和拉动式（pull）两种模式。我们在腾讯云顾问的产品化过程中也参考了这两种模式。

　　传统的运维体系通常是技术主导的，由开发运维团队发起，要求所有系统上报日志，然后制定指标、配置监控告警，等待问题发生时通知。在这个过程中，业务团队往往不参与，即使将监控告警的内容推送给业务团队，他们也难以理解。而我们的模式正好相反，我们从业务出发。

　　例如，业务团队告诉我们“618”即将到来，预计用户量将增加 5 倍，运维团队就会根据这一需求进行扩容评估，并在平台上完成评估和扩容。在某些情况下，基于现有资源和过往经验，我们可能会发现实际上扩容 3 倍就能满足需求。这种模式大大缩短了交付时间（lead time），从过去可能需要几周甚至几个月，到现在基本可以实现当天交付。

　　经验 5，在个人技能方面，数字化升级是工业 4.0 的核心，每个人都需要具备数字敏感度。过去，我们对数据的处理仅停留在统计层面，认为只要能进行数据分析就足够了。

　　但如今，我们需要将数据提升到更高的层次。这里我引用了一个模型叫 DIKW。数据 Data 本身并没有意义，我们需要建立数据之间的关联，找到趋势，将其转化为信息 Info；再将信息与业务场景结合，转化为知识 Knowledge；最终用知识指导业务，形成洞察 Wisdom 并付诸行动。这才是数据驱动的高层次体现。

　　当然，这一切也与我们一直强调的变革飞轮密切相关。我们需要不断推动这个飞轮，从我们主动驱动，到组织能够自我驱动，最终实现变革的逐步深化。

　　许小川，腾讯云安灯和腾讯云顾问产品总经理。曾先后负责过近 10 年的 C 端社交平台软件的研发管理、 B 端云计算解决方案咨询，当前负责腾讯云安灯 ITSM 平台和腾讯云顾问可视化云上治理平台的产品及研发管理工作，关注 Gen AI 在企业应用中的落地。

　　6 月 27～28 日的 AICon 北京站将继续聚焦 AI 技术的前沿突破与产业落地，围绕 AI Agent 构建、多模态应用、大模型推理性能优化、数据智能实践、AI 产品创新等热门议题，深入探讨技术与应用融合的最新趋势。欢迎持续关注，和我们一起探索 AI 应用的无限可能！

上一篇: 探索B端SaaS系统首页升级

下一篇: 微盟集团早盘涨超6% 微信宣布公众号可带货微信小店公司有望

Kaiyun(中国大陆) - 官方认证的数字化服务平台

AI 驱动云上运维革命：腾讯云如何用“云顾问”重塑 SRE

随便看看