专栏首页EAWorldDevOps与合规性:鱼和熊掌兼得指南

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

编者按:很多行业身处强力监管领域,因而格外强调合规性。反映在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(eaworld)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-09-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • DevOps落地实践及案例分享

    银行业为了应对业务的快速变化、互联网层面不穷的业务形态和交易压力,IT“双态(或双模)化”无可避免,开始探索部分业务参考互联网的方式引入分布式架构,但对于银行业...

    yuanyi928
  • DevOps转型陷阱与核心实践指南

    2010年,我曾在IBM供职,开始参与DevOps相关的产品研发与实施工作。今天看来,我也许是国内较早的DevOps践行者。这两年DevOps在国内开花结果的时...

    yuanyi928
  • 用Ansible部署ELK STACK

    ? 作者:Daniel Berman 译者:张斌 想要重复部署你的ELK STACK更方便一点?在这篇帖子中,我们来看看如何通过使用Ansible来实现这一...

    yuanyi928
  • Selenium Webdriver 3.X源码分析之alert.py

    > Selenium Webdriver 3.X源码分析系列第6篇,该系列原则上会将整个源码分享一遍

    苦叶子
  • Java代码审计-铁人下载系统

    初学 java 代码审计,跟着表哥们脚步,走一遍审计流程,就选了个没有使用 Java 框架的 java 系统,作为入门。

    信安之路
  • 统计自然语言处理-基础知识

    数学我工作这几年时间,基本把之前学的忘光了(虽然学的也不咋地!?)。但做数据,最重要的就是清晰的思路!而数学,大概就是训练人的逻辑性很好的途径吧。好了,开始本周...

    数据处理与分析
  • 星巴克推出小程序了!这次不卖咖啡,而是发「好人卡」

    4 月 6 日,全球最大的咖啡连锁品牌星巴克上线了一款小程序,取名为「星巴克用星说」。

    知晓君
  • 加锁还是不加锁,这是一个问题

    上次我说过, 我们这个线程的世界是个弱肉强食的地方, 大家为了争抢资源大打出手,时不时闹出些内存数据互相被覆盖的事故, 给人类带了无穷的烦恼。

    帅地
  • 星巴克数字忠诚十五年|洞见

    2017年初,一条消息令所有北美零售商震动:星巴克用户所有存储在礼品卡和移动应用中的现金超过12亿美元,而这一成绩,超过了绝大多数美国银行机构(下图)。 ? 在...

    ThoughtWorks
  • PHP进阶资料

    luxixing

扫码关注云+社区

领取腾讯云代金券