DevOps与合规性：鱼和熊掌兼得指南

Posted 2021-04-16 DevOps时代

编者按：很多行业身处强力监管领域，因而格外强调合规性。反映在IT上就是开发、部署和运维等规范（比如开发团队不能碰生产日志）的不可或缺。本文中提到的一些方法（如自动化测试、自动化合规性及安全检查）和步骤将帮助团队获得合规性与DevOps的融合之益。

“哎呀。真要命……”玛丽亚关闭了另一个浏览器选项卡（上面有她不打算申请的另外一份公开招聘启事），歇斯底里地吼道。她恼怒地一头撞在桌子上，她之前压根没想到会像现在这般痛苦。天哪，究竟是怎么回事？

她曾经热爱的工作，如今变得面目可憎。她身处一个伟大的团队，一个伟大的公司，并且担任IT和工程主管的要职，她的转角办公室视野空阔，一眼就可以看到室外的美好景色。后来，SplinterTech上市了。她满脑子都是她的团队现在务必遵守的多如牛毛的规则（PCI，SOX，HIPAA），她满以为这一切都可以轻易搞掂。但实际上这几天都做了些什么？理想很丰满，现实很骨感，目前的境况跟想象的完全不一样。

写那些含糊不清的文档本身就已经足够把人的魂儿劈成两半儿了，更别提还有代码评审。

（此处原文作者用的是drain a person’s soul in two releases。《哈利波特与混血王子》一集中引入了魂器的概念，就是把灵魂分成几份来对付敌人，编者猜想，这大概是作者埋下的一个梗）。

她的团队并不抵触审查代码，只是他们似乎无法有效地完成这一工作，这是代码审计时所应承担的责任，这还会危及SplinterTech的声誉，甚至有可能砸了2500人的饭碗。

对，现实就是这样：压力实在太大了。

“哎，瞻前顾后有什么用，能解决什么问题呢？”玛丽亚心想，“可以跳槽逃避这一堆麻烦事，但是，这种畏畏缩缩的行径并不光明磊落，压根不是我的风格。”她凝视着墙，墙上是装裱得很精美的文凭；这些文凭提醒她，她多才多艺、风光无限，但这些东西对她毫无意义，无助于解决她目前的困境 。

与玛丽亚相似的境遇比比皆是，并非孤例。合规性和根管治疗一样激动人心。从好的方面来看，它不需要承受根管治疗那样的痛苦。

您现在可能已经听说过DevOps。您甚至也像我一样认可“DevOps实际上可帮助团队满足合规性标准”这一观点，因为自动化不仅是DevOps的一个完整部分，而且是可以确保研发和部署实践的可靠性、可重复性和可追溯性的一个非常有效用的方法。更何况，自动化加速了整个过程，这有助于您与竞争对手同样快速（甚至更加快速）地往前推进。而DevOps强调文化的透明度，在需要进行代码审计的时候，它会让您受益。

我相信对于技术团队来说，完成开发速度，透明度和开发纪律之间的融合是个穿针引线（threading the m-fing needle）的精细活儿，这种事儿不会一蹴而就，但是你可以按照“虽然不容易但是完全可行”的步骤达到目标。

步骤1：识别并记录影响，您的团队的所有规则

这是常识，也正因为如此，所以往往很容易被忽视。确保您的团队成员和利益相关者知道您需要遵守什么规则、您将如何着手处理与这些规则相关的合规性，以及在哪里可以参考这个规则——毕竟大家不可能过目不忘、事无巨细记得一清二楚。为了避免“文档版本地狱”（ 顺便说一下，这也是一个专业术语），把这些规则信息全部记录在维基页面上，然后再链接到团队门户和Dashboard等地方。如果如果能做到以下这点就更好了：在页面上将关键人员指定为“观察者”，每次页面有信息更新时观察者都会收到通知。

步骤2：把待办事项自动化

一旦人们了解什么是重要的内容，以及为什么如此重要，您就可以设置自动化，使合规性变得更为容易。首先选择可以从手动转换为自动化的重复性任务，通常有如下几类：

合并请求（Pull requests）——虽然应该总是进行细致的、人工的审查，但您可以自动化繁琐的部分，如确保两个或更多的审核人员批准PR（Pull Request），并且确保不存在与该提交相关联的失败构建或测试运行。

代码覆盖率（Code coverage）——测试覆盖率低于某个阈值时触发失败构建，随便哪种说得过去的CI / CD工具都可以干这个活。

连点成线（Connecting of dots）——确保代码更改、代码审查、构建结果、部署和事务卡片（issues）都链接在一起（这样，您就可以通过单击鼠标来从一个点到另一个点）。日事日毕更为简单，审计也更容易。

权限（Permissions ）——安全……自动化的确可能带来安全问题。但您可以设置库管理器，以便只有某些人可以在特定的代码仓库和/或分支中进行更改，并且没有人可以在生产环境中实施变更。

注意：根据DevOps的原则，默认情况下，所有代码仓库和分支都应该开放只读权限。而且，这种透明化更加简单实用。

审计跟踪（Audit trails）——通过自动记录构建/测试和部署结果来形成完整的信息路径。然后再链接代码提交、评审和前文提到的事务卡片（issues）来完成闭环。

故障切换和恢复——自动回滚有问题的部署，比使用手动更不容易出错。而且它是可追溯的，速度更快，这有助于您满足服务级别协议（SLA）。

确保将此类工作纳入每次迭代，这样您就可以一点点的把他们溶入到日常工作中，并且不断复盘。“我们对分支的访问控制是有效的还是矫枉过正？”……“我们的代码覆盖率是否让审计员更加满意？”……等等。诀窍在于履行您的义务而又不会自设藩篱。在这里，还有一些穿针引线的事情要做。

步骤3：培养文化

平心而论，这应该是与步骤1和2同时发生的，因为,在DevOps领域，文化始终是重中之重（但是，（如果在每一点都列示文化的重要性，编者注）这个“始终”会搞砸我漂亮的编号列表，就这样吧）。

如果您的团队缺乏沟通、互相指责和/或角色和责任不明确，简单地把一些事情自动化就完事显然毫无裨益。将您的团队凝聚在一起，以确定您的问题所在，并弄清楚您将如何解决这些问题。听起来很繁琐困难，但不要恐慌、乱了分寸：《Atlassian团队手册》可以为您提供帮助。

（手册中有三个概念，健康监测器、场景和用例，以下为便于理解，我们将三个部分添加了小标题，编者注）

• 场景（Plays）

透彻了解症结所在以及为何出现这些症结的团队，可以直接转到手册的场景（Plays）一栏，根据自己的痛点来选择适合的场景。无论您是饱受“沟通障碍”之苦，抑或是深陷“领导力缺失症”，都没有关系，《手册》将提供一些方法技巧，让您悬崖勒马，重回正轨。

请记住，Plays不是额外的工作。它们只是以完全不同（以及有效）的方法来完成你本就该做的事情而已。

• 团队健康监测器（Health Monitors）

然而，在许多情况下，一个团队因为不得而知的原因而功能失调。在这种情况下，团队健康监测器（Health Monitors）应运而生。通过团队健康监测器，您的团队可以自我评估在高绩效团队中常见的八个属性，并找出需要改进的地方。您还可以获得有助于改进弱点的Plays建议。

• 用例（Game Plans）

为便于实践，《手册》提供了一个专门用于构建DevOps文化的“Game Plan”—— “悲观预测法” （Pre-mortem，假定最坏的情况发生，来考虑对策）或“约定规则”(Rules of Engagement，协同定义社交规范来促进团队合作)等流行的Plays。Game Plan可以让您少走一些弯路，但是您仍然应该使用健康监测器来了解您的团队的工作。必须审慎对待。

最后，不要忘记，循序渐进的胜利也是来之不易的，值得为之庆祝。 即使是“站会”上短暂的击掌（ “代码覆盖率提高了20个百分点——很成功，Give me Five！”），都是可以保持势头，士气高涨，创造奇迹的筹码。

（站会是敏捷开发的一种实践，团队成员用简短的时间围圈站立交流工作）

步骤3：培养文化

现在，您正在走上了团队健康的正途，现在该开始改进工作流了。退一步，寻找可操作的快速进步。例如，对于团队而言，比较常见的方法是，通过采用Git（或者偶尔采用Mercurial）实施DevOps来部署feature分支工作流。

除非被证明可以进入生产环境，保持流程中所有杂乱无章的工作隔离孤立于某个feature分支，保证您不会出现“oh $#!τ”的时刻——例如，当您意识到您刚刚反格式化了生产日志中的客户数据，就是这样的时刻。此外，您可以使用前文提到的权限自动化,从而更好地控制从分支到分支以及从环境到环境的变更流程。

还要检查在所需要的地方是否达到了你所需要的代码覆盖率水平。“实例化需求规格” 方法在这里大有可为。根据这一方法的合规性进行工作，从而可以了解合规性失败会是什么样子（比如，就如之前的生产日志中客户数据的显示问题，事先定义日志中数据的显示方式），然后编写一些测试代码，一旦触发了这些条件，这些测试代码可以导致构建失败。

一旦您有了健壮的自动化测试，您就有能力根据您所使用的特定规则，来将构建自动的推送到下一个环境。再次提醒：自动部署是您的良师益友。他们是可靠的和可追溯的——这两个特点都是审计员所钟爱的。

那么，还有可以通过自动化来消除的其他一些开销吗？例如，如果您使用JIRA Software跟踪您的工作，则可以将其与Bitbucket集成，以利用“智能提交”，自动将相关问题转移到工作流的下一步，并节省了返回敏捷板（agile board）的步骤。或者您可以将存储库管理器与CI/CD工具集成，以便在创建pull request时自动触发构建。

这是一个进程，而不是整个工作的颠覆。

您现在是不是有点头晕目眩找不到方向？不要紧张。从逻辑视角，一事一议，不断迭代，将使转型过程更加易于管理。还记得本文开头的玛丽亚吗？一步一个脚印的改善使得她的团队回到正轨。如果说这很容易，那我是在自欺欺人。但他们做到了，现在他们沟通得很好，状况大为改观。

为了在技术方面提供帮助，请考虑切换到BitBucket Server或Bitbucket数据中心等Git仓库管理工具。像您一样身处管制行业的团队，正在利用Bitbucket支持工作流的执行（如，要求绿色构建或代码审查的多重审批）、项目级管理控制和细粒度权限功能。

如果您已经在使用Bitbucket服务器/数据中心（看看，您真是越来越上路了）并希望加强您的持续集成实践，那么，可以考察一下Bamboo。它具有一系列合规性-使能（compliance-flavored）的功能，如项目组织、权限，以及与Bitbucket服务器和JIRA软件的深度整合。

一点点灵巧的工具作业，加上大量正确的文化和实践，是享有DevOps方法的所有好处而不违反合规性规则的好方法。谁说鱼和熊掌不能兼得呢？

原文链接：https://www.atlassian.com/blog/devops/how-to-make-compliance-easier-devops

有了好的工具，还要好的落地经验！DevOps 落地实施的灯塔！DevOps 国际峰会 · 深圳站，11月2日，在深圳等您！

点击阅读原文，对接 DevOps 标准！