榮譽,還是苦逼?| 也議全棧工程師和DevOps

OneAPM官方技術部落格發表於2015-10-16

引言

全棧工程師(本文稱「全棧」開發者)和 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 是應用效能管理領域的新興領軍企業,能幫助運維人員進行故障預警和定位,減少業務系統維護的工作量,同時還能提供可追溯的效能資料,量化運維部門的業務價值。想告別加班熬夜,歡迎免費註冊使用!

相關文章