开发运维自动化治理

我如何卷入这真的很多东西,但是我想我会开始的地方至少我能够激发这个想法到纸上,然后我做一些进一步的文件但是…基因金,一部分革命,凤凰城项目的作者,邀请约40人每年去波特兰,我们已经做了7年,我们这些论文,成为论坛论文,电子书,我一直这样做,我认为,2014年是第一年，所以我每年都这样做。总的来说，包括今年在内，我们刚刚完成了四到五本书，将于今年夏天出版，我想七年内会有大约30本书，所以我一直参与其中。其中一些我分享了我参与的项目，多年来，我只是在许多书中漂泊。所以，有些年我喜欢在不同的项目之间来回切换。
但我指出这一点的原因是，从2015年开始，有一个工作小组，我与他们间接合作，制作了这本电子书，所有这些都在知识共享资源上，你可以从IT革命论坛的论文中下载。它被称为“一个不可能的联盟:DevOps和审计”，所以这至少是从DevOps It革命的角度来看。关于如何审计和我们如何处理DevOps的第一次对话应该有一个更紧密的对话。职责分离，那些需要证明的东西我们也在DevOps手册中讨论过。我们讨论了模式的某些方式，如果您可以使用DevOps来交付软件，那么它们实际上可以像其他的一样应用于某些遵从性需求。然后在2018年，这是一篇很棒的论文，我没有写这篇文章，但我是一名顾问，正在研究它。这首歌名叫《亲爱的审计员》，非常棒。
这实际上是一封给审计人员的道歉信。比如“嘿，我们真的很抱歉，你知道，我们应该这样做的，我们应该和你谈谈这个”这不仅仅是一封道歉信，它还有一个我们承诺做的事情的清单，实际上，如果你搜索“亲爱的审计员”实际上是一个关于这个的Github项目，这真的很好，这个线程是关于审计和DevOps的。
几年前，我开始有了一个想法，从审计的角度来看，我们如何做得更好，所以去年，2019年，实际上，这些论坛通常在4月左右开始，我们通常在第四季度或第三季度末或第四季度的某个时候发布工作。因此，我组建了一个团队，真正专注于我们所谓的DevOps自动化治理和它的参考架构，我将更详细地解释这一点。所以,几件事情前一年之前的两年让我真正感兴趣的,Capital One多年来一直积极参与这些论坛论文,多年来我们已经讨论管道、闸门的管道,在2017年,Capital One写了一本非常有趣的论文他们如何做,你知道,关注DevOps管道有一个分段称为“创造更好的管道”,这是什么他们谈论这些门,他们称之为16门。这些东西允许服务团队绕过像cab这样的中央权威。换句话说，他们可以得到一种自动部署许可，如果他们能证明这些东西确实来自于源代码控制，它有最佳分支策略，静态分析，所有这些东西。
我记得我去年看过一个报告，他们说他们现在有30个。但在讨论这个问题时，有这些门是很好的。但是，既然你有这些门，我们就不能把它们变成证据吗?所以在一年左右的时间,我们一直有这样的对话,可以说是让我开始思考这个,然后在文章的同时,谷歌宣布一个开源项目叫做Grafeas事实证明这是一个项目,他们是用内部审计治理,它有很多功能,我认为很多功能还没有被利用,但在特定的一个认证,元数据认证,认证的证据。我开始思考，Kit Merker，我的好朋友，也是青蛙，在青蛙公司工作，他找到我问我为什么不考虑使用Grafeas我们聊得很开心。这让我想到了去年，我试着让一群人聚在一起，说:“嘿，我们能围绕这个自动化治理的想法创建一个参考架构吗?”
你们知道，这些条款是非常超载的但是我们有一个具体的章程我们想要在这个特殊的。所以我们实际上发布了，这是，这是知识共享，它是，正如你之前看到的，它是去年9月发布的实际上是来自Saber的Mike Nygard。你可能知道《释放它》中的Mike Nygard，断路器模式的发明者，Capital One的Tapabrata Pal, Steve Magill, Sam Guckenheimer，他参与了微软的大部分基础设施，我自己，PNC的John Rzeszotarski, Dwayne Holmes在万豪酒店管理大型Kubernetes基础设施，以及Nike的Courtney Kissler。所以我们聚在一起讨论了几天，我们试着讨论一下，我们是否可以把这个作为参考架构写在一篇论文中，比如最终模型是否可以是一个微服务Java，放在一个容器中，可以直接进入Kubernetes，使用Grafeas和kritis。因此，我的目标之一是改变审计人员如何创建证据的语言。通常情况下，审计员来到一个地点，他们在附近的某个地方，花30天的时间和组织一起工作，观察变化，他们真正做的是，证据实际上是主观的。所以证据和证明，在这个对话中，是同一个意思。因此，改变主观证据的想法，将主观证明变成客观证据或客观证明。
因此，目前人们在大多数大型企业中创建变更记录。然后这是一个人类的讨论，比如苏要做这些事情，鲍勃会读这些东西，也许莎莉想让苏再加几行。这些都是复杂的系统，所以…这通常是一个人类的电话游戏，试图记录变化的复杂性。然后，审计员来了，看到了这个关于联合的讨论记录，主观的讨论作为证据，然后试图弄明白这一点，这是很辛苦的，这是很多脱节的，这是。它只是没有很高的效果。那么，我们能改变这一点吗?让这些证据成为自动化的，非人为干预的，自动化的，内置在数字签名机制中的管道本身。它是一组签名，基本上变成了一个不可变的签名链表。所以，当我们坐下来考虑写这个东西的时候，我们有三个目标。一是缩短审核时间，能否把30天的审核改成半天的审核?
这个想法是，除了主观的讨论和比较丝网版画，我们是否可以展示一个不可变的列表，我们真的不想叫它区块链，但它是基于区块链模型的，你是否可以展示一个不可变的列表，证明一个没有人类参与的变化，实际上，没有人类的互动，所以字面上，你只是看着这些不可变的列表，然后下一个，下一个，下一个。第二个问题是，我们能不能提高疗效?我的意思是，事实是，在过去的三四年里，我花了很多时间和CILs在一起，然后采访了一个组织中的很多人。大多数人，他们的大多数审计，我称之为安全和合规剧场，当你进入云原生和微服务的现代化时，这甚至不包括在内，甚至更糟糕。所以他们认为在这种快速部署结构中需要证明的风险概况是完全脱节的。所以你会发现在大多数组织中，审计的效率非常低。
所以我们能不能把审计的效率从20%提高到90%最后但并非最不重要的是，如果我们能做到这一点，我们可以提出一个有弹性的论点，即摆脱顾问委员会或CAB或中央集权的改变，你知道，如果你想想最初的第一资本文章。所以我们坐下来，我就不详细讲了因为这是参考建筑。我只是想让你们了解一下这些想法，如果你们感兴趣，可以下载知识共享版本，在ITrevolution.com上。所以我们把它分成七个阶段，我们的想法不是真正关注人们如何看待管道，而是为认证创造界限。记住每次我说证词，我指的都是证据。那么，认证的逻辑阻塞或边界是什么呢，所以我们提出了一个开发构建，在它自己的阶段打包，非prod/prod，我们把依赖和工件放在一起的原因是，它在传统CI/CD路径的生命周期中，但依赖管理工件有自己的生命周期，有点像异步的。所以我们想确保大家都理解这一点。
然后我们同意了所谓的公共控制和公共参与者这些控制基本上就是证明。所以，如果你还记得我之前说过的话，那就是耐克、Capital One、PNC、万豪和Saber Group。当一切都准备好了，我们有大约75个证明。现在我不认为一个公司或一个组织或一个服务会使用所有这些，但它是一个参考工件，以显示可以完成什么。我不打算详细讲，但如果你看源代码阶段，比如出现在轮询请求或单元测试覆盖，清除依赖，扫描，如果你到构建阶段，单元测试，检测，从输入/输出角度看的不变性，我故意讲得快一点因为如果你感兴趣的话，所有这些都是拼出来的，大概有两页，三页每一个控制点的聚合,依赖管理、许可检查,批准了外部资源,安全检查,老化,所以不允许失效构件,通过版本,包,公证,或签名的签名,或者如果你想从一个动物园管理员之类应用元数据操作时确保元数据不能砍,也不能站在中间的那个人,所以很多在这里,就像我说的75工件阶段,保留期，不可变工件，产品阶段，然后如果你看prod, prod或非prod，一些细微的差异，但允许配置。
因此，当您处理Kubernetes和容器时，对手有很多机会通过错误的配置定义来创建对手。所以要确保你捕获了这些东西作为证据，然后我们要做的是通过一个例子，而不是推荐，只是一个例子，说明控制点在哪里，它们来自哪里，像SonarQube或Checkmarx，当然还有JFrog x射线，但这些都不是真正的推荐，它实际上只是一个。
对我们来说，这是一个让我们理解的练习，“这有意义吗?然后，“我们能快速浏览一下所有这些证明可能来自哪里吗?”随着项目的进行，我们并没有完成我们想要完成的所有事情。最后，我们用Grafeas和Kubernetes做了一个骨干架构的参考架构，我们想做这个简单的_在管理控制器中，它的符号非常简单。但真正有趣的是，当我们进行这些对话时，当我们写论文时，晚上我们去吃饭，所有写论文的人都会出去玩，然后我们开始思考，如果你能创建DevOps自动化治理架构，那么我们是否可以开始考虑模板，比如，这些东西的明智模板。
如果你能做到这一点，你能创造出人类可读的代码来应用这些模板吗?所以这实际上只是一次晚餐谈话，但其中一家银行走出去，全身心地投入其中。他们投入了大量资源，我们现在称之为“政策2022世界杯阿根廷预选赛赛程即代码”。所以我们今年夏天要做这个，开始这个文件的第二个版本，我们将真正关注政策，我将向你们展示一些东西，作为。
作为我的顾问，但其中一家银行真的把它提升到了一个全新的水平，并发布了参考架构。这是一些治理的原则，人类可读的，平台无关的，持久的，我会让你们再看一下幻灯片，条件参数。但事情是这样的，这家公司所做的是进入并创建了他们所谓的包文件，政策是代码文件。有趣的是，这些是人类可读的文件，政策制定者们正在参与其中。实际的政策的人,所以现在发生了什么,服务所有者想经过这可以说是新定义的方式处理事情,和有很多的优点,所以人们想要做到这一点,他们必须去政策的人,这是由设计和政策的人,然后他们会想出一个人类可读的包文件将与该服务相关的定义,然后所以我们与之交谈过的证明之类的东西会被定义。如果你看管道版本控制，每个应用或服务都必须有实际组件的助记符，必须有服务的助记符，组件ID和版本。
然后你可以把它看作是单元测试覆盖，然后你有一个pull请求审查，所以这些东西实际上是与服务所有者，与实际的策略人员合作编写的，顺便说一下，现在策略人员来设计需求，这些变得不可变，因为它们实际上与工件一起存储在源代码控制中，因此他们可以交付服务。所以没有，你有DevOps自动化治理体系结构，我将在一分钟内向你展示它是如何发展的。发生的是每次你做合并时，你会拉入所有提交的证据，你会拉入当时的包文件和所有其他工件，那将是不可变的证据它会在这个例子中，在Grafeas和认证存储中结束。
所以现在你得到了两个世界的好处。没有政策制定者试图把电子表格交给基础设施人员，服务人员，服务人员不得不把这些电子表格解释成可能被封锁的东西，很少有证据。现在你什么都有了，你有了门控和证据。这就是最酷的地方，我将向你们展示一家银行正在使用的架构。他们现在实际上在使用OPA和Rego如果你记得在那个包文件中，有一个版本控制管道，所以所有的服务都必须有助记成分反转。所以基本上你现在会想到的是接口定义是包文件是风险人员和服务所有者之间的协作然后实现可以是类似Rego的东西。这里有一个实际使用包文件和Rego在Kubernetes中从策略角度控制是否允许某事的例子。
这真的很酷。我的意思是，我们甚至在讨论下一个版本，如果你有了所有这些，你可以做政策航空预算，对吧?这是一个架构样本，它比这个复杂一点，但你基本上把Kafka放在了两端。实际上现在，我们正在努力弄清楚我们是否可以，我说的是我们处于顾问模式，但是，如果我们可以在两者之间放入一个无服务器架构，那么当你获得总量时，就像Kafka，无服务器实现，Knative，然后Kafka，然后进入这个执行器证据引擎，并且执行器可以与OPA集成。这真的很酷。希望在下一个参考体系结构定义中，我们能得到其中一些东西的开源，但无论如何，我们都会有一个非常健壮的参考体系结构来说明它是如何工作的。另一件很酷的事情是，根据我的经验，当今大多数企业都存在的一个问题是，很少有企业……
其中一个问题，让我回到这里，你在企业审计中遇到的一个问题是，它是基于，大多数审计是基于传统的服务管理模型，其中每个更改都必须与服务所有者相关联服务所有者传统上与CNDBCI配置项相关联。
我不能告诉你,我参观了在过去,你知道,三、四年,任何大型机构,诚实地告诉我,CNDB比25%更准确…所以如果你的整个模型的证据在审计是基于这种错误的想法,而不是基于像Git,发生的事情你知道,Github,各地的詹金斯,或构建模型…就像,这个模型的美,就是为了玩,你必须真正定义所以你真正开始创建一个紧急配置管理数据库因为你必须找到一个助记成分反转根据定义，所有在这个过程中建立和获得更多价值的服务实际上都成为了紧急NDB。不仅如此，您还可以查看连续的审计重播，因为我之前说过，这些工件是不可变的，而且您确切地知道包文件的哪个版本被推送，实际上Rego文件也在那个时候被推送所以您可以随时返回并进行重播。
另一件事，记得我们讨论过的关于航空预算的事情，所以现在你实际上可以分析持续的证据或持续的遵从性如果你想要或者我们称之为自动化管理的东西，是失败的东西，对吧?所以，我想说的另一个主题是，那篇论文发表了，我已经讨论了大约一年了，然后在纽约有一个组织叫做开放网络用户组，由一个叫尼克·里皮斯的人管理他们的董事会成员就像纽约乃至世界上最大的银行。今年的焦点之一是软件定义网络，SD-LAN，他们已经更多地转向DevOps，一些董事会成员看到了我们写的这篇论文，Nick Lippis认识我，所以他联系了我，问我是否愿意帮助推动基于我们写的那篇论文的云自动化治理。所以我们聚在一起，这一次我们创造了，这真的很酷，因为参与这个项目的人是联邦快递、凯撒医疗、信诺和摩根大通，而且我认为……
是的，摩根大通，然后间接地，Don Duet是高盛的工程副总裁，他现在是独立的，我们专注于从云提供商到租户的认证关系。现在我们快速地过一遍。再一次，这是一本知识共享的书，一篇可以从ONUG获得的论文。你知道，这很容易找到，你可以下载。你需要填写一些名字之类的东西，但这是一本免费的书。我们实际上，这篇论文得到了很多，大约一个月前，不到一个月前，华尔街日报写了一篇关于它的文章他们采访了，它实际上是由联邦快递，信诺和凯撒医疗机构赞助的，所以赞助这篇论文的三个公民社会组织接受了华尔街日报的采访谈论我们在这篇论文中所做的工作。所以这是非常非常重要的工作，我再总结一遍，我就不深入细节了，就像我说的，我离开你们，听众，读者，如果你们感兴趣的话，很明显我的联系方式会在这个演讲中到处都是如果你们想讨论的话。
如果有人知道我的话，我喜欢谈论或探索这些东西，但是。我们在这篇论文中的目标是，我们有三个目标，他们真正关注的是云提供商，向这些云的租户或消费者展示证据。所以我们想确定的一件事是，我们能不能问问社区，我也想说清楚的一件事是，最初我们坐下来的时候，每个人都说，“如果你能想到所有三家云提供商，或者所有五家云提供商，或者有多少家云提供商会接受你的建议，那你就疯了。”尽管我们在这个团队上投入了250亿美元，但我从一开始就说:“不要担心说服亚马逊、谷歌或微软，这不是我们论文的重点。我们的重点应该是，说服另外100家公司，这些公司将代表1万亿美元的资产购买力”，如果他们都同意这篇论文，那么也许我们会，顺便说一下，我们将在今年夏天推出第二个版本，并且已经有前三大云提供商中的两家加入了，所以任务完成了。
这是三件事。一个是，我们能否得到一个统一的格式?这意味着，每个云提供商都同意创建一个统一的…某种类型签名的标准化版本，告诉你他们所做的一切都没有改变。所以这是一个告诉你你知道已知状态的签名，他们不需要告诉任何IP他们是如何做到的，任何秘密武器只要让它保持简单，我知道它没有这么简单，但是想象一个校验和事件告诉你你所看到的任何东西的姿势都没有改变。所以它的规模对引导顺序的改变，或者引导基础设施实际上可能为对手创造新的机会，例如，所有事件审查的第一原则是，回到最后的改变。
因此，想象一下，如果我们能够在所有提供者之间保持一个事件的常态化，该事件在每次进行新部署或每天一次时告诉我们，该序列中没有任何更改。或者出了什么问题，我们可以检查一下这个序列。再一次，更多的细节。第二点是，既然所有云提供商都能看到来自承租者、使用者和所有API调用的所有入口请求，那么它们能否以某种规范化格式将这些内容公开给承租者?你需要这个的原因是，今天很多云的消费者会刮日志，他们这样做他们刮不同的日志，为不同的供应商刮不同的日志，即使在扩大的结构中也没有标准化的方法，更不用说刮日志之类的事情了这很脆弱，日志会变化。
我们能不能说，既然你看到了所有的东西，你能不能把它吐回一个事件网关，一些我们可以通过一种Knative或某种类型的事件网关处理的东西我们可以直接看到你所看到的东西。因此，对于服务请求伪造，或者一些逃跑的活动，或者一些不遵守规则的人，没有放入正确的元数据，如果有一个单一的控制点来识别任何可能给我们带来麻烦的异常行为，将会容易得多。最后但并非最不重要的是，从安全框架中寻找规范化结构。所有不同的产品都有安全框架，他们说不hth华体会最新官方网站同的语言，他们并不真正与安全专家交流，所以，在论文中再多说一点。
这是标准化的模型。在这里结束，最后一件事是我们尝试做的一件事是基于Gherkin创建伪代码它是基于YAML的所以我想尝试探索一个不同的模型，看看我们是否可以尝试用Gherkin做些什么。这里我有两个基于这两个模型的例子。引导完整性,这基本上就是一个小黄瓜的模型检查,看看如果,意图或校验和的引导顺序哈希已经改变了,然后这是一个,如果我们收到的所有入口流量的提供者,我们听,我们可以查找元数据,应该是如果它不是,那么我们可以去找有几分邪恶的演员像一个加密矿工等等。
像往常一样，我想以其中一个结束，我谈到Kit Merker，我谈到JFrog，我真的很喜欢JFrog家族，他们邀请我来演讲，我想这就是我喜欢他们的原因，我想他们也喜欢我，但是这本书，很多这本书《液体软件》讲了很多自动化管理的原则在组件管道中建立信任。这是几年前另一个"我认为我在做正确的事"的想法，当我读到这本书的时候，书中谈到了Grafeas，它帮助我说，不止一个人告诉我，这是需要的，一切都到位了。这是一本很棒的书。我总是试着在演讲结束时说，这是一个快速阅读，它确实完美地设定了心态。无论如何，非常感谢你们的聆听，我希望你们喜欢，如果你们对这些感兴趣，我很容易找到，请联系我。我喜欢讨论这些东西。