編者按：在別的地方搜索一下這個看不出性別的簡介真心沒多大意思。陳愛珍，DBA+社群中間件云用戶組聯(lián)合發(fā)起人，上海中間件用戶組負責人，新炬網(wǎng)絡(luò)技術(shù)專家，7年運維經(jīng)驗，涉及電信、金融、稅務(wù)等行業(yè)，精通主流中間件技術(shù)，精通以業(yè)務(wù)為導(dǎo)向的端到端性能優(yōu)化，熟悉私有云平臺建設(shè)。

紅色三月的節(jié)氣，發(fā)點生活照來應(yīng)應(yīng)景。

再來一些未披露的才藝。

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

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

---

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

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

收到開發(fā)給我回復(fù)的這個郵件，我的內(nèi)心是崩潰的。編碼不符合規(guī)范卻要求中間件修改底層的編譯方法來兼容，中間件不是為你一家開發(fā)的好嗎！開發(fā)發(fā)布了一個應(yīng)用包，有三個不同的接入渠道，其中有兩個接入渠道都能正常訪問，而另一個不能正常訪問，且只有部分頁面不能訪問。

當時跟開發(fā)溝通，對應(yīng)用平臺來說，只要應(yīng)用包可以正常的發(fā)布，有兩個接入渠道可以訪問，就說明應(yīng)用平臺本身是沒有問題的，應(yīng)該要去核實代碼的問題。而開發(fā)卻一直跟我強調(diào)這個應(yīng)用包在其他的應(yīng)用平臺是可以正常訪問的，只是遷移到這個平臺運行才異常，一定是與平臺有關(guān)。在中間件的日志里一直在拋找不到文件，但文件卻是真實存在的，可以找到。代碼跑在平臺上有問題，不能證明平臺沒有問題，就只能想辦法證明代碼有問題了。讓他把代碼發(fā)過來review，一眼就看出問題了。

代碼如下：

?

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

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

做運維得懂系統(tǒng)軟件（中間件，數(shù)據(jù)庫等），運維腳本編寫（Shell，Python等），操作系統(tǒng)管理（AIX，HP,SUN,LINUX等），各種故障分析工具（HA,JCA,Hpjmeter,MAT等）。運維自動化工具開發(fā)，應(yīng)用系統(tǒng)服務(wù)架構(gòu)也得了解，還要有很強的運維意識，生產(chǎn)操作安全（攜程2015年故障據(jù)說就是因操作不當導(dǎo)致數(shù)據(jù)全部強制rm ），備份容災(zāi)高可用等等。如果應(yīng)用程序?qū)懙貌缓?#xff0c;還要能對代碼做review，配合開發(fā)一起排查。寫到這里我都覺得自己好牛了，做運維不容易啊。

什么是ops？度娘的解釋是：將開發(fā)交付的業(yè)務(wù)軟件和硬件基礎(chǔ)設(shè)施高效合理的整合，轉(zhuǎn)換為可持續(xù)提供高質(zhì)量服務(wù)的產(chǎn)品，同時最大限度降低服務(wù)運行的成本，保障服務(wù)運行的安全。簡單來說，開發(fā)提供的是功能性需求，而運維提供的是非功能性需求，主要是以下幾個方面：

• 項目管控：總體設(shè)計把關(guān)，包括高可用，容災(zāi)備份，集成規(guī)范，集成質(zhì)量管控

• 容量管理：資源容量管理，服務(wù)容量管理，業(yè)務(wù)容量管理

• 應(yīng)用維護：測試，發(fā)布部署，問題處理，性能調(diào)優(yōu)

• 監(jiān)控管理：提前預(yù)警，性能監(jiān)控，可視化監(jiān)控

• 安全管理：操作規(guī)范，權(quán)限管理，安全漏洞，應(yīng)急演練

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

1應(yīng)用代碼編寫方面?

1、了解程序運行到生產(chǎn)環(huán)境后對資源的使用不當會造成什么樣的后果。比如對內(nèi)存的使用，在開發(fā)階段沒有業(yè)務(wù)壓力，什么東西都可以往內(nèi)存里放，但是拿到生產(chǎn)時并發(fā)量上來，很容易造成內(nèi)存溢出或系統(tǒng)運行緩慢，所以在資源申請一定要仔細考量。資源包括什么？內(nèi)存、CPU、磁盤、網(wǎng)絡(luò)、文件描述符、外部API、緩存、數(shù)據(jù)庫等；編程語言是如何管理資源的、合理的算法/架構(gòu)保證了資源的合理使用；malloc/free分配內(nèi)存、connec、close使用網(wǎng)絡(luò)等等。

2、了解當程序運行異常時做故障處理的思路。這樣在開發(fā)階段就能知道什么樣的信息要暴露，什么樣的信息不要暴露。有的開發(fā)什么日志都輸出，做故障分析的時候看得眼花也找不到個核心的信息，但重要的信息又不打印。開發(fā)模式和生產(chǎn)模式不一樣，不要把開發(fā)調(diào)試的模式發(fā)布到生產(chǎn)。大量的日志輸出也可能導(dǎo)致實例掛起，停止服務(wù)。

3、了解不良的coding習慣會給運維帶來怎么樣的麻煩。比如申請內(nèi)存不釋放，數(shù)據(jù)庫連接池申請了不關(guān)閉，慎用同步鎖造成線程堵塞，死鎖之類。絕不傳遞一個已知缺陷至下游，絕不因小失大。

4、站在容易維護的角度編寫代碼，包括容易配置、容易部署、容易監(jiān)控、容易擴展，只需要簡單的增加資源（CPU、內(nèi)存、磁盤、機器等）就行，不需要太多人工遷數(shù)據(jù)、修改配置。

2系統(tǒng)平臺方面?

1、對運行平臺的產(chǎn)品有基本的了解，比如tomcat，weblogic，websphere。了解這些系統(tǒng)軟件的基本運行原理，特性，比如不同版本對java的要求，不同操作系統(tǒng)平臺java的配置參數(shù)。

2、從軟件交付的全局出發(fā)，加強各角色之前的合作，提交軟件交付的成功率和效率。打破開發(fā)與運維之間存在的信息"鴻溝"。開發(fā)人員應(yīng)讓運維人員了解架構(gòu)設(shè)計，細心聽取運維人員的建議，了解系統(tǒng)上線方面運維的需求，進行技術(shù)改造，使部署工作更加快捷有效。

3、深刻理解運行平臺基本沒有問題。應(yīng)用代碼的運行平臺是指一個容器，承載著業(yè)務(wù)代碼的運行，負責提供相關(guān)資源的調(diào)度和分配。如果應(yīng)用代碼能夠正常的部署在平臺上，實例可以正常啟動，那么一切不能正常訪問的異常都是源自代碼編寫的問題。一個生產(chǎn)環(huán)境中往往是有很多套系統(tǒng)都運行在這個平臺上，其他系統(tǒng)可以正常訪問，那平臺本身是不會導(dǎo)致異常，這里指的是產(chǎn)品bug類，無關(guān)配置。

3運維技能方面?

1、了解一些基本的故障分析工具的使用，因為并不是每一個運維都能做代碼review。如果開發(fā)不懂分析故障，運維不懂代碼review，就是死鎖。比如說threaddump，javacore，headdump文件代表是什么，怎么產(chǎn)生的，怎么分析，使用什么樣的工具。如果開發(fā)能了解這些東西，和運維一起做troubleshooting時效率也能快速提升。

2、了解一些應(yīng)用性能分析的方法，在開發(fā)階段對核心的業(yè)務(wù)功能就關(guān)注性能情況，避免提交到生產(chǎn)環(huán)境在大并發(fā)的情況下存在嚴重明顯的性能問題。

3、開發(fā)人員一定要記住，如果出現(xiàn)了問題，那么有90%的可能性是開發(fā)人員自己的錯誤。

以上想表達的是開發(fā)需要在源頭上解決質(zhì)量問題，減少技術(shù)債務(wù)從研發(fā)轉(zhuǎn)向運維，并了解運維負責的“非功能性需求”，化解掉一部分風險。兩方相互之間緊密合作，才能為業(yè)務(wù)提供穩(wěn)定，安全及可靠的IT服務(wù)。

最后借用網(wǎng)紅互聯(lián)網(wǎng)運維雜談老王的一張圖展示一下Dev與Ops的關(guān)系。在非DevOps模式里用是防火墻來隔離dev與ops，彼此不懂。其實開發(fā)的程序作為運維體系里的一部分，應(yīng)該要了解運維，了解程序跑在什么樣的環(huán)境上，才能讓程序更好的服務(wù)業(yè)務(wù)?，F(xiàn)在DevOps模式炒得很火，老王把DO關(guān)系分成三個階段。

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

第二個階段：DO分離。研發(fā)和運維走向分離，一些維護的壓力逐漸浮現(xiàn)出來，專業(yè)的運維如何更好的做好運維，定規(guī)范，建平臺，收數(shù)據(jù)等等。

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

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

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

• 螞蟻金服高級技術(shù)專家、支付核算技術(shù)部負責人、成都研發(fā)中心技術(shù)團隊創(chuàng)建者之一。

• 先后負責或參與過轉(zhuǎn)賬類業(yè)務(wù)、賬單類業(yè)務(wù)、社區(qū)支付、開放平臺、支付平臺、資金核算平臺類、營銷類支付工具的建設(shè)。

• 有數(shù)年電信業(yè)務(wù)研發(fā)經(jīng)驗，涉及BSS|OSS|針對性營銷等平臺。

• 個人感興趣的方向：高并發(fā)、分布式系統(tǒng)、穩(wěn)定性模式；內(nèi)建質(zhì)量、技術(shù)型管理。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。