暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / 浅谈运维数字化转型

浅谈运维数字化转型

IT那活儿 2022-02-17
3247

点击上方“IT那活儿”，关注后了解更多精彩内容！！！



01




为什么运维工作要做数字化转型？

相信在IT运维领域干过一段时间的同学，对于运维工作的内容都耳熟能详了，每天从早忙到晚，经常加班加点。例行巡检、安装部署、风险评估、故障处置、性能优化、安全加固、资产盘点、日志分析、安全审计等等。
但一到写工作汇报的时候就抓耳挠腮，因为想不起自己到底干了啥能拿得出手的成绩。这算是做运维同学的心病：工作没有量化输出，我做了那么多，你却看不见。
运维工作重要吗？绝大多数人都知道非常重要。毕竟一次意料之外的故障或访问风暴带来危害可能是灾难级的。
疫情时代好几个城市的健康码平台故障上了微博热搜，不少相关行业干运维的同学都心有惶惶，担心自家的家底是否能经得起如此考验。
做运维显然不能靠天吃饭，除了把应急预案做足，我们也需要知道何时该触发预案执行。如果不能提前把自家平台的底给摸透，出了问题真的是哭都来不及了。
所以，平台业务能力数字化评估是预案执行的前提。

运维自动化已经做了多年，通过平台实现了很多运维动作的自动化。确实有不少原本需要人工投入的工作交给了机器定时执行，或根据规则算法等方式实现自动执行。
但是在跨平台或跨系统的环节，仍需要靠人力实现流转，各平台之间的流程打通和数据打通仍是困扰运维人员的一大难题。
领导在工作群里的指令下达到平台上的任务执行，仍然需要靠人来实现从自然语言到应用程序的转换过程，只能感叹一句：流程没有基于数字化平台打通，有人工才有智能。




02




运维的数字化转型如何落地？


围绕着上述这些困扰运维团队的问题，把目光聚焦到数字化上。我们需要通过数字化的方式来实现对运维工作的现状量化评估、目标量化设定、过程量化管理、成果量化体现。四步实现运维的数字化。
第一步，运维工作评估数字化
我们需要通过对运维对象做量化评估来明确下一步工作目标，也需要通过对运维过程做量化统计来发现效率问题。
A、构建系统健康评估体系
在实施了监控管理之后，我们对于所运维目标系统（设备）已具有了较强的性能采集和性能阈值告警的能力。
这个能力提供我们对于系统故障发生后的快速响应能力，但仍不足以提前预知故障的发生，并且这些性能指标往往只预示某一个维度的风险，而对于客户感知到的整体业务性能或业务可用性，却缺少关联性支撑。
事实上，当客户反馈系统存在业务缓慢或业务办理不成功等异常时，运维人员往往从监控指标层面是无法发现问题的所在。
这里面有性能劣化累加的缘故，例如完整流程中一个单元的微小性能变化也许无法触发阈值告警，但存在多个单元存在性能下降时，带来的业务办理缓慢的感知却是恶劣的。
又比如，业务日益复杂带来流程过长，单点的效率略低，单个性能数据来看甚至无法引起运维监控的注意，而在对外的接口侧反馈却是超时返回。另外一方面，也有业务层面异常与系统层面异常的差异。
运维人员往往关注到的性能指标都是偏向底层的Paas层指标，而客户关注的其实是业务层的办理是否成功、办理是否迅速等感受。
而在业务规则条件日益复杂的情况下，因为某些业务逻辑受限带来的办理失败，已经远远超过系统自身故障（性能）的原因了。
在这样的形势下，构建一个覆盖系统性能指标以及业务支撑能力指标的完整指标体系是必须的。
我们可以从单个重点业务办理的流程维度、应用服务的物理拓扑架构维度、业务支撑的整体性能维度来建立这样一套评估指标体系。
1）业务流程维度
业务系统平台对外的服务，是由一个个的业务流程组成的。一线的平台使用者对于系统的最直接感知，也是单笔的业务办理是否顺畅。
通过对核心（重点）业务进行全流程的单元分解，基于单元明确服务能力指标，我们可以得到用于标识单个业务的一组运行指标。这里面包含有单个服务的调用总量、平均调用耗时、单位时间的调用成功率等。
通过对这些指标做基线沉淀，我们能够得到一组用于快速发现该业务发生异常的感应器。
例如业务正常时段的调用量突降或变为0可能预示入口网络访问异常；平均调用耗时的增加可能是由于近期上线代码质量不过关导致服务性能劣化；单位时间内调用成功率下降的原因可能多种多样，也许是代码级的bug，也许是某些业务规则改变带来的办理条件不满足，需要从业务角度切入做进一步分析。
这些指标数据的长期历史数据汇聚，能为运维分析提供强有力的数据依据支撑。
2）应用拓扑维度
应用拓扑是传统的Paas层运维的纳管对象。运维人员对于这个维度的指标体系是比较熟悉的。
通过对系统资产的部署关系、调用关系、归属关系的获取和维护，并对各层级的应用模块、设备模块、网络模块的性能进行指标化管理，我们可以得到一座由下而上的异常影响分析金字塔。
目前在我们所运维的大多数现场，或多或少都已实现了这些指标数据。
在这座金字塔中，下层的物理设备故障必然引起部署于其上的应用模块（数据模块）发生异常，有调用关系的某个模块发生故障时，必然会引起关联模块的服务调用异常。
通过对这些逻辑关系的分析，建立层级之间的模块指标体系的关联，运维人员可以做健康影响分析，也可应用高可用、双中心、冷热备等方式实现对系统可靠性进行优化。
3）对外业务支撑能力维度
对外业务支撑能力维度是从系统整体来评估业务支撑能力。
这个维度是将系统作为一个整体来看待，关注点在其对外提供的能力。例如服务的并发提供能力、周期内的业务容量、数据的存储容量、单位时间的最大订单执行量等等。
通过这些系统整体指标，能看到当前系统承载容量水位，为及时扩缩容提供数据依据，也能为经营分析评估提供业务增长或萎缩的数据支撑。
通过将业务支撑能力指标与应用拓扑或业务流程维度指标结合，我们能更快定位到系统的性能瓶颈所在，让优化工作开展更有针对性。
B、构建运维效率评估体系
做了不短时间的现场运维团队，都会面临一个困扰。日常工作按部就班的在做，明确的运维范围都覆盖到了，系统的稳定性也在优化工作的推进下稳步提升。
虽说仍有一些不可预知的故障发生，毕竟硬件的突然坏掉或业务上了个bug这种小概率事件无法彻底避免。
那么，运维工作的提升是否就到此为止了呢？
很显然不是的。
随着业务范围的扩展，可以预见我们所运维的系统将日益庞大，业务模块越来越多，系统架构也变得更加庞大。更新的技术也带来更多的能力，各种开源框架、开源组件层出不穷。
相信任何运维团队都无法靠人力扩张来支撑随之而来的运维压力，人力捉襟见肘是常态。在人力无法扩张的时候，提升效率几乎是唯一的出路。

在运维工作的初始阶段，所有的工作都是靠人。巡检是人工登到一台台的主机上去检查的，数据库是靠DBA一套套装的。
十多年前，系统仍不算复杂，业务量尚没有那么大时，我们曾经这样干过。而现在的设备翻了100倍还不止，动辄数百套库的安装部署。这已经不是单凭个人效率或能力能解决的问题了。
当我们想到要提升运维工作效率的时候，首先面对的问题是如何评估现在的效率，并且找到现在运维工作中严重影响效率的环节，再有的放矢去优化它们。
对于运维工作效率的考量可以从建立任务跟踪体系和评估流程人力占比两个方面开展：
1）运维任务跟踪体系
运维工作是可以用任务的颗粒度进行跟踪的，无论是对外提供的IT服务，还是对内的日常工作，使用一套优秀的任务系统来登记各项任务、设定预定完成时间、记录实际完成时间，备注当前状态及所遇到的问题有有必要的。
结合流程引擎，我们可以将需要执行的运维工作拆解为一个个的任务单元，将任务单元分配给人或自动化平台来完成。
通过接口获取到任务单元的执行状态、执行结果等信息，我们能知道哪些任务存在时延，哪些人导致效率瓶颈，甚至是哪些配合工作没有做好，哪些组织存在配合上的问题。
流程复杂、耗时太长的运维工作一定是工作优化的首要目标。
2）运维人力投入评估
如果一项运维工作绝大部分都需要靠人才能完成时，这项工作的效率一定是不够高的，毕竟人的并发工作能力无法与机器相比。
当人力成为现场运维团队最大的效率瓶颈，无论单个人的能力有多强，是时候考虑如何提高自动化能力在运维工作中的占比了。
日常巡检这样的工作当然应该尽量交给监控告警系统；如果系统具备高可用环境，那么发现了故障后的处置，也可以由自动化平台触发自愈流程来完成；还有安装部署、主机加固、配置调参这样的操作动作相对固定，操作对象数量巨大的工作，也应转由系统完成，人力在其中只负责值守并查看结果即可。
对于运维效率的评估中，是否占用更少的人力，提升机器自动化投入占比，是衡量现场运维工作成熟度的重要标志。

第二步，运维工作目标数字化
通过对运维对象健康状况的量化评估，我们得以发现系统的运行状态以及薄弱环节；通过对运维效率的量化评估，我们也具备了定位流程优化及自动化改造关键环节的能力。
那么，应该如何推动运维工作的进一步优化呢？
不少的现场运维团队工作开展是事件触发的。
一个告警触发了一条任务工单，由某位运维工程师接单后执行相应的运维操作，并通过回单动作结束了这项运维工作；领导或客户的一个口头工作安排，也可能是运维工作触发的起点，出个系统运行情况报表，或者安装一套库。
经常听网上有职场人吐槽说上头动动嘴，下面跑断腿，大概就是这一类了。
这些工作当然是属于日常工作的范畴，无论是系统事件还是客户事件，都构成了运维工作的一部分。
但，也只包括了一部分。
到了月底年底要做汇报的时候，我们显然不能拿出一张清单来说处理了多少个系统告警，处理了多少起系统故障，处理了多少次客户口头工作安排。
这些不是运维工作应该展现的成绩。或者说，这些只能代表工作的苦劳，却不是功劳。
运维工作在一系列繁杂的事项中，是有一条主线的。
这条主线是要让我们运维的系统运行越来越稳定、性能越来越强、业务越来越高端、承载的客户越来越多；让我们运维服务效率越来越高，投入的低效劳动越来越少，自动化水平越来越高，所面向的客户越来越满意。
这个目标是没有止境的，听着似乎是一句很空洞的口号，所以如果要实现它，需要做一层层的拆解。
运维工作目标的数字化，以及对该目标分解为各阶段的执行计划和执行任务项，是落地目标实现方案的具象。
我们可以通过运维工作任务系统，设定每一年度或时间阶段的运维提升目标。这个目标可以是面向所运维业务系统的，也可以是面向运维服务过程的。
A、面向运维业务系统的优化目标
1）确保系统运行更加健康
这个目标的设定是与前面所讲述的系统健康量化评估相关的。
随着业务的发展壮大，要承载的业务量越来越多，业务逻辑越来越复杂，必然带来系统的压力日益增长以及对于单笔业务的办理效率下降。
如同逆水行舟，如果不持续关注系统的运行状态，并推动关键环节的优化，则必定会积重难返。
可以预见的未来会出现时不时的业务办理流程超长导致超时失败，数据库并发访问增大导致死锁或夯住甚至宕机，网络流量过大出现阻塞……

各种的异常故障并不是瞬间形成的，而是在一次次微小的变化后积累而成，当最后一根稻草轻轻压下时，已是回天乏术了。
所以，通过对业务系统各项运行指标的分析和评估，确定阶段时间内的优化指标项，保障这些指标不会进一步劣化，对存在风险的指标进行优化，更甚至将未来可能的劣化提前进行优化改造，都成为运维工作设定的重要目标。
例如高负荷系统的扩容改造，高水位数据存储的腾挪清理并重新制定生命周期管理规划，访问峰值的负载均衡调整等等。
这些工作也许没有那么紧急，但却非常重要，这是现场运维团队任务的重中之重。
2）确保系统运维向符合业务发展方向演进
这个目标的设定是伴随着企业发展规划的。随着行业业务的发展，以及业务系统所面向客户的需求提高，系统的能力也被寄予了更高的要求。
例如建立数据共享中心必然会引入一些大数据组件，按不同的数据应用需求来提供数据存储及开放。新引入的开源数据组件该如何运维则即将成为运维团队所面临的问题。
又例如客户需要更快的在线数据分析能力，那么引入实时计算的开源架构也势在必行，如何确保计算过程中不出现异常中断，或系统异常中断后如何恢复不丢失数据，同样是运维团队应该参与考虑解决的问题。

这些问题在系统改造或系统建设阶段就应该介入，从利于运维的角度提出解决方案，并将方案作为阶段目标，并分解出任务子项，与系统建设团队一起推动落地施行。
例如故障场景的应急预案构建，数据迁移任务准备等等，这样才不至于在接手系统运维时故障频发，手忙脚乱。
B、面向运维服务过程的优化目标
1）运维服务效率提升
运维工作的执行效率是衡量运维服务水平的重要指标体系。这个效率的评估是以完成任务为前提的。
例如50套数据库的装库及数据迁移工作，两个人一个月完成，投入60个人日，最终达到了任务目标，但客户不见得满意，因为这是以牺牲其他工作的完成为代价的。
如果投入1个人半个月时间，通过写脚本、测试脚本并顺利执行50套库的安装迁移工作，虽然整个安装库的过程也耗时1个月，但实际投入的人力其实只有15人日，并且这套装库程序在后续的同类工作中稍加改造还能继续发挥作用。
那么效率的提升是明显的。因为对于单个运维人员来说，还能并发执行其他的运维工作。
我们可以把常见的运维工作场景化，并梳理这些场景的工作流程，基于这些工作场景设定流程时长压降目标，或人力投入压降目标。
无论是缩短单个场景的工作时长，还是减少人力投入，对于整个运维团队来说，都是运维效率的提升，可以带来巨大的并发工作能力增长。
流程的优化，可以分拆到各个步骤环节，使用自动化平台能力替代人工执行，还可以对审核环节由人工审批转为自动审批，甚至优化掉一些不合理环节。
所有的优化方案都可以分拆到一项项子任务来推动实施，并最终完成一项运维服务工作效率的整体提升。

2）运维服务质量提升
面对客户，面对业务系统，应该心存敬畏，如履薄冰。没有哪家老爷会愿意自家的长工当成了祖宗。
在笔者还是个运维行业菜鸟的时候，就曾听前辈大佬说过这样一句话：当用户还愿意骂你的时候，说明他还对你有所依赖；如果他已经懒得骂你时，你就离滚蛋不远了。
所以，运维服务应该有质量标准，并且运维服务要把不断提升质量标准作为阶段目标。
不过，运维服务的质量评估较难通过数字做客观量化体现，一般现场往往用客户满意度或客户最终的合作伙伴打分来作为相应目标，而这些打分标准或扣分标准也来源于客户对于系统运行稳定性、运维支撑情况、事件处置效率的综合印象。
由于各个现场存在差异，因此在这里不做赘述了。

第三步，运维执行过程数字化
运维执行过程的数字化，包括应用任务管理系统将所有的运维工作任务化记载，通过连接自动化平台实现部分任务的自动化完成，以虚拟数字员工跨系统对接工作流程闭环。
A、运维工作任务化记载
通过前述的运维目标评估和运维目标设定，我们已引入了运维任务这个名词。
所谓运维任务，应该是指运维过程中的每一个执行环节。当然，这个执行环节可以是大的运维场景，也可以是细小到具体的一项运维操作。
例如安全加固这个事项可以是一个运维任务，其实这个任务里面也可以继续拆分为多个子任务分派给不同的人执行，又或者可以将部分加固操作分配给某个自动化程序来执行。
运维任务的设定，可以更好的对运维过程进行把控。
应用任务管理系统从整体目标分解到阶段计划，设定阶段里程碑目标，再分解到每个阶段需要执行的运维任务，指定任务的执行人或执行程序，设定计划开始时间和计划结束时间，预分配人工工时占用等等。
以数字化方式管理运维执行过程，将运维工作的无序转变为有序。
这里有个理想与现实的差异。有不少同学会认为运维工作存在很强的不确定性，领导一句话可能就会完全打乱既定的运维工作，又或者一个突发的故障事件也会让原来正在执行的某个运维动作不得不暂停下来，毕竟保障系统正常运行是第一重要的工作。
基于这种显示情况，我们提出一个任务补登记的流程，由运维人员将临时安排的工作手工补登记到任务系统。
通过任务历史记录，管理人员可以回溯获得以下信息：
1）哪些事件导致了正常安排的运维任务的延期。
2）哪些事件存在周期性触发，应该可以作为计划任务预先安排。
3）哪些任务时间预估不合理，应调整预估时间。
4）哪些任务存在较大的优化空间，应推动自动化平台执行来提升效率。
5）哪些运维人员执行任务存在较大时延，分析能力因素或其他因素。
通过上述的数字化转型，将运维工作任务化记载，为运维工作的迭代优化提供数据分析依据。
B、运维动作自动化执行
运维动作的自动化主要由各类自动化平台承载，通过运维工作任务系统与自动化平台接口对接，将配置在自动化平台的运维操作调度执行实现。
每一个执行动作需要采集执行时长信息，反馈到任务系统用于事后分析，并对存在执行过久的动作程序进行不断优化，提升执行效率。
通过任务系统将原本散乱在不同自动化平台的程序、脚本、后台定时任务整合起来，通过平台的任务流程进行串联执行，并数字化记录完整流程的执行过程，避免运维人员在各种不同平台或主机、数据库检查执行过程和执行结果的繁琐。

C、数字员工实现跨系统连接
数字员工伴随着元宇宙的概念，现在着实是火了。
通过数字员工链接企业各个系统，在不入侵企业原有系统基础上对各个数据资源快速调取和处理；摆脱了系统孤立、数据孤岛的问题，同时规避跨系统操作的风险。
如何将数字员工的理念在实际工作中落到实处带来真实的效率呢？这里给出一些方案给大家参考。
1）任务系统以数字员工身份进入工作通讯工具接收工作安排
这个方案中借鉴了电商系统的智能店小二的能力，打开数字员工的私聊窗口或在工作群中@数字员工时，数字员工回应消息并提供自己能提供的服务清单目录，客户可以选择对应的服务项目并确认执行。
通过模拟实际的运维任务交代、任务执行和任务反馈的流程，实现从工作社群到后台任务执行的无障碍串联。
例如特定需求巡检、空间清理、进程重启等常规运维操作均可以用这样的方式执行，与数字员工的交互过程以逐层服务目录选择方式推进。
当然，也可以通过捕捉自然语言中的关键词信息智能识别任务，需要搭配一定的机器学习算法等应用，在此不过多展开了。
2）任务系统以数字员工身份进入OA平台对接工作安排
在企业内部已有OA系统环境中，可以将任务系统以数字员工身份注册到OA中。
通过OA系统下发的工作安排通过接口传递到任务系统中。通过对OA下发的工作安排的解析（自然语言解析或转排人工），发起任务系统中的任务工单，并在任务系统中工单完结后通过接口回传到OA平台继续流转。
OA系统中应用数字员工的好处主要是实现任务工作的自动流转对接，降低运维人员的人工对接工作量。
对于一些重复性的工作安排，甚至可以在任务系统中部署一些自动化环节实现对文件、数据的预加工处理，甚至某些处理工作都可以全部配置为自动化执行动作，降低人工耗时，提高效率。
例如常见的项目备案、项目合规审计等运维工作，都可以以数字员工的形式提供全流程的自动化执行。
3）监控告警平台以数字员工身份进入工作通讯工具发送系统预警
监控告警平台常规的消息推送形式一般是短信、邮件等，通过数字员工身份注册到工作通讯工具后，更加符合日常的工作交互习惯。避免了运维人员从多处接收信息的繁琐和忙乱。
对于一些重要预警信息和预警恢复信息直接以数字员工身份在工作群中反馈，一方面加快了信息的传递效率，另一方面也可以提升领导对运维工作的感知。
需要特别注意的是，对于数字员工在工作群的告警需要做相应的级别控制和告警合并压降，避免出现告警风暴的现象，影响了故障发生时的正常交流，带来负面效果。
4）运维相关平台以数字员工身份进入任务系统
自动化平台具备了越来越多运维动作的执行能力，一些自动化运维动作已经可以由事件触发。
例如自愈类的切换、重启等，又例如常规的备份清理等，都已可自动触发，这些自动化工作的执行给运维带来了巨大的效率提升，但我们其实很难对其收益价值进行评估。另外，仍有很多能力的执行需要人工判断后再触发。
还有不少的企业内部的信息化建设中，自动化能力是根据不同的需求分散建设在不同的系统中的，如何讲这些自动化能力进行整合，同样是运维团队需要考虑的问题。
我们可以将各自动化平台注册为数字员工接入到任务系统。在任务系统中，各自动化平台可以以任务流程形式串联，将一个个子任务组成完整的运维工作场景，避免的运维场景的零散化。
我们还可以将监控告警系统也注册为数字员工接入到任务系统作为任务派单者角色，使其与自动化操作能力对接，这样也避免了监控告警平台对接多种不同自动化平台的改造工作量和繁琐配置。
最后，通过将各类自动化平台数字员工化，我们可以在任务工时统计时更方便的获得运维工作的人工工时与机器工时的占比，并推动更多的运维工作自动化执行。

第四步，运维成果体现数字化
一个运维周期下来，通过上述的现状量化评估、目标量化设定、过程量化执行，最终仍需要对整个运维过程的改进进行再一次的量化评估。
一方面看初始设定的数字化目标是否达成，也为我们的汇报提供充足素材。另一方面回顾整个运维过程，发现管理上的薄弱环节以及效率瓶颈。
这些数据信息，又成为了下一个运维周期的量化目标。通过一次又一次的目标迭代优化，运维团队的工作将更加趋向完善。
至于运维成果的数字化呈现效果，从最早的报表、可视化展现，到现在很多企业建设的各类领导驾驶舱或指挥中心大屏等能力，无不酷炫，在此不做展开了。

本文作者：李秋霖

本文来源：IT那活儿（上海新炬王翦团队）


分享

收藏

点赞

在看

数据库
文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论