做了这么久程序员,程序可用率你真的了解么

在我们日常的生活中,可用性是衡量一个东西好坏的标准。举个例子,一辆车,动力很足,内饰奢华,空间够大,安全性好,但是每半个小时就会熄火一次,这是个好车么?同样的道理,你设计一个APP,操作流畅,但是每半个小时就会Crash一次,显然也不是什么好APP。对于程序员来说,特别是对于后端开发来说,系统的可用性非常地重要,那么怎么衡量一个系统的可用性呢?
我们有两个重要的标准,一个是故障间隔时间,顾名思义,就是两次故障之间,相隔了多长的时间,很明显,故障间隔时间越长,说明系统越稳定。另一个是故障恢复时间,人非圣贤,孰能无过。故障总是会发生的,那么从故障开始,到发现问题,解决问题的时间,我们称之为故障解决时间,很明显,故障解决时间越短,说明解决问题的速度越快,系统越稳定。
我们把故障间隔时间/(故障间隔时间+故障恢复时间)称之为系统的可用率,很显然,这是个小于等于100%的数。我们把系统可用率99%以上的称之为2个9,把系统可用率99.9%以上的称之为3个9,很显然,越接近1,说明可用性越高。但是每当我们把可用性提高1个9,有多难么?

做了这么久程序员,程序可用率你真的了解么

当系统的可用性为2个9的时候,我们的系统有3.65天是故障不可用的,这个看起来难度并不是很大,但是当我们把标准提高到4个9的时候,我们一年只有52分钟的时间允许故障,这是非常困难的,因为从故障的发生,到收到反馈,到定位,再修复,往往需要不少的时间。对于一个大公司来说,特别是一个有着千万甚至上亿月活的项目来说,故障的时间越长,影响的用户越多,那么就会造成越大的损失。
那么,为了提高系统的可用性,我们有哪些简单又行之有效的方法呢?
首先是规范好流程,代码的开发到发布上线,需要进行技术评审、代码审查、测试验证,不能够那么的随意,把线上环境当成测试环境使用。

做了这么久程序员,程序可用率你真的了解么

其次是做好监控,自己发现用户而不是等用户发现问题,很多程序员,对处理异常、错误码非常地不屑,这是个非常不好的习惯,一般来说,好的代码,几乎60%都是用来处理异常跟边界情况地,如果不去做好这些,就很难从监控中去发现异常。
然后是,自动化的运维,人总是会犯错误的,并且还常犯,相信每个运维都重启错应用,或者部署错机器。而且人不可能24小时都盯着机器看,所以,我们需要自动化的运维,在某些机器故障的时候,快速进行响应。
最后则是定时的演练,在阿里巴巴,每年双十一前的3个月,都是进行压测跟演练,从而形成一套说明书,某某系统压力过高,降级停用了,其他系统该如何表现,让技术人员又心理准备,才能在故障真正发生地时候临危不乱。

做了这么久程序员,程序可用率你真的了解么

好了,今天我们学习了高可用的系统标准还有一些方法论。关注我,让我们一起学习,共同进步!(同名公众号:沙茶敏碎碎念)

标签:   |    |    |