如何改善您的 IT 支持工作流
如何利用 DevOps 运行 IT 支持
事实证明，将 DevOps 原则引入 IT 服务和工程团队可以显著提高服务质量、团队士气、问题解决能力和企业工作效率。事实上，采用 DevOps 原则的公司报告称，其客户满意度平均提高了 45％，员工工作效率提高了 43％，不良率降低了 41％，IT 相关成本降低了 38％。
有了这些统计数据，将 DevOps 原则集成到 IT 服务管理对公司来说非常有帮助。但对于团队来说，这听起来也像是一次复杂的变化。好消息？它并不像看起来那么复杂。让人大吃一惊的是，提供更高性能服务的关键竟是如此简单。
什么是 DevOps？
那么，DevOps 究竟是什么？它是将两个意见长期不统一且经常孤立的团队（开发团队和运营团队）组合在一起的一套实践方法。其目标是实现协作、开放式沟通，以及为两个部门找到实现各自目标的方法。
正如我们的专家所解释的那样：“DevOps 是一套将软件开发和 IT 团队之间的流程自动化的实践，目的是让他们能够更快、更可靠地构建、测试和发布软件。DevOps 的理念基础是：在过去处于相对孤立的小环境中工作的团队之间构建协作文化。它承诺的优势包括增加信任、更快地发布软件、更快地解决关键问题，以及更好地管理计划外工作。”
为什么选择 DevOps 提供 IT 支持？
从企业角度来看，数字更有说服力。客户满意度提高 45％。员工工作效率提高 43％。IT 相关成本降低 38％。DevOps 运动在很大程度上帮助企业实现了盈利。因此，80% 的公司表示它们至少使用了其中部分 DevOps 原则。
DevOps 对团队同样具有吸引力，如果使用得当，DevOps 可以提高员工和团队的满意度、协作性和认可度。它可以简化繁杂的流程，加速完成任务，并消除长期以来在 IT、开发和其他彼此相关团队中造成紧张关系的官僚主义。
运营团队过去常常对自己毫不知情的新发布感到沮丧，同时也没有做好提供支持的准备（且据 Gartner 称，这是导致 85% 到 87％ 事件的原因）。而DevOps 则开辟了沟通渠道，并为未来发布做好了充分的 IT 运营准备。过去运营团队的迟滞会使产品发布放缓，从而使开发团队受挫。如今，这两个团队可以共同努力，加快产品发布速度，同时又不会对 SLA 承诺和 SLO 目标产生影响。
面向 IT 服务的 DevOps：最佳实践
优先考虑进行文化变革
DevOps 集成的最大挑战是文化转变。
传统的 IT 组织往往处于孤立状态，开发团队在其独立的生态系统中工作，一旦出现变更，运营部门就会接管，且通常在出现系统变更之前几乎没有甚至根本没有任何警告。
另一方面，DevOps 组织会优先考虑协作和跨团队沟通（通过诸如黑客日、站会和聊天室等实践和工具实现）。
接受这种改变意味着接受新工具、新流程以及优先考虑跨团队沟通和共享成功的新文化视角。
尽可能实现自动化
DevOps 在工作效率方面的优势至少部分归功于优先考虑自动化的这一理念。支持 DevOps 意味着鼓励团队不断发问：我们可以在哪些方面实现自动化？
我们能针对常见错误自动进行代码审查吗？我们能否对系统进行自动化，将问题、事件和请求与可能触发它们的变更或版本关联起来？我们能否自动执行制衡，以阻止自己发布不符合安全性或法律要求的代码？当我们即将完成 SLO 目标时，我们能否实现系统自动化以冻结新发布？
我们有许多方法可以自动实现和改进 DevOps 指标。最常见的三种是：
- 工作流程（例如：通过服务台更快速地移交支持工作单）
- 知识（出现事件时，您的服务管理工具应自动显示相关知识和文档）
- 上报（如果组织中只有两个人可以解决某个问题，智能系统应直接将问题上报给他们，而不是走完呆板的线性上报路径）
跟踪重要指标
当开发和 IT 运营部门协同工作时，最佳实践还要求他们跟踪事务的进展情况。
常见的 DevOps 关键绩效指标 (KPI) 包括 MTBF（平均故障间隔时间）、MTTR（平均恢复、修复、响应或解决时间）、MTTF（平均无故障时间）和 MTTA（平均确认时间）。很多公司还依赖于一些数字，比如在特定时间范围内生成的警报或请求数量、每分钟的停机成本或每次通话/请求的支持成本。
您团队需要跟踪的指标取决于团队本身、您在 SLA 协议中向客户做出的承诺、您与组织商定的 SLO 目标以及您想解决的具体问题点。指标是一个不断变化的目标，意识到这一点同样重要。随着公司内部情况的变化（从 IT 支持的产品到利益相关者的需求，再到任何外部法律或安全义务），您跟踪的指标以及跟踪这些指标的方式也可能需要改变。
重视共享
DevOps 旨在弥合创建与维护、创建者与支持者之间的差距。它涉及创建共享的视图、目标、流程和词汇表。它涉及分享知识和沟通。它涉及共享的工具集、资源和代码库。也许最重要的是，它涉及共享所有权，而这意味着共担责任和共享成功。
对于许多传统组织而言，转而使用 DevOps 意味着重新思考如何定义、奖励和跟踪这些共同的责任和成功。开发团队和运营团队的目标是否存在冲突？一个团队的成功是否会使其他团队的成功更加困难？
例如：如果开发团队的任务是尽快推出新功能，而 IT 运营团队则负责维持正常运行时间，那么这两个目标可能会对彼此产生不利影响。运营团队可能希望开发人员放慢脚步以超越正常运行时间目标，而开发团队则可能会因为无法实现其发布目标而对运营团队感到不满。
很多 DevOps 团队的解决方案是采用 SRE 方法，即只要正常运行时间在 SLO 目标范围内，开发团队就可以随心所欲地推出新功能。当正常运行时间降至不可接受的水平时，推出的所有功能都会冻结，直到两个团队共同努力将正常运行时间恢复至所需水平。
ITIL 与 DevOps
如果您采用 ITIL，或许会想知道 DevOps 适用于哪些方面。对很多公司来说，ITIL 和 DevOps 实践可以协同工作。事实上，在 Atlassian，我们发现很多公司在同时利用两者的优势。
正如这篇关于 DevOps 与 ITIL 的文章所解释的那样：“我们需要两者兼而有之。我们谈论的是互补、而非相互冲撞的解决方法。我们需要有能力以更智能、更快速的方法开展工作，但我们仍需流程和控制。现代化的高绩效团队和组织开始意识到这一点，并开始利用两者的要素，他们已经超越了非此即彼的基本原理。”
ITIL 倾向于解决运营、支持、治理和其他核心业务职能部门的最佳实践。DevOps 则带来了持续交付、无指责文化、协作工具和敏捷开发实践等明显好处，而这些内容可在 ITIL 指导方针中长期构建的实践基础之上进行增强和发展。
面向 DevOps 组织的工具
采用 DevOps 方法可能还意味着采用新的工具，以实现沟通、自动化和跨团队协作。
在评估新工具时，请务必问自己以下几个问题：
- 此工具是否适合我们的环境，是否能与现有工具集成？
- 它能否满足我们的需求？
- 所有新工具是否均可在一个全面且凝聚性的工具集中协同工作？
我们可能会有偏见，但在 Atlassian，我们使用 Jira Service Management 进行 IT 服务管理，使用 Jira Software 进行软件开发，并使用 Bitbucket 作为代码存储库。
这些工具运行良好的部分原因在于，它们可以很好地协同工作。此外，当您消除团队结构中的孤岛时，您也会想消除任何所选工具中的孤岛。
The Total Economic Impact™ Of Atlassian For ITSM
The Total Economic Impact™ of Atlassian Jira Service Management. The report includes cost savings and business benefits enabled by Jira Service Management.
阅读白皮书Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
阅读白皮书