一个心理学问题
在开车方面，在刚开的那三年，我都开得非常小心：开直线会时不时观察后视镜；高速上会按照规定速度开，不快也不慢；绿灯变红灯前10秒，我开始减速。
而最近的我，好几次差点拿罚单。
这其中包括的心理学含义，估计老司机们都能体会到。但是，我无法给出一个明确的心理学定义。
经过
前段时间，我们计划在22:00对生产环境进行hotfix。操作人就是本人。
而13:30到22:00这9个半小时，除了吃饭时间和通勤时间，我一直没有怎么休息过。因为一直在尝试解决一个难题。
21:30，我开始准备22:00的hotfix。内容是修改应用的版本号和Values。改Values是为了适配chart的版本更新。
在22:00时，我们准时开始部署流水线。但是，部署完成时，就有大量告警涌现。几分钟过去，依然无法查到原因。
负责业务的同学开始收到客诉。
我们决定回滚。告警消失。
根据错误的现象，对比预发布环境与测试环境与生产环境的配置后，并没有什么特别不同。
这其中迷惑的地方是chart的技术逻辑和应用业务逻辑都在测试环境和预发布环境都已经测试通过了。为什么在生产就不行？
这是软件工程经常遇到的经典问题。我大脑里也猜到是配置的不一致导致的问题。但是就是无法知道是哪个配置出了问题。如同儿时把钥匙弄丢了在某一片草丛中，你知道钥匙在那里，你找遍了每一寸土，就是找不到钥匙。
在大家都没有头绪的时候，我决定再部署一次，以验证部署顺序是否与这次事故有关系。
我内心明知这是没有希望的。就像在坠崖时抓住了一棵草，明知道没有希望，但是还是会盲目给予那棵草希望。
事实证明，此次事故与部署顺序无关。
大家都安静了。时间一点点流逝，窗外漆的黑夜与花场里，那坡墨竹沙沙响。
突然，视频会议那边的吴同事说：问题应该出在镜像地址写错了。
在确认吴同事的结论的正确性后，我头上的重担总算落地了。
完成部署后，才有空看一下时间，已经是23:20。短短一个多小时像是经历了一天。
以上就是整个事故的过程。
复盘
没有人比我更清楚问题出在哪里了。复盘结果如下：
1. 在部署前，另一个同事要对配置进行二次检查。即MR中需要有人approve才行；
2. 使用Jsonnet配置的方式减少人工配置出错；
3. 在将来设计完整的DevOps系统时，DevOps系统应该对镜像地址与应用名进行匹配校验。当然，连镜像地址都不需要填，就更好（这是理想情况，但是在变更镜像地址的时候，依然可能出问题）；
4. 部署操作人在部署前，一定要休息够。
后记
本次事故，出现了文章开头说的心理学问题。这似乎是人性。为了避免这样的心理学问题，个人认为可以这么做：
1. 故障演练，保持团队对事故的警惕，但前提是监控的告警都完备；
2. 部署操作人轮岗，即使人少的情况下；
欢迎关注公众号：持续交付实践指南
往期好文推荐：
3859
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
