DevOps 助力数字化管理

上周六1-20号研发教练大会，下午参加DevOps专场，说带来的冲击和思想碰撞有多大，也没有想象中的大，毕竟我们从12年参与构建持续集成的流程和平台，然后一路延着持续交付的目标在推进，到现在我们在参与DevOps的理念、文化、研发转型以及工具链实践，其实没有离开过这个主线，和他们的差距也不大。对于这个主线是什么，我自己这样定义，就是快速、高质量的交付用户价值这个愿景。

ZTE 的DevOps有这样一个观点，DevOps解决什么问题，他们说主要是解决效率问题，这里的效率我解读有几个维度，研发的效率，交付的效率，快速反馈的效率。

现在大家都提VUCA：

就像大会上一位教练所说，我们需要认清这个状况，也拥抱这种状况，但是我们追求的目标一定是不变化的，并且确定的，简单的和清晰的。

关于DevOps的整体框架和理念的实施大家可以看此链接，我觉得说的非常好。

道法术器— DevOps 端到端部署流水线 V2.0

http://mp.weixin.qq.com/s/IA4kygpX36-faxY15cvPlA

我想聊的主要是三方面：

第一、DevOps的全景视图

第二、DevOps的全链路数据

第三、数字化运营助力研发持续改进

对于第一点，全景视图，对于我们这种按项目远程交付的项目如何构建全景，我的观点是全景分段，两段，一是研发到交付物的交付全景，二是交付物到线上运维的全景。此种方式看似反模式，违反了DevOps的基本理念“打通研发和运维的墙”。其实不然，是否隔离主要的一个文化理念和实现落地，是研发和运维的任务和工作是否还是依然独立分离，研发是否在思考产品运维落地，运维是否参与到研发任务中。

第一段：应该是从需求的导入到最终的交付物生成，比如Docker image。使的研发流程能够有一个完整的视图可视化展示研发环节各个阶段，并可视化的展示各阶段的活动和产物。

比如：版本仓库-->代码下载-->编译-->静态检查-->单元测试-->打包-->脚本自动升级-->自动部署-->回归测试-->版本发布 等

第二段，第二阶段主要是从image生成到线上的自动化运维监控全景，版本升级的轨迹、版本的历史、当前节点的所有状态。

对于第二点，全链路数据，现在ZTE在做数据全链路打通和沉淀，他们的DevOps要尽量的对接所有的数据然后对数据进行分析和挖掘。这点对我有不小的冲击。全链路的数据这块在13-14年的时候我们团队就想来做，我们想做的是关于一次版本交付能够有详细的此次版本相关的所有数据，比如：包含多少任务单，静态的代码检查质量如何，变化了多少文件，变化文件的覆盖率是多少，变化文件的单元测试通过率，变化文件的回归覆盖率，新版本的变化对历史功能的影响范围有多大；此次版本交付物有多大，对于按项目远程交付我们需要花费多久时间传递和升级。以及在后期补齐此版本的故障数和散落的范围等数据。全链路的数据一个明显的价值是可以作为一个版本质量的量化评估指标。同样重要的价值是全链路的数据沉淀后为第三点数字化运营来提供基础支撑。

对于第三点，数字化运营，现在都提数字换运营，对于交付的产品有很多工程实践的方法，不管哪种都是以数据为基础，比如A/B test，数据埋点后的各种留存率、转化率等等，都是对数据的分析和在处理，用当前的热词就是对数据赋能。

对于产品我们是数字化运营，对于研发管理现在也都提数字化管理来改进研发管理流程，那研发流程的数据在那里，其实嘴和和有价值的数据应该就落在、沉淀在我们这里持续集成、持续交付到现在的DevOps全链路工具平台中。

也是在13-14年的时候我们团队，我们的项目规划中就开始要做数据的挖掘分析对数据赋能，但一拖再拖，至今未真重意义上开始和落地此项工作。今年我们准备认真思考如何落地和规划这个数据中心的任务，但如何做还没有想好，我们想做一次工作坊，从不同的视角和不同的管理维度来探索数据对其带来的价值，以用户为主体来推动此项工作的建设：

比如，个人关心的代码质量、代码提交次数和代码覆盖率情况。

比如，团队负责人关注的个人提交和构建失败关心，核心模块覆盖率信息，核心模板质量数据

比如，更高层次的考核预警、以及研发流程是否顺畅的预警和标记、哪个研发环节出了问题，如何进行有效干预，等等。

2018，我希望自己能够促成这件事情，做正确的事用正确的做事方法。

借敏捷的宣言的套路，做正确的事 over 正确的做事。

数据还能带来更多的价值，最主要是我们赋予它什么能力。

已经结尾，感觉什么也没有写，说了一大堆废话，这就是我迟迟没有写这个文章之一的原因，希望明年的自己能够看得更加具象、深层次和更加的清晰，就这么多吧。