Home | 簡體中文 | 繁體中文 | 雜文 | 知乎專欄 | Github | OSChina 博客 | 雲社區 | 雲棲社區 | Facebook | Linkedin | 視頻教程 | 打賞(Donations) | About
知乎專欄多維度架構 | 微信號 netkiller-ebook | QQ群:128659835 請註明“讀者”

第 12 章 風險管理

目錄

12.1. 項目管理繞不開問題
12.1.1. 開發,測試與運維的關係
12.1.2. 壓力問題
12.1.3. 重速度輕安全
12.1.4. 技術實力
12.1.5. 測試問題
12.1.6. 運維問題
12.2. 程序猿說的「優化」是什麼意思?
12.2.1. 經驗和能力不足
12.2.2. 給前人擦屁股
12.2.3. 先蓋樓,後打地基
12.2.4. 使用新技術和不熟悉的技術
12.2.5. 最後總結
12.3. 制度、流程和規範的誤區
12.3.1. 故事一
12.3.2. 故事二
12.3.3. 故事三
12.3.4. 故事四
12.3.5. 故事五
12.3.6. 總結
12.3.7. 案例分析:怎樣避免電梯傷人事件再發生
12.4. 因果圖在運維工作中的應用
12.4.1. 故障樹分析(Fault Tree Analysis,FTA)
12.4.2. 什麼是因果圖
12.4.3. 為什麼使用因果圖
12.4.4. 何時使用因果圖
12.4.5. 何處使用因果圖
12.4.6. 誰來負責製作因果圖
12.4.7. 怎樣使用因果圖
12.4.7.1. www.example.com, img.example.com
12.4.7.2. acc.example.com, api.example.com
12.4.7.3. cch.exampel.com, mq.exampe.com, db.example.com
12.5. Incident Management(突發事件管理)
12.5.1. 突發事件處理流程
12.5.2. 事件處理方式
12.6. 監控的藝術
12.6.1. 背景
12.6.2. 概述
12.6.3. 怎樣監控
12.6.3.1. 衛星監測
12.6.3.2. 逐級診斷
12.6.3.3. 模擬人工
12.6.3.4. 數據分析
12.6.3.5. 監控與開發
12.6.4. 總結

涉及項目可能遇到各種不確定因素。它包括風險識別,風險量化,制訂對策和風險控制等。

12.1. 項目管理繞不開問題

12.1.1. 開發,測試與運維的關係

開發,測試,運維不是三個獨立部門,他們相互緊密聯繫,但又相互制約:

開發只負責寫程序,將運行無誤的程序提交至版本庫中

開發不能私自將程序交給運維部署,也不能將編譯好的程序給運維測試。

測試部只能從版本庫提取代碼,然後編譯,打包,運行,測試

不允許測試部將代碼交給運維部部署

避免代碼沒有經過版本庫流入生產環境,綫下與線上代碼不一致

運維部負責部署應用程序,配置管理,只接受測試部確認無誤的版本,部署代碼只能從版本庫中提取

開發 -> 測試 -> 運維 貫穿始終。

12.1.2. 壓力問題

運維人員在互聯網企業是最辛苦的,7*24小時待命,待遇一般。

很多程序寫的非常差,BUG非常多,容易出現無響應,崩潰,開發人員一時也解決不了,只能硬上線。

最終這些問題都推給運維,通過運維手段去解決。這就讓運維工作壓力很大,狀態緊繃,如履薄冰,如臨深淵,隨時隨地處理故障。尤其是在雙11這樣的節日。

12.1.3. 重速度輕安全

國內互聯網企業成長速度是第一位,管理粗放,怎麼快,怎麼來。

期初公司也是重視安全的,例如賬號權限分級管理,操作也有流程,審批。但是企業要速度,各部門都面臨壓力。從一周一個版本到一天升級一個版本,程序的質量也在下滑,常常升級失敗,反覆回撤,為了效率甚至線上直接開放給開發人員權限,在線上修改。很多開發人員擁有資料庫權限。

另一個問題是人員流動,很多人離職很長一段時間,權限都沒有收回,仍能遠程進入系統。

國內企業沒有花錢請安全顧問公司的習慣,自認為自己有能力解決安全問題。運維人員也不會向公司建議找第三方安全公司,他們擔心公司懷疑他們的技術能力。

12.1.4. 技術實力

你真的認為花高薪聘用的運維人員技術能力很強嗎?哪些標着有BAT經驗(大企業),渡過金的人運維人員能力很強嗎?

很多運維人員僅僅是安裝配置的水平,看了幾本架構優化的書籍侃侃而談。哪些在大企業幹過的運維人員,也僅僅接觸到平台的一角,他的權限根本無法窺視到全貌,無法使公司的運維水平上升到另一高度。

目前互聯網企業運維人員普遍比較年輕,都是90後組成,這個年紀正是處于經驗積累階段和學習階段,只有把系統當成了試驗場才能學到東西,有很多事故是運維人員趕時髦,使用了一些新技術,不熟悉的技術(僅僅掌握皮毛),他們管這個叫“踩坑”。現在几乎沒有企業招聘80後做運維,因為他們不能加班,不願加班,抗壓性/服從性較差。

由於運維技術能力,眼界見識。不是他們沒有做(備份,快照,防篡改技術,防刪除技術),是他們是想不出來解決方案的。

運維人員也不會建議公司請第三方公司或技術顧問,一是要花錢,公司不同意。二是,他們怕公司懷疑他們的技術能力。就這樣很多問題被塵封了,只有出現重大事故的時候你才意識到他們能力不行。

12.1.5. 測試問題

首先回答你測試問題,測試人員的水平是整個團隊中能力最差的,企業對技術人員重視重讀順序是,開發第一,運維第二,測試第三。人肉測試與自動化測試80%:20%的比例,掌握自動化測試高級測試人員薪水不低,很多企業不願意或出於成本考慮,國內人力成本便宜大量採用人肉測試。無論是人肉還是自動化距離理想期望的測試結果還差的遠。

自動化測試實施常常遇到很多問題(安全,技術,管理等等),例如

自動化測試攻城獅的技術水平有限(僅僅掌握了皮毛)需求的頻繁變更讓自動化測試腳本成為負擔,最後不了了之複雜的技術棧,手機驗證,圖像驗證,定位信息,攝像頭操作,指紋,感測器,二進制位操作...... 一般測試攻城獅搞不了,卡在某個點過不去,最終放棄

導致自動化測試無法繼續實施下去,一般除非是在職的高級軟件攻城獅轉測試攻城獅,他對需求清楚,功能清楚,協議清楚,數據清楚,業務邏輯走向清楚,否則一般的測試攻城獅根本搞不定這麼複雜的測試腳本。企業也不捨得讓這個開發主力轉到測試部門去。

由於系統過于龐大,人肉測試所有功能是不現實的,所以常常是隻測試新加入的功能或測試有依賴的功能。實際工作中,程序猿改動一行代碼,牽一髮動全身,尤其是那些復用的代碼,加之程序猿人員流動,當時負責該功能人早已經離職(平均三年離職),你不知道改動一處,會有什麼影響,所以程序猿很牴觸修改老代碼和其他人寫的代碼,寧可自己重新寫,這又造成了臟代碼,代碼不斷膨脹,反證三年後他也可能離職,讓新來的程序猿接盤。所以常常是新加入的功能測試OK,隱藏很深的一個功能出現的故障,測試無法覆蓋到所有功能。

很多時候故障不是測試人員發現的,多半是用戶發現的,用戶投訴到客服,客服反饋給技術部。

12.1.6. 運維問題

接下來回答你運維的問題,運維手段多着能,通過運維手段可以解決很多BUG問題。常用手段,例如萬能重啟,主備策略,負載均衡,快照,權限控制。我給你舉幾個例子。

如果代碼容易崩潰,那就做一個自動重啟的腳本,發現崩潰,立馬重啟。

如果代碼並發有問題,例如做一個並發 10000的程序,結果程序猿水平有限1000並發就崩潰。就用負載均衡堆硬件,用10台伺服器,先抗着

代碼有漏洞,黑客入侵,修改頁面植入木馬。運維就通過權限限制檔案只能讀,不能修改。

代碼有漏洞,導致黑客修改資料庫數據。運維有多重解決方案,例如去掉修改權限,臨時增加觸發器,修改數據拋出錯誤中止操作

很多手段,這些手段可以為開發人員爭取代碼修復的時間