线上事故风险解读之规范篇
专业在线打字练习平台-巧手打字通,只输出有价值的知识。
一 统一编码规范
事故回顾
门店误删事件:由于 switch 分支条件中遗漏了 break 语句,导致程序执行了本不应执行的代码逻辑,意外删除了门店数据。
线程池资源泄露导致 OOM:线程池中的队列数据未能及时释放,造成内存泄漏,最终引发内存溢出(OOM)问题。
日志过载导致服务不可用:在流量高峰期,由于日志打印量过大,占用了大量 CPU 资源,导致服务性能急剧下降,甚至不可用。
数据库查询效率低下:在 for 循环中频繁查询数据库,未进行有效优化,导致数据库负载过高,出现卡顿甚至崩溃现象。
在软件的生命周期中,维护成本通常占据了总成本的 80%,特别是对于大型系统而言,往往需要团队协作进行维护。因此,采用统一的编码风格和开发规范对于提升代码的可读性、健壮性以及团队合作效率至关重要。我们倡导摒弃个性化的代码风格,转而鼓励在遵循规范的基础上,发挥创造性的代码内容,以促进项目的长期发展与维护。
二 环境配置开闭原则
环境配置问题主要涉及网络连接、服务部署以及数据存储等多个环境。这些问题往往源于配置错误、环境间的错误交互以及数据共享管理的不当,从而引发一系列复杂且难以解决的技术难题。
遵循开闭原则(即对扩展开放,对修改关闭)是提升系统设计稳健性的关键。实践表明,那些需要人工介入的操作或配置,往往成为事故频发的高风险区域,这正是墨菲定律的一种体现。因此,在开发设计中融入开闭原则显得尤为重要。
同样,优秀的环境配置也应遵循这一原则。具体而言,在进行系统上线扩容时,应确保过程标准化和自动化,尽可能减少或消除人工干预,以此降低出错风险并减轻维护者的认知负担。验证这一标准的方法相对直观:只需让一个不熟悉该系统的人员,依据既定的扩容标准操作,若其能顺利完成服务扩容,即可视为达标。
三 设置安全防火墙策略
在 IT 网络安全防护领域,专业人士常遵循一项核心原则:“防入侵(进不来)、防窃取(拿不走)、防理解(看不懂)、防篡改(改不了)、防逃逸(跑不掉)”。
这一原则生动描绘了安全防护的核心理念与优先级,实质上是安全架构设计的高层哲学。在技术实施过程中,我们也应借鉴这一理念。大型线上安全事故往往源于流程链中多个环节的疏漏。
此外,依据金字塔模型,问题发现越早,解决成本越低,因此需合理分配精力,避免将设计工作拖延至开发阶段,或将研发任务延迟至测试后处理。
资源隔离策略
环境隔离:严格区分预发布与线上环境,包括服务与数据,确保互不干扰。
网络隔离:将测试环境与线上机房网络有效隔离,降低潜在风险。
配置隔离:为不同服务分组实施配置隔离,确保各服务间独立性。
权限隔离策略
权限收拢:精简管理系统角色权限,严格控制服务器资源管理权限,防止权限滥用。
权责明确:明确划分研发与测试职责,禁止研发人员私自修改线上测试数据,确保权责一致。
流量灰度控制
针对复杂核心流程的升级改动,实施流量灰度控制与应急回滚方案,有效缩小问题影响范围。
DDL 操作、日志管理、开关控制及监控等关键问题解决工具至关重要。在自动化实现前,可适当引入第三方人工检查机制,确保系统安全与稳定。
四 团队多方协同
在产品从构思到交付的全过程中,产品、研发、测试、运维四方构成了不可分割的整体,项目成功交付离不开各方的紧密配合与高效协作。
早期的软件开发阶段,角色分工尚未细化,研发人员往往身兼多职,如产品规划、架构设计、测试验证及运维管理等,此时的团队协作主要聚焦于业务功能的横向整合,而垂直交付流程中的沟通协作需求相对较少。然而,随着市场竞争的加剧和项目复杂度的提升,对产品质量和交付效率的要求日益严格,按照产品交付流程进行角色细分并强化协作成为行业共识。
研发团队作为交付流程的核心枢纽,扮演着承上启下的关键角色,是确保项目顺利落地的决定性因素。因此,研发人员的职责边界往往较为模糊,需要跨越传统界限,主动推动项目进展,以结果为导向,积极承担责任,这样才能更有可能取得良好的成果。
在多方协作中,研发团队的关注点主要包括:
与产品团队协作:紧密围绕业务目标,共同制定实现方案的 ROI 评估、降级策略及灰度发布计划等。
与研发团队协作:明确接口交互方案、参数约定、调用频率、数据流向及用途,并共同制定应急响应计划。
与测试团队协作:协同确定测试方法、测试范围、测试环境、回归测试时机及压力测试计划等。
与运维团队协作:共同规划部署架构、制定应急预案及数据修复方案,确保系统稳定运行。
五 基础设施共识
应用的可用率受限于其底层基础设施的可用率,可以说,基础设施的可用率构成了应用可用率的上限。因此,确保底层中间件的高效稳定运行对于提升应用可用率至关重要。
以消息队列(MQ)举例,需要团队内形成一些基础共识:在 MQ 消息的处理中,消费方应专注于轻量级的业务通知,避免承担复杂的业务逻辑处理。若需处理繁重逻辑,建议将消息本地化存储,并通过分布式任务调度系统来消费处理。
整理出常见避坑建议:
避免核心业务 MQ Topic 复用:为防止一个业务场景的消息处理阻塞影响其他业务场景,核心业务应使用独立的 MQ Topic。
注意 MQ 消费超时问题:MQ 默认消费时长通常为 120 秒,超时后会自动重试,这可能导致消息队列积压。因此,建议将消息功能限定为通知,避免处理复杂逻辑。
避免使用 Sleep 阻塞 MQ 消费:当系统需等待另一系统执行完毕再消费 MQ 时,应使用 MQ 自带的延迟消费策略,而非 Sleep 方式,以避免消费缓慢导致的消息积压。
谨慎使用有序队列消息:有序队列消息吞吐量较低,建议使用状态机机制和服务幂等方式替代。
本地多线程消费时选择适当队列:在使用本地多线程进行消息消费时,建议线程池采用 SynchronousQueue 队列,以避免使用其他有界队列类型时,在服务重启场景下可能出现的消息丢失风险。
六 总结
本文深入探讨了软件维护过程中遵循规范的重要性,并通过一系列因编码不规范而引发的事故案例,凸显了规范操作的必要性。随后,文章着重强调了在进行环境配置时,应严格遵循开闭原则,即系统应对扩展保持开放态度,而对修改则保持封闭,以此来有效降低出错风险,并据此提出了优秀环境配置应达到的标准。
在安全防火墙策略方面,文章系统阐述了安全防护的核心理念,包括资源隔离、权限隔离以及流量灰度控制等关键策略,这些策略对于确保系统安全至关重要。
此外,文章还详细分析了产品、研发、测试、运维四个团队在协同工作中的角色定位与核心关注点,特别强调了研发团队在推动项目进程中的桥梁作用。
最后,文章着重指出了基础设施优化对于提升应用可用性的重要性,并以消息队列为例,给出了具体的处理建议。同时,文章还总结了在实际操作中常见的避坑指南,为相关人员提供了宝贵的参考。
版权声明: 本文为 InfoQ 作者【巧手打字通】的原创文章。
原文链接:【http://xie.infoq.cn/article/ffe4c8f83a17ba5caefb79ff2】。文章转载请联系作者。
评论