DevOps很难DevSecOps更难——Enterprise Holdings, Inc。

所以我们的团队，就像我说的，有点独特;我们没有人是开发人员，没有人在基础设施领域工作，我们有很多不同的人才，来自不同的领域。所以每个人都可以更专注于我们遇到的具体项目。现在，大约有4个以上的工程师在这个项目上工作，大约有2个建筑师把它从地面上启动，大约两年半前开始，我只是想让你们了解我们的进展，我们看到的问题，以及你们如何调整可能是正常的。

我们还确保考虑到我们使用的所有不同的中间件平台，各种不同级别的遗留平台，它们要么在PRIM上，要么使用任何现有的云解决方案。

不用说，这就是我们的开发经验，这就是去年的情况，当我们离开这里时，感觉好多了;我们感觉好多了，我们在做正确的事，我们在前进。所以我们真的觉得一切都很顺利。

对我们来说，出去让人们收养孩子很容易，但事实并非如此。我们需要做很多市场营销，我们需要处理很多组织问题，仅仅是为了得到领导的认可，花时间做这件事却不能展示一个完美的投资回报率，这对我们来说很难讲。这就是为什么我们的旅程有点痛苦。但是随着我们今年的进展，我们开始真正地揭开我们的工具链的面纱，以及我们用来采用的开发流程和文化，以及团队可以很容易地采用并推进他们的SDLC的CI/CD框架。

所以话不多说，我想请TJ Smreker，他将给你更多关于我们所看到的SDLC的概述，以及我们如何执行它，以及更多关于开发文化变化的内容。TJ吗?

谢谢你Nathan。我是TJ Smreker，我是Enterprise Holdings的系统工程师。所以我将从软件交付生命周期(SDLC)开始。我要提醒一下;这是我们的观点;就像内森说的，我们的处境很有趣。我们不是开发者，我们没有任何我们支持的应用。但是我们在应用程序中支持应用程序团队。我们介于他们和基础设施之间。

再一次，这是从我们的角度，以及我们是如何发展这个过程的。但在一个非常高的层次上，一开始，它是一个开发人员在本地开发，检查存储库中的源代码。在构建服务器上构建该应用程序。运行各种合法的安全扫描，寻找漏洞。打包该应用程序并将其发布到Jfrog Artifactory。部署该应用程序，在该环境中进行测试，一旦在每个环境中运行了所有测试套件，我们就将其部署到生产环境中。

非常简单，非常高级。但要把它拉得更远一点，我们必须包括很多东西才能使这个过程继续下去。所以我们创造，开发了很多不同的东西我们必须把它们合并到我们的SDLC中，正如你在这里看到的，也包括了登录。领养是一项艰巨的任务，我马上就会讲到。

仔细看一下:DSL框架，它实际上是我们围绕入职过程构建的自动化，或者说是采用。我们开发了模板，这些模板是[听不清00:04:57]库，所有这些都存储在源代码控制中，还有我们的打包脚本、自动化工具和Ansible，我们为此使用的所有存储库，以及我们的PROD文件和脚本都存储在源代码控制中。

这些我会在这里多讲一点。但只是给一个想法，有很多涉及。试图构建这样的东西。这也不局限于工具。所以当我们看产品时，我们部门实际上拥有hth华体会最新官方网站SDLC中包含的几乎所有产品。所以我们有一个很好的视角，知道这些东西需要放在哪里，如何集成它们，例如，通过持续集成，我们在Jenkins中有自动化工具。我们有漏洞扫描工具，我们有Artifactory，我们有持续交付的构建工具。我们仍然在使用Jenkins，仍然有Artifactory参与其中，现在引入了Ansible，以及我们的中间件解决方案和测试套件。所有我们部门的财产。这让我们的工作变得简单，但是，你仍然需要确定所有这些部分的位置。

所以，把它进一步展示出来，展示所有涉及到的东西。有很多。您必须确定这些部分适合在哪里，如何集成它们，包括工具。在这一点上，你可以看到，我们有了产品，我们有了我们的过程。我们知道工具适合的地方，集成点……我们觉得我们已经创建了一个土生土长的DevOps流程。

在这一点上，我们就像，嗯，我认为我们正在成为DevOps!那我们现在该怎么办?我们需要一些应用程序来使用它。

所以我们就想，DevOps应该让你的生活更轻松，对吧?确实如此，但实现这一目标可能很困难，如果有人告诉你DevOps很容易，那他们是在骗你。是很困难的。这是困难的。这涉及到很多东西，我觉得从我们的角度来看，这尤其困难;正如内森所说，我们是一家大型企业。我们有很多IT员工，有很多应用程序，所以我们必须考虑一大堆东西。

所以我们开始的时候，我们要识别;我们的公分母是什么?无论是应用程序、平台……这就是我们开始的地方，就像Nathan说的，我们有200多个应用程序。它们运行在多个平台、不同的中间件解决方案上。如果我们有一个或几个应用程序在同一个平台上运行，很可能，一个和另一个是不一样的。所以说，我们的应用是一堆雪花。这是很难做到的。

在我们试图找出所有这些共性的同时，我们也想确保我们正在标准化最佳实践。因为我们不想重复过去的任何错误，如果我们有一堆应用程序在做一件事，那是违反最佳实践的，这不是我们想要引入我们的新标准的东西。在这种情况下，如果你有一群人在做一件事，这并不意味着那就是你需要做的;你需要确定什么是最佳实践?

当我们看到所有这些的时候，如果可行的话，我们想利用我们目前拥有的。举个简单的例子，Jenkins已经在我们的环境中了，我们有应用团队已经在使用它了，他们对这个很熟悉。这很容易实现。与我们的构建方法、部署脚本一样，我们认为这些都是易于重用的部分。我们不想无缘无故地重新发明轮子。

从这个角度来看，这让事情变得简单了一些，但我们仍然有很多需要考虑的地方。

在这一点上，我们已经有了一些有用的东西。我们建立了一个庞大的流程，所以我们与一个应用团队合作，我们把他们当作我们的拥护者。我们在POC的情况下使用它们。但这是概念的证明，所以我们提出的是为这些应用量身定制的。所以一旦我们让它工作起来，我们就想，好吧?我们希望所有的应用程序都能使用它!但现在我们需要让它们充满活力。我们希望它们能够重复使用。这对应用团队来说很容易采用，因为他们忙于开发，我们觉得我们的工作就是让他们尽可能无缝地采用这个过程。

所以我们最后做的就是开发模板。它们是用Groovy编写的。因为我们的自动化工具是Jenkins，所以我们开发Jenkins文件，但我们也将它们开发为不可知的。所以，如果我们决定改变我们的自动化工具，我们就能很容易地向前发展。

就像我说的，我们开发了几个模板;确切地说，是四个，所以我们就直接开始，这是我们如何能够驱逐收养的主要内容。

我们将从构建开始。构建只是一个持续集成的部分。因此，我们能够确定我们认为每个应用程序在这个过程中成功所必需的七个事件;我们在詹金斯的文件中把这七个事件变成了阶段。正如你所看到的，我们这里有一小段代码，我知道这可能有点难读。

但我们的想法是展示它们是如何被分割的，当我们浏览Jenkins文件时，每个阶段都有自己的部分，所以如果出了问题，就很容易确定到底是哪里出了问题。

通过这些模板，对于构建，我们将克隆存储库，我们将在共享构建代理上构建应用程序，我们将在所有应用程序中使用该代理。我们正在运行漏洞扫描，我们正在打包应用程序，我们将它与元数据一起发布到Artifactory，以便我们以后可以使用它，用于安全目的，或跟踪，或其他用途。

同时，我们将标记Repo，然后我们将清理工作区。这样看起来什么都没有。需要注意的一点是:为了保持这些模板的动态性，我们实际上创建了一个JSON格式的特定于应用的文件，因此每个应用都有这个文件。它存储了模板在管道中使用时所必需的变量。

因此，对于每个模板，它实际上是提取它需要的必要变量。

下一个是;部署。所以部署就是持续交付。我一会儿会稍微讲一下这个，我们还没有讲完。因为几个原因，但是，看起来这里并没有发生很多事情。特别是如果你看一下持续积分部分。但是我们使用Ansible作为我们的配置管理工具，它实际上做了很多繁琐的工作，繁重的幕后工作，它能够使事情变得更加清晰，因为就像我说的，我们有这么多不同的平台和中间件解决方案，我们必须能够为这些不同的解决方案量身定制一切。

这里有一个例子，如果我们加入一个团队，他们会得到什么。它是一个简单的部署到一个环境，运行一些检查来确保应用程序启动，实际上，每当我们部署时，我们实际上写回Artifactory的元数据关于它被部署到什么环境，它是什么时候，如果它还在部署。但就像我说的，我们正在检查以确保应用程序正常运行。

最重要的部分是最后一点:不分配测试。很明显，没有任何测试分配给这个应用程序。但这是我们在很多应用中看到的，它们没有自动测试。所以我们试着给他们这个简单的路径，这样你就可以开发你的自动化测试，你只需要把它插入到你的管道中。

显然这里什么都没有发生，但这是一个动态的阶段。这是一个团队利用这一点的例子。在部署应用程序之后，它们实际上运行了三个测试。你会看到上面这里的代码，这实际上来自那个应用的特定JSON文件。它是特定于那个应用的所以它存储在那个文件中。无论何时我们运行这个模板，它都会回到那个JSON文件，然后说，哦，这里有测试?让我们跑一跑!哦，你还有一个?让我们来试试吧!”然后循环这些。

有几件事需要提醒我们。我们的构建和部署在一个Jenkins实例上运行，我们在另一个Jenkins实例上做测试。所以这是职责分离。让它更安全一点。

你可能会注意到，我之前说过，这不是很CD，我们只部署到一个应用或一个环境。我们这么做有几个原因:第一，舒适。我们必须得到团队的支持。所以我们想为他们创造一条简单的道路，我们的团队仍然手动部署。或者，我们仍然有使用Jenkins的团队，但是是自由式的。

所以有一些团队对它很熟悉，但我们想让它尽可能地简单。

第二，团队还没有准备好。就像前面的例子一样，没有任何可用的测试，团队就是没有这些测试，所以如果没有适当的测试套件，我们就不能使用完整的CI/CD模型。

三，第三个原因是灵活性。无论如何，我们可能已经开发了它，只是为了在需要时对环境进行临时部署。

但这将我们带入下一个，完整的管道。因此，这正是您期望从CI/CD模型中得到的。只是在我们的环境中，我们排除了生产。这是另一种职责分离，或者说分割。我们实际上是在不同的Jenkins实例上部署到生产环境中，所以非prod不会影响生产环境。

但从非产品的角度来看，它是完整的CI/CD;我们实际上是在使用我之前提到的那些模板，构建和部署，我们在做完全相同的事情。唯一不同的是审批阶段。这实际上是管道中的一个暂停。我们把这个放在适当的位置，是为了让应用团队和他们的管理者感到舒适，因为如果他们没有适当的测试，他们运行这个，它就会跳转到下一个环境，他们会说，这是怎么回事?

我们把这些放好，这些Jenkins文件非常灵活;东西可以被移除。只要他们觉得他们的管道中包含了适当的测试，他们就可以删除这个阶段，然后他们就可以得到完整的CI/CD模型。

最后一件事是prod部署。我们认为，产品部署是应用团队从中获益最多的地方。同样，我们是分段的，只从一个Jenkins实例部署到生产环境。对于某些应用程序，它的部署非常简单。部署到一个实例，运行检查，结束一天的工作。

但是，在我们的大企业中，大多数人都不是这样。我们的大多数应用程序都在应用程序家族中，所以它们有多个应用程序，它们一起部署到多个集群中，这样应用程序就可以保持弹性。

在这个模型中，传统上，我们有一个生产运营团队来做部署;他们正在打开多个PuTTY会话来运行，脚本来启动这些部署，我们也在一个接一个地部署应用程序;所以部署时间很长。他们需要几个小时。

在这个模型中，如果出现问题，很难排除故障。如果出了问题，你甚至无法看到到底发生了什么，也很难进行合作。

对于需要状态更新的人;没有合适的人来运行作业来获取状态更新，所以你是在传递信息。然后，就像我说的，我们一个接一个地使用这些应用，这使得这些部署非常长。所以，Jenkins能够帮助解决很多这样的问题，因为如果出了问题，你能够准确地确定它在哪个阶段出了问题，你可以排除故障并实时协作，因为每个人都能看到这一点。每个人都能接触到詹金斯警长，我们给每个人读权限。这样任何人都可以去那里;如果出了问题，你可以进行回顾。

就像我说的，解决你遇到的任何情况，状态更新真的不再需要了。但我们仍然看到我之前提到的一个小问题，我们没有看到时间效益，我们仍然部署一个又一个应用程序。所以他们仍然是长期部署。

所以当我们再次与冠军团队合作时;他们当时有五份申请，这实际上发生在去年内森来这里做演讲之前。就像我说的，有五个应用程序，我们开发了一个我们称之为“编排工作”的东西。因此，编排作业控制所有这五个应用程序，因此您可以通过一个作业部署这些应用程序的任何组合，因此对于运行它的人来说更容易，您不必去五个不同的作业来启动构建，每个人都更容易准确地确定我们在流程中的位置。

它最终节省了大量的时间;因为我们所做的是利用并行暂存，所以我们确定了使用系统资源的最佳方法，以便部署应用程序。2022世界杯阿根廷预选赛赛程因为我们的很多应用程序都是WebLogic的，所以你每次只能在服务器上部署一个应用程序。因此，我们最终使用了并行阶段，确定了哪些应用程序可以在何时部署，并且还能够包括这个冗长的编排计划中包含的许多手动步骤。

因此，通过这样做，该团队正常的五个应用程序部署大约需要四个小时。他们每月都在部署。在我们第一次尝试的时候，我们成功了，我们可以把它缩短到一个半小时。我们第一次尝试。

这对我们来说是巨大的胜利，对他们来说也是巨大的胜利。他们在这方面取得了很大的成功，他们已经完全掌握了这个过程;他们就是从那里成长起来的。他们吸取了我们的经验，并在此基础上进行扩展。据我所知，他们现在的部署时间大约是一个小时。而且他们还添加了更多的应用，所以。这对他们来说是巨大的胜利，对我们来说也是巨大的胜利。

我要说的最后一件事是:我们就像，如果我们进入部署半小时，其中一个平行阶段失败了，会发生什么?整个管道都要崩溃了!我们损失了大约半个小时的时间。所以我们实际上开发了一个动态阶段，它检查并行阶段中那些部署的状态，我们说，如果它失败了，不要让工作失败。我们要把它放在不稳定的，我们要暂停管道。”这样，我们就可以让必要的各方参与进来，说:“好吧，我们可以解决这种情况，并采取必要的行动，如果我们能够解决这些问题，那么我们就可以继续进行管道建设，这样我们就不会浪费任何时间。”

这对我们来说也是个大问题。

再简单说几句。DSL和自动化。这是为了我们的利益;就像我之前说的，我们有200多个应用程序，我们希望能够采用这个。要让一个应用程序承担这个任务需要很多东西。实际上，我们已经围绕入职建立了一个完整的流程，所以它更加精简。然后我们还使用了Jenkins Job DSL Plugin，这样我们就可以自动创建那些Jenkins Job，创建特定于应用程序的文件，将那些模板放在那个文件的Repos下。所以我们花了几个小时做的事情，现在只需要几分钟。

这对我们来说真的很有帮助，能够帮助这些团队采用这个过程。

最后一件事是一个标准的过程。这就是整个的想法，我们想拍下这张照片，然后把它放在我们支持的每个人的身上。这样，对我们来说，它更容易支持，对他们来说，它更容易扩展，它只是帮助每个人，它允许我们尝试朝着DevSecOps解决方案努力。

我要说的最后一件事是，我所在的团队，我们记录了这件事。我们需要这么做，因为涉及的事情太多了。现在我们知道我们不可能记录所有的东西，因为我们要处理这么多雪花，而且有这么多不同的定制解决方案。但是，我们希望向我们的客户(也就是我们的应用团队)提供尽可能多的信息，这样他们就能尽可能轻松地完成这个过程。比如如何开始，他们需要的任何先决条件，在他们开始之前，这样他们就不会浪费时间，或者浪费时间，我们可以让他们马上开始。

除了管理文件，我们部门有，我不知道，40个人，我们只有三个人知道整个过程。所以我们就尽可能多地记录下来，我们花了几个月的时间来记录，因为涉及的内容太多了。

话虽如此，这听起来很简单，对吧?不是很多吗?我想说的是，DevOps就像阳光和彩虹。现在吉姆要上来了，他会告诉你安全在我们的解决方案中是如何工作的。

谢谢TJ。我是吉姆·莱塞。我也是企业公司的系统工程师。我要跟你们谈谈DevSecOps以及安全是我们组织中非常重要的一部分。以及实施起来有多困难。

那么，首先，一点点安全历史，以及我们缺乏的地方。我们开始使用普通用户来运行我们的所有进程，并且这些普通用户拥有普通的登录信息。这里的问题是，实际拥有这些处理器运行的应用程序的团队，甚至不拥有这些用户。我们在安全增强方面缺乏测试。不幸的是，我们确实处于这样一种情况，无论何时我们进行这些增强，都是在生产环境中进行测试。

我们也有一个非常糟糕，过时的FOSS吸收过程，或自由和开源软件。我们很容易花一个多月的时间将新组件引入到我们的环境中，而这与敏捷完全没有关系。这也增加了缓解任何出现的安全漏洞所需的时间。

也就是说，当我们开始关注安全性，以及我们真正需要将其纳入的地方时，我们意识到它需要纳入整个SDLC。我们需要确保我们不仅关注开发和构建，还关注QA，特别是生产环境。将其构建到整个SDLC的好处是，我们可以在每个步骤中构建批准。现在事情发展得太快了，我们实在等不起了。

我们首先关注的是客户管理，以及它与职责划分的关系。这是我们的信息安全团队一开始实际上并不需要的东西，但是当我们开始构建解决方案时，我们意识到我们需要它才能成功。我们的许多团队一开始都有一些阻力，因为他们不想要额外的责任，因为他们必须对另一个账户负责。但最终，他们意识到，一旦他们开始使用它，它让他们的生活变得更加顺畅，因为他们不像以前那样依赖于支持团队。

测试对我们来说非常重要，也很重要。我们希望确保在任何时候我们考虑实现任何新的安全最佳实践时，我们在实现新东西时不会破坏当前的解决方案。

我们最近关注的重点是漏洞扫描。这是在开发过程中需要考虑的一件非常重要的事情，因为我们希望确保在将它们引入我们的环境之前找到所有这些漏洞。同时我们也希望确保我们能够将这些内容融入到QA和生产过程中。因为我们知道每天都有新的漏洞出现。所以我们需要确保我们积极主动地寻找这些新的犯罪行为。当我们这样做的时候，我们已经构建了适当的sla来根据其严重性修复所有这些漏洞。

那么，切入主题:这在我们的环境中到底是什么样子的?我们允许开发者像使用沙盒一样使用他们的桌面。他们可以引入任何他们想要的组件、新产品、新版本……但前提是，在将代码更改推送到源代码存储库之前，他们会在桌面上进行扫描，以确保不会引入hth华体会最新官方网站这些漏洞。

我们知道我们并不生活在一个完美的世界。不管它是不是恶意的，这些扫描并不总能完成。所以我们想要确保我们也将其构建到我们的CI/CD管道中。就像TJ之前说的，“每个人都是雪花。”那么我们如何将其融入其中呢?

无论什么体系结构，即使团队彼此使用相同的体系结构，我们知道他们的构建过程永远不会是相同的，这里和那里总是会有一些小的变化。

所以我们想要确保我们提出了一个解决方案，允许我们的开发人员实际上使用他们正在使用的完全相同的构建过程。我们只是让他们在管道中增加了一个额外的阶段。这样做很简单，这样更容易被采用，而且对当前流程的干扰也少得多。

现在，我们在管道中进行漏洞扫描的方式的好处是，我们实际上在调用它时构建了一个组合检查。这样，我们就知道漏洞扫描实际上需要很长时间。所以它会在扫描之前检查是否添加了新组件，或者版本发生了变化，这样就不会浪费不必要的时间。

现在把它建立在我们的管道中，它还允许我们与票务跟踪系统集成。这不仅会增加进行这些更改的团队的可见性和所有权，并可能引入漏洞，而且还允许我们的信息安全团队了解整个环境中正在发生的事情。

话虽如此，第一次迭代并不总是完美的。我们总是会发现我们以前没有想到的新事物;这些惊喜。即使我们做了所有的计划，总会有痛点，总会有未知。因此，我们真正关注的一件事是确保我们从某个地方开始;把它放到环境中，因为我们知道，我们可以在任何时候实现的任何安全性都比完全没有安全性要好。

这并不总是关于不知道最终实现会是什么样子，而只是确保你真正理解你正在实现的工具。

那么，是什么让我们难以实施呢?

这是关于获得支持;这是最重要的一点。因为你的安全取决于你最薄弱的环节。我们是怎么得到支持的呢?我们正在与我们的团队合作。第一批采用者是成功的关键。正如TJ之前谈到的编排工作;如果我们一直在黑洞中工作，并且一直在自己做这件事，我们就不可能成功。与我们一起工作的团队，他们最终是他们确切构建过程的专家。因此，通过与他们合作，我们会更成功。

我们也知道每个人的时间都是宝贵的。我们想尝试用一些东西来吸引他们。这很有帮助，所以回头看看作文检查;在他们的工作中建立漏洞扫描，我们的团队基本上采用了这个过程，他们可以从等待一个多月，就像我之前说的，在他们的构建中立即获得新组件，所以，他们在这方面取得了胜利。

最后，我们要确保向我们的团队展示他们是如何成功的，并向他们展示成功是什么样子的，这样才能让事情顺利进行。

我们还确保与所有团队保持持续的沟通。我们实际上会进行路演，我们会走出去，确保我们支持的团队真正了解我们目前提供的所有产品，以及我们即将提出的任何想法。

我们用它来向他们推销，向他们展示它是如何使他们受益的，因为最终，每个人都必须参与进来，并愿意采用这些新的最佳实践，以便我们取得成功。

那么，总结一下:采用完整的CI/CD后，安全性是什么样的呢?它确保安全是每个人工作的一部分。不仅仅是开发，不仅仅是安全;但它是运营，它是测试，它是一切。这就是在组织中全面采用DevSecOps所需要的样子。因为我们真的想确保我们所有的流程在设计上是安全的。

我们去年已经讲过我们的故事了，现在我们要讲我们的故事，让大家都知道;我们2019年的目标是，我们真正专注于整合我们的基础设施团队，实现真正的全栈集成。这包括服务器环境网络配置，实际上这都是由于我们在SDLC内的基础设施更改速度的提高。

这是我所有的。谢谢大家的时间，我们很感激，我们稍后会回答你们的问题。谢谢你！