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