返回 登录
0

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

阅读444

本文转自微信号EAWorld。扫描下方二维码,关注成功后,回复“普元方法+”,将会获得热门课堂免费学习机会!本文转自微信号EAWorld。

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

作者:Sarah Goff-Dupont
译者:半部春秋

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

她曾经热爱的工作,如今变得面目可憎。她身处一个伟大的团队,一个伟大的公司,并且担任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团队手册》可以为您提供帮助。

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

团队手册的地址:https://www.atlassian.com/team-playbook/

场景(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分支,这有一个免费教程
https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow

除非被证明可以进入生产环境,保持流程中所有杂乱无章的工作隔离孤立于某个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

关于作者:
莎拉是一位Atlassian敏捷交付传道者,之前是一名测试自动化工程师,还是简化书呆子式生活的忠实拥趸。例如,像持续集成和自动化一样。手动测试越来越变得枯燥无趣,她试图作出一些改变。她所崇拜的人包括玛格丽特·撒切尔夫人、麦吉弗和她的母亲。

关于EAWorld
微服务,DevOps,元数据,企业架构原创技术分享,EAii(Enterprise Architecture Innovation Institute)企业架构创新研究院旗下官方微信公众号。
扫描下方二维码,关注成功后,回复“普元方法+”,将会获得热门课堂免费学习机会!
微信号:EAWorld,长按二维码关注。

图片描述

评论