——没有算法专家，AIOps 也能玩得这么 High
在这样一个 IT 技术高速发展的时代，速度往往能决定一切!
开源项目，让我们避免重复造轮子，节省大量的人力和时间，并大大加快业务的发展速度。
热爱开源的你，想了解一线大厂最新的开源项目吗？
· 无算法专家也能优雅地做 AIOps ?首次开源的腾讯 Metis 会有多闪亮
· 作为 Go语言开发框架性能王者，腾讯 TARS-GO 有何与众不同?
· 从软件定义存储到微服务，华为开源历程及项目大揭秘
· 腾讯、阿里、和小米，开源历程以及最新开源项目有哪些?
· 如何选择一个企业级 Kubernetes 平台?对于国内容器开源生态，专家怎么看?
这里有一个机会
你可以面对面聆听名企开源背后的故事 ，并参与互动式的Workshop。
为本土开源企业与开源软件提供分享与交流平台、促进国产开源软件繁荣与发展的【OSCAR 开源先锋日】就要来啦!
原文：搜狐
网址：http://www.sohu.com/a/256214142_100281827
——裴丹：智能运维算法需要工业界
学术界密切合作实现技术突破
■商灏
清华的计算机系，国内一流，而其智能运维研究，据业内人士透露，近两年已超越美国同行，为世界最顶尖水平。本篇可能是国内财经媒体首次触及此类最前端科技应用的报道。
清华大学计算机系副教授裴丹博士，曾在美国AT&T研究院学习和工作，AT&T研究院前身是贝尔实验室的一部分，大概有200个博士，有C++发明者、防火墙之父，裴教授在此发表了23项运维相关的专利。之后他回到清华继续从事运维科研。
裴教授所在的清华大学NetMan实验室，做的科研基本上都是跟运维相关。他认为，工业界、学术界应该在运维领域里面能够密切合作，各取所需。工业界有很多实际问题，有很多经验，也有实际的数据，学术界有时间，有算法，有学生，大家一起结合，这样就会产生很好的效果。
作为一位运维专家，裴教授曾在美国一个30万人的大公司里面主要通过大数据分析的方法做运维，是基于大数据技术管理网络和应用的性能，各种网络协议、IPTV、Video等等；回到清华做科研后，开设的也是网络性能管理/应用性能管理相关的课程，所有的科研都是跟运维相关的，在国内工业界的合作伙伴包括百度、阿里、腾讯、滴滴、搜狗、微众银行、华为等。
智能运维现在已呈现一个很清晰的趋势：从基于规则的智能运维自动化逐渐转为基于机器学习。那么，智能运维在中国落地和发展所必须面对的挑战是什么？思路是什么？要解决哪些关键问题？
智能运维
今后几年将有长足发展
裴丹说，智能运维是指在互联网中的大型分布式系统不断处理海量用户体验、性能、稳定性、安全事件，从而达到如下效果：能够准确地复现并诊断过去发生的事件；能够及时准确地检测、诊断当前正在发生的事件，并确定最适合的应对方案；能够相对准确地规划和预测将来可能发生的事件。
由此可以看出，智能运维是人工智能（机器学习）、互联网运维领域知识、工程开发的交叉领域，三者缺一不可。
裴丹介绍：智能运维常用到的机器学习技术包括相关性分析、回归、关联分析、聚类、决策树、随机森林、支持向量机、隐氏马尔科夫、卷积神经网络、LSTM（Long Short Term Memory） 等等。这些算法在各种（开源或闭源的）工具集中都有现成的代码实现。智能运维的一个主要挑战是根据具体需求评判应用哪些机器学习算法，并适配或改造。
基于如上机器学习技术的具体智能运维技术包括：
1.面向历史事件的： 批量根因分析、瓶颈分析、热点分析等；2.面向实时事件的： KPI异常检测、日志异常监测、事件关联关系挖掘、报警聚合、快速止损、故障根因分析、止损建议分析；3.面向未来的：配置管理、容量预测、趋势预测、故障预测、热点预测等。
智能运维呈现怎样的发展趋势？其与APM（应用性能监控），操作系统性能监控，数据库监控，网络监控等技术是怎样的关系？裴丹称，智能运维正在经历由“基于人为指定规则”到“基于机器学习”的转变，我们将来会看到越来越多的科研成果和实际系统采用机器学习算法做为基础工具。目前机器学习在一个领域取得广泛成功有几个要素：可用的开源机器学习系统、实际应用场景、大量数据、大量标注，而智能运维恰好具备这几类要素。所以，他觉得基于机器学习的智能运维在今后几年会取得长足的进展。他强调，这些基于机器学习的智能运维技术是APM（应用性能监控），操作系统性能监控，数据库监控，网络监控等技术的底层基础技术，因此智能运维的发展会大大促使上述领域的发展。
自2016年以来运维行业蓬勃发展，新技术大规模推广，如容器与微服务，配置管理工具，DevOps，SRE这样的概念和思想的落地，还有很多运维方向的公司都拿到了大手笔的融资，怎样看当前运维行业的发展？
裴丹说：首先，上述新概念和思想的落地是运维行业的大好事儿，这标志着运维行业已经逐渐脱离了人工和经验（dark arts），而转向一个真正基于技术的行业。容器和微服务的不断落地，会使得一些过去可行的技术（比如基于人工置顶规则的根因分析）遇到瓶颈，需要新的智能运维技术来适应容器和微服务等底层技术的更新。同时，不少运维方向的公司都拿到大额融资，把大公司的运维系统及技术提供给中小企业使用，这也是一件大好事。更多的企业在应用运维技术的生产实践中，会不断产生新的挑战，相应地会有新的技术和解决方案提出来，会对整个智能运维行业的发展产生强烈的促进作用。
他认为，用发展的眼光看，未来SRE这一职位除了目前强调的互联网运维领域知识、工程开发的结合以外，也会逐渐强调机器学习技术的应用。
裴丹还向笔者介绍了智能运维中，运维工作人员与机器的分工。他说，机器将成为运维人员的高效可靠助手，逐渐替代人力完成基础性和重复性的基层运维工作。对于较为复杂的运维问题，通过不断向运维专家学习，从而向运维人员自动提供决策建议。
他认为，将来的智能运维人员可能主要有三种：经验丰富的运维专家；熟悉运维场景的机器学习专家；智能运维系统开发者。
裴丹曾在美国做过很长时间的运维工作，对于中美运维行业发展的差别，他的看法是，总体来说，美国运维行业在运维理念和智能运维技术的创新比国内要多一些。
首先，美国的运维行业工作历史悠久，AT&T电信网络的运维在几十年前就开始了，并且依赖AT&T的科学家们，发明了很多智能运维算法，发表在计算机网络领域的顶级会议（如ACM SIGCOMM）和期刊（如IEEE/ACM Transactions on Networking）中，并引发了学术界的深度参与，这些算法的核心思想有不少在现代互联网中仍然适用。
互联网兴起后，大型互联网公司在生产实践中不断深挖运维问题的根源，提出或深入实践了微服务、容器、DevOps 等先进理念。国内运维业总体上来说还处于应用已有先进技术的阶段，但是在一些局部的技术点上（比如普适异常检测技术）也走在了世界的前列。
工业界和学术界应密切合作实现技术突破
展望未来几年的运维领域的技术发展，裴丹认为：在国际范围内，越来越多的先进机器学习技术会被应用到运维领域。一些智能运维的关键技术，会逐渐通过工业界和学术界的密切合作被突破，比如异常检测、异常定位、异常事件关联等。更多的预测型的智能运维技术会被提出并实际应用，比如故障预测、热点预测、容量预测等。
对国内的运维人员的发展，裴丹提出了几点建议：除了提升代码开发能力，希望国内运维人员有意识地提升应用机器学习技术的能力，并不断实践。国际上“基于机器学习的智能运维”的实践也只是刚刚兴起，因此，就像中国的人工智能被认为有可能实现对美国人工智能的弯道超车一样，裴丹说他相信国内的运维行业只要足够重视并不断尝试实践，完全有可能在“基于机器学习的智能运维领域”实现对美国运维业的弯道超车。
关于智能运维技术如何落地的问题，裴丹说，在目前这个阶段，智能运维科研想要继续往前推进并取得更好的成果，需要把智能运维里的一些关键算法定义好、分解好。这是智能运维落地的一个关键步骤和手段。
他表示，现在智能运维很热门、很火爆，大家都感兴趣。但智能运维落地的核心挑战是：从工业界的角度，我们有数据、有应用，但是缺乏一些算法和经验；从学术界的角度，我们有不少理论算法，但是缺乏实际的数据以支持科学研究，也不熟悉运维的场景。“尽管我们已经在工业界和学术界的合作方面有了很多实践，但我切身感受到，相对来说，这种一对一的交流效率比较低，且见效慢，特别不符合当前的开源开放的趋势。”
因此，裴丹提出的解决思路是，以科研问题为导向，将我们在智能运维领域需要解决的一系列挑战性的问题，定义成切实可行的科研问题。这样，就有明确的输入和输出。在这种情况下，如果我们的企业能够拥抱开源开放的趋势，把数据开源出来，就能让学术界更多的研究人员参与到研究智能运维有关的算法中来。
从智能运维发展历程看，最早出现的是手工运维；在大量的自动化脚本产生后，就有了自动化的运维；后来又出现了DevOps和智能运维。在运维的过程中，涉及到的步骤可以概括为：产生海量的监测日志，进行分析决策，并通过自动化的脚本进行控制。运维的发展过程，主要是分析决策步骤发生了变化：起初，由人工决策分析；后来，在采集数据的基础上，使用自动化的脚本进行决策分析；最后，用机器学习方法做决策分析。
根据Gartner Report（加特纳报告），智能运维相关的技术产业处于上升期。2016年，AIOps（基于算法的IT运维）的部署率低于5%，Gartner预计2019年AIOps的全球部署率可以达到25%。所以，AIOps的前景一片光明。
如果AIOps普遍部署之后会是什么样的？
裴丹分析说，从机器的角度来看，基础性、重复性的运维工作现在都交给计算机来做了；同时，机器通过机器学习算法为复杂的问题提供决策的建议，然后向运维专家学习解决复杂问题的思路。从运维专家的角度看，运维专家主要处理运维过程中的难题，同时基于机器建议给出决策和训练机器徒弟。运维工程师将逐渐转型为大数据工程师，主要负责开发数据采集程序以及自动化执行脚本，负责搭建大数据基础架构，同时高效实现基于机器学习的算法。机器学习科学家主要负责AI的落地应用。智能运维领域相对于其它AI应用领域的优势在于，我们不仅有大量的应用数据，而且有实际的应用场景和部署环境。因此，人工智能在计算机视觉、自然语言理解、语音识别之外，又多了一个落地应用——这是一座尚未开采的金矿。
裴丹说，智能运维科研门槛高。
从工业界的角度看，因为智能运维需要三方面的知识：第一，要熟悉应用的行业，比如说互联网、电信或者相对传统的行业，如金融、电力等等；第二，要熟悉运维相关的场景，包括异常检测、故障预测、瓶颈分析、容量预测等；第三，虽然工业界熟悉运维行业和场景，熟悉生产实践中的挑战，也有数据。但是，工业界并不熟悉整个智能运维中最重要的部分——如何把实际问题转化为算法问题（后面会讲到如何把实践中的难题分解成多个算法并逐个解决）。同时，工业界也不太熟悉查阅科研文献，特别是跨行业的文献。因此，智能运维是一个需要三方面领域知识结合的高门槛领域。
所以，裴教授和他的团队正通过自己的一些努力，来降低工业界部署智能运维的门槛。比如，清华的实验室运营了一个微信公众号，叫做“智能运维前沿”。基本上两三周推出一篇公众号文章，介绍世界范围内智能运维的前沿进展。
智能运维算法
需要在实践中更好落地
在学术界中，很少有人做智能运维方向。这是因为，对于学术界来说，进入到智能运维这一科研领域具有很强的挑战性。为什么？
虽然学术界研究人员的算法能力相对较强，但是他们往往不熟悉行业和运维领域的相关知识。而智能运维处于三个领域的交叉部分。这就导致智能运维的门槛比较高，需要花大量的时间和精力才能进入智能运维领域。
在推动降低工业界进入智能运维的门槛的同时，裴丹的团队也在努力推动降低学术界进入智能运维领域的门槛。他还曾应邀在《中国计算机学会通讯》上发表文章，向学术界的同行介绍智能运维中的科研问题。但仅仅宣传是远远不够的，还要实践。裴丹在第一届APMCon会议（由听云、极客邦科技与InfoQ联合主办的全球高水准APM技术盛会）上发表学术演讲，阐述了当时和百度合作的三个案例，包括异常检测、瓶颈分析以及智能熔断。这种公开的宣传带来了很多新的合作。除了与百度的合作，清华实验室相继与滴滴、搜狗、阿里巴巴、腾讯签署了正式的合作协议。他认为这验证了他的一个观点：工业界可以获得算法层面的深度支持，学术界可以获得现实世界的前沿问题和数据，有利于发表论文和申请国家项目。
谈到工业界与学术界在智能运维方面的合作，裴丹表示，现在工业界跟学术界的合作方式，还处于1.0阶段，即一对一的交流。在这个过程中，遇到了诸多挑战：
1.交流合作效率低，见效慢。2.智能运维算法不幸成了特权。3.涉及知识产权，不符合开源大趋势。
在他看来，开源开放的大趋势已经对工业界和学术界产生了巨大的影响。大家耳熟能详的Hadoop、Ecosystem、TensorFlow等，都是开源开放的产物。在算法层面，当前有arXiv共享算法（论文）平台和Github代码共享；在数据层面，ImageNet等数据共享平台对机器学习算法的研究起到了巨大的推动作用；在计算能力层面，各大公司都建立了AI云；在人才层面，我们也可以看到，学术界和工业界的人才流动比原来顺畅多了。
所以，裴丹说，他的基本思路是，希望能够建立智能运维的问题库。“我们尝试把运维的常见问题梳理出来，并存储到一个问题库里。这样的话，对于缺乏智能运维背景知识的科研人员，在问题的输入、输出、数据集齐全的前提下，可以很容易地着手解决问题库中的科研问题。对于做运维实践的工业界的同学们，当遇到实际的问题时，可以查询问题库中的解决方案。”
裴丹的这一思路受到了斯坦福教授李飞飞的影响。李飞飞最近在宣传普世化AI的思路——让所有人都可以使用AI，在她建立的 ImageNet上面有1000多万张图片的分类标注数据。在2012年Hinton教授提出了一种基于CNN的图片分类算法，取得比以往最好结果高好几个百分点的结果， 引起了深度学习的复兴。现在，她同时兼任Google机器学习部门的负责人。她在宣传普世化AI思路时，提到普世化有四个基本点：计算能力、数据、算法、人才。这四个基本点跟裴丹他们要落地智能运维所遇到的挑战是一样的。因为他们也需要用到机器学习和AI的技术来解决智能运维中的挑战性问题。
在智能运维的领域，裴教授的团队从去年就开始推动智能运维算法在实践中的落地，他相信只要有更多的学术界和工业界的人士参与进来，一定能推动智能运维算法在实践中更好落地。
原文：新浪财经
网址：http://finance.sina.com.cn/roll/2018-09-29/doc-ifxeuwwr9323286.shtml
——十年一剑，阿里推荐与搜索引擎平台AI·OS首次公开！
今天，五福老师将带领大家走进AI·OS（大数据深度学习在线服务体系）的十年基业里，看看工程如何与数据和算法一起驱动商业创新。
作者简介：五福，搜索&推荐工程技术负责人，阿里巴巴高级研究员，十年间带领搜索与推荐工程团队从追求极致效率入手，走向集团统一的引擎中台，实现了到智能化时代的升级，建立了世界领先的大数据深度学习的在线服务体系 AI·OS (Online Serving)。
AI·OS（Online Serving），大数据深度学习在线服务体系，由阿里巴巴工程、算法、效率的同事们砥砺十年而成，支撑起海内外阿里电商全部的搜索和推荐业务，时刻置身大数据主战场，引导成交占据集团大盘主体；此外，作为中台技术中坚，AI·OS已是包括电商、阿里云、优酷、菜鸟、盒马、钉钉等等在内全集团的基础设施；更为重要的是，AI·OS体系的云产品矩阵服务于全球开发者，今年预期在数千万级的营收规模。
AI·OS聚焦于深度学习的在线服务，其组件Jarvis甚至已经运行于手机上，但从功能角度来看，在体系中处于关键地位的有5个服务组件：TPP推荐业务平台、RTP深度学习预测引擎、HA3搜索召回引擎、DII推荐召回引擎、iGraph图查询引擎。AI·OS上的主要的算法场景，比如手淘的搜索、猜你喜欢、AIO以及海神等，都以图化（算子流程图定制）的模式对组件快速组合与部署并承担实验流量，让在线服务不拖模型训练的后腿随训随上，这是我们对迭代效率的最高水平的新演绎。
AI·OS这些关键服务组件能够幻化异彩纷呈的算法场景和技术产品，绝非机械组合可成。引擎图化的基础，尤其是对组件快速组合与部署并接流的能力，得益于我们对大数据在线服务的通用抽象（要求具备秒级数据更新的最终一致性），它就是Suez在线服务框架。Suez框架统一了3个维度的工作：
索引存储（全文检索、图检索、深度学习模型）
索引管理（全量、增量以及实时更新）
服务管理（最终一致性、切流降级扩缩容等）
每一个服务组件比如iGraph，孤立地做好这几个维度至少要3年时间，哪怕是共享大部分代码，而做好它们只是一个在线服务的基本前提，毕竟我们都知道频繁的业务迭代一定是发生在图的计算层面。近日回顾，将iGraph迁移到Suez框架上，出于对使命的认同团队精锐尽出不计投入，使得AI·OS可以合围而成。
AI·OS体系里Hippo承担着集群物理资源的调度任务，这里是中台容器和隔离技术与搜索工程交汇之地，更是模型训练PAI-TF与实时计算Blink通过AOP成为体系友员的桥头堡。今天推荐与搜索的训练任务都运行在Hippo混部资源池上，算法鼎盛时期我见证过最大2千台、七天均值1300台百核机器满负荷运转，这些资源是免费获得的，而这些作业创造的价值大到无法估量。
AI·OS自身也是预测与优化算法的用武之地，其中AIOps更是集大成者，在metrics服务KMon解决了秒级实时可靠性之后，在TPP成功推升ajdk的负载极限之后，在广大无状态服务组件弹性扩缩成功之后，AIOps终于可以再迈进一步推动Hippo池内大部分引擎服务组件执行弹性策略，双11当日力争摸高50%的负载峰值。弹性扩缩据我们所知在大数据在线服务领域是开拓性的工作。
AI·OS得以自成体系完成算法迭代闭环，离不开嵌于手淘皇冠上的搜荐服务端和客户端两颗明珠，这里是算法工程产品融合亦是相关各方博弈的主场，高效的产品迭代和完善的实验机制配合支持体系不断实现众望所归的开疆辟土。近年来端上智能的探索逐步明晰，助力拍立淘突破数千万UV，技术上反哺手淘也给AI·OS体系带来新的发展空间。
AI·OS深入骨髓的产品化理念支撑我们自居中台技术中坚，TPP、TisPlus以及OpenSearch这些精准定位的推荐与搜索中台产品成就众多事业部的大数据场景和基础检索服务。国际化大潮中，AI·OS体系化部署无需定制开发，技术中台优势独显。索引更新链路的设计欠缺造成负面影响，鞭策我们的同时侧面也佐证AI·OS的基础地位。
云上拓展不仅是机遇更是AI·OS产品化的使命和终极归宿，一批早期的引擎开发者富有远见志同道合殊途同归勇于开拓，如今OpenSearch和ES（基于AI·OS体系的基础设施）已经全球部署成长为两款千万级的搜索产品，而名为AIRec的智能推荐产品即将问世，明年我们的公有云大数据产品矩阵有望营收有新突破。
总结一下，AI·OS体系的基石是Hippo它为体系划定了资源的刚性边界，资源为在线服务发展所必须，凡支持混部在资源角度能形成双赢的即为体系友员（比如PAI-TF），目前我们也在不断拓展Hippo边界即将与Yarn合体甚至合池；往上的Suez是体系里大数据在线服务的基础框架，支持Suez即为体系成员，除运维成本大幅降低外还很自然的参与AIOps弹性扩缩进一步提升系统效率；进而再具备图化能力即成为深度学习在线服务体系的核心成员，可以在业务场景里任意驰骋，未来我们寄望于全图化引擎与离线高效对接大幅提升算法迭代效率。
从Hippo到Suez（iGraph）再到图化引擎（RTP、HA3、DII），再延伸到手淘搜荐服务端与客户端，乃至其上的AIOps和几大技术产品TPP、TisPlus、OpenSearch，其核心线索是优化算法迭代效率，这乃是AI·OS体系的精髓所在。从今天AI·OS达到的境界而言，我在所知范围内还没有见到同行到达过。
AI·OS与算法
直白地讲，面对大数据业务挑战， AI·OS至多能起到30%的作用，随后是算法解决30%+，其余的靠产品和机缘，只不过AI·OS的30%是个前提条件，这容易被忽视，在早期淘宝搜索，不久前的手淘推荐在上演。很难想象有另外的技术领域会像这两个领域一样乐于相互成就，对彼此同事的职级、规模和疆域的成长感受到的只有羡慕。我们需要永远铭记，AI·OS发展的核心线索是优化算法迭代效率。
AI·OS与Blink
Blink孵化自早期的AI·OS体内，今天已蓬勃发展为通用实时计算引擎，不过二者间关系永远的凝结于实时二字之上：AI·OS体系的引擎服务都要求具备秒级数据更新的最终一致性，而Blink在AI·OS的场景之外再难寻觅真正的技术挑战。这就很容易解释为什么Blink团队珍视AOP，而AI·OS狂热地推动Blink上混部，甚至落地Hippo与Yarn合体合池。AI·OS与Blink的互补特性，仅次于AI·OS与算法。
AI·OS与PAI
稍早时PAI希望独立发挥作用却总不能得门而入，原因是忽视了AI·OS体系尤其是Hippo的混部资源池的刚性诉求，尽管大家都认同PAI在Blink和AI·OS之间有很大的发挥空间。所幸三方的开放心胸最终达成分工默契，放弃自己的资源池后，PAI-TF成功地撑起了搜索和推荐算法全部的模型训练任务，而且也支持了AI·OS的图化执行引擎。展望未来PAI-TF可以在AI·OS发展的核心线索上发挥更大作用。
对比Blink和PAI，梳理一下AI·OS的发展脉络，不难发现规律：AI·OS首先服务于集团头部客户发展基础体系，然后具备产品化能力服务于集团内中长尾，最后再完善产品化成为云上服务。Blink诞生于AI·OS优化实时计算效率服务好了头部客户，然后发展SQL走产品化的路服务好中长尾集团内得以统一，现在也在云上大力发展。而PAI之前只能服务集团内中长尾，反观几家头部客户均有自己的训练平台，这绝非任性，主因是当时PAI并不足以支撑头部客户迭代需求。而今天PAI-TF做出改变兼容AI·OS体系，格局会本质改观，彻底落地的PAI将会同时具备头部和中长尾的服务能力，集团内统一深度学习的训练平台将会水到渠成。
AI·OS与图计算
图计算在计算引擎学界引领热潮，在离线场景（包含迭代计算）有丰富的论作，向在线服务领域拓展寻求更快速的验证在所必然，但在互联网大数据技术业界鲜有堪称经典的对标实现，是因为业界技术能力不够吗？学界热潮容易理解，图论本是经典倾倒无数英雄，而业界缺乏对标更刺激学界投入。只不过业界见到的多数大数据业务场景完整抽象后并非经典的图计算问题，比如AI·OS对此的抽象是算子流程图快速定制，这至多算是一个泛化的图计算模型。不过在AI·OS体系之上的局部，经典的图计算技术的确大有空间，iGraph乃至整个体系准备好随时被颠覆，不过颠覆之前，需要摸透具备秒级数据更新的最终一致性的在线服务的特点，从Hippo到Suez的能力要素都要逐步具备。是融入体系在iGraph或Suez上快速落地，还是像PAI一样兼容于体系，还是独立于AI·OS体系之外从头开始，选择决定成败。
OLAP与图计算相似，走向在线也将面临类似的选择。对于这类具备面向最终一致性的在线服务，独立于AI·OS建设，还意味着要开辟独立资源池，因而也更加需要提供足够独特的价值，这方面我还没有看的很清楚。最后一个和AI·OS关系密切的技术方向是OLTP，因此在数据更新的一致性上要求更高，AI·OS不会妄自涉足。
需要指出的是，集团内外流行的Graph Embedding从在线服务角度来看，和图计算无关，这个技术叫向量召回，是图像检索的泛化应用，该技术集团内实现以达摩院机器智能实验室最为突出（拍立淘核心技术之一），这部分已是AI·OS体系能力的一部分。
原文：搜狐科技
网址：http://www.sohu.com/a/256751987_629652
——循序渐进前景看好 智能运维“护航”金融业
日前，IBM发布《金融行业AIOps智能运维白皮书》(以下简称白皮书)，为金融机构与企业支招，推动智能运维落地。《上海金融报》记者就国内金融业智能运维的必要性、运维领域发展前景等问题，采访了白皮书编写总顾问、清华大学长聘副教授裴丹；IBM大中华区全球信息科技服务部、技术服务产品管理部总经理孙建钢；IBM大中华区创新解决方案总监元新华和IBM全球信息科技服务部资深构架师刘斌。
《上海金融报》:金融业智能运维有何必要性？金融机构如何构建智能运维系统？
裴丹:由于金融业对IT系统服务的要求极为苛刻，必须24 小时不间断，接近于“零”宕机，且金融业务持续创新也要求支撑软件不断迭代。因此，金融业数据中心运维必须引入新技术、新思路、新体系，更智能地为行业保驾护航。
孙建钢:金融机构构建智能运维系统，应结合实际，循序渐进。目前，金融机构基本都已建立较完善的运维监控系统，收集了较全面的运维指标数据，内部大数据平台趋于完善。下一步，需从基本数据/平台开始，逐步构建金融级的智能化运维平台及金融类业务场景，实现数据中心全覆盖，最终建立自有人工智能算法模型，将运维系统建设成为企业数据中心的运维大脑，实现智能洞察、智能定位、智能分析。此外，金融机构需搭建基于AI的智能运维平台，通过自主学习，分析和总结系统运维过程中的各种状况和规律，并针对不同应用场景建立模型，再让平台去了解运行规律。如一家全国性银行的IT环境里，可能有几万甚至几十万个趋势或规律，AI平台根据总结出来的规律去监控其IT环境，掌握所有趋势或规律后，不仅能快速找出导致问题的原因，还能提前预测，防备可能出现的问题。
《上海金融报》:很多银行都搭建了大数据平台，运行中哪个环节最常出问题？该如何化解？
元新华:包括银行在内，整个金融业的数字化平台架构较复杂，如底层架构中有大量服务器、存储网络等。从应用层或软件层看，金融业对端到端的业务有非常严格的技术要求和很高的服务要求，智能化环境较复杂，难点在于系统的层次越来越多，从底层硬件到中间件到应用软件，发生故障时，无法立刻判断哪个环节出问题。而通过智能运维，就能借助AI手段帮助企业对大量数据进行分析，从不同曲线叠加中找出故障所在。
刘斌:某全国性大型银行2016年启动IBM智能运维平台项目，日处理数据增量达TB级，覆盖个人网银、手机银行等系统，初步建立数据中心“运维大脑”，实现对针对性能指标异常波动提前预警，主动运维，并自动挖掘数据背后的现象，快速定位系统瓶颈。此前，该行手机银行在一段时间内交易缓慢，利用智能运维平台分析，发现问题出在磁盘IO的响应时间，当时瞬间峰值是正常均值的20至30倍。故障根源找到后，很快得以恢复。
《上海金融报》:国内金融业智能运维产品现状如何？未来会如何发展？
刘斌:目前，国内金融业尚无单独的智能运维产品和智能运维架构。银行使用的所有监控软件，都属于智能运维的一个组件，其他还有大数据平台、分析引擎、报表系统、智能分析系统，这是一个复杂的架构。
孙建钢:我认为未来金融业智能运维发展前景很好，尽管智能化会带来颠覆性的运维思维和效应，但并非取代现有系统，而是为之赋予智能。未来的智能运维需既懂业务场景语言，又懂平台和技术，能把业务场景翻译成新型AI语言，将咨询与交付一体化完成。智能运维最终体现形式将是人机超融合，进而实现企业永续发展。
原文：上海金融新闻网
网址：http://www.shfinancialnews.com/xww/2009jrb/node5019/node5036/n5433/u1ai208009.html
——优维科技加入信通院“AIOps标准工作组”，智能运维之路更进一步
2018年9月14日，第十届GOPS全球运维大会在上海开幕。优维科技受邀参加了AIOps标准工作组成员单位的授牌仪式。AIOps标准组由中国信息通信研究院旗下云计算开源产业联盟（OSCAR联盟）、高效运维社区和DEVOPS时代社区联合发起，汇聚了国内一线互联网企业、通信、金融等行业顶级单位及专家联合编写而成,是国内外首个AIOps 标准。
现场授牌仪式图
“AIOps”标准工作组成员单位图
优维科技为国内领先的一站式DevOps及运维解决方案服务商。核心产品EasyOps是基于DevOps理念开发的一站式DevOps及运维管理平台。旗下分为应用CMDB、运维自动化、持续交付、智能监控及ITOA五个能力模块，从应用的资源、变更、状态三个维度来构建全面的IT管理能力。
应用CMDB（IT资源管理），从应用上层入手，支持资源自定义，适配所有管理需求，自动发现能力采集一切所需资源、降低维护成本，极大提高信息的准确性。
灵活易用的持续交付平台，内置多种开源软件，插件式开发。具有完善的制品库并支持Docker镜像。灰度发布、蓝绿部署，DevOps交付看板等功能使之高效率、低成本、智能化持续驱动IT优化。
包容且强场景化的运维自动化平台，具有丰富工具库和编排库，场景商店沉淀1000+工具支持一键导入，面对不同的角色具有强大的场景化运维能力。
多维实时的智能监控平台，具有新一代APM—分布式链路追踪(Zipkin)，自定义DashBroad实现面板个性化、指标多维度，让问题发现更直观，处理更迅速，同时故障自愈也带来了极大的智能优化。
全能可用的运营分析系统，分析更全面，数据驱动DevOps的优化，数据更清晰，看板改善组织，状态更直观，有利于团队的信息共享。平台采用如微服务、NoSql、elasticsearch等技术栈，有利于功能扩展。
此次作为AIOps标准工作组成员单位，优维科技多位技术专家深度参与编写首部《企业级 AIOps 实施建议》白皮书，系统阐述了AIOps理论体系及落地实施指南，为各企业实现 AIOps 提供了实施路径。
目前，优维科技EasyOps产品已在招商银行、国信证券、招商基金，上汽通用、春秋航空等不同的领域企业成功落地。
未来相信优维科技凭借深厚的互联网DevOps运维经念及多年传统企业落地最佳实践，加上AIOps领域的不断探索，为客户提供更加“Easy”的一站式运维解决方案平台：EasyOps。
优维科技一直以开放的心态积极拥抱DevOps行业交流与社区建设。除了各家领域内客户的认可，这次成为AIOps标准工作组的成员单位也体现了行业对优维科技在智能运维领域耕耘成果的肯定。优维科技仍将坚守初心，以“连接IT和技术，让IT为企业提高持续创新动能”为宗旨，更积极地联合各大产业社区，提高运维产能效率，为IT智能运维的建设添砖加瓦，以顶级服务支撑客户的运维方案，与行业共同成长。
原文：CSDN
网址：https://www.csdn.net/article/a/2018-09-18/15961068
——2018 Gdevops全球敏捷运维峰会北京站圆满落幕
9月21日，2018 Gdevops全球敏捷运维峰会北京站如约开幕！这场汇集运维与数据库干货的高质量技术盛会，可以说提前给北京新老朋友们送上了一份诚意满满的中秋佳礼。没有到场的朋友也不必遗憾，让我们马上精彩回放！
主会场
新炬网络运维产品部总经理 宋辉——
传统企业AIOps落地实践
2018被视为AIOps落地的元年，毫无疑问，无论是对于互联网公司还是传统企业来说，当前系统的规模和复杂度都已慢慢接近人力极限，智能化是必然选择。在企业级运维服务市场深耕十余年的宋辉老师，基于新炬网络在助力传统企业智能化运维上做过的尝试和经验，总结出了传统企业AIOps落地的三大建议——1、统一数据管理，做好可视化；2、引入AI能力，结合智能化；3、标准化运维场景，落地自动化。由此串连出落地AIOps的演进路线，让现场听众对智能化运维有了更清晰、更系统的理解。
清华大学长聘副教授/青年千人 裴丹——
基于AIOps的无人运维
来自清华大学的裴丹教授是AIOps方面的专家，他分享的内容相较前者更偏向学术思路。从当今技术发展的背景来看，人力决策已经无法应对运维挑战，他提出“无人运维”的思路，建议基于AIOps建立运维大脑，把繁杂的具体运维场景拆解成四类模块，搭建起AIOps架构、应用决策算法和运维知识图谱来真正实现智能运维。
JFrog中国区总经理 马致杰——
数据驱动DevOps和安全的碰撞：传统行业DevSecOps的实践
马致杰老师以DevOps的全球生态作为切入点，由其基本特点引出建立DevOps团队的最佳实践，并指出从组织结构来考虑，要明白在哪放置DevOps团队。而对于落地DevOps的问题，他建议用三步来完成：选择合适的工具；收集DevOps元数据，评估研发效率；落地内部容器化。此外，他还提出，如果想要上线的应用没有漏洞，就需要让漏洞扫描作为应用上线的质量关卡，用深入依赖管理来明确漏洞的影响范围。
快狗打车（原58速运）CTO 沈剑——
底层技术团队，该怎么带？
有别于前面三位老师，沈剑老师从团队管理的层面展开了分享。他围绕“底层技术部门作为业务技术部门的支撑，如何处理上下游的管理、带好团队”这一问题，针对底层技术团队的5大痛点逐一给出解法，总结得出：工作需求应从业务研发里来；支持工作应由工单型转变为业务型；上下游配合应把丑话好话都说在前头，即提前制定数据指标、流程规范等；若没有业务成就感，可考虑接手中台业务系统；若团队技术氛围不强，可定期开展技术分享或培训夜校，帮助员工成长。
数据库专场
罗辑思维首席DBA 李丹——
DBA与RD如何更优雅地驾驭MongoDB
随着数据量不断膨胀，以及企业业务需求的持续增长，数据库的更新和选型成为了越来越多企业的探索和尝试。针对MongoDB这一时下热门的开源数据库，李丹老师进行了详细的应用讲解。他着重强调了MongoDB读写一致性的问题处理，以及常见的架构部署建议，还结合最佳实践分别列举出MongoDB在最新认证模式中的坑、在查询优化上的原则，以及其他使用事项的要点，足以让DBA和RD轻松驾驭MongoDB成为了可能。
PingCAP核心工程师 邓栓——
Cloud-Native数据库的实现：TiDB在Kubernetes平台自动化部署运维实践
当下，Kubernetes已从最初的无状态服务部署平台逐渐演化成云上标配“操作系统”，邓栓老师以TiDB的实战经历详细分享了如何在Kubernetes上管理有状态服务，如何借助Kubernetes实现数据库的自动化部署和运维，和大家一起回顾了TiDB被打造成Cloud-Native数据库的全过程。
中国光大银行资深数据架构师 王磊——
银行业图数据库分析、选型与实践
图数据库虽然在目前还是比较小众的话题，但用作一种对已有数据可视化更清晰有效的补充，十分值得深入研究和使用。王磊老师所在的光大银行，不少业务像信贷管理、反洗钱、审计分析等，面临着高连接数据的挑战，因此他们将图谱技术应用于这些业务场景里。分享中，除了图数据库在光大银行的实践以外，王磊老师还对主流图数据库的架构进行了分析并提出了选型建议。
巨杉数据库联合创始人/CTO 王涛——
新一代NewSQL数据库架构与实现
王涛老师主要分享的内容是如何从分布式数据库的架构里做到NewSQL数据库。他从传统MySQL的主从复制结构说起，依次讲解了NewSQL数据库SequoiaDB的MySQL兼容架构与实现、分布式架构与特性、MySQL兼容样例、性能测试，以及在银行业的应用实践，同时还解答了现场听众提出的关于异地双活的疑难。
小米运维DBA负责人 张良——
智能SQL优化与改写
既要检查语法又要判断逻辑、幽灵般的隐式数据类转换、复杂查询的索引优化、不重不漏的索引优化能力……张良老师指出的这些SQL查询优化难点，相信也是不少企业面临的难题。他从多方位对目前市面上的SQL优化产品和相关书籍进行了大量调研，研发出了开源工具SQLOptimizer，更为现场听众详细解析了其在SQL改写的启发式算法、数据采样算法以及索引优化算法等策略和实践。
网易Cetus项目负责人 王斌——
MySQL数据库中间件—Cetus的架构与性能优化
据王斌老师介绍，他们研发的这款开源的MySQL数据库中间件之所以叫Cetus，是因为MySQL是海豚，而Cetus是鲸鱼的意思，两者是同属一个类别的海洋动物，目的就是希望让Cetus使MySQL这个技术变得更加强大。那么Cetus是如何助力MySQL的呢？王斌老师从性能、架构、SQL功能、代码优化、压缩优化、硬件体系支持等方面做了详细的解读。
运维专场
中国电信甜橙金融高级总监 张小虎——
甜橙金融异地双活方案
作为运维专场第一位开讲的讲师，张小虎老师带来了甜橙金融异地双活方案的运维实战经历。一个新架构的成型必定与业务的发展有关，业务发展促进了架构迭代前进。想要实现异地多活架构，就要解决这种架构的核心问题，掌握其设计原则，设计契合的架构方案。在仔细分析了公司现状后，最终采用了流量调度、消息分发及数据层改造等方案，顺利解决了面对跨千公里网络时延、各数据中心一致性的问题。
汇丰基金服务技术经理 刘华——
银行项目落地DevOps的难点及攻克之道
虽然目前市面上有很多DevOps的教科书，但直接照搬这些案例在传统行业进行尝试却往往会水土不服。那么银行项目在落地DevOps时应该怎么做？刘华老师就银行项目的难点及攻克问题的方法进行了详细的分享。他针对业务需要计划与承诺、业务组织架构复杂且难以找到PO、依赖供应商开发、需求不清晰且复杂并难以理解等难点，给出了对应的解法，分别是：传统项目计划的方法和工具依然重要；通过敏捷实践和工具实现高效沟通与交付；实例化需求确保正确交付和持续交付。
腾讯运维总监 聂鑫——
腾讯最新AIOps落地与实战
聂鑫老师从腾讯的织云监控体系详细介绍了他们对数据的多维处理及DPL指标概念。随着AI的发展和普及，运维践行AI成为一种必然趋势，织云对AI的尝试逐渐迈上正轨，大致可以分为解决文本NLP、预测和预判的问题、信息收敛的问题、根因分析等四个阶段。此过程中的思考和探索引人深思，给现场听众带来了不少启发。
京东商城基础架构部资深架构师 梁小平——
京东商城集群管理与调度系统-阿基米德
梁小平老师给大家带来了京东商城集群管理与调度系统阿基米德的运维经验，首先介绍了阿基米德的容器生态，着重强调了生态顶层核心JDOS的重要性；又从调度系统的实践经历入手，分享了搭建过程中解决的三大挑战：内存超分算法、衡量指标SLA及使用大数据存量算力用于大促。最后以混合部署实践来收尾，从部署过程的痛点说起，总结解决痛点的条件和混合部署的关键技术——资源隔离及限制。
携程技术保障中心资深运维 徐新龙——
AIOps在携程的探索与实践
徐新龙老师从异常指标监测、智能告警诊断、资源混合部署、智能弹性扩缩容四个方面分享了携程的AIOps实践。其实对于AIOps的落地，故障预测就是一个典型的场景。原来的指标性、指标范围性的数据分析已经难以满足周期数据的问题预测，在这个层面上，如果有大量的数据沉淀下来，根据时间序列的周期问题就是一种行之有效的策略。AI毕竟只是一个工具，实践还是要结合自己的场景，紧跟行业动态，从学术界跟工业界汲取精华。
阿里资深运维 张娟（希宁）——
NoOps运维实践之弹性容量托管
如今谈论运维，越来越避不开AIOps和NoOps这两个话题。在峰会的最后，希宁老师首度公开了阿里NoOps运维的弹性容量托管实践。弹性托管大大提高了运维的生活质量，业务可以不必关注更多运维细节，但可以在业务方面做更多设计和改进。为了实现弹性托管，阿里进行了多种尝试，从容量规划、弹性伸缩及风险管控三方面下手调整。这种托管的保姆式呵护根据压力负载做到弹性，把故障率降低，比单纯提高可用的几个9要实在得多。
原文：ZOL新闻中心
网址：http://news.zol.com.cn/698/6989921.html
