环境管理
- 互联网公司的环境会包括：开发环境、功能测试环境、验收测试环境、预发布环境和生产环境这 5 套。
- 测试环境的目的是要保证最终将交付的软件产品的质量，所以好用的测试环境，不能从规模、性能和作用的角度来评判，而应该是从它能否满足用户需求去保证软件质量的角度进行定义，于是得出：当一个环境可以满足其真正核心用户的需求时, 就是一个好用的测试环境。
- 测试环境的功能要求如下：
- 可得性，即在开发一个新项目时，能快速获取构建一个环境需要的机器，基础设施。最好的情况是，能随时可得，随时归还。
- 快速部署，即在搭建新环境时，能以最快的速度构建出一整套完整的环境。测试环境的部署很频繁，在代码提交后，能在很短的时间内构建代码，在环境上更新，就能更早开始测试。
- 独立性，即一个环境在使用过程中，可以不受其他项目测试人员的干扰。
- 稳定性，即不会因为下游服务，基础设施的异常，造成测试中断、等待。
- 高仿真，主要分为两个方面：“测试数据真实”，即能在测试环境构建出真实的测试用例；“环境真实”，即基础服务的架构和行为与线上环境保持一致，避免因为环境不一致造成测试结果不一致。
- 成本和效率的问题
- 第一个关键点是抽象公共环境，而其中的公共服务基本都属于底层服务，相对比较稳定，这是解耦环境的重中之重。在公共环境的基础上，可以通过泳道的方式隔离相关测试应用，利用LB和SOA中间件对路由功能的支持，在一个大的公共集成测试环境中隔离出一个个独立的功能测试环境，那么增加的机器成本就仅与被并行的项目多少有关系了。
- 第二，避免产生多套公共环境。
- 第三，减轻配置的复杂度。
- 环境配置的目标与标准
从面向的目标来看，环境配置大体上可以分为两大部分：
以环境中每台服务器为对象的运行时配置；
以一个环境为整体目标的独立环境配置。
环境一定要标准化
所谓标准化，就是为了在一定范围内获得最佳秩序，对实际的或潜在的问题制定共同、可重复使用的规则。
- 规定公司的主流语言栈；
- 统一服务器安装镜像；
- 提供默认的运行时配置模板；
- 统一基础软件的版本，以及更新方式；
- 在架构层面统一解决环境路由问题；
- 自动化环境产生过程。
在实施持续交付的同时，去推动形成以下几个方面的规范： - 代码及依赖规范；
- 命名规范；
- 开发规范；
- 配置规范；
- 部署规范；
- 安全规范；
- 测试规范
- 配置的相关内容
配置管理： 是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。它的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期的各个阶段都能得到精确的产品配置信息。
配置： 是指独立于程序之外，但又对程序产生作用的可配变量。也就是说，同一份代码在不同的配置下，会产生不同的运行结果。
从上面的定义中，你可以看到配置和配置管理有着本质上的不同：配置管理服务于软件研发过程，而配置则服务于程序本身。 - 常用的配置方法
- 构建时配置：方案看起来很简单，但它依赖于某个特定的构建工具，而且使用方法不统一；每次都要重新编译，浪费计算资源。
- 打包时配置： 构建时完全不清楚程序所要部署的环境，因此只完成最基本的默认配置；而发布时清晰地知晓环境信息，因此可根据环境信息，进行相关配置的替换。
- 运行时配置：修改后实时生效；支持灰度发布；能分环境、分集群管理配置；有完善的权限、审核机制。
- 问题：先回滚配置还是先回滚代码就成了一个死循环的问题。最好的办法是保证配置与代码的兼容性，这有点类似于数据库的 schema 变更。一定要注意配置的回滚问题。因为，无论是回滚还是不回滚，它没有标准答案，这个复杂问题必须按当时情况作出相对应的处理。
- 搭建测试环境的流程
- 可以使用虚拟机资源池，提升获取机器资源的速度；
- 合理打造并行的应用部署流水线，是进一步提升环境创建速度的方法；
- 利用配置等方式快速达到环境变更需求，可以再次有效地提升整个环境部署的效率。
- 容器带来的改变
重新定义交付标准
容器技术统一了软件环境和软件代码，交付产物中既包括了软件环境，又包括了软件代码。也就是说，容器帮我们重新定义了交付标准。被重新定义后的交付，有如下特点：
- 第一，交付结果一致；
- 第二，交付自动化；
- 第三，交付个性化；
- 第四，交付版本控制；
构建集成
- 构建提速的方式
- 升级硬件资源，最直接和粗暴的提速方式；
- 搭建私有仓库，避免从外网下载依赖；
- 使用本地缓存，减少每次构建时依赖下载的消耗；
- 规范构建流程，通过异步方式解决旁支流程的执行；
- 善用构建工具，根据实际情况合理发挥的工具特性。
- 构建检测的方式
- Maven Enforcer 插件可以帮我们更好地完成编译检测；
- 可以使用内置的 Maven Enforcer 规则，覆盖常规检测；
- 可以使用自定义 Maven Enforcer 检查规则的方式，增加版本号规则等的检查；
- Maven Enforcer 之外，你还可以自己丰富一些例如依赖版本检测这样的服务，以提高检测效果。
- https://maven.apache.org/enforcer/enforcer-rules/index.html
- http://www.mojohaus.org/extra-enforcer-rules/
- 镜像的安全规则
- 基础镜像来自于 Docker 官方认证的，并做好签名检查；
- 不使用 root 启动应用进程；
- 不在镜像保存密码，Token 之类的敏感信息；
- 不使用 –privileged 参数标记使用特权容器；
- 安全的 Linux 内核、内核补丁。如 SELinux，AppArmor，GRSEC 等。
发布及监控
- 发布的需求点：
- 易用：执行脚本就好，填入参数，一键执行。
- 快速：自动化肯定比手工快，并且有提升空间。比如，因为有版本的概念，我们可以跳过相同版本的部署，或是某些步骤。
- 稳定：因为这个程序逻辑比较简单，而且执行步骤并不多，没有交叉和并行，所以稳定性也没什么大的挑战。
- 容错性强：表现一般，脚本碰到异常状况只能停下来，但因为版本间是隔离的，不至于弄坏老的服务，通过人工介入仍能恢复。
- 回滚顺滑：因为每个版本都是完整的可执行产物，所以回滚可以视作使用旧版本重新做一次发布。甚至我们可以在目标机器上缓存旧版本产物，实现超快速回滚。
- 几种常见的灰度方式
- 蓝绿发布，是先增加一套新的集群，发布新版本到这批新机器，并进行验证，新版本服务器并不接入外部流量。此时旧版本集群保持原有状态，发布和验证过程中老版本所在的服务器仍照常服务。验证通过后，流控处理把流量引入新服务器，待全部流量切换完成，等待一段时间没有异常的话，老版本服务器下线。
这种发布方法需要额外的服务器集群支持，对于负载高的核心应用机器需求可观，实现难度巨大且成本较高。
蓝绿发布的好处是所有服务都使用这种方式时，实际上创造了蓝绿两套环境，隔离性最好、最可控，回滚切换几乎没有成本。 - 滚动发布，是不添加新机器，从同样的集群服务器中挑选一批，停止上面的服务，并更新为新版本，进行验证，验证完毕后接入流量。重复此步骤，一批一批地更新集群内的所有机器，直到遍历完所有机器。
这种滚动更新的方法比蓝绿发布节省资源，但发布过程中同时会有两个版本对外提供服务，无论是对自身或是调用者都有较高的兼容性要求，需要团队间的合作妥协。但这类问题相对容易解决，实际中往往会通过功能开关等方式来解决。 - 金丝雀发布，从集群中挑选特定服务器或一小批符合要求的特征用户，对其进行版本更新及验证，随后逐步更新剩余服务器。这种方式，比较符合携程对灰度发布的预期，但可能需要精细的流控和数据的支持，同样有版本兼容的需求。
- 不可变模型和三种模型
对任何的包、配置文件、软件应用和数据，都不做 CRUD（创建、替换、更新、删除）操作。
发散模型
是我们通常会碰到的基础设施的管理模型。在这个模型中，基础设施随着我们的想法而变化，也就是我们想更新什么就更新什么，最终就会形成一种发散的形态。
收敛模型
是 Puppet 和 Chef 遵循的设计原则。随着时间推移，目标和实际需求汇聚，达到一致。通过这个模型，我们有了可扩展的基础设施的基础和实现。
一致模型
指的是整个基础设施始终把每一天当成是与第一天相同的模型。根据我们之前的假设，达到这一目的的关键点就在于，有序地正确执行从真正的第一天开始的所有变更。
- 发布系统的设计理念
- 1 张页面展示发布信息，且仅有 1 张页面，展示发布当时的绝大多数信息、数据和内容，这个页面既要全面，又要精准。
- 2 个操作按钮简化使用，即页面上除了“回滚”按钮常在外，最多同时展示 2 个操作按钮。目的是要降低发布系统的使用难度，做到“谁开发，谁运行”。
- 3 种发布结果，即成功、失败和中断状态，目的是简单、明了地显示用户最关心的发布结果。
- 4 类操作选择，包括开始发布、停止发布、发布回退、发布重试，目的是使状态机清晰明了。
- 5 个发布步骤，即 markdown、download、install、verify 和 markup。这里需要注意到的是，verify 这步包含了预热，由于耗时往往比较长，一般采用异步的处理方式。
- 6 大页面主要内容，包括集群、实例、发布日志、发布历史、发布批次、发布操作，来统一、简洁而又详细呈现发布中和未发布时的各种信息。
- 监控的几种分类
- 用户侧监控，可以通过打点收集，或者定期采集日志的方式进行数据收集；
- 网络监控，通过模拟手段或定期采样进行收集；
- 业务监控，需要定义正确的指标以及相匹配的采集技术，务必注意实时性；
- 应用监控，可以通过中间件打点采集，也可以通过日志联合分析进行数据采集；
- 系统监控，通常采用定期采样的方式收集数据。