Redian新闻
>
毕玄:稳定性,难的不是技术,而是……

毕玄:稳定性,难的不是技术,而是……

公众号新闻

作者 | 毕玄  

作为一个惹出过和处理过一些严重故障的人,我仍然觉得要做好稳定性,最难的并不是技术。

或者更准确的说,关于怎么做好稳定性这个话题,从技术上说,从代码到设计到变更都有全面的指导思想和原则。你如果去看的话,很多故障复盘的改进措施处,基本上会看到各种类似的话。

然而,要落地好这些思想和原则,就是一个很复杂的话题了,有能力要求,还有更重要的是「投入要求」,而且并没有这样的银弹级产品——某件事,或安装一个什么软件,就可以保障稳定性了。

先简单说说技术上关于稳定性的指导思想,然后再来说为什么难的不是技术。

代码层面关于稳定性的指导思想

我之前说过,是不是优秀的程序员,代码是最好的证明,优秀的程序员的最大差别其实就是在代码的鲁棒性上,而这个一方面需要极强的能力,看看 Netty 的代码里对各种边界情况的处理就知道要求多高,另一方面则是需要有投入的保障,否则都在赶进度,自然是会把鲁棒性相关的代码放一边,毕竟很多时候这些代码还挺难体现价值的。

代码要写得鲁棒,有很关键的几点:

  1. 对输入的边界的控制,确保输入是符合自己的预期的,而不只是文档上写的一些对输入边界的约束,例如最典型的故障是批量操作型的接口,由于批量操作的量超过了预期,直接内存溢出等;

  1. 对使用到的 API 需要有深刻的理解(包括实现原理、代码细节),这个其实对程序员的能力要求是非常高的,这里用到的 API 包括了语言本身提供的,这也是为什么很多时候大家觉得面试的时候问得非常的细,好像这些技能对实际写写业务代码也没什么影响,但其实只有这样,才能知道各种情况下的状况,从而在真正出故障的情况下能快速处理;

  1. Fail fast,不管什么情况,以保障代码能正常运转是最重要的(最简单的标准是别把资源耗尽或 Crash),在碰到意外情况下,尽快往外抛出错误是最好的,当然,这个主要是对在线型业务而言。

设计层面关于稳定性的指导思想

在设计层面,关于稳定性的指导思想,有很关键的几点:

  1. 强弱依赖识别,对弱依赖的地方,确保有各种降级策略,当年阿里某关键系统,就是在做好这点后,稳定性提升了 N 个档次;

  1. 自身能力保护,一定要对自己系统的能力有清晰的认识,例如通常来说在线业务系统的指标通常是每秒处理的请求数,在超出能处理的请求数的情况下,需要尽快 fail fast,在线业务做堆积是不好的,容易出问题,像 Nginx 之类的不一样,但也会对堆积程度有个边界控制;

  1. 容灾能力,这个从集群化、到同城多活、再到异地多活,其实都有各种成熟的案例和相应的方案。

对于架构师而言,在设计层面,对稳定性的投入的平衡是很重要的,这个和代码层面还不太一样,代码层面有追求的程序员很多时候自己就会花时间去做到,但设计层面很多对稳定性的投入可能是非常大的,所以会是更大的决策。

变更层面关于稳定性的指导思想

专门说变更,而不是整个运维层面,是因为通常故障和变更会有关系,运维的话比变更这个话题大太多。

在变更层面,关于稳定性的指导思想,有很关键的几点:

  1. 强制灰度,毕竟能灰度,相对来说就能更好的控制故障的影响范围(另外一个词是爆炸半径),这一点呢,我觉得只要不完全是通过系统去做的变更,就很难完全做到(人很多时候还是会容易信心爆棚),非常非常核心的系统,其实还是需要有强制流程规则及很重的惩罚规则的,就算是以影响效率为代价,毕竟有些时候慢才是快;

  1. 可监控以及可回滚,没有监控,就完全没办法知道变更后的情况,可回滚通常是变更一旦出问题,最好用的招,但确实也会难免碰到无法回滚的变更,那样类型的变更就要高度谨慎了;

  1. 在故障出现时尽快恢复,而不是解决故障,在保留一定的现场的基础上,尽快的恢复问题比查问题重要的多,例如大家很多时候看到最有效的处理故障的方法可能是重启,有同城双活、异地多活的通常最有效的处理方法是切流量等。

持续投入才是最难的

事实上,做好稳定性,难的不是技术,而是……

大家可以看下,是不是在很多故障复盘的改进措施里,都会重复看到上面的影子,说明其实指导思想、解决方案是不缺的,技术上真的没有那么的难,想当年淘宝稳定性很差的某一年,新任 CTO 上来后把稳定性列在了第一考核指标,三个月后淘宝的稳定性就提升了 N 个档次。

但难就难在没有银弹,只能靠大量的细节来落地做好稳定性这个系统工程的事情,这意味着的是大量的投入,能不能在稳定性这件事上保持持续的一定的投入,甚至当成做业务功能实现一样的必须的投入,这才是真正做好稳定性最难的,毕竟就算有指导思想、解决方案、能力,但没有相应的投入,那自然只能有一定的取舍。

最终呢,总是要还的。

很多做过稳定性这事的人都知道,做这个事情最麻烦的是很难被认可,做的好,不出问题,不懂的人不知道你做了什么,出了问题的时候觉得你到底做了什么,所以会看到很多公司都是运动式地做稳定性,一阵一阵的。

要解决这个问题其实挺难的,我看到做得好一些的,基本是因为稳定性对业务而言是致命的,例如某些行业,稳定性出问题,业务基本就没法进行下去了;还有就是某些处于非常激烈竞争,但又有关键时间点的业务,例如外卖。

只有把稳定性当成业务的功能实现一样,有相应的人员配备和投入,例如做一个业务可能需要多少人,相应的稳定性这块也固定投入多少人,你说到底多少比例合理呢,其实也说不太清楚,但这种简单粗暴的方式其实是最有效的,当然,是不是要把稳定性上升到这样的高度,也需要根据业务的性质、业务所处的阶段来具体判断,以及有这样的投入的情况下,怎么去评判相应职责的团队也仍然是个很复杂的话题。

作者简介

毕玄,贝联珠贯创始人 &CEO 。在创办贝联珠贯之前,他的主要工作经历为在阿里的十四年,先后参与,主导设计并带领团队落地了阿里的多轮重要的技术架构演进,主要为从 0 到 1 打造 HSF、作为主要的架构师设计并带领虚拟团队落地阿里电商异地多活、作为主要的负责人设计并带领团队落地阿里的统一资源调度。当前致力于打造一家为客户提供降低超过 30% 云成本的软件及云服务的公司。

他曾多次以主题演讲嘉宾、出品人、演讲嘉宾的身份出席 InfoQ 技术大会,给听众带来了深刻启发。在今年 2 月份的 QCon 全球软件开发大会(北京站)中,他以《FinOps:从概念到落地》为题做了精彩的主题演讲,使得 FinOps 对于各家企业从概念变成了实际可落地、可行动的降本增效的有效方案。下载完整幻灯片:https://qcon.infoq.cn/202302/beijing/presentation/4905

活动推荐

下一站 QCon 也将继续探索 GenAI 和通用大模型应用探索、AI Agent 与行业融合应用的前景、面向人工智能时代的架构等方向。此次大会策划了 GenAI 和通用大模型应用探索、AI Agent 与行业融合应用的前景、LLM 时代的性能优化、智能化信创软件 IDE、LLM 时代的大前端技术、高性能网关设计、面向人工智能时代的架构、高效的编程语言、性能工程:提升效率和创新的新方法、前端和移动开发的新趋势、现代数据架构演进、建设弹性组织的经验传递、SaaS 云服务弹性架构设计等专题。

想要参加这场技术人的年终盛会?扫码或点击「阅读原文」即可查看全部专题。大会现已进入8 折优惠报名最后10天,立减 ¥1360!详情可咨询票务经理 18514549229(微信同手机号)。12 月 28-29 日,上海·中优城市万豪酒店,期待见面!


微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。
相关阅读
人生走到最后,最亲的不是子女和老伴,而是这个人中国行困扰小仙女们的不是爱情,而是……百度重构的不是如流,而是办公“见多识广”和“少见多怪”的孩子,究竟差在哪儿?不是金钱,而是……普通人提升颜值最快的办法,不是医美,不是化妆,而是……杨伟民最新演讲:“先立后破”不是针对企业,不是针对消费者,也不是针对市场的,而是对政府经济治理而言加沙医院遇袭真相:不是以军干的,而是……90%的人都没想到:家里最脏的地方,根本不是厨房和厕所,而是……美联储何时会开启降息?走线客又找到“新路径”!走过去就是纽约 不是水路不是陆路 而是……乔布斯不是技术大牛,他凭什么赚大钱?朋友家12岁儿子从15楼跳下后,我才顿悟:这一代孩子不是脆弱,而是……苏格兰城堡巡礼上云还是下云,最大挑战是什么?| 对话章文嵩、毕玄、王小瑞真正能解决烦恼的不是钱,而是……苟了又1年,等来的不是新年钟声,而是年终大裁员的丧钟!“色斑”最怕什么?不是柠檬,也不是生姜,更不是医美,而是......婚姻幸福的秘诀:不是忍,不是作,而是……中国要干一件新的大事,一群国家将受益,而最大的变量不是美国,而是…40岁吴昕“失业”现状惊人!女人最大的靠山,不是男人,不是美貌,而是……一个孩子最难越过的坎,不是成绩退步,不是父母离婚,而是……最摧毁婚姻的不是贫穷、不是无性,而是这4个字拒绝他人,既是技术,也是修炼目 光(图)“凌晨2点,发完最后一条朋友圈,他去世了”:人这辈子,最值钱的不是车子房子,而是……华为秋季发布会,炸场的不是芯片,而是“预告”!慢的不是 Ruby,而是你的数据库孩子能不能成学霸,影响最大的不是智商,不是学校,而是…孩子最怕面对的,不是厌学、不是父母离婚,而是……章子怡、汪峰官宣离婚:婚姻最可怕的不是出轨,不是冷淡,而是这件事游纽芬兰散记:西布鲁克湖加拿大各省大学费用出炉!最贵的不是安省也不是BC省,而是这!具备这种特征的婚姻更能长久,不是爱也不是性,而是——这种时候运动,真的不是「健身」,而是「作死」啊!
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。