企业中实施DevOps？

DevOps是一个相对较新的术语，我相信这个观念已经持续好一段时间了。关于这点，在一些企业中它被广泛接受为一种文化方式，前独立团队的集合产生更快、更高频以及高可信赖的结果。

我很幸运在这个术语成为主流之前，开始了我的DevOps文化职业生涯。2001年，当我还是Bloomberg的开发人员时，该公司已经闻名于其不懈地追求上市时间，迭代开发周期以及开发人员持有其交付系统的持续运营。新开发者不需要花太多时间去体验在凌晨4点（当伦敦交易开市时）进行系统故障排除。我发现这些深夜经验是系统健壮运行的伟大驱动力。

DevOps对于初创公司的影响就直觉上会更明显，因为较小的企业应用起来会相对容易些。但对于拥有大量技术债，整体架构和风险规避业务实践的大型企业而言，这项业务似乎令人望而生畏。

好消息是，它不是必须的。接下来的几周，我将讨论企业中实施DevOps的具体领域和策略。我鼓励想要转向DevOps文化的公司以DevOps的方式这样做——从小项目开始，迭代，学习和改进。我鼓励他们考虑可以被企业普遍接受的实施策略，并接受这样的想法：当实现自动化后，持续的运营可以被许多团队分散以及信任来运行他们的构建。

对于那些考虑DevOps但也玩弄技术债的人，请参考这三个原则：

当今的企业应该把他们的内部利益相关者看作是客户。这些客户可以是来自营销部门，产品经理或开发人员的任何人。无论个人或团体都需要技术来支持他们完成工作。以这些需求至上的团队将使客户不会徘徊于其他解决方案（Shadow IT），这会带来更好的结果（更快，更好，更便宜），并拥有更快乐的合伙人。缺乏优质的服务会让你的客户围绕你工作而不是与你一起工作。

众所周知，为了充分利用云，您将需要使用代码可靠地重现系统。这对于自动伸缩（弹性）尤其如此。自动化还使得能够组织更积极地实施更改：如果您出错了，您可以很快返回并可靠地再现之前的状态。不仅如此，自动化具有更高的效率，安全性和可审计性等优点。

这通常是使传统IT变得焦虑的地方。在传统的IT模型中，应用或服务的运营有时由那些不涉及资产创建的人管理。这样做有很多原因（例如，成本更低的资源，集中的专业知识），但我认为这些原因正在消失。云技术现在可以处理与IT运营相关的大量繁重工作，而且大部分操作可以通过软件自动完成。开发人员熟悉软件，这也意味着缺少分离任何给定任务的运营指责。毕竟，这就是DevOps一词的来源。因为开发人员将是最熟悉系统细微差别的人，他们能够最快地解决问题。通过使用自动化，在影响客户之前方便回滚和解决问题。我鼓励有条不紊地传播变更和集中的DevOps团队，尽力使开发团队越来越独立，而不是集中在进行的操作/释放的关键路径中。

对于那些喜欢享受泡脚带来的惬意的，抱歉，现在已经没有时间了。从小的项目开始，并以适宜的增量递增。文化变革不能发生在一夜之间。慢慢开始在您的投资组合中应用这些概念，新的与旧的工作方式都会得到改善。随着您经验的增长，将每一次的所学应用到下一次学习中，然后利用您日益增加的自动化知识库存，期待看到您更好的结果。

作者Stephen Orban

来源: AWS Enterprise Blog,  Considering DevOps in Your Enterprise?

史蒂芬·奥本 (Stephen Orban) 于 2014 年9月加入亚马逊AWS 担任企业战略总经理。奥本与多名企业技术高管合作，在云如何实现业务成果、加快创新和简化流程方面进行经验和战略分享。在加入亚马逊AWS 之前，奥本曾在道琼斯担任首席信息官 (CIO)一职，他通过借力 AWS 和其他软件即服务 (SaaS) 合作伙伴，引入现代软件开发方法、实现降低成本、执行云优先政策。这些转型变革加快了产品开发周期并提高了全部业务线的生产能力，这其中就包括《华尔街日报》、MarketWatch.com、道琼斯通讯社及Factiva。奥本还曾在彭博有限合伙公司(Bloomberg LP)工作 11 年，并且在股权和消息平台担任不同的领导职务；2008 年，奥本创建彭博体育（Bloomberg Sports）并担任首席技术官 (CTO)。