系统重大故障为什么总是难以预测

白鳝的洞穴 2024-01-22

910

防患于未然，让系统0重大故障是运维部门的目标，这些年的运维工作中，我有个感受，就是系统重大故障很难预料。不管你的系统运维管理如何规范，技术手段如何高超，故障总是免不了的，而且重大故障出现时，所有的预警手段往往都没有发挥作用。我以前总以为这是因为传统用户的管理存在缺陷、技术水平不足、投资不足导致了重大故障无法避免，这些年看到互联网企业也经常发生史诗级的P0故障，似乎以前的认知也不见得对。

以前传统行业减少系统重大故障的逻辑比较简单，那就是用最不容易出故障的IT基础设施来搭建信息系统，IOE是那个时代被证明有效的典型架构，依托中高端小型机、高端存储和Oracle强大的可靠性，很容易构建出可用率极高的系统。当然单点故障还是无法避免，不过还是可以通过多花点钱来解决问题的。而现在解决这个问题的逻辑相对来说要绕一点，就是用云平台这样的无单点故障的云化基础设施来替代当年的IOE。

以前的高端小型机和高端集中式存储系统的高可用是通过严格的工业设计和堆料来实现的，标称的可用性大体上是能够保证的。而现在的云基础设施在理论上是可以比传统架构的可用率更高的，不过不是工程化的系统，而是集成系统。因此设计上的理论可用率往往会被很多因素影响而无法真正达到。这种用复杂的系统整体可用性来解决以前使用工程化的手段解决的问题的环境下，系统中存在P0故障隐患的可能性还是存在的。按照IOE时代的做法，对可用性要求极高的系统是要通过多云安全来保证云出问题的时候系统高可用的，不过多云保障的成本远高于IOE时代的备机系统，因此在云时代，这方面的高可用往往被企业忽略了。

基于上述原因，目前系统出现大型故障的可能性相比较IOE时代而言不一定是更低了，而在某些用户那里很可能是更高了。很多重大故障的诱因十分简单，可能是网络设备的老化，也可能是无心之失的一个配置调整，或者是云平台的一个BUG，还可能是云中的某几台倒霉的服务器的质量不好。

在故障没有发生之前某些隐患往往被忽略或者被系统的整体性掩盖。很多重大故障的隐患实际上已经被日常运维工作解决掉了，但是我们并没有感觉到。不过事情不会总是这么顺利，总有一些隐患会被很深地隐藏起来，让运维人员难以发现，同时不合理的考核KPI让原本应该在闭环管理中被发现的问题没有足够的资源去分析。因此不管如何，重大故障总是无法避免，也无法提前预警，只有当故障真正发生的时候才会让人感知到。

重大故障之所以被称之为重大故障，并不是引发故障的根因十分重大，而是故障发生后解决故障十分棘手。重大故障发生时，快速找到解决方案是最为关键的。而随着IT基础设施变得更为复杂，根因分析也变得困难重重。在云基础设施的加持下，事先预知根因的场景大多数不需要人费劲巴拉地去做根因分析，甚至绝大多数这种场景都已经被云平台本身实现自动化处理了。能够自动化解决的问题一般不会引发重大故障，除非自动化处置本身有问题。因此令人十分无奈的是重大故障发生时，往往都是自动化故障发现也无法发挥作用的时候。

遇到这样事情的时候，人往往是解决此类问题的关键，因此哪怕是头部互联网企业有着投入巨资建设的十分完善的自动化运维系统，也还必须养着一批高人来负责故障应急。实际上在这种时候采用的是一套与云平台管理完全不同逻辑的系统来分析与解决问题，因为云平台的系统中的故障处置逻辑已经失效。这套系统可以是高度自动化的，也可以是主要依赖于专家的，各村有各村的高招，这方面我也知之甚少。不过有一点是肯定的，这一定也是钱堆出来的系统。

随着传统企业IT系统上云的加速，传统企业面临此问题的风险也在加大。如果选择公有云，那么企业不大需要关注这些问题，祈祷自己的云服务商不要出史诗级的故障就好了。如果是自建的私有云，那么请不要总是希望自己的云平台中故障可以完全预知，可以自动消缺。对自己的关键业务系统，还是参考传统的系统高可用模型，多花点钱多堆点料吧。因为复杂环境的快速根因定位不一定是你能玩得转的。发生重大故障的时候，切换到备用系统永远是最简单，最快速，也是最有保障的。

高可用

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

系统重大故障为什么总是难以预测

评论