“ 是软件就有bug, 第一个bug是一虫子 ”,软件工程的老师是这样讲的。
当bug突破层层检查站,被释放到线上生产环境时, 比如文案错误,xx交易系统不可使用等,根据 其严重性不同,会引发线上的问题,甚至是线上故障。
而在大型软件工程中, 讲究预期一致性 , 非预期内的线上表现,往往伴随着bug的产生:
可能影响 不大 ,引发线上问题
比如运营图片没有更新,显示成了昨天的了,且今天无重大活动
可能影响巨 大, 引 发线上故障
比如运营图片没有生效,原因是服务端 最近一次 发布,代码本身有bug,某些行为下会触发生效,导致全平台配置失效,App内所有图片坑位白屏
线上故障带来的不仅仅是bugFix这么简单, 对于有一定规模量的产品, 尤其是toB或付费类产品更甚,引发的可能是公关甚至品牌。
让我们重新review一下,这种线上影响较大的技术故障处理的注意事项,当真的发生了线上故障:
处理故障三板斧
1- 止血,止血,止血
先“ 止血 ”,再看为什么 。线上故障就像是系统的破损,当发现并确认问题确实存在,第一件事情就是“ 止血 ”, 让问题第一时间得到遏制,解法可以不是最优,但一定要最快。
2- 复盘
趁热打铁,在1-3天内,重新推演问题的发生的原因, 找到根本原因和触发原因 ,分析影响面,是否要主动安抚客户。在每个关键节点, 当时 为什么关键“卡点”处,没有发现该隐患,还是发现了,谁决策了“带伤上线”。
3- 改进
如果有类似的场景, 怎么 保证不会再次发生 ,那么需要接下来做哪些Action? 落实到具体负责人, 确定落地的时间点。
避免故障三板斧
这里,简单分享下,目前业内比较常见的共识方法论
1. 发布前, 确保有效的数字化监控
近些年,在一线工程团队里的一种思潮是, 重视有效的监控大盘 ,减少对个人操作经验依赖,重视 流程信息化 审批,减少“发布核按钮”掌握在单个人手里。
2. 发布时, 逐步灰度
每一次新功能及新产品的发布,都 不要一把梭,要逐步放量 。可以从用户比例、uid分桶、服务端机房分批、非核心用户、VIP用户等逐步放到止100%流量。
3. 发布后, 一键回滚的能力
只有 每次发布都具备一键回滚的技术能力 ,才能在真的发生问题时,瞬间做到问题止血。对软件工程中featrue更有控制力,上线还是下线,从容应对,灵活控制。
理解产品周期与线上故障
技术故障,在产品的初期,到发展期,到成熟期,到半衰期,是有着不一样的影响效力和重视程度。
产品初期
一切为了快速 试错+反馈
所有的功能和技术实现围绕的是,商业核心问题的是否被市场验证。这时想的是,解决方案是否有效,是YY的,还是击中了用户核心诉求。用户愿意花钱买你的服务吗?愿意花多少钱买?追求的更快的是错误反馈。
产品发展期
故障的快速处理 开始被要求
核心功能看似已得到市场验证,至少有部分人群,真的愿意“掏腰包”买你的服务,这时团队追求转变喂新用户拉新。运营力量开始介入,进一步提高新用户涌入,刺激体量上一个新台阶。产品服务的稳定性、一致性开始被重视,技术侧的工程能力逐步搭建,要求可用性比例, 故障可以有,但同样的故障决不允许出现第二次 。
产品成熟期
线上故障 几乎是0容忍态度
产品在细分领域占据了一定份额,很多时候没有可参照竞品。技术所维护的业务形态,变得越来越复杂,代码量越来越多。技术架构升级与产品横纵向整合同时推进, 故障等级也在不断被细化, 线上故障开始有了问题追责 。
产品半衰期
既要 业务创新, 又要 技术稳定
技术上既要 维护前人的老代码,又要实现YY的新业务需求和老系统嫁接。对于组织来说, 没有企业喜欢衰退期,要么 尽力延长成熟期,扩大市场规模;要么 寻求变革突破,宁可赴死也不等死。
现实的意义
在当下 敏捷/精益 迭代 + 狼性创业文化 的大行情下,不论是一线技术主管还是一线扭螺丝的,其实大家每天都是在高强度+高并发的工作中度过。很多时候, 人每天的精力是有限的 , 扯皮、需求变更、开会等都会压缩工期,最可恨的是Deadline几乎很难延后。
质量和上线速度,落到实际工作中,有时候真的很难两全 。 这时候故障的被发现,有时候反倒是 梳理这些事情的一个抓手 ,让类似的故障不再发生,就需要技术侧的架构更合理,监控更完善,流程更规范,这反倒是给技术同学争取了一些时间buffer和价值意义实践的窗口。产品侧不能只顾提新需求,不考虑整体可靠性及由于业务越来越复杂,必须要进行的基础技术能力升级。
未来还能做什么?
对线上故障的重视,短期内可能会增加一线技术同学的心里负担与工作,但长期来看, 倒逼各角色对线上质量的重视程度 ,用户的体验,功能的稳定,对团队及核心服务可靠性的支持意义重大。
敬畏每一次线上操作变更的风险 ,落实发布能够灰度、数据大盘监控、业务数据指标是否符合预期。
加强有效报警,从对敬畏故障的思想做起,在基础能力建设完善的基础基础上,未来实现“无人盯守,发现问题,自动告警,风险预测,自动回滚”,让devOps从经常要搞到凌晨发布,无法安心入睡的困境中解救出来, 减少一线拧螺丝人员的背锅次数,减少系统释放处来的背锅HC机会,最终实现已知领域内的线上功能服务的高可用 。
欢迎关注微信公众号:土豆他爸爸
坚持每周写一篇 生活|技术|时事 的原创总结