這裡系統專門指的是那種使用者量大的系統，比如有幾百萬或者上千萬的註冊會員。因為小系統因為使用者量少，不存在這種思考，考慮有時候是多餘的。另外還有內部系統，給自己公司內部人員使用的，即便是出現了問題，也不會造成很大的問題，內部協調一下即可。
而針對客戶的系統，公司的收入和價值來源於給客戶提供穩定的服務。這是關係到公司命脈的。如果系統不穩定，在客戶心中造成的印象就會不好。
快速修復與穩定測試之間的權衡
如果線上系統出現了bug，使用者反饋問題。作為開發人員，肯定要修復bug。是馬修復程式碼後上傳到生產環境，還是在灰度或測試環境把修復的程式碼測一遍後，再上傳到生產環境呢？
有時候為了快速解決線上問題，所以修改程式碼後，就想釋出上去。大一點的網站，都要走釋出流程，填寫釋出單的。不能隨便ftp上傳程式碼的。都是業務系統，一點問題會存在影響。
看《淘寶技術這10年》裡面也出現過類似問題，改改，編譯(java語言要編譯)好後釋出上去，發現還是有問題，又得重新找，一天過去了。
我自己也有類似的體會：有時候發現bug，想快速修復bug，就懶得在灰度測試了。於是釋出到線上。但是會出現其他問題來。
有的時候還會犯低階錯誤。
比如我自己親身經歷過好幾次了。一次是郵箱的啟用狀態。發現有這個bug，去修復，想快速修復，在測試環境測驗了後，程式是沒問題，但是釋出到線上，就出現問題。
這次不是程式出現問題。是沒溝通好，不應該改為啟用狀態。這種辦法只是一個臨時辦法，沒有從整體角度考慮，即其他系統也會用到資料庫的狀態，根據這個狀態來攔截髮廣告行為。這樣改掉就造成資料錯誤了。
很多人都有類似的習慣，乾脆懶得測了，自己覺得有信心，就釋出到生產環境去(身邊一些開發人員改好程式碼，自己不測試，直接發到灰度去給測試人員測試，實際上還是要打回來。這樣來回折騰的耗費的精力和時間其實還更多)
表面以為快，實際上並沒有快。有時候，我們修改簡單的功能，釋出上去，沒有出現問題，於是就養成這樣的習慣了。幾次沒有出現問題，但是某次就會出現意外，造成了系統的不穩定，也讓開發人員到處救火的行為，比如這裡修復好後，出現新的問題，繼續修復，到處救火弄得精疲力竭的。
我如今越來越有如下感悟：追求快速可以，但如果追求快速，質量得不到保證，這種快速有多大意義呢？為了保證質量，寧願慢一點，放到測試環境和灰度環境把問題還原出來，測驗沒問題再發布。
靠人的經驗和能力來控制是否靠譜
開發人員出於自信和經驗考慮，覺得自己修改的東西不用經過測驗，反正就修改那麼一點點程式碼，我有信心保證不出錯。
我現在發現，靠人的經驗來保證質量，不太靠譜了。因為任何人再厲害，都有犯錯的時候，都會有疏忽。比如今天剛好因為家庭有事，情緒比較低落。修改程式碼就忽略掉一些部分了。眼睛看失誤了。或者今天睡眠不充足，或者今天心情不好。就會造成類似的事故出來。一個人的大腦負擔多的時候，就更加容易失誤了。
靠一個人的智力終究有限，怎麼防火才能從源頭上來解決問題。如果能夠設計一種辦法，哪怕是人會犯錯，但是可以糾錯，就會好很多。
很多時候之所以那麼趕，是因為覺得自己再去測驗浪費時間，還有上面也不給你時間來測驗？
這方面的投入時間相比後續出現問題再去救火到處的成本，是非常值得的。
古代人說，慢工出細活，的確非常有道理。程式設計就是一個慢共出細活的工種。心理越亂月容易出錯。
線上的bug怎麼處理？
分清楚優先順序，重要程度。如果影響的面不是很廣，只是一部分使用者。可以放在測試環境把這個問題還原出來。這樣確保找到了原因，再去修復問題。
避免越修越亂的局面！
沒有找到確切的原因，像蒼蠅一樣，各個去嘗試，這樣會造成更多的問題出來。以前只是影響一部分使用者，後來影響更多的使用者了。得到反饋回來，這個時候會驚動更多人(比如產品、老闆)，開發人員得到的心裡壓力會更大。這樣乾的也不愉快。產品對系統頻繁出問題也心裡不爽，反饋到老闆那裡，老闆也覺得是這樣，開發人員也因為受到壓力乾的不愉快。最後是一個雙輸的局面。
總結：不要因為線上出了問題，為了快速修復bug，而忽略掉了節奏。開發人員能夠做到面臨外界壓力，不亂其實是一種心裡素質。
如果亂，心智不穩定的狀態下，還會造成更多的問題出來，以前的修改程式碼就白勞動一場。有時候要慶幸現在自己冷靜，沒有去亂動，還沒有因為亂動而造成更多問題(到時候吃不了兜著走)。
以前我的思想是，既然是面對使用者的系統出現了bug，那麼就要快速修復，我或多或少是出於假設某天我的公司遇到類似問題我應該如何辦的思維模式來做事。
面對使用者的bug，會引起我的特別重視。但是後來我發現，完全這樣子也不行的。要權衡一下質量。如果沒有質量保證的修復，那就會造成其他問題的出現。其實有些使用者是可以緩一緩的，沒想象那麼緊急。比如線上程式就的確有這個bug：在app註冊後，跑到pc版本去登入，需要郵箱啟用。我仔細跟產品溝通會發現，沒有想象的那麼重要。週五本來想釋出修復bug，但是可以緩到週一去釋出的(這樣有足夠的時間來測驗修改程式碼後造成的影響)。我沒有抓住裡面的關鍵點，目前只有這一個使用者反饋這個問題。沒有出現大面積的使用者反饋。
因為通過手機app註冊的使用者，並不像我們想象那樣，會去pc端頁面進行登入。所以使用者沒有遇到這樣的問題。
由於一個瓶子放在桌面上，每個人觀察到的面是不同的。我們會忽略掉一些看不到的面。
我們內部開發人員觀察到的永遠是bug，因為產品反饋給我們了，我們看到的就是這個bug這一面。但是我們沒有從整體角度來考慮。我們只是關注這是一個影響使用者登入的bug。
我們以為改掉可以很有成就感，但可能是楊白勞，週五去釋出，如果無法確保自己的程式碼不會造成其他影響。就少幹。原地不動，反而風險更低。
頂著錯誤前進，錯誤次數多了後，就會是經驗。有人宣揚，人生沒有後退的路子。但我在想，如果一個人無法從錯誤的經歷中吸取教訓，避免下一次犯錯，那麼還是一樣的浪費折騰。比如修復bug的事情，如何權衡，這樣的錯誤繼續再犯，總是到處救火。還是沒有形成穩定的局面。