网络Devops探索与实践 流程管理分析师
https://mp.weixin.qq.com/s/OKLiDi78uB8ZkPG2kUVxvA
网络Devops探索与实践
老的开发模式这样会出现多个问题：
-
最常见的一个场景：开发这边的排期已经到2个月之后，运营这边觉得太晚了。但前面确实有那么多开发需求待实现。开发搞不过来了。
-
某些新的监控项目，运营通过具体的数据才能知道该功能的业务价值；开发的同学把功能上线后，就忙着下一个需求了，对后续的运营关注不多。经常会导致历史上积累了非常多的工具系统，但作用都很寥寥。
-
基础架构的运营系统，原来只针对自研业务做了大量的功能；后来到公有云，现在也有大量的私有云客户，服务的对象发生了变化。外部的客户对功能需要做二次开发，需要具备Devops能力。
为了解决以上这些问题，需要系统化的来进行解决。根本上来说，就是要以人为本，提升运营与开发的满意度，Devops是一个切实可行的方案。、、
Devops没有发明任何新技术，他只是一种软件开发的模式。这里有个Devops的分级模型，是国内业界的前辈制定了一个规范，最近也已经通过了ITU-T组织的审核。这里内容比较多，不逐一赘述。基础架构Devops的实践过程，是借鉴其理念，让大家都在同一个简单易用的软件平台上进行合作开发，达到服务快速上线目的。其中最主要的一个关键点就是双方要进行融合，互相促进。
腾讯的网络运营先后经历人工操作、工具脚本、自动化等这几个阶段。运营团队，就是我们熟悉的网工，过去都有专业的开发人员来进行配套的工具系统开发。在过去几年，网工们的开发能力持续提升，在Devops平台的加持下，已经掌握了通用的开发能力，一些运营过程中需要的功能，可以基于Devops平台自行开发了。这样，传统的开发人员和网工，都可以基于这个统一平台来“吃自己的狗粮”。运营人员自行开发功能，上线后出现问题，反查自己设计的业务逻辑；开发人员主导开发功能发布后，出现了bug，也自己定位代码或者平台的问题。这样，发现问题后，都先从自身出发来排查，减少了互相埋怨，大家的关系也相对融洽起来。
如何建设Devops平台？
我们把建设的过程分以下6个方面来介绍。
1、上层规划 – 运营事务流程化
无流程不运营。我们在内部先把这个意识先进行了统一，这个是Devops开发的前提，也是Devops任务可编排的前提。我们经常说可编排，编排完了之后，不就是由一个个编排后节点串接起来的流程吗？下面跟大家介绍下我们内部总结出来的流程成熟的模型。初步评估，腾讯基础架构运营处在level 3这个阶段。怎么解读呢？
- 流程体系化，是指我们各个运营业务基本都有了对应的线上流程。几乎不存在线下操作的场景了。
- 部分的流程完成生命周期管理，这个是对流程控制端到端的一个需求。
- 较为完善的OLA/SLA管理，有了详细的OLA数据，我们就能对每个工单的实施过程都能详细的分析和管理。
- 工具系统敏捷迭代，系统工具除了能直接解决业务的需求，还要有二次开发的能力。
在系统架构顶层设计方面，我们使用DDD—领域驱动设计的模式，具体到Devops平台，着重领域层的实践。把Devops的整体功能模块分为四大块：
- 可视化编排平台 – 这个是运营事务流程化的具体落地方式。流程图让业务逻辑可以非常直观的展示出来。
- 应用管理模块 – 方便用户参与开发。SDK的方式，是开源共建的基础，减少了大量重复代码；权限管理，有效避免了用户之间的互信影响。
- 数据运营模块 – 数据化管理。流程及工单数据每天都会以非常大的量级增长，没有完善的任务超时告警及运营数据自动收集分析功能，后续的业务维护会非常耗时耗力。
- 平台管理 – 是系统运维的重要窗口。让人人可运维成为可能。
2、业务逻辑 – 无代码化开发
无代码化开发，并不是指一行代码都没有。而是尽量减少编码的场景。在很多模块中，Devops平台把设备命令模板层、业务函数、业务流程及触发规则等这四个层次，都用对应的模板或SDK封装起来，形成可复用的逻辑。这里列举的是命令模板这一层的封装。对于运营人员来说，在Devops体系的驱动下，开发能力逐步提升。同时，通过配置化或少量的代码，可以用极低的成本，快速开发上线验证类的功能，不需要任何专业开发资源投入，大大较少试错的成本。
3、Devops的生命周期管理
这里是从Devops开发的新模式出发，把过程中需要配套的功能点逐一进行完善，从而完成了Devops开发整个生命周期的管理。
1）需求管理。对需求进行建模，把功能点往各个预分配好的领域靠拢，避免功能碎片化。在腾讯内部，有TAPD工具对需求做详细跟踪，保证落地效果。 2）开发环境。这个是参与Devops开发同学最关心的地方，直接关系到开发效率。主要涉及环境统一配置、代码版本管理、测试覆盖及CI/CD等环节。 3）流程管理。事务流程化后，会产生非常多的流程，流程图需要方便创建及修改；其次在工单建立后，会马上实例化，任务执行过程中的异常超时基础配置需要在OLA/SLA中进行配置。 4）任务管理。具体事务的操作，更多的是调用第三方接口和对设备进行查询操作。需要全程对任务的执行过程进行跟踪，其次需要把可以复用的代码通过SDK有效管理起来，避免重复开发。 5）运维管理。这块是整个Devops平台的后腰，保证系统的正常运行，以及出现问题后快速恢复。
4、可维护 – 产品化的控制台
提供便于Devops应用开发和运维的WEB控制台，旨在通过页面可视化以及页面可操作的手段，提升开发和运维效率。在过去，我们讲的D/O分离是指开发与系统运维的分工。在Devops时代，运维工具不但面向专业开发人员，也需要面向业务开发人员，让大家在同一个控制台中发现问题、定位问题。在运维底层功能方面，我们把流程实例管理、任务管理及控制台的功能，按不同的角色进行开放。本着谁开发，谁负责的原则，大家一起共同把系统平台及业务功能模块的可用性维护起来。
5、认证管理 – 建立岗前认证培训体系
Devops是一个以人为本，回归人性的一种开发运维文化，其效果体现更多的是在于人，在于从业人员能力的提升，更注重开发人员的感受。所以，在内部有一个Devops的认证体系，经过这个体系的培训，可以让一个小白用户从零开始逐步上手。这个培训体系主要分为四个步骤： 1）开发知识基础。主要是学习开发环境、代码管理及代码检查一些基础的知识。 2）Devops功能开发。这个是按照基础架构运营功能的特点来展开的，主要的内容包括需求的提炼汇总，把运营需求用流程图的形式展示出来，然后进行任务节点的逻辑代码编写。 3）demo实战。经过以上两个阶段的学习，这里可以开始动手了。 4）经过一系列培训，通过考试后，对学员颁发证书。并根据不同的能力水平，证书也会区分一级、二级和三级。
6、最差实践 – 坑点
我们的题目叫“最佳实践”，但这个过程并不是一帆风顺的，过程中经历了非常多的挫折与不理解。我们把这些因为考虑不完善而踩坑的地方总结了几个最差实践。
第一方面就是主要功能点缺乏，用户使用满意度不高。
1）尝试去优化某个具体的环节，而忽略了全局优化的可能 前期缺少顶层设计，举个例子，我们之前一直以为画流程图是用户接触Devops系统的第一个界面，是业务需求转化的第一步。就千方百计的把画流程图的界面进行优化。但用户在画完图了后，后面就很少会关注了。
2）产品化不够，用户使用不够友好 一个功能完备的Devops平台就跟建设一座城市或一个小区一样，有太多的功能点需求开发。SDK的合入规则，云函数的调用方式等等。这些专业的开发技能，对于传统的开发同学来说，大家交流起来是很顺畅的。但对于运营同学，要跟大家解释就显得比较费劲。
3）研发效能低下 本地开发环境无法与线上环境保持一致，调试困难。还有业务代码逻辑的经常需要线上调试，测试的覆盖率长期偏低，功能稳定性无法保证。还有bug定位跟踪的方式比较单一，一个bug需要分析半天才能知道问题点在哪里。 第二方面是过度设计，没有使用户真正获益。对于Devops的深入程度，有一点我们必须牢记，那就是Devops平台系统本身的成功并不是真正的成功，只能是业务的效率提升，使用Devops的用户满意度提升了，才是检验成功的唯一标准。
罗马不是一天建成的，这个Devops平台凝聚了腾讯基础架构运营多年的经验。之前我们谈的自动化及数据化运营，更多是端到端的传统开发方式。具体到Devops，我们希望可以打造一个生态，可以跟众多的合作伙伴和外部的用户一起，一起在同一个平台上进行功能完善和迭代。
在接口对接方面，近期我们跟很多运营商及设备厂商一起努力，把报障、割接、还有case管理、备件管理等几个使用频率最高的场景进行了线上对接。在外部用户方面，我们通过腾讯云的窗口，把Devops的能力对外进行的开放。使用的用户越多，发现越多的问题，devops平台的功能就可以越趋完善。
