后台运维操作建议

1.版本升级

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

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

2.配置发布

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

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

3.数据库/脚本操作

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

4.发布依赖确认

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

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

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

5.发布规范

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

强制:

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

建议:

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

6.服务下线

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

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

参考文献

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值