關於線上的bug何時修復的思考

 

 

這裏系統專門指的是那種用戶量大的系統，好比有幾百萬或者上千萬的註冊會員。由於小系統由於用戶量少，不存在這種思考，考慮有時候是多餘的。另外還有內部系統，給本身公司內部人員使用的，即使是出現了問題，也不會形成很大的問題，內部協調一下便可。

 

而針對客戶的系統，公司的收入和價值來源於給客戶提供穩定的服務。這是關係到公司命脈的。若是系統不穩定，在客戶心中形成的印象就會很差。

 

 

 

快速修復與穩定測試之間的權衡

 

若是線上系統出現了bug，用戶反饋問題。做爲開發人員，確定要修復bug。是馬修復代碼後上傳到生產環境，仍是在灰度或測試環境把修復的代碼測一遍後，再上傳到生產環境呢？

 

有時候爲了快速解決線上問題，因此修改代碼後，就想發佈上去。大一點的網站，都要走發佈流程，填寫發佈單的。不能隨便ftp上傳代碼的。都是業務系統，一點問題會存在影響。

 

看《淘寶技術這10年》裏面也出現過相似問題，改改，編譯(java語言要編譯)好後發佈上去，發現仍是有問題，又得從新找，一天過去了。

 

我本身也有相似的體會：有時候發現bug，想快速修復bug，就懶得在灰度測試了。因而發佈到線上。可是會出現其餘問題來。

有的時候還會犯低級錯誤。

 

好比我本身親身經歷過好幾回了。一次是郵箱的激活狀態。發現有這個bug，去修復，想快速修復，在測試環境測驗了後，程序是沒問題，可是發佈到線上，就出現問題。

此次不是程序出現問題。是沒溝通好，不該該改成激活狀態。這種辦法只是一個臨時辦法，沒有從總體角度考慮，即其餘系統也會用到數據庫的狀態，根據這個狀態來攔截髮廣告行爲。這樣改掉就形成數據錯誤了。

 

不少人都有相似的習慣，乾脆懶得測了，本身以爲有信心，就發佈到生產環境去(身邊一些開發人員改好代碼，本身不測試，直接發到灰度去給測試人員測試，實際上仍是要打回來。這樣來回折騰的耗費的精力和時間其實還更多)

 

表面覺得快，實際上並無快。有時候，咱們修改簡單的功能，發佈上去，沒有出現問題，因而就養成這樣的習慣了。幾回沒有出現問題，可是某次就會出現意外，形成了系統的不穩定，也讓開發人員處處救火的行爲，好比這裏修復好後，出現新的問題，繼續修復，處處救火弄得精疲力竭的。

 

我現在愈來愈有以下感悟：追求快速能夠，但若是追求快速，質量得不到保證，這種快速有多大意義呢？爲了保證質量，寧願慢一點，放到測試環境和灰度環境把問題還原出來，測驗沒問題再發布。

 

 

靠人的經驗和能力來控制是否靠譜

 

開發人員出於自信和經驗考慮，以爲本身修改的東西不用通過測驗，反正就修改那麼一點點代碼，我有信心保證不出錯。

 

我如今發現，靠人的經驗來保證質量，不太靠譜了。由於任何人再厲害，都有犯錯的時候，都會有疏忽。好比今天恰好由於家庭有事，情緒比較低落。修改代碼就忽略掉一些部分了。眼睛看失誤了。或者今天睡眠不充足，或者今天心情很差。就會形成相似的事故出來。一我的的大腦負擔多的時候，就更加容易失誤了。

 

靠一我的的智力終究有限，怎麼防火才能從源頭上來解決問題。若是可以設計一種辦法，哪怕是人會犯錯，可是能夠糾錯，就會好不少。

 

 

不少時候之因此那麼趕，是由於以爲本身再去測驗浪費時間，還有上面也不給你時間來測驗？

 

這方面的投入時間相比後續出現問題再去救火處處的成本，是很是值得的。

 

古代人說，慢工出細活，的確很是有道理。編程就是一個慢共出細活的工種。心理越亂月容易出錯。

 

 

線上的bug怎麼處理？

 

分清楚優先級，重要程度。若是影響的面不是很廣，只是一部分用戶。能夠放在測試環境把這個問題還原出來。這樣確保找到了緣由，再去修復問題。

 

避免越修越亂的局面！

沒有找到確切的緣由，像蒼蠅同樣，各個去嘗試，這樣會形成更多的問題出來。之前只是影響一部分用戶，後來影響更多的用戶了。獲得反饋回來，這個時候會驚動更多人(好比產品、老闆)，開發人員獲得的內心壓力會更大。這樣乾的也不愉快。產品對系統頻繁出問題也內心不爽，反饋到老闆那裏，老闆也以爲是這樣，開發人員也由於受到壓力乾的不愉快。最後是一個雙輸的局面。

 

總結：不要由於線上出了問題，爲了快速修復bug，而忽略掉了節奏。開發人員可以作到面臨外界壓力，不亂實際上是一種內心素質。

若是亂，心智不穩定的狀態下，還會形成更多的問題出來，之前的修改代碼就白勞動一場。有時候要慶幸如今本身冷靜，沒有去亂動，尚未由於亂動而形成更多問題(到時候吃不了兜着走)。

 

之前個人思想是，既然是面對用戶的系統出現了bug，那麼就要快速修復，我或多或少是出於假設某天個人公司遇到相似問題我應該如何辦的思惟模式來作事。

面對用戶的bug，會引發個人特別重視。可是後來我發現，徹底這樣子也不行的。要權衡一下質量。若是沒有質量保證的修復，那就會形成其餘問題的出現。其實有些用戶是能夠緩一緩的，沒想象那麼緊急。好比線上程序就的確有這個bug：在app註冊後，跑到pc版本去登陸，須要郵箱激活。我仔細跟產品溝通會發現，沒有想象的那麼重要。週五原本想發佈修復bug，可是能夠緩到週一去發佈的(這樣有足夠的時間來測驗修改代碼後形成的影響)。我沒有抓住裏面的關鍵點，目前只有這一個用戶反饋這個問題。沒有出現大面積的用戶反饋。

由於經過手機app註冊的用戶，並不像咱們想象那樣，會去pc端頁面進行登陸。因此用戶沒有遇到這樣的問題。

 

因爲一個瓶子放在桌面上，每一個人觀察到的面是不一樣的。咱們會忽略掉一些看不到的面。

 

咱們內部開發人員觀察到的永遠是bug，由於產品反饋給咱們了，咱們看到的就是這個bug這一面。可是咱們沒有從總體角度來考慮。咱們只是關注這是一個影響用戶登陸的bug。

 

咱們覺得改掉能夠頗有成就感，但多是楊白勞，週五去發佈，若是沒法確保本身的代碼不會形成其餘影響。就少幹。原地不動，反而風險更低。

 

頂着錯誤前進，錯誤次數多了後，就會是經驗。有人宣揚，人生沒有後退的路子。但我在想，若是一我的沒法從錯誤的經歷中吸收教訓，避免下一次犯錯，那麼仍是同樣的浪費折騰。好比修復bug的事情，如何權衡，這樣的錯誤繼續再犯，老是處處救火。仍是沒有造成穩定的局面。