运维的那点事：从0到1自动化智能运维之路

在江苏CRM 项目经历了传统IOE封闭的商业架构到第三代BES开放的互联网架构的演进历程，设备数量也从几十台到上千台，客户的运维要求也越来越精细，各类指标分析逐年增加等，给系统运维带来极大的挑战。

挑战1：设备数量激增

系统设备从几十台小机到上千台的虚拟机,应用部署、版本发布、主机资源负荷分析、异常分析、应用（配置）一致性检查、日常维护等工作量上涨20倍+。在小机时代只需要人工定期登录到主机进行巡检输出报表即可完成，故障定位时可以很快的找到故障主机；CRM系统割接到第三代BES互联网化版本后，运维人员并没有增加的情况下，系统的运维几乎处于奔溃的边缘，系统故障后问题定位缓慢，客户满意度下降。

挑战2：系统架构变化

老CRM系统架构是主要围绕以IOE架构，采用比较闭源的软硬件产品，以小型机、weblogic、tuxedo等构建的三层架构，这种架构体系纵向扩展能力极强，横向扩展能力很弱，在遇到电子渠道的营销活动时，时常出现性能瓶颈不能完全支持业务的要求，每月月底月初业务量高峰期时常被客户诟病，运维人员都处于救火的状态。但是由于架构限制，导致系统处理能力扩容较为困难。但是传统的涉及的组件比较少，三层架构相对简单，业务调用、数据流向非清晰，对运维人员来说运维你能相对单一压力较小，且有第三方的专项技术支持人员进行技术支持。

第三代系统上线后，系统架构从传统的3层变成5层架构，引入了zookeeper、MQ、缓存、VS等开源软件，服务间调用更加复杂，故障定界更加困难，对运维人员的要求更高，需要掌握系统中各个组件的特性和维护的方法或工具。

挑战3：系统监控

系统监控方面客户还是沿用老CRM架构的监控方式,完全依赖传统的bomc网管系统，以点监控为主，无法做到按照集群级、全面的监控。由于第三代系统上线后设备数量激增， 导致bomc 性能严重不足，告警延迟；同时在系统故障时bomc 告警铺天盖地而来，往往将有效告警淹没掉，导致系统监控完全失效。

挑战4：指标分析

老CRM系统时代，由于系统架构简单、稳定性较高，维护人员关注的指标主要是偏向主机资源、业务调用量等，更多的是偏向；新系统割接后，更加关注最终用户的体验，客户也对系统的响应时长、故障时长等指标更为关切，面对自身维护和客户各类指标数据的分析，每天都有相当的运维人员在进行指标分析，同时由于运维人员经验和技能参差不齐，导致数据分析效果差强人意。缺乏统一的数据采集、数据分析的方法，导致运维效率欠佳、效果被客户诟病。在新系统上线后引入了dv,采集了大量的系统指标数据,存放在系统中，这类数据就像没有工具开发的宝藏。

挑战5：日志分析

系统日志的分析一直以来是一线运维人员的痛，只能凭借运维人员的经验来发现系统中的错误日志，在出现问题时由为严重。新系统上线后每天业务报错日志有4亿条，全部都采集到dv中，提供日志查询服务，而维护人员真正使用日志服务的场景屈指可数，使用频率并不大，没有真正的发挥出海量日志应有的作用。维护人员想对日志进行优化往往也抓不住重点。

挑战6：思维模式

传统运维模式主要是依赖bomc的网管系统进行，以被动响应的模式进行系统故障的处理与干预，运维人员每天只需要看管好自己负责模块的运行情况即可；新系统上线后,x86架构的故障率更高，老的运维方式已经不满足新系统的模式，如何实现自动化和高效的运维成为一线运维人员的首要任务。

同时也有来自客户的声音：系统上线后如何评价新版本对系统的影响；dv中大量的指标数据如何发挥其功效；日志服务器中的大量日志如何利用大数据物尽其用。同时客户也在积极寻求运维上转变，多次要求协调大数据、智能运维的专家到场交流。

面对上述问题，我们也在积极的转型，逐步向自动化运维迈进，积极向智能化运维探索；我们主要从如下几个方面提升系统的自动化、可视化运维，提升系统运维效率：

基础平台运维方面：拉通客户推动bomc对基础平台的监控进行改造，要求bomc 的监控方式严格参照BES系统的集群组网重新构建bomc的监控平台，实现基础资源平台和业务集群相互对应，快速实现基础资源性能、故障对业务集群影响的分析判断。

应用版本发布方面：BES主要是使用df 的版本管理和版本发布能力，在此不再进行详诉；由于江苏CRM应用为全部割接到bes系统，还有一部分在老icrm系统运行，针对老icrm业务，我们也在构建自己的自动化发布平台，实现界面化操作，目前已进入测试阶段。

应用服务运维方面：我们从宏观的集群维度进行自动化、可视化监控；从微观的server实例维度进行监控：

宏观的集群维度：

2016年引入维优的orpt（oracle report）工具对bes系统的关键集群进行指标的可视化展示，提升了系统故障定位的效率。缺点是无法实时监控系统各集群的运行指标，在业务人员报障后运维人员才介入处理故障。

2017年年初，维护联合DV研发在江苏推出监控大盘，将bes系统营业厅、电渠、客服等集群的响应时长、调用量、成功率在监控大盘中展示，监控性能达到分钟级，可以快速发现系统中问题集群和问题主机，实现故障主机快速隔离（停止服务、服务隔离），实现故障集群的流量切换（集群切换）。

微观的server实例维度：

系统割接初期，运维人员通过编写脚本采用curl http://ip：port/health.jsp的方式探测生产环境所有节点的运行情况，发现异常节点后就已短信告警的方式通知维护人员对异常节点进行人工干预。在单节点故障时可以有效的发现故障节点，在系统大面积异常时会导致短信风暴。

2017年推出拨测大盘后，将生产系统的所有server 节点配置到拨测平台进行主动探测，参照生产集群进行分组，将所有server划分到各自所属的集群中。通过拨测大盘可以很清楚的知道各个集群中server的健康度（server响应时长和server存活率）.

同时根据日常的故障处理得经验，将系统故障时的关键字进行脚本固化，在系统日志中定期进行匹配并告警，提前发现系统异常节点并提前规避。

业务维护方面：业务维护主要是从业务指标运维和业务投诉运维两个方面。

业务指标运维主要是根据维护人员经验将系统中的核心指标进行监控和分析，系统上线初期主要是将系统监控的指标配置到bomc告警，由于bomc系统不支持可视化展示，体验性较差。我们尝试自己开发工具进行数据的采集和展示，当时完成了订单、批量、数据库性能的采集监控，效率较低；2018年尝试使用DV的自定义采集功能，将生产250+指标数据实时采集到dv中，进行性能趋势的展示。

业务投诉运维主要是业务运维人员接受各个渠道的业务投诉工单，不同投诉人员对相同的业务报错采用自然语言表述各不相同，导致问题分析和统计非常耗时，运维效率低下；后面和客户多次讨论推出了“智能机器人”，业务投诉人员通过“机器人”将业务投诉录入到系统中，同时“智能机器人”对自然语言进行解析并快速将问题进行聚类，极大是提升了系统问题的分析统计和收敛。

业务连续性方面：由于新系统上线后，运维人员对系统中新增软件的特效不熟悉，在故障定位和故障处理的效率都比较低下，每次在故障恢复后，会分析该故障是否可以进行故障演练，如果满足演练条件就会联系客户进行评审，每月安排一次模拟故障演练和故障快速恢复，截止目前已经对zk、vs、nginx等组件安排了20余次故障演练，通过故障演练提升运维人员的应急能力。同时根据江苏bes应用的多中心组网情况，构建了多中心一键切换的能力，单中心故障后将流量导入其他中心即可，可实现故障快速隔离。

日常保障方面：学习SRE引入轮值on-call机制， 应对系统中全天候的突发性的、临时的事件（规范化的例行事情、告警、故障等），重大故障升级到维护组内重点保障。释放其他维护人员的碎片化时间，重点关注系统重要问题分析解决、运维自动化等效率提升性工作。

人员技能方面：我们要求运维人员熟悉shell和python脚本能力，通过自动化脚本实现icrm版本发布、版本检测；服务隔离、日志系统自动维护、异常日志异常监控、数据采集等工作，将日常简单的判断逻辑全部实现自动化操作，减小人工运维的成本。

在日志运维上面：对运维人员来说，系统中的报错日志太多，运维人员想通过日志的聚类分析发现哪些日志是系统正常运行报错的日志，哪些日志是系统故障时会出现的日志，各类日志出现的频率是什么样的？包括新版本上线后是否有出现新增类型的日志报错等。这些问题在17年系统转维时和dfx兄弟进行交流时表达了一线运维的述求。18年研发开发出基于机器学习的日志分析工具（SLA），在江苏现场的使用效果很明显，可以在十几万条日志中聚类分析出有几条日志是异常，经分析这几条日志是因为表字段不一致导致。该工具极大的提升了现场维护通过日志分析辅助问题定位效率，在给客户的演示效果后，客户对改工具非常感兴趣（客户将所有系统的日志采集到了bomc系统中进行大数据分析，目前日志分析效果不明显）。

在指标运维上面：我们和客户对系统共同制定了各种各样的SLI（服务质量指标：成功率、时延等），并对各类指标制定了各自的SLO（务质量目标: 服务的某个SLI的目标值，或者目标范围），开发工具对系统的各类指标的服务质量目标进行实时度量，每天安排专人对系统出现的故障进行分析定位，逐步提升系统SLA目标。

我们在分析这类指标时需要根据运维人员的经验为每一个指标项制定参考值，严重依赖运维人员的经验，无法根据系统的历史指标数据设置动态的预值。18年引入了研发的的KPIcheck工具，对系统的指标智能检测。该指标检测工具具备学习能力，能将对应指标项的历史数据进行学习并提取特征数据，然后根据历史的特征数据准实时对生产的指标进行异常检测。目前江苏主要用于业务集群的性能指标检测，彻底摆脱了依赖运维人员设置大量的静态规则，提高了系统周期性实时检测的能力，根据工具检测出来的结果准确率达到90%以上。

江苏现场结合KPIcheck智能异常检测的算法的和dv的故障诊断能力，进行2次开发实现了AI诊断的能力《江苏BES依托AI算法构建故障诊断能力》，在此不在详诉。19年我们计划将更多的系统和业务的指标进行量化，纳入到KPICHECK工具的异常检测范围内；同时也会丰富我们的日志检测范围，及时发现我们系统的隐患和问题。

同时为了便捷运维人员的效率，我们使用python实现微信聊天机器人，实现随时随地查看系统运行情况，极大提升客户感知。

我们离全量自动化运维、智能运维的理想王国还有很长的路要走，我们现阶段还处于建设阶段，我们将以始为终将，不断完善系统的自动化运维能力、智能运维能力、可视化运维能力。在当前大数据和AI大行其道的环境下，智能运维和数据挖掘是我们的工具，如何从运维到运营，通过数据挖掘成就客户价值，也是我们未来发展的方向。

运维 大数据

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。