前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >【DevOps入门】代码重构的下一站:韧性构建 v0.5

【DevOps入门】代码重构的下一站:韧性构建 v0.5

作者头像
程序员吾真本
发布2020-06-28 10:34:41
5080
发布2020-06-28 10:34:41
举报
文章被收录于专栏:程序员吾真本

代码重构、韧性构建与DevOps的关系

作为一个有DevOps追求的程序员,你的目标,肯定是要让代码能在生产环境中,持续稳定地为用户提供良好服务。

但当你撸起袖子翻开祖传的代码后,心里就凉了半截。因为代码实在是难以理解和维护。

于是,你买来老马的《重构》第2版,苦修代码重构。另外还学习和实践了整洁代码、测试驱动开发、持续集成和持续交付。

功夫不负有心人,祖传代码在你手上,开始变得更可读,更易维护。

你还暖心地增加了覆盖关键业务的自动化测试,并且上了流水线,每次代码提交就能跑上一次。

如果流水线变红,10分钟内你就能修复。

当你正为自己感到自豪的时候,意外发生了。

你所参与开发的系统,在生产环境出现了严重的事故——用户无法登录系统。

运维人员用了大半天时间,把公司所开发的所有系统都重启了一遍,但依然无济于事。

最后,一个运维人员无意中发现,一个生产系统所依赖的外部系统,发生了死机。

这导致了层叠失效,并波及到你所开发的模块,并最终把整个系统拖垮。

为什么会这样?因为你当时在开发时,总是假设所依赖的外部系统,从来不会死机。这样就没有设计超时或断路器等机制,来应对这种未知的失效场景。

这时,你开始意识到,代码重构是面向已知场景的。所以无法发现未知场景的漏洞。

代码重构的下一站:韧性构建

你翻开《重构》,找的了重构的定义。

重构,是对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本。

定义里面的“不改变软件可观察行为”,就意味着重构所涉及的软件行为,必然是已知的,否则就无法判断是否改变了该行为。

上图有4个象限。

第1象限,已知的已知行为,就好比用纸叠一架纸飞机一样,一切尽在掌握。

这就像在程序员本机运行单元测试,或修复静态扫描出来的技术债一样。测试用例和技术债,都是已知的。

第2象限,未知的已知行为,就好比一边听音乐一边外出锁门那样,自己都不知道自己已经把门锁得好好的。

当你养成了重构和整洁代码的习惯,也会到达“未知的已知行为”的境界。

第3象限,已知的未知行为,就好比一个最近半年因为疫情在家上网课很久的高三学生,知道今年的高考一定很特别,但就是不知道特别在哪里一样。

当过程序员的都知道,当你写完所负责的模块,第一次在测试环境中进行集成测试,就会预感到,因为所依赖的模块可能没有遵循契约,或测试环境的配置可能有错误,会出现各种状况,但你不知道具体会碰到什么状况。但测试环境还是相对简单的,而且用户一般就你一个人,所以你能估计出一些常见的问题,所以这还算“已知的未知行为”。

第4象限,未知的未知行为。就好比你现在正在北京丰台区,你真的不知道明天疫情会出现怎样的发展。

与疫情的不确定性相比,生产环境的不确定性一点也不少——用户会不会一窝蜂地点击“重试”按钮?生产系统所依赖的外部系统的响应会不会突然出现延迟,或者违反了契约?生产环境所依赖的包,会不会有内存泄露?……林林总总,你真的是两眼一抹黑。

那该如何发现未知的漏洞呢?

能靠人事先评估出来吗?不能。因为如果能,那还算“未知的未知行为”吗?你能事先评估出海鲜市场会爆发疫情吗?

之前未知的漏洞,只能靠系统在实际运行时暴露出来。

让系统在实际运行时暴露出漏洞,也分“被动”和“主动”两种情况。

比如生产事故,以及今年北京新发地农场品批发市场所发现的疫情,都属于被动暴露漏洞。虽然被动,但确实能发现未知的漏洞。

虽然被动的方式能发现未知的漏洞,但是以生产事故或确诊染病为代价的,成本较高。

有没有主动发现未知漏洞的方法?有的,变着花样多考验生产系统就行。比如西游记中四圣试禅心那样,变成母女四人,主动考验师徒四人。又比如北京目前在居民小区所进行的大规模核酸检测筛查,也是主动考验居民健康状态的一种形式。

你弥补了上次生产事故所暴露的漏洞。

接下来,你针对这个有可能会停机的外部系统,设计了能限制爆炸半径的灾难恢复测试——一旦这个外部系统停机,生产系统可以为用户发出提示信息,而不至于一起死机。

为防范灾难恢复测试中的意外,你还设计了能让测试紧急中止的应急机制。

你先在测试环境中运行通过了这个灾难恢复测试,然后又在生产环境上运行通过。这验证了漏洞确实被补上了。

你还将这个灾难恢复测试进行了自动化,使其能持续运行,以验证漏洞不会再漏。

为了引导大家发现更有价值的未知漏洞,你还召开了“考验会”,即让团队成员,根据生产环境可能出现的考验场景发生频次、概率和经受考验的信心,排序选出最应优先进行的考验,并为其设计灾难恢复测试,来验证考验能否通过,以及在考验中发现未知的漏洞。

这样,你就实现了面向未知漏洞的系统的韧性(Resilience)构建。

韧性,来源于“韧性工程”(Resilience Engineering,也称作“弹性工程”),指系统在生产环境的动荡(包括变更、干扰和机会)发生之前、之中和之后,都能相应调整其功能,从而在预期和意外的情况下,仍然可以保持可做出所需操作的能力。

通过上面的故事,你获得了以下启示:

代码重构,能让代码更易读和更易维护,让以后的漏洞修补更加快速。在流水线上运行自动化测试,能发现和修复已知的漏洞。

韧性构建,能通过生产事故,或在测试环境或生产环境所运行的灾难恢复测试这样的考验,来发现并修复未知的漏洞。将灾难恢复测试自动化,且持续运行,能验证漏洞不会再漏。

代码重构的下一站,就是应对未知漏洞的韧性构建,是向DevOps迈出的更大一步。

针对已知行为的代码重构,为针对未知行为的韧性构建,创造了易理解和易维护的代码库,以便分析未知漏洞。

而韧性构建,能将所发现的未知漏洞,转化为已知的软件可观察行为,进行重构,以修复漏洞。

代码重构,一般发生在本机或开发环境,主要由Dev来完成。

韧性构建,一般发生在测试环境与生产环境,主要由Dev和Ops一起协作,来定义系统稳态行为的假设,设计一系列灾难恢复测试,来考验系统在未知动荡下的韧性,并在灾难恢复测试进行时,搜集系统稳态相关的数据,以便发现并修复未知的漏洞。由此可见,这需要Dev与Ops的密切协作。

两者的有机结合,能弥补软件系统已知和未知漏洞,从而更好地让代码,能在生产环境持续稳定地为用户提供良好服务。

如果你听了很久DevOps,但不知该从何做起,那么可以尝试从“代码重构”和“韧性构建”开始你的DevOps之旅。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
CODING DevOps
CODING DevOps 一站式研发管理平台,包括代码托管、项目管理、测试管理、持续集成、制品库等多款产品和服务,涵盖软件开发从构想到交付的一切所需,使研发团队在云端高效协同,实践敏捷开发与 DevOps,提升软件交付质量与速度。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档