引言

最近和朋友交流运维的未来发展，很担心在云计算时代下，运维工作缺少价值，替代性太强。我基于这些年在运维岗位的一些思考，和大家说点关于运维数字化转型的分享。

数字化运维

仔细的同学会发现，运维有着天然的数字基因。在数字化转型的大趋势下，运维要拥抱数据。一切皆数据 ！

我从三个方向围绕数字化转型做些阐述：

日志驱动 项目管理 企业架构

日志驱动

日志是无价的

日常运维过程，我们有大量的日志，包括 业务日志，前端日志，后端日志，APM日志，监控数据，安全日志，流水线日志等等。

运维应该思考如何充分利用日志提升运维的价值。

一个基于日志的运维平台

万物皆规则

万物皆规则 日志+规则agent+告警平台，实现：分单，现场快照，诊断分析，动作。

可以参考开源告警规则，针对不同日志开发不同规则告警。像 zabbix, Prometheus, open-falcon都有告警规则设置，也可以看一些开源的规则引擎。

开源告警：

GitHub - bosun-monitor/bosun: Time Series Alerting Framework

规则引擎：

GitHub - kiegroup/drools: Drools is a rule engine, DMN engine and complex event processing (CEP) engine for Java.

一切皆工单

用工厂流水线视角看待研发过程，在流水线的每个环节采集日志，形成对应工单（需求工单，错误工单，告警工单，发布工单，故障工单等），工单最终目的：降本增效 知识沉淀。

错误日志工单闭环系统

1. 系统错误日志+代码提交记录 生成错误工单 推送给研发；
2. 研发确认后进入版本计划；
3. 发布后错误单自动消失；
4. 根据研发线上错误情况，生产绩效数据。

项目管理

运维工作大体两类： 计划性工作+计划外工作。核心目标： 减少 计划外工作占比。

工作皆项目

用项目管理的方式来做运维：把公司当作我们客户，借助项目管理方式，做好 目标、人员、进度、风险和成本 的管理。

项目分类：可以从 KPI提取项目类别，比如：效率提升/稳定性优化/成本优化/架构优化等。

立项方式：随时随地立项，只要可以归属某种分类，就可立项。方式包括自主立项或者推动研发部门作为项目负责人，成员可跨部门。

项目进度：负责人每日关注项目进度情况，识别风险。

减少例外

可以通过下面几个方式：

1. 建设完善的故障处理流程
2. 每日巡检，保证监控和告警系统本身的稳定性；
3. 遵循2/8原则，关注核心业务；
4. 自愈能力建设，通过数据和规则匹配能做部分自愈功能。

故障处理流程：

企业架构

学会用企业架构视角去解决运维问题。作为一个运维负责人，你要知道公司的 业务架构、应用架构、数据架构和基础技术架构。你既要懂业务也要会管理。

懂业务

运维是面向客户的最后一个触达点，必须熟悉业务流程和系统。因此我们：

1. 维护系统架构图；
2. 和业务部门学习并形成业务排错指南；
3. 数据流向如何做

会管理

建议运维都去工厂车间去参观，了解一个物品是如何被生产出来。运维也一样，你把自己当作车间主任，产品研发是一个流水线。车间主任要关注：

1. 目前的吞吐量和生产能力如何？
2. 某个环节除故障时候，如何快速消除?
3. 是否存在瓶颈点，如何消除？
4. 上下游如何高效配合？

个人比较喜欢这2本书：

《SRE：Google运维解密》(（美）Betsy Beyer（贝特西 拜尔）等)【简介_书评_在线阅读】 - 当当图书 (dangdang.com)

《凤凰项目 一个IT运维的传奇故事 修订版》([美]吉恩·金 凯文·贝尔 乔治·斯帕福德)【简介_书评_在线阅读】 - 当当图书 (dangdang.com)

总结

运维部门工作，是公司长期可持续发展的基石。持续保证业务可靠性，是公司业务对外最后的守护者。作为运维从业者，应从公司角度和企业目标去做事情。

最后送一个寓言故事给大家：

两个工人一起在工地里搬石头，很累，汗流浃背。 一位老者过来问之：你们在干嘛？ 一人回答说：在搬石头。 另一人回答说：在修教堂。 十年后: 回答在搬石头的人依然在搬石头，唯一不变的是背有点驮了。 而另一个回答在修教堂的人已经成了一个令人尊敬的牧师了。

运维工作是盖教堂。