到目前为止，我们大多数人都熟悉DevOps是什么 - 它是一种将人员，流程和产品结合在一起以更快地交付高质量软件的文化，其最终目标是为客户提供更多价值。
在大型，高度监管的企业中扩展DevOps带来了独特的挑战。 通常，这些挑战涉及诸如单片系统，遗留软件，手动工作流以及与大型组织相关的其他问题，这些问题由于其大小和年龄而固有地更加麻烦且更慢地适应。
在本文中，我将讨论DevOps如何适应企业以及发布经理可以采取哪些措施来调整和扩展DevOps以应对大型企业中存在的挑战。
什么是DevOps？要了解DevOps是什么，您必须了解开发和运营之间的根本脱节。 开发团队创建和更改软件，而运营团队的任务是确保他们维护的系统的稳定性。 这个被接受的比喻是由Andrew Shafer在2009年提出的，它认为发展与运营之间存在着“混乱之墙”。
企业有两个相互竞争的动机：交付和稳定。 企业需要能够经常提供软件更改，同时还要为最终用户保持100％的可用性。 传统的IT方法强调开发和运营之间严格分离关注点，迫使企业选择交付或稳定。 您可以不断地提供软件更改并牺牲稳定性，或者您可以强调稳定性并使软件几乎不可能发生变化。
有些人将DevOps定义为一组工具和技术，但DevOps（如其表兄Agile）更常见的特征是一组常用方法和共享值：
- 更频繁的发布 - DevOps团队努力消除不常见的礼仪版本，并转向与敏捷软件开发更紧密结合的模型。 在某些组织中，这意味着持续发布。
- 强调自动化 - DevOps团队使用端到端自动化。 DevOps项目可以使开发团队使用Chef或Puppet等工具执行自助服务部署。
- 共同责任 - DevOps团队不会将发布和部署视为其他人的责任。 当软件发布时，开发和操作都应该在Shafer的混乱墙上进行协作。
DevOps（像敏捷一样）无法轻易解释，但实践它的人可以识别它。 虽然我认为将DevOps定义为一组工具并不合理，但有几个与运动相关联，例如Chef和Puppet。 与敏捷类似，组织也可以轻松采用单点方法的组件。
企业面临的挑战首先，让我们来定义Enterprise的含义。 我们并没有将此作为谈论所有业务的全能词汇; 当我们说“企业”时，我们的意思是它。 这些公司像国际银行每天数十亿美元或大型零售商追踪数千亿的库存。
在这些环境中，描述开发和运营之间差异的一个很好的比喻就是卫星。 开发团队正忙于在机库中制造卫星，而运营则负责在轨道上维护这些系统。
在这些企业中，给出了以下关注点：
- Change Control – 发布版本有一个变更控制流程，无论多小，都需要为每个变更完成.
- Approval Gates – 由开发按需驱动的DevOps承诺自助部署可能是不可能的。 有一个发布团队.
- Massive Environments – 如果您的软件处理数十亿的交易或客户，您的环境很可能同样庞大，并且可能无法通过Chef和Puppet等工具实现快速自动化.
- Orchestration with Multiple Groups – 大型组织倾向于同时在多个部门中发布.
通常使用的DevOps在前面的列表中有一些盲点。
- DevOps and Change Management – 实施持续部署的人可能会将BMC Remedy等工具视为浪费时间，但对于应用支持团队或网络运营中心而言，此信息至关重要.
- DevOps and Approval Gates – 应用程序团队应该能够自动化和控制部署，而不会有长时间的延迟和流程，但是在开发高风险软件的大型组织中，governance gates有充分的理由.
- DevOps and Non-automated Environments – 开发人员可以获得启动和缩减云基础架构的权力，但组织通常会受到基础架构的资源限制，并且可能需要数天时间来准备和验证新环境。.
- DevOps and Orchestration – DevOps从开发人员的角度强调单团队效率，但它没有解释最大的软件版本中发生的一些跨团队编排挑战.
从IT的角度来看，DevOps项目发布了风险和维护增加的所有迹象。 在下一节中，我们将定义如何弥合DevOps和IT之间的差距。
企业DevOps战略是的，DevOps是关于自动化和技术，但它主要是关于通信。 它是关于在开发和运营之间进行非对抗性和不正式的沟通。 企业DevOps有点不同。 您可以将Enterprise DevOps视为“当IT部门仍然专注于ITSM和ITIL时的DevOps。”企业DevOps将部分基础架构自动化要求从DevOps的Dev端转移到DevOps的Ops端。
发展中心管理重心转移通过高效的企业DevOps，您的开发团队仍然可以尽早提供，他们可能仍然使用Puppet和Chef来自动部署，但他们正在花费额外的精力来满足IT团队的信息需求，他们将继续完全与生产部署过程断开连接。虽然较小的DevOps方法中的重心完全在开发人员的一边，但在Enterprise DevOps中，协调的责任在于发布经理。
在企业DevOps方法中，您的应用程序团队应该对一组通用的自动化工具和方法进行标准化。如果每个团队和应用程序组都能够对DevOps进行独特的解释，则无法将DevOps扩展到大型企业的级别。在每个组中，应该很难区分DevOps和Enterprise DevOps。对于开发人员而言，体验应与提供给共享参考系统以便持续测试的代码相同。
企业DevOps尊重变更管理企业DevOps是一种快速软件交付形式，仍然需要尊重大型组织IT部门的手续。 如果操作使用BMC Remedy或ServiceNow将版本建模为更改请求，则您的发布过程需要遵守该策略。 虽然许多人认为DevOps摆脱了不必要的过程，但企业DevOps保留了开发和运营之间的正式接口，并将双方隔离开来，使其面临繁重的面向流程的交互。
企业DevOps降低了与环境相关的风险当您练习企业DevOps时，您需要训练您的操作组使用DevOps工具自动化和站立常见环境，以便团队可以互换使用。 例如，如果您的公司中有40个组在Apache Tomcat上开发所有应用程序，那么企业DevOps方法就是让中央IT组创建一组Puppet或Chef脚本，以用作其他组的基线。
在企业DevOps方法中，您的运营团队提供一组通用的虚拟机（VM）映像或环境，开发组可以自动执行。 在较小的DevOps方法中，您的开发团队将编写工具来自动部署到生产。 在企业DevOps方法中，您的应用程序团队将停止测试和登台环境，并且操作仍将负责将登台中完成的自动化工作转换为生产环境。
企业DevOps启用业务流程当所有团队都拥有相同版本的DevOps标准时，发布经理了解软件部署和发布是标准化的，他们可以更准确地预测时间表。 在大型组织中，这对按时交付至关重要。
Plutora支持企业DevOps当我们创建Plutora时，我们这样做的理念是，弥合发布中涉及的不同组之间的信息差距可以减少与发布相关的摩擦和风险。如果您参与了一个重要的版本，您会理解版本是关于冲突 - 发布和操作之间的冲突，以及用于建模发布的冲突工具。如果您能够理解并预测这些冲突，您可以管理它们，并且发布可以更加可预测。
DevOps方法是打破开发和运营之间的界限，并调整两个组以实现相同的目标。如果Operations组仍然必须执行与ITSM等繁重流程相关的一些过程任务，那么您仍然可以拥有一个针对DevOps样式部署的开发团队，该部署会为IT部门预期的界面改进此新流程。
Plutora可以做到这一点。它为专注于DevOps技术的开发团队提供了一个界面，并使他们不必处理ITSM。您可以配置Plutora将来自JIRA和其他工具的信息直接提供给BMC Remedy等工具。 Plutora是一个工具，它将为项目经理提供他们所需的工具，以便对运营团队施加适当的压力，以适应使用Agile和DevOps式自动化的开发团队。
通过Plutora，我们正在努力解决部署软件的真正挑战 - 运营与开发之间的沟通差距。将Plutora视为拆除Shafer混乱墙的工具，并将其替换为可以在降低风险的同时提供极佳可见性的工具。
From： https://www.plutora.com/blog/what-is-enterprise-devops
,
