故事背景：我今年干了不少杂活儿，其中就包括在各个环境用脚本创建测试数据。脚本是用 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 的场景只是笑谈，大家都专注于搭建更健全的基础设施，而不是花时间扯皮。