在阿里技术一线呆三年，你会遇到哪些故障

在技术面试的时候，我们通常会被问到“你遇到过哪些问题，是怎么解决的”。这个问题就很考验经验了，如果你在一个小作坊呆了很多年，你可能根本就不会遇到这些问题。所以面试官通常都会根据这个问题快速判断该不该pass掉一个求职者。只有遇到问题，解决问题，经历了这个过程，技术能力和解决问题的能力才会提升，人和技术才能融为一体，才知道什么技术是真正有用的，什么技术是华而不实的花拳绣腿。

这里列举一些大型网站的典型故障，我们会发现，在高并发和海量数据的情况下，一般情况下的不是问题的问题都会涌现出来。这可不是危言耸听，如果你在BAT等大厂呆过三年之后，你一定和我一样有此体会。

你见过写日志写出故障的吗？磁盘空间预警，服务器宕机。一个普通的应用服务器集群，配置硬盘大小100G，装上系统以及程序运行环境之后还剩余几十G。正常情况下这么大的磁盘空间绝对够用了，但是开发人员忘记将日志输出级别调整为ERROR了，这样普通的请求都会打印非常多日志，很快就将磁盘写满了。

一条慢SQL引发的血案和一条执行频率非常高的SQL引发的血案。通常数据库load居高不下，所有要访问数据库的应用全部加载缓慢甚至无返回。那你就要检查一下是不是有慢sql或者某条sql在疯狂执行。

高并发下对象锁引发的故障。某个单例对象中多处使用synchronized（this）。通常操作都是获得锁，完成操作，迅速释放。但是某个远程操作也调用了这个synchronized（this），每次这个应用执行时，所有其他操作都要排队等很久甚至响应超时。

数据库突然load飙升然后失去响应，只是因为缓存服务器疏于管理。通常缓存服务器挂了一部分大家都没什么感觉，平时也不怎么在意。但是如果部署的时候关闭了很多个缓存服务器忘记开启了，你猜数据库load会不会飙升，数据库会不会失去响应？

一行注释带跨一个队伍。某工程师在开发时候，为了测试方便，将一行读取缓存的代码注释掉了，从而直接读取数据库的数据。最后提交代码也忘记打开注释了，发布的时候数据库load飙升，导致一堆别的应用也都挂掉，真是一行注释带跨一个队伍。

俗话说“吃一堑长一智”，这些都是血与泪的经验教训啊。所以你在开发过程中遇到过哪些问题呢？

如有侵权，请联系删除

转载请注明来源