程式會出bug、資源會出故障、發布會操作錯誤、測試會有疏漏、安全會出漏洞、網路會有波動、伺服器會突然壞掉。當產品的需求日益增多，判隨工程師團隊會日益增大，乙個軟體專案或功能從開發到上線的完成，都不可能由一人或者幾個核心工程師去做，需要由不同背景、不同能力及做事風格的的開發、測試、工程師配合完成。當任一環節問題（包括有不少並非你直接可控範圍之內的問題）未及時發現並帶到線上之後，最終的責任會落在你的肩上。每當問題一出，你會感受到各方面的壓力，有技術的缺陷、工作的失職、流程及規範執行方面的欠缺的問題；同時也會來自組織內外對你能力及人品等方面的質疑的聲音。當發生問題後，你可能會獨處一隅，沉浸在未能把事情做好的懊悔中。
儘管平時付出了很多辛勤與努力，在業界普遍處於kpi焦慮的環境中，技術作為底層支撐部門，出現的各種問題通常是顯而易見的，不足的問題通常會被放大。
因此，你經常面臨的艱難的選擇是，quality, or death.
設計及架構，是否在開發的特性進行設計上的tradeoff？
風險及依賴，開發計畫中充分考慮風險及專案依賴因素？
**是否經過足夠的review？
上線計畫及風險因素是否考慮詳盡？比如是否需要灰度發布？上線後檢查及測試措施是否到位？是否有回滾方案，回滾是否會產生髒資料?
是否有充足渠道及時發現問題？以免小問題變成大問題？
收到問題後是否有合適方式（如日誌及工具）快速定位並確認問題？有時候一些使用者反饋的些問題並不好測試及重現。
是否有現成的問題處理預案？
對於新功能是否有回滾處理方法，回滾後是否存在髒資料需要修復？
問題的根源是什麼？在技術上、流程上、風險防範上各有什麼可以馬上執行的行動計畫？
在很多企業中，容易把軟體質量上發生的各種問題歸結到單一的技術因素。但是，如果沒有非技術體系的支援，乙個團隊不可能做到完善的高質量。
研發流程及質量改進在你企業規劃中的權重是怎樣？年度規劃中除了業務目標、競爭環境、市場份額、產品策略之外，研發體系改進是否有一席之地？
在功能需求及產品設計階段，是否充分考慮了技術風險及人力資源因素？是否會突然啟動當前團隊並不能支撐的專案？
在開發階段，開發計畫是否符合軟體開發規律？開發計畫是根據專案壓力制定，還是從定好的交付日期來倒推開發時間表？
安全及優化，是否有專門的人力及團隊？開發工程師需要面臨日常的開發任務，突然被使用者發現之前開發的模組存在安全問題，修復完之後發現又帶出了另外乙個bug？
國內大部分產品面臨市場及競爭對手的壓力非常大，在相對惡劣的環境下，研發技術建設大多只考慮短期收益。如果期望研發體系做到零故障或者可控的故障（比如six sigma中的99.99966%），需要長時間的體系建設與積累，包括整個企業的工作流程，同時也需要在技術基礎研發上投入更多的精力。
系統故障排除
常見的系統故障排除 1.確定問題的故障特徵 2.重現故障 3.使用工具進一步收集資訊 4.排除不可能的原因 5.定位故障 從簡單的問題入手 一次嘗試一種方式 1.備份原始檔 2.盡可能借助工具 可能出現的故障 1.管理員密碼忘記 2.系統無法正常啟動 a grub損壞 mrb損壞 grub配置檔案丟...
系統故障排查
一 1.建立用於儲存mbr備份的新硬碟分割槽,並永久掛載 1 新建乙個目錄 mkdir backmbr 2 掛載 mount dev sdd1 backmbr 永久掛載 vim etc fstab 3 備份mbr扇區資料 dd if dev sda of backmbr mbr.bak bs 512...
系統故障及其恢復
1.系統啟動流程 通電 bios 主機板上的唯讀儲存 作用，硬體檢測，啟用硬體 grub系統引導 grub引導分為兩個階段 1 階段1 mbr 主引導記錄 主引導記錄在硬碟的磁軌上，一扇區，446個位元組 2 階段2 grub檔案引導階段 由檔案 boot grub2 grub.cfg控制流程，指定...