其他
从拼多多系统漏洞， 阿里专家谈码农如何防背锅
点击上方“开发者技术前线”，选择“星标”
你就是真爱
转自：土豆他爸爸
20号凌晨 拼夕夕出现重大漏洞， 用户可以在无限制情况下领取100元无门槛优惠券，这吸引了大量羊毛党蜂拥而至。这次漏洞给拼多多造成了千万级别的损，最后官方发布报告称为故障并且已修复，并已做复盘。所以线上bug预案和如何防止故障扩大的问题，给开发者和管理带来了思考。
据说本次事发， 当事者部们年终全没了，具体操作人可能也会带来法律的制裁，因此背锅这个词在软件开发中比较常见！
本文是蚂蚁金服专家谈对线上故障处理的方案。
第一个bug是一虫子
“是软件就有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机会，最终实现已知领域内的线上功能服务的高可用。
---------- END ----------
开发者技术前线 ，汇集技术前线快讯和关注行业趋势，大厂干货，是开发者经历和成长的优秀指南。