当前位置: 首页 > >

关于稳定性和故障的一点思考,每个互联网公司都吃过这个亏!

发布时间:


作者:丁浪,目前在创业公司担任高级技术架构师。曾就职于阿里巴巴大文娱和蚂蚁金服。具有丰富的稳定性保障,全链路性能优化的经验。架构师社区特邀嘉宾!



引发故障的原因主要有几种:


    遗留系统的坑和技术债务。这些隐患就像一个个地雷,搞不清什么时候会爆炸。比如以前的架构设计问题,模型设计问题,代码实现的问题,性能瓶颈等。追究起来大家都会说是"历史问题",或者叫"有人生,没人养"

    由变更引发。为了追求所谓的"敏捷"和"快速交付"匆忙上线,结果是带着问题上线的,自身就存在缺陷甚至还可能引发其他问题。开发或优化A功能上线后结果引发了B功能的潜在bug最终导致故障,得不偿失

    其他因素。比如人肉的误操作,比如运行环境不规范,比如系统相互依赖、部署和公共资源隔离不彻底等


多数公司遇到的其实都是些很基本的技术问题,并不是像电商、金融类、微博的一些复杂场景性、超大规模性的技术问题(例如:突发大流量)。解决起来往往是受限于资源不足、跨组织推动困难、一线开发人员意识薄弱和积极性不高等


关于遗留系统和技术债务的应对措施


    见招拆招,不止是解决表面问题,而是遇到问题后得找到根本原因并解决,学会举一反三的解决类似问题。周期长,见效慢,是一种相对被动的方式

    主动审视既有系统的坑,分优先级去推动解决。修缮式的做法资源投入相对可控,可验收阶段性的成效

    重构或重写。拆迁式的做法对技术人员来说最爽,但资源投入比较多,很容易耽误业务发展更新,而且没有人敢保证重新做一套就完全没问题。以目前的现状推倒重写的可能性很小,当然,必要时小范围重构是可以的


根据经验,挖坑只需要一天,而填坑则可能需要一周。规范、设计等往往在项目初期和*讨杏行В潞笤偃プ鲈蚝苣巡咕龋疃嘀荒芏笾撇嗟目樱质稻褪侨绱瞬锌


关于变更


    新开发功能或者重构是需要有设计和方案评审,形式不限、简单实际,目的是搞清楚为什么要做、打算怎么做(关键实现)、以及这么做有什么风险和关键注意事项。要开始尝试去做,否则永远都是停留在纸上的模板

    需要补充测试用例覆盖,合并代码和上线前都需要回归,上线有也需要验证主链路。这个过程很漫长,但是日积月累的。测试用例也需要审查和长期治理的,不能是为了应付"覆盖率"这些指标而做

    code review ,静态代码扫描... 这些不是灵丹妙药,但关键系统要先做起来

    发布窗口收紧,节假日前禁止发布,必要时走紧急发布窗口。系统趋于稳定后,自动化体系和工具链也成熟了,控制权将逐步*桓滴裼虻募芄故蚑L

    可灰度、可回滚、可监控 这是金融核心系统保障稳定的"三板斧"。灰度和引流的能力可能现在并不具备,但是也要考虑,哪怕是实现的龊一点。至少要有优雅停机的能力。快速回滚的能力目前是具备的,但是比较依赖人肉。监控和日志,这个目前做的也不太好,需要改进


发布后除了产品验收交付的新功能,技术人员一定要验证主链路,盯监控,盯日志,发布完就闪这是红线


关于故障应对和管理


    不要幻想"完全没有故障"。我们要做的是怎么尽可能避免故障,以及怎么缩短故障影响时间、缩小故障的影响范围等

    故障应急处理的原则是第一时间快速止损而非彻底解决,无法快速解决的故障应该升级到更高层面(例如:通知运营、客服、销售、公关等团队)。原则上是要快速解决和应急,但技术需保留现场(如日志、dump信息等)以便分析根本原因并彻底解决。过程通常包含:发现问题、定位问题、解决问题、消除影响(比如技术的恢复降级开关、客服通知客户并安抚客户等)、复盘问题等阶段。应当杜绝"*糁伟俨"的盲目操作,不要放过任何一个"神奇的问题"

    故障应该被管理,要有定级、定责、复盘等。定级、定责的原则这些都要写清楚,避免扯皮、推诿

    复盘的根本目的是为了从故障中吸取经验教训。应该记录处理过程,多问为什么并分析清楚根本原因,参考价值,以及后续改进计划。过程公正、透明,不要形式主义,参与者不做"围观者"和"事后诸葛亮"。要学会举一反三并避免类似问题在其他地方再出现,总之学费不能白交。定期审视系统的健康状况有助于改进系统

    定责和惩罚是两回事,对事不对人。鼓励做事,应尽量避免让一线人员产生"做的多错的多"的误解从而打击到大家做事的积极性

    制定明确的红线、高压线,宣传和提高大家的意识,很多问题是意识薄弱导致而并非技术人员能力不足

    需要沉淀一些应急预案,即使系统趋于稳定后也需要不定期做一些"线上故障演练"


对于触碰高压线或者态度恶劣的这种应该受必要的惩罚。但不建议将故障和绩效强挂钩,应该阶段性的看问题,如果某人是偶尔的犯错,态度良好且后续表现有明显改进,这种就不该影响到整体绩效。如果是频繁犯错,未见改进,这种在绩效沟通时可以就事论事


提倡的和不提倡的


    优先通过技术手段解决问题,标准化、自动化、可信赖。例如:增加蓝绿发布来控制受影响范围从而降低变更引发的风险,通过自动化用例覆盖来回归现有的功能,通过完善的监控和日志来预知故障并缩短问题的排查解决时间...

    特殊时期才加入必要的流程管控,比如新增流程节点、doublecheck等。这里要区分常规流程和非常规流程。codereview、QA确认之类的属于日常发布的常规流程,而"总监/副总审批"则属于非常规流程,一般只有封网等特殊时期才会启用,不能是常态

    如上所说,"一刀切"的处罚手段并不能真正改善系统质量和稳定性现状,还会打消一线技术人员的积极性,是应该尽量避免的

    直视问题并解决,而不是想办法"绕过去"。例如:下游某个基础的服务经常不稳定,应该是花力气好好优化掉,而不是让上游的一些应用来花费很大精力想办法怎么绕开和避免

    优秀的工程师应当思维严谨,对技术问题要刨根问底。不要出问题就找出"网络抖动"等虚无缥缈且毫无说服力的原因


文化


鼓励做正确的、有价值的事情;

与那些想做事的、愿意共同成长的人相互成就;

信任、授权、ownership;

敬畏生产、质量意识、荣辱感;


最需要做的


    单元测试、静态代码检查、技术设计和评审、code review、故障复盘等。通过这些手段扼制既有系统产生新的坑,并持续改善

    明确故障定级标准、定责原则、开发/运维的高压线等等。提升一线人员的意识,激发责任心和积极性,逐步建立起以应用为核心的owner制

    各业务线 + 运维 需要有作战地图和值班机制,除了降低故障发生的几率,也要努力降低故障影响范围和缩短影响时间,逐步沉淀应急手段和预案

    主动审视和识别现有系统中的一些隐患,短期内无法彻底解决的需给出应急预案,以及后续的治理方案和大致计划

    推广devops文化,建立devops*台,配置管理(CMDB),paas*台等提升研发效能和质量有些功夫是需要长期修炼的,不一定立马就见效,但长期来看是很有效的
    没有银弹,没有灵丹妙药,也没有一劳永逸


codeReview



    Leader、架构师主动抽查/审查代码,直接指明存在的问题

    可以是小团队在会议室"晒代码",由开发人员自己讲出来,评审的人给出建议

    禁止手工直接合并主干代码,在gitlab中通过Merge Request来做合并主干,发布集成前强制指定人CR确认


对于1,2这种主动审查的,目前没有专门的工具去记录,可以先记录在本地,对于一些典型的问题和建议可以放confluence,具体实施时可以再看


静态代码扫描
1.开发人员本地ide中安装插件、模板等,自行做扫描和修复
2.借助sonarqube等*台来实现,和jenkins等CI*台流程整合,构建后生成报告。对系统设定阶段目标,定期检查报告查看达成和改善情况
3.优先关注和接入核心业务系统
该阶段主要关注:明显的bug、潜在的风险、代码坏味道、不规范、安全漏洞等,以及单元测试的覆盖率


单元测试
1.优先关注和覆盖核心系统,主业务流程
2.关注"通过率"、"行覆盖率"、"分支覆盖率"等指标。也需要关注用例的执行效率、用例执行的的稳定性
3.单元测试也是要抽查和治理的。对于一些无用的、滥竽充数的测试用例要及时指出,必要时团队内"通晒"


技术红黑榜
1.对于一些写的好的代码,写的不好的代码,象征性的晒出来,激发技术人员的荣辱感
2.故障记录、公告、盘点统计
3.性能问题定期统计和公告,问题应用、问题接口、问题数据库等直接排出来
...


文档知识库
1.业务领域的一些产品文档,业务知识文档等
2.业务领域的一些架构文档、系分设计文档、技术方案文档、规范等
3.公司级的规范、基础技术、架构大图等
...


对owner的理解
业务域的owner:规划业务发展方向和目标,制定计划,衡量投入产出,拿结果 需要具备产品、技术、业务等多维度能力


应用系统是owner的孩子,需要负责其"生老病死",作为合格的owner至少需要掌握如下信息:


应用名和概述(是web应用还是领域服务、spring mvc还是spring boot、所属业务领域、核心能力、关键职责)

部署架构(线上部署情况、部署那些机器、用的tomcat还是jetty、运行端口、JVM参数、系统资源负载情况、容量水位)

运行状态(当前业务量、应用及关键接口吞吐量、99线/95线/90线响应时间、错误数,未来的业务量评估和容量规划)

关联的数据库、缓存中间件等

关键的服务接口和能力

上下游情况(主要被谁依赖 and 主要依赖了谁)

关键模型(业务模型/数据模型)

关键的配置(业务配置项、开关、监控项等)

包含的定时任务

包含消息topic/队列

系统存在问题、应急手段、长期治理方案和计划


长按订阅更多精彩?



如有收获,点个在看,诚挚感谢



友情链接: