使Devops在Webops之外工作

最近3年来我一直在学习有关devop的更多知识 。 我参加了Velocity和Devopsdays以及其他一些包含devop内容的会议（例如OWASP USA的最后几次会议和今年的Agile会议 ）。 我一直在关注devops论坛和新闻 ，阅读devops书籍 ，试用devops工具和Continuous Delivery ，与在成功的devops商店工作的聪明人交谈，鼓励我组织中的人们在其中采用某些想法和工具。感。 寻找可以用于企业B2B环境中的实践，模式和技术，并将其应用于我们所做的工作。

对我们来说，一个问题是，今天的devops仍然大部分是从头开始的，它植根于Web Ops ，专注于建立和扩展在线商店，社区和云服务-也许有些企业技术供应商跳槽devops潮流以重新品牌他们的工具。

吸引着成百上千个其他企业的运作良好，受到严格监管的企业IT组织真的可以从尝试启动新的在线社交社区或多人在线游戏甚至更大型的技术创业公司那里学到很多东西，像Etsy或Netflix这样更成熟的开发商店？ 是否应用相同的规则和想法？

答案是：有时是，但不是，并非总是如此。

有一些重要的因素使企业与当今的大多数商店分开。

平台的异构性以及对遗留系统的支持以及系统之间所有操作相互依存的需求是其中之一–您不能假装可以通过在已建立的企业中使用Puppet或Chef来解决配置管理问题通过并购在许多年中实现了这一目标，并且必须在数十种不同的技术平台上支持数千种不同的应用程序。 这些应用程序中有很多是您无法控制的第三方应用程序。 其中一些平台是不再受支持的旧系统。 其中一些配置是一次性的雪花，因为这是某人可以使事情正常工作的唯一方法。

治理和法规遵从性（以及与此相关的所有文书工作和麻烦）是另一回事。 甚至devop商店也无法像处理其余代码那样来处理其高度监管的核心业务功能（一个很好的例子是Etsy如何满足PCI规范 ）。

还有其他两个重要因素使大型企业等金融机构与一家专门机构的运作方式分开：对变革速度的需求和失败的成本。

速度需求

如果是“我怎样才能更快地改变事情？” 是问题，devops看起来就像答案。

Devops通过无休止的自动化，打破开发人员与运营之间的壁垒以及通过诸如持续部署 （ Continuous Deployment）之类的实践来实现并强调快速，连续的更改，在该过程中，开发人员每天将代码更改推送到生产中。

对于迭代式设计和开发的早期阶段而言，能够快速移动这一点非常重要，这对于需要在客户用光之前建立大量客户的在线初创企业以及其他组织出现快速增长的企业来说非常重要。 每个组织都有一些需要经常更改的系统，并且可以以最小的影响对其进行更改：例如CRM系统，分析和内部管理报告。 正如James Urqhuart所解释的那样 ，当您需要经常更改技术时，针对更改进行优化是有意义的。

但是，您不需要其他系统，也不必每天，每周或每月更改其他系统：ERP和会计系统，付款处理，B2B交易系统，工业控制。 您不需要或不想对客户进行实验以尝试新功能或不断完善其用户体验的细节的地方，因为该系统已经可以正常工作，并且很多人都依赖它以某种方式工作真正重要的是保持系统正常运行并降低运营成本。 或者，由于法规和合规性要求以及与其他系统和其他组织的运营相互依存关系而带来的变更风险巨大且代价昂贵。 而失败的代价很高。

即使您对此进行了优化，变更也总是伴随着失败的风险。 《 2013年Devops状态报告》发现，高性能devops商店更频繁地部署代码30倍，“变更成功率翻倍”。 这些数字本身就令人印象深刻。 放在一起–它们还不够好。 与组织移动得更慢，更谨慎的组织相比，改变得更多仍然意味着失败更多，而且并不是每个组织都能承受得更多的失败。

失败的代价

大多数在线业务都存在于一个更简单，更无辜的世界，在这里，变更很简单-它是您的代码和您的云，因此您可以进行更改并将其推出，而不必担心对其他系统和使用它们的人员的依赖性或如何协调跨不同公司和业务线在全球范围内推广–失败的后果确实不那么严重。

如果您不向客户收取任何费用（Facebook，Twitter）或不收取任何费用（Netflix）以使用您的服务，并且客户失败造成的损失不算太大（他们必须稍等片刻告诉人们他们的小猫刚打喷嚏，或张贴他们的金鱼的照片或看电影），那么当出现问题时，没有人有权期望太多。

对于金融服务公司来说，这是一个完全不同的世界， 失败并不总是可以选择的 -“ 快速失败，经常失败 ”在早期开发中有效，但是一旦客户使用了您的技术就不会生效。

一家银行的技术主管告诉我，Etsy（或任何网络公司）不是“认真”的工作，他的银行使用“认真的钱”工作，这意味着他们不能像网络公司。 我也看到过网络公司对企业的热情，因为它们被用户规模较小和非24×7的工作环境所“宠坏”。

在这些小组之间达成​​共识之前，健康和成熟的思想和观念交流将是缓慢的。

约翰·奥尔斯帕（John Allspaw），访谈，企业是否已准备好进行DevOps？

那位银行高管虽然不外交，但却是正确的。

银行和在线消费者网络业务之间的失败所涉及的成本和风险相差几个数量级，甚至大到Etsy。 在2012年底的一次演讲中 ，Etsy的CTO吹嘘说他们现在正在处理“真钱”，当时“每分钟一千美元”之多。 虽然这对Etsy的真实客户来说是一笔真钱（而且我敢肯定，现在这个数字会更高），但与任何大型金融机构处理的交易价值相比，这是微不足道的。

没有像Etsy或Facebook这样的公司可能犯的任何错误，可以与大型银行 ，信用卡处理商， 大型证券交易所 ，金融清算所或经纪公司的大型系统故障的影响相提并论，或者其他一些大型金融机构。

这不仅是因为通过这些系统进行的交易具有很高的价值。 也是由于连锁反应，此类故障对这些组织所运行的国家和国际系统体系中的其他机构产生了影响–对合作伙伴和客户的系统以及对其客户和合作伙伴的影响。 这些故障的成本可能高达数百万或数亿美元，如果您包括丧失的机会成本和响应故障的下游成本（包括用于升级或更换整个系统的IT成本，则通常会更多）。应对重大故障的响应），不要介意在重大系统故障后整个行业通常要求加强监管的后续成本。

当在线电子商务或社交网络出现故障时，即使大规模失败也不会发生这种规模的问题。 这给客户带来了不便，这对在线业务来说是真正的代价，但是失败不会蔓延到其他公司和行业，除非亚马逊的AWS基础设施可能无法正常工作并且依赖于此的在线公司会停滞不前 ，似乎每年发生两次 。

对于许多企业甚至较小的B2B平台而言，不足以针对MTTR进行优化并在下一次再努力，或者接受回滚是一个神话 ，而“真正的男人只能向前滚”，以及持续不断的备受瞩目的失败故事中，这还不够。在在线组织中，一旦发展到一定规模，这对devops组织来说还不够。

但是您仍然可以从Devops中学到很多东西

不是说devop在企业中行不通。 只是没有发展，因为到现在为止大多数都没有描述。 Devops夸大了“更快更频繁地进行更改所需的一切”，并简化了许多组织在无法运行或无法在云中运行所有功能时所面临的其他一些问题。 但是，即使他们的故事，他们的优先重点和制约因素以及他们的业务状况不尽相同，但仍需要向发展组织的领导者学习很多东西。

我们当然可以从他们那里学习如何运行可扩展的Web存在以及如何将内容移动到云中。

我们可以学习如何通过尽可能简化和标准化配置以及尽可能简化和自动化测试和部署步骤来最大程度地降低变更管理的风险和成本，即使我们不会每天都在进行更改。

但是就目前而言，devops带给我们这些在网上网上商店不工作的人最有价值的东西不是工具或实践。 正是因为devop正在为开发人员和Ops与管理层之间的互动创造新的理由和更多的机会 ，因为他们试图弄清楚这是devop的含义，以及它们在我们组织中是否有意义以及如何发挥作用。

为了使开发人员，管理人员和Ops一起讨论配置管理以及如何改进发布和部署以及运行时警报和应用程序监视以及运行时运行状况检查 ，以及开发人员和Ops如何从失败中共同学习 。 让开发人员和Ops考虑这些问题，并尝试以协作和建设性的方式一起解决这些问题，而ITIL肯定从来没有这样做过。 将更多的时间花在解决问题上，将更少的时间花在昂贵的官僚主义和推卸责任上。 那一定是一件好事。

参考： Building Real Software博客上的JCG合作伙伴 Jim Bird 使Devops在Webops之外工作 。

翻译自: https://www.javacodegeeks.com/2013/10/making-devops-work-outside-of-webops.html