在优维公司内部，我们采用发布单的方式进行每天的应用变更管理，这里给各位介绍优维的最佳实践。
变更是需要多角色合作的，而且他是整体研发流程的一部分。在优维内部，我们坚持每日变更，打通开发环节到最终发布上线的全过程，在保证质量的前提下，尽可能提升需求交付速率，如下是我们的简要流程图：
其中最右侧【发布单】就是用EasyOps产品的【双态部署 - 发布单】来实现的。发布单用于记录应用程序的更改，包括:
变更的内容
变更的顺序
影响的范围
变更的结果
操作的人
操作的开始时间和耗时
这种标准变更方案有助于保证每日变更过程的有序可靠及高效。同时优维内部也把发布单的创建跟提测单对接起来，做到了全流程自动化。
大伙知道，发布绝不仅仅只是程序包版本的变化，他包括发布前的各种准备，部署过程以及部署之后的线上检查等。基于此考虑，我们的日常发布单是由升级前、升级、升级后三部分组成，如下是产品截图的全貌：
升级前
1.发送升级通知
升级前通知各同事环境开始升级，避免升级过程中影响到环境的使用，这里使用的是调用钉钉机器人给各个关系群发送消息，客户可以根据实际情况采用不同通知方式.
在一些对客系统中，经常需要进行系统维护或升级的情况下，我们会考虑挂维护页面，以避免客户访问页面时出现报错或其他不良体验.
通过挂维护页面，我们可以向用户提供一些相关的信息，如维护的时间范围、维护目的以及预计恢复时间等。这样可以增加透明度，让用户了解系统维护的原因和进展。此外，维护页面还可以提供一些联系方式，以便用户在有需要时能够与系统管理员或客服人员进行沟通和交流。
这些都可以在发布单的前置动作去灵活配置
2.设置监控维护期
这步骤内部没有设置,我们想清楚的看到升级过程中监控是否能够监控到服务的变化,实际使用时建议配置上,避免升级过程中收到误报.
升级
优维内部总共将近400个组件，每日变更的组件平均有20+，最多时候有50来个。组件之间有些是有部署依赖，有顺序要求，在如此庞大的组件清单里面我们如何去解决这个部署依赖的问题？对此，我们设立了一些标准：
对组件进行分层（runtime -> runtime_db -> model_resource -> logic -> logic_db -> L1 -> L2 -> L3 -> xxx），层与层之间是串行部署的
将所有组件归属到具体层级中，下层组件可以对上层组件有依赖，但同层组件不允许有依赖（如logic层的logic_x组件可以对runtime层的runtime_x有依赖）
不同层有自己的并发部署设置，并发限定为1（串行）肯定是最为可靠和有序的，但他带来的是部署时长的增加，故我们需要依据不同层的特性，在保证稳定的前提下，尽可能提升部署效率
这里简单介绍几个重要的层：
model_resource（数据组件）
这里主要放置了数据组件，他主要负责表结构的变更，我们要求我们的表结构是不能做破坏性变更的，故把他放在第一步，在升级过程中，即使表结构发生的变化，但逻辑组件应该也是能正常运行的。同时我们也会有专门的数据割接组件（logic_db层），如果有数据割接，就会在后续执行。
因为表结构的变更是非常严谨的，故在这个阶段我们采用串行执行的方式。
虽然串行执行的方式可能会导致导入模型的时间变长，但它可以有效地控制数据库的负载，确保系统的稳定性和可靠性。
逻辑组件（logic）
逻辑组件可以被理解为无状态应用，它们之间相互独立，没有依赖关系。由于这种独立性，我们可以采用并发执行的方式来提高发布速度，当前并行度我们设置为3。
通过并发执行逻辑组件，我们可以同时处理多个组件的发布任务，而不需要按照严格的顺序逐个执行。这样可以显著提高发布的速度和效率。每个逻辑组件都可以在独立的线程或进程中执行，充分利用多核处理器和分布式计算资源，以实现并行处理。
前端组件（L5）
优维微应用是前端组件，同样是无状态组件，但在某些情况下可能会依赖于后端逻辑组件。针对这种情况，我们将微应用的处理与逻辑组件分开，分成前后两个阶段进行处理。
在本阶段, 我们并发执行微应用的变更，当前并行度我们同样设置为3。
升级后
升级后我们会做一些升级后的通知和检查工作，包括：
1.发送升级完成通知
通知各同事环境已就绪,可以正常使用,同时做一些人工验证。
2.触发自动化冒烟
在升级后的环境中，通过自动化测试可以快速执行一系列测试用例，验证系统在升级后是否正常运行，是否满足预期的功能和性能要求。
3.计算升级过程中平台可用性
计算升级过程中平台可用性,用于评估升级对客户的影响,后续分析如何进一步优化缩小对客户的影响。
