DevOps 文化中的合规性

何时使用它

如果要测量的属性集很小，版本发布不频繁，并且响应很简单，那么这可能是一个简单易行的流程。对于小型合规流程的实施，不需要大量资源或时间投资。它可以像为团队创建 Google 表格以填写和提交一样简单。通常，这种类型的实施还涉及手动审查流程，通常作为与审查会议相关的正式批准来实施。

随着组织的规模扩大，此流程很快就会变得很痛苦。额外的规模会带来挑战，这些挑战会由于工作量和复杂性的增加而体现在多个维度。

容量挑战源于组织规模扩大带来的工作量增加。随着组织的增长，运营合规流程的能力必须与之成比例地增长，以处理额外的合规批准请求。由于部署批准请求的随机性质，中央合规团队的工作流程变化很大，因此为快速响应而调整中央团队的规模成本很高。随着组织的增长，这个问题会加剧。

复杂性挑战随着组织的规模扩大而出现，创造了新的和令人兴奋的故障模式，进而推动了合规流程的改变。合规表格的大小和复杂性不断增加，需要开发团队和合规团队花费更多的时间和精力来完成流程。

当合规流程在规模上显示出其效率低下，并开始成为开发团队交付业务价值速度的限制因素时，可能会出现二阶效应。

团队可以通过将更改进行批处理来专注于成本效率，这样，发布的价值的开发工作将占部署这些更改到生产环境所需的总成本的很大一部分。

合规流程的交付周期也会决定批次大小，因为合规办公室的工作能力限制了在给定时间段内可以处理的部署请求数量。在部署数量有限的情况下，增加交付给客户的价值的唯一方法是增加批次大小。

如果合规办公室因任何原因超负荷，那么等待合规结果的团队队列就会增长——合规流程本身就是一个限制价值交付的瓶颈。通常，交付压力会压倒合规流程，开发团队会积极地滥用、破坏或完全规避合规流程，导致“影子 IT”、设计和架构决策受损，甚至伪造合规响应。

我们在商业和政府领域内的组织中都观察到了所有这些行为。我们已经看到了手动合规流程，这些流程实际上需要 6-9 个月才能完成，然后才能将新服务或系统部署到生产环境。在另一家客户那里，我们能够证明他们的流程不仅限制了组织交付的速度和规模，而且该流程在应用和最终结果方面高度不一致。

不幸的是，我们的经验表明，手动合规流程是一种“安全表演”，导致价值交付延迟，而没有实质性提高系统的安全性和安全性。我们还看到这些流程对交付流程以外的影响远远超过，影响了组织结构、架构决策、领域边界，甚至人员配置和人才保留。

何时使用它

显然，合规测试的自动化对合规办公室和团队中的开发人员来说都是巨大的优势。

合规办公室可以确信正在执行适当的合规适应性函数，并且管道日志可以提供记录适应性函数执行和结果的审计跟踪。团队可以专注于交付业务价值，而不是通过确保管道执行所需的操作来控制单个更改。

团队中的开发人员可以更快地获得有关系统发布是否满足合规要求的反馈（至少对于已作为适应性函数自动化的那些要求而言），因为管道中的故障表明未能满足合规要求。

在同构开发环境中，每个团队都使用相同的堆栈，构建大致相同类型的系统（例如 REST 服务等），团队可以通过复制标准管道来实现效率提升。至少，共享相同的合规适应性函数将在同构环境中产生规模经济。

组织对生产环境中故障的常见反应是在部署流程中添加手动验证步骤。例如，适应性函数可以定义为“所有工作已完成并且存在回滚计划”，这必须由团队经理和安全官手动验证。这并不理想，因为它会导致对名义上对系统负责但实际上并不负责（即熟悉）他们批准的更改的角色的排队工作。 [2] 净结果是额外的延迟，但没有对系统的安全性或稳定性进行具体改进。

另一个典型的反应是希望锁定管道以保证合规性。当生产环境中出现某些故障时，这可能会发生，也许可以追溯到团队特定偏离标准管道的行为。组织将管道合规流程的责任转移到一个中央团队，目的是将每个团队的系统发布通过相同的“黄金”管道。

我们的经验表明，由于团队管道中变化的频率很高，因此管道中央所有权是开发流程中最大的摩擦来源之一。这种集中化会导致开发速度整体放缓，因为中央团队已成为限制团队改进其系统的瓶颈。

二阶效应类似于手动解决方案：“影子 IT”、设计和架构决策受损，或在没有更新的合规管道的情况下部署到生产环境。

我们知道，在某些情况下，这种中央“所有权”决策是出于明确的减缓发布速度的愿望而做出的。虽然很少公开说明，但组织已经意识到，更频繁的发布通常会暴露其开发流程中的系统性不成熟。转向中央控制通常是试图将交付质量的责任从工程和开发团队转移到合规组织。

随着时间的推移，产生的摩擦程度难以估量。管道存在的首要原因是在软件开发流程中提供一个中央工具。当它被征用并随后为正交目标控制时，开发人员的关注点往往会根据管道团队（通常是 DevOps 团队）的人员配置、组织、激励和运营方式而降低优先级。

何时使用它

对于具有符合构建块功能的要求的团队来说，这是一个很好的解决方案。这些“黄金映像”代表了团队原本需要实现的业务或技术能力，并且这些映像已经通过了合规性要求。例如，依赖黄金 PostgreSQL 映像意味着团队不需要考虑如何配置备份/恢复、数据库调优、部署、日志记录或操作注意事项。所有这些活动都已作为通过合规性的 PostgreSQL 构建块的一部分完成。

鉴于成熟的构建块集合、同构开发环境和需求变化较小的业务需求，这可以通过避免跨多个开发团队的重复工作来提高效率。

当这些基本假设和限制被违反时，与组件组合策略相关的摩擦就会出现。任何需要现有“黄金映像”范围之外的功能的产品开发也需要开发团队对其系统中的这些“非黄金”组件进行相同的繁琐合规性流程。一些团队可能会认为这样做存在相当大的进度风险，这可能会对系统的架构和设计产生不当影响。

此外，这是一个滑坡；在滑坡的底部，组织并没有变得更好，因为每个团队都在管理其自身特殊情况解决方案的合规性。有人可能会争辩说，使用合规映像作为定制的基础，将合规性工作限制在增量更改中。但是，由于这些共享的“基线”映像，团队之间的耦合增加了。合规性单位仍然是整个映像，因此随着时间的推移，合规性的边际成本可能比人们想象的要大。

将责任转移到中央团队以提供合规映像具有与上面提到的管道集中化时相同的特征。

随着组件组合解决方案在规模上显示出其效率低下，它也开始成为限制开发团队交付业务价值速度的因素。二阶效应类似于手动和基于管道的解决方案：“影子 IT”、设计和架构决策受损，或部署到生产环境中未通过合规性要求的组件。

我们观察到，遵循这种模式的系统在不同规模的组织中表现出不同的行为。在小规模或实施这种模式的早期阶段，很容易找到需求相似的团队，在那里依赖合规构建块的经济效益是显而易见的，并为团队提供了加速。但是，超过一定规模后，交付的解决方案的需求就会分化，导致在团队无法依赖合规构建块的地方出现熟悉的摩擦来源。

注意：我们故意回避了合规性是否实际上对一组合规容器映像的组合是分配的这个问题。假设这是真的，它可能只适用于完全不可定制的精确容器映像，这反过来可能会将解决方案空间限制到如此程度，以至于它没有实际效用。我们鼓励您认真思考在组合合规性的范围内可以实现哪些类型的可配置性，以及与您的用例相关的可配置性。

何时使用它

此解决方案有助于最大程度地减少先前描述的解决方案中存在的瓶颈。它本质上比上面描述的解决方案更复杂，因此可能仅限于组织规模会创建此方法能够解决的瓶颈类型的环境。

通过分离合规性问题，我们可以实现避免与集中管理的合规性方法相关的摩擦所需的松散耦合。团队可以选择采用集中提供的管道控制集，同时仍然能够有效地自行管理团队可能具有的任何独特要求。

如果合规性约束经常发生变化，组织可以有效地确定对现有系统的影响，从而减少计划工作并简化实施流程。“代码即策略”原则保护团队免受额外工作的影响，因为应用测量测试来收集证据的流程没有改变。

由于合规性流程的所有输入都基于数据和配置，因此审计流程得到了显着简化。在任何给定时间点，都可以通过查询 SoR 来获取证据集和验证流程的结果。

如上所述，由于关注点的分离，该解决方案稍微复杂一些。但是，复杂性适当地存在于合规性办公室内部，而不是委托给整个组织的每个开发团队。

必须明确解决流程中的信任问题，作为 SoR 和相关密钥管理的一部分，这些必须由合规性办公室管理。虽然在批准新测量测试的流程中存在熟悉的瓶颈，但这些瓶颈的范围更有限，因为单个工作项（即就测量测试的适用性达成一致）明显更小，并且不会显着阻止团队进行开发。

仍然存在“影子 IT”或将未通过合规性要求的生产组件部署到生产环境的风险。但是，设计和架构决策被破坏的风险大大降低。

多年来，我们一直在多个客户中实施这种模式。对于一家大型企业组织，我们实施了一个自定义准入控制器，该控制器确保符合部署要求、安全性和证书，使用提供 CVE 扫描容器的可信容器注册表，并验证适当文档的存在（或创建）。在另一个组织中，我们实施了类似的功能，此外还集成了一个“代码即策略”解决方案，在部署之前对 Kubernetes 配置执行 CIS 基准测试。