作者｜TesterHome投稿
最近这一段时间，阿里声音不断，热度上估计只有openAI能一较高下。除了分分合合的组织架构、裁员带来的降本增“笑”，就是近两个月连续故障了，先是10月语雀宕机8小时，接着11月阿里云史诗级故障，紧接着又是支付宝会员中心不可用。网上一时议论纷纷，口诛笔伐，黑阿里成了技术圈的主线。开发圈的人说，“看吧，把经验丰富的老人裁了，系统不稳定了吧”，测试圈说，“看吧，把测试裁了，没人测试了吧”。人人都想在这几次故障中找到存在感。
其实在阿里云故障出来之后，我（作者）也想蹭个热度，速度不够快，网上已经各种大神长文分析了，于是悻悻作罢，事后诸葛亮也不多我一个。我所在的测试群里，测试同学各种开心，都觉得离开测试不行了吧，故障了吧。想起我们内部常说的一句话，出两次大故障，才知道测试的重要性。 但是严格来说，其实这3个故障，测试工程师想关性并没有那么大，我们不妨看看故障，然后分析下：
据语雀公告，10月23日下午，服务语雀的数据存储运维团队在进行升级操作时，由于新的运维升级工具 bug，导致华东地区生产环境存储服务器被误下线。受其影响，语雀数据服务发生严重故障，造成大面积的服务中断。为了尽快恢复服务，语雀和数据存储运维团队全力进行数据恢复工作，但受限于恢复方案、数据量级等因素，整体用时较长。
-- 语雀故障
2023年11月12日17:39 起，阿里云云产品控制台访问及管控 API 调用出现异常、部分云产品服务访问异常，工程师排查故障原因与访问密钥服务 (AK) 异常有关。工程师修订白名单版本后，采取分批重启 AK 服务的措施，于 18:35 开始陆续恢复，19:20 绝大部分 Region 产品控制台和管控 API 恢复。
大概原因：访问密钥服务 (AK）在读取白名单数据时出现读取异常，因处理读取异常的代码存在逻辑缺陷，生成了一份不完整白名单，导致不在此白名单中的有效请求失败，影响云产品控制台及管控 API 服务出现异常，同时部分依赖 AK 服务的产品因不完整的白名单出现部分服务运行异常。
-- 阿里云故障
以上信息均来自互联网，支付宝会员中心信息没有找到。网上还有比较具体的技术分析，我就不贴上来了。
我们先看第一个点，为什么这些都没有测试？
这个点其实有三层含义，第一层，有没有测试工程师？第二层，测试工程师有没有测？第三层，除去测试工程师外，其他角色没有测试吗？很显然，这三层很可能都没有做到。
根据几个微信的软件测试群里的百晓生们说，阿里云很早就开始去测试化了，早就没有专职的软件测试工程师了。 语雀应该有测试工程师配备，不过按笔者对阿里的理解，这种类型的产品，研发测试比应该高到“令人发指”，而且语雀这个故障其实和语雀测试工程师应该也没有关系，谁能想到底层数据库的运维团队会野路子呢？当然也有不少同学说，不可能会给运维团队配备测试工程师，这也是人之常情，毕竟在如今的形式之下，用得起测试工程师的公司不多了。所以就到了第三层，难道离开测试工程师，研发角色、运维角色连自己的代码都不会验证了吗？
接着，我们看第二点，我们假设有测试工程师这个角色存在，那么测试工程师就能保证不会出故障？ 百密都有一疏，更何况是穷举的测试。所以测试工程师们，你们就别自嗨了。阿里云AK这个异常路径，很有可能就是测分遗漏，或者测试执行遗漏呀。假设是这样的，那就是个背锅侠。还好阿里云这次应该没有用到测试工程师，所以锅应该甩给了运维。
作为事后诸葛亮，我也可以分析的头头是道，从网上一些比较准确的分析中，明显是可以看出，全是低级错误，但凡有人验证一下，就不会出问题。那为啥会出问题呢？在支付宝会员中心不可用之后，我在和同事在楼下抽烟，我们觉得本质原因，是技术人员这个群体安全感缺失。在当下降本增效的环境下，公司、组织、团队已经没办法给到大家安全感了，而没有安全感，人心惶惶，谁会踏实做事呢？
2017年，调研公司盖洛普提出了一个估算：心理安全感，可以降低27%的员工流失率、减少40%的安全事故，提高12%的生产率。 （不知道真假，网上搜的）。很显然，阿里最近频发的故障，笔者以为和技术同学的安全感息息相关，反正看不到明天或者后天的希望，不如随便上个临时方案，搞架构的人都知道，临时方案就是最终方案，最终隐患就慢慢堆积了，突然有一天爆发了，就成了行业的笑话。那么现在这个环境怎么才能拥有安全感？从公司层面，保持信息透明，视人为人，裁员也让员工明明白白，开开心心的。从员工层面，努力工作，努力成长，即便丢了这一份工作，也能快速找到下一份，让自己有选择的余地。
以上笔者吐吐槽，真心希望大环境好起来，希望有一天，技术同学可以在一家科技公司，安安心心干到退休，为公司奉献一生的时候，也能得到公司的尊重。
TesterHome学堂：
