一、体系建设目标
查阅了大量资料，也没有到对“运维体系”的明确定义，大多数资料对运维体系的解读及建设方案都是基于ITIL认证体系与Google SRE，通过一系列的制度、标准、规范及流程，辅以高效的IT管理系统，向用户提供高质量的运维服务，保证系统的可靠运行。 基于对ITIL及Google SRE的理解，部门的运维体系建设目标可以确定为：以积极、负责、严谨的工作态度，正确、高效、规范的工作方法，保证系统7*24小时正常服务，全心全意为客户服务，让客户满意。 二、运维现状分析
随着部门研发的产品日趋成熟，系统的复杂度日益提升，主要体现在业务功能增多、业务流程复杂、业务组件多且依赖关系复杂、系统硬件数量多等，导致整个系统运维的工作量及难度均大幅度增加。运维做了很多的工作，却依然保证不了系统的可靠服务能力，并不能完全满足来自公司内外部“客户”的运维服务要求。通过运维团队内部的讨论与分析，发现运维工作提升困难的主要原因与其所处现状息息相关，主要存在如下亟待解决的痛点：
1)运维人员的技能参差不齐，深度不够，专业化不足；
2)运维人员分工及职责不明确，要求全栈运维，工作上出现相互推诿、拖延；
3)运维操作随意性强，容易出现疏忽与失误，导致系统事故；
4)运维服务接入点不单一，任何运维人员都可以接入服务；
5)运维工作范围繁杂琐碎，出了问题就有责任，有失公平，影响团队成员的积极性； 6)运维对问题的复盘分析不够深入，运维质量改进缓慢；
7)大量的硬件资产缺乏全面细致的管理，不能做到全生命周期管理；聚酯丙烯酸酯
8)大量的业务系统，全手工运维与巡检，耗时耗力；
9)缺乏全面的系统监控手段/系统，不能及时发现系统中的问题；
10)业务系统复杂度高，运维还没有完全了解业务系统的功能及依赖关系；定心支片
11)业务系统质量低、可靠性差，导致升级变更的工作量超大。
以上并不是全部的问题，这些问题均不是一天两天形成的，有很多历史原因，在此就不再详述了。但
是如果不解决这些问题，运维团队将会继续维持低下的工作效率，运维工作质量也得不到改善。为此，我们需要对症下药，借鉴他人的优秀实践，结合我们自己的实际情况，建立科学、高效地运维体系，以解决所有上述的运维工作中的痛点，提升运维工作效率及服务质量。
三、体系建设规划
通过调研大量的资料，并根据运维现状、资源投入等实际情况，提出了“五化一库”的体系建设规划，即“分工专业化、工作精细化、服务流程化、操作规范化、运维自动化、运维知识库”，逐步提升运维工作的效率与质量。
3.1分工专业化
目前，运维人员就像是 “全能骑士”，即要懂业务，也要懂硬件、网络、安全、架构等多方面的知识与技能，人人都需要是全栈运维工程师。的确存在这样的能人，但是毕竟是少数，大多数的结果是“广而不精”，各方面都知道皮毛，遇到问题了不到根本原因，对运维工作的质量及效率均有影响。因此，在本运维体系中，计划将运维人员按运维工作内容进行专业分组，分为基础设施组、网络组、平台组、业务组及安全组，如图 1所示。 建筑隔墙图1 运维团队分工及职责
通过专业化分组，可以让运维人员在其所负责的专业上做全、做深、做强，各个专业小组有相对独立的、明确的工作内容、职责及标准，计划编制《岗位职责说明书》进行详细地定义与描述。各个专业小组的负责人要想尽一切办法保证自己所负责内容的质量。
倍速链组装线
在实际操作上，考虑到运维人员数量少的情况，可以一个人参加两个小组，形成主备关系，但是在同一时刻只存在一位负责人，只有当主负责人由于请假等原因不在岗的时候才由另一人临时顶替其工作。同时，为了扩大大家的技能广度，制定“轮岗计划”，计划每两个月进行一次专业小组（安全组除外）轮换，让所有运维人员都有机会负责所有专业小组。在日常工作期间，各个专业的负责人要进行培训分享，为其他团队伙伴进行轮岗提前做知识储备，也利于大家逐渐具备值班处理问题的能力。
在专业化的分组模式下，可以有效地让运维人员提升专注，减少琐事的消耗，提高工作效率及质量。各专业小组的工作内容相对独立，但是也需要相互协作，共同完成整个系统的运维，因此，将梳理各项工作的执行流程，将各专业的工作有效地组织起来，做到统筹高效。
3.2工作精细化
当前的运维大多时候可以说是“面向整体”的运维，关注最终结果是否正确，比如系统各项功能正常、各项指标正常即可，只有在出现异常的时候，才会去分析细节，具体的原因。平时对系统的各个局部与细节的关注度不够，导致很多的问题不能及时发现，造成不必要的损失。因此，运维计划通过体系建设细化各专业的具体工作内容，将每一项工作内容都写到《岗位职责说明书》中，做到全面、无死角的运维。
运维的工作将不再仅是面向整体，还将面向局部、面向细节。通过专业化的分组，将整个系统运维拆
分成不同的部分，各个专业小组还将就各自负责的部分进行更加细致的梳理，明确所有的配置项（需要关注并维护的对象），做好配置管理与变更管理，做好日常监控与维护，做好容量规划管理等各种精细化工作。
泥浆泵压力传感器
3.3服务流程化
目前，运维的工作范围有生产系统运维、开发测试协助、售前支持、售后支持、信息安全管理等方面的工作，除了生产系统运维外的工作，各类繁杂琐碎很多，公司外部客户、公司内部的同事均有可能提出运维服务需求，提出需求的渠道也很多（如QQ、、邮件、电话、当面沟通等），而且直接到运维人员，没有统一接入各类服务需求的“点”，因此，各类需求分散，没有根据工作安排及人力情况进行综合安排与调度，导致运维工作“杂乱”，运维人员成天“忙碌”，但是工作效率却非常低下，亟待进行改进。经过分析，计划通过“建立运维服务台及运维服务流程” 的方式对运维服务进行流程化。轴套与轴承
1) 建立运维服务台
制定《运维服务管理规定》对运维服务进行规范化管理，统一运维服务入口，引进工单系统。所有的运维服务（如：问题处理、事务性工作等）均通过服务台统一接入，由服务台值班人员创建工单，如果是问题则派发给相应专业小组负责人员进行处理，如果是事务性工作，则转发给运维组长进行统一安排调度，如图 2所示。做到“不见工单不处理问题”，以便对运维服务工作进行全面的跟踪及有序地组
织实施。
注意：运维服务不区分公司内外、部门内外，对于运维团队外的所有对运维的需求均视为运维服务，均需要通过运维服务台统一接入管理。
图 2 运维服务台主要服务流程
2) 建立事件/问题处理流程
前面提到了运维服务台的大致工作模式及流程，但是具体要把服务做完还需要更多的人参与，更多的流程与分工协作。为了保证整个过程有序开展、资源合理配置，需要协同开发组建服务团队，分层级逐步处理，一层一层上升，直至问题最终解决。大致的流程是：需求方提出需求 →服务台创建工单→分派给一线人员（值班人员）处理→转交给二线人员（各专业负责人）→转交给三线人员（相关开发人员）→管理者。任何一个环节将事件/问题处理掉就可关闭此工单，否则逐级流转与上报直至工单最终关闭，问题得到解决。
3) 建立事务性工作处理流程
除了事件（或问题）处理，还有各种事务性服务需求，这类需求将转交给运维团队的小组长统一安排调度。在专业分组过后，一件事务性工作，可能需要各个专业组相互协作才能最终完成，其协作流程并不能统一，运维团队将周期对各类事务性工作进行总结与分析，出主要的（频次高且需要多专业协作）的事务，制定标准化的处理流程，以保证这些工作有序开展并保证质量及效率。
3.4操作规范化
长期以来，运维的操作事故没有得到有效的控制，缺乏严格的审批流程，没有明确的管理制度，各种变更操作随意性强，运维工作无章可依，无规可循。因此需要制定运维操作的相关制度、标准、规范及流程，做到变更管理与配置管理等运维操作的制度化、标准化、规范化与流程化，让运维的工作有
章可依，有规可循。
1)制定变更管理的制度与流程
各个专业均会遇到变更需求，对这些变更必须进行管理及控制。首先所有变更必须进行记录，可以通过“工单系统”或“任务管理”进行追踪，做到全生命周期管理。对所有的变更进行分析，根据复杂度、影响范围及程度、风险大小进行分类，设置不同的审批级别，如：对系统有严重影响且风险较高的必须由主管领导进行审批，简单且风险小的可直接授权执行人员进行实施。
对于事件或问题导致的变更，必须同时符合《事件/问题管理规定》与《变更管理规定》的要求。运维对事件或问题要进行复盘与分析，出主要的变更点及关联问题，制定《应急预案》并在其中明确其变更的审批要求及授权说明。
2)制定配置管理的制度与流程
配置管理即配置项管理，配置项即为“需要关注并维护的对象”，硬件如服务器、CPU、硬盘，软件如业务软件实例、软件配置参数等。凡是需要进行关注并维护的对象，均可以是配置项，均可以纳入配置管理的范围。
配置管理将通过CMDB进行管理。不同的配置项，有不同的属性，通过数据库建模将其纳入到系统中
进行管理。配置项也常由于各种原因的变更导致变化，我们也需要跟随这些变更同步更新配置项，同时记录变更的细节，做到变更的全生命周期可追溯。
配置管理需要符合《配置管理规定》的要求，所有配置项的变更不独立进行，而是与“工单”或“任务”关联起来，必须有变更依据（或变更来源），符合变更管理的各项管理规定及审批流程，避免或降低操作失误。
3)制定运维操作的通过标准
制度及流程保证了运维操作的有序执行及有效控制，但是没有解决运维工作质量保证的问题，因此，需要对每一项的运维操作或每一个操作组合确定其通过的标准。运维将对于各类运维操作进行分析，出关键控制点（如重要的功能点、配置项或容易疏忽的点），制作出《检查清单》，由操作人员或指定专人执行检查，确保结果准确无误。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议