生产环境出现事故，开发和运维都有责任，到底该谁背锅

发生一档子事情，公司技术团队之中有两个部门，一个开发一个运维，开发负责公司项目软件项目实现，运维负责项目运行生产环境服务器与数据的管理与维护。 前两天生产环境发生一块儿故障，项目依赖的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，若是出了那就以处罚的方式让事故责任人牢记在心避免再犯，这即是他们应对技术问题惟一的措施。而后还总爱大言炎炎的张嘴流程优化闭嘴责任态度，却历来不会深刻技术部门去发现问题去督促改进，他们以为这是技术主管负责的事情，这没错， 可要在技术主管靠谱的前提下，若是不靠谱那么就容易发生悲剧，好比说此次事故。 而如今一般不少公司技术部门主管的工做更偏向因而督促员工完成需求保证进度的包工头，至于技术选型和实现通通都要给进度让路，主动改进技术问题，不存在的。

 

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