發(fā)生一檔子事情，公司技術(shù)團(tuán)隊(duì)之中有兩個(gè)部門，一個(gè)開發(fā)一個(gè)運(yùn)維，開發(fā)負(fù)責(zé)公司項(xiàng)目軟件項(xiàng)目實(shí)現(xiàn)，運(yùn)維負(fù)責(zé)項(xiàng)目運(yùn)行生產(chǎn)環(huán)境服務(wù)器與數(shù)據(jù)的管理與維護(hù)。 前兩天生產(chǎn)環(huán)境發(fā)生一起故障，項(xiàng)目依賴的redis服務(wù)器由于內(nèi)存不足而出現(xiàn)寫入故障，有一批用戶丟失了一小時(shí)的數(shù)據(jù)， 公司發(fā)出批評(píng)通告， 運(yùn)維全責(zé)，運(yùn)維部門涉事相關(guān)員工與領(lǐng)導(dǎo)統(tǒng)統(tǒng)被罰。

為什么運(yùn)維被罰，因?yàn)榉?wù)器內(nèi)存不足會(huì)報(bào)警，向負(fù)責(zé)服務(wù)器的運(yùn)維人員發(fā)出警告短信，運(yùn)維人員收到警告后需要即使處理。 而這次事故服務(wù)器發(fā)出的警告不湊巧的被運(yùn)維忽略，于是事故發(fā)生， 究其原因是因?yàn)楹雎跃?，因此被罰。

這看起來(lái)似乎在情理之中，被罰是理所應(yīng)當(dāng)，這是運(yùn)維馬虎大意造成的惡果。可是不知道大家有沒有覺得奇怪，為什么Redis無(wú)法寫入會(huì)造成用戶數(shù)據(jù)丟失，Redis只是一個(gè)緩存工具，理論上緩存數(shù)據(jù)丟失可以通過(guò)磁盤持久存儲(chǔ)數(shù)據(jù)恢復(fù)。有的同學(xué)推測(cè)可能緩存中的數(shù)據(jù)沒有同步至磁盤導(dǎo)致問(wèn)題，事實(shí)上這次事故并非同步數(shù)據(jù)失敗引起，甚至根本沒有緩存數(shù)據(jù)同步至持久存儲(chǔ)一說(shuō)，因?yàn)轫?xiàng)目的開發(fā)人員直接把Redis當(dāng)成了持久存儲(chǔ)的數(shù)據(jù)庫(kù)，而沒有使用MySql之類的真正持久存儲(chǔ)數(shù)據(jù)庫(kù)。是不是很奇怪，居然有人把內(nèi)存數(shù)據(jù)庫(kù)當(dāng)真正的數(shù)據(jù)庫(kù)使用，雖然Redis提供這個(gè)功能。這就是導(dǎo)致問(wèn)題的根本原因，持久存儲(chǔ)并非Redis擅長(zhǎng)，強(qiáng)行使用不但敗家，而且危險(xiǎn)，用戶數(shù)據(jù)增長(zhǎng)內(nèi)存也要跟著漲，一旦跟不上Redis崩潰，程序故障，線上業(yè)務(wù)直接受到影響。

現(xiàn)在看起來(lái)，這起事故的責(zé)任開發(fā)人員也應(yīng)該承擔(dān)部分，技術(shù)使用不當(dāng)是導(dǎo)致問(wèn)題的根源。可是我說(shuō)了不算，公司的領(lǐng)導(dǎo)不吃這套， 畢竟觸發(fā)這起事故的直接原因是運(yùn)維忽略告警照成的，那這個(gè)責(zé)任沒有理由推脫給別人。

通常在業(yè)務(wù)上犯錯(cuò)會(huì)被追究責(zé)任，比如說(shuō)這次事故運(yùn)維被罰，而技術(shù)上犯的錯(cuò)誤卻不會(huì)， 因?yàn)榧夹g(shù)上的錯(cuò)誤不容易被明確定義，比如說(shuō)問(wèn)開發(fā)人員們?yōu)槭裁匆獙edis當(dāng)成數(shù)據(jù)庫(kù)，他們會(huì)有充足的理由，比如讓程序跑的更快，使用Redis的確能讓程序跑的更快，而且是必然。可使用Redis當(dāng)數(shù)據(jù)庫(kù)也存在一系列問(wèn)題，比如不穩(wěn)定，容易丟失數(shù)據(jù)等，這起事故便是證明，可這不是必然發(fā)生的，MySql也會(huì)丟失數(shù)據(jù)，關(guān)鍵是要看如何避免，這便是開發(fā)人員使用Redis的充足理由，同時(shí)也不會(huì)被認(rèn)為是在范錯(cuò)誤，他們是為了讓程序獲得更好的性能，這應(yīng)該受到獎(jiǎng)勵(lì)而不是處罰，可實(shí)際上使用Redis當(dāng)數(shù)據(jù)庫(kù)就是在犯技術(shù)上的錯(cuò)誤，就像你開個(gè)跑車去跟越野車去山路上跑比賽，你說(shuō)你開跑車是為了跑贏，可卻隨時(shí)會(huì)有車毀人亡的危險(xiǎn)， 因?yàn)榕苘嚥贿m合開山路，Redis也同樣不適合做數(shù)據(jù)庫(kù)。

現(xiàn)在很多程序員對(duì)于技術(shù)的選擇并不以解決問(wèn)題為目的，有時(shí)候他們會(huì)為了使用技術(shù)而選擇技術(shù)，就好比Redis，因?yàn)楹芏啻蠊径荚谑褂茫运麄円卜且谧约旱捻?xiàng)目中用一用，不然怎么跟的上技術(shù)的步伐。他們把Redis研究的很精通，甚至連底層的C語(yǔ)言實(shí)現(xiàn)都會(huì)去研究，這是好事，可在項(xiàng)目中盲目使用就不對(duì)了，恨不得把所有存儲(chǔ)數(shù)據(jù)的地方都用Redis，至于適合不適合，他們不考慮。

然后隨著項(xiàng)目的進(jìn)展，使用Redis當(dāng)數(shù)據(jù)庫(kù)的問(wèn)題漸漸暴露，他們意識(shí)到這方面Redis的確不如MySql，然后他們后悔了，可這個(gè)時(shí)候技術(shù)架構(gòu)已經(jīng)定型，要換成MySql需要花費(fèi)極大的代價(jià)，如果項(xiàng)目已經(jīng)上線則還要承擔(dān)風(fēng)險(xiǎn)，這種傷筋動(dòng)骨的修改容易產(chǎn)生嚴(yán)重的bug，要保證既不影響進(jìn)度又不改出bug是一項(xiàng)異常艱難的任務(wù)，因次開發(fā)人員們沒有勇氣邁出這一步去優(yōu)化。

甚至于對(duì)于那些全新啟動(dòng)但是沿用舊框架的項(xiàng)目他們也沒有動(dòng)力與勇氣去改變，我常常聽他們說(shuō)這樣一句話：舊的架構(gòu)已經(jīng)被證明是可用和穩(wěn)定的，那么我們就沒有理由去改，如果新項(xiàng)目采用新架構(gòu)卻沒有辦法應(yīng)付業(yè)務(wù)， 出了問(wèn)題誰(shuí)負(fù)責(zé)?？偠灾痪湓?，他們害怕改變害怕走出舒適區(qū)。

而那些級(jí)別高一點(diǎn)的領(lǐng)導(dǎo)卻完全不關(guān)注技術(shù)對(duì)項(xiàng)目的影響， 即使項(xiàng)目部門的領(lǐng)導(dǎo)也不關(guān)注，在他們眼里業(yè)務(wù)是首當(dāng)其沖，技術(shù)是細(xì)枝末節(jié)，他們對(duì)技術(shù)的要求是別拖項(xiàng)目的進(jìn)度，生產(chǎn)環(huán)境別出嚴(yán)重的bug，如果出了那就以處罰的方式讓事故責(zé)任人牢記在心避免再犯，這便是他們應(yīng)對(duì)技術(shù)問(wèn)題唯一的措施。然后還總愛大言炎炎的張嘴流程優(yōu)化閉嘴責(zé)任態(tài)度，卻從來(lái)不會(huì)深入技術(shù)部門去發(fā)現(xiàn)問(wèn)題去督促改進(jìn)，他們覺得這是技術(shù)主管負(fù)責(zé)的事情，這沒錯(cuò)， 可要在技術(shù)主管靠譜的前提下，如果不靠譜那么就容易發(fā)生悲劇，比如說(shuō)這次事故。 而現(xiàn)在通常很多公司技術(shù)部門主管的工作更偏向于是督促員工完成需求保證進(jìn)度的包工頭，至于技術(shù)選型和實(shí)現(xiàn)統(tǒng)統(tǒng)都要給進(jìn)度讓路，主動(dòng)改進(jìn)技術(shù)問(wèn)題，不存在的。

我就是覺得公司對(duì)于這件事情處理不公平才說(shuō)這么多，那些不懂技術(shù)的人只從問(wèn)題的表明定義責(zé)任，而不是去從根本上解決問(wèn)題，當(dāng)然，他們的確不可能從根本上去解決問(wèn)題， 因?yàn)樗麄兏緵]發(fā)現(xiàn)問(wèn)題。