Part3: Focus on Flow and Velocity（关注流和速度）
Published February 5,2018 by Brian Kelly.
这是一系列讨论高性能DevOps团队如何大规模构建安全系统的第三篇文章。
DevOps的核心是可持续、平稳的工作流（flows of work）的概念。为了实现这一点，DevOps团队创建CI/CD管道，将团队聚焦于非常小但频繁的代码更改，提前端到端（gettingend-to-end early），并采用系统架构（例如基于微服务的体系结构）以快速支持所有上述这些内容。
如果团队调整其现有的DevOps原则来包含安全性，那么在安全环境中成功使用DevOps的可能性就更大。一个高速的DevOps团队不应该为了更快地发布特性，而被迫将任何安全实践扔到船外。
安全工作流建模与优化
看板（Kanban）是一个关注流程和开发速度的工作系统。其核心是工作阶段的可视化：随着项目在不同的工作阶段中移动，这些状态的可视化有助于梳理工作阶段的缓慢性，识别瓶颈，并优化速度。
一个面临长期发布延迟的组织可能会发现，安全审查阶段在他们自己的系统中花费了太长时间。通常，这是因为安全审查做得太晚了，而且“批量”太大。换句话说：太多的东西落在了安全小组的盘子里，无法一次全部审查。
成熟的组织通过“向左移动安全”（moving security left）来解决这个问题。假设工作在看板可视化中从左到右流动，这意味着让安全团队更早地参与新特性和版本的开发。这将在开发周期的早期发现主要的安全问题，并防止以后的延迟。
确保微服务的速度
微服务体系结构为安全团队提供了许多好处，特别是那些专注于自己的发布速度的团队。
让我们以一个假设的“货币转换器”微服务为例。让安全团队审查它并授予它对所需单个数据库的访问权限，可能是一项简单的任务。但是，如果相同的特性在一个巨大的体系（monoliths）中，用数百万行代码编写，又会怎样呢？安全团队可能需要详细分析大量更改，以了解哪些更改对他们来说是重要的。如果在发行版之间进行了许多实质性的更改，情况会更糟。让安全团队检查几十行安全策略代码，比让他们使用和检查数千行代码要容易得多。
只要新版本不需要新的秘密或权限，对已经注册的微服务中代码的持续升级就非常快。退役微服务在策略级别变成了一个简单的取消注册。考虑到所涉及的耦合的数量，或需要监督的覆盖面的绝对大小，在一个非常大的整体中退役并不容易。
使用大爆炸模型的巨大体系（monoliths）的传统团队，往往在瀑布系统（waterfall system）中工作。一旦一个应用程序笨拙地脱离了QA（质量保证），他们就请求进行安全审查。然后，安全团队将面临一个难以完成的审查任务——一下子全部！——数千个相关的应用程序都会发生变化，而业务部门则在施加压力以使应用程序正常运行。
经常发货的大型团队通过将代码库分解为微服务来实现这一点，从而使安全团队能够在一个有利于加快进度和提高进度可视性的集中、细粒度的模型中，发挥他们的审批魔力。
从头到尾，及早做
DevOps已经接受了“提前端到端”（getting end-to-end early）的概念。这是一种降低交付风险和提高估计信心的简单方法。团队在新服务中“连接管道”的速度越快，他们就越快学会如何构建平滑的部署流程，以便频繁地对其进行升级和更新。功能标志（Feature flags）可以隐藏部署到生产环境中但尚未准备好完全向用户公开的新功能。
这种方法还可以很好地消除服务所需的安全更改风险，特别是当团队已经拥抱安全策略即代码的原则时。
例如，如果一个新服务需要访问内部CRM数据库和支付网关，团队将为此新服务构建一个CI/CD管道，作为他们的第一个任务，并让其中的v.0.1在仅建立基本连接的情况下通过该管道移动。
该服务将拥有已经审查过的特权，一旦部署到生产环境中，它将“预先注册”以访问所需的敏感资源。这就降低了部署更高版本的风险，开发人员将能够在该版本中创建服务中的其余功能，这是安全的，因为他们知道已经设置了服务的权限和安全设置。
总结
高性能的DevOps团队能够通过以下方式实现高速、平稳的流动：
- 使用看板（Kanban）的开发周期视图，来发现瓶颈并优化它们。
- 将安全性“左移”，并让安全团队在开发周期的早期参与以尽早发现安全问题。
- 使用安全策略即代码的方式，让开发、安全和运维团队高效、明确地进行沟通。
- 将大型应用程序分解为较小的微服务，每个微服务都有自己的安全策略。
- 尽可能减少变更的“批量尺寸”（batch size），使安全团队能够平稳、可预测地处理小项目流。
- 尽早实现端到端，以消除组件和模块持续升级的风险。
这些原则在由数百个开发人员和更多人员组成的大型团队中很好地工作，但在更小的团队中也很有效。无论团队规模如何，安全开发流程的上述原则始终有利于应用。
在本系列的下一篇文章中，我们将了解高绩效组织中的所有团队如何将安全视为“头等公民”（first-classcitizen），而不是事后诸葛亮。
