發生一檔子事情，公司技術團隊之中有兩個部門，一個開發一個運維，開發負責公司項目軟件項目實現，運維負責項目運行生產環境服務器與數據的管理與維護。 前兩天生產環境發生一起故障，項目依賴的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，如果出了那就以處罰的方式讓事故責任人牢記在心避免再犯，這便是他們應對技術問題唯一的措施。然後還總愛大言炎炎的張嘴流程優化閉嘴責任態度，卻從來不會深入技術部門去發現問題去督促改進，他們覺得這是技術主管負責的事情，這沒錯， 可要在技術主管靠譜的前提下，如果不靠譜那麼就容易發生悲劇，比如說這次事故。 而現在通常很多公司技術部門主管的工作更偏向於是督促員工完成需求保證進度的包工頭，至於技術選型和實現統統都要給進度讓路，主動改進技術問題，不存在的。
我就是覺得公司對於這件事情處理不公平才說這麼多，那些不懂技術的人只從問題的表明定義責任，而不是去從根本上解決問題，當然，他們的確不可能從根本上去解決問題， 因爲他們根本沒發現問題。