柚子快報激活碼778899分享：DevOps 的起源

http://yzkb.51969.com/

注：機(jī)翻，未校。

The Origins of DevOps: What’s in a Name?

As DevOps prepares for its second decade of existence, it might be worth a stroll down memory lane to revisit the origins of DevOps methods—and even the term itself. 隨著DevOps為其存在的第二個十年做準(zhǔn)備，可能值得沿著記憶之路漫步，重新審視DevOps方法的起源，甚至是這個術(shù)語本身。

Pre-2007: A Perfect Storm of Events 2007年之前：一場完美的事件風(fēng)暴

Prior to 2007, a series of circumstances came together that would eventually give birth to what we know today as DevOps. 在 2007 年之前，一系列情況匯集在一起，最終誕生了我們今天所知道的 DevOps。

“Lean manufacturing” was already well-established as a set of best practices for manufacturing. Often branded as the “Toyota Manufacturing Method,” lean manufacturing strives for process optimization across the manufacturing floor. (Sidebar: Toyota leaders were originally inspired by the ingenious assembly line methods introduced by Ford Motor Company.) “Continuous improvement” is the mantra for lean manufacturing and practitioners continually evaluate ways to: “精益生產(chǎn)”已經(jīng)作為一套制造業(yè)的最佳實(shí)踐得到了廣泛的認(rèn)可。精益制造通常被稱為“豐田制造方法”，致力于在整個制造車間進(jìn)行流程優(yōu)化。（側(cè)邊欄：豐田的領(lǐng)導(dǎo)者最初受到福特汽車公司推出的巧妙裝配線方法的啟發(fā)?！俺掷m(xù)改進(jìn)”是精益生產(chǎn)的口號，從業(yè)者不斷評估以下方法：

Keep inventory at a minimum. Lean manufacturing means minimal inventory on hand: raw materials (materials used to produce goods) and finished inventory (completed products waiting to be assigned to an order and/or shipped). 將庫存保持在最低限度。精益生產(chǎn)意味著手頭的庫存最少：原材料（用于生產(chǎn)商品的材料）和成品庫存（等待分配給訂單和/或發(fā)貨的已完成產(chǎn)品）。Minimize the queue of orders. Ideally, orders received should move immediately into fulfillment mode. A key metric of lean manufacturing will always be “order to ship” time. 最小化訂單隊列。理想情況下，收到的訂單應(yīng)立即進(jìn)入履行模式。精益生產(chǎn)的一個關(guān)鍵指標(biāo)始終是“從訂單到發(fā)貨”的時間。Maximize efficiency in the manufacturing process. Process re-engineering and improved automation will marry into a goal to produce goods as quickly as possible. Each station of operation along the way (cut, weld, assemble, test, etc.) is evaluated for inefficiencies. 最大限度地提高制造過程中的效率。流程再造和自動化程度的提高將實(shí)現(xiàn)一個目標(biāo)，即盡快生產(chǎn)產(chǎn)品。沿途的每個操作站（切割、焊接、組裝、測試等）都經(jīng)過評估，以確定是否存在效率低下。

In IT, traditional waterfall methods of application development were already giving way to rapid, iterative methods such as agile. “Speed” was the battle cry, even if quality output was occasionally compromised in the pursuit of rapid development and deployment. Similarly, on the operations and infrastructure side of IT, Cloud Computing and, in particular, infrastructure as a service (IaaS) and platform as a service (PaaS) were coming into their own as mature service offerings. 在 IT 領(lǐng)域，傳統(tǒng)的瀑布式應(yīng)用程序開發(fā)方法已經(jīng)被敏捷等快速迭代方法所取代?！八俣取笔菓?zhàn)斗口號，即使在追求快速開發(fā)和部署的過程中，質(zhì)量輸出偶爾會受到影響。同樣，在IT的運(yùn)營和基礎(chǔ)設(shè)施方面，云計算，特別是基礎(chǔ)設(shè)施即服務(wù)（IaaS）和平臺即服務(wù)（PaaS）正在成為成熟的服務(wù)產(chǎn)品。

Finally, a fledgling set of tools classified as “continuous integration (CI)” tools began to emerge. The notion of CI tools was birthed and branded by Grady Brooch back in 1991 in his Brooch Method. 最后，一套被歸類為“持續(xù)集成（CI）”工具的新興工具開始出現(xiàn)。CI 工具的概念是由 Grady Brooch 于 1991 年在他的 Brooch Method 中誕生并打上烙印的。

2007-2008: A Frustrated Belgian 2007-2008： 一個沮喪的比利時人

Belgian consultant, project manager and agile practitioner Patrick Debois took on an assignment with a Belgian government ministry to help with data center migrations. In particular, his role was in certification/readiness testing. His duties required him to straddle activities and relationships between the application development teams and the operations teams (server, database network). His experiences—and frustrations over the walls of separation and lack of cohesion between application methods and infrastructure methods—planted seeds of discontent for Debois. His desire for a better way would soon lead him to action. 比利時顧問、項(xiàng)目經(jīng)理和敏捷實(shí)踐者 Patrick Debois 在比利時政府部門接受了一項(xiàng)任務(wù)，幫助進(jìn)行數(shù)據(jù)中心遷移。具體而言，他的角色是認(rèn)證/準(zhǔn)備測試。他的職責(zé)要求他跨越應(yīng)用程序開發(fā)團(tuán)隊和運(yùn)營團(tuán)隊（服務(wù)器、數(shù)據(jù)庫網(wǎng)絡(luò)）之間的活動和關(guān)系。他的經(jīng)歷——以及對應(yīng)用方法和基礎(chǔ)設(shè)施方法之間缺乏凝聚力的隔離墻的挫敗感——為 Debois 埋下了不滿的種子。他對更好方法的渴望很快導(dǎo)致他采取行動。

In 2008, at the Agile Conference in Toronto, Andrew Schafer posted an offer to moderate an ad hoc “Birds of a Feather” meeting to discuss the topic of “Agile Infrastructure.” Only one person showed up to discuss the topic: Patrick Debois. Their discussions and sharing of ideas with others advanced the concept of “agile systems administration.” In that same year, Debois and Shafer formed an Agile Systems Administrator group on Google, with limited success. 2008 年，在多倫多的敏捷大會上，Andrew Schafer 提出了一個提議，希望他能主持一個臨時的“Birds of a Feather”會議，討論“敏捷基礎(chǔ)設(shè)施”這個話題。只有一個人來討論這個話題：帕特里克·德布瓦。他們與他人的討論和分享想法，推動了“敏捷系統(tǒng)管理”的概念。同年，Debois 和 Shafer 在 Google 上成立了一個敏捷系統(tǒng)管理員小組，但收效甚微。

2009: The Case for Dev and Ops Cooperation 2009 年：開發(fā)和運(yùn)營合作的案例

At the O’Reilly Velocity Conference, two Flickr employees—John Allspaw, senior vice president of technical operations, and Paul Hammond, director of engineering—gave a now-famous presentation titled, “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.” The presentation had a dramatic flair to it, as Allspaw and Hammond would role-play the contentious interplay between representatives of Development and Operations during a typical software deployment, along with all the finger-pointing/blame that goes on, such as, “It’s not my code, it’s your machines!” Their presentation made the case that the only rational way forward is for application development and operations activities to be seamless, transparent and fully integrated. Over time, this presentation has reached legendary status, and is historically viewed as the seminal moment in time for that called out to the IT industry for methods that we now know as DevOps. 在 O’Reilly Velocity 大會上，兩位 Flickr 員工——技術(shù)運(yùn)營高級副總裁 John Allspaw 和工程總監(jiān) Paul Hammond——做了一場現(xiàn)在著名的演講，題為“每天 10+ 次部署：Flickr 的開發(fā)和運(yùn)營合作”。這個演講有一種戲劇性的氣息，因?yàn)锳llspaw和Hammond將扮演一個典型的軟件部署過程中開發(fā)和運(yùn)營代表之間有爭議的相互作用，以及所有的指責(zé)/責(zé)備，例如，“這不是我的代碼，這是你的機(jī)器！他們的介紹表明，唯一合理的前進(jìn)道路是使應(yīng)用程序開發(fā)和運(yùn)營活動無縫、透明和完全集成。隨著時間的流逝，這個演講已經(jīng)達(dá)到了傳奇的地位，并且在歷史上被視為一個開創(chuàng)性的時刻，它呼吁IT行業(yè)采用我們現(xiàn)在所知的DevOps方法。

Unable to attend in person, Debois watched the Allspaw/Hammond presentation by video stream. He was inspired, and—at the prompting of others through social media—formed his own conference called Devopsdays in Ghent, Belgium. By this point in time, the term “DevOps” had officially landed in the history books. 由于無法親自參加，Debois 通過視頻流觀看了 Allspaw/Hammond 的演講。他受到啟發(fā)，在其他人通過社交媒體的推動下，在比利時根特成立了自己的會議，名為Devopsdays。至此，“DevOps”一詞已正式載入史冊。

2010: DevOps in the United States 2010 年：美國的 DevOps

With a growing constituency, a Devopsdays conference is held for the first time in the United States in Mountain View, California, on the heels of the Velocity annual conference. Fast forward to 2018: There are more than 30 Devopsdays conferences already scheduled for 2018, including dozens across the United States. 隨著選區(qū)的不斷壯大，在Velocity年會之后，Devopsdays會議首次在美國加利福尼亞州山景城舉行?？爝M(jìn)到 2018 年：2018 年已經(jīng)安排了 30 多場 Devopsdays 會議，其中包括美國各地的數(shù)十場。

2013: ‘The Phoenix Project’ 2013年：《鳳凰計劃》

For many of us, another noteworthy moment in the history of DevOps was the publishing of the book, “The Phoenix Project,” written by Gene Kim, Kevin Behr and George Spafford. This fictional novel tells the story of an IT manager thrust into a seemingly hopeless situation, as he’s charged with salvaging a mission-critical ecommerce development project that’s gone off the rails. His mysterious mentor, a board member steeped in the disciplines of lean manufacturing, guides the main character into new ways of thinking about IT and application development, introducing the concept of DevOps along the way. 對于我們中的許多人來說，DevOps歷史上另一個值得注意的時刻是由Gene Kim、Kevin Behr和George Spafford撰寫的《鳳凰計劃》一書的出版。這部虛構(gòu)的小說講述了一名 IT 經(jīng)理陷入看似絕望的境地的故事，因?yàn)樗恢缚赝炀纫粋€偏離軌道的關(guān)鍵任務(wù)電子商務(wù)開發(fā)項(xiàng)目。他的神秘導(dǎo)師是一位深諳精益制造學(xué)科的董事會成員，他引導(dǎo)主角采用新的思維方式來看待 IT 和應(yīng)用程序開發(fā)，并在此過程中引入 DevOps 的概念。

(Sidebar: The Phoenix Project helped inspire us to write “Outsource or Else!” a similar business fable in which a VP of Software uses DevOps when outsourcing development of a major new product.) （側(cè)邊欄：鳳凰項(xiàng)目激發(fā)了我們寫“外包否則！”的靈感，這是一個類似的商業(yè)寓言，其中軟件副總裁在外包主要新產(chǎn)品的開發(fā)時使用DevOps。

DevOps for the Future 面向未來的 DevOps

It’s reasonable to describe DevOps as a journey, or perhaps an aspiration, rather than defined destination. DevOps, like lean manufacturing, seeks continuous improvement, seeking higher output, greater efficiencies and even continuous deployment. Automated tools that support DevOps continue to evolve. 將DevOps描述為一個旅程，或者可能是一個愿望，而不是定義的目的地，這是合理的。DevOps和精益制造一樣，追求持續(xù)改進(jìn)，追求更高的產(chǎn)出、更高的效率，甚至持續(xù)部署。支持 DevOps 的自動化工具不斷發(fā)展。

Much has been accomplished since the inception of DevOps in the last decade and we expect to see even more in 2018 and beyond. 自DevOps成立以來，在過去十年中已經(jīng)取得了很多成就，我們預(yù)計在2018年及以后將看到更多。

— Steve Mezak

via：

The Origins of DevOps: What’s in a Name? - DevOps.com By: Steve Mezak on January 25, 2018 https://devops.com/the-origins-of-devops-whats-in-a-name/

什么是 DevOps？看這一篇就夠了！

本文作者：Daniel Hu

一、前因

我是一個 “DevOps 工程師”，于是總會遇到有人問我：“什么是 DevOps？”

這個問題看似特別基礎(chǔ)，基礎(chǔ)到很多人懶得回答。但其實(shí)冷靜一秒，問自己一句 “什么是 DevOps？” 可能每個 DevOps 工程師都知道 “什么是 DevOps”，但是他們給出的答案不盡相同。

所以我會怎么回答這個呢？下面我們展開來聊聊。

特別強(qiáng)調(diào)：本文僅代表我個人現(xiàn)階段的粗淺認(rèn)知，本文觀點(diǎn)不代表 思碼逸 公司也不代表 DevStream 團(tuán)隊。

二、記憶

我第一次看到 DevOps 這個詞，大概是在 2016 年的秋天。那時候我在 H3C 從事云計算研發(fā)相關(guān)工作。記得我接到的第一個任務(wù)是研究 OpenStack 的一個 CICD 相關(guān)的組件，叫做 Solum，那是我第一次知道什么是 CICD，第一次看到 DevOps 這個詞。沒錯，只是看到 DevOps，但是我無法記住 DevOps 的定義?；蛘哒f，當(dāng)時我甚至沒有找到一個清晰易懂的關(guān)于 DevOps 的定義。可能很多人和我當(dāng)年一樣，對 DevOps 的印象，就是Dev + Ops。

2018 年的夏天，我開始在太保成研任云平臺 PaaS 組負(fù)責(zé)人，兼任太保云 CMO (Configuration Management Officer) 一職。沒錯，我依舊是一個 “云平臺研發(fā)工程師”，但是再一次與 DevOps 結(jié)緣。太保云的 CMO，簡單說就是負(fù)責(zé)太保云平臺的源碼管理、研發(fā)協(xié)作流程、版本管理、CICD、制品管理、發(fā)版流程等等。這個時候我其實(shí)已經(jīng)開始研究一些 DevOps 相關(guān)的工具了，比如 GitLab、Jenkins、禪道、Artifactory、Nexus 等等；同時也在主導(dǎo)一些 DevOps 文化層面的建設(shè)，比如怎樣的模式或行為在團(tuán)隊里是被鼓勵的，怎樣的事情是被禁止的…… 不過我只是在制定規(guī)則，而沒有意識到這是 “文化”?？傊?，那幾年我也算是投身于 DevOps，致力于提升團(tuán)隊研發(fā)效率、交付效率與交付質(zhì)量，但是同時我沒有去仔細(xì)思考過 “什么是 DevOps？” 這個問題，我也沒有刻意去思考過自己是不是在玩 DevOps。

去年 (2021 年) 年底，我加入了 思碼逸，我的 title 第一次從 “xxx 云平臺研發(fā)工程師” 變成了 “xxx DevOps 工程師”（xxx 表示初級、中級、高級等）。那天我開玩笑說：“以前，我在云原生領(lǐng)域兼職玩 DevOps；以后，我在 DevOps 領(lǐng)域兼職玩云原生”。

好吧，這會我是名正言順的 “xxx DevOps 工程師” 了，我總該知道 “什么是 DevOps” 吧！

三、他們說……

我們先來看一下幾家典型的公司是如何定義他們眼中的 DevOps 的，包括：

Atlassian（代表產(chǎn)品：Jira、Trello 等）微軟AWS

3.1、Atlassian 回答 “什么是 DevOps？”

Atlassion 有一篇題為 DevOps 的文章，里面有這樣一句話：

DevOps is a set of practices, tools, and a cultural philosophy that automate and integrate the processes between software development and IT teams. It emphasizes team empowerment, cross-team communication and collaboration, and technology automation.

我嘗試翻譯一下：DevOps 是一系列 實(shí)踐、工具 和一個融合開發(fā)及 IT 團(tuán)隊的 文化理念。DevOps 強(qiáng)調(diào)賦能團(tuán)隊、跨團(tuán)隊溝通與協(xié)作以及技術(shù)自動化。

可以看到 Atlassian 給的等式是：

DevOps = 工具 + 實(shí)踐 + 文化

Atlassian 還提到一個 DevOps 團(tuán)隊包含了開發(fā)和 IT 運(yùn)維，大家一起協(xié)作，共同參與產(chǎn)品的整個生命周期，一起為提升軟件質(zhì)量和加速軟件開發(fā)過程而努力。DevOps 模式下開發(fā)和運(yùn)維不再是獨(dú)立的 “筒倉”，而是幾乎被整合成一個團(tuán)隊，這個團(tuán)隊的工程師技術(shù)棧會覆蓋開發(fā)、測試、運(yùn)維等。同時 DevOps 團(tuán)隊會利用一系列的 DevOps 工具鏈來實(shí)現(xiàn)諸如持續(xù)集成、持續(xù)發(fā)布、流程自動化、高效協(xié)作等等目的。

Atlassion 給的 “無窮環(huán)” 長這樣：

用 “無窮環(huán)” 表示 DevOps 生命周期，是因?yàn)?DevOps 的根本理念是 “持續(xù)”，也就是 “沒有終點(diǎn)”。Atlassion 將整個 DevOps 生命周期分成 6 個階段，分別是：

計劃（Plan）構(gòu)建（Build）持續(xù)集成和部署（或者交付）（Continuous Integration and Deployment or Delivery）監(jiān)控和告警（Monitor and Alert）運(yùn)維（Operate）持續(xù)反饋（Continuous Feedback）

另外從這個環(huán)里我們還能看到 Atlassian 想強(qiáng)調(diào)溝通與協(xié)作是貫穿 DevOps 生命周期全過程的。

3.2、微軟回答 “什么是 DevOps？”

微軟這篇 Introduce the foundation pillars of DevOps: Culture and Lean Product 我特別喜歡！這個標(biāo)題的意思是 “介紹 DevOps 的基柱：文化和精益產(chǎn)品”。

文章第一句話：

DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.

DevOps 是人、過程和產(chǎn)品的結(jié)合，使能持續(xù)地向終端用戶交付價值。

微軟還提到：

Typically, the goal for Development is to deliver more features faster, and the goal of Operations is to achieve better system stability. DevOps aligns these disciplines by using a framework of best practices proven to increase speed to market while improving system stability.

多數(shù)情況下，開發(fā)的目標(biāo)是快速發(fā)布更多的新特性，而運(yùn)維的目標(biāo)是保證更高的系統(tǒng)可用性。DevOps 通過切實(shí)可行的最佳實(shí)踐體系來拉齊這兩個目標(biāo)，在提升系統(tǒng)穩(wěn)定性的同時加速產(chǎn)品交付到市場的速度。

這里微軟可以看到微軟給的第一個等式：

DevOps = 人 + 過程 + 產(chǎn)品

然后微軟從 “人 + 過程 + 產(chǎn)品” 進(jìn)一步提煉了 DevOps 的 4 大基柱：文化、精益產(chǎn)品、架構(gòu)和技術(shù)。

也就是：人 + 過程 + 產(chǎn)品 -> 文化、精益產(chǎn)品、架構(gòu) + 技術(shù)

微軟給的 “無窮環(huán)” 長這樣：

圖里描繪的 DevOps 生命周期還是分成 6 個階段，分別是：

計劃（Plan）構(gòu)建（Build）持續(xù)集成（Continuous Integration）部署（Deploy）運(yùn)維（Operate）持續(xù)反饋（Continuous Feedback）

外加貫穿整個 DevOps 生命周期全過程的 “協(xié)作（Collaboration）”。

在圖外，微軟還定義了對其而言 DevOps 的 8 大能力：

持續(xù)計劃（Continuous Planning）持續(xù)集成（Continuous Integration）持續(xù)發(fā)布（Continuous Delivery）持續(xù)運(yùn)維（Continuous Operations）持續(xù)質(zhì)量（Continuous Quality）持續(xù)安全（Continuous Security）持續(xù)協(xié)作（Continuous Collaboration）持續(xù)改進(jìn)（Continuous Improvement）

每次看到這里我總覺得微軟的圖該更新一版 *。

另外微軟有一句特別有深度總結(jié)：

What is new? Continuous Everything. The process is a journey and requires a growth mindset to continually evolve and improve.

“Continuous Everything”，鏗鏘有力！微軟強(qiáng)調(diào) DevOps 過程是一段沒有終點(diǎn)的旅途，要求我們抱著成長的觀念模式，持續(xù)地改進(jìn)，永不滿足。

3.3、AWS 回答 “什么是 DevOps？”

不難猜到，AWS 也有 一篇文章 來回答 “What is DevOps?”

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.

DevOps 是文化理念、實(shí)踐和工具等的組合，能夠提升一個組織快速交付應(yīng)用和服務(wù)的能力。

這里 AWS 給了一個等式：

DevOps = 文化 + 實(shí)踐 + 工具

不過這篇文章里 AWS 不落俗套，沒有畫一個自己的 “無窮環(huán)”，而是給了這樣一張圖：

這里提到了：

構(gòu)建（Build）測試（Test）發(fā)布（Release）監(jiān)控（Monitor）計劃（Plan）

還可以看到這個 “交付管道” 和 “反饋環(huán)” 連接的是 “企業(yè)” 和 “客戶”，可見 AWS 希望強(qiáng)調(diào) “DevOps 的目的是更快地向客戶交付”。

四、DevOps 文化

我曾一度片面以為 DevOps 要解決的問題就只是工具問題，也就是如何選擇或者開發(fā)好用的 DevOps 工具 or 平臺，從而提升企業(yè)內(nèi)部整個研發(fā)生命周期的運(yùn)行效率。不記得是哪一天，我突然有一個強(qiáng)烈的想法：工具只是工具而已，文化建設(shè)才是成敗的關(guān)鍵！

文化決定了我們?nèi)绾稳プ鍪?，工具決定了，決定了啥？可能啥也決定不了。因?yàn)槲艺J(rèn)為工具也是被文化所決定的。

4.1、什么是文化？

簡單說，文化就是一個組織的社交遺產(chǎn)，也就是一個組織對于其成員的各種行為的響應(yīng)模式。

比如當(dāng)我們說一個企業(yè)有 “加班文化” 時，其實(shí)是在說在這個企業(yè)內(nèi)，員工加班會得到獎賞，而不加班會受到懲罰?；蛘呶覀冋f一個企業(yè)是 “狼性文化”、“奮斗者文化”…… 不同的文化背后對應(yīng)的也就是這個企業(yè)對于員工不同行為的不同響應(yīng)模式。

一個企業(yè)的文化決定了在這個企業(yè)內(nèi)：

什么事情是對的，什么事情是錯的；什么事情是重要的，什么事情是不重要的；什么事情是值得做的，什么事情是不值得做的。

所以文化決定了一個企業(yè)會去招聘哪些人，會開除哪些人，會提拔哪些人。

看到這里可能你已經(jīng)在思考自己呆過的企業(yè)對員工有哪些要求，在鼓勵什么，在懲罰什么…… 沒錯，此刻在你腦海中閃現(xiàn)的一幕幕就是企業(yè)文化。

4.2、什么是 DevOps 文化？

這幅圖大家肯定都不陌生：

什么是 DevOps 文化？

其實(shí)從這幅圖中我們就能看到文化的影子。我們都知道 DevOps 強(qiáng)調(diào)打通開發(fā)團(tuán)隊與運(yùn)維團(tuán)隊的壁壘，要求兩個團(tuán)隊拉齊認(rèn)知與責(zé)任，不再各自為戰(zhàn)，而是一起為更快地交付更高質(zhì)量的產(chǎn)品而努力。沒錯，這就是最基礎(chǔ)的 DevOps 文化。

那么如何拉齊認(rèn)知與責(zé)任呢？

首先可以確認(rèn)的是，我們在組織架構(gòu)上直接融合 Dev 和 Ops 團(tuán)隊，這并不是一個 DevOps 團(tuán)隊。人是不是坐在一起，改變的只是溝通的效率。這里我想強(qiáng)調(diào)兩點(diǎn)：

責(zé)任共擔(dān)，在一個 DevOps 模式組建團(tuán)隊里，每個人都需要為軟件開發(fā)交付的整個生命周期而負(fù)責(zé)；技能共享，通過持續(xù)學(xué)習(xí)，互相學(xué)習(xí)，讓本是傳統(tǒng) Dev 的工程師學(xué)習(xí) Ops 的技能，同時傳統(tǒng) Ops 的工程師也需要學(xué)習(xí) Dev 的技能。

Dev 與 Ops 互相學(xué)習(xí)彼此領(lǐng)域技能，每個人都懂開發(fā)又懂運(yùn)維，抱著 “成長的觀念”，持續(xù)學(xué)習(xí)，不滿足于當(dāng)前已掌握的技術(shù)棧。

但是我們也需要意識到不能要求每個工程師都精通開發(fā)與運(yùn)維，這是不可能的。這里說的 Dev 掌握 Ops 能力，更多的是 Dev 能夠借助完善的工具鏈從而掌握 “應(yīng)用運(yùn)維” 的能力，能夠在自己完成開發(fā)之后，有能力和權(quán)限將應(yīng)用部署上線，同時線上應(yīng)用出問題后，能夠直接對其負(fù)責(zé)，定位、修復(fù)、更新升級等。而一些基礎(chǔ)設(shè)施的運(yùn)維能力需要獨(dú)立出來考慮，比如機(jī)房里的局域網(wǎng)配置、虛擬機(jī)掛 NAS 盤等傳統(tǒng)運(yùn)維能力。

同理 Ops 需要理解應(yīng)用開發(fā)的生命周期，知道 Dev 的痛點(diǎn)，尤其是在流程上的痛點(diǎn)，比如怎樣提升應(yīng)用的構(gòu)建速度，怎樣優(yōu)化應(yīng)用的 cd 流程等，Ops 要關(guān)注應(yīng)用的 “生產(chǎn)過程”，進(jìn)而發(fā)力去優(yōu)化這個過程或相應(yīng)的工具，讓應(yīng)用能夠更可靠更快速地完成 cicd 流程等，更容易地部署上線或者對外交付。也就是說我們并不是要求 Ops 也去寫業(yè)務(wù)代碼，而是協(xié)助 Dev 去解決業(yè)務(wù)代碼之外的痛點(diǎn)，讓 Dev 能夠更加專注于業(yè)務(wù)功能實(shí)現(xiàn)。

最后，一個 DevOps 模式組件的團(tuán)隊中每個人都為整個軟件研發(fā)生命周期的速度和質(zhì)量負(fù)責(zé)，每個具體的角色就像一個大頭釘，底部很寬，代表著技術(shù)面廣，關(guān)注整個軟件研發(fā)生命周期的所有環(huán)節(jié)；同時頂部很高，在某個環(huán)節(jié)里專注，做好做精。

DevOps 成功落地的關(guān)鍵是什么？

我們前面說到的 “其樂融融” 的場景，我們希望 Dev 和 Ops 能夠互相學(xué)習(xí)，共擔(dān)責(zé)任，一起為更快更好地交付產(chǎn)品而努力。但是，工程師們?yōu)槭裁匆@樣做？他們的動力在哪里？

4.3、領(lǐng)導(dǎo)與激勵

Gartner 曾出過一個分析報告，表明在 2023 年，90% 的 DevOps 改革將會失敗（相較于預(yù)期）。而失敗的主要原因是領(lǐng)導(dǎo)層管理方法的局限。

其實(shí)這是顯而易見的，DevOps 可以稱為一種 “改革”，而很多人是抵觸 “變化”，抵觸 “新事物” 的。比如 DevOps 鼓勵接受失敗，快速失敗，從失敗中學(xué)習(xí)經(jīng)驗(yàn)，進(jìn)而在更長的時間維度上爭取更大的成功。但是可能你遇到的剛好是一個 “失敗懲罰型” 領(lǐng)導(dǎo)，那么你的團(tuán)隊就會懼怕失敗，從而放棄創(chuàng)造與嘗試新技術(shù)，選擇安于現(xiàn)狀。

一個技術(shù)團(tuán)隊的領(lǐng)導(dǎo)首先自己需要懂技術(shù)，有豐富的經(jīng)驗(yàn)，這是基礎(chǔ)要求。但是除此之外，更重要的是團(tuán)隊領(lǐng)導(dǎo)能夠激勵整個團(tuán)隊，去發(fā)揮整個團(tuán)隊的主觀能動性，讓所有團(tuán)隊成員都能夠有動力持續(xù)學(xué)習(xí)，快速學(xué)習(xí)，同時也能夠敢于失敗，快速失敗且不懼怕失敗，把失敗當(dāng)做一個學(xué)習(xí)的機(jī)會，進(jìn)而不斷成長，讓整個團(tuán)隊的戰(zhàn)斗力能夠越來越強(qiáng)。

所以領(lǐng)導(dǎo)怎樣激勵工程師呢？

福利？比如一些大廠提供的免費(fèi)零食或者定期的下午茶？免費(fèi)的咖啡或者午餐？

沒錯，作為一個工程師，這一切的福利都會讓其開心，但是其實(shí)無法激勵其更加認(rèn)真努力地工作。工程師的薪資水平普遍不低，所有這些零食也好，咖啡也好，大概率不會到其月薪的零頭。同理，工程師找工作時，看重的也絕不會是一個企業(yè)是否提供免費(fèi)午餐和下午茶。

那么工程師看重的是什么？

在選擇一家企業(yè)的時候，可能工程師第一個考慮的是薪資，剩下的可能是成長的空間、工作內(nèi)容是否感興趣等等等等。但是進(jìn)入一家公司以后，真正開始工作的時候，工程師看重的是什么？我認(rèn)為可能是：

-精通 -自驅(qū) -目標(biāo)

我們逐個來解釋一下。

1. 精通

我們在某個工作方向做的好，我們擅長某個技術(shù)方向，進(jìn)而很好地完成相應(yīng)的工作，這時候我們會有一種成就感，滿足感，我們會覺得自己得心應(yīng)手，同時大概率會獲得認(rèn)可，贊揚(yáng)，因此接下來的時間里我們就更加愿意在這個方向上繼續(xù)努力，做的更好。也就是說一個工程師能夠有機(jī)會專注于自己精通的技術(shù)上發(fā)力，那么他大概率會感受到激勵。

反例是什么呢？比如你是一個 Java 工程師，但是你的領(lǐng)導(dǎo)擅長 PHP，并且覺得 PHP 是世界上最好的語言，于是要求整個團(tuán)隊轉(zhuǎn)向使用 PHP，這時候你會放棄自己研究多年的 Java 技術(shù)棧，努力學(xué)習(xí) PHP 并決心干出一番成績嗎？

2. 自驅(qū)

我們希望組建一個學(xué)習(xí)型、創(chuàng)造型的團(tuán)隊，每個人能夠持續(xù)成長，樂于創(chuàng)新，自我驅(qū)動。這就需要領(lǐng)導(dǎo)能夠允許團(tuán)隊花時間去學(xué)習(xí)，去輸入，而不是一味地輸出，每時每刻匯報自己寫了幾行代碼。同時這也要求領(lǐng)導(dǎo)自身勇于接受新事物，擁抱變化，而不是 “不求有功，但求無過”。舉個例子：假如你的領(lǐng)導(dǎo)最擔(dān)心的是線上應(yīng)用出事故，并且他認(rèn)為穩(wěn)定的第一要素就是不要引入新技術(shù)，新工具，那么這時候你的領(lǐng)導(dǎo)也不會在意你是不是有時間學(xué)習(xí)，也不會允許你花時間去研究新技術(shù)，因?yàn)檫@一切只會帶來不穩(wěn)定。如果領(lǐng)導(dǎo)害怕失控，因而拒絕創(chuàng)新，那么這樣的團(tuán)隊成員也就只能滿足于實(shí)現(xiàn)日復(fù)一日的常規(guī)需求開發(fā)迭代，而不會享受技術(shù)，自我驅(qū)動，擁抱創(chuàng)新。

3. 目標(biāo)

顯而易見，團(tuán)隊每個成員都需要知道自己為什么做？目的是什么？目標(biāo)是什么？而不是領(lǐng)導(dǎo)心里藏著一個目標(biāo)，然后簡單地指揮團(tuán)隊成員完成一件件具體的零散的工作項(xiàng)。如果團(tuán)隊成員只知道今天需要完成事務(wù) A，明天需要完成事務(wù) B，而不知道為什么要做，最終要做成什么樣，那么大家只會滿足于機(jī)械地完成任務(wù)，而不會有動力追求 “如何做得更好”。

五、總結(jié)

所以 DevOps 是什么？

我嘗試給出我的答案：

DevOps 是一種文化理念、工具與實(shí)踐的結(jié)合，目的是更快更可靠地向用戶持續(xù)交付價值。其中最重要的是文化，文化要求 Dev 和 Ops 團(tuán)隊責(zé)任共擔(dān)，目標(biāo)一致，也要求整個團(tuán)隊持續(xù)學(xué)習(xí)，抱著成長的心態(tài)，Continuously Everything。其次 DevOps 離不開高效的工具集，工具是自動化的基礎(chǔ)。最后我們要在各個環(huán)節(jié)追求最佳實(shí)踐，不管是工具的使用，還是團(tuán)隊的協(xié)作模式，溝通方法上面。

最后，關(guān)于標(biāo)題 “什么是 DevOps？看這一篇就夠了！”，我想告訴你，DevOps 文化里不存在 “夠了”，所以我不得不承認(rèn)，我撒謊了。本文只代表我個人現(xiàn)階段的粗淺認(rèn)知，我建議你查閱更多的資料，持續(xù)學(xué)習(xí)，永不滿足。當(dāng)然如果本文對你有一點(diǎn)點(diǎn)的幫助，那么我很滿足。

via:

什么是 DevOps？看這一篇就夠了！- 博客園 玩轉(zhuǎn) DevOps 和研發(fā)效能 posted on 2022-08-04 11:43 https://www.cnblogs.com/DevLake-DevStream/p/what-is-devops.html

柚子快報激活碼778899分享：DevOps 的起源

http://yzkb.51969.com/

好文閱讀