榮譽，仍是苦逼？| 也議全棧工程師和DevOps

引言

全棧工程師（本文稱「全棧」開發者）和 DevOps 無疑是近期最火的詞彙，不管是國外仍是國內。並且火爆程度遠超於想象。

全棧和 DevOps，到底是咱們的新職業方向，仍是僅僅創業公司老闆的心頭所愛？且聽本文理性分享。

Anyway，文末附贈 9 家把 DevOps 搞得風生水起的國外公司及更多信息。本文系 OneAPM 聯合高效運維編譯整理。

正文

最近有兩個特別討厭的趨勢：DevOps 和「全棧」開發者的思想。

時下，DevOps 已經很是流行，以致於討厭它就像討厭 x86 架構或單內核同樣，那麼到底是什麼形成了這樣的結果？讓我如此痛苦的根本緣由，又是什麼？

事實上，並非每家公司都是創業公司，但卻又要去表現得像創業公司同樣。

「DevOps」旨在表示密切合做，讓本來純粹的開發、運營和 QA 角色之間協做運轉。

由於軟件發佈的頻率愈來愈高，傳統的「瀑布型」開發—測試—發佈週期已經不能知足業務的需求，後果就是，開發者還必須爲測試和發佈的環境質量負責。

隨着「開發者」（這個詞是否恰當仍存爭議）的責任範圍不斷擴大的同時，綜合的全能型開發者需求也被觸發——「全棧」開發者。

這樣一來，開發者要既能作開發，還須要兼任 QA 團隊成員、業務分析師、系統管理員和 DBA 的工做。

那麼，DevOps 和「全棧」開發者，這些概念是從哪裏冒出來的呢？

固然是來自創業公司（和敏捷方法）：

不容否定的是：初創企業就像一種「蟄伏」的野獸，在最初的幾年每每默默無名，並且過的也很是艱辛（人員配備不齊，因此急需 DevOps 和「全棧」開發者）。

但不幸的是，當下 DevOps 這個潮流正在迫使開發者在一個成熟的公司中繼續扮演這些角色，迫使開發者擔任因爲基礎資源缺少而不得不爲的「開發者」角色。

身兼數職

想象你在一個只有七我的組成開發團隊的創業公司。花一年的時間去開發一個 Web 應用，各個項目都進展順利，可是這個過程絕對讓你混亂——若是有一個特別嚴重的問題出現，彷佛須要深度的數據庫知識。

這種情形下說：「這不是個人專長」這樣的話，或者將它交給 DBA 團隊進行調查顯然是不可行的。因爲資源限制，你不得不承擔 DBA 的角色，本身去解決問題。

如今，擴展這個場景到以前所列的角色下。在任什麼時候候，開發人員在一個初創企業可能會兼任開發者、QA 測試員、部署/業務分析師、系統管理員或 DBA。

這徹底由創業公司的性質所決定，而有些人在這樣的環境下能夠飛速成長。但一路走來，咱們不斷欺騙本身，由於在任什麼時候候，開發者都不得不身兼多職，甚至有時候要承擔全部角色。

即便這樣的人真的存在，「全棧」開發者仍然不會以正常的方式去工做。創業公司並不是只是想着開發者暫時短時間內擔任某個角色，而後過渡到下一個角色；相反，會要求你一直擔任全部的角色。

這真的很糟糕，這意味着，可能須要最優秀的開發者。

也談等級

優秀的開發者都是聰明人，這麼說可能會被不少人吐槽，然而在一個機構內，技術人員倒是存在多個不一樣的等級。開發者最高，接着是系統管理員和 DBA。「運營」人員、發佈管理員等角色處於最底層。

爲何這樣排序呢？

由於，如有必要，每一個角色都可以承擔低於這一層次所能作的全部工做。

這一點在創業公司已經獲得證明。在須要的狀況下，優秀的開發者能夠轉成合格的 DBA、不錯的測試員、「部署開發者」以及各類所需的角色。

他們的工做須要他們儘量的瞭解底層角色的工做範圍。但這存在着一個大的隱患——反之則不成立。

在緊要關頭，測試員卻幹不了開發者的活，也不能成爲構建開發者作 DBA 的工做。他們從未得到這些角色的專業知識。

舉個例子說得更清楚吧：

好比一名牙醫，他開了傢俬人診所，而後聘請了祕書、衛生員和牙醫助理等不少人員。通常狀況下，祕書能夠幫忙作預定，衛生員能夠幫助消毒，牙醫助理也能夠幫忙作一些基礎的工做，可是若是須要給牙齒鑽孔或者進行根部的治療時，就必須須要牙醫親自「出馬」，畢竟沒有專業的知識是絕對搞不定的，若是沒有專業的「牙醫」，即便是所有的「僱員」加起來，也搞不定這件事。

不管樂意與否，每一個組織都有層次結構，人們按不一樣技能和能力水平分類。因此，當你一昧要求開發者擔任其餘角色時，最後的結果多是：沒人能擔當得起開發者的角色。

如此運轉會損害全部人員，除了僱主。這場實驗本意是提升軟件質量，卻無心之間成了鬧劇，讓最有才華的員工過分工做（作了不少無用功），同時低層次的職位沒有存在感。

而這正是問題的癥結所在。全部最初由不一樣層次的人所擔任的崗位，都是由「全棧」開發者進行的。大型公司很是喜歡這一點，由於這意味着他們能夠僱用更少的人來作一樣的工做。

儘管在這個過程當中，實際開發成爲開發者的工做中很小的一部分。這就是爲何咱們看到這麼多的開發者沒法經過 FizzBuzz：

他們幾乎沒寫任何代碼。這個問題很是廣泛，你能想象一下面試一位廚師，問他天天有多少時間真的花在烹飪上？

博而不精

若是你是一箇中等規模軟件的開發者，你應該須要一個適當的部署系統。考考你，請立刻說出下述這些系統各自的優缺點：

Puppet、Chef、Salt、Ansible、 Vagrant 和 Docker。如今開始實現你的部署解決方案吧！你是否注意到以上系統有一項是徹底無關的嗎？

專業化是有緣由的：人們只能專一於有限的知識。任務切換無疑是昂貴的。強迫開發者承擔其餘角色意味着：

• 沒法專一開發
• 須要補充龐大的知識領域
• 不堪重負

更重要的是，經過迫使開發者承擔「全棧」責任，他們會支付其遠遠高於完成大部分工做的市場平均價格。

若是開發人員每一年掙 100K ，你能夠支付 4 個開發者每一年 100K 來作一兩我的的任務，50% 時間徹底作開發，剩下 50% 的時間作發佈管理。或者，只是僱一個發佈經理，花大約 75K，但兩個開發者全職開發。

注意一下兼職發佈管理的開發者在無需發佈時浪費了不少時間。

不要再扼殺開發者！

這樣作的效果是摧毀「開發者」這個角色，以一種「全能技術工人」來替代。

就筆者所知，每一個進入編程領域的開發者，都是由於他們實際上喜歡開發（或者一度喜歡）。當你強迫最聰明的人承擔額外角色時，其實傷害了全部人。

並不是全部公司都是創業公司。創業公司不得不讓開發者身兼多職，也有其必要性。可是請根據實際狀況進行判斷，你是否須要 DevOps。

推薦9個 DevOps 實踐公司

你可能知道 Netflix 和 Etsy 在 DevOps 領域的突出表現，可是下面的9個 DevOps 實踐公司卻可能讓你感到難以想象，咱們一塊兒來盤點下。

1. Starbucks

星巴克在2015年4月的 #DevOpsTogether 開始了其 DevOps 計劃。儘管「在一塊兒」已是個陳詞濫調，可是不用擔憂。從Medium.com這篇文章瞭解到，星巴克 CEO 很是支持 DevOps 理念，而且一直努力讓公司保持技術上的創新。

2. Ancestry.com

Ancestry.com 是 DevOps 運動的早期採用者，是 Continuous Delivery 和 DevOps 運動的先鋒。

早在2013年，這些流行的方法就對發佈次數和公司滿意度上有了顯著提高。想了解更多關於他們的過程、遷移和 DevOps 文化，不妨查看一下他們的系列文章。

3. Ashley Madison

沒人會以爲這是一個 DevSecOps 博客，儘管其數據庫被黑已經成爲 DevOps 安全的反面教材。冒着風險開始一個更大的話題，這個著名公司的失敗有助於闡明事實，也許 DevOps 並不總意味着更快和更常常。這裏有一些不錯的DevOps安全文章，僅供參考。

4. Etsy

Etsy 也在實踐 DevOps。Etsy 不只是一個超級酷的公司，專一於節日禮物，他們一樣也在努力的 DevOps。

2008年，他們看到了 Flickr 天天發佈10次部署，2009年，他們創建本身的工具來更好更快地發佈代碼，並且不只由開發團隊。「Etsy 如何應用 DevOps」絕對值得一讀，或者再看看他們的代碼。

5. U.S. Customs and Border Protection

這個確定是你想不到的！在司法部、海關、邊境保護署和美聯儲，美國政府異常活躍於採用 DevOps。

6. LinkedIn

LinkedIn 成爲一個大型的 DevOps 用戶不足爲奇。早在2009年，LinkedIn 團隊就開始使用自動化部署工具，用於管理在1000+節點環境下發布上千個應用/服務的複雜性。如今他們正在培養世界級的 DevOps 社區。看看這篇關於他們使用第一個工具的文章。

7. NASA

無論你是否知道 NASA 正在使用 DevOps，這都很是振奮人心。咱們最愛的方法可能正幫助人類登上火星，或許是有點誇張……或者也名副其實。不管哪一種方式，NASA 一直在思考軟件部署，自從2004年首先採用了 JIRA 後，他們已經抵達 DevOps 星球。

8. Apple

不要讓蘋果巨大的 IOS 更新，以及它重要的九月發佈季，讓你誤覺得他們放棄了技術創新的風口浪尖。儘管蘋果的 DevOps 尚未普遍使用，但他們正在尋找合適的工具，僱傭優秀的人才，來完善平常部署。

9. Airbnb

相似 Netflix 和 Uber，Airbnb 被認爲是一個「第三平臺公司」，由於他們利用社交、移動、分析和雲。做爲一個第三平臺公司，DevOps 需求不可避免，這便於迅速發佈多個小型部署。

若是你有興趣學習更多關於 Airbnb 的數據和基礎設施，能夠參考這個slides。

然而，是否每一個公司都須要緊跟這個潮流，Jeff Knupp 在 「How ‘DevOps’ is Killing the Developer 」一文中發表了他的觀點。

OneAPM 是應用性能管理領域的新興領軍企業，能幫助運維人員進行故障預警和定位，減小業務系統維護的工做量，同時還能提供可追溯的性能數據，量化運維部門的業務價值。想告別加班熬夜，歡迎免費註冊使用！