| 本文要点
在如今以持续服务交付和运营为主流的世界中，团队之间的协作需要比以前任何时候都要更加紧密。开发和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则使用新的多用途（开发和运营）工具。
总结
问题跟踪工具的选择和使用其实很简单：选择最适合你团队的工具。但在如今以持续服务交付和运营为主流的世界中，团队间的协作需要比以往任何时候都要更加紧密。
让每个团队根据偏好单独选择工具是局部优化的一种形式，可能会导致信息在无意中被隐藏，并让团队渐行渐远。
s当然，选择的工具应该能支持所有依赖于它的团队的工作流。它们还应该具备易用性，支持查询和扩展，能够与其他工具集成，支持跟踪跨团队的相关问题。这些特性是在开发团队和运营团队间建立强大的早期反馈回路的基础。
|
