Atlassian：“DevOps 本身不是一个目标”

“DevOps 不是某一个人的工作——而是每个人的工作。”开展真正意义DevOps可能具有一定的挑战性，但一旦克服了障碍和偏见，一切都会变得很容易。我们请Atlassian公司的Michael Knight和NickWright跟我们介绍一下他们是如何从 （真正）实践DevOps中受益的。

我们与Michael Knight（Atlassian构建工程团队高级支持工程师）和Nick Wright（Atlassian 网站可靠性工程团队负责人 ）探讨了该公司的DevOps 实践之旅中面对的挑战及从中吸取的经验教训。

Q：Atlassian开展的DevOps是什么样子的？你们是如何开始的呢？

Mike Knight：我们的DevOps文化随着时间推移而自然蔓延。我认为这主要得益于我们现有的对于敏捷方法的承诺。我们不再是纯粹的现有软件供应商，还是一家服务提供商。我们现有的敏捷实践，比如跨职能团队、自动化测试和快速反馈回路的小型/迭代变化等，为此我们团队在扩展执行能力以适应这种变化的同时，自然地过渡到DevOps型文化。

如今，我们团队构建和运行着很多不同的外部和内部服务。尽管每个团队的任务性质各有不同，但是文化是相通的。在我们所有的工程团队中，你都会发现基于scrum或看板的工作流程、每日站立会议，成熟的持续集成（CI）系统、各个层面重点关注自动化。我们所有的团队均拥有精简流程，可以轻松并且可靠的启动和运行微服务（或大或小）解决他们的问题，同时还有很多的空间来尝试新的技术和工具。

Nick Wright：在Atlassian，我们的核心价值是遇见更好的自己，这有助于强化团队塑造各自工作方式的能力。可以说，解决问题的方法多种多样，过去5年里，DevOps方法已经在不同时间不同团队深入人心。这与自上而下决定开展DevOps的情况截然不同。

在我们向网站可靠性工程推进的过程中，我们始终专注于自动化和工具，同时直接与开发团队合作，解决共同的问题。

一方面，我们有一些团队正在开展的工作在DevOps被普及时已经被列为DevOps方法——2011年我加入了这样一个团队，团队非常注重自动化，配置管理是数据中心扩展数千个硬件节点的唯一方法。这个团队从未特意与DevOps联系起来，但自身发现了阻力最小的途径来解决扩展问题。

其他团体在实施DevOps实践时，采取了仔细审慎的态度，他们观察外部团队的做法，参考我们在其它地方看到的案例。在我们向网站可靠性工程推进的过程中，我们始终专注于自动化和工具，同时直接与开发团队合作，解决共同的问题；这种方法还有力地推动我们形成了精简运维团队的方法。

Q：在DevOps入门（DevOps 101）报告中，你提到更快地发布高质量版本的关键在于开发和运维团队之间的密切关系。你是如何获得这一经验的？

Mike Knight：在我们提供云服务的初期，我们的运维是外包给主机提供商管理的，因为当时我们在这方面的专业知识还很欠缺（几乎所有的工程师都是Java开发人员）。这有助于我们的产品迅速起步，但是很快就遇到了很多麻烦。沟通不畅导致偶尔中断（重大或小规模中断均有），我们在实验和规模方面也受到了限制。最后，我们认为不再外包而改为内部运维是按我们的步伐进行创新及改善开发质量与速度的唯一方法。这样做虽然投资很大，但绝对有必要，几年下来，我们确实从中获得了回报。回想起来，或许我们应该早点这么做。

自动化是根本。

Nick Wright：对于我来说，就是转变思维，将竞争目标下的两种对立力量（对于运维来说注重稳定性，而对于开发团队来说则重视功能）转变为一种，即所有的工程师在目标一致情况下快速可靠地发布代码。最大的经验教训是首先寻求理解——花时间去了解同事们的想法，且相信他们是怀着最大化实现目标的意图来开展行动的。

如果有人因为错误而产生了导致生产中断的漏洞（尤其是在没有遵循正常流程的情况下），这个人很快就会被发现。人们犯错误——这是不可避免的。构建安全及自动化系统，来发现这些事情，从而使我们更少依赖于人们不犯错误，这已经成为改善并实现这些结果，同时消除由于责任因素而侵蚀信任的重要部分。

Q：你使用什么工具和流程帮助开发和运维团队之间形成良好的关系？

Mike Knight：开发和运维团队的主要矛盾压力来源于责任和目标存在冲突。为使团队协调一致，我们让开发人员承担尽可能多的责任，但这也必须要赋予他们必要的权力和自主权来履行这些责任。这意味着开发人员控制自己所有或大部分交付渠道、部署环境和QA流程，同时这也意味着他们需要及时解决生产问题。这有助于开发人员了解（并深化）运行稳定性，而运维团队则能够更专注于平台的改进。对于我们的一些服务，开发和运维团队是同一个团队。

DevOps文化的某些方面可能适合一个团队并很快被采用，但不一定适合其它团队。

我们作为协作开发工具的设计企业是很幸运的，可以通过使用大量自己开发的软件进行研发管理工作。我们利用JIRA的工作流清晰地跟踪变化，同时自动链接到相关代码的更改。根据更改位置不同，通过开发团队和运维团队的评审合并代码变更请求。提醒运维团队注意这些变化，使运维团队能够在进入生产环节之前发现潜在问题。

Bamboo用于持续集成和部署，允许开发和运维团队跟踪哪些环境部署了哪些内容，必要时两个团队都可以触发回滚。HipChat 将这一切结合起来，为团队内部及外部提供了稳定的通信层，同时兼作发送监控警报和状态更新的“命令指挥中心”。

Nick Wright：我们通过HipChat进行团队协作，这是我们工作的核心。团队协作、从构建接收通知、部署事件、监控和报警系统都是他们日常活动的一部分。如果出现问题，可以通过HipChat内部事件管理和聊天记录获取一个导致事件失败的有效日志，使我们能够完成事故审查，并帮助开发和运维团队对事故处理意见达成一致。

Q：Atlassian实践真正意义上的DevOps难度有多大？

Mike Knight：DevOps本身不是一个目标，而是一种提供服务交付的有效手段。因为不同的团队面临不同的情况，DevOps 文化的某些方面可能适合一个团队并很快采用，但不一定适合其它团队。例如，一个团队运行一个几乎没有与其他服务交互的内部服务，这个团队通常对从概念到交付，并在生产环境下（及以后的）运行承担全部责任。他们可能会使用DevOps环境下流行的工具：容器化技术（如Docker）、配置管理（如Puppet）和云平台（如AWS）及其他相关工具。这样的团队就像通常意义上的“DevOps团队”一样运作。

另一方面，交付复杂生产服务的团队必须更专业，并且需要其他团队为其提供大量支持。这样实际上会使团队看起来不太像上面提到的DevOps团队那么专业（例如，他们可能不会管理自己的基础设施或平台），但其实文化是相同的。你仍然会看到快速发布的自动CI管道、实现生产监控的快速反馈、中断后随时转换，以及密切的用户关系（直接或通过支持人员）反馈。他们可能不直接使用Docker、Puppet或AWS，但我认为他们还是体现出了真正意义上的“DevOps”。

有时团队会觉得他们正在做重复工作。

Nick Wright：我认为，对我们来说相对比较简单——我建议在不适合的情况下，那就很难进行利用。当事情进展不顺利，我们的团队会快速迭代和做出变化，这种灵活性使团队可以尝试不同的方案，最终保留最佳方案，并将它们集成到我们的工作流程中。

有件事我想提一下，有些时候团队会感觉他们在一次次的做重复工作。我曾经参与过一个项目，是要求我们构建新的服务帮助别人解决他们在管理服务中碰到的关键运维问题——我们是采用集中日志方式的解决方案——与此同时，听说另一个团队也在构建新的服务，利用不同的方法解决相同的问题。

Q：你是如何看待Jeff Bezos制定的“2-pizza team”（小团队）规则的？你会在Atlassian中推行这个概念吗？

Mike Knight：是的。一般来说我们的团队规模是相当小的。超过六个人的团队通常会拆分成子团队，每个子团队有一名负责人。这样降低了沟通成本，帮助团队成员之间建立紧密联系。然而，我们也鼓励借调到其他团队，如果他们需要的话甚至会完全改变团队。这有助于促进团队之间的关系和知识共享。

Q：你如何看待自动化？在DevOps背景下它的重要性如何？

Mike Knight：自动化绝对是基础。实现以编程方式构建、测试、部署和监控服务是一项很大的投资，但回报也更多。虽然必须花时间维护自动化系统，但是，大大提高了团队分享专业知识、跟踪变化、推动他们更快更可靠的实现生产交付的能力。自动化还潜移默化地提供帮助，例如，聊天机器人、自动报告正在发生事件的智能服务状态网页或跟踪团队收到的服务支持请求的数量与类型，避免在未来进行重复工作，从而提升您的客户支持能力。

Nick Wright：自动化是如何在客户不断增长的情况下不需要扩展我们团队的规模。在Atlassian 没有其它的运行和运维方式，事实上，对于世界上大多数公司而言，不论其是否属于科技行业，这一点将越来越来被使用。

在使用一个平台提供服务时，自动化让他们快速的做好事情，不会因为要经过服务台或需要其他人推动的流程而延误。我们可以进行尝试，因为这样做的成本减少了很多：如果您在DevOps还没有形成的环境下，启动100台服务器对新组件进行负载测试，可能需要几天甚至几个星期时间完成。在现在的环境下，工程师可以通过更广泛的用例在几分钟内便可做到这一点，而且成本大大降低，同时我们鼓励提高整体服务可靠性的关键行为。

非常感谢您！