在前文中我们说到，传统企业在逐步建设自己的数字平台过程中，需要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱。那么，当我们谈“交付基础设施”，我们究竟在谈什么?怎样的交付基础设施能加速数字化项目的交付?
一、什么是交付基础设施
云时代的研发环境应该以原生支持云计算的方式提供、管理和维护。在提供基础的弹性计算能力的IaaS平台之上，交付基础设施负责为交付团队提供便利的、***是自助式的工作环境，让交付团队专注于交付软件的功能性需求，而不必操心软件功能之外的“脚手架”工作。按照ThoughtWorks数字平台战略的定义，这些脚手架包括：
- 弹性基础设施，交付团队使用底层云计算平台的方式，既包括各种虚拟机和镜像的管理，也包括生产环境的水平伸缩能力。
- 持续交付流水线，交付团队编写的代码需要通过这条流水线最终变成可以上线运行的软件。
- 部署运行时，软件在开发、测试、试运行、用户验收、培训、生产等各种环境需要部署的环境。
- 监控，为交付团队提供生产环境(及其他环境)的可观测性，方便他们发现和解决问题。
- 安全，把安全内建在软件的研发过程中，尽量避免因为人为失误造成安全隐患。
从前这些交付基础设施脚手架通常是由每个交付团队的技术***(Tech Lead)来负责搭建和维护的。并且由于软硬件资源的稀缺和不灵活，团队经常需要微调自己的实践来适应不同的环境。所以，即使在同一家公司，各支团队所使用的交付基础设施也可能大相径庭。交付基础设施不一致、不规范的情况会迫使团队花费额外的精力去操心脚手架工作，并且使***实践不易推广普及。走上数字化道路的企业必定有大量的软件项目，尤其是微服务架构风格的引入会使企业拥有数量更多、单体规模更小的软件应用，此时交付基础设施不一致、不规范的情况就会对企业的数字化进程带来更大的阻力。
云计算带来的弹性和灵活性让组织级的交付基础设施标准化、规范化成为可能。一个跨越项目团队的、组织级的交付基础设施团队现在可以在IaaS的基础上封装标准的脚手架，甚至把脚手架本身以PaaS的形式提供给交付团队。通过把整个企业优秀技术***的知识与经验内嵌在交付基础设施脚手架中，降低了对单个交付团队的技术要求，帮助企业缓解优秀技术***难以获得的人才挑战。从这个意义上，以PaaS形式提供的交付基础设施本质上是技术***作为服务(Tech Lead as a Service)的云计算应用形式，它解决的是优秀技术人才的弹性和灵活性问题，让企业能够以一种创新的方式使用这些人才。
| 架构师写代码吗?
关于“架构师是否应该写代码”这个问题，业界有各种不同的声音。在敏捷的社区里，意见倾向于认为架构师需要写代码，因为这是他们获得关于技术决策的反馈和建立技术领导力的重要方式。将交付基础设施明确提出来，就给了架构师又一个清晰的编程目标——他们需要用代码的形式描述软件交付中的基础设施和***实践。除了培训、开会、代码评审等我们已经知道效率并不太高的方式以外，架构师对交付团队的指导和监管现在可以用实实在在的代码来承载。当交付团队不理解架构师说的某件事应该怎么做，现在他们更有理由要求架构师“show me the code”。 |
二、交付基础设施解读
下面我们来看看，在“交付基础设施”这顶帽子下面，架构师/技术***们究竟应该关心哪些问题，又有哪些***实践应该被纳入他们的视线。
1. 弹性基础设施
允许交付随需获得计算能力。在微服务语境下，这种弹性有两层常见的含义：在生产环境下，服务可以随负载动态获得和释放计算资源，从而更高效地使用计算资源，更自动化地应对负载变化;在研发环境下，开发、测试、运维等不同角色可以随需动态获得完整的环境，从而统一环境、标准化研发实践、规范化研发能力，并且给研发提供体验更好的开发环境。
为了实现弹性基础设施，一方面基础设施需要支持弹性，例如使用支持弹性计算的公有/私有云，并且有对生产环境的监控和自动化手段;另一方面应用本身需要有可扩展性，例如服务能分别独立部署、无状态化、容器化、有透明的前端负载均衡机制。有状态服务(比如数据库服务)的弹性伸缩问题是特别需要考虑的重要挑战。
2. 持续交付流水线
用持续交付实践打通微服务的开发、构建、验证和部署流程。在数字化、服务化的背景下，众多互相依赖的微服务形成的系统架构，对构建、验证和部署造成更大的压力：各个服务有独立的代码库和构建流程，又需要随时能组合成可用的软件;构建产物需要有统一的存储管理;完整的运行时环境应该能按需获得;配置和部署应该能快速准确地完成。
为了应对这些挑战，交付基础设施中应该包含完整的持续交付概念：流水线、环境管理、构建产物管理等。应该鼓励对服务虚拟化，***是每个主机运行一个微服务，而不共享使用主机。应该包含配置自动化工具，例如Chef、Puppet等。在服务化的背景下，持续交付流水线需要体现服务间的依赖关系和团队间的协作关系，设计一个运转良好的流水线不是容易的任务。
3. 部署运行时
交付基础设施应该包含生产系统所使用的运行时环境，并把生产环境前向拉通到验证和研发环节。为了在研发流程的出口得到服务化友好的交付物，***是在整个开发过程中一直使用与生产环境近似的环境。例如开发人员应该使用全套环境随时验证，自动化测试和手工测试都基于全套环境开展。在这种情况下，环境的设置、管理、更新不可能由每个开发人员和测试人员自己进行，所以环境的管理更新必定是集中进行的，环境的设置必定是自动化的。
在《技术栈管理：云时代的研发环境》一文中，我们已经介绍过“一个平台、两个PaaS服务、三个运行时环境”的技术栈管理理念。特别需要注意的是，如何将生产数据拉通到验证和研发环节。
4. 监控
在微服务架构中，系统由多个小服务组成，且广泛使用异步通信，使问题和故障更难定位。因此交付基础设施需要提供全面可靠的监控机制，帮助交付团队了解系统的整体状况。
监控的实现涉及日志、服务指标跟踪、业务语义综合监控等方式。在云环境下如何划分和管理监控的层级，监控系统如何无侵入的在各个微服务体系中收集故障和信息，如何有效管理监控的反馈环，如何在前后端分离和移动应用情况下收集和监控客户端日志，都是常见的挑战。
5. 安全
当数字化、服务化IT系统的数量剧增，安全的设置会变得更加复杂。在微服务架构下，系统的安全性需要有一个整体的考虑。例如单点登录、服务间的身份验证和授权、各种防御措施等安全考量不应该下放到交付团队，而应该被涵盖在交付基础设施中统一提供、统一管理、统一更新。
交付基础设施还应该鼓励安全实践内建(Build Security In)，例如团队应该熟悉OWASP安全列表和测试框架、需求分析中应该包含安全需求和恶意用户需求、测试过程中应该包含安全性测试、应该进行自动化安全性测试并纳入持续交付流水线。这些流程与工作方法虽然不能完全以软件代码的形式承载，但它们同样是交付基础设施的重要组成部分。
三、小结
数字化、服务化的IT大背景会让企业开发和拥有的IT系统数量剧增。当企业IT交付更多地以“两个pizza团队”的形式组织，依赖于每个交付团队的技术***来搭建和维护一套完整高效的交付基础设施脚手架，这种期望即使不是完全不现实，也会对企业的人才积累提出非常高的要求。因此，企业应该集中优秀的技术人才(包括架构师们)，打造一套标准的交付基础设施，充分考虑生产环境与研发环境的弹性、持续交付、部署运行时的统一、监控、安全等因素，并借助云计算的弹性和灵活性将其提供给交付团队。用便利的脚手架赋能一支能快速交付的团队，这是企业的数字化旅程的***步。
【本文是51CTO专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】
