针对高速团队的事件管理
“谁构建，谁运行”是否名副其实？
践行“谁构建，谁运行”已有 13 年。当初的诺言是否已兑现？
十三年前，一次访谈悄然泄露了人们对部署和操作软件的新呼声，给全球 IT 流程带来翻天覆地的变化。如今，越来越多企业开始采纳 DevOps 协作方法，以及与之相伴的“谁构建，谁运行”思维方式。不过，既然我们经历这场变革已有十多年，这个概念是否还有意义？有没有兑现当初承诺的好处？
这次变迁的历程
“从客户和技术角度来看，赋予开发人员运营职责极大地提高了服务质量。在传统模式中，您把软件丢到分隔开发和运营的墙壁上后，便不再管它了。亚马逊不会这样。是谁建造，就由谁运行。这样，开发人员可以接触其软件的日常运行，而且还能在平日与客户保持联络。这种客户反馈循环对于提高服务质量而言至关重要。”
“谁构建，谁运行”由此诞生，这是一种全新的行事方式，与随后协作性 DevOps 运动的兴起密切相融，而这项运动最大的亮点就是推倒区隔构建者和支持者的那一堵墙。
这一理念开始盛行，而且理由充分。弥合开发和运营之间的差距意义非凡。在事件发生时，为什么不该由编写代码的团队（极其熟悉产品的团队）披挂上阵解决问题呢？这样做不仅能加快解决问题的时间，还能让开发人员更近距离地接触客户反馈和实时问题，为始终在线服务的运行而出力。
好处很明朗... 挑战也很明显
与所有流程转变一样，与这些好处相伴的是一系列挑战，还有来自结构更为传统的业务部门的巨大阻力。
好处包括减轻 IT 团队压力，实现生产就绪型设计、加快响应时间，以及代码测试更加彻底（毕竟，如果您在凌晨一点被叫醒来解决错误，必然会增大仔细检查下一部署的概率）。此外，它也造就了更优秀、更全面的开发人员，他们将学习新技能和以新方式思考业务作为己任。
代码责任由同一团队承担，因此这种方法也对事件预防产生了积极影响。某份报告显示，如果公司在部署之前请外部团队进行代码审查，其成功率与根本不做代码审查的公司相同。另一方面，由已熟悉产品的开发人员处理同行审查，对事件预防有着积极的影响。
至于挑战，我们团队是如此谈论这种不断变化的事件管理方法所面临的一些挑战的：“[去中心化事件管理] 面临的挑战是组织仍然需要一定的集中化。领导层需要查阅报告和文档。业务利益相关者需要掌握最新消息。他们希望查看事件指标，如平均解决时间和平均确认时间。他们希望事件更新、事件事后分析报告和补救工作全都一目了然。
对于许多正在转向去中心化 [和“谁构建，谁运行”方法] 并且表现尚可的公司来说，应对这一挑战的答案是运用促进中心化和团队自主的技术，以保持事件解决的灵活性，同时仍然将信息集中到一处以使业务部门掌握最新动态。
另一个核心挑战是，采纳“谁建立，谁运行”对许多企业而言意味着改变团队结构和内部文化。这需要以开放的态度对待协作，以新的方式思考产品，并且建立新的团队结构来打破沟通障碍。这样的变革颇具挑战性，要取得成功，必须采取非常明确的方法。
“谁构建，谁运行”能否兑现诺言？
尽管存在挑战，但依我们的经验来看，答案是肯定的。“谁构建，谁运行”仍在为行业带来变革，即便是传统的 IT 团队也在稳扎稳打地进行试水。
目前尚无与采用“谁构建，谁运行”相关的研究，但根据我们的经验，它通常与采用 DevOps 原则相伴而行。而且，我们确实有这方面的数据。根据 Forrester 的研究报告，在 2017 年有 63% 的组织表示已经实施 DevOps，另有 27％ 计划在年内追赶这一潮流，只有 1％ 表示没有兴趣做出改变。
更引人注目的是，各公司报告采用 DevOps 原则后，客户满意度平均提高了 45%，员工生产力提高了 43%。
开始采用"谁构建，谁运行”
若无灵活且高度协作的平台，采用“谁构建，谁运行”方法就是空中楼阁。大前提是开发和运营能够在一起无缝协作，而这种协作只有使用恰当的工具才能解锁。
Jira Service Management 通过集成式协作沟通将团队联合在一起，并允许团队使用首选沟通方式进行连接，包括聊天渠道（Slack、Microsoft Teams）和视频会议（通过原生视频桥或 Zoom）等。几乎 Jira Service Management 的每个方面都能自定义，满足各个团队的不同需求（从警报到路由规则等），使必要的响应者参与到沟通循环中，并且向各方提供从最初响应阶段到事后分析报告和问题管理等背景信息。
详细了解 Jira Service Management 如何释放团队的协作潜力。