17. 风险管理
涉及項目可能遇到各種不確定因素。它包括風險識別，風險量化，制訂對策和風險控制等。
17.1.?開發，測試與運維的關系
開發，測試，運維不是三個獨立部門，他們相互緊密聯系，但又相互制約：
開發只負責寫程序，將運行無誤的程序提交至版本庫中
開發不能私自將程序交給運維部署，也不能將編譯好的程序給運維測試。
測試部只能從版本庫提取代碼，然后編譯，打包，運行，測試
不允許測試部將代碼交給運維部部署
避免代碼沒有經過版本庫流入生產環境，線下與線上代碼不一致
運維部負責部署應用程序，配置管理，只接受測試部確認無誤的版本，部署代碼只能從版本庫中提取
17.2.?技術規范的誤區
開發 -> 測試 -> 運維 貫穿始終。
幾乎所有的技術企業都會重視技術規范，為此制定各種規范，并要求員工嚴格執行。同時員工會想出各種對策，就這樣形成了潛規則。
流程與規范的制定需要需要滿足幾個條件，簡單，容易掌握，容易執行，可重復執行
企業管理層擅長制定烏托邦式的流程與規范，隨便拿出一條都堪稱完美，無懈可擊，但沒有考慮到執行結果，流程規范在執行過程中每個環節都會出現問題。
我16年的職業生涯中在不同的公司任職過，幾乎每到一家公司都會遇到各種規范，隨著職業發展最后我也成為了規范的制定者，也曾經主持制定過開發規范，運維規范，測試規范等等。
我做過很多規范，文檔無數，技術人員根本不會去看，通過開會向下傳達，開會的人根本沒有心思理會你的規范，規范執行阻力是很大的，效果也差。
終于有一天我意識問題的存在，開始反思，企業是否需要制定這些規范？ 我發現與企業環境/文化有很大關系。
有些強制的規范可以通過一些技術手段，避免出現。不會出現也就無需規范！
只有機器人才能100%執行流程
除了事，制定規范，后續無人跟進，
員工考慮的是盡快完成工作，
但這些規范起到的實質作用就好比“請保持室內衛生，不準亂團垃圾，禁止隨地吐痰”
故事一
例如下面一個小故事，公司某部因為將開發數月的代碼丟失了，導致測試無法進行，領導打發雷霆，某管理層制定了下面的規范，大意為。
1.?定期備份機制
2.?代碼注釋要求
3.?代碼訪問需要更高層的批準
4.?詳細的部署文檔
等等
我認為源碼管理主要有兩種手段，技術手段與管理手段。
我先談談管理手段： 例如通常通過規章制度，責任追究等等手段，要求員工達到規范標準，但通常執行力都會打折，無法達到預期，人的不穩定性因素太多。往往發現員工沒有按照規范操作為時已晚，將該員工辭退也無法挽回公司的損失。
就如公司規章制度寫的清清楚楚，要求員工提交代碼到版本庫，但各種原因沒有被執行，當代碼丟失，從上至下追究責任，公司的損失無法挽回。
所以我主張技術手段：
例如源碼如果發布到線上，必須經過版本庫，只能使用自動部署，不允許程序員私自將代碼交給運維手工部署。另外發布代碼的同事，可以不提供生產服務器登陸權限，他只能通過工具發布代碼。
部署流程如下：
源碼(程序員)?提交到development?分支UAT階段?---->?合并到?testing
分支Beta階段（主管合并，程序員沒有權限）------>?master?分支(主管合并)?----->?自動部署系統(運維)
---->?生產服務器。
這樣通過技術手段防止了代碼因員工離職，硬盤損壞等等原因，導致代碼丟失的可能。
代碼發布者也無需對照部署文檔，手動登陸服務器逐條按照部署說明書操作，防止了人員誤操作，也提高了部署效率，節省了人力成本，通常在5分鐘之內可以完成所有部署。
故事二
Sidebar content.
-----
我再來舉另外一個例子，就是開發中的編碼規范，很多軟件企業都有是不是？
例如要求程序員：
if
(){}
要寫成
if?()
{
...
}
等等要求不一一列舉，甚至組織代碼評審解決編碼規范問題。
我的建議為什么不在IDE上設置自動格式化，或者在svn/git提交的時候通過hook調用格式化程序。
故事三
-----
管理層要求運維每天發送服務器狀態報告，運維人員需要登錄每個服務器或者從cacti等工具中獲得服務器運行狀態數據，然后制作一個報告文檔，每天給各位發送一次。
運維需要一個專職人員做這個報告，這種報告幾乎沒有人看，就像“人民日報”?人民從來不看。
當運維事故該出現的時候還是會出現，老板一個一個罵，扣工資，扣獎金，運維覺得委屈，公司受到損失。平日里的這些工作并不能避免運維事故，也不能改善運維工作。
故事四
-----
在舉一個例子，運維工作要求備份數據，A員工負責備份，B
員工負責檢查A員工的備份，結果兩年以后出事了，需要恢復數據，發現A沒有備份，而B在一年前就再沒有檢查A的工作。起初前一年還是按流程備份，后來A發現B不再嚴格檢查工作，備份工作逐漸減少，最后停止了備份，一直相安無事，直到事發。
故事五
-----
我曾經遇到過一個兢兢業業的管理者，他制定規范，要求值班的同事7*24小時，每間隔一定的時間做一次操作，驗證系統正常運行，以便能夠第一時間通知運維處理故障。值班的同事而偶偷懶，他就半夜起來監控他們工作。一個打工者能做到如此，真讓人佩服。
但是我們有更好的方法，真的不必如此操勞且效率低下。
這些故事是一個無休止的死循環
-----
出問題?->?發上制定規范?->
無人看/看了慢慢淡忘/石沉大海?->
繼續出問題。連續出現問題，采用行政手段處分，扣獎金等等。很多管理者將其歸咎為?“執行力”
弱，我并不這么認為。
我覺得很多規范是形式主義。我一向主張實用主義。
通過技術手段可能避免很多沒有意義規范，開發自動化，測試自動化，運維自動化，這是趨勢也是我的努力的目標。
上面僅僅舉了幾個例子，較片面，不能完全表達我的想法，需要更多的溝通，歡迎提出您的意見與建議。
原文出處：Netkiller 系列 手札
本文作者：陳景峯
轉載請與作者聯系，同時請務必標明文章原始出處和作者信息及本聲明。
總結
- 上一篇： .NET Core 使用 nlog 进行
- 下一篇： Python 学习笔记 -- 继承与多态