DevOps工程師成長秘籍
DevOps一詞的來自於Development和Operations的組合，其概念早先升溫於2009年的歐洲，因傳統模式的運維之痛而生。
前幾天偶然間看到阿里巴巴在高薪招聘DevOps工程師：
那麼，什麼是DevOps工程師呢，如何才能成為一個成功的DevOps工程師呢？
1
首先，我們來看一下DevOps是什麼。
DevOps一詞的來自於Development和Operations的組合，其概念早先升溫於2009年的歐洲，因傳統模式的運維之痛而生。
DevOps是為了填補開發端和運維端之間的信息鴻溝，從而改善團隊之間的協作關係。不過需要澄清的一點是，從開發到運維，中間還有測試環節。DevOps其實包含了三個部分：開發、測試和運維。
Advertisements
DevOps突出重視軟體開發人員和運維人員的溝通合作，通過自動化流程來使得軟體構建、測試、發布更加快捷、頻繁和可靠。
換句話說，DevOps希望做到的是軟體產品交付過程中IT工具鏈的打通，使得各個團隊減少時間損耗，更加高效地協同工作。
2
DevOps的好處
DevOps的一個巨大好處就是可以高效交付，這也正好是它的初衷。Puppet與 DevOps研究與評估（以下簡稱 DORA）協會主辦的2016年DevOps調查報告中，根據全球4600位各IT公司的技術工作者的提交數據統計得出結論：高效公司平均每年可以完成1460次部署。與低效組織相比，高效組織的部署頻繁200倍，產品投入使用速度快2555倍，服務恢復速度快24倍。
Advertisements
在工作內容的時間分配上，低效者要多花22%的時間用在為規劃好或者重複工作上，而高效者卻可以多花29%的時間用在新的工作上。所以這裡的高效不僅僅指公司產出的效率提高，還指員工的工作質量得到提升。
DevOps另外一個好處就是會改善公司組織文化、提高員工的參與感。員工們變得更高效，也更有滿足和成就感；調查顯示高效員工的僱員凈推薦值（eNPS:employee Net Promoter Score）更高，即對公司更加認同。
對於工程師而言，他們也是DevOps的受益者。微軟資深工程師Scott Hanselman說過「對於開發者而言，最有力的工具就是自動化工具」（The most powerful tool we have as developers is automation）。工具鏈的打通使得開發者們在交付軟體時可以完成生產環境的構建、測試和運行；正如Amazon的VP兼CTO Werner Vogels那句讓人印象深刻的話：「誰開發誰運行」。（You build it, you run it）
3
DevOps的現狀
目前在國外，互聯網巨頭如Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb，傳統軟體公司如Adobe、IBM、Microsoft、SAP等，亦或是網路業務非核心企業如蘋果、沃爾瑪、索尼影視娛樂、星巴克等都在採用DevOps或提供相關支持產品。
其實DevOps早在九年前就有人提出來，但是，這兩年才開始受到越來越多的企業重視和實踐。DORA 發布的最新《DevOps現狀調查報告（State of DevOps）》發現，最近幾年 DevOps團隊的人員規模都保持著持續上漲。三年之前，只有 16%的受訪者身為 DevOps團隊成員，但如今這一比例幾乎翻了一番（達到 27%）。
根據國外一項調查表明，在2016年，74%的受訪者已經接受了DevOps，而2015年這一比例為66%；另外，在大企業中已經有81%開始接受DevOps：
4
為什麼DevOps近兩年才得以重視？
因為DevOps的發展是獨木不成林的，而現在有越來越多的技術支撐。微服務架構理念、容器技術使得DevOps的實施變得更加容易，計算能力提升和雲環境的發展使得快速開發的產品可以立刻獲得更廣泛的使用。技術的發展使得DevOps有了更多的配合。
早期時，大家雖然意識到了這個問題的，但是苦於當時沒有完善豐富的技術工具，是一種「理想很豐滿，但是現實很骨感」的情況。DevOps的實現可以基於新興的容器技術，也可以在自動化運維工具Puppet、SaltStack、Ansible之後的延伸，還可以構建在傳統的Cloud Foundry、OpenShift等PaaS廠商之上。
事實上，DevOps正在成為 IT行業的新標準，並且已經被業界廣泛採納，常見於雲計算和容器技術。
同時，許多組織正儘力去理解 DevOps的全貌，這主要受限於他們專業知識上的缺乏和各種組織結構上的挑戰。儘管面臨這些挑戰，DevOps還是漸漸成為一個主流運動，各個公司已經注意到DevOps加速發布的無限價值潛力：誰創新速度最快，誰頻繁更新…誰就可能打通創新的任督二脈。DevOps正在改變著 IT組織發布軟體的方式，這就像敏捷運動在過去十多年中所產生的影響。
5
DevOps工程師
現在，我們可以來看一下什麼是DevOps工程師了。
採用DevOps的主要意圖是在開發和運營團隊之間建立更好的工作關係。有些建議是將團隊安排在一起，將他們包含在彼此的流程和工作流程中，甚至創建一個能夠完成任務的跨職能團隊。不過在這種方式中，Dev仍然是Dev，Ops仍然是Ops。
DevOps工程師一詞試圖將Dev與Ops之間的差距模糊起來，並表示最好的方法是請一些可以搞定Dev角色以及處理所有Ops職能的工程師。簡而言之，DevOps工程師可以是開發，主要是他們能通過運營的心態思考問題並具有以下技能：
1. 熟練使用各種操作和自動化工具的經驗；2. 強大的腳本能力；3. 在頻繁測試和增量的時候從容不迫；4. 了解Ops問題的來龍去脈，能在源頭杜絕問題擴散；5. 技能和邏輯相對開發更全面，讓團隊更好的協作。
亞馬遜CTO Werner Vogels認為：
把運營的責任和職能放在開發身上，從客戶和技術的角度，大大提高了服務質量和包容度。傳統模式只是把包帶到部門牆就甩手不管了。我認為最好的方式是誰建立，誰運行……開發接觸到運營，也帶來了與客戶的日常聯繫。這個客戶反饋循環對於提高服務質量非常重要。
Dev遷移到DevOps角色比以往任何時候都容易。交付自動化日益改善，DevOps平台通過最少的腳本輕鬆就能實現自動化。
Ops工程師能否遷移到DevOps角色？當然！但相對開發可能挑戰更大一些，因為轉換之前，嚴謹的編碼技巧也得學習學習。不過編碼啟動陣營的變化，這可能相比幾年前更容易過渡一些。
開門見山，成為DevOps工程師的關鍵是關注以下幾點。
1、零觸摸式的自動化
你應該深刻了解下自動化，諸如基礎設施配置，CI/CD管道，發布管理，安全補丁甚至客戶反饋等所有內容的想法……這些可以讓組織創新腳步更快：免去手工切換，並在引入后立即追蹤並修復錯誤。
在這裡就可以開始適度增加版本更新周期並獲得客戶的快速反饋，從而幫助您更快地改善產品和響應市場需求。這步可以帶著你一直走向DevOps的最終涅磐。
DevOps交付管道的完全自動化，多去找找相關開源方案學習精髓之處吧，本文沒什麼捷徑提供。 2、寬容度高的行動心態
開發在設計軟體時多走一步，考慮一些常見的操作陷阱。這個環節如果開發環節就能注意到，那就非常好了，而不是遇到問題，然後才修復。
嘗試通過創建一個作為設計評估模板一部分的清單來標準化這類過程。Microsoft有部分團隊就總結了一些清單，其中考慮了部署和基礎架構的要求。
堅信團結的力量。鼓勵通過團建，跨團體遊戲之類的形式相互認識。長久以往，可能會發現Slack渠道的溝通也不那麼麻煩了，對每個人都開放包容，有助於更好地理解和對交叉團隊的問題感同身受。
如何衡量DevOps的成功？
最終，您所有的努力都要轉化為更快創新的業務目標。
DevOps策略成功的一些關鍵指標如下。
部署頻率——部署到生產要多久？通過自動化，你可以隨著每一個變化的生產進行持續部署。這是一個到達過程，每天至少一次作為目標並沒有什麼不妥。
代碼更改的交付時間——將代碼更改部署到生產中需要多久？這將衡量自動化管道的效率。目標：建議是不到30分鐘，最好再結合自己實際情況調整。
回滾率——出錯回滾頻繁嗎？這很可能意味著自動化流程需要改進，因為DevOps的整個目標是創建可預測且無錯誤的版本。如果回滾率高，那至少得提高回滾速度。這個是快速恢復的一個基本能力，把對業務的影響降到最低。
寫在最後
真正意義上的DevOps工程師難找，這塊目前為止還是個不斷發展的領域。說得諷刺些，許多為這些角色做背書的公司也並不知道DevOps具體是怎麼回事。所以萬一你被聘成了DevOps工程師，那你就得用這個聘請理由驅動手頭的事情做出改變，說的大白話一些，你得讓DevOps落地跑起來。