昨天下午6点左右学员群里有人说阿里云又出问题了，并且还挺长时间没有恢复了。
我也登录了一下，结果登录直接不停地302。如下所示：
做为阿里云重要的基础设施，这一故障影响了。如官方通告的处理时间线：
17:44起，阿里云监控发现云产品控制台访问及API调用出现异常，阿里云工程师正在紧急介入排查。非常抱歉给您的使用带来不便，若有任何问题，请随时联系我们。
17:50 阿里云已确认故障原因与某个底层服务组件有关，工程师正在紧急处理中。
18:54 经过工程师处理，杭州、北京等地域控制台及API服务已恢复，其他地域控制台服务逐步恢复中。
19:20 工程师通过分批重启组件服务，绝大部分地域控制台及API服务已恢复。
19:43 异常管控服务组件均已完成重启，除个别云产品（如消息队列MQ、消息服务MNS）仍需处理，其余云产品控制台及API服务已恢复。
20:12 北京、杭州等地域消息队列MQ已完成重启，其余地域逐步恢复中。
21:11 受影响云产品均已恢复，因故障影响部分云产品的数据（如监控、账单等）可能存在延迟推送情况，不影响业务运行。
看来运维大招是重启再一次得到验证。
影响范围：
华北2 (北京)、华北6 (乌兰察布)、 华北1 (青岛)、华东2(上海)、华南2(河源)、华北3(张家口)、中国香港、印度(孟买)、美国(硅谷)、华南1(深圳)、英国(伦敦)、韩国(首尔)、日本(东京)、阿联酉(迪拜)、西南1 (成都)、华南3 (广州)、新加坡、澳大利亚 (悉尼)、马来西亚(吉隆坡)、 华北5 (呼和浩特)、 印度 尼西亚(雅加达)、美国 (弗吉尼亚)、菲律宾 (马尼拉)、泰国(曼谷)、华东1(杭州)、华南1金融云
阿里云的事故出的不是一次两次，只是这一次的生产事故范围比较大，并且时间达到3.5个小时。这一次事故，全年的可用性就只能达到 99.96 %了。
做为国内市场占有率第一的云服务，阿里云这次事故的重要性在哪呢？
-
对于公有云一直提到的稳定计算能力的信心会有影响。
-
对于一些强依赖公有云的企业，需要考虑应急方案。
-
对于重要的IT系统的非功能能力验证过程需要重新审视。
关于故障定级，事故分析，已经有大量的从业人员连蒙带猜了，也不差我这一个。所以做为非内部人员，我也不去瞎蒙了。
写这篇文章也不是为了笑话阿里云这样的企业连可用性都保障不了。
只是从这一事故来来说一下，一个企业的IT系统的非功能生命线到底应该如何保障。
对于一个IT系统来说，质量保证分为两大类：功能、非功能。
功能的保证我觉得大部分企业只要有业务测试（不管是手工还是自动化）的环节，业务功能还是基本可以保证的。
但是非功能的范围可就有点麻烦了。因为非功能能力的范围是非常庞大的。简单的从特性上划分，我们可以分这些（特性的划分在不同的人眼中是不同的，所以你可以根据自己的理解去划分）：
只划分这些还远远不够，还要有相对应的落地规范、指南性的具体描述。
有很多企业在非功能领域中，对于性能做的还稍微多一点。再加上近些年提到的"混沌工程"，也做一些故障演练之类的事情。阿里自己就有相应的混沌工具和服务。
但是这些都还只是冰山一角，没有达到方法论的级别。
做为一个IT从业近20年的我来说，见到的生产事故不是一次两次了。从技术的角度上来说，没有100%不出生产事故的系统，只能尽力减少事故次数和时间长度。
我们可以看到，企业在计算IT系统可用性几个9的时候，都是事后动作，但是从来没有一个企业可以在上生产之前通过非功能测试之后给出几个9的结论。
甚至于，上生产之前所做的非功能测试都不敢说覆盖了多少非功能特性。这是一个非常大、也非常难的话题。
在2021-2022两年内，我做过一个非功能体系咨询的项目。在这两年中，针对现在国内信创转型、数字化转型、架构转型的IT系统，我一直在考虑通过什么样的逻辑可以让一个IT系统的非功能能力得到较为全面的验证测试。
通过不断的摸索，在这个项目中，我写了一套完整的非功能能力验证体系，覆盖了最初的业务需求到上线运维，交付文档就达到几十万字，逻辑也在不断地实践项目中得到验证，直到现在也仍然在不断迭代完善之中。
当然这里不是为了推广我写的这套咨询体系。
而是说一个IT系统的非功能能力要想得到全面保障，是非常宏大的话题。一入非功能深似海。
在非功能能力上，如果想要全面验证，首先要确定一下基本的原则。
非功能能力要想得到全面的验证，任何大而空的没有落地能力的方法论都是没有价值的。而只有工具没有方法论，也是不可能做到面面俱到的。即便是有了方法论，也是要不断迭代更新的。
企业需要做一些非功能体系规范的事情。
有了原则和规划做为前提，还要对非功能的特性进行细分。
而一个IT系统会分出多少非功能的子特性出来，是要在具体的项目中分析的。这些特性的细分，是要覆盖业务功能、架构设计、系统设计、开发、运维各环节的非功能需求的。
非功能验证测试的环节就是要针对以上的细分特性进行全面的验证。
这样才能完成一套完整的非功能体系的落地过程。
有一句类似口号的话放到结尾：
非功能体系能力是企业技术能力的全面体现，是技术深度认识的完整概括。