后台运维操作建议

1.版本升级

版本升级是软件维护和演进中的关键环节，但它可能带来一系列问题。这些问题涉及兼容性、功能、性能、安全性等方面。

• 【强制】版本管理：使用版本控制工具管理版本，确保不同版本间的兼容性。遵循语义版本控制（SemVer）原则，以清晰标识版本间的兼容性。
• 【强制】迁移指南：提供详细的迁移指南和文档，帮助用户了解版本升级的变化和兼容性注意事项。
• 【强制】回归测试：在新版本发布前，执行回归测试，确保新版本的代码不会破坏旧版本的功能。
• 【强制】灰度发布：在新版本发布时，采用灰度发布的方式，逐步将流量引导到新版本，并监控兼容性问题。
• 【建议】自动化测试：建立向后兼容性的自动化测试，模拟旧版本客户端的行为，验证其在新版本环境下的兼容性。

2.配置发布

服务配置变更是系统维护和优化的重要操作，但如果配置变更过程中出现错误，可能会导致线上问题。以下是规避服务配置变更引发问题的措施：

• 【强制】配置梳理。在发布前，梳理所有依赖的配置项，确保所有配置项的完整性，发布模板中的 checklist 需要有此动作。
• 【强制】配置 Review。服务配置发布需要经过其他同事 Review 同意后方可发布。
• 【强制】预发布环境验证：在将配置变更应用到生产环境之前，先在预发布环境中进行测试，确保配置变更不会引入新的问题。
• 【强制】发布后验证，由测试同学在生产环境进行回归验证，确保配置加载正确且系统功能正常。
• 【强制】配置回滚：建立有效的回滚机制，在配置变更出现问题时能够快速恢复到稳定的配置。
• 【建议】发布前验证：在配置变更前，使用配置验证工具或脚本检查配置文件的正确性，确保语法和参数设置无误。
• 【建议】在配置文件中注释说明每个字段及其取值的含义。

3.数据库/脚本操作

• 【强制】在进行数据库和脚本操作前，必须让相关团队（如开发、运维）review，确认操作需求的详细描述和业务背景，确认操作的合理性和必要性，确保操作设计符合业务需求，并记录所有操作场景及其用途。
• 【强制】优化脚本和SQL语句，确保操作高效且不会对系统性能造成影响。例如，分批删除数据避免全表扫描锁表
• 【强制】在涉及多个步骤的操作中（如批量更新），使用数据库事务，确保操作的原子性和一致性。
• 【强制】使用 DMS 平台进行数据库变更操作，严格控制数据库和脚本操作权限，确保只有授权人员才能进行相关操作。
• 【强制】按照预先制定的操作步骤进行操作，确保每一步操作都记录在案。
• 【强制】在发布完成后，及时进行回归验证，确保操作执行正确且系统功能正常。
• 【强制】对定期脚本的执行过程和结果要有监控告警和打印日志。
• 【建议】涉及重大的变更发布时，制定详细的回滚方案，确保在操作出现问题时能够快速恢复到操作前的状态。常见的手段是备份当前数据库状态，准备好回滚脚本。
• 【建议】在操作完成后，进行总结和反馈，记录操作过程中出现的问题和解决方案，以便后续改进。
• 【建议】定期进行数据库和脚本操作相关的培训和知识共享，提升团队成员的操作能力。

4.发布依赖确认

发布依赖问题通常涉及到在软件发布过程中，系统组件、库或服务的依赖关系出现不一致或冲突，可能导致应用程序运行不稳定或失败。

为避免发布依赖不满足导致的问题，可通过如下措施规避：

• 【强制】跨组的事项负责人需要梳理发布依赖项。
• 【强制】跨组的事项一定要确定负责人，统一发布节奏。
• 【强制】现网功能有损，修复发布的第一时间应该是修复功能。要根据功能的情况、修复的复杂度，重要程度去思考如何发布。

5.发布规范

系统发布规范是指在软件系统开发和部署过程中，为了确保系统的稳定性、安全性和可维护性而制定的一系列标准和流程。这些规范有助于团队在发布新版本时保持一致性，减少错误，确保用户体验。以下是一些关键的系统发布规范：

强制：

• 确认即将发布的版本已通过CI/CD流水线的所有测试，并且版本号正确。
• CI流水线应该有增量覆盖率的拦截节点，不允许代码未经测试就发布上线。
• 检查服务器配置、网络连接、数据库、MQ、Redis 等，确保已经配置正确。
• 选择适当的发布时间，如盘后，确保在问题发生时有足够的时间进行处理，且不会影响到大部分用户。
• 在发布完成后，及时进行功能验证，确保新版本功能正常，系统稳定。例如验证关键功能、接口、性能指标等。
• 严格控制发布权限，确保只有授权人员才能进行服务发布操作。
• 涉及其他依赖方的发布，需要通知对应依赖方，依赖方确认后方可发布。比如发布大流量场景应提前通知数据上游扩容，以免请求量激增导致上游服务被压垮。

建议：

• 涉及重大发布时，按照预先制定的发布步骤进行操作，确保每一步操作都记录在案。
• 在发布完成后，进行总结和反馈，记录发布过程中出现的问题和解决方案，以便后续改进。
• 编写详细的发布文档，记录发布步骤、注意事项、回滚方案等。
• 定期进行发布相关的培训和知识共享，提升团队成员的发布操作能力。
• 生产环境的变更及时同步到验证群，并@相关同事进行double check。

6.服务下线

服务下线属于高危高作，可能会对系统的可用性和用户体验产生负面影响。为减少服务下线所带来的问题需要制定严格的规范流程和应急措施。

• 【强制】制定下线计划：明确服务下线的目标和理由（如淘汰过时的服务、进行重大升级等）。制定详细的时间表，包括服务下线的开始时间、各阶段时间点和预计完成时间。
• 【强制】通知相关方：内部通知：通知开发、运维、产品、客服等相关团队，确保所有团队了解服务下线的计划和影响。外部通知：向用户发布公告，告知服务下线的时间、影响范围和替代方案。如果可能，提供替代服务或解决方案。
• 【强制】逐步下线：根据服务的功能模块逐步下线，减少对用户的影响。可以通过逐步停用功能或减少流量的方式进行。
• 【强制】回滚计划。指定服务下线过程中发生意外情况的回复计划，比如服务重新上线，数据恢复等。
• 【建议】收集反馈：用户反馈：收集用户对服务下线过程的反馈，了解用户体验和问题。内部反馈：收集团队对下线过程的反馈，评估下线过程中的问题和改进建议。

---

参考文献