最近我们部门故障频发:
7.30号,生意经数据库因为不明原因,压力很大,导致生意经前台无法访问,中文站其他多个应用受到影响,包括offer
8月份,blog因为机器增加了一倍,原来一个错误oscache块的crontab设置不对,导致数据库压力大增,
9月初,asc发布了一个有问题的第二方类库。一小时后生意经问题出现,导致生意经客户无法访问。
上周生意经因为memcached的服务器硬盘线掉了,导致生意经无法访问。
8月份,WebWW的传输服务器的80端口没有开放,导致客户无法使用WebWW。
最近故障和问题很多,虽然很多都由于第三方原因或者偶然因素引起。但结果是我们创造了我们网站应用开发部在质量方面的历史最差纪录!
为什么?
你可以说,有些问题不是我们的问题,我们是受害者
你可以说,有些问题存在偶然因素,我们也没有办法
你可以说,有些是历史原因,我们只是踩到了地雷
你可以说,最近运气不好,该去拜拜了!
事情好象是偶然,但是偶然中有必然。
我们可以发现,出现故障是一个结果。但是导致这个故障的原因会很多,有自己的,有别人的,只要我们能够把其中任何一个原因注意处理好,就不会出现问题:
比如上周生意经因为memcached的服务器硬盘挂了导致产生故障。表现起来好象是硬盘线掉了,但是
假如:
1 Memcached不是单点
2 这条语句不是6秒,只是1秒
3 我们在设计的时候,这个慢速查询的结果是放在临时表里面的
4.。。。。。。
上面这些条,我们应用做到任何一条,那么我们都不会产生这个故障。
只要在你的产品上,产生所以任何问题,都是你的问题。因为最起码,都影响到你的客户了。
所以,请大家关注自己开发的每一行代码,部署的每一个应用,设计的每一个功能。
我的经验:作为一个开发,在面对代码的时候,应该是一个悲观主义者和完美主义者。
对于别人提供给你的接口要在开发的时候考虑到接口无法访问、接口超时、接口返回空、接口返回错误数据等等可能性的时候做好预防措施,保证这些问题出现了,你的应用不会挂。或者不会受到太大的影响。
你如果使用了数据库,因为数据库是我们的应用的命门,而且是永远的瓶颈,请尽量做到:
能不访问数据库就不访问数据库,
不做慢速查询,慢速查询全部用其他的可替代方面解决。
统计等等功能尽量在低峰时段做好,放在统计表里面
在部署应用时候,
不要让你的应用是单点,你永远不知道服务器的硬盘会不会坏,老鼠会不会咬,线会不会脱落
这些只是抛砖,我们还有还有很多很多的办法来让我们的系统更加安全,稳定。这些全在你手,在你敲出的每一个字符,做出的每一个决策!
我们后面也会有一系列的行动来让我们的系统更加可靠.但是更重要的是,大家要牢记质量是我们开发人员的生命,是所有0前面那个1。
所以,我们期待大家有更多,更好的的方法和行动来保障我们的系统质量和稳定性,提升客户满意度。