这段时间,我一直在思考,为什么运维在高压态势下反而频频出现问题,为什么投入了比过去更多的时间和精力,反而取不到更好的效果,那什么样的运维才是高质高效、现代科学的运维呢,哪一种运维组织架构更适合我们的现状呢,我们未来的路和方向又该如何走,团队需要做哪些调整才能适应当下和符合未来的预期。

一、运维的困境

与过去对比,现在的运维是“强监管,高标准,高要求”。一方面是监管越来越严,重要信息系统稍微“风吹草动”便会受到监管机构的通报与处罚;另一方面是系统数量越来越多、架构越来越复杂,从基础架构到系统、网络和应用都要求从过去的粗放式管理转为标准化建设、精细化管理。

这样,再以过去的技术手段和管理模式来应对,就很难满足要求了。比如:

过去,系统数量少、架构简单,往往是系统管理员“统领天下”一锅管,包括系统搭建、应用部署、版本变更、问题跟踪与协调、故障排查、备份、本地高可用、灾备建设等,但随着系统的数量增多,功能划分变复杂,软件种类多样化,系统管理员就很难深入了解和管理应用相关的问题了。但目前很多应用相关的告警依然由系统管理员跟进处理,然后联合开发使用一些治标不治本的方式处理。时间久了,应用就容易埋下隐患,系统管理员也逐渐变成了一支“四不像团队”、“全能全庸型人才”,表现为专业性不强,专注度不高,什么都知道,但什么都做不深、做不精、做不强,工作内容零散,无法形成系统性与延续性。

再比如,这几年随着移动互联网业务的增长,并发数变大,过去很少出现的基础性能和应用性能问题变得容易被触发,平时技术人员在方面下的功夫少,逐渐暴露出这方面的薄弱和经验积累不足问题。

总结来说,我认为今天运维所面临的“困境”是:基础工作不扎实,专业化、精细化、流程化程度不高,整体联动性较差,金融科技创新能力弱,改革发展速度慢。

二、如何应对

过去我们总强调加大人员招聘,壮大运维队伍,但我认为如果只是单纯的加人,不能有效分析什么岗位应该壮大发展,什么岗位应该加快发展,只会使得人员分配不均,劳动力不能被充分利用。这样时间一久,容易出现干活看不到效果,出不了成绩,员工得不到肯定的现象,最后团队凝聚力不足,人心涣散,工作效率和能动性不高。

我认为未来可以从以下几方面努力:

(一)分工精细化,定位专业化。

目前,数据中心的运维工作中,主要的岗位有系统管理岗、网络管理岗和应用维护岗,其中网络管理岗的工作内容相对专注和纯粹,但系统管理岗和应用维护岗的工作边界容易模糊,这里有几点建议

一是成立中间件组和DBA组。最近,应用出现因中间件性能和数据库性能问题导致业务中断现象,但运维团队中缺少这方面的技术人才,故障发生时不仅拖延了问题定位的时间,事后分析原因也容易陷入被动。目前,我们行已大量引入不同的开源中间件,建议(1)尽早成立中间件组,负责中间件的规范建设、性能指标监控与协助代码调优等工作。(2)推进DBA组的成立,负责数据库规范的建设、性能指标监控与sql语句调优等工作。此两组成员可以从部门内部招揽人才,组织外出培训,逐步壮大。

二是精细化分工,走技术专业化路线。系统管理岗主责:(1)管理硬件设备,包括存储、服务器、光纤交换机等资源的规划、分配、性能与容量监控、调优等;(2)管理操作系统,包括AIX、LINUX、WINDOWS、AS400的系统标准化建设、性能监控、参数调优、版本和补丁升级维护;(3)制定系统上线规范,搭建上线基础环境和部署监控;(4)管理本地高可用和灾备高可用架构,规避单点风险,确保主备机一致可切,掌握并提高快速切换和恢复能力;(5)备份恢复管理,优化备份策略,实现备份验证与快速恢复。(6)故障发生时系统问题定位与快速恢复。这是系统管理岗的基础性工作,目前做得不扎实,还有很多可以提升的地方。应用维护岗主责:(1)应用上线部署、版本变更发布;(2)数据提取;(3)账务数据修改;(4)交易指标、应用性能指标、应用目录空间指标监控;(5)批处理出错跟踪;(6)故障发生时应用问题定位与快速恢复。网络管理岗主责:(1)全行信息网络规划;(2)数据中心网络基础建设;(3)网络资源分配与管理;(4)网络性能监控与调优;(5)网络信息安全防范;(6)故障发生时网络问题定位与快速恢复。

岗位可根据实际情况再细分,比如系统管理岗可设设备管理组、系统管理组。要求各岗位把本职工作做精做优,在夯实基础工作之上,引入提高本岗效率的方法和工具。

(二)以ITIL为核心,强化工单与流程模式。

ITIL的是IT运维服务的最佳实践,结合本人多年的运维管理经验,也确实如此,它把繁琐的运维工作以流程的形式规范起来,不仅可以提高工作效率和团队联动性,还可以量化考核,优化团队职能,推动运维向服务输出型转变。我个人认为目前我们的运维还未形成围绕ITIL流程为核心、以服务为理念的工作思维,各室各组联动性较弱。因此,建议在分工精细化的基础上,我们梳理并设计流程闭环,日常以监控告警为入口,围绕ITIL流程开展工作,杜绝无依据、无流程、无审批的操作和变更,降低生产安全风险。这里以一个事件流程为例:

比如Tivoli监控发出一个“手机银行应用线程池使用率超过80%”的告警,应用维护岗接收后分析原因,必要时请中间件组介入协助分析,将问题反馈给研发,建议研发优化代码、调整参数或申请扩大内存。最后由研发发起服务请求,运维中心根据服务请求提交变更申请并分派工单,执行者在变更窗口执行变更,完成流程闭环,目的是从根本上解决风险隐患。

运维中心领导通过ITIL报表,一方面可以了解各室接收事件、处理工单的数量和效率,优化岗位人员安排;另一方面可以得到各系统的缺陷和修改次数,季度末给各室系统评分反馈给研发中心等。

从监控平台的过往告警来看,纯硬件和系统的事件较少,应用运行产生的事件较多。因此,建议:加快发展、壮大发展应用维护团队,把应用运行过程中存在的隐患或将要发生的风险扼杀在告警阶段。目前,应用维护团队经过几年的发展,依然面临不少困难,包括人员不充足、应用不规范等。但研发与运维分离是监管要求,路再难走最后还是要走,我认为应用维护“宜招旧不宜招新”,只有参与过该系统的研发过程,才能深刻理解各功能模块的运行机制和关联关系,故障发生时才能快速定位,最好的方式是从研发各组抽调一名人员加入应用维护,负责原室管辖的系统应用,人员无法协调安排的,应用维护自身加快团队人员扩充(短期可考虑智融员工),并安排其加入研发各室负责半年至一年,储备人才队伍,逐步接手相关系统,制定规范,从简单的维护阶段开始,待该系统完全符合规范后,全面接手系统应用维护。

(三)建立一二线技术梯队,强化前中后台管理模式。

一二线技术梯队建设和团队精细化分工是提升运维管理水平不同的两种手段,目前我们的运维人员是水平方向的,同一岗位负责内容差异不大,人员不能有效分工,充分发挥差异优势。

建议部分岗位可以尝试建立一二线技术梯队,由缺少经验的新员工组成一线队伍,按照老员工的培训和手册负责一线工作,方向和目标是提高技术水平,积累运维经验,快速响应运维服务;老员工组成二线队伍,充分发挥经验丰富的优势,制定本岗位的工作手册、规范和标准,思考提高效率、效益的方法,学习深层次的技术,响应一线队伍的问题反馈,解决一线队伍的技术难题,给一线队伍提供更优的解决方案。

一二线队伍要求保持沟通,一线把遇到的问题和不合理的地方,向二线反映并提供好的建议,二线协调部门相关人员或技术专家思考解决方案,逐步形成本岗标准和规范。

梯队划分可以适当引入智融公司人员,壮大一线队伍,解决目前运维中心人员不足的现状,由二线人员思考权限与分工控制,部分表现出色的成员经过考核后,可考虑转正式员工,解决招人难、社招人员不熟我行环境的难题。

(四)加强运维管理建设,推进现代运维转型。

我认为,运维应该是一个系统工程,不是简单、零散和孤岛阵营的工作堆砌。我们要坚持“稳安全,强管理”的工作总思路不变,一线队伍守住生产安全防线,把潜在的风险控制在告警阶段,二线队伍要加强运维管理平台的整合与建设,多思考,协助领导提升运维管理水平,最终形成优良的运维文化氛围,做到团队上下一条心,切实提升员工的归属感。确实,我们在管理方面还有很多可以提升的地方,比如ITIL流程的持续优化,Tivoli监控、统一监控指标的细化、完善CMDB建设、改造本地和灾备高可用架构、提高切换演练效率等,相信只有做好这些基础管理工作,我们的运维才能如虎添翼;只有基础打牢固了,我们才有信心和底气建设真正的自动化、智能化运维;只有提高了效率,我们才有精力和能力去面对金融科技日新月异创新的挑战。

郭建滔

2019-11-6

Editing is enabled. Use the "Save changes" button below the editor to commit modifications to this file.