请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 232|回复: 0

如何幂等地解决不一致情况

[复制链接]
发表于 2020-12-5 23:49:14 | 显示全部楼层 |阅读模式
"一周内上线"是一个很恐怖的任务。我们目前有十几个团队编写出的几万行的shell脚本。虽然我们能够快速分析任何一个集群的问题所在,但是修复它意味着十几个团队不得不提交数百个Bug,接着我们就只能希望这些Bug 能被及时地解决。

, ?* C4 j4 x8 ^; h, e
我们意识到,从"Python 单元测试发现错误配置"到"Python代码修复错误配置"的演进能够使我们更快解决这些问题。

/ _$ t+ x; t5 ^# |! J; z
单元测试已经能够指出被检查的集群中哪个测试失败,我们就给每个测试增加了一个修复程序。如果每一个修复程序都具有幂等性,并且假设所有的依赖关系都得到满足,那么修复问题就是简单而安全的。强调修复程序的幂等性意味着团队可以每 15分钟运行一次他们自己的"修复脚本",而不用担心对集群配置造成损害。如果DNS团队的测试在等待机器数据库团队对新集群的配置,只要该集群出现在数据库中,DNS 团队的测试和修补程序就会立刻开始工作。

+ q' V' U8 q  o! o2 D9 a* Q
以图7-2 展示的测试为例。如果TestDNSMonitoringConfigExists失败,我们可以调用FixDNSMonitoringCreateConfig,这样会从一个数据库中将配置去掉,然后将一个骨架配置文件提交到版本控制系统中。接下来重试TestDNSMonitoringConfigExists成功,然后就可以进行TestDNSMonitoringConfigPushed测试。如果测试失败,就运行FixDNSMonitoringPushConfig。如果一个修复程序失败多次,自动化系统假设这个修补程序失败、并且会停止进行,通知用户修复。
8 ?  u& a, Q4 d& R1 }

9 Y) d9 `! P; Z/ m
粘贴上传202012052348298387..png

' B) W  n* c6 e6 u8 {$ r6 E
# H2 T+ b; i4 Z# |5 t* \
; B( H8 L; B" V3 M- g0 K
图7-2∶DNS 服务的ProdTest,体现了-个失败测试的后果仅仅是多运行-个修复程序,左侧是测试,右侧是对应的修复程序。
+ b3 B+ g; I6 T! c, m
有了这些脚本后,一小组工程师可以保证我们能够在一个或两个星期内从"网络就绪以及机器在数据库中存在"发展到"服务网络搜索和广告流量的1%流量"。在当时,这似乎达到了自动化技术的巅峰。

3 z& M  g0 P' v! h3 k
然而,现在回头来看,这种方式本身是存在严重缺陷的;在测试、修复、再测试之间的延迟引入了"不稳定"的测试,时好时坏。并不是所有的修复程序都具有幂等性,所以一个"不稳定"的测试引起的一次修复可能造成系统处于不一致的状态。
3 e8 E: E- f; _1 i! Q' K
$ S/ O( E; w7 I) I

  X+ z: ^' v( V+ u* i




上一篇:舒缓疼痛∶将自动化应用到集群上线中
下一篇:自动化程序的不同体现在哪三个方面

本版积分规则

本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2021-1-25 10:06 , Processed in 0.161416 second(s), 33 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表