运维绩效考核难题怎么解？这份方案帮你理清思路
常被诟病的是运维团队, 其存在“功劳看不见、苦劳全都算”此种状况。系统达到稳定运行属于常态, 而事故才是被予以关注的关键节点。当HR展开制定运维考核方案的工作时, 核心矛盾在于: 怎样将“不出事”所具备的价值予以量化, 与此同时还要防止员工仅仅进行被动的一些响应罢了, 以及对主观主动的种种优化有所忽视这件得以落实。需要涵盖既技术质量、又服务意识以及还成长贡献这三个维度的情况, 才会是一套合理的运维绩效考核体系, 要让考核切实真正能够去把业务进行驱动, 而不是对团队士气造成消耗这样才行。
指标设计要分层，避免单一数据导向
运维工作存在特殊性, 这就决定了没办法用一个数字去衡量全部产出, 这种情况表示建议采用“结果指标 + 过程指标”的双轨制, 其中结果指标重点在系统可用性、平均故障恢复时间MTTR、核心业务SLA达成率上, 而过程指标包含工单响应及时率、变更记录合规率、巡检覆盖率。在权重分配那里, 技术稳定性类指标给出的建议占比是50%至60%, 之所以这样是为了防止员工为了追求数字而去掩盖隐患。某些部分公司, 曾有情况发生, 即运维工作者, 因惧怕致使可用性数据降低, 进而隐瞒故障, 出现了相关案例, 最终导致酿成更为严重的事故, 这样的教训, 值得予以警惕。
引入服务评价维度，打破技术壁垒
服务内部客户是运维的本质所在, 纯技术指标会致使团队偏离业务场景, 提议纳入来自业务部门的服务满意度评分, 权重的设定范围为20%至30%, 问卷设计要着重于可感知的服务质量, 即故障通报是否及时, 沟通是否专业, 问题是否被彻底解决。与此同时, 可设立"业务支持贡献度"专门加分类目, 例如协助业务上线新功能, 参与需求评审并给出可运维性建议等 , 引导运维人员主动向前, 而非被动等待工单。
对于运维这个岗位而言, 它很容易出现技能方面的天花板, 而长期进行重复性工作的话, 会把积极性给消磨掉。在考核方案里, 应当留存10%到20%的弹性空间, 用来对团队建设以及技术改进情况做评估。其中, 能够进行量化的一些维度有: 主导或者参与自动化脚本开发数量, 沉淀进运维知识库的条目数量, 向跨团队进行技术分享的次数, 考取专业认证的情况。要是一名员工连续两年在成长维度上表现很突出, 那么在进行晋升或者调岗的操作时, 应当优先把他纳入到考评的考虑范围, 这种做法相较于单纯地比拼故障处理速度, 更有助于留住核心人才。
差异化考核不同运维岗位
对于开发运维、网络运维、安全运维而言, 其每一项工作的着重点都是区别不一的, 要是用同一套指标去涵盖, 必定会致使结果失实。故而建议在具备共性的指标之上, 设置专门属于各个岗位的模块。就好比安全运维, 需要着重强化漏洞修复的时效以及安全审计的合规率；网络运维则更偏向于链路冗余率以及拓扑变更的成这些方面。当HR在推动相关方案落地实施的时候, 应当与各个部门的负责人一同去确认岗位权重之间的差异, 从而构建出一种“基础盘+自选盘”的考核结构, 以此来保证公平性与适配性能够同时存在且得到有效兼顾。
