一般剛畢業不久的會回答：我們有監控；看日誌等之類的答案。
工作幾年的人會回答：從網路，機器，資源等方面排查有沒有問題，如果沒有問題，再看看日誌，找開發核對。
也有人回答這個是開發的問題，我們運維還沒有精確到業務層面。
運維人員進行故障定位時，遇到主要問題：
1）業務掌握深入程度有限。不像某個應用的開發那樣，能很清楚乙個小問題的處理邏輯。
3）造成故障的原因很多。除了**bug可能導致問題外，idc，機器，流量波動等外在條件都會有影響。
4）不同運維人員對於業務理解或運維能力不同。不同的業務運維人員由於經驗等不同，遇到故障時的心態、決策等區別很大。
這時候，就要快速、準確定位出故障原因，至少要知道造成這次故障的乙個範圍是什麼，以便採取相應措施。
網路方面
網路無疑是造成服務故障的第一殺手。
使用者->cdn->源站idc->業務接入層->後端服務
使用者->源站idc->業務接入層->後端服務
服務健康
資源使用
核心依賴
上線變更
容量方面
談談運維這個崗位
運維是個什麼崗位？運維是管理伺服器的，運維是管理 倉庫的，運維是維護公司線上服務的，運維是做成本管理的，運維是幫開發發布版本的，運維是sre 等等。有時候和朋友相聚，總是會問到 你們在公司主要做什麼事情？有些時候我也愣了一下，腦袋裡快速回想自己在公司做了什麼事情。部署環境 伺服器管理 幫人排查問題 ...
從運維角度來說如何實現多分支測試
隨著業務和需求的增長，需要研發進行並行開發，如何保證功能之間不受影響，防止研發打架。如何保證大家 不被覆蓋，如何保證上線的功能就是上線的 這需要從 管理方面來進行考慮，當然推行git是基本。1.功能開發時使用功能分支，拋棄都提交到develop分支的方式，單獨拉取乙個分支進行開發，保證開發的時候只涉...
複雜運維場景下,如何實現分鐘級的故障根因定位
熊亞軍開篇 在超級網際網路公司，隨著伺服器規模都早早邁過 10 萬台量級，加之業務模式的多樣性和 it 架構的雲化遷移，其 it 運維團隊面臨的挑戰與日俱增，常規的系統和經驗都需要不斷迭代更新。首先我們先來看看超級網際網路公司的業務架構示例圖 在超級網際網路公司中，通常不同的層次都由不同的團隊來負責...