編者按：在別的地方搜索一下這個看不出性別的簡介真心沒多大意思。陳愛珍，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，彼此不懂。其實開發的程序作為運維體系里的一部分，應該要了解運維，了解程序跑在什么樣的環境上，才能讓程序更好的服務業務?，F在DevOps模式炒得很火，老王把DO關系分成三個階段。

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

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

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

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

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

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

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

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

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

本文來自云棲社區合作伙伴"DBAplus"，原文發布時間：2016-03-04

總結

以上是生活随笔為你收集整理的那些年你追过的女神：开发人员应该懂多少运维的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。