有故障，毋寧死
—談系統故障及軟件質量
如果你是一個7×24小時在線服務的整體（或模塊）的技術或系統負責人，你的大部分生活會如遊走鋼絲。
程序會出bug、資源會出故障、發佈會操作錯誤、測試會有疏漏、安全會出漏洞、網絡會有波動、服務器會突然壞掉。當產品的需求日益增多，判隨工程師團隊會日益增大，一個軟件項目或功能從開發到上線的完成，都不可能由一人或者幾個核心工程師去做，需要由不同背景、不同能力及做事風格的的開發、測試、工程師配合完成。當任一環節問題（包括有不少並非你直接可控範圍之內的問題）未及時發現並帶到線上之後，最終的責任會落在你的肩上。每當問題一出，你會感受到各方面的壓力，有技術的缺陷、工作的失職、流程及規範執行方面的欠缺的問題；同時也會來自組織內外對你能力及人品等方面的質疑的聲音。當發生問題後，你可能會獨處一隅，沉浸在未能把事情做好的懊悔中。
儘管平時付出了很多辛勤與努力，在業界普遍處於KPI焦慮的環境中，技術作爲底層支撐部門，出現的各種問題通常是顯而易見的，不足的問題通常會被放大。
因此，你經常面臨的艱難的選擇是，quality, or death.
傳統工作生產中，有標準化的流程及規範來提高質量、降低故障。比如六西格瑪（Six Sigma）可以降低產品瑕疵率。他們有成熟的規範與制度，有熟悉制度執行的專業人員，有提供諮詢服務且具有豐富經驗執行的諮詢公司，企業員工及業務負責人只需要按步就班，就可以把問題做得相對到位。但在互聯網在線服務這種不規範的軟件系統中，有沒有類似的標準化流程來指導生產呢？大部分團隊需要從頭到尾摸索一遍，在交足學費後才能得到一套並不完善的流程及制度？
發佈前流程
設計及架構，是否在開發的特性進行設計上的tradeoff？
風險及依賴，開發計劃中充分考慮風險及項目依賴因素？
代碼是否經過足夠的review？
上線計劃及風險因素是否考慮詳盡？比如是否需要灰度發佈？上線後檢查及測試措施是否到位？是否有回滾方案，回滾是否會產生髒數據?
當故障發生時
是否有充足渠道及時發現問題？以免小問題變成大問題？
收到問題後是否有合適方式（如日誌及工具）快速定位並確認問題？有時候一些用戶反饋的些問題並不好測試及重現。
處理問題
是否有現成的問題處理預案？
對於新功能是否有回滾處理方法，回滾後是否存在髒數據需要修復？
總結問題
問題的根源是什麼？在技術上、流程上、風險防範上各有什麼可以馬上執行的行動計劃？
非技術因素
在很多企業中，容易把軟件質量上發生的各種問題歸結到單一的技術因素。但是，如果沒有非技術體系的支持，一個團隊不可能做到完善的高質量。
研發流程及質量改進在你企業規劃中的權重是怎樣？年度規劃中除了業務目標、競爭環境、市場份額、產品策略之外，研發體系改進是否有一席之地？
在功能需求及產品設計階段，是否充分考慮了技術風險及人力資源因素？是否會突然啓動當前團隊並不能支撐的項目？
在開發階段，開發計劃是否符合軟件開發規律？開發計劃是根據項目壓力制定，還是從定好的交付日期來倒推開發時間表？
安全及優化，是否有專門的人力及團隊？開發工程師需要面臨日常的開發任務，突然被用戶發現之前開發的模塊存在安全問題，修復完之後發現又帶出了另外一個bug？
國內大部分產品面臨市場及競爭對手的壓力非常大，在相對惡劣的環境下，研發技術建設大多隻考慮短期收益。如果期望研發體系做到零故障或者可控的故障（比如six sigma中的99.99966%），需要長時間的體系建設與積累，包括整個企業的工作流程，同時也需要在技術基礎研發上投入更多的精力。