引言
全棧工程師（本文稱(chēng)「全?！归_(kāi)發(fā)者）和 DevOps 無(wú)疑是近期最火的詞匯，無(wú)論是國(guó)外還是國(guó)內(nèi)。而且火爆程度遠(yuǎn)超于想象。
全棧和 DevOps，究竟是我們的新職業(yè)方向，還是僅僅創(chuàng)業(yè)公司老板的心頭所愛(ài)？且聽(tīng)本文理性分享。
Anyway，文末附贈(zèng) 9 家把 DevOps 搞得風(fēng)生水起的國(guó)外公司及更多信息。本文系 OneAPM 聯(lián)合高效運(yùn)維編譯整理。
正文
最近有兩個(gè)特別討厭的趨勢(shì)：DevOps 和「全?！归_(kāi)發(fā)者的思想。
時(shí)下，DevOps 已經(jīng)非常流行，以至于討厭它就像討厭 x86 架構(gòu)或單內(nèi)核一樣，那么究竟是什么造成了這樣的結(jié)果？讓我如此痛苦的根本原因，又是什么？
事實(shí)上，并不是每家公司都是創(chuàng)業(yè)公司，但卻又要去表現(xiàn)得像創(chuàng)業(yè)公司一樣。
「DevOps」旨在表示密切合作，讓原本純粹的開(kāi)發(fā)、運(yùn)營(yíng)和 QA 角色之間協(xié)作運(yùn)轉(zhuǎn)。
因?yàn)檐浖l(fā)布的頻率越來(lái)越高，傳統(tǒng)的「瀑布型」開(kāi)發(fā)—測(cè)試—發(fā)布周期已經(jīng)不能滿(mǎn)足業(yè)務(wù)的需求，后果就是，開(kāi)發(fā)者還必須為測(cè)試和發(fā)布的環(huán)境質(zhì)量負(fù)責(zé)。
隨著「開(kāi)發(fā)者」（這個(gè)詞是否恰當(dāng)仍存爭(zhēng)議）的責(zé)任范圍不斷擴(kuò)大的同時(shí)，綜合的全能型開(kāi)發(fā)者需求也被觸發(fā)——「全?！归_(kāi)發(fā)者。
這樣一來(lái)，開(kāi)發(fā)者要既能做開(kāi)發(fā)，還需要兼任 QA 團(tuán)隊(duì)成員、業(yè)務(wù)分析師、系統(tǒng)管理員和 DBA 的工作。
那么，DevOps 和「全?！归_(kāi)發(fā)者，這些概念是從哪里冒出來(lái)的呢？
當(dāng)然是來(lái)自創(chuàng)業(yè)公司（和敏捷方法）：
不容否認(rèn)的是：初創(chuàng)企業(yè)就像一種「蟄伏」的野獸，在最初的幾年往往默默無(wú)名，而且過(guò)的也非常艱辛（人員配備不齊，所以急需 DevOps 和「全?！归_(kāi)發(fā)者）。
但不幸的是，當(dāng)下 DevOps 這個(gè)潮流正在迫使開(kāi)發(fā)者在一個(gè)成熟的公司中繼續(xù)扮演這些角色，迫使開(kāi)發(fā)者擔(dān)任由于基礎(chǔ)資源缺乏而不得不為的「開(kāi)發(fā)者」角色。
身兼數(shù)職
想象你在一個(gè)只有七個(gè)人組成開(kāi)發(fā)團(tuán)隊(duì)的創(chuàng)業(yè)公司。花一年的時(shí)間去開(kāi)發(fā)一個(gè) Web 應(yīng)用，各個(gè)項(xiàng)目都進(jìn)展順利，但是這個(gè)過(guò)程絕對(duì)讓你混亂——如果有一個(gè)特別嚴(yán)重的問(wèn)題出現(xiàn)，似乎需要深度的數(shù)據(jù)庫(kù)知識(shí)。
這種情形下說(shuō)：「這不是我的專(zhuān)長(zhǎng)」這樣的話(huà)，或者將它交給 DBA 團(tuán)隊(duì)進(jìn)行調(diào)查顯然是不可行的。由于資源限制，你不得不承擔(dān) DBA 的角色，自己去解決問(wèn)題。
現(xiàn)在，擴(kuò)展這個(gè)場(chǎng)景到之前所列的角色下。在任何時(shí)候，開(kāi)發(fā)人員在一個(gè)初創(chuàng)企業(yè)可能會(huì)兼任開(kāi)發(fā)者、QA 測(cè)試員、部署/業(yè)務(wù)分析師、系統(tǒng)管理員或 DBA。
這完全由創(chuàng)業(yè)公司的性質(zhì)所決定，而有些人在這樣的環(huán)境下可以飛速成長(zhǎng)。但一路走來(lái)，我們不斷欺騙自己，因?yàn)樵谌魏螘r(shí)候，開(kāi)發(fā)者都不得不身兼多職，甚至有時(shí)候要承擔(dān)所有角色。
即使這樣的人真的存在，「全?！归_(kāi)發(fā)者仍然不會(huì)以正常的方式去工作。創(chuàng)業(yè)公司并非只是想著開(kāi)發(fā)者暫時(shí)短期內(nèi)擔(dān)任某個(gè)角色，然后過(guò)渡到下一個(gè)角色；相反，會(huì)要求你一直擔(dān)任所有的角色。
這真的很糟糕，這意味著，可能需要最優(yōu)秀的開(kāi)發(fā)者。
也談等級(jí)
優(yōu)秀的開(kāi)發(fā)者都是聰明人，這么說(shuō)可能會(huì)被很多人吐槽，然而在一個(gè)機(jī)構(gòu)內(nèi)，技術(shù)人員卻是存在多個(gè)不同的等級(jí)。開(kāi)發(fā)者最高，接著是系統(tǒng)管理員和 DBA?！高\(yùn)營(yíng)」人員、發(fā)布管理員等角色處于最底層。
為什么這樣排序呢？
因?yàn)?，若有必要，每個(gè)角色都能夠承擔(dān)低于這一層次所能做的所有工作。
這一點(diǎn)在創(chuàng)業(yè)公司已經(jīng)得到證實(shí)。在需要的情況下，優(yōu)秀的開(kāi)發(fā)者可以轉(zhuǎn)成合格的 DBA、不錯(cuò)的測(cè)試員、「部署開(kāi)發(fā)者」以及各種所需的角色。
他們的工作需要他們盡可能的了解底層角色的工作范圍。但這存在著一個(gè)大的隱患——反之則不成立。
在緊要關(guān)頭，測(cè)試員卻干不了開(kāi)發(fā)者的活，也不能成為構(gòu)建開(kāi)發(fā)者做 DBA 的工作。他們從未獲得這些角色的專(zhuān)業(yè)知識(shí)。
舉個(gè)例子說(shuō)得更清楚吧：
比如一名牙醫(yī)，他開(kāi)了家私人診所，然后聘請(qǐng)了秘書(shū)、衛(wèi)生員和牙醫(yī)助理等很多人員。一般情況下，秘書(shū)可以幫忙做預(yù)約，衛(wèi)生員可以幫助消毒，牙醫(yī)助理也可以幫忙做一些基礎(chǔ)的工作，但是如果需要給牙齒鉆孔或者進(jìn)行根部的治療時(shí)，就必須需要牙醫(yī)親自「出馬」，畢竟沒(méi)有專(zhuān)業(yè)的知識(shí)是絕對(duì)搞不定的，如果沒(méi)有專(zhuān)業(yè)的「牙醫(yī)」，即使是全部的“雇員”加起來(lái)，也搞不定這件事。
無(wú)論樂(lè)意與否，每個(gè)組織都有層次結(jié)構(gòu)，人們按不同技能和能力水平分類(lèi)。所以，當(dāng)你一昧要求開(kāi)發(fā)者擔(dān)任其他角色時(shí)，最后的結(jié)果可能是：沒(méi)人能擔(dān)當(dāng)?shù)闷痖_(kāi)發(fā)者的角色。
如此運(yùn)轉(zhuǎn)會(huì)損害所有人員，除了雇主。這場(chǎng)實(shí)驗(yàn)本意是提高軟件質(zhì)量，卻無(wú)意之間成了鬧劇，讓最有才華的員工過(guò)度工作（做了很多無(wú)用功），同時(shí)低層次的職位沒(méi)有存在感。
而這正是問(wèn)題的癥結(jié)所在。所有最初由不同層次的人所擔(dān)任的崗位，都是由「全?！归_(kāi)發(fā)者進(jìn)行的。大型公司非常喜歡這一點(diǎn)，因?yàn)檫@意味著他們可以雇用更少的人來(lái)做同樣的工作。
盡管在這個(gè)過(guò)程中，實(shí)際開(kāi)發(fā)成為開(kāi)發(fā)者的工作中很小的一部分。這就是為什么我們看到這么多的開(kāi)發(fā)者無(wú)法通過(guò) FizzBuzz：
他們幾乎沒(méi)寫(xiě)任何代碼。這個(gè)問(wèn)題非常普遍，你能想象一下面試一位廚師，問(wèn)他每天有多少時(shí)間真的花在烹飪上？
博而不精
如果你是一個(gè)中等規(guī)模軟件的開(kāi)發(fā)者，你應(yīng)該需要一個(gè)適當(dāng)?shù)牟渴鹣到y(tǒng)?？伎寄?，請(qǐng)馬上說(shuō)出下述這些系統(tǒng)各自的優(yōu)缺點(diǎn)：
Puppet、Chef、Salt、Ansible、 Vagrant 和 Docker?，F(xiàn)在開(kāi)始實(shí)現(xiàn)你的部署解決方案吧！你是否注意到以上系統(tǒng)有一項(xiàng)是完全無(wú)關(guān)的嗎？
專(zhuān)業(yè)化是有原因的：人們只能專(zhuān)注于有限的知識(shí)。任務(wù)切換無(wú)疑是昂貴的。強(qiáng)迫開(kāi)發(fā)者承擔(dān)其他角色意味著：
- 無(wú)法專(zhuān)注開(kāi)發(fā)
- 需要補(bǔ)充龐大的知識(shí)領(lǐng)域
- 不堪重負(fù)
更重要的是，通過(guò)迫使開(kāi)發(fā)者承擔(dān)「全?！关?zé)任，他們會(huì)支付其遠(yuǎn)遠(yuǎn)高于完成大部分工作的市場(chǎng)平均價(jià)格。
如果開(kāi)發(fā)人員每年掙 100K ，你可以支付 4 個(gè)開(kāi)發(fā)者每年 100K 來(lái)做一兩個(gè)人的任務(wù)，50% 時(shí)間完全做開(kāi)發(fā)，剩下 50% 的時(shí)間做發(fā)布管理?；蛘撸皇枪鸵粋€(gè)發(fā)布經(jīng)理，花大約 75K，但兩個(gè)開(kāi)發(fā)者全職開(kāi)發(fā)。
注意一下兼職發(fā)布管理的開(kāi)發(fā)者在無(wú)需發(fā)布時(shí)浪費(fèi)了很多時(shí)間。
不要再扼殺開(kāi)發(fā)者！
這樣做的效果是摧毀「開(kāi)發(fā)者」這個(gè)角色，以一種「全能技術(shù)工人」來(lái)替代。
就筆者所知，每個(gè)進(jìn)入編程領(lǐng)域的開(kāi)發(fā)者，都是因?yàn)樗麄儗?shí)際上喜歡開(kāi)發(fā)（或者一度喜歡）。當(dāng)你強(qiáng)迫最聰明的人承擔(dān)額外角色時(shí)，其實(shí)傷害了所有人。
并非所有公司都是創(chuàng)業(yè)公司。創(chuàng)業(yè)公司不得不讓開(kāi)發(fā)者身兼多職，也有其必要性。但是請(qǐng)根據(jù)實(shí)際情況進(jìn)行判斷，你是否需要 DevOps。
推薦9個(gè) DevOps 實(shí)踐公司
你可能知道 Netflix 和 Etsy 在 DevOps 領(lǐng)域的突出表現(xiàn)，但是下面的9個(gè) DevOps 實(shí)踐公司卻可能讓你感到不可思議，我們一起來(lái)盤(pán)點(diǎn)下。
1. Starbucks
星巴克在2015年4月的 #DevOpsTogether 開(kāi)始了其 DevOps 計(jì)劃。盡管「在一起」已經(jīng)是個(gè)陳詞濫調(diào)，但是不用擔(dān)心。從Medium.com這篇文章了解到，星巴克 CEO 非常支持 DevOps 理念，并且一直努力讓公司保持技術(shù)上的創(chuàng)新。
2. Ancestry.com
Ancestry.com 是 DevOps 運(yùn)動(dòng)的早期采用者，是 Continuous Delivery 和 DevOps 運(yùn)動(dòng)的先鋒。
早在2013年，這些流行的方法就對(duì)發(fā)布次數(shù)和公司滿(mǎn)意度上有了顯著提升。想了解更多關(guān)于他們的過(guò)程、遷移和 DevOps 文化，不妨查看一下他們的系列文章。
3. Ashley Madison
沒(méi)人會(huì)覺(jué)得這是一個(gè) DevSecOps 博客，盡管其數(shù)據(jù)庫(kù)被黑已經(jīng)成為 DevOps 安全的反面教材。冒著風(fēng)險(xiǎn)開(kāi)始一個(gè)更大的話(huà)題，這個(gè)著名公司的失敗有助于闡明事實(shí)，也許 DevOps 并不總意味著更快和更經(jīng)常。這里有一些不錯(cuò)的DevOps安全文章，僅供參考。
4. Etsy
Etsy 也在實(shí)踐 DevOps。Etsy 不僅是一個(gè)超級(jí)酷的公司，專(zhuān)注于節(jié)日禮物，他們同樣也在努力的 DevOps。
2008年，他們看到了 Flickr 每天發(fā)布10次部署，2009年，他們建立自己的工具來(lái)更好更快地發(fā)布代碼，而且不僅由開(kāi)發(fā)團(tuán)隊(duì)。「Etsy 如何應(yīng)用 DevOps」絕對(duì)值得一讀，或者再看看他們的代碼。
5. U.S. Customs and Border Protection
這個(gè)肯定是你想不到的！在司法部、海關(guān)、邊境保護(hù)署和美聯(lián)儲(chǔ)，美國(guó)政府異?；钴S于采用 DevOps。
6. LinkedIn
LinkedIn 成為一個(gè)大型的 DevOps 用戶(hù)不足為奇。早在2009年，LinkedIn 團(tuán)隊(duì)就開(kāi)始使用自動(dòng)化部署工具，用于管理在1000+節(jié)點(diǎn)環(huán)境下發(fā)布上千個(gè)應(yīng)用/服務(wù)的復(fù)雜性。現(xiàn)在他們正在培養(yǎng)世界級(jí)的 DevOps 社區(qū)。看看這篇關(guān)于他們使用第一個(gè)工具的文章。
7. NASA
不管你是否知道 NASA 正在使用 DevOps，這都非常振奮人心。我們最?lèi)?ài)的方法可能正幫助人類(lèi)登上火星，或許是有點(diǎn)夸張……或者也名副其實(shí)。無(wú)論哪種方式，NASA 一直在思考軟件部署，自從2004年首先采用了 JIRA 后，他們已經(jīng)抵達(dá) DevOps 星球。
8. Apple
不要讓蘋(píng)果巨大的 IOS 更新，以及它重要的九月發(fā)布季，讓你誤以為他們放棄了技術(shù)創(chuàng)新的風(fēng)口浪尖。盡管蘋(píng)果的 DevOps 還沒(méi)有廣泛使用，但他們正在尋找合適的工具，雇傭優(yōu)秀的人才，來(lái)完善日常部署。
9. Airbnb
類(lèi)似 Netflix 和 Uber，Airbnb 被認(rèn)為是一個(gè)「第三平臺(tái)公司」，因?yàn)樗麄兝蒙缃弧⒁苿?dòng)、分析和云。作為一個(gè)第三平臺(tái)公司，DevOps 需求不可避免，這便于迅速發(fā)布多個(gè)小型部署。
如果你有興趣學(xué)習(xí)更多關(guān)于 Airbnb 的數(shù)據(jù)和基礎(chǔ)設(shè)施，可以參考這個(gè)slides。
然而，是否每個(gè)公司都需要緊跟這個(gè)潮流，Jeff Knupp 在 「How ‘DevOps’ is Killing the Developer 」一文中發(fā)表了他的觀點(diǎn)。
OneAPM 是應(yīng)用性能管理領(lǐng)域的新興領(lǐng)軍企業(yè)，能幫助運(yùn)維人員進(jìn)行故障預(yù)警和定位，減少業(yè)務(wù)系統(tǒng)維護(hù)的工作量，同時(shí)還能提供可追溯的性能數(shù)據(jù)，量化運(yùn)維部門(mén)的業(yè)務(wù)價(jià)值。想告別加班熬夜，歡迎免費(fèi)注冊(cè)使用！
