本文将接着上篇的专访，依托于阿里-柳明、新浪微博-彭冬、奇虎360-籍鑫璞、携程-徐新龙、新炬网络-宋辉、平安科技-汪洋等6位AIOps领域先行探索者的经验之谈，分别从企业和个人两个角度，详析AIOps的实现路径，帮助大家解决技术疑虑，明确发展方向。

认真读完本文，你可以了解到：

• 怎样的企业适合更早一步建设和落地AIOps？

• 建设和落地AIOps有哪些普遍存在的技术难点？如何攻破？

• 国内AIOps先行企业目前已实现哪些相关技术成效？

• 随着AIOps的实现，运维人员会面临失业吗？若会，如何化解这种矛盾？

• 从事AIOps相关工作，需要重点掌握哪些知识和技能？

我的看法是有非常夯实的DevOps基础和注重数据积累的公司会更容易进一步建设和落地AIOps。

为什么会强调基础设施的重要性？因为通过我们的实践，会很清楚地感受到决定AIOps最终效果的其实是运维数据，而不是有多牛的算法。对于AIOps而言，数据才是决定智能化运维效果的天花板，而夯实的基础DevOps工程能力的高低，则是决定你能有多快能达到这个效果的天花板。

是否要实践AIOps取决于运维基础设施的成熟程度，因为AIOps核心是智能发现和智能决策，其最终执行需要依赖数据的计算能力和运维自动化的能力。因此，有成熟的CI/CD、监控报警体系、大数据处理平台及机器学习平台等的企业会更加有优势去落地AIOps。

现在很多企业为了赶潮流，不注重基础设施建设，直接挂上AIOps的名头，其实是不可取的。尽管我们有非常广泛的开源软件可以快速实验AIOps的一些想法，但AIOps一定不能脱离Ops而独立存在，其本质是要提升运维效率。

AIOps的建设和落地离不开最基础的材料——数据。

所以在建设AIOps之前，需要先将自己的监控平台、日志平台等完善好，收集足够多的服务器指标、进程指标、日志文件等数据。当然，有了数据只是有了基础，还需要算法工程师的加入才能真正发挥数据的价值。拥有数据和算法工程师这两个前提的企业，AIOps才能更早一步地建设和落地。

适合建设和落地AIOps的企业一般都有相似的条件：运维数据达到一定规模，基于传统经验规则已经难以应对某些运维“痛点”。

所以从行业现状和发展趋势观察下来，互联网行业、金融行业、电信行业、物流行业、制造行业等会非常具有代表性。

其实并没有什么适合不适合，有兴趣有技术能力的企业都可以去尝试。当然企业会讲究一个投入回报的平衡，一般来说肯定是在规模上、复杂度上导致运维出现了比较大的人力、效率瓶颈才会真正推动落地AIOps。虽然AIOps现在被宣传得很好，但对于一个从零开始的企业，难度还是非常之大的，所以得真的遇到了这个槛才会真正有动力做起来。

AIOps带来的效益取决于数据的质量和样本的丰富性，同样的模型经由不同的数据训练和优化，产出的效果可能大不相同。

一个企业如果想建设和落地AIOps，一定是运维方面遇到了挑战和痛点，AIOps带来的效益要远远大于建设AIOps所需要的成本投入。因此，我的看法是运维规模大、系统复杂度高、运维成本居高不下的企业比较适合尽早进行AIOps的建设。

同样，这样的企业建设AIOps后，也比较容易看到成果，会更加有信心不断地完善AIOps。

其实我们在推进AIOps的时候也踩过一些坑，走过一些弯路，大家遇到的问题我们肯定都遇到过。

现在智能化运维界放眼望去，大家都大谈特谈AIOps实践，对工程上谈的东西很少，大多是在强调强大的算法，似乎有了强大的算法就能轻松实现不需人工干预的智能化运维，实现无人值守，一步实现智能化运维。但事实上，这个难度不亚于你从手工驾驶直接晋升到无人驾驶，完全是一种想走捷径的思路在推动AIOps。

所以我们认为，在实践过程中我们工程的同学需要去做也必须做好的其实有三块内容：

• 首先是沉淀强大的DevOps工程化能力，言下之意是你的服务到底有没有上调度框架，能不能更通用地解决你实际运维问题的二层调度框架，这些都会直接影响到智能化决策的执行；

• 其次我们认为必须是将生产环境的一切运维对象进行数据化、样本化、特征化，然后在此基础上去沉淀快速获取样本、积累有效样本的系统能力；

• 最后是在第二块基础上，你有没有算法迭代端对端体验的平台，换句话说就是有没有能力去建立运维数据样本之间亲缘关系、方便算法；或者说在针对不同智能化运维场景下，你是不是具备快速复用和共享的样本数据和模型训练、预测的端对端算法产品化的能力。比方说，如果一个算法优化迭代你都需要两周，那么一个新的智能运维场景想推进，你需要从数据源头、训练到效果数据反馈的数据闭环都完全重新开发一遍，来一个场景要1-2个月，那这个事情就没法玩了，因为你一年也开发不了几个AIOps场景。

我认为技术难点挺多，除了依赖于外围基础设施成熟度，比如监控平台、自动化能力、机器学习等基础平台支撑能力以外，AIOps所研究范畴内有很多需要解决的问题。

比如在研究根因分析方面，通常结合关联关系及聚类算法来做，再结合上下游的业务调用链关系，根因归纳准确率到80-90%还是可以的，但要做到99%以上甚至100%就比较困难。对核心业务不能做到100%的准确率，就很难实现无人值守由机器自动处理。

算法准确率的影响因素很多，比如可能在数据采集端就不完整或者丢失，也可能在数据清洗过程导致数据偏差，还可能是特征抽取或模型参数上的问题等等。

虽然短期内，AIOps还有很多类似要解决的问题，但它确实可以减少人工分析的工作量，辅助人力分析，同时辅助决策，降低决策门槛。

建设和落地AIOps的过程中，会碰到下面的技术难点：

拿异常检测来说明，技术难点在于：除了需要面对复杂的序列，还需要面对负样本比较少的问题，如何在无监督和有监督算法之间取舍，如何得到一个准确率和召回率都比较理想的检测算法是异常检测算法必须要解决的问题。

解决方法是可以使用多种算法的投票机制来解决单个算法误报比较高的问题。对于样本的问题，可以采用用户标注、过滤规则、自动生成样本、随机采样等方式解决。

建设和落地AIOps首先是需要找到合适的运维场景，针对自动化运维无法解决的“痛点”问题，分析评估通过机器学习解决的可行性。

结合我们自身的实践经验，技术上的挑战主要在于这么几点：

• 首先构建用于机器学习和算法检验的通用数据仓库，规模较大的企业运维数据一般都存在于不同的存储设备和运维系统中，数据类型、结构和质量也可能存在较大的差异，数据仓库的建设需要解决数据间的差异化、统一结构、相关特征提取、以及“零散”分布的存储等问题；

• 其次选择合适的算法解决特定的问题，从现有的技术看，即使是同一类问题，也很难找到通用的算法。一方面在于数据质量，另一方面就是机器看来“无语义”的数据可能有其特定业务含义。以监控时序的异常检测为例，在一种业务场景下检测到异常，换另外的业务场景可能就是正常的了。另外，对算法的具体实现和适配也有一定的技术门槛，需要同时结合特定的运维背景知识及算法开发能力；

• 最后就是对AIOps算法质量的评估与迭代优化，行业现状大部分还是靠人力反馈来形成算法闭环。以监控时序的异常检测来说，告警准确与否，基本还是靠运维专家或者业务方反馈来实现检测闭环。这个问题想要通过技术解决，还需累计到一定的反馈数据，然后通过强化学习，寻找解决方案。

总的来说，技术上的突破需要行业整体贡献力量（特别是实践AIOps较早的巨型互联网企业，有足够的人力和资源投入，积累了宝贵的实践经验）；学术界和工业界结合，各输己长；开源社区也可以逐步发展起来，一起来推动技术的发展和前进。

对于建设和落地AIOPS存在的难点，按照我们的经验主要包括两个部分，一是管理维度的，二是技术维度的。

在管理维度上，因为很多企业尤其是大型传统企业，运维的组织架构基本上是横向划分，从上往下看主要就是开发、应用运维（不少企业连这一层都没有，直接就开发兼了，当然也算DevOps的一种组织形式，不说好坏）、数据运维（管数据库）、平台运维、网络运维、机房管理，大家各管各的，甚至数据都不通，组织协同性较差，这种组织形式是比较难推动AIOps的。

做AIOps最主要的一条就是数据，甚至100%高保真的数据，因此数据的统一管理和关联协同非常重要。

在技术维度上，难点比较好理解，按我们的经验，对于算法肯定是大家最难入手的，平常都是写写代码或写写脚本搞运维，现在要去研究算法，感觉是一入佛门深似海。

对于算法我们也有一些好的建议，现在大家基本都是在使用现成的算法，我们要先了解这些算法模型的内部原理，拿异常检测算法来说就分好多种，有统计学的，有基于聚类的，这里一般可以参考相关的论文，然后看我们的数据适合哪种算法，进行多次的测试及模型参数的调整，最终选定最优的算法。

当然这个过程中还是会踩到很多坑，但这是一个比较好的突破逻辑。

正如大家可能会对AI过分寄予厚望、过分乐观一样，对AIOps的认识也存在一些误区。

截止到现在，AIOps还不能发现以前没有发生过的问题。换句话说，AIOps还是用于发现和解决过去重复发生的问题，这些问题的行为模式是重复的。

即使是这样，建设AIOps还是存在难点。原因在于不像围棋和象棋是有边界的，运维领域没有边界，甚至连结果也是不确定的，这些都对AIOps的建设带来了挑战。

这就要求我们从数据中充分了解系统的特性，对系统进行画像，消除噪音。在过程中不断验证模型的准确性，并对模型不断优化，形成数据和模型的良性循环。

我们打造了非常夯实的调度框架，在调度之上也有很好的DevOps管控层进行服务和业务的支撑，让我们在此之上推进AIOps变得相对容易，目前在容量规划、弹性伸缩、异常检测、数据搬迁、资源碎片整理上有了非常好的成效。

我们目前在广告业务上率先引入AIOps的相关技术。

计算广告学里面有大量实践是通过算法、机器学习技术来实现的，比如广告里面的CTR（点击率）预估模型，用户画像等等。

我们在做AIOps的时候具备了算法的基础能力，同时，广告直接关系着公司商业收入，我们对系统的可用性、稳定性要求都很高，这也为我们践行AIOps带来了业务的基础。我们在异常检测、动态阈值、根因分析、报警聚合、趋势预测等方面都做了相关的尝试。

微博是一个社交媒体平台，是各种“场”的聚集地，尤其是热门事件和实时新闻经常受到用户极大的关注。通常一个热门事件可能会让广告系统的流量增长50%，某些热门可能带来几倍的瞬间流量。

广告系统有一套智能的预测系统和流量控制系统来检测和应对高峰流量。当然，我们也广泛使用了基础算法来做AIOps，比如我们使用3sigma做了异常值的检测，用prophet做趋势预测等等。在广告曝光量走势预测上，我们尝试使用了深度学习技术（LSTM）并应用到报警系统。

prophet Facebook开源框架：

https://facebook.github.io/prophet/

我们公司在AIOps领域积累和深耕了一年有余，在成本和效率两个方面已经取得了不错的效果：

对于成本，我们利用预测、分类等算法，节省了3.5千万的成本；而在效率方面，我们在异常检测、根因分析、报警收敛方面都取得了很好的突破。

携程从2016年开始实践和落地AIOps，启动时间相对较早，经过两年多的技术投入与积累，在效率提升、可用性保障、成本优化等运维场景取得了较显著的成果。

罗列部分具体的实践内容，相关技术包括：

• 监控时序的智能告警，解决了传统基于固定阈值准确率、召回率低，时效性不足，需要人力维护大量告警规则的痛点；

• 应用故障根源定位，解决了面对应用告警风暴时快速定位故障根源的痛点；

• 在线和离线资源的混合部署，非业务高峰时间段将离线作业调度至在线资源，一方面提高在线资源的利用率，另一方面缓解了离线作业集群的负担；

• 智能弹性扩缩容，通过对基础监控数据的分析，定期产生容量报告，借助自动化平台动态的优化容量；

• 应用画像，应用运维的权威数据，包括应用的资源类型画像、业务属性画像、健康指标画像、重要程度画像等维度；

• NOC智能问答机器助手，通过构建问答知识库、NLP技术，自动应答和处理用户提出的问题，有效提升了效率。

平安科技有发展AIOps得天独厚的条件：

• 对内，平安科技是集团的高科技内核，面向全集团的各个业务子公司提供集中化的IT服务。集团子公司业务涵盖各个领域，从运维角度来看，我们积累了大量的运维数据，样本丰富，可以充分对运维数据进行挖掘；

• 对外，平安科技提供公有云服务，经过几年的发展也积累了很多客户，涵盖各个行业。同样符合我之前提到的建设和落地AIOps的条件，从而可以让中小企业也享受到AIOps的好处。

在年初，平安科技作为《企业级AIOps实施建议》白皮书的编写者之一，制定了相关标准和规范，以协助企业加快AIOps的落地实施。从我负责的数据库和存储领域来看，我们当前主要在四个方面发力AIOps的使用，包括基于时间序列的异常检测、故障或者问题的根因分析、监控告警的收敛以及容量趋势的精准预测等。

DevOps和AIOps的最终目标不是说把“运维人员”做没了，而是要把“运维”这件事情给做没了。

所以大家清楚了，我们说的不是要把“人”给消灭了，而是要把运维中苦逼的事情给做没了，换句话说就是消除掉重复的人肉操作和没成就感、背着重大责任还碎片化的事情。

当然，言下之意也表达了作为运维人员，你必须完成自己技能的升级，才可能不会被趋势所淘汰。如果一个运维人员工作技能90%还是停留在做线上救火、人肉扩缩容、人肉诊断等事情，那我觉得会很危险。

在这股趋势下，大家需要做的是自我进化，未来的运维角色关注点应该在如何做系统稳定性架构、如何做系统的容量规划、如何低成本对基础设施进行布局方面。

到那时，运维应该是DevOps平台化的建设者，运维标准和准入机制的建立者。而这些工作内容和传统的运维工作内容完全不同，甚至可以认为是另外一个工种。

我认为3-5年内都不用太过担忧。

因为就现状来讲，AIOps还处于初级阶段，远不能完全替代运维人员的工作，更多的还是暂时被用于辅助决策。就像AlphaGo打赢人类时可能会让人担心未来机器人会取代人类一样，AIOps也可能会让传统运维人员产生担忧，但是我们应该更加积极拥抱这种变化，不断学习各种新的技术以适应互联网的发展变革。

目前，AIOps只是在某些单点取得了突破，远没有达到取代人的地步，在很多场景中，还是需要运维人员去处理和解决。可以这么说，AIOps是运维领域的一个补充和促进，运维人员和AIOps都各有长处和短处，需要一起努力，才能完成运维工作。

历史上有过多次工业革命，每一次工业革命爆发之后，人们都会有类似的焦虑，担心自己现有的工作会不会被新技术所替代。

从长远看，每次技术革新后会有新的机会和岗位被创造出来，历史一次次证明这种过分焦虑是没有必要的。生产力在新技术下得到解放，运维人员可以腾出更多的时间和精力去思考更加有挑战性的技术，AIOps不会也不可能成为运维的终点。

面对新的技术，需要我们用更加开放的态度去迎接和拥抱，要时刻保持“活到老，学到老”的态度。既然投身于技术行业之中，快速学习的能力就成了我们安身立命的必备技能，如果不能做到这点，即使没有出现AIOps，丢掉工作在不久的将来也可能会成为事实。

运维当然不会失业，这个问题其实跟人工智能会不会取代人类一样，但技术的发展没有边界，未来我们无法想象。

短期内来看，AIOps对运维的人员架构会促成优化：

• 一方面，运维会越来越依靠平台，围绕平台能力提升的大量新型运维开发岗位会兴起；

• 另一方面，AIOps取代了低端重复的工作，让人员释放出来做更高级别的事情，让运维变得更加准确和高效，释放出运维专家的时间，让他们全身心投入到核心问题处理和架构层面工作上去。

我不认为AIOps会导致运维人员的失业或者运维工种的消失。

正如大家担心AI会取代大部分现有工作，但事实上是，每一次技术革命都会创造大量新的工种和工作。AIOps也不例外，也许我们需要重新定义运维工作的内容和职责，但它不会消失。

由于AIOps的应用，运维人员得以从繁复的劳动密集型工作中解放出来，能够从事知识密集型的工作。但这并不意味着我们不需要做好准备迎接AIOps时代的到来，相反，我们应该做好各方面知识的储备，才能驾驭好AIOps。

AIOps是一个跨知识领域的前沿方向，所以对人的要求将会非常高，要把这个事情做好，一定是需要既懂算法又懂工程的跨领域的人才。

所以从事这个领域的同学应该熟悉并了解：

• 对现有主流的分类&预测的AI技术充分了解和掌握（LR、决策树、贝叶斯、DNN）；

• 能够熟悉较成熟的开源AI技术（tensorflow）；

• 非常熟悉主流的运维领域的技术（比如监控、容器技术Docker、调度技术K8S等）；

• 对机器&业务大规模挑战下运维领域的场景非常熟悉，知道你的问题和瓶颈在哪里，要怎么做。

从事AIOps相关的工作有两种角色的工程师：

• 一类是大数据工程师，他需要掌握比较底层的技术，需要对操作系统、内核、分布式系统等方面有一些了解；

• 另一类是算法工程师，他需要对时间序列处理、分类、聚类、回归等基础的机器学习算法有一些了解之外，还需要有一些深度学习方面的经验。