发生一档子事情，公司技术团队之中有两个部门，一个开发一个运维，开发负责公司项目软件项目实现，运维负责项目运行生产环境服务器与数据的管理与维护。 前两天生产环境发生一起故障，项目依赖的redis服务器由于内存不足而出现写入故障，有一批用户丢失了一小时的数据， 公司发出批评通告， 运维全责，运维部门涉事相关员工与领导统统被罚。

为什么运维被罚，因为服务器内存不足会报警，向负责服务器的运维人员发出警告短信，运维人员收到警告后需要即使处理。 而这次事故服务器发出的警告不凑巧的被运维忽略，于是事故发生， 究其原因是因为忽略警告，因此被罚。

这看起来似乎在情理之中，被罚是理所应当，这是运维马虎大意造成的恶果。可是不知道大家有没有觉得奇怪，为什么Redis无法写入会造成用户数据丢失，Redis只是一个缓存工具，理论上缓存数据丢失可以通过磁盘持久存储数据恢复。有的同学推测可能缓存中的数据没有同步至磁盘导致问题，事实上这次事故并非同步数据失败引起，甚至根本没有缓存数据同步至持久存储一说，因为项目的开发人员直接把Redis当成了持久存储的数据库，而没有使用MySql之类的真正持久存储数据库。是不是很奇怪，居然有人把内存数据库当真正的数据库使用，虽然Redis提供这个功能。这就是导致问题的根本原因，持久存储并非Redis擅长，强行使用不但败家，而且危险，用户数据增长内存也要跟着涨，一旦跟不上Redis崩溃，程序故障，线上业务直接受到影响。

现在看起来，这起事故的责任开发人员也应该承担部分，技术使用不当是导致问题的根源。可是我说了不算，公司的领导不吃这套， 毕竟触发这起事故的直接原因是运维忽略告警照成的，那这个责任没有理由推脱给别人。

通常在业务上犯错会被追究责任，比如说这次事故运维被罚，而技术上犯的错误却不会， 因为技术上的错误不容易被明确定义，比如说问开发人员们为什么要将Redis当成数据库，他们会有充足的理由，比如让程序跑的更快，使用Redis的确能让程序跑的更快，而且是必然。可使用Redis当数据库也存在一系列问题，比如不稳定，容易丢失数据等，这起事故便是证明，可这不是必然发生的，MySql也会丢失数据，关键是要看如何避免，这便是开发人员使用Redis的充足理由，同时也不会被认为是在范错误，他们是为了让程序获得更好的性能，这应该受到奖励而不是处罚，可实际上使用Redis当数据库就是在犯技术上的错误，就像你开个跑车去跟越野车去山路上跑比赛，你说你开跑车是为了跑赢，可却随时会有车毁人亡的危险， 因为跑车不适合开山路，Redis也同样不适合做数据库。

现在很多程序员对于技术的选择并不以解决问题为目的，有时候他们会为了使用技术而选择技术，就好比Redis，因为很多大公司都在使用，所以他们也非要在自己的项目中用一用，不然怎么跟的上技术的步伐。他们把Redis研究的很精通，甚至连底层的C语言实现都会去研究，这是好事，可在项目中盲目使用就不对了，恨不得把所有存储数据的地方都用Redis，至于适合不适合，他们不考虑。

然后随着项目的进展，使用Redis当数据库的问题渐渐暴露，他们意识到这方面Redis的确不如MySql，然后他们后悔了，可这个时候技术架构已经定型，要换成MySql需要花费极大的代价，如果项目已经上线则还要承担风险，这种伤筋动骨的修改容易产生严重的bug，要保证既不影响进度又不改出bug是一项异常艰难的任务，因次开发人员们没有勇气迈出这一步去优化。

甚至于对于那些全新启动但是沿用旧框架的项目他们也没有动力与勇气去改变，我常常听他们说这样一句话：旧的架构已经被证明是可用和稳定的，那么我们就没有理由去改，如果新项目采用新架构却没有办法应付业务， 出了问题谁负责。总而言之一句话，他们害怕改变害怕走出舒适区。

而那些级别高一点的领导却完全不关注技术对项目的影响， 即使项目部门的领导也不关注，在他们眼里业务是首当其冲，技术是细枝末节，他们对技术的要求是别拖项目的进度，生产环境别出严重的bug，如果出了那就以处罚的方式让事故责任人牢记在心避免再犯，这便是他们应对技术问题唯一的措施。然后还总爱大言炎炎的张嘴流程优化闭嘴责任态度，却从来不会深入技术部门去发现问题去督促改进，他们觉得这是技术主管负责的事情，这没错， 可要在技术主管靠谱的前提下，如果不靠谱那么就容易发生悲剧，比如说这次事故。 而现在通常很多公司技术部门主管的工作更偏向于是督促员工完成需求保证进度的包工头，至于技术选型和实现统统都要给进度让路，主动改进技术问题，不存在的。

我就是觉得公司对于这件事情处理不公平才说这么多，那些不懂技术的人只从问题的表明定义责任，而不是去从根本上解决问题，当然，他们的确不可能从根本上去解决问题， 因为他们根本没发现问题。