Amir Kirsh
许多第一次接触 DevOps 理念体系的团队在选择工具时可能没有从规模角度进行考虑。企业级 DevOps 要求对各组成部分的运行方式做出更多思考。此外，团队沟通方式对开发工作效率也有很大影响。如今，工程师们意识到，实现与安全、文化和云基础设施有关的标准需要额外具备自动化能力。
企业级 DevOps 是否不同于标准 DevOps？
简单来说，是的！我们在第一次实施 DevOps 时，采取的往往是按需的模式。很多时候，高级工程师都会接到在 CI/CD 场景中创建自动化能力的任务，这就是实施 DevOps 的基础。企业级 DevOps 则是一个完全不同的概念。它涉及一系列要求，提供实现每个任务自动化的手段。它以一种有利于促进稳定性和可用性的方式大规模执行任务。
通常情况下，小型公司中进行的都是标准 DevOps 工作。他们的大部分基础设施都是静态的，而且由于变化率低，所以很少会出现惊喜。某些时候，公司会从许多方面向企业级 DevOps 转型。企业级 DevOps 旨在帮助公司随变化实现扩展，从而确保技术可以应对额外增长，比如一个为处理平均流量设置的网络应用。通过利用水平扩展或垂直扩展，为意料之外的流量高峰做好准备只是企业级 DevOps 的其中一个关键原则。
尽管自动化一直是 DevOps 工程师的工作，但向企业级 DevOps 体系转型需要做出相应调整。应始终将当前环境以及未来扩展两方面的内容放在首位。
另一个企业尤其关注的方面就是更高的安全要求。这也是企业级 DevOps 的热门话题之一。在 DevOps 领域，人们创造了 DevSecOps 这一术语，它涉及一系列检验和网关能力，达到保护代码和数据的目的。虽然 DevSecOps 不是专门针对企业级 DevOps 设计的，但它能确保所有安全能力都通过自动化实现，出于对认证或合规性需求的考虑，大型企业中还需要进行额外扫描工作。
DevSecOps 实践方面，许多企业都被要求遵守与隐私信息保护相关的标准。为应对此类隐私安全威胁，他们会使用一些工具来扫描最常见的漏洞。
另一个近几年越来越流行的术语是“左移”。通过这种方式，确保代码质量的责任“左移”到开发过程中，对新代码提交到代码库前的保证和认证工作提出更高要求。 “左移”也同样不是为企业设计的专属方案，但在企业中采用和实施“左移”方案更具挑战性。对小公司而言，这种变化影响很小，毕竟整个团队规模本身就不大。但对企业而言，“左移”是整体性调整，涉及组织复杂性以及各种实施工具的使用。
应该在什么时候使用企业级 DevOps 方案？
如果我们讨论的是奠定基础，那答案就是尽早使用！鉴于我们正在进行的工作具有可扩展性，对待每一种解决方案，需要假设我们也同样面临着进行企业级 DevOps 实践的人所面临的诸多挑战。如果该解决方案对数百个数据库和众多开发人员都有效，那么它也一定能在更小规模的应用环境中发挥作用。但即便如此，也应该避免过度架构。为企业级 DevOps 奠定基础自然是必须的，但除非真的需要，否则不要为不必要的流程和能力投入精力。
对于可扩展 DevOps 实现还需要考虑哪些因素？
单体和遗留应用程序
出于许多合理因素，公司必须保留一些旧的系统，为后端或是用户界面问题提供支持。我们知道这些系统被称作单体或遗留应用程序。而通常情况下，对其进行编码的堆栈可能并不是今天的开发人员熟悉的领域。尽管如此，在为企业实现 DevOps 时，这些都是需要考虑的关键因素。
相关文章：如何实现遗留 C++ 代码现代化？
技术多样性
如今的工程团队有着许多需求，主要围绕项目所需专用工具和环境。对许多公司而言，这意味着需要许多精通各种编程语言和技术的团队。而且并不是所有语言都对工具都有着相同要求。因此，为企业级 DevOps 选择的工具应支持多种堆栈和方法，确保应用的自动化能够支持相应场景。
上游依赖
当团队间在工作内容方面存在交互时，在某些情况下，一个破坏性变化将会导致多米诺骨牌效应。将这一问题考虑在内才能确保事情顺利进行。复杂的依赖关系会在开发过程中让宝贵的时间被浪费掉，尤其是出现停工的情况下。依赖关系图自然十分有帮助，但自动回归测试等方案也是如此。像“冒烟”测试和“可用性”测试之类的自动化 QA 流程就是企业级 DevOps 团队都知晓的必要流程。
生产正常运行时间
当代码已经部署完毕，另一个版本发布准备就绪时，DevOps 的自动化还不算完成。为确保关键服务和应用程序的正常运行时间而实施的额外工具也会乔装成企业级 DevOps 实现的模样。自动化的主要作用并不是停留在发送警报方面。今天，之所以会有自我监控、自我校正和自动扩展，是因为自动化使得管理相应程序变得更加容易。
多重和混合环境
由于许多公司对云资源的适应速度极快，我们经常会面临同时包含数据中心资源和云资源的多重环境。管理这些资源时，企业级 DevOps 的实现将需要使用针对混合环境的工具。多云也在考虑范围内。应该根据实际情况来选择工具。值得庆幸的是，今天的许多 DevOps 工具集都包含了应对相关问题的方法。
自定义企业级 DevOps 工具
有时，市场上现有的东西并不完全适用于某一特定环境中的工作。无论是出于遗留需求，还是其他原因，相应的解决方案可能需要 DevOps 团队自定义编码或脚本。确保应用适用标准的其中一个目的就是保护这些自定义工具。将 DevOps 代码和脚本保存到数据库中的方案，不仅能够保护这些代码和脚本，对于未来发展而言，也有着许多积极意义。它打通了合作渠道，实现冲刺型工作的分配，就像开发团队的工作形式一样。
微服务时代来临！
这一程序其实本身就很简单。作为 DevOps工程师，我们的目标就是获取代码，确保它能建立工件，并将该工件发布到环境中。随着微服务的发展，我们又有了新的问题需要考虑，包括基础设施、扩展和故障处理。
企业级 DevOps 尤其关注涉及这些内容的方面，特别是基础设施。基础设施即代码 (IaS) 的基本理念就是：创建的任何东西都可以通过使用检入的信息根据需要重新进行创建，就跟代码一样。无论是 Terraform、Azure ARM 模板、AWS CloudFormation 还是 GCP 部署管理器模板。这一理念旨在动态创建几乎所有资源，而这些资源都有着明确说明的规范。
扩展一直以来都是管理应用程序性能的一种方式。垂直扩展和水平扩展分别用于针对性能和规模进行扩展。使用微服务的情况下，该程序通常由您和目标提供的指令组合进行处理。无论是 AWS App Mesh、Azure Service Fabric应用、GCP Service Mesh，还是 Kubernetes 中的容器。 在考察云供应商以及寻找支持本地开发的方案时，需要将这一方面的内容考虑在内。
相关文章：探索微服务和 C++组合的潜力
使用 Kubernetes 执行 CI 构建工作和通用处理任务
企业级 DevOps 和变化管理
在企业环境中，变化管理不仅有益而且不可或缺！虽然我们可以随意修改较低层级的环境，但任何面向客户的内容都必须以更高的管理和审核要求对待。为实现这一目的，变更管理工作流程应包括企业级 DevOps 各方面的内容。
在开发过程初期就让 DevOps 工程师参与相关工作可以帮助团队识别生产中需要作出的潜在变化。企业级 DevOps 通常更为先进，并且已成为许多开发团队奉行的文化。在 IaC（基础设施即代码）等常见方案的支持下，它已经成为常规工作流程的一部分。这种领先变化一步的理念帮助企业实现变化管理流程，而不是将变化管理视为阻碍。
企业级 DevOps 引导策略
我们针对代码库应用的任何策略扫描工具都有助于我们在进行合并和引入无效代码的问题方面拥有更多控制权。这些工具以及 Git “pre-commit 钩子”等技术可以帮助我们避免不符合要求的代码。简而言之，此类技术有助于确保合规性，而开发人员将成为阻挡不合规内容的第一道防线。这会促使企业级 DevOps 通过开放策略代理 (OPA)，使用 Conftest 或 Kubernetes GateKeeper 等工具实施自动策略。
在 CI/CD 管道中使用的其他工具则有助于在完成流程的每个步骤时确保遵守策略要求，包括从代码提交到构建再到发布的整个过程。而且许多工具的设计都旨在帮助引导团队在不影响效率的前提下遵守策略。从多个角度来看，这种企业级 DevOps 方案都能让我们在晚上睡个好觉！为了实现这一目标，文化层面的转变往往是需要考虑的一个主要问题。
企业级 DevOps 文化
我们不该驻足于自动化的流程和程序优化层面。企业级 DevOps 方案成功的关键是对这种文化本身的投入。与其把 DevOps 看作是资源，企业团队不如把它当作一种思维模式。每个人都应该参与到该过程中，从产品经理到发布工程师，每个人都坚持这种思维模式。在某些组织中，采用这种模式的结果就是 SRE 方法论的应用，与传统 DevOps 一起使用或用作替代方案。
企业级 DevOps 文化和思维模式最初是有利于扩展的工具，但后来会成为成功实施企业级 DevOps 的关键。让每个人都站在同一起跑线上，推动消息灵通的团队成形，创建增值文档，监控关键系统，并掌握标准和要求的最新情况。如果每个成员都将企业级 DevOps 放在首位，那么团队也就步入了成功实现企业级 DevOps 的正轨。
总结
你可能也注意到，企业级 DevOps 从很多方面来看只是小型组织中传统 DevOps 的延伸，从与使用的各种堆栈有关的考虑因素，到合规性和变化管理等细节方面。
践行企业级 DevOps 的人正在获取相关知识，并应用到更大的项目中，从而与今天的业务发展节奏保持一致。人们期望实现的成果是什么？是一台能够帮助指引团队所有成员在成功、合规和可靠的技术环境中工作的良好运作的机器。
你可能在想“DevOps 不就是 DevOps 吗？”并非如此。在小公司内，DevOps 主要是用于提高效率的工具。而对企业而言，它的能力则远不止于此：它是企业成功的关键组成部分，处理着业务中风险最大和最重要的任务。这需要改变 DevOps 的运行和处理方式，向企业级 DevOps 的实践和思维模式转变，就像这篇文章中描述的内容一样。
