那些年你追過的女神：開發人員應該懂多少運維

編者按：在別的地方搜尋一下這個看不出性別的簡介真心沒多大意思。陳愛珍，DBA+社群中介軟體雲使用者組聯合發起人，上海中介軟體使用者組負責人，新炬網路技術專家，7年運維經驗，涉及電信、金融、稅務等行業，精通主流中介軟體技術，精通以業務為導向的端到端效能優化，熟悉私有云平臺建設。

紅色三月的節氣，發點生活照來應應景。

再來一些未披露的才藝。

（不知道為啥畫的是殺阡陌，而不是被囚禁的尊上和胡歌！捂臉~）

（新時代女性，可以寫程式碼，也能下廚房~）

---

偶然在朋友圈看到文章《放假了 過節了 寂寞了》， 忘記是誰轉發的。12月25日發表，一個寂寞的日子。文章屬於抒情式的小詩，作者描述的心情讓我有共鳴，文體非常喜歡。再看了看公眾號——流浪不是我的初衷，文藝女青年就果斷地關注了。因為流浪也不是我的初衷，雖然這幾年一直在四處流浪。平常自己也喜歡寫點抒情的文章小詩，就熱情的問是不是可以投稿，結果右軍說，你寫個《開發人員應該懂多少運維》吧。納尼！說好的文藝範呢，說好的流浪呢！

好吧，誰讓我自己說要投稿的，自已挖的坑只能自己填了。做運維這麼多年，也經常和開發人員打交道。下面就根據我自己的見解，跟大家聊聊開發人員應該懂多少運維。從一個郵件開始講起吧：

收到開發給我回復的這個郵件，我的內心是崩潰的。編碼不符合規範卻要求中介軟體修改底層的編譯方法來相容，中介軟體不是為你一家開發的好嗎！開發釋出了一個應用包，有三個不同的接入渠道，其中有兩個接入渠道都能正常訪問，而另一個不能正常訪問，且只有部分頁面不能訪問。

當時跟開發溝通，對應用平臺來說，只要應用包可以正常的釋出，有兩個接入渠道可以訪問，就說明應用平臺本身是沒有問題的，應該要去核實程式碼的問題。而開發卻一直跟我強調這個應用包在其他的應用平臺是可以正常訪問的，只是遷移到這個平臺執行才異常，一定是與平臺有關。在中介軟體的日誌裡一直在拋找不到檔案，但檔案卻是真實存在的，可以找到。程式碼跑在平臺上有問題，不能證明平臺沒有問題，就只能想辦法證明程式碼有問題了。讓他把程式碼發過來review，一眼就看出問題了。

程式碼如下：

 

那麼顯眼的空格都沒有看到，還反覆跟我強調應用程式碼沒有問題，遇上這樣的開發，我也是醉了。在故障分析時，日誌只有通過選中以高亮的方式顯示才能看出檔案路徑中多了一個空格，如果不是拿程式碼來review，從中介軟體的角度真的是沒辦法繼續排查。從這個事件可以看到，程式碼只有按照規範去編寫才能很好的遷移到各種平臺上。像這個案例，他們很多地方都是這麼編寫，得把全部的程式碼review一遍進行修改，所以按標準要求編寫程式碼非常重要，否則就是給自己埋坑。這是最常見的dev與ops交流的場景，應用程式碼交付部署失敗導致業務中斷。其實如果dev開發的程式質量高一點，ops是沒有機會接觸到dev。但是往往dev把ops當不良coding習慣的發現者，當程式bug的挖掘者。ops在做troubleshooting時，最常聽到dev的一句話就是：程式碼很多，這個方法很多模組都呼叫了，能幫忙定位到具體程式碼嗎？所以我認為開發至少要懂得運維分析程式碼異常的方法。

在很多“外人”的眼中，運維工程師的工作不過是裝軟體、部署上線、處理故障、7×24小時值班，感覺簡單而又枯燥至極。但事實並非如此，運維工作涵蓋很多技術領域，運維工程師要掌握硬體、軟體、作業系統、開發等多方面的知識。核心目標是確保系統穩定執行的同時，提高系統的質量，為億萬使用者使用的產品保駕護航。需要在程式碼不斷的更新發布過程中，在不中斷和破壞當前服務的基礎上，確保功能部署成功，同時也可以快速檢測和修復缺陷，提高可用性，提高變更成功率，減少故障等等。開發人員開發的程式只是整個系統的一個部分，而運維要搭建，維護系統提供全部的功能，所以ops要掌握的知識多且雜。

做運維得懂系統軟體（中介軟體，資料庫等），運維指令碼編寫（Shell，Python等），作業系統管理（AIX，HP,SUN,LINUX等），各種故障分析工具（HA,JCA,Hpjmeter,MAT等）。運維自動化工具開發，應用系統服務架構也得了解，還要有很強的運維意識，生產操作安全（攜程2015年故障據說就是因操作不當導致資料全部強制rm ），備份容災高可用等等。如果應用程式寫得不好，還要能對程式碼做review，配合開發一起排查。寫到這裡我都覺得自己好牛了，做運維不容易啊。

什麼是ops？度孃的解釋是：將開發交付的業務軟體和硬體基礎設施高效合理的整合，轉換為可持續提供高質量服務的產品，同時最大限度降低服務執行的成本，保障服務執行的安全。簡單來說，開發提供的是功能性需求，而運維提供的是非功能性需求，主要是以下幾個方面：

• 專案管控：總體設計把關，包括高可用，容災備份，整合規範，整合質量管控

• 容量管理：資源容量管理，服務容量管理，業務容量管理

• 應用維護：測試，釋出部署，問題處理，效能調優

• 監控管理：提前預警，效能監控，視覺化監控

• 安全管理：操作規範，許可權管理，安全漏洞，應急演練

就拿雙十一淘寶的保障和12306春運的保障來說，開發實現了相關的業務功能開發將程式碼交付給運維之後他們就沒事情了，而運維的工作則關係到系統的可用性，穩定性，安全性，業務的價值能否良好的傳達取決於運維。比如系統癱瘓是否能迅速恢復，比如高併發能否及時擴容，比如程式碼問題是否能夠不中斷的進行回退，這些都和運維息息相關。如果開發只關注應用新功能實現，當程式碼開發完成被部署到生產上時問題不斷，就要依靠IT運維來收拾殘局，缺陷和已知錯誤在生產上不斷遞迴，迫使IT運維不停的救火，所以開發需要看到他們工作和變更帶來的下游變化，以IT運維的視角來思考程式碼的構建，從而達到一個全域性的目標。所以開發要懂多少運維呢？我覺得是以下幾個方面：

1應用程式碼編寫方面 

1、瞭解程式執行到生產環境後對資源的使用不當會造成什麼樣的後果。比如對記憶體的使用，在開發階段沒有業務壓力，什麼東西都可以往記憶體裡放，但是拿到生產時併發量上來，很容易造成記憶體溢位或系統執行緩慢，所以在資源申請一定要仔細考量。資源包括什麼？記憶體、CPU、磁碟、網路、檔案描述符、外部API、快取、資料庫等；程式語言是如何管理資源的、合理的演算法/架構保證了資源的合理使用；malloc/free分配記憶體、connec、close使用網路等等。

2、瞭解當程式執行異常時做故障處理的思路。這樣在開發階段就能知道什麼樣的資訊要暴露，什麼樣的資訊不要暴露。有的開發什麼日誌都輸出，做故障分析的時候看得眼花也找不到個核心的資訊，但重要的資訊又不列印。開發模式和生產模式不一樣，不要把開發除錯的模式釋出到生產。大量的日誌輸出也可能導致例項掛起，停止服務。

3、瞭解不良的coding習慣會給運維帶來怎麼樣的麻煩。比如申請記憶體不釋放，資料庫連線池申請了不關閉，慎用同步鎖造成執行緒堵塞，死鎖之類。絕不傳遞一個已知缺陷至下游，絕不因小失大。

4、站在容易維護的角度編寫程式碼，包括容易配置、容易部署、容易監控、容易擴充套件，只需要簡單的增加資源（CPU、記憶體、磁碟、機器等）就行，不需要太多人工遷資料、修改配置。

2系統平臺方面 

1、對執行平臺的產品有基本的瞭解，比如tomcat，weblogic，websphere。瞭解這些系統軟體的基本執行原理，特性，比如不同版本對java的要求，不同作業系統平臺java的配置引數。

2、從軟體交付的全域性出發，加強各角色之前的合作，提交軟體交付的成功率和效率。打破開發與運維之間存在的資訊”鴻溝”。開發人員應讓運維人員瞭解架構設計，細心聽取運維人員的建議，瞭解系統上線方面運維的需求，進行技術改造，使部署工作更加快捷有效。

3、深刻理解執行平臺基本沒有問題。應用程式碼的執行平臺是指一個容器，承載著業務程式碼的執行，負責提供相關資源的排程和分配。如果應用程式碼能夠正常的部署在平臺上，例項可以正常啟動，那麼一切不能正常訪問的異常都是源自程式碼編寫的問題。一個生產環境中往往是有很多套系統都執行在這個平臺上，其他系統可以正常訪問，那平臺本身是不會導致異常，這裡指的是產品bug類，無關配置。

3運維技能方面 

1、瞭解一些基本的故障分析工具的使用，因為並不是每一個運維都能做程式碼review。如果開發不懂分析故障，運維不懂程式碼review，就是死鎖。比如說threaddump，javacore，headdump檔案代表是什麼，怎麼產生的，怎麼分析，使用什麼樣的工具。如果開發能瞭解這些東西，和運維一起做troubleshooting時效率也能快速提升。

2、瞭解一些應用效能分析的方法，在開發階段對核心的業務功能就關注效能情況，避擴音交到生產環境在大併發的情況下存在嚴重明顯的效能問題。

3、開發人員一定要記住，如果出現了問題，那麼有90%的可能性是開發人員自己的錯誤。

以上想表達的是開發需要在源頭上解決質量問題，減少技術債務從研發轉向運維，並瞭解運維負責的“非功能性需求”，化解掉一部分風險。兩方相互之間緊密合作，才能為業務提供穩定，安全及可靠的IT服務。

最後借用網紅網際網路運維雜談老王的一張圖展示一下Dev與Ops的關係。在非DevOps模式裡用是防火牆來隔離dev與ops，彼此不懂。其實開發的程式作為運維體系裡的一部分，應該要了解運維，瞭解程式跑在什麼樣的環境上，才能讓程式更好的服務業務。現在DevOps模式炒得很火，老王把DO關係分成三個階段。

第一個階段：DO混合。大家的職能交織在一起，運維是研發的附屬過程，運維的職責就是資源交付。

第二個階段：DO分離。研發和運維走向分離，一些維護的壓力逐漸浮現出來，專業的運維如何更好的做好運維，定規範，建平臺，收資料等等。

第三個階段：DO融合。注意不是混合。融合是指一種能力的流動，運維的能力已經是研發過程自然而然考慮的一部分的了。另外隨著平臺、規範、流程的完善，此時研發都可以具備真正的運維能力。

當未來發展到DO融合階段時，DO是不分的，中間不會再有那道防火牆。開發人員會具備運維能力，運維人員具備開發能力，雙方共同肩負著質量的責任。

作者介紹：於君澤（右軍）

• 螞蟻金服高階技術專家、支付核算技術部負責人、成都研發中心技術團隊建立者之一。

• 先後負責或參與過轉賬類業務、賬單類業務、社群支付、開放平臺、支付平臺、資金核算平臺類、營銷類支付工具的建設。

• 有數年電信業務研發經驗，涉及BSS|OSS|針對性營銷等平臺。

• 個人感興趣的方向：高併發、分散式系統、穩定性模式；內建質量、技術型管理。

本文來自雲棲社群合作伙伴”DBAplus”，原文釋出時間：2016-03-04