泰康保险集团基于 Jira 打造 DevOps 工具链

泰康保险集团 DevOps 的发展历程

泰康保险集团作为一个世界 500 强企业，旗下拥有多家子公司和大量的合作机构，各个都属于不同的业态，整体都需要集团提供科技赋能。因此 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板），实现了产品需求和具体开发任务的联动，解决了人肉跟踪和手动更新需求状态的困境。团队每个人的工作都被透明化了，在提升了团队协作效率的同时也促进了大家工作效率的提高。

另外一个案例就是针对独立的产品管理团队1因为每个产品经理可能对接多个开发团队，所以产品管理团队负责人如何可视化所有的产品需求？每个产品经理如何快速有效地了解产品需求对应的各开发任务的进度？这里我们就引入了多层级需求管理模式：通过在一个需求下创建多个子级需求，并且划分到不同的 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 全系列产品其实是个不错的选择。