推荐语
从运维工程师到创业先锋，老王用十年时间打造中国运维新标杆，用Elevo重燃技术梦想。
核心内容：
1. 从腾讯、阿里一线运维到创业的心路历程与行业洞察
2. EasyOps时代：开创"应用CMDB"新理念的突破性实践
3. 新一代运维核心系统的理念创新与行业价值重塑
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
一转眼，离开腾讯、阿里一线运维竟已十年之久！
回顾我个人的创业史，可以说一切都源自一个最原始的念头：用技术重新定义传统运维，运维软件版图中应该有中国的运维平台。
认识我的朋友都知道，我最早也是个运维工程师。
曾几何时，年少轻狂的我也有过“喝着咖啡干运维”的浪漫幻想，但剧烈摇晃的现实无数次将我的“杯子”打翻在地——独立创业之前，身处互联网大厂海量运维时代的我先后在腾讯、YY、阿里巴巴打过运维阵地战，可谓是相当惨烈。彼时的我在机房扛过服务器，做过无数次的发布、变更、值班、手搓脚本，光是我个人独立维护的服务器规模都将近万台，也经历过无数次半夜两三点被报警电话吵醒的煎熬。
往事历历在目却也不堪回首，这些经历让我深知IT运维人的尴尬处境： 明明是个做技术的人，却总是被琐碎的事情困住手脚。光绪皇帝那句“奈掣肘何”的含金量还在上升，只不过我们面临的掣肘来自于天地无形，比老佛爷更抽象、更难搞。
但一路走来，我还是想用几个关键的创造来概括我的创业过程！何尝不是“悲欣交集”。
EasyOps时代：
自动化运维探索成功史
2015年，我与几个志同道合的腾讯同事创立了优维，开始了创造EasyOps之旅。
初衷很简单：通过自动化，把重复劳动交给系统，让人去做更有价值的事。我们从应用部署切入（那时候还没有持续交付概念），却很快发现，很多客户根本不具备基础条件——系统封闭、流程复杂、数据散乱。
恰在此时，有个金融客户看了我的分享——以应用为中心的CMDB，便和我们提出要做新一代CMDB的想法。毕竟创业还是有生存压力的，于是就从CMDB开始。早前我们提出“应用CMDB”这一思路框架，希望用一套全新的理念重构运维逻辑和认知。慢慢地，EasyOps CMDB模块成了不少企业的“运维中枢”，成为很多公司的运维平台基石。
其实我们这次的选择是一个很大的偶然，甚至是不得已而为之，但却成功地让“应用CMDB”这一概念被行业所接受，和上一代CMDB（台账） 落地的鲜有成功相比，这一代中国的CMDB堪称大获全胜，作为主导者的我们，与有荣焉！“应用CMDB”也算是我对行业的一点价值贡献。
进入全平台化时代，我们再次敏锐捕捉到行业脉动，在国内率先提出“新一代运维核心系统”的理念并成功付诸实践，核心缘由也是因为客户越来越倚重这一平台。这不仅仅是一次产品升级，更是一次认知的跨越——我们深刻认识到，运维系统不应止于功能堆砌背后的复杂事务支持与辅助，而应当成为企业的核心决策系统（A类系统），真正承载业务运行的生命线，和客户的业务系统一样重要！
这一理念的推进，让我们更加清晰地看到自动化与平台化的局限。也正是基于这一认知高度，我们后来才没有盲目推进所谓的AIOps 1.0——算法驱动运维，因为我们感知到，纯粹依靠算法并不能从根本上破解运维的困境——数据孤岛、流程断裂、人的惯性，这些都不是算法能单独解决的。
客户真正需要的，从来不是一个更聪明的算法，而是一个真正懂业务、懂架构、懂他们的系统。
这一路跌跌撞撞走来，“大胆假设，小心求证”成为我们团队的“团魂”，最初那股干劲总在有意无意推着我们闯入无人之境，时常陷入“无经可引无典可据”的困境，但真正支撑着我们穿越周期的不是什么苦中作乐的伟光正叙事，往往都是拨得云开见月明的爽感——我们总能在最难搞的事情上找对方向大干一场，然后享受大功告成的喜悦。
这就是思考的重要性！
Murphy：
AI运维领域的小试牛刀
2023年，当ChatGPT火遍全球时，我的心情很复杂。一方面为AI技术的突破感到兴奋，另一方面又在思考：这东西带来的改变是什么？对运维的影响又是什么？我们看到太多团队还在用最原始的方式处理问题，优秀的工程师把时间浪费在重复劳动上（貌似自动化运维并没有带来改变，哈），甚至很多老师傅的经验都无法有效地传承下来。记得在2023年的一次公开课上，有听众问我“老王，你怎么看ChatGPT对运维的影响”，我的回答是“还不知道，当前运维还有很多初级问题没解决”，其实何尝不是内心的一种抗拒，对AI认知不足导致。回看当时，觉得自己认知是多么的狭隘！
但多年的思维习惯左右着我，也借用丰田那句经典广告词为自己寻求和解之道——车到山前必有路——先干，又或者边干边想永远强过想得太多干得太少。
最开始，我们想得很简单：接个通用大语言模型LLM，预训练（注入）一些IT相关的知识，做个智能问答系统应该不难。
于是，在2024年初，优维科技联合一个大型时尚消费客户，从0开始，打造一个完整的AI平台——AiCenter，并推出了运维赛道第一个专用AI数智人——Murphy，同时围绕Murphy构建了一整套智能体生态系统，包括智能体开发、运维助手、模型管理、AI知识库等。Murphy的诞生带给了市场和客户不少惊喜，私人订制+云端一体的产品设定给IT运维场景带来全新的想象力。
这次小试牛刀仿佛让我们触碰到了大模型的核心脉动。
还记得Murphy发布的时候我们曾写下这样一句话：在优维看来，运维场恰如修罗场，运维就是与不确定性争斗！。对于我们这样一个团队而言，在今天这样一个蓬勃的AI时代，如果依然拘泥于“用AI解决运维的问题”显然是不够进步的。
我们已经利用通用大模型解决了运维“最初一公里”的问题，就不能再用同样的方式方法来解决运维的“中途N公里”，甚至于全盘IT的“中途N公里”问题，因为到了“中途N公里”，大模型面临的就不仅仅是运维的问题，而是IT全业务流协同的问题，这是一条脉络众多的漫漫长路。
Murphy带给我一个很直观的领悟是：IT领域的知识太深太杂了。同一个问题，不同行业、不同客户、不同环境、不同IT架构下，解决方案则完全不同。通用大模型根本无法理解“磁盘IOPS异常”和“某某业务系统故障”之间的关联，更别说给出准确的诊断建议了。
所以很遗憾，Murphy并不是我心目中真正的AI——理想很丰满，现实很骨感。核心原因还是我们过高估计了通用大模型的能力，也过低估计了企业私域问题的复杂性。如何打破僵局？
我非常急于带领团队寻求AIOps 2.0的价值和技术锚点，但到底什么是AIOps 2.0？什么才是我心目中真正的智能化?其实相比于“智能化运维”我更喜欢“自主化运维”这个概念，自主化是接近于人的。
确定了AI的核心逻辑，我们就面临一个关键问题：EasyOps产品AI化还是重新构建独立的AI产品？对于“AI产品独立化”这个问题，我和团队思考了很久，最终统一下来三个关键性的思考：
① AI是一种近似人类智能，不是技术也不是工具
② 一定要有独特性，但也要不要浪费过去的所有经验
③ AI产品要独立构建，不要被过去产品架构所捆绑
我和团队说，对于AIOps 2.0而言， 「提升+进化」 的产品愿景全程不可忽视，一定要打破AI的工具化定义和局限，必须是面向人的价值体现。
AIOps 2.0：
用LLM超越传统智能运维边界
今年我花了大量时间重新思考商业逻辑方面的基本问题。
首先是我对toB软件商业模式的认知。过去我们总认为，企业软件就是满足功能需求，并且去解决客户具体问题即可，我之前写过一篇文章【投资几百亿，为何中国toB运维软件行业商业化仍陷困局？我看到的企业3因素+外在环境4因素+行业5因素。】但在AI 大模型时代，我越来越清晰地意识到，客户买的早已不是软件功能，而是一种能力，以及该能力带来的直接成果。这是一种进化！
AI不应该只是工具，而应该成为企业进化过程中的伙伴， 这更让我重新理解技术创新的意义。曾经我们认为，运维产品稳定大于一切，技术创新只是锦上添花。 但现在，AI技术的不确定性、涌现性和持续迭代/进化能力，反而成为Ai时代产品最核心的竞争力。今天的AI产品，你必须要提前用未来6个月甚至是一年的状态来做设计，否则实现的产品可能就落后了。
更重要的是，我对AI本身的认知发生了根本转变。AI不再是“技术”或“工具”，而是一种Human-like的能力。它应该像人一样理解场景、像人一样思考判断、甚至像人一样主动学习和进化。这种认知，直接决定了Elevo的设计初衷：它要体现人的价值，成为人的一个延伸，一个真正懂你、配合你、与你共同成长的数字拍档。因此， Ai时代的技术创新不再是一个可选项，而是新质生产力的主导要素——这一点，恰恰与我们团队多年积累的技术气质不谋而合。
在定义AIOps 2.0产品时，我们坚持“自上而下”的思路：不再从技术出发，而是从人在企业中人的真实活动出发——人在什么业务流中参与了什么活动。运维工程师每天在做什么？他们遇到故障时怎么思考与行动？性能优化系统时关注哪些指标？这些活生生的场景，才是AIOps 2.0生长的土壤。注意：我在打造AI产品时候，严格禁止团队谈场景，我认为它容易让我们陷入传统软件的功能化思考。
在实际推进中，我们也意识到，AI技术真正落地，远不是模型和算法那么简单。其不确定性的核心，必须依靠工程来解决——包括数据质量、语料工程、上下文工程、训练框、多Agent协同、人机协作、伦理安全等一系列复杂工程实践。AI绝不是常见技术的堆砌，而是一项严谨、系统且持续迭代的工程。而这一切，最终要靠团队来实现。
我始终相信，精英团队结硕果。AIOps 2.0之所以能一步步从构想走向现实，正是因为我们有一群既懂技术又懂业务、既尊重传统又敢于突破的小伙伴。他们不是在执行需求，而是在创造一种可能。
带着以上的种种认知，我们终于清晰地看到：未来的运维，不该被困在过去的范式里——工具系统无法适应不同组织的运维挑战。我们应该打破边界，超越传统意义上的“智能运维”，走向一个人机协同与进化的新世界。而Elevo，正是我们设定的运维新范式——Elevo不再是一个工具系统，无需体现底层工具的价值。
Elevo：
将理念注入代码的实践破壁
革命尚未成功，思想和理论基础有了，我决定集中力量再干一件不一样的事情，一个能从全维度盘活业务流的“小而轻”的产品计划开始酝酿。
但，“小而轻”的开局并不容易。
最困难的时候，团队连续个把月没有任何突破。有个核心工程师凌晨给我发消息：“老王，我们的技术路线可能有问题，有些地方卡点了”，都是创业初期一起杀过来的老伙计，我知道这句话有半开玩笑半自嘲的成分。
蜕变一定是在痛苦中产生！这么多年我都有早起的习惯，今年我更是每天早上爬山，边运动边思考，看看自己的满清遗老的“小辫子”在哪儿？接下来更是逼着自己剪掉“小辫子”。第二天还是会打气和大家说：“兄弟们，还记得我们为什么开始做这个项目吗？不是为了追AI热点，全因AI是一种全新的模式，有新的可能，它也是在考验我们团队学习和商业模式设计/落地能力，而这一验证更是对我们过去十年创业经验的优化迭代验证。”我一个搞技术出身的创始人，面对团队困境其实说不出什么豪言壮语，当时能拿得出来的“鸡汤”也只有一颗做产品的初心。
在2025年初，我做了一个看似很“笨”的决定：放下代码，全员去客户现场。一个多月时间，我们团队跑了20多家客户的机房，记录了成百上千个运维场景。这个过程很苦，但收获巨大。
我们发现，优秀的运维工程师都有一个共同特点：他们不仅在解决问题，更在持续优化系统。每次处理完故障，他们都会思考：怎么避免下次再出现类似问题？怎么让系统变得更智能？这种“进化”思维，正是Elevo想具备的智能特质。
印象最深的是在某电商公司的数据中心，他们的首席架构师告诉我们：“最好的运维是让系统自己会预判和执行，让问题被及时的识别和解决。”这句话再次加固了我的产品意志：我们的新产品不能仍然给人一种“只是一个问答工具”的体感，它必须成为一个能够持续进化、主动思考的智能伙伴，这也是Agent的本质。
在后来无数次柳暗花明的讨论中，我们逐渐清晰了产品的核心理念，产品名字也得以浮出水面，我们决定叫它：Elevo。这个名字，来源于Elevate（提升）和Evolution（进化）的组合，它意味着我们面向客户的价值承诺。
想明白这一点后，我们彻底调整了方向。Elevo的核心不再是知识库的大小，而是学习能力和场景解决能力的强弱。我们要让每一次故障处理、每一次优化调整，都成为AI系统进化的养分。
蜕变：
从我们的产品到您的智能伙伴
经过多个内部版本的迭代和客户落地验证，Elevo终于慢慢长大了。它通过强化学习开始能够理解复杂的运维场景，能够从历史事件中学习经验，甚至能够预测一些潜在的问题。
我最感动的是看到用户态度的转变。从一开始的怀疑：“这玩意儿靠谱吗？”，到后来的试探性使用：“试试看吧”，再到现在的依赖：“Elevo你怎么看？”。这个过程带来的爽感比任何技术突破都让我感到兴奋。
现在，当有人问我Elevo到底是什么时，我会这样回答：它不只是个工具，而是每个IT人身边的智能伙伴。它的价值不仅体现在能帮你多快地解决问题，更体现在它能和你一起成长，它就是你身边的智能伙伴。
Elevo不再是一个降本增效的手段，我把它定义成新质生产力，核心要强调它不仅是一个“智能助手”，更是“IT团队的生产力放大器”，并且能 直接提升IT及运维团队的产出效率与业务价值。Elevo 的定位逻辑就是：
不是 简单工具集合 → 而是 新质生产力
不是 节省时间 → 而是 创造价值
不是 减少运维成本 → 而是 业务增长引擎
关于AI带来的焦虑问题，我是这么思考的，“Elevo最让我意外的地方是，它不会让我觉得被替代，而是让我觉得自己变厉害。”这正是我们做这款产品的初心——不是用AI取代人，而是用AI增强人。
粤ICP备14082021号
免费POC，
零成本试错
