五、丰富的报表统计与分析

5．3版本对报表进行了重新梳理，从任务、代码、测试、构建、部署维度切分，通过跑批，计算数据状态和趋势，做更深层次的分析。

基于上述的一系列报表，以及持续的运营数据，及时得到项目风险提示，指导PMO或项目经理有效干预。

六、非功能特性的集中优化

性能、可靠、体验是DevOps最重要的三个非功能特性，新版本中，拿性能为例，我们并不是那种一味的通过压力测试工具来驱动，个人觉得很多非常规场景下性能问题才容易暴露，所以我们更多的是结合实施情况做了一些定向优化，主要包括：

分布式锁的重新设计：原先锁定时间的固化等，调整成前序可设置，让一些特殊场景可以自行控制，并结合超时、重试等手段解决一些非常规问题

升级序列化能力：这个是原先架构设计的一些原因，序列化这块没有统一，此版本将jsonlib等性能一般的框架移除

修改Jira认证模式：jira的basic认证是我们之前的使用方式，但是在实施中发现其性能远不如session模式快，所以将其替换成了session模式

返回数据量裁剪：尤其在多系统发布流水线上，因为返回数据较多，使得网络占用、前端解析都会有一定延迟，此次对关键API进行了统一review，裁剪冗余信息

配置日志数据存储与保留策略： 平台中需要汇聚来自各模块的日志，并对日志中的敏感信息进行处理，但随着平台的运行，日志的存储会越来越大，且影响界面append展示，所以除了传统运维的一些手段，本次对日志的存储策略、保留策略进行配置控制，可结合实际要求进行保留（其余转历史）

还有像一些报表数据汇集算法、守护进程开关这类调整，不再一一描述

在DevOps5．3版本中，最终形成如下的平台能力矩阵：

二、对研发过程的思考

接着分享下在研发过程中的一些感触，这块没有过多整理，只是将之前遇到的一些问题做了些归纳：

一、团队文化方面，尤其在版本相对成熟之后，对于团队的要求会越来越高，重点体现在产品经理与开发团队身上

产品经理的高要求体现在：

自我学习，版本到了一定程度，不再是简单的对手产品分析就可以制定方向的，更多的是自身的学习积累后的一些思考

时间投入，无论是甲方乙方，负责产品的人事情都相对较杂，如何保证产品需求的不断纳入，是对产品经理的一个挑战，有一些时候，我们甚至发现backlog没有了

取舍思路，产品的缺陷、待优化点会很多，优先级的不断调整则是摆在小团队面前的最大难题

代码深入，可能有些互联网的产品经理更聚焦业务过程，但是对于普元这样的中间件厂商，产品经理越深入技术，则会给产品带来更多的内在进步

开发团队的高要求体现在：

业务的理解，比如前端与后端人员的分离，虽然技能更专业，但对整体业务需求的把握，总体上还是不如以前从前做到后的工程师

开发团队的自我责任感，纯测试团队在乙方会越来越少，开发人员的自测会变得更重要

二、技术能力方面，对产品形态的抽象决定了产品的生命力

开发过程中，我们团队也会抱怨现在的开源软件太多了，每个设计思路都不太一样，甚至同一个开源软件的不同版本都差别很大，使得DevOps这样的产品变得越来越难做。

这一点确实对团队的挑战很大，就拿jira和zentao的集成来讲，将这两者的模型抽象成一套非常痛苦，一个重在扩展（什么都可以自定义），一个重在适应国内项目管控（提供三套驱动模式），类似的工作我们需要很多投入，甚至多遍重构。

三、产品管理方面，传统的流程管理＋迭代的演进思路

我们的每次版本推出，都对我们实施的工程师是一个巨大挑战，新的功能，新的问题。从管理流程上，我们还是保持着修订版＋补丁的方式，以前有一段时间想过快速迭代升级，后来发现这种事情只适合To C，To B基本不现实。

不过我们还是会遵循迭代的演进思路，快速修复，减少版本周期。同时我们在版本的无缝升级上花了很大心思，每次变更（尤其数据字段），都会提供对应的全量与升级两套脚本，使得现在5．2的客户可以快速升级到5．3，工作不难，其实就是一种产品管理与团队习惯（以前看visual studio内部结构时，觉得怎么有产品是这么设计的，3．0版本基本上包含了2．0，1．0的所有独立包，现在终于理解了）

三、下一版本的想法

最后也分享下我们下一版本的主要投入，也希望我们的实施工程师，或者有兴趣的各位，能给予一些建议。

简单说明下已确定的部分：

测试管理之前多数是和其他厂商集成的，新版本会自带一定的支持

自动化测试则主要支持前端自动化以及API自动化

与gitlab、jira等工具的权限做映射管理

提供独立的运维操作台，便于应用运维人员快速编排与一键发布

精选提问：

问1：自动化测试部分都集成了哪些工具，节省了哪些工作量？

答：目前自动化测试工具的集成在我们即将推出的DevOps5．5版本中会有集成；不过在我们之前较多的客户实施案例中，会有不同自动化测试工具或者平台的集成； 至于说集成自动化测试工具节省哪些工作量，这块其实最节省工作量的是提供了多少的自动化测试用例；如果自动化测试用例能够覆盖90％以上的功能，那么每一轮功能测试只需要夜间批量跑批就OK了。

问2：我听说DevOps落地很难，能说下现在有哪些成功的案例吗？

答：目前普元DevOps产品已经在金融、制造业、运营商、高效、能源、保险、电力等多个行业有落地实施经验。

问3：你们的DevOps的最大优点是什么？

答：这个不能说的太多，不然有自卖自夸的嫌疑：

1）全生命周期的支持

2）针对不同客户提供量身定制的DevOps平台适配能力，更能适应企业现状

3）几十个企业级的客户案例验证，对常见的企业级的工具支撑更友好

问4：请问，DevOps5．3产品需要的网络条件必须具备哪些？

答：这个问题比较好；通常客户的开发测试与生产网络是隔离的；针对企业不同的复杂网络模型，我们提供不同的部署方案来支撑。

问5：DevOps5．3在持续自动化方面的能力，目前达到了什么程度？

答：DevOps产品提供了流水线的设计，支持开发流水线、测试流水线、预发流水线、生产流水线，当然可以根据需要自定义不同的流水线；所有的流水线可以自动执行也可以人工介入审批工单；从技术角度来看，目前可以实现一键发布哦（从源代码开始到最终发布到目标环境，比如物理机，虚拟机，容器，多种云平台等）。

问6：DevOps5．3产品的目标，对于交付、运维、微服务应用，目前各自的突出特点在哪些方面？

答：DevOps5．3产品重点关注在运维前面的阶段，对应用的类型无论是微服务还是传统架构，无论是移动应用，还是其它语言，比如C、Python等，都提供了CICD的能力。

问7：DevOps新平台在应用扩展和部署方面有什么好的解决办法？

答：DevOps平台在设计的时候充分考虑了平台的扩展性，可以支持多种类型的编译工具（Maven、Ant、Gradle），在应用类型方面也没有限制，可以支持多种应用类型的接入，部署支持多种异构基础设施（比如物理机，虚拟机，容器，多种云平台等）。

问8：咱们研发团队在开发DevOps5．3或其他软件时，使用DevOps的思想或者工具了吗？

答：我们一直在吃自己的狗粮哦。DevOps5．3的版本就是通过DevOps平台进行项目、需求、CI、CD、流水线的管理的。

问9：Devops对业务流程集成方向是如何把控和处理的呢？还有数据集成。

答：这个确实是个很难通用的工程，目前产品中流程内置较少，这个我们是指企业的实施中不断补充的，平台本身并不想内置太多传统流程的工作，因为这个在企业一般都有系统已经在运行，我们只是给了很多回调接口，以及事件触发机制，便于集成。数据的集成则是视流程来定，以及实时要求。我们还有个想法就是做一些行业的流程模板，比如金融的，我们就有了些总结。

问10：什么样的企业需要DevOps？DevOps能带来什么价值？

答：有一定规模的IT团队就需要DevOps； DevOps带来最大的价值，是先实现IT部门或者IT团队的数字化转型；当然对业务来讲，可以快速试错，快速推新业务，抢占市场啦。