开发运维是困难的开发运维是更加困难的-企业控股有限公司

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

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

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

对我们来说，走出去让人们收养是很容易的，但事实并非如此。我们必须做大量的营销，有很多组织问题，我们必须经历，只是得到你的领导的认可，花时间做这件事，而不能展示一个完美的投资回报率，这对我们来说很难讲这个故事。这就是为什么我们的旅程有点痛苦。但是随着我们今年的进展，我们开始真正地收回我们的工具链，以及我们正在采用的开发运营流程和文化，以及团队可以轻松采用并推进他们的SDLC的CI/CD框架。

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

谢谢你，内森。我是TJ Smreker，是企业控股公司的系统工程师。因此，我将从软件交付生命周期(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，我们只部署到一个应用，或一个环境。我们这样做有几个原因:第一，舒适。我们必须得到团队的支持。所以我们想让他们走得更容易，我们的团队仍然在手动部署。或者，我们仍然有团队，使用詹金斯，但以自由式形式。

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

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

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

但这就引出了下一个问题，完整的管道。因此，这正是您对CI/CD模型的期望。除了在我们的环境中，我们不考虑生产。这是另一种职责分离，或者说是分割。我们实际上是在与其他Jenkins实例不同的Jenkins实例上部署到生产环境，因此非prod不会影响生产环境。

但从非刺激的角度来看，这是完全的CI/CD;我们实际上是在利用我之前提到的那些模板，构建和部署，我们在做完全相同的事情。唯一不同的是这个审批阶段。所以这实际上是管道中的一个暂停。我们把它放在合适的地方，还是为了让应用程序团队和他们的经理感到舒服，让他们舒服地转移到这个地方因为如果他们没有适当的测试，他们运行这个，它就会跳到下一个环境，他们会想，这里发生了什么?

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

最后一件事是prod部署。Prod部署是我们认为应用团队能够从中获得最大利益的地方。同样，我们是分段的，只从一个Jenkins实例部署到生产环境。对于一些应用程序来说，这是超级简单的部署。部署到一个实例，运行检查，结束工作。

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

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

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

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

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

所以当我们再次与冠军团队合作时;他们当时有五份申请，这实际上发生在去年内森来这里演讲之前。就像我说的，五个应用程序，我们开发的是我们所谓的“编排工作”。所以编排作业控制所有五个应用程序，所以你可以通过一个作业部署这些应用程序的任何组合，所以它让运行它的人更容易，你不需要去五个不同的作业来启动构建，它更容易让每个人都能准确地识别我们在过程中的位置。

这样就大大节省了时间;因为我们所做的是利用并行登台，我们确定了使用系统资源的最佳方式，这样我们就可以部署应用程序。2022世界杯阿根廷预选赛赛程因为我们的很多应用程序都是WebLogic的，所以在大多数情况下，一次只能在服务器上部署一个应用程序。因此，我们最终使用了并行阶段，确定了哪些应用程序可以在什么时候部署，并且能够在这个漫长的编排计划中包括许多手动步骤。

因此，通过这样做，这个团队一个正常的5个应用程序部署大约需要4个小时。他们每月进行一次部署。我们第一次尝试就成功了，我们把时间缩短到了一个半小时。在我们第一次尝试时。

这对我们来说是巨大的胜利，对他们来说也是巨大的胜利。他们在这方面取得了很大的成功，他们实际上已经完全掌握了这个过程;他们从那里成长起来。他们拿走了我们所拥有的，并在此基础上进行了扩展。我记得上次我检查的时候，他们现在大约需要一个小时的时间。而且他们还在添加更多的应用程序，所以。这对他们来说是一场巨大的胜利，对我们来说也是巨大的胜利。

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

这也是我们面临的另一个重大挑战。

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

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

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

最后我要说的是，我所在的团队，我们记录下了这一切。我们需要这么做，因为涉及的事情太多了。现在我们知道不能记录所有内容，因为我们要处理的雪花太多了，而且有很多不同的自定义解决方案。但是，我们希望向我们的客户，也就是我们的应用团队，提供尽可能多的信息，这样对他们来说，整个过程就会尽可能简单。比如如何开始，他们需要的任何先决条件，在他们开始之前，这样他们就不会转圈，或者浪费时间，我们能够让他们马上开始。

再加上管理文档，我们部门大概有40个人，但只有3个人知道整个流程。所以我们尽可能多地记录它，我们花了几个月的时间来记录，因为涉及的内容太多了。

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

谢谢TJ。我是吉姆·莱塞。我也是企业号的系统工程师。我要跟你们谈谈DevSecOps以及安全是我们公司非常重要的一部分。以及实现它的难度。

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

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

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

我们首先关注的是帐户管理，以及它与职责分割的关系。这是我们的信息安全团队一开始实际上并不需要的东西，但一旦我们开始构建解决方案，我们就意识到为了成功，我们需要它。许多与我们一起试点的团队一开始都有一些阻力，因为他们不想承担额外的责任，因为他们必须负责另一个帐户。但最终，他们意识到，一旦他们开始使用它，它使他们的生活工作得更顺利，因为他们不像过去那样依赖支持团队。

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

现在我们最近关注的重点是漏洞扫描。这是在开发中需要考虑的非常重要的事情，因为我们希望确保在将这些漏洞引入环境之前找到它们。同时，我们也希望确保我们专注于将这些纳入我们的QA和生产流程。因为我们知道每天都有新的漏洞出现。因此，我们需要确保我们积极主动地寻找这些新的违法行为。当我们这样做的时候，我们已经建立了适当的sla来补救所有这些漏洞，基于其严重性。

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

我们知道我们生活在一个不完美的世界。不管是否是恶意的，这些扫描并不总是能完成。因此，我们希望确保我们也将其构建到我们的CI/CD管道中。正如TJ之前所说，“每个人都是一片雪花。”那么我们如何将其整合进来呢?

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

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

现在，关于我们在管道中进行漏洞扫描的方式的好处是，我们实际上内置了一个组合检查，正如我们所说的。这样，我们就知道漏洞扫描实际上会花很多时间。所以它会在扫描之前检查是否添加了新组件，或者版本变化，这样如果没有必要的话就不会浪费时间。

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

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

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

那么，是什么让我们很难实现它呢?

关键是要让他们接受;这是最重要的一点。因为你的安全程度取决于你最薄弱的环节。我们是如何获得这种认可的呢?我们正在与我们的团队合作。第一个采用者是成功的关键。正如TJ之前谈到的编排工作;如果我们一直在黑洞里工作，只靠自己，我们是不可能成功的。和我们一起工作的团队，他们最终都是精确构建过程的专家。因此，通过与他们合作，我们可以更成功。

我们也知道每个人的时间都是宝贵的。我们想用一些东西来引诱他们。这很有帮助，回头看看成分检查;将漏洞扫描构建到他们的工作中，我们基本上……通过我们的团队采用这个过程，他们能够从等待一个多月开始，就像我之前说的那样，从立即获得新组件到他们的构建中，所以，他们在那里获得了胜利。

最后，我们要确保我们向团队展示他们如何才能成功，以及成功是什么样子，以便让事情继续下去。

我们也确保与所有团队保持持续的沟通。实际上，我们使用路演，我们走出去，我们实际上确保我们支持的团队实际上知道我们目前提供的所有产品，以及我们的任何想法。

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

那么，我们来总结一下:全面采用CI/CD的安全性是什么样的?确保安全是每个人工作的一部分。不仅仅是发展，不仅仅是安全;但这是操作，是测试，是一切。这就是一个组织中全面采用DevSecOps所需要的样子。因为我们真的希望确保我们所有的流程都是安全的。

为了让大家知道，我们去年已经讲述了我们的故事，现在我们也在努力讲述我们的故事，让每个人都知道;我们2019年的目标是，我们真正专注于尝试在我们的基础设施团队内部进行真正的全栈集成。这包括服务器环境网络供应，实际上这都是由于我们在SDLC中基础设施更改的速度增加。

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