软件系统几乎影响我们生活的各个方面。 从我们用于在线购物的基于Web的门户到运行我们的业务的大型企业系统，我们希望计算机系统能够提供广泛的功能，进行扩展以满足峰值使用需求并了解我们的偏好。他们可以预见我们的所有需求。 当我们使用一个编写良好的软件系统时，我们已经习惯了它的功能和灵活性，当其他软件系统没有达到或超过相同的期望时，我们会感到惊讶。

计算机故障导致灾难性后果

由于计算机在我们的许多日常任务中发挥着作用，因此当我们依赖的系统的可靠性不足100％时，我们会受到特别的影响。 本文重点介绍可采用的最佳实践，以创建可靠的软件系统，并避免最近影响如此多其他公司的重大事件。

骑士资本集团的一个例子

2012年8月，骑士资本集团（Knight Capital Group，Inc.）遭受了灾难性的计算机故障，事实证明对该公司作为独立组织的生存至关重要。 已发布的报告表明，升级与纽约证券交易所（NYSE）泛欧交易所有关的软件的失败尝试导致该公司无意中购买了他们不想要的价值70亿美元的股票。

奈特不得不立即清算该股票，结果造成了超过4.4亿美元的损失。 随着一些客户撤回业务（某些行业专家称其对公司能力失去信心），损失增加了。 Knight Capital被另一家公司收购。 之所以倒闭，主要是因为该公司缺乏管理软件升级的适当程序。 这一广为人知且引人注目的事件只是影响银行系统，贸易公司，证券交易所以及诸如纽约市911应急系统之类的重要政府系统的众多近期软件故障之一。

来自股市的类似例子

最近其他许多软件故障也产生了类似的严重后果。 2013年5月，芝加哥软件交易所期权交易系统（CBOE）交易系统被关闭，原因是该软件故障据称与延长交易日所需的系统配置更改有关。 这次事件使人们怀疑，基于标准普尔500指数和VIX的股票波动率指标，芝加哥期权交易所是否真的应该是期权的单一来源。 发生此事件的同时，其他公司也在挑战CBOE管理这些交易指数的专有权，并证明交易交易所可能无法继续成为这些期权的单一来源。

一些行业专家质疑大型计算机系统是否已经变得如此复杂，以至于任何公司或组织都无法确保这些企业级系统可靠且没有服务中断。 本文回答了这个问题。 我们确切地知道如何开发完全可靠的大型，关键任务系统。 实际上，许多建立与BestOps一致的行业最佳实践的行业标准和框架可以帮助确保计算机系统的高度可靠性。

行业标准和框架

IEEE，ISO和其他几个受人尊敬的标准组织提供了有关如何开发可靠和安全系统的详细指南。 使用这些行业最佳实践，您可以证明您具有有效的IT控制手段，以帮助确保您的系统可靠并满足大多数联邦法规的要求。 在本系列文章中，我们将在相关行业标准和框架的背景下讨论DevOps最佳实践的实际实施，并说明如何以一种自然和实际的方式与DevOps相关的实践和原则保持一致的方式，来实施必要的自动化程序。

例如，信息技术基础结构库（ITIL）是通过支持使IT服务与业务需求保持一致来支持IT服务管理（ITSM）的一组实践。 ITIL V3是最流行的框架之一，它提供有关如何确保可以维护和升级IT服务而不会造成服务中断风险的指导。 ITIL描述了用于跟踪对所有配置项（CI）的更改的配置管理系统（CMS）。 它还通过提供有关运行时系统上CI的状态的更新且准确的信息，来描述支持CMS的配置管理数据库（CMDB）。

配置管理数据库要求支持

CMDB是CMS的重要组成部分，它通过自动发现程序提供更新且准确的信息。 DevOps通过启用成熟的构建过程来帮助使CMDB保持最新状态。 实际上，只有使用嵌入式和不变版本ID构建的应用程序代码才能被发现并准确识别。 因此，您的构建工程工作必须包括将版本ID嵌入配置项本身并将版本ID嵌入到容器清单（例如将其打包在其中的jar，war或ear文件）的过程。

DevOps通过提供构建，发布和部署自动化来满足此要求，使CMDB能够向CMS提供有关应用程序代码的准确信息。

CMDB可能阻止了Knight Capital Group的事件，该数据库可以发现其服务器上的代码版本，并根据CMS中的预期版本进行验证。 仅当开发和运营组织在软件开发生命周期的早期就共同构建和自动化它们时，这些技术才有可能。

DevOps通过发布工程提升质量

发布工程为构建和打包可在目标服务器上验证的代码提供了最有效的方法。 这种方法可以防止在当今的金融服务行业中变得如此普遍的小故障。 成功的实施取决于开发和运营团队的有效协作，以：

• 内置版本识别
• 创建按操作运行的发现工具和过程，这些发现和过程：
  • 验证是否已部署正确的代码
  • 确认没有由于恶意或人为错误而进行未经授权的更改。

每个团队都有特定的目的：

• 运营团队的重点：保持可靠的服务。
• 开发团队重点：开发新功能。
• DevOps的重点 ：确保运营团队和开发团队之间的协作以实现这些自动化过程，以防止由于在生产服务器上部署的代码版本错误而导致软件故障。

正如质量专家W. Edwards Deming所倡导的那样，使用DevOps方法来构建，打包和部署应用程序使组织能够从一开始就构建质量。 如果我们知道如何防止在Knight Capital发生的这类问题，为什么没有更多的组织采用这些行业最佳实践？

DevOps实际上省钱

无法建立必需的IT控制的最常见借口是，它花费太多，并且花费太多时间。 在许多组织中，挑战性的期限和交付新功能的压力导致偷工减料，这一决定经常直接导致软件缺陷，从缺失需求到在代码库中引入错误。 质量的确需要付出一定的代价，但是交付有缺陷的代码的成本也很高，并且可能包括金钱损失，更重要的是，对组织本身的信心也会下降。

DevOps从一开始就将重点放在提高质量上。 该重点对于公司交付有效且支持业务的软件至关重要。

DevOps将复杂性对软件开发的影响最小化

质量不佳的另一个常见借口是软件太复杂了。

软件系统确实提供了越来越复杂的功能。 大多数大型软件系统都无法被任何一名技术专业人员完全理解。 我们所有人都使用软件框架，使我们能够更快地编写代码并提供更多功能，但是这些优势通常是以使用我们不完全了解的组件（由他人编写）为代价的。

但是，如果开发了自动过程来构建，打包和部署应用程序，则可以管理软件解决方案的每个部分。 可以创建这些过程来验证与运行时相关性的接口，并确保正确配置环境以支持所需的所有组件，包括组件本身的构建和部署。 通过为每个组件开发自动化的构建，打包和部署过程，可以有效地管理和管理系统的整体复杂性。

DevOps管理构建，打包和部署依赖性

实施自动化构建，打包和部署过程是任何DevOps工作的重点。 许多软件开发人员完全专注于在其集成开发环境（IDE）中工作，例如Eclipse和Visual Studio。

问题在于他们可能实际上并不了解和理解所有构建依赖关系。 当这些开发人员继续进行下一个项目时，或者因事故导致笔记本电脑崩溃时，组织可能会发现它不具备构建，打包和部署代码所需的知识。 对于开发人员来说，仅部分了解其构建和运行时依赖关系是很普遍的。 这是一种精确的情况，在这种情况下，通常由行业法规要求进行分工的建筑工程师可以通过捕获所需的知识并自动进行构建和部署管道来提高可靠性。

DevOps改善了可靠性和部署流程

对构建进行脚本化和自动化可确保发现并记录有关编译和运行时依赖项的基本知识。 开发人员可能早已忘记了在IDE中配置的所有环境设置，但是幸运的是，用Ant，Maven或Make编写的构建脚本可以清晰，准确地查看构建，打包和部署Java所需的基本配置。码。

能够以一致的方式可靠地构建，打包和部署对于确保可以支持和修改系统而不会造成意外和严重后果至关重要。 除了能够可靠地构建代码之外，我们还需要确保我们可以验证是否已部署了正确的代码，更重要的是，必须立即识别出来自恶意意图或人为错误的任何未经授权的更改。

正确的部署取决于加密和基准的使用

在对应用程序代码进行编译和打包之后，对于部署工程师来说，验证代码是否已正确部署非常重要。 由于许多原因，此处可能会引入问题。 有时，由于权限问题或简单的人为错误，代码未按预期到达目标计算机。

尽管我们测试编写的应用程序代码并验证其是否符合原始要求和设计，但是许多部署工程师还是忘记了验证所构建的代码是否已成功复制到目标计算机上。 解决此问题的正确方法是使用加密技术，以验证所构建的确切代码是否已实际部署到目标计算机。 密码术还可用于识别和检测可能导致系统故障的任何未经授权的更改。

向上游移动构建，打包和部署功能

本文中描述的每种技术都需要一定的努力和技术专长。 许多公司尝试在将代码部署到生产中之后才实施这些控件，这在该过程中太晚了。

DevOps非常重视在应用程序开发生命周期的早期就实施自动部署管道。 编写可验证代码的决定从一开始就将质量纳入流程，这是有效的DevOps的基本原理。

组织通常具有构建工程团队，负责从软件开发生命周期的一开始就自动化应用程序的构建，打包和部署。 应该编写代码，例如嵌入本文前面所述的不可变版本ID的代码，以简化自动化工作。 不幸的是，有些组织在软件开发生命周期的开始就让开发人员处理其应用程序构建而犯错。 这是个错误。 如果构建团队从开发测试环境开始就自动执行代码的构建，打包和部署，则开发人员可以享受这些实践并更快地编写代码。 质量保证和测试小组还可以从自动化应用程序的构建，打包和部署任务中受益，因为这些自动化技术可确保测试的代码与部署的代码匹配。 此外，自动化部署任务有助于确保应用程序正常运行，并且没有可能影响系统可靠性的缺陷。 DevOps认为预配任务是代码工作。

DevOps正确地将供应基础架构（以及在基于云的环境中供应服务器）的任务标识为代码和开发工作。 另外，以安全可靠的方式配置服务器的任务也是代码工作。

在类似的主题上，管理部署管道的任务是软件和系统开发工作，必须包括其自身的生命周期。 DevOps正确地将部署自动化作为其自身必不可少的开发工作。 这种方法要求DevOps工程师验证DevOps流程本身。

DevOps会验证DevOps流程本身

无论是供应服务器还是部署应用程序，DevOps的工作都必须视为开发生命周期，以创建自动部署管道为目标。 许多DevOps从业人员使用敏捷实践来完成此任务，从而以迭代方式改进部署过程本身。

实际上，尽管我们中的许多人也使用这些方法来支持瀑布式开发工作，但许多早期的DevOps爱好者将这些实践称为“敏捷系统管理”，这句话既说明又恰当。 无论您的组织使用的是敏捷，瀑布式还是混合式敏捷瀑布式方法，软件方法都是至关重要的。

实践中的软件方法

应用程序生命周期管理（ALM）定义了与成功实施任何软件或系统开发工作有关的所有涉众所采用的任务和过程。 定义明确的ALM通过使用工作流工具实现自动化，有助于提供必要的基本清晰度，以便每个利益相关者了解他们所负责的任务并通过促进沟通来提高透明度。

结论

开发人员专注于创建新功能。 运营团队专注于提供可靠的系统。 DevOps工程师提供了开发软件的原则，实践和动手过程，这些软件从软件，系统和交付生命周期的一开始就具有内置的质量。 这些实践与行业标准和框架中所述的备受尊重的最佳实践非常吻合。 创建可靠的系统需要DevOps革命中不断涌现的实践和原则。

翻译自: https://www.ibm.com/developerworks/library/d-develop-reliable-software-devops/index.html