从一个不起眼的错误想到 DevOps

2018-03-01  籽藤 

故事背景:我今年干了不少杂活儿,其中就包括在各个环境用脚本创建测试数据。脚本是用 Python 写的,逻辑就是像商户接入那样,调用我们公开的 RESTful API,从而生成相应的业务数据。 
 

这是很简单的脚本,也跑了大半年了,然而前几天我发现有部分数据没有生成。我先本地验证了一下,本地跑脚本没有问题。再上服务器上看 log,确实报错了。

HTTPSConnectionPool(host='*****', port=*****): Max retries exceeded with url: ****** (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')],)",),))

总的来说就是,脚本在本地执行,往 Stage 和 Prod 环境造数据都没问题;在服务器上执行,造 Stage 环境数据没问题,造 Prod 数据就报错了。 
 
问题倒是很好解决,就是字面意思,证书验证失败了,连接还未建立,还没走到后面的造数据逻辑。运维童鞋告诉我,最近证书没有变动过,我自己也知道这个脚本最近也没有更新过,那为啥之前没问题,现在不好使了呢? 
 
答案也挺简单,因为服务器上 requests 包不知道何时更新了。虽然脚本未更新,但是它依赖 requests,之前使用的版本(2.10.0)的 requests 没有新版(2.18.3)验证这么严格。 
 
 由此我想到,如果这是要交付的产品,模块 A 调用模块 B 的接口,出现了上述问题,导致产品业务不可用,那将是多么痛心的事情。而如果要避免此类事件,其实是需要多个角色紧密配合,很难说这是谁的过错。YY 一下这个场景,开发可能吐槽说,运维那边为啥擅自更新第三方包的版本呢?运维也可能吐槽说,明明是你们开发没有指定版本,新加的机器自然用了比较新的版本... 测试或许会飘来一句:难怪在测试环境没法复现...  
 
抱怨总是容易的,可是问题还是得解决。这或许就是近几年 DevOps 被广为称道的缘故吧。 
 
一支游击队要成长为正规军,自然有个步枪换炮的过程。随着业务增长,日志不能随便什么格式都往文件里面塞;监控也不能仅仅只靠云平台上的那些系统指标;部署也不能是直接 remote 到服务器上敲命令... 后端各种业务拆分,分布式架构,高可用集群啥的,把技术同学也折腾得不轻,因为对团队有了更高的要求,过去一个模块,可能被拆成了十个,开发要代码重构就不说了,测试和部署过程也更加复杂了。但这不是我们降低质量标准的理由,希望我上文 YY 的场景只是笑谈,大家都专注于搭建更健全的基础设施,而不是花时间扯皮。

148°|1482 人阅读|0 条评论
登录 后发表评论