写点什么

单独的问题跟踪工具带来的分裂影响

2017 年 5 月 07 日

本文要点

  • 在如今以持续服务交付和运营为主流的世界中,团队之间的协作需要比以前任何时候都要更加紧密。开发和 IT 运营团队有自己单独的问题跟踪系统可以为团队带来了便利,但从整个组织层面来看,这样会带来冲突,影响效率。
  • 由代码或架构缺陷引起的生产环境的 incident 如果存储在开发团队无法访问的问题跟踪系统中,可能会出现修复不完全的情况,因为开发团队不知道具体信息和修改历史。
  • 另一方面,如果把开发的工作项目存储在 IT 运营团队无法访问的工具中,通常会导致匆忙部署而无法满足任何操作标准。
  • 让开发人员可以看到生产环境的 incident,让 IT 运营人员可以看到目前开发中的变更细节,可以促进早期反馈,更有效地实施 DevOps。
  • 如果单个工具可以同时支持开发团队和运营团队的工作流,并能解决跨团队问题,那么它就是一个可以减少团队摩擦、提升重用性、促进信息共享的理想方案。工具需要有较低的访问门槛,具有基于浏览器的界面和可用于自定义集成和生成报告的 API。

在许多组织中,开发和 IT 运营的问题跟踪系统都是分开的,这是造成冲突和无效工作的根源问题之一。要想实现有效的变更管理,尤其是数据库变更,我们需要共享问题跟踪系统,这样运营团队可以看到开发团队要做的工作,开发团队也能从生产环境中看到现实服务问题的细节。

综述

负责开发数据驱动软件系统的团队如果能改变跟踪问题和工作项目的方法,他们就可以更加有效地工作。

使用不同的工具已经逐渐演变为团队之间无法跨越的墙,这就是为什么使用不同工具来跟踪工作或缺陷的团队很难一起合作。相反,开发团队和 IT 运营团队(包括数据库管理员)需要使用同样的工具,或至少能够通过共同的界面查询横切(crosscutting)信息。

由代码或架构缺陷引起的生产环境的 incident 就是一个很好的横切面例子。如果这些 incident 存储在仅由运营团队能访问的问题跟踪工具中,开发团队就会错过 incident 的内容和修改历史。经常会发生开发团队进行了修复,但是并不能完全解决问题的情况,因为开发团队只知道有“什么”问题,但不知道“为什么”有问题,以及问题是“怎样”发生的。

另一个例子是经过计划的数据库变更。如果这种工作项目存储在运营团队无法访问或了解到的敏捷板上或项目管理工具中,他们就不会知道有这样的变更。最后的结果就是由于产品或营销团队的施压,匆忙部署数据库变更,导致无法满足运营标准。

简单来说,问题和工作项目跟踪系统需要有较低的访问门槛,具有基于浏览器的界面和可用于自定义集成和生成报告的 API 比较理想。浏览器界面提升了可访问性并且便于使用,API 帮助在交付周期中整合问题跟踪,比如说开发人员可以通过提交并评论预定义的模式,如“Fixes issue #4”,将一个问题设置为“已修复”状态。

避免“每个部门一个工具”

由于许多组织允许每个部门选择自己的问题及工作跟踪工具,他们失去了让开发和 DBA 或运营团队使用相同工具的机会:开发团队通常会使用与版本控制集成的轻量级工具,但这些工具往往对生产环境的 incident 支持得不好,而运营或 DBA 团队倾向于选择服务管理做得出色的工具,但几乎没有提供对版本控制集成的支持,或是对敏捷和迭代软件开发的支持。结果就是信息难以共享,DBA 或运营人员很难和开发人员合作。

如果不阻隔知识共享,通过公共的门户或界面至少可以查找到任务和问题的跟踪信息,就可以让开发人员看到生产环境的 incident,而 DBA 也可以看到当前正在开发的数据库变更的详细内容。

无论你用的是哪种工具,请确保知识和问题能及时共享,并且能配置好工具来促进不同团队之间的合作和沟通。

具体来说,沟通是信息共享的前提。不过可惜,工具只能存储信息,它们不能代替人进行沟通。也就是说你需要某些(轻量级)的过程,在开发团队和运营团队之间识别并交换相关的信息。

查询

问题跟踪系统可能有几十个甚至几百个处于开放状态的 ticket。已经关闭的 ticket 每年可能会有几千个。怎么才能确定有哪些相关 ticket 呢?

从运营到开发

让我们来看看开发团队怎么查询到运营部门的 incident。

通常来说,运营团队需要处理跨多个系统或服务的 incident,然后将每个 incident 指派给一个开发团队。所以首先需要在 incident 中说明清楚这个问题影响了哪些系统。

当然,你也可能碰到几十个 incident 牵扯到同一个系统。一种可能的解决方法是添加自定义字段,确定系统的哪个组件直接受到了影响(数据库、后端、前端等等)。另外一种更直接的方法是添加自定义字段“由开发审查”,之后这个 incident 就可以由问题提交者进行核实(或者,如果可能,任何可以访问该问题的人员都可以进行核实)。

另外,如果运营部门的一个问题派生出一个或多个需要由开发部门修复的问题,那么可以直接把原始问题链接到这些子问题上。这里可能会发生的问题是,有一些问题或许不需要代码变更(但仍然与开发部门有关,比如说运营团队附加了一个从集中式日志系统(如 ELK )里获取的日志),或许需要很大的变更,一个问题中难以完全描述(比如说重新架构应用程序,提升某些负载下的低下性能)。

从开发到运营

在瀑布模型开发任务中,如创建新的数据库或添加新的字段是很常见的。然而,被拆分成用户故事或特性,它们跨越了栈(“垂直切片”)的所有层次。

这就给DBA 造成了问题,例如他们不清楚一个故事是否需要数据库变更,需要进行多大的变更。

你选择的工具需要提供一种简单的方法来确定故事牵涉到应用程序的什么组件,可以通过标签、自定义字段,或更进一步,与你的代码控制系统集成(比如,自动链接到评论中引用了这个故事的提交)。

另一个选择,类似于“从运营到开发”,就是将牵涉到重大数据库变更的故事标记(或通过其他任意方法识别出来的)为“DBA 审核”(提示:对于重大数据库变更的定义需要开发人员和DBA 一致协商同意)。

沟通

在存储了信息之后,开发和运营团队可以查询和定位到问题。但这不是说团队就可以马上开始采取行动。

另外,审查问题的时间不可忽视。请DBA 定期审查开发团队中可能会影响到数据库的项目,当DBA 在定期处理生产环境中的问题时,他们可能不太愿意这样做。

由于我们想要通过提供即时的反馈来保证信息的共享,一个简单的方法就是促进开发团队和运营团队之间的定期会议(实际参与者可能会不同)。这能保证人们能腾出一段时间来促进信息共享,这也为团队提供了一个澄清问题的机会,他们指出了繁忙的部署和incident 工作流中可以改进的部分。

不过请不要将这样的会议变为变更审核,会议的目的是促进不同团队之间的互动,而不是采用新的手段部署变更。

双方团队成员的事先准备很重要,尤其是在最初阶段。每个团队都需要预先准备好另外团队需要审核的问题,且按照重要性降序排列。详细描述每个问题的重要性,需要计划或实施什么变更,会影响到什么系统等等。

我们也建议限制会议的时间,以及用在每个问题上的时间,避免时间的浪费,也避免过于详细地讨论一个问题(如果有必要,可以在会后再安排时间讨论这些问题)。

最后,确保你不仅仅在解决问题本身并做出改进,你还要反思整个审核过程。审核是否有效?你是否提前发现了问题?团队成员是否更加了解对方的工作流?是否了解工作对其他成员产生的影响?你审核问题的时间是太多还是太少?如何改善?

一旦你觉得这个过程运行地很成熟之后,可能会想对其中的一部分进行自动化(当然需要所有参与的团队都同意)。比如说,DBA 可以到某个数据库定义文件变更的通知,参与开发和维护的系统如果出现问题,开发人员也可以收到通知。

工具推荐

使用现代化软件交付方法(比如持续交付)进行问题跟踪的实用工具之一是 Atlassian JIRA ,JIRA 拥有优越的第三方集成,可以通过 API 进行编程,而且可以方便地为不同团队(Agile、Kanban、服务台)配置不同的工作流,避免了常见问题:“每个部门一个工具”。

JIRA 为开发团队设计的 Kanban 界面

JIRA 为 IT 运营团队设计的服务台界面

JIRA 集成了服务台和以开发人员为中心的 ticket 工作流,通过利用这种集成,开发团队和运营或 DBA 团队可以共同参与到问题的诊断和修复中来,并通过访问到更多的相关细节内容更好地改进软件系统。

选择同时适合开发人员和 DBA 或运营人员的问题跟踪工具

你选择的问题跟踪工具必须同时对开发团队和运营或 DBA 团队友好,且他们都可以访问该工具。许多工具都提供问题跟踪的功能,但是这些工具主要是作为 IT 运营团队的服务台功能而设计的,因此不适合用作软件交付的问题跟踪器。服务台通常设计用于处理来自个人的支持电话,而不是用来处理团队的问题的,默认的 ticket 访问权限会隐藏 ticket 的详细信息,只有首个报告问题的人才能访问到详细内容。

这就是说,对问题跟踪工具的选择需要兼顾到软件开发团队、IT 运营团队以及 DBA 团队。Ticket 需要对开发和运营或 DBA 团队可见且共享,ticket 的工作流必须是灵活可配的。即使工作流不同,ticket 也至少必须同时照顾到开发团队跟踪的领域和运营团队跟踪的领域。

当你必须保留多个工具

就像之前提到的,使用单个工具支持开发和运营的工作流和问题类型是最理想的方法,这样可以减少团队间的摩擦,提高可重用性并且有助于信息共享。

然而,有时候无法迁移到单个工具。将开发或运营外包出去就是一个很明显的例子。不可能要求外包服务商使用与客户相同的工具,因为外包服务商不能为满足每个客户的要求,一直切换工具。

在这种情况下,就需要双方工具都能支持基于 API 的集成,并具有严格的访问控制机制(例如双方组织跟踪系统的 LDAP 验证)。你可以在两个系统中查找相关的 ticket(请参考“查询”部分获得详细信息),但愿系统已经内置搜索支持,你也可以开发自定义的 CRUD 集成,在工具之间同步数据(这样做所带来的好处也仅局限于每个团队可以只使用一个工具的情况)。

无论采用哪个解决方法,这个选项都需要额外的工作,也可能造成更多的错误,因此除非没有其他选择,否则建议不要这么做。

让所有团队和所有人都能看到所有 ticket

每个参与到创建或运行软件系统的人都应该能查询或查看到每个问题。至少技术部门的所有人都应该有这个权限,即使不能修改,也需要对所有的 ticket 有评论的权限。具体来说,使用问题跟踪器时不能只允许问题报告者才能看到细节信息。

主要问题通常发生在对不同类型的 ticket(内部服务台、面向客户的软件系统,等等)进行集成的时候,这些 ticket 来自不同的跟踪系统,它们都具有自己的访问控制机制。而且一小部分 ticket(比如为 CEO 分配新的 iPhone)的安全需求不应该覆盖团队间对透明度和共享的需求。

这就是说,“服务台”设置(处理与员工设备相关的请求,如打印机、台式电脑、手机等等,或创建账户和更改访问权限)应该与核心软件系统的问题跟踪工具分开。

当我们在构建软件时,软件的质量,以及我们跟踪的问题,不仅仅是一个团队的责任,而可能是在不同楼宇、不同国家或不同组织中多个团队的责任。

这种区分是统一业务系统 ticket 管理的第一步。“服务台”团队(或是运营团队中的角色)可以保留自己的跟踪系统,而新的业务系统的 ticket 则使用新的多用途(开发和运营)工具。

总结

问题跟踪工具的选择和使用其实很简单:选择最适合你团队的工具。但在如今以持续服务交付和运营为主流的世界中,团队间的协作需要比以往任何时候都要更加紧密。

让每个团队根据偏好单独选择工具是局部优化的一种形式,可能会导致信息在无意中被隐藏,并让团队渐行渐远。

当然,选择的工具应该能支持所有依赖于它的团队的工作流。它们还应该具备易用性,支持查询和扩展,能够与其他工具集成,支持跟踪跨团队的相关问题。这些特性是在开发团队和运营团队间建立强大的早期反馈回路的基础。

想要了解开发团队和运营团队(特别是 DBA)间合作问题的更多报道,请查看数据库生命周期管理上的系列文章。

有关作者

Matthew Skelton从 1998 年起一直在搭建、部署并运营商业软件系统。作为 Skelton Thatcher Consulting 的联合创始人兼首席顾问,他致力于帮助组织采纳并维持搭建运营软件系统的最佳实践:持续交付、DevOps、ITIL 和软件可操作性。Matthew 创造了著名的 DevOps 团队拓扑模式。他还是《Database Lifecycle Management (Redgate)》和《Continuous Delivery with Windows and .NET (O’Reilly)》两书的合著者。他的推特账号: @matthewpskelton

Manuel Pais是 Dev+Build+QA = DevOps 理念倡导者(以及 InfoQ 主编)。他是 Skelton Thatcher Consulting 的优秀技术人员、多面手和持续改进大师。Manuel 非常乐于从技术和人的角度帮助团队采纳 DevOps、持续交付和云技术。他曾经接触过很多种技术(Java、.Net、web 和 mobile),也在各种行业工作过(银行、通信、国防和航空)。他的推特账号: @manupaisable

快速了解他:最喜欢的比赛 fim da Europa(欧洲终点站),最喜欢的酒:红葡萄酒 ,最喜欢的成就:成为父亲。

查看英文原文 The Divisive Effect of Separate Issue Tracking Tools


感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2017 年 5 月 07 日 18:43778
用户头像

发布了 217 篇内容, 共 53.5 次阅读, 收获喜欢 70 次。

关注

评论

发布
暂无评论
发现更多内容

辞职1000小时后,我走进字节跳动拿了offer

Java 白

Java java程序员 java面试 java编程

php内核分析-fpm和df的问题思考

H

网络安全 网络 渗透测试·

中层管理者挖掘需求的七大法宝

石云升

读书笔记 需求 职场经验 管理经验 7月日更

关于胖指针的应用

Honey拯救世界

架构实战营

Padding Oracle Attack填充提示攻击-渗透测试

H

网络安全 网络 渗透测试

阿里P8爆肝分享2021年最新版 Dubbo 面试题(附答案)

Java架构师之路

Java 架构 dubbo 面试题 Alibaba

Redis 高级特性

QiyihaoLabs

redis

闭关刷题3个月,斩获腾讯java开发岗位,五轮面试,六个小时灵魂拷问,扶我起来我还能再战

Java领路人

Java 编程 程序员 面试 架构师

5分钟速读之Rust权威指南(三十六)模式匹配

码生笔谈

rust

全靠阿里内部(珠峰版)Java 面试笔记,成功拿下 12 家大厂 offer

Java架构师之路

Java 架构 面试题 面试笔记 一线大厂

在GitHub 上疯传!阿里P8大牛把 SpringCloudAlibaba 讲明白了

Java架构师之路

Java GitHub 架构 微服务 Alibaba

程序员外包避坑指南?

孙叫兽

程序员 外包

为了对抗内卷,我“偷”了阿里两份笔记:JDK源码+Java并发图册

Java架构师迁哥

关于数据安全

奔向架构师

大数据 数据安全

入职腾讯一周年了

程序员鱼皮

Java 腾讯 前端 实习 校招

BAT大厂java程序员面试必问:JVM+Spring+分布式+tomcat+MyBatis

喝酸奶不舔盖

模块一作业

lhp

架构实战营

5000 页?一份字节跳动 Java 面试全解手册发布!瞬间登上各大搜索栏

Java架构师之路

Java 字节跳动 面试题 面经 面试手册

堪称史上最全JVM大全详解!让你的JVM细节到极致

喝酸奶不舔盖

非技科!大专生苦学37天,五轮面试,六个小时灵魂拷问,含泪拿下阿里 offer~

Java领路人

Java 编程 架构师 java程序员 java面试

内网疯传!阿里P8大牛的“满级”分布式架构笔记,上线直接霸榜

Java架构师之路

Java 架构 分布式 阿里 笔记

从零开始构建企业级推荐系统(二十九)

数据与智能

产品 推荐系统

[架构实战营][模块一作业]

KK_TTN

#架构实战营

写给小白看的,逆向工程怎么上路?

Machine Gun

黑客 网络安全 信息安全 渗透测试 逆向

分享 2021 年最新阿里 java 面试题:java 初级 + 中级 + 高级面试题(附答案),让你的面试之路畅通无阻!

Java架构师之路

Java 架构 面试题 阿里 Alibaba

架构实战营模块一作业

Felix

阿里三面惨遭被虐,spring,jvm,mybatis,并发编程等一窍不通

喝酸奶不舔盖

第一周作业

Morphling

#架构实战营

InnoDB存储引擎-锁

CodeWithBuff

MySQL innodb

前方高能预警!阿里大佬出品“Spring实战学习笔记”震撼来袭

互联网架构师小马

渗透测试之子域到父域的横向移动(Sid History)

H

网络安全 网络 渗透测试·

单独的问题跟踪工具带来的分裂影响-InfoQ