可用性都是相对的，总有投资没有覆盖的领域会出问题

白鳝的洞穴 2023-06-07

205

今天儿子高考的第一天，早上心就不定，想问题也就比较发散，写完这篇文章后，我自己看了一遍，觉得有点散，不过想要表达的意思是写出来了。

前几天一个客户出了一次事故，开发人员把生产库当成测试库，连上去后直接把应用系统的几个核心业务表给清了，后来花了大半天时间才完全恢复。实际上很多年前这个用户也发生过类似的故障，当时我给他们建议了一系列管控方法，以防类似的现象再发生。其中一条是确保生产环境的数据库、操作系统密码都与测试、开发环境不同，并且平时不对开发人员开放。这条规则执行了几年，后来上了堡垒机，就变得毫无用处了，因为连接到数据库都是通过堡垒机的密码和权限，根本不和系统的实际密码打交道了。前两年我建议他们通过数据库访问代理来进行危险操作防范，后来因为觉得这玩意价格有点高，当年没有经费实施，也就不了了之了。前几天他们发生故障后，IT主管十分感慨地和我说：“老白，当年上了这套系统就不会出这次的事故了”。

实际上关键系统因为可用性、人工误操作等导致停服也是十分常见的事情。昨天看到唯品会3月份事故的处理结果。唯品会的南沙IDC机房因为冷冻系统故障机房升温过快导致服务器故障，引发12小时业务受影响，造成了上亿的损失，被定为P0级故障。实际上那次天翼云IDC的故障，受到影响的不止唯品会一家，当天腾讯QQ等同在这个机房的互联网企业以及一些政务云的业务也受到了很大的影响。

在电信的IDC机房出现冷冻系统故障这是一个极小概率的事情，而唯品会、腾讯等企业将关键业务系统放置在电信机房里，也是从运营成本去考虑的。原本IDC管理这种电信十分拿手的事情居然会捅出这么大的娄子，是谁都意料不到的事情。我们的信息系统建设的时候也总是会面对几个9的选择问题，6个9几乎是无法实现的目标，因为可能意味着超出企业承受能力的IT成本。但是哪怕7个9，也总还不是100%，发生事故还是不可避免。

昨天一个群里朋友们在讨论这个问题，有朋友就认为互联网企业搞了这么多年的多可用区建设，还出这种问题，真的不应该。我倒是有不同的看法，我觉得所有的可用性都是相对的，因为哪怕7个9也不是绝对的安全，很多我们现在看来花点钱就能弥补的问题，在出事之前并不是没有人看得见，而是投资与回报之间的博弈问题而已。对于任何一个IT系统，总有投资没有覆盖的领域会出问题，我们能做的只是把这个概率尽可能降低而已，并不能完全杜绝事故。

可能喜欢深究问题的朋友会觉得我这个观点过于消极，难道因为这个原因，就不去尽可能完善自己的IT和预案了吗？答案肯定是否定的，不断提升核心业务系统的可用性肯定是it部门的重要职责，只不过这一切都是以投资与成本作为保障的。不论是领导还是基层IT从业人员，总会被企业信息系统建设的琐事所缠绕，让他们无法对这个每天都面对的熟悉系统像CT一样不停的扫描。定期请高水平的第三方的专家来做审计也是一件很花钱的事情，而且效果能好到哪里去也并不一定。事后评估往往是效果最好的，不过此时大错已铸。

现在信息系统已经成为了支撑国计民生的关键系统了，如果哪天各种网络支付手段突然全部失效了，我想这个社会就会乱套了。对于一个企业来说也是如此，十多年前顺丰出现服务器宕机导致的快递核心系统阿修罗出现2小时业务中断的时候，损失了两千多万。当时王卫并没有直接批评IT部门，而是把矛头指向了业务部门。他认为IT系统出故障是必然会发生的事情，因为数据中心是按照4个9建设的，不是100%靠谱。那么业务部门就应该有在IT系统不存在的情况下，几个小时内脱机工作的能力，否则这种业务模式设计就是不合理的。

不过现在很多企业的业务恐怕已经无法离开IT系统了，甚至现在顺丰也做不到脱机处理了。实际上那次故障两三年后，顺丰又遇到了一次更大的机房故障，而这次故障中，王卫提到的脱机处理流程发挥了巨大的作用。如果企业的核心业务已经不能脱机处理了，而且也不能出现长时间的业务暂停，那么多活系统建设就是必须要做的事情了。实际上这背后的并不完全是技术，技术目前是没有障碍的，最为关键的就是成本。

成本是最不容易完全满足的，而技术不是。这也是我们经常会说：“当年这地方不省这点钱就好了”的主要原因。

可用性

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

可用性都是相对的，总有投资没有覆盖的领域会出问题

评论