作者简介：郭鸿，泰康保险集团 Jira 和 Confluence 组织级管理员及敏捷教练。负责集团及子公司的 DevOps 落地实施及推广和 TDS（Taikang DevOps Service）平台产品设计，以及集团和分子公司 Jira 和 Confluence 的运营和维护。
郭鸿在6月29日的 Atlassian User Group | 北京站，详细介绍了泰康保险集团基于 Jira 的 DevOps 工具链的实践历程：从引入 Jira 之前泰康保险集团IT遇到的挑战，到为什么要进行工具整合及流程再造，以及集团如何利用 Jira 打造 DevOps 工具链，从而实现研发全生命周期透明化，度量可视化及持续改进以及目前集团的 Jira 和 Confluence的使用情况等，跟大家做了详细的分享。
泰康保险集团 DevOps 的发展历程
泰康保险集团作为一个世界500强的企业，相信大家都知道我们，或者选择过我们的保险产品。泰康品牌的高端养老社区已经在11城落户，泰康的大健康云科技产品在今年的健博会上也有惊艳亮相，泰康集团旗下拥有多家子公司以及大量的合作机构，各个都属于不同的业态，整体都需要集团提供科技赋能。因此IT也面临很大的挑战，传统的IT模式向DevOps转型也成为必然趋势。
泰康保险集团 DevOps 的演进路线：集团从2016年开始进行敏捷转型，主要是敏捷方法论引入和自动化工具的选型和实施。2017年进行了 DevOps 平台的研发，2018年开始做平台推广，2019年开始提供端到端交付的能力及全面推广落地。2019年7月加入信通院发起的企业级DevOps赋能共促计划，将为DevOps社区贡献力量。
引入 DevOps 之前，集团 IT 面临的问题
在引入 DevOps 之前，集团 IT 面临一些实际问题：首先从业务层面来看，业务线快速扩张，比如两年时间从之前的人寿、养老、资产扩张增加了健康、医养、健投等，新的业态导致了业务需求多而复杂，对需求人员的业务分析、产品设计能力要求越来越高。保险产品日趋互联网化，移动化和多样化，对产品的快速交付要求越来越高；业务与技术创新加快，对新技术的诉求越来越多；需求、开发、测试、运维等过程数据分散，对持续交付过程的信息可视化提出了要求。
从工具和流程层面来看，集团原有的工具和流程受到挑战：各类工具非常繁杂，工具之间缺乏互联互通，流程超长。比如从一个业务需求提出需要经过OA、ITSM、RDMS 三个系统，并经过很多的审批节点才能流转到开发负责人手里转变成 IT 需求。需求 - 开发 - 代码 - 构建分别在不同的系统上进行，互相之间连通性较弱。这也直接导致了各环节容易出现黑盒状态，上下游协作不佳，沟通成本较高，最终用户体验不佳。
原有流程反映出的弊端就是需求流转涉及多系统多审批节点导致效率低，开发系统和测试系统没有打通导致开发测试反馈慢，基于前面两个问题必然会出现运维个案多。
泰康保险集团的工具重组和流程再造
为了满足业务快速交付且过程透明化的诉求，集团 IT 决定尝试进行工具重组和流程再造。但是任何变革初期都不能一刀切，摸着石头过河尝试前行，所以集团选择了一些试点项目尝试了基于 Jira 的DevOps 全流程工具链。
比如：使用 Confluence从需求收集到拆解，进行需求内容管理和需求条目化；利用 Jira 和Confluence 关联实现条目化需求到 Jira 任务的转换，然后 Jira 开发任务和 Gitlab 代码直接关联，Gitlab 代码库和 Jenkins Job关联，Jenkins Job 和制品库制品进行自动关联。这样在打通了全链条工具的同时，简化了流程，实现了端到端交付的自动化和可视化。
集团内基于 Jira 优化流程的实际案例
我在这里跟大家分享几个泰康保险集团基于 Jira 的全流程透明化的实际案例：
第一个是我们某个团队的案例。当初这个团队是使用了内部的一个老旧系统需求的收集、评审。具体开发任务是 PM 手动用 Excel 管理。需求评审过程对于业务方不可见，需求和具体开发任务关联缺失，PM 通过线下定期跟开发团队相关人员确认每项任务进度后更新 Excel，然后再手动去系统更新对应需求的状态，非常费时费力！
我在详细了解了团队的具体诉求后，给他们设计了自定义的产品看板，个性化的工作流，和特定跳转的权限，解决了各方透明化的诉求，同时也设计了关联的开发任务板（Scrum板），实现了产品需求和具体开发任务的联动，解决了人肉跟踪和手动更新需求状态的困境。团队每个人的工作都被透明化了，在加强了团队协作效率提升的同时也促进了大家工作效率的提高。
另外一个案例就是针对独立的产品管理团队，由于每个产品经理可能对接多个开发团队。所以产品管理团队负责人如何可视化所有的产品需求？每个产品经理如何快速有效的了解产品需求对应的各开发任务的进度？这里我们就引入了多层级需求管理模式：通过在一个需求下创建多个子级需求，并且划分到不同的 Jira 项目实现了父需求和归属不同项目的子需求之间的层级管理。如果需要产品负责人或者业务方想了解产品需求对应的子需求情况，可以实时查看子需求的进度和负责人信息，甚至可以进一步查看子需求对应的故事或者子任务的进展。进一步提高了上下游之间的协作透明化和高效化。
以上两个案例中可以看到通过 Jira 实现了多层级需求管理，产品需求和开发任务之间的自动联动。
那么测试管理又是如何在 Jira 上面实现的呢？基于敏捷的思路，我们在创建需求任务的同时就会在相应的需求下面创建测试用例或者关联已有的测试用例/测试用例集，测试用例执行之后，可以在需求下面看到每个测试用例的执行结果以及关联产生的bug。因此需求 - 开发任务 - 测试用例 - 测试结果在一个需求界面一览无遗，减少了多个系统之间来回切换导致的人力浪费的同时，提高了信息的连贯性和可读性。
下面大家看到的一些测试报告都是自动生成的，执行情况报告等，用户也可以根据自己的需求生成自定义报表，不过synapseRT的缺点在于不支持测试用例属性的自定义，并不能满足所有场景。
大家看到前面已经通过 Jira 实现了需求 - 开发 - 测试的联通，接下来我们一起来看下基于 Jira 的 DevOps 研发生命周期流程的具体效果。
下图大家可以看到一个需求下面可以拆解多个子级需求到不同的 Jira 项目，同时该需求下面还关联了测试用例，每个测试用例的执行结果以及产生的 bug 都在同一个界面进行了完整的展示。那么重点来了，需求是如何跟 GitLab、Jenkins 关联的呢?大家可以看到右侧的 Develop Panel上有Create branch 和 Create merge request 的按钮，没错，就是通过在需求下直接创建分支到相应的 Gitlab 库来达到和代码关联。GitLab 上的任何提交操作都会反应在相应的 Jira 任务上，构建的结果也会返回。这样就在一个界面上看到了全流程记录啦！
泰康基于 Jira 打造 DevOps 全流程平台
前面讲了这么多，接下来就跟大家一起来揭晓泰康保险集团以 Jira 为源的 DevOps 工具链的神秘面纱吧！整个工具链从需求端到交付端涵盖：Jira GitLab Jenkins pipeline ELK，所有的知识管理通过 Confluence 实现。
Jira 主要是进行需求、开发任务、测试的管理；通过 Jira 和 GitLab 实现需求和代码的关联，从代码提交后的全过程都实现了自动化（比如：构建、代码扫描、自动化测试、单元测试、包管理等），这个自动化过程都是在我们的TDS（TaiKang DevOps Service）平台上实现，平台上所有的日志和ELK（日志平台）平台对接，实现了实时日志收集分析和监控反馈，并且可以通过邮件通知相关人员，后续我们正在考虑 AIOps 和 SecOps，为我们的开发和运维人员提供更加智能和人性化的服务。
搭建工具链，从试点团队的情况来看确实在很大程度上提高了团队协同能力和透明化水平，这些都为过程数据的产出奠定了良好的基础。没有度量就没有持续改进，按照PDCA的原则，泰康保险集团制定了度量指标体系，从需求到发布涉及：交付吞吐率、需求交付周期、开发交付周期、代码重复率、线上缺陷密度、测试通过率、有效bug率，构建失败率、发布频率、部署成功率、故障恢复时长等几十个指标，通过工具链中获取了度量数据，然后通过统一的TDS平台多维度的可视化展示，维度包括：需求度量、测试度量、代码度量、CICD度量等，视图包括：管理者视图、团队视图、普通视图等。各团队也会将度量中发现的问题进行记录并排序，不断的持续改进，并跟进改进的情况。
DevOps 全流程产品选择上的更多思考
目前泰康保险集团已经是 Jira 和 Confluence 的资深用户了，从2013年开始使用 Jira 和 Confluence，从最开始的 Jira 50用户到现在的近5000用户，Confluence从60用户到现在突破8000用户，6年时间持续增长，大家可以明显看到近两年随着敏捷和 Devops 的推广落地用户的迅猛增长。
在集团 DevOps 平台和流程落地之后，我们如果回过头来总结，在最初工具的选择上，我们曾经试用过 Atlassian 全系列产品，包括：Bitbucket、Bamboo 等。从 DevOps 全链条的角度来说，使用 Atlassian 全系列对于用户来说会更加流畅自然，对于运维人员来说会更加舒服。但是当时考虑 GitLab 和 Jenkins 也是主流的开源工具（重点是免费），所以我们当时优先选择了开源工具和 Jira 做了集成打通。
但在后续在实际实施的过程中，我们发现使用开源产品的问题在于需要对集成的开源工具有深入的研究，不但需要付出很多学习成本，而且需要有专人负责开发和维护，用户使用起来流畅性和便捷性稍也比 Atlassian 的原生产品差，特别是开源产品在使用过程中会时不时的遇到各种坑，维护起来也相对费事儿。所以如果从综合人力及时间等成本考量，选择 Atlassian DevOps 全系列产品其实是个不错的选择。
