【運維者說】程序員玩跨界，錯在運維人員

   

   在不少交流場合，咱們或多或少能聽到有小夥伴抱怨運維崗位工做沒有獲得老闆或者公司同事的承認，這怪誰呢？私覺得只能怪運維崗位的各位同行，爲何這麼講呢？我這個攢了好久的大招，今天終於能夠釋放出來了。

   

  恰逢看到田逸老師寫的博客《程序員，請不要搶系統管理員的飯碗》以及文章下面各位同仁的評論內容，不少小夥伴基本上是從一個系統管理員的角度出發說出了安全問題的緣由是程序員不該該這麼作而這麼作了，那程序員應該怎麼作，他們知道嗎？從這篇博客中描述的安全問題出發，田逸老師做爲系統管理人員排查問題的思路很是清晰，對於咱們這些運維崗位的新人而言，是一次不錯的學習機會。同時，這篇文章也讓我想跟你們交流下在運維崗位的一些心得和想法（不必定正確，還有點羞於表達，想一想仍是寫出來比較痛快），可能不少優秀的運維工程師和系統工程師會無心躺槍，請你們不要介意，無心針對任何人，只是有感而發。

  不得不說，若是放在剛開始作運維工做的時候，我也會如田老師這樣義憤填膺（可能描述不當，望田老師海涵）地跳出來指責程序員，「×××」程序員居然還用root（不是root難道就能夠直接出如今程序代碼裏面嗎？），還在命令行中輸入明文密碼（運維人員不會這麼作麼？腳本里面也不行），還用lamp套件（運維工程師大家偷懶讓程序員在服務器上部署lamp套件還怪程序員）。固然在不瞭解田老師公司具體的開發運維模式的狀況下，我就不妄加評論文章所描述的安全問題事件中運維人員的失職之處了。

  不少時候，運維狗和程序猿應該是好×××而不是情敵，在具體的工做中也應該是互相協做而不該該是互相指責的。每一個崗位都有本身專一點和知識經驗積累，固然也不可避免會有一些交集，尤爲當公司業務規模不大，或者說某些崗位的人員沒有體現出本身應有的價值，那麼這種交集可能會不少了。運維和開發人員在整個業務系統建設過程當中應該是互相協做，各有關注點，我的認爲開發關注的是系統實現，運維關注的是系統運營。把一個系統該有的功能和該注意的點實現了，減小代碼低級的bug，加強代碼可讀性和可重構性，這是程序員的職責所在。環境維護，代碼部署，安全防範，容量管理，可用保障等是運維人員的職責所在。

 當一個程序開始在生產環境運行後，主要的工做和權責就都在運維崗位上了，開發人員頂多協助處理問題而已。

 業務在生產環境運行過程出現的任何問題，都是運維人員工做不到位形成的。可能有人會說，老闆沒有給運維人員這麼大的權限（沒法拒絕垃圾應用上線，那你至少應該告訴老闆，讓老闆取捨）或者不少時候緊急上線，產品和開發人員在運維人員屁股後面的威逼利誘致使讓一個有問題的業務應用跑在了生產環境（你讓上的，風險確定須要本身來承擔，產品和開發人員纔沒時間處理線上故障啊）。不管什麼藉口，我始終堅持這是運維人員工做不到位，對本身崗位的權責認知不到位。先不說一些比較複雜，讓運維人員沒法拒絕的緣由致使一個有問題的業務應用部署到生產環境，對於不少很低級的問題，運維人員均可能把責任推到程序員身上，除非大家公司就一個程序員並且還作着系統管理員的工做，不然仍是本身認真反省下：

 1.沒有運維人員的受權（或者說壓根就沒作權限管理）和支持，開發人員是如何把業務應用部署到生產環境服務器的：

   目錄777權限（rwx rwx rwx），這徹底是在打開發人員的屁股，狂抽運維人員的臉。

   一個應用程序不該該是由運維人員負責部署或者提供工具部署上線的嗎？

   生產環境維護，應用部署支持，這些都是須要運維人員處理的事情。

 2.沒有運維人員的默許，一些敏感信息能明文出如今生產環境的服務器上？

    惡意的猜猜，這個程序員會不會也喜歡用root賬號連數據庫呢？

   關鍵配置文件可疑信息的掃描，這是運維人員必需要作的事情。

 3.是否正確作到網絡區域劃分和內外網的隔離？

   不少業務服務器是不必直接訪問外網，對於這些服務器阻斷外網訪問權限是很是必要的。若是大家公司只有一臺服務器或者只有一個網段的話，當我什麼都沒說。

  

 4.關於「root」這個問題，是否有相關明文規範，是否有相關指導說明（可能有人說了，我常常說了程序員不聽話，仍是老樣子咋辦。光說有毛用，你能跟每個程序員都這麼講麼，白紙黑字纔是王道）。

  我很肯定，不少開發人員對於使用root有什麼風險徹底不清楚的，可是對於運維人員而言，這個風險是很清楚的，運維人員有沒有明確告訴開發人員不能這麼作，這麼作有什麼問題。徹底臆測對方可能知道某些本身崗位知道的東西，出問題了還拿這些來埋怨對方的行爲，徹底實在耍流氓。

5.低級別或者第三方應用系統是否和主業務相關服務器作了很好的隔離。

  每一個崗位都有本身的關注點，以及相應的背景知識，若是可以作到充分的溝通交流，這樣纔不會產生沒必要要的信息不對稱。

  開發人員徹底能夠抱怨運維人員不能及時處理SSH相關漏洞問題。不少人看到這句話，運維人員第一反應是ssh有什麼漏洞，咱們常常登陸系統的服務管大家程序員什麼事，開發人員看到後會會心一笑，java框架strtus已經成爲漏洞之王，防不勝防啊。你看對於一個簡單的SSH三個字母，在不一樣的知識背景下，若是沒有充分的溝通了解，很容易出現知識不對稱形成的問題。我認爲你應該知道什麼，應該怎麼作，事實上對方可能壓根就不清楚你的想法。讓開發人員知道生產環境有哪些爲了保證業務高速穩定安全運行而存在的規矩，是運維人員責無旁貸的責任。咱們也常常碰到這種狀況，線上異常應用拋出異常日誌，運維人員看了半晌不知道錯在哪裏，有沒有這種狀況？開發人員一眼就能看出錯誤日誌表明的是什麼意思，並且有些二流的開發人員還以此爲傲，這麼簡單的錯誤信息都看很少，怎麼作IT民工的。我想說，程序員在應用中寫的異常日誌難道不是給運維人員看的麼，搞的這麼深奧，有毛意思？日誌輸出就是要錯誤等級分明，提示信息簡單明瞭。

  運維人員要明確本身的職責，作好生產環境的守護神，不要動不動就怪咱們可愛的程序員，你們都不容易，我相信只要運維人員作好了本身的工做，更好地幫助程序員成長，老闆和同事必定會承認大家的價值的。

別人能玩跨界，確定是咱們本身不少東西沒作到位致使的。我相信大部分的程序員仍是喜歡安心寫代碼的，運維這些瑣事才懶得弄呢。不要給別人犯錯的機會，不要給程序員折騰生產環境的機會，不少時候程序員可以玩跨界，要麼這個公司沒有運維崗位，要麼徹底源於運維人員偷懶，放開了相關係統權限，你能說不是這樣嗎？

程序員玩跨界，錯在運維人員。

固然一個全能的程序員和一個全能的運維工程師都是不可多得的人才，開發人員要有運維思惟和意識，運維人員要有開發思惟和意識，對於不少像大衆點評這種給每一個程序員發一本《鳥哥的linux私房菜（基礎學習篇）》和一本《hadoop權威指南》的公司點無數個贊，固然若是能給每一個運維工程師發一些開發相關入門的書籍，那就更加贊得不能說了。

安全問題從來是一個大問題，不是說系統管理員就能比程序員解決安全問題的能力高多少，這是一個體系問題，須要設備，技術，制度以及人員，培訓各方面的綜合介入，當系統規模發展到必定程度的時候須要專一安全的人員（各類猥瑣流）投入時間和精力來處理。只能說針對系統層面的安全問題，運維工程師或者說系統管理員可能會被開發人員有更深入的認識罷了。

歡迎交流，同時但願更多運維工程師和開發工程師成爲好×××或者好情侶，一塊兒保證業務高速穩定安全發展。若是你認爲本身在安全方面有更好的意識和經驗，歡迎時刻在任何地方把你掌握的東西分享給你們。

啥？運維工做作的很專業很優秀的狀況下，老闆還不承認？歡迎聯繫我，我認識不少對運維工程師價值承認的老闆。

相關引用：

程序員，請不要搶系統管理員的飯碗：http://sery.blog.51cto.com/10037/1429418