灰度方案如何拉低我的焦虑值

“潮退时就知道谁在裸泳”

如果给你 100W/M 的工资,你能写出无 bug 的代码吗?

我相信有这样的大神存在,但在一个项目要靠大神才能保障安全,也是可笑至极,最后的结果极可能是大神要烦死,小神们没空间成长,参天大树之下只有杂草丛生;

正常项目都会遇到人员的流失,新人的培养,在能力锻炼的过程中,总会出一些线上问题,当问题出现时该如何处理?

风险的规避隔离应该是每一个人的选择,灰度是我的其中一个极有效选择;借助灰度可以打造一个良性循环的团队升级机制;

灰度解决的痛点

在我的实践中,灰度会解决下列问题:

1. 次生灾害:一人生病,所有人受治疗的方案,可能  使正常用户受连带影响,甚至导致次生灾害的发生;
2. 版本困境:版本升与不升都有用户受影响,升新版本就会影响 A 用户,不升版本 B 用户;
3. 版本魔咒:每个版本总会有些问题的魔咒,上线会紧张,节假日前更慌的要命;
4. bug 复现难:某个问题在本地无法复现;
5. A/B 测试:一部分用户先尝试某功能,获取用户报告;

上面列的问题会复合发生,我曾经历一个问题(2 与 4 的复合体),真的打打飞的去现场改 bug; 升版本会影响 KA 用户,不升版本又不能赶上功能上线时间;但本地使用各种方法都不能复现,最后  迫不得已,打飞的去客户现场才解决了问题 ;

灰度 是什么

百科上解释

灰度 是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行 A/B testing，即让一部分用户继续用产品特性 A，一部分用户开始用产品特性 B，如果用户对 B 没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到 B 上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。 灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。

在上线流程上添加一个环节 “灰度上线”,就能解决上面列出的 5 类问题;

问题突发时: 尤其在问题并不明朗的情况下,可以把受影响用户切到灰度,单独为其部署 fix 版本;控制了影响范围,上线心理压力自然小些;

新版本上线:可以拉一些用户进行体验,借助数据分析, 错误追踪,售后等措施,获取用户反馈,在震荡期过后,可以平移到线上;

A/B 测试:新特性上线,邀请用户体验新功能;

灰度实现

这里不做过多说明,如果对方案有兴趣可以留言;

总结

灰度方案 也不是银弹, 只是辅助工具;

配合错误  跟踪,数据统计等工具,能达到最好的  “治疗”效果;