在過去的三年中哥谷，我作為 DevOps 的咨詢師參與了很多企業(yè)的 DevOps 轉(zhuǎn)型咨詢以及技術(shù)實(shí)施，也在不同的社區(qū)活動(dòng)中分享了自己在 DevOps 上的實(shí)踐麻献、理解和觀點(diǎn)们妥。
隨著 DevOps 的盛行，我在很多場合和越來越多的人聊起 DevOps勉吻。也在不同的渠道聽到了很多人在講 DevOps监婶。然而，討論的背后齿桃，我發(fā)現(xiàn)每個(gè)人對 DevOps 所指并不是同一件事情惑惶，也由于各執(zhí)一詞導(dǎo)致不歡而散。
于是我通過 DevOpsDays 的官方網(wǎng)站整理所有 DevOps 的有關(guān)材料短纵，隨著學(xué)習(xí)和了解的不斷增多带污，我也漸漸的對 DevOps 有了更進(jìn)一步的認(rèn)識。我把學(xué)到的材料經(jīng)過整理后把陸續(xù)放在了簡書上香到，形成了" DevOps 前世今生" 這個(gè)系列鱼冀，這個(gè)系列還在不斷補(bǔ)充新的材料。
含義越來越豐富的 DevOps
DevOps 至今都缺乏一個(gè)清晰和統(tǒng)一的認(rèn)識养渴。對于一場運(yùn)動(dòng)來說雷绢，這是一件好事，也同樣是一件壞事理卑。雖然 Patrick 曾經(jīng)在自己的博客里一再提到自己對 DevOps 的"正確認(rèn)識''翘紊，但社區(qū)似乎不以為然。
缺乏“官方定義”好處是人人都可以定義藐唠，因此沒有一個(gè)人或者組織可以壟斷 DevOps 定義權(quán)帆疟。所以每個(gè)人都自己可以參與到這一運(yùn)動(dòng)中去鹉究，不斷為其增加新的概念、新的實(shí)踐和新的工具踪宠。這會(huì)使 DevOps 社區(qū)不斷的繁榮自赔。
而壞處也很明顯，對于 DevOps 的后來者 —— 那些沒有參與進(jìn)來的人柳琢，需要學(xué)習(xí)和理解的 DevOps 知識的廣度和深度也越來越大绍妨。
以至于后來出現(xiàn)了這幅眾所周知的“盲人摸象圖”：
這幅圖中包含了很多概念，但主要表現(xiàn)的意義 DevOps 是一系列概念的總和柬脸，任何一個(gè)單方面的定義只是 DevOps 的一個(gè)部分他去，而不是 DevOps 的整體，隨著 DevOps 這個(gè)概念的不斷膨脹倒堕，人們就更難理解 DevOps 了灾测。
那么，你理解的 DevOps 是指的什么垦巴？
在接觸了各類客戶和社區(qū)之后媳搪，我開始嘗試?yán)斫饷總€(gè)人談到 DevOps 的時(shí)候，他們分別指的是什么骤宣，以及所指內(nèi)容背后的目標(biāo)和動(dòng)機(jī)秦爆。漸漸的，我把我所聽到的 DevOps 概念分成如下四類涯雅，分別是：
- DevOps 是一組技術(shù)/實(shí)踐
- DevOps 是一個(gè)角色
- DevOps 是一種工作方式
- DevOps 是一種組織結(jié)構(gòu)
那么鲜结，我們分別來談?wù)勥@四類 DevOps展运。
當(dāng) DevOps 是一組技術(shù)/實(shí)踐
在工程師文化的組織里活逆，對先進(jìn)技術(shù)的渴望是最常見的學(xué)習(xí)動(dòng)機(jī)∞质ぃ可以促進(jìn)工程師用更有效率蔗候，更優(yōu)雅的方式解決問題。而對于非工程師文化的組織埂软，新的技術(shù)往往是提升其 KPI 的工具锈遥。以下是我聽到 DevOps 的時(shí)候，經(jīng)常觸及的話題：
- 高頻部署
- 持續(xù)交付
- 云計(jì)算/虛擬化技術(shù)
- 基礎(chǔ)設(shè)施即代碼
- Docker
- 自動(dòng)化運(yùn)維
高頻部署
曾經(jīng)和某跨國著名銀行的外匯交易產(chǎn)品的 IT 產(chǎn)品負(fù)責(zé)人交流 DevOps勘畔。對方很自豪的告訴我所灸，他們產(chǎn)品每天的部署頻率超過500次，我聽了不以為然炫七。因?yàn)榕懒ⅲ渴痤l率高不見得是件好事。于是我問了以下幾個(gè)問題：
- 為什么你們需要這么頻繁的部署万哪？有這么頻繁變動(dòng)的業(yè)務(wù)需求嗎侠驯？
- 在這么多次部署里抡秆，是發(fā)布業(yè)務(wù)價(jià)值的部署更多，還是修復(fù)問題的部署更多吟策？
- 這些生產(chǎn)環(huán)境的變更難道完全是不可規(guī)劃的嗎儒士？
由于對方的金融業(yè)務(wù)有相應(yīng)的法律法規(guī)，理論上沒有這么頻繁的變更需求檩坚，除非清理技術(shù)債着撩，否則沒有很強(qiáng)烈的變更動(dòng)機(jī)。但對方并沒有直接回答我的問題匾委，而是換到了其它問題上睹酌，因此我最終也不清楚對方這么頻繁變更的驅(qū)動(dòng)力。
這對我有一個(gè)重要的：指標(biāo)導(dǎo)向的 DevOps 往往是一種 DevOps 的反模式剩檀，它會(huì)忽略和掩蓋真正的問題憋沿。
指標(biāo)的背后是某種度量，如果部署頻率一直很高沪猴，一定反應(yīng)了某種現(xiàn)象辐啄。而這些現(xiàn)象不一定是個(gè)好現(xiàn)象：不是業(yè)務(wù)的變動(dòng)很頻繁，就是技術(shù)的變動(dòng)很頻繁运嗜。但如果二者都頻繁壶辜，我們應(yīng)該衡量變更帶來的價(jià)值和風(fēng)險(xiǎn)（當(dāng)然，DevOps 可以降低變更的風(fēng)險(xiǎn)）担租，并優(yōu)先變更價(jià)值較高的請求砸民。有可能新的業(yè)務(wù)嘗試讓我們從市場上獲得了更多的關(guān)注，也有可能新的技術(shù)提升了生產(chǎn)率奋救。但無論是哪一種岭参，部署頻率應(yīng)該是一個(gè)有多到少不斷循環(huán)的過程。這表明系統(tǒng)在走向成熟和穩(wěn)定的同時(shí)尝艘，能夠及時(shí)響應(yīng)變化演侯，無論是對技術(shù)還是對業(yè)務(wù)，對變更產(chǎn)生的影響都需要一段時(shí)間去積累和總結(jié)數(shù)據(jù)背亥。
此外秒际，DevOps 絕不是為了提升部署頻率而犧牲了軟件質(zhì)量和業(yè)務(wù)價(jià)值，甚至是安全措施狡汉。換句話說娄徊，DevOps 不是一種對質(zhì)量的平衡和妥協(xié)，它是一種全局改進(jìn)盾戴。全局的改進(jìn)就意味著以價(jià)值為最高原則所度量的相關(guān)指標(biāo)是不能有所下降的寄锐。
持續(xù)交付
持續(xù)交付是 DevOps 中非常重要的實(shí)踐，持續(xù)交付的思想遠(yuǎn)早于 DevOps 。但直到第二屆歐洲的 DevOpsDays 才有了持續(xù)交付這個(gè)重量級話題锐峭。因?yàn)槌掷m(xù)交付本身也通過技術(shù)手段和實(shí)踐解決了 DevOps 最初所面臨的 Dev 和 Ops 的合作問題中鼠。
不夸張的說，如果 Patrick Debois 早一點(diǎn)讀到持續(xù)交付中運(yùn)維相關(guān)的話題沿癞，說不定就沒有 DevOps 了援雇。
然而，隨著 DevOps 的理念的發(fā)展比持續(xù)交付融匯了更多的概念（這就是沒有一個(gè)人能壟斷定義的好處）椎扬，使得 DevOps 更加廣泛和盛行惫搏。因此， DevOps 所涵蓋的范圍已經(jīng)超出了持續(xù)交付本身蚕涤。
我把 持續(xù)交付 列為 DevOps 的核心實(shí)踐之一筐赔，因?yàn)槿绻銢]有實(shí)踐 持續(xù)交付。那么根本不能稱之為 DevOps揖铜，但是如果你完整實(shí)踐了持續(xù)交付茴丰，那么你離完整的 DevOps 也不遠(yuǎn)了。
云計(jì)算/虛擬化技術(shù)
隨著分布式應(yīng)用的井噴式發(fā)展天吓』呒纾基礎(chǔ)設(shè)施的管理成為了分布式應(yīng)用的新瓶頸。在集中式管理的時(shí)代龄寞，大型應(yīng)用只能運(yùn)行在昂貴的小型機(jī)上汰规，只有微軟，SAP物邑， IBM 溜哮，Oracle 和 EMC 這樣的企業(yè)才有能力提供相應(yīng)的產(chǎn)品完成這樣復(fù)雜度很高的架構(gòu)。因此企業(yè)需要單獨(dú)的運(yùn)維部門（Ops）來管理這些軟件和設(shè)備色解。
而隨著虛擬技術(shù)和云計(jì)算的興起茂嗓，企業(yè)的基礎(chǔ)設(shè)施管理工作往往變得很簡單。VMWare 這樣的虛擬技術(shù)企業(yè)和 AWS 這樣的云計(jì)算供應(yīng)商提供了更加成熟和穩(wěn)定的產(chǎn)品冒签。大大的節(jié)約了企業(yè)機(jī)房管理的開支在抛。
而 Ops 也不再需要進(jìn)出機(jī)房钟病，只需要通過遠(yuǎn)程桌面的方式就可以使用各種 SDK 開發(fā)工具去完成過去很多只有在機(jī)房才能做到的操作萧恕。
然而，即使云計(jì)算和虛擬化技術(shù)提升了 Ops 的生產(chǎn)率肠阱，減輕了 Ops 的痛苦票唆。但仍沒有解決 Dev 和 Ops 之間的矛盾 —— 開發(fā)團(tuán)隊(duì)和維護(hù)團(tuán)隊(duì)仍然各自為政，仍然通過制度談判而不是合作共贏來工作屹徘，畢竟目標(biāo)是相對立的走趋。
基礎(chǔ)設(shè)施即代碼
隨著設(shè)備和網(wǎng)絡(luò)的持續(xù)增多，加之更加復(fù)雜的應(yīng)用部署和初始化噪伊〔净停基礎(chǔ)設(shè)施的管理成為了一個(gè)十分尖銳的問題氮唯。當(dāng)復(fù)雜度上升一個(gè)量級，就需要專業(yè)的管理工具來管理這類問題姨伟。于是 Puppet 這樣的框架順勢而出惩琉。以至于在 《DevOps Handbook》中，合著者之一的 John Willis 在理解了 PuppetLab 的創(chuàng)始人 Luke Kanies 的想法之后夺荒，才有了 DevOps 的最初理解瞒渠。
基礎(chǔ)設(shè)施即代碼利用了編程語言和虛擬化工具 API 的無縫連接達(dá)到這一目的。它在很大程度上把基礎(chǔ)設(shè)施的管理當(dāng)做其問題域技扼，采用正確的面向?qū)ο蠓绞轿榫粒岄_發(fā)人員和運(yùn)維人員能夠理解并設(shè)計(jì)出更加穩(wěn)定和靈活的基礎(chǔ)設(shè)施。大大降低基礎(chǔ)設(shè)施變更的風(fēng)險(xiǎn)：提升了運(yùn)維知識的透明度并使基礎(chǔ)設(shè)施變更具備冪等性剿吻。
此外窍箍，它在一定程度上解決了不同環(huán)境（開發(fā)，測試丽旅，生產(chǎn)）之間的不一致問題仔燕，也讓開發(fā)人員能夠?qū)W習(xí)到 Ops 領(lǐng)域的知識并用軟件開發(fā)的優(yōu)秀思想解決運(yùn)維領(lǐng)域的問題。
因此魔招，基礎(chǔ)設(shè)施即代碼除了工具以外晰搀，更是一種 Dev 和 Ops 之間相互溝通的媒介，能夠讓開發(fā)人員和運(yùn)維人員相互理解办斑。所以外恕，基礎(chǔ)設(shè)施即代碼毫無疑問的是 DevOps 的核心實(shí)踐之一。
Docker
Docker 是含著 DevOps 的金鑰匙出生的乡翅，它誕生的第一天就帶著 DevOps 的基因：更簡單的解決了基礎(chǔ)設(shè)施即代碼和虛擬化在實(shí)踐中的問題鳞疲，進(jìn)一步提升了自動(dòng)化能力以提升效率，并且對開發(fā)人員和運(yùn)維人員都十分友好蠕蚜。
甚至很多地方都會(huì)以是否采用 docker 來評判是否采用了 DevOps 的相關(guān)技術(shù)尚洽。
Docker 一定程度上簡化了基礎(chǔ)設(shè)施的初始化和狀態(tài)管理問題。通過鏡像和運(yùn)行時(shí)容器封裝了應(yīng)用運(yùn)行時(shí)的復(fù)雜度靶累。并通過容器的編排實(shí)現(xiàn)輕量級的分布式架構(gòu)腺毫，也更加經(jīng)濟(jì)快捷。
但是挣柬，Docker 和任何一種工具一樣潮酒，都不是”黃金錘“。當(dāng)用錯(cuò)了場景邪蛔，使用 docker 可能是一場災(zāi)難急黎。我曾經(jīng)參與并幫客戶完成了一個(gè)數(shù)據(jù)中心遷移的項(xiàng)目，就是采用的 docker 作為統(tǒng)一的運(yùn)行時(shí)容器。最初是因?yàn)?docker 鏡像的移植性好勃教，在各種異構(gòu) Linux 系統(tǒng)上可以正確執(zhí)行淤击，且鏡像構(gòu)建過程透明。但是客戶為了能讓這個(gè)業(yè)務(wù)場景更加通用故源，又分別采用了另外兩種工具對其部署場景進(jìn)行封裝遭贸，并寫出了第三個(gè)工具。由于這個(gè)工具并沒有很好的分離其業(yè)務(wù)關(guān)注點(diǎn)和技術(shù)關(guān)注點(diǎn)心软，導(dǎo)致這個(gè)工具使用異常繁瑣壕吹，需要增加更多額外的配置去定制化容器運(yùn)行環(huán)境。原本為了提升生產(chǎn)效率的手段反而成為了阻礙效率的絆腳石删铃。
自動(dòng)化運(yùn)維
看了以上那么多的工具和技術(shù)耳贬，很多對 DevOps 望文生義?或有些技術(shù)了解的運(yùn)維工程師認(rèn)為提高了自動(dòng)化運(yùn)維的水平，就是 DevOps猎唁。雖然 DevOps 里的一個(gè)重要特征是“自動(dòng)化”咒劲，但擁有自動(dòng)化運(yùn)維，并不代表你就正在實(shí)踐 DevOps诫隅，很可能你僅僅提升了運(yùn)維部門的效率腐魂，但并沒有從全局的角度提升開發(fā)和運(yùn)維之間的效率和端到端價(jià)值的流動(dòng)。因此逐纬，僅僅有自動(dòng)化運(yùn)維蛔屹，還不足以稱之為 DevOps。
關(guān)于 “ DevOps 技術(shù)”
以上列舉了很多所謂 “DevOps 技術(shù)”豁生，是從技術(shù)的角度來認(rèn)識 DevOps兔毒。然而，不探索 DevOps 真正的問題甸箱，以及技術(shù)背后的目的和最佳實(shí)踐育叁。往往會(huì)使導(dǎo)致對 DevOps 的片面了解而適得其反。
從 DevOps 運(yùn)動(dòng)發(fā)展的歷史上來看芍殖，DevOps 相關(guān)技術(shù)是解決 DevOps 相關(guān)問題的結(jié)果豪嗽，而非起因。因此豌骏，對于 DevOps 的理解如果本末倒置龟梦，則很有可能起到東施效顰的結(jié)果。你會(huì)發(fā)現(xiàn)你拿著一堆 DevOps 的錘子肯适，看見了可能并不存在的釘子变秦。
此外，我相信掌握工具對于工程師群體來說不是一件難事框舔，并且隨著技術(shù)的發(fā)展，工具和平臺的使用會(huì)越來越容易。但是刘绣，能夠跳出自己的舒適區(qū)和思維習(xí)慣樱溉，從全局的角度觀察并解決問題的能力則是很多工程師所欠缺的。
當(dāng) DevOps 是一個(gè)崗位角色
當(dāng) DevOps 傳播開來纬凤，大家都會(huì)傾向于去找叫做 “DevOps” 的人福贞，希望通過招聘和培訓(xùn)來提升自己的 DevOps 能力。 于是設(shè)置了一些稱之為 "DevOps 工程師" 的崗位和角色停士。通過對這些招聘需求以及客戶對 DevOps 的需求挖帘，我發(fā)現(xiàn)了四個(gè)不同但是相關(guān)的 " DevOps 工程師 " ：
- 作為 Dev 的 Ops（會(huì)開發(fā)技能的運(yùn)維工程師）
- 作為 Ops 的 Dev（會(huì)運(yùn)維技能的開發(fā)工程師）
- 基礎(chǔ)設(shè)施開發(fā)工程師
- 全棧工程師
作為 Dev 的 Ops
有很多人也會(huì)認(rèn)為，只要讓開發(fā)工程師掌握運(yùn)維技能恋技，運(yùn)維工程師掌握開發(fā)技能拇舀，就做到了 DevOps。這招來了很多運(yùn)維工程師的反感蜻底。我采訪過一些運(yùn)維工程師骄崩，當(dāng)初他們就是不喜歡也不想寫代碼，才選擇了運(yùn)維方向薄辅。
這種想法的其中一個(gè)動(dòng)機(jī)是在于架構(gòu)的逐漸穩(wěn)定帶來的運(yùn)維工作減少要拂，特別是使用了云計(jì)算技術(shù)和虛擬化技術(shù)的企業(yè)。這會(huì)讓管理層有一種錯(cuò)覺站楚，認(rèn)為運(yùn)維團(tuán)隊(duì)的空閑狀態(tài)脱惰，一定程度上是浪費(fèi)。因此窿春，為了達(dá)到“人盡其用”枪芒，讓運(yùn)維工程師進(jìn)入開發(fā)團(tuán)隊(duì)去寫業(yè)務(wù)代碼。并用“DevOps"作為對這種措施這一合理化的幌子谁尸。
這種想法的天真在于忽視了開發(fā)和運(yùn)維的專業(yè)性和差異性舅踪。這讓我想起一個(gè)段子：
老板：“我怎么覺得在公司的運(yùn)營中你們部門沒起多大作用？”
運(yùn)維經(jīng)理：“你走過大橋嗎良蛮？”
老板：“走過抽碌。“
運(yùn)維經(jīng)理：“橋上有欄桿嗎决瞳？”
老板：“有货徙。”
運(yùn)維經(jīng)理：“您過橋的時(shí)候扶欄桿嗎皮胡？”
老板：“不扶痴颊≈髦”
運(yùn)維經(jīng)理：“那么务冕，欄桿對您來說就沒用了？”
老板：“那當(dāng)然有用了答捕，沒用欄桿護(hù)著，掉下去怎么辦泻仙？”
運(yùn)維經(jīng)理：“可是您沒有扶欄桿案庠佟！玉转？”
老板：“…… 可是 …… 可是沒有欄桿突想，我會(huì)害怕！“
運(yùn)維經(jīng)理：“那么究抓，運(yùn)維就是橋上的欄桿猾担。“
雖然我不否認(rèn)技術(shù)的發(fā)展對二者來說難度和門檻在不斷降低刺下。而且掌握一定開發(fā)技能的運(yùn)維工程師前景更加光明绑嘹。但是強(qiáng)人所難并不會(huì)讓事情變好。此外怠李，這類人才可遇不可求圾叼，也不要因?yàn)檎胁坏竭@樣的人而阻止了 DevOps 實(shí)踐。
作為 Ops 的 Dev
同樣的誤解也會(huì)發(fā)生在開發(fā)工程師身上捺癞。對于開發(fā)工程師來說夷蚊，其實(shí)難度并沒有增加。無非是把 Ops 的工作當(dāng)做需要通過別的工具完成的開發(fā)需求而已髓介，甚至很多開發(fā)工程師自己也這么認(rèn)為惕鼓。
運(yùn)維除了知識以外，很大一部分的不可替代性來源于生產(chǎn)環(huán)境的維護(hù)經(jīng)驗(yàn)唐础。然而這些經(jīng)驗(yàn)不可復(fù)制箱歧，因?yàn)橛行﹩栴}作為開發(fā)人員來說你很難碰到。我曾打趣的說一膨，當(dāng)你聽到有人說“這不可能啊”呀邢，他一定是個(gè)運(yùn)維新手。
就像我在上文強(qiáng)調(diào)的豹绪，軟件開發(fā)和軟件維護(hù)是相互關(guān)聯(lián)但是各自獨(dú)立的專業(yè)領(lǐng)域价淌。DevOps 并不是要消除任何一方，而是要通過更加深入的合作成為彼此工作的潤滑劑而非絆腳石瞒津。
對于開發(fā)工程師來說蝉衣，掌握更多的技能絕對是一件好事。但也不要低估運(yùn)維的專業(yè)性和經(jīng)驗(yàn)性巷蚪。
基礎(chǔ)設(shè)施開發(fā)工程師
由于有了虛擬化和基礎(chǔ)設(shè)施即代碼這樣的技術(shù)病毡，“通過 Dev 的方式完成 Ops 的工作，就是 DevOps “ 也很自然的成為了很多 Ops 對 DevOps 的認(rèn)識屁柏。指的是通過 SDK啦膜，相關(guān)工具和配置文件有送，利用現(xiàn)有的平臺資源，為應(yīng)用程序構(gòu)建基礎(chǔ)設(shè)施功戚。而他們往往有一個(gè)新的稱謂：基礎(chǔ)設(shè)施開發(fā)者 （Infrastructure Developer）或這 云計(jì)算工程師 （Cloud Engineer）娶眷。
有一次到馬來西亞出差似嗤，我稱自己是 Infrastructure Developer 被 Uber 司機(jī)當(dāng)做政府基建項(xiàng)目開發(fā)商?問了一堆稀奇古怪的問題啸臀，當(dāng)然我并沒有澄清，而是繼續(xù)逗他 ;-D
在一些企業(yè)里烁落，基礎(chǔ)設(shè)施開發(fā)工程師都會(huì)肩負(fù)著推行企業(yè) DevOps 的責(zé)任乘粒。但很少有企業(yè)能夠明確 DevOps 是要做什么（這就是 DevOps 缺乏基準(zhǔn)定義的壞處），而這些基礎(chǔ)設(shè)施開發(fā)工程師會(huì)慢慢變成一個(gè)孤立的“平臺團(tuán)隊(duì)”伤塌，這對 DevOps 是不利的灯萍。
全棧工程師
當(dāng)然絕對不排除有些工程師是既懂開發(fā)也懂運(yùn)維的"復(fù)合型人才"。但這樣的人才的成本也十分高昂：一方面是尋找這樣的人所花費(fèi)的時(shí)間每聪。另一方面是雇用這樣的人所花費(fèi)的資金旦棉。此外，對于某些企業(yè)來說還有培養(yǎng)這樣人才的成本药薯。
但是绑洛，僅僅認(rèn)為有了這樣的人才就具備 DevOps 的能力也并不現(xiàn)實(shí)。首先童本，DevOps 是一個(gè)團(tuán)隊(duì)屬性真屯，而不是一個(gè)人屬性。一個(gè)人的力量相較于一個(gè)團(tuán)隊(duì)來說穷娱，還是很有限绑蔫。其次，招聘這樣的人主要還是為了勝任紛繁多變的工作泵额，創(chuàng)業(yè)公司尤其如此配深。因此，我有時(shí)候會(huì)戲稱全棧工程師為“全干工程師”嫁盲，聽起來很厲害篓叶，但工作境遇并不見的很好。
你可能只需要一個(gè) “DevOps 晃動(dòng)器”
軟件開發(fā)和軟件運(yùn)維亡资，是兩類不同但聯(lián)系很密切的事務(wù)澜共，在過去很長的時(shí)間里。由于專業(yè)性和責(zé)任的不同從甲乙雙方的矛盾變成了企業(yè)內(nèi)部的矛盾锥腻。這是企業(yè)在互聯(lián)網(wǎng)轉(zhuǎn)型過程中的必經(jīng)階段嗦董，因?yàn)檫\(yùn)維的開發(fā)不密切合作帶來的問題日漸突出。而如何平滑的過渡瘦黑，則是 DevOps 成敗關(guān)鍵所在京革。你所需要不光是工程人才奇唤，你還需要新型的管理人才或者外部顧問來推動(dòng)這項(xiàng)改進(jìn)。
一般來說匹摇，DevOps 的變革一定會(huì)調(diào)整組織的制度和做事方式咬扇。而制度層面的改變從企業(yè)內(nèi)部是很難做到的。企業(yè)越大廊勃，“不求有功懈贺，但求無過”的鴕鳥心態(tài)普遍存在，因此越是大型的組織坡垫，所面臨的組織僵化會(huì)越嚴(yán)重梭灿。組織僵化不見得是一件壞事，這意味著你的企業(yè)組織形態(tài)更加的問題和高效冰悠，這是長時(shí)間積累的結(jié)果堡妒。但由于過于高效，組織僵化的負(fù)面效應(yīng)就是缺乏創(chuàng)新溉卓。
所以皮迟，要推動(dòng)企業(yè)的 DevOps 轉(zhuǎn)型，特別是制度方面的創(chuàng)新桑寨，往往需要從組織外部引入“晃動(dòng)器”（無論是聘用新的管理人才伏尼，還是外部顧問）來松動(dòng)一下過于高效的組織，這都是能夠幫助組織解除僵化的方式西疤。
DevOps 是一種工作方式
這算是最貼近 DevOps 的目標(biāo)的定義烦粒。但是在理解和時(shí)間上也是問題百出，片面的理解和機(jī)械的模仿都會(huì)造成 DevOps 之痛代赁。對于 DevOps 的工作方式扰她，有以下四個(gè)常見的理解：
- 用 Dev 的方法做 Ops 的事
- 換了名字的 Ops 團(tuán)隊(duì)
- 一個(gè)有 Ops 的 Dev 團(tuán)隊(duì)
- 一個(gè) Dev 和 Ops 合作的團(tuán)隊(duì)
用 Dev 的方式做 Ops 的事
當(dāng)你采用了上文中的 “基礎(chǔ)設(shè)施即代碼”，或者你有了“基礎(chǔ)設(shè)施開發(fā)工程師”的時(shí)候芭碍。很自然的會(huì)想“我已經(jīng)做到 DevOps 了”徒役。然而，如果你并沒有注意我在上述概念中特別提到的情況窖壕，那么你可能得到的只是下面所述的”換了名字的 Ops 團(tuán)隊(duì)“忧勿。
換了名字的 Ops 團(tuán)隊(duì)
這其實(shí)是很多公司的做法，認(rèn)為 DevOps 所做的事情只是技術(shù)的更新瞻讽，并無其它鸳吸。
在 2016 年底我在悉尼的一個(gè) DevOps 項(xiàng)目上做轉(zhuǎn)型咨詢，客戶的應(yīng)用系統(tǒng)是基于 AWS 構(gòu)建的速勇。并且客戶始終認(rèn)為 DevOps 工程師就是上文所述的基礎(chǔ)設(shè)施開發(fā)團(tuán)隊(duì)晌砾，只是工作的內(nèi)容全都在 AWS 上面，并沒有什么變化烦磁。而且給這個(gè)團(tuán)隊(duì)一個(gè)很高大上的名字：Enablers养匈。然而哼勇，這個(gè)團(tuán)隊(duì)僅僅用新工具是清償了之前運(yùn)維工程師留下的技術(shù)債，并沒有幫助開發(fā)團(tuán)隊(duì)呕乎、測試團(tuán)隊(duì)甚至是業(yè)務(wù)團(tuán)隊(duì)從自己的角度提供幫助來提升價(jià)值的流動(dòng)速度和工作效率积担。
不光如此，因?yàn)檫@個(gè)團(tuán)隊(duì)掌握了關(guān)鍵的基礎(chǔ)設(shè)施資源猬仁，成為了所有團(tuán)隊(duì)前進(jìn)的阻力帝璧，導(dǎo)致其它部門有更多積壓的工作并需要更多人的人來處理。由于出現(xiàn)了這樣的結(jié)果逐虚，“DevOps doesn't work in my orgnization”（DevOps 在我的組織里不好使）的批評也不絕于耳聋溜。
在 DevOps 轉(zhuǎn)型的初期谆膳，我們需要一個(gè)這樣的團(tuán)隊(duì)從運(yùn)維的角度提出統(tǒng)一的方案并提供統(tǒng)一的服務(wù)支持叭爱。但隨著 DevOps 能力和成熟度的提升，這樣一個(gè)實(shí)體團(tuán)隊(duì)而不是虛擬團(tuán)隊(duì)的存在則會(huì)成為 DevOps 繼續(xù)發(fā)展的阻力漱病。
一個(gè)有 Ops 的 Dev 團(tuán)隊(duì)
最天真的想法莫不如把兩類工程師放在一個(gè)團(tuán)隊(duì)里买雾，在同一個(gè)負(fù)責(zé)人的范圍內(nèi)消化 Dev 和 Ops 的問題。這樣杨帽，Dev 和 Ops 就能統(tǒng)一目標(biāo)漓穿，平衡矛盾和沖突，共同解決問題注盈。
但實(shí)際上很少有企業(yè)能夠走出這一步晃危，一方面是 IT 部門的崗位設(shè)置和預(yù)算歸屬，另一方面是團(tuán)隊(duì)變更后的 KPI 考核老客。一件很小的舉動(dòng)就會(huì)牽扯更多的問題僚饭，使 DevOps 難以進(jìn)行下去。此外胧砰，如果缺乏有效的 DevOps 實(shí)踐或者外部教練d 額指引鳍鸵，那么使 Dev 和 Ops 的融合將是一個(gè)漫長的旅程。
在這種情況下尉间，我建議采用 DevOps 項(xiàng)目制的方式來進(jìn)行 DevOps 的體驗(yàn)：
- 首先根據(jù)項(xiàng)目匯聚資源偿乖，在項(xiàng)目中預(yù)留 Ops 角色。
- 從運(yùn)維部門借調(diào)運(yùn)維工程師到項(xiàng)目中哲嘲。運(yùn)維部門要提前安排好運(yùn)維工作的交接贪薪，或者至少把日常性的運(yùn)維任務(wù)的80%剝離出來，分配給現(xiàn)有團(tuán)隊(duì)眠副。保證進(jìn)入項(xiàng)目團(tuán)隊(duì)的運(yùn)維工程師的工作不被打擾
- Ops 所在的部門績效分為兩塊：一塊為常規(guī)運(yùn)維績效（保證系統(tǒng)穩(wěn)定性）画切，另一塊為 DevOps 項(xiàng)目績效（保證開發(fā)順利性），可以根據(jù)具體工作狀況來設(shè)置這樣的工作比率侦啸。
- 保證運(yùn)維團(tuán)隊(duì)人員能夠有機(jī)會(huì)進(jìn)入項(xiàng)目實(shí)踐 DevOps 槽唾，同時(shí)要把項(xiàng)目開發(fā)中的運(yùn)維痛點(diǎn)帶回給運(yùn)維團(tuán)隊(duì)處理丧枪。
在上述 2的悉尼項(xiàng)目里，我就成為了加入到了產(chǎn)品開發(fā)團(tuán)隊(duì)中的運(yùn)維工程師庞萍。一方面解決開發(fā)團(tuán)隊(duì)痛點(diǎn)拧烦，一方面和 Enablers 團(tuán)隊(duì)溝通。一方面解決 開發(fā)團(tuán)隊(duì)的痛點(diǎn)钝计，另一方面獲得相應(yīng)的權(quán)限和知識恋博，并把 開發(fā)團(tuán)隊(duì)的反饋及時(shí)傳達(dá)給 Enablers 團(tuán)隊(duì)。
一個(gè) Dev 和 Ops 合作的團(tuán)隊(duì)
這就是 DevOps 所要達(dá)到的目標(biāo)私恬，它不是一個(gè)人的屬性债沮，而是一個(gè)團(tuán)隊(duì)的屬性。它讓利益相關(guān)方坐在一起解決問題本鸣，而不是相互甩鍋疫衩。然而，由于”合作“的定義很簡單荣德，也很空泛闷煤，導(dǎo)致”合作“難以落地。以下是我認(rèn)為”關(guān)鍵”的 DevOps 合作方式：
- 共同進(jìn)行架構(gòu)設(shè)計(jì)
- 共同進(jìn)行技術(shù)決策
- 持續(xù)交付流水線的建立
- 共同 Pair 和 Review 代碼和環(huán)境的配置
- 共同參與回顧會(huì)議
- 通過定期的內(nèi)部 Session 增加相互的理解
- 共同處理運(yùn)維的問題
此外涮瞻，還有很多其他的合作方式能夠提升 DevOps 的效果鲤拿，在此不一一列舉，這里僅做參考署咽。如果你是一個(gè)敏捷的團(tuán)隊(duì)近顷，只需要把 Ops 作為團(tuán)隊(duì)的一份子，參加所有的活動(dòng)就可以了宁否。
DevOps 是一種組織文化
在著名在 Velocity 09 大會(huì)上窒升，來自 Flicker 的著名演講”10+ Deploys Per Day: Dev and Ops Cooperation“ 明確的指出工具和文化是他們成功的原因。這也第一屆 DevOpsDays 也將工具和文化這兩個(gè)話題進(jìn)一步細(xì)化家淤。在會(huì)后 Patrick Debois 把 DevOps 定義為“管理改進(jìn)”和技術(shù)提升“异剥。
John Willis 和 Damon Edwards 也在 2010 年 MoutainView 舉辦的 DevOpsDays 中重新強(qiáng)調(diào)了文化的重要性。
相對于可以看得見的工具絮重，文化顯得華而不實(shí)冤寿，也有人認(rèn)為 DevOps 文化是一種“空談陷阱”。
有一篇關(guān)于企業(yè)文化的文章寫的非常好青伤，這篇文章叫做”Culture is the Behavior You Reward and Punish“督怜。翻譯過來就是：文化就是你獎(jiǎng)勵(lì)和懲罰的行為。就是說對行為的懲罰和獎(jiǎng)勵(lì)構(gòu)成了你的文化狠角，對 DevOps 也一樣号杠。獎(jiǎng)勵(lì)符合 DevOps 的行為（而不僅僅是鼓勵(lì)），懲罰不符合 DevOps 的行為。就形成了 DevOps 的文化姨蟋。
而我所說的“建立 DevOps 的文化“則是建立一種規(guī)則約束屉凯，這種約束不但包含了 DevOps 的行為準(zhǔn)則，而且包含了獎(jiǎng)勵(lì)和懲罰的機(jī)制眼溶。而這種規(guī)則約束不能變成一紙空文悠砚，更要切實(shí)執(zhí)行下去，形成一種行為習(xí)慣堂飞。
習(xí)慣的力量則能夠保證一種好的制度和實(shí)踐順利的延續(xù)下去灌旧。當(dāng)然這種規(guī)則約束不是一成不變的，這些約束和規(guī)則也需要根據(jù)團(tuán)隊(duì)的發(fā)展不斷的變化以適應(yīng)新的狀況绰筛。
然而枢泰，就如上文所說的，由于企業(yè)并不存在產(chǎn)生 DevOps 的基因（否則你早就有 DevOps 了）铝噩。這些制度很難從內(nèi)部產(chǎn)生衡蚂，必須要的話，請引入外部資源薄榛，例如 DevOps 顧問或者 DevOps 教練讳窟。
我經(jīng)常看到一些 ”KTV式轉(zhuǎn)型”敞恋，這種轉(zhuǎn)型就像是唱 KTV：當(dāng)人們在 KTV 里面對歌詞字幕你總能唱出來，也能唱對谋右。但如果沒有歌詞硬猫，人們往往就唱不出來了。這里的歌詞字幕就相當(dāng)于是轉(zhuǎn)型教練改执，當(dāng)教練在的時(shí)候啸蜜，每個(gè)人都知道怎么做。當(dāng)教練不在辈挂，什么都沒有了衬横。
很多情況下，顧問和教練在短期內(nèi)起到從”0到1“的轉(zhuǎn)變终蒂，然而從”1-100“則不是一朝一夕就能實(shí)現(xiàn)的蜂林。文化的形成是一個(gè)長期的塑造過程，不是能夠買來的拇泣。你需要有足夠的耐心來不斷的評估和反饋當(dāng)前的狀況噪叙。
以下是 DevOps 所鼓勵(lì)的行為。盡管每個(gè)人都鼓勵(lì)以下的行為霉翔，但實(shí)際效果則千差萬別睁蕾，往往抓住了形式而不是本質(zhì)。
- 信任
- 溝通
- 學(xué)習(xí)
- 分享/共擔(dān)
- 不要指責(zé)
信任
你的團(tuán)隊(duì)里的 Dev 和 Ops 之間是相互信任的嗎？你信任你的團(tuán)隊(duì)成員嗎子眶？如果回答是瀑凝。那么你的團(tuán)隊(duì)成員信任你嗎？信任是相互的臭杰，而且是高效團(tuán)隊(duì)成功的基石猜丹。獲得信任很難，需要時(shí)間去建立硅卢。信任同樣也很脆弱射窒，很容易就會(huì)失去。你是否明確哪些行為對信任有幫助将塑，而哪些行為會(huì)傷害信任脉顿？你能說出那些幫助構(gòu)建信任和傷害信任的行為嗎？你的團(tuán)隊(duì)都清楚嗎点寥？
當(dāng)想到以上這些問題艾疟，你還信任你自己和你的團(tuán)隊(duì)嗎？
這里有一個(gè)很重要的原理：沒有無條件的信任敢辩，信任是需要建立的蔽莱。
除了《鳳凰項(xiàng)目》中所介紹的構(gòu)建信任的方式——把自己最脆弱的一面告訴大家——以外，這里我推薦一種構(gòu)建信任的方式：
- 回顧團(tuán)隊(duì)中的每一個(gè)人戚长。
- 把你不信任的人說出來盗冷，并且說出你不信任的點(diǎn)。
- 為了消除這種不信任同廉，你自己愿意做什么事情（而不是讓對方做什么事情）
- 其它人為了消除團(tuán)隊(duì)中的不信任仪糖，也可以輪流發(fā)言。
- 如果消除了這種不信任迫肖，也請說出來锅劝。并為之前你不信任的人和整個(gè)團(tuán)隊(duì)故障歡呼。
第三點(diǎn)最為重要蟆湖，我們給出的建議往往不起效的原因就在于你在對別人提要求故爵，而不是提供幫助。而人們對于提要求的感受都不會(huì)很好隅津，只有提供自己的幫助诬垂，才是真正能解決問題的有效方式。另外饥瓷，作為同一個(gè)團(tuán)隊(duì)的成員剥纷，你也必須想辦法相信對方，并且讓對方相信自己呢铆，沒有選擇晦鞋。
很多人都覺得難以啟齒，難以啟齒的原因就是因?yàn)槿藗儾辉敢庀嘈艑Ψ侥軌蚪蛹{這些不信任。而這么做恰恰能表明你對對方的信任悠垛，相信經(jīng)歷過一系列的措施之后线定，能改善當(dāng)前的狀況。
如果你覺得信任很難達(dá)成确买，那么這就是一個(gè)風(fēng)險(xiǎn)點(diǎn)斤讥，他會(huì)影響團(tuán)隊(duì)成員的行為和判斷，造成不利的影響湾趾。所以芭商，請多檢查團(tuán)隊(duì)內(nèi)部的信任情況，及時(shí)排除風(fēng)險(xiǎn)搀缠。
溝通
溝通是一個(gè)泛濫的話題铛楣，各種打著“高效溝通”的方法也層出不窮，但人們雖然都懂各種道理艺普，也知道溝通的重要性簸州，可溝通仍然被用作為”命令“的幌子，或用來實(shí)施語言暴力歧譬。
溝通的主要目的在于對齊交換意見和看法岸浑，達(dá)成理解。
溝通不僅僅是信息交流的通道瑰步，同樣也是情緒宣泄的出口矢洲。我們在溝通中，有多少是發(fā)泄情緒占了很大的比重面氓，但我們往往沒有察覺兵钮。人們對表達(dá)自己的情緒是難以啟齒的，因此用各種各樣的“道理”來掩蓋真實(shí)的意圖舌界。如果團(tuán)隊(duì)成員的大腦被不良情緒占據(jù)，那么無論如何他在團(tuán)隊(duì)中都不會(huì)有很好的表現(xiàn)的泰演。人們往往會(huì)用其它的方式宣泄自己的情緒呻拌，而缺乏正確的發(fā)泄渠道則會(huì)導(dǎo)致災(zāi)難。
你的團(tuán)隊(duì)里有沒有比較沉默的人或者是不喜歡主動(dòng)溝通的人睦焕？由于信任的逐漸缺失藐握，有些人往往不再溝通。而這類不再溝通的人垃喊，往往是項(xiàng)目中的定時(shí)炸彈猾普。而情緒積累到某一個(gè)點(diǎn)后，這個(gè)炸彈就會(huì)爆炸本谜，造成很惡劣的影響初家。所以，盡早的介入并讓每個(gè)人能夠很順暢的溝通，對降低情緒風(fēng)險(xiǎn)溜在，尤為重要陌知。
此外，在溝通里掖肋，你是聽的多仆葡？還是說的多？如果作為聽者志笼，你真正明白對方講的是什么嗎沿盅？如果作為說者，你在溝通之前纫溃，你是否有計(jì)劃腰涧，是否明確溝通的目的，溝通后如何確認(rèn)達(dá)到了溝通的目的皇耗？
如果不確認(rèn)這些問題南窗，那么溝通往往就是沒有意義的閑聊。
學(xué)習(xí)
在英文里郎楼， 學(xué)習(xí)是一個(gè)詞——Learn 万伤。而在中文里“學(xué)習(xí)”是兩個(gè)詞，對應(yīng)的英文分別是 Learn （學(xué)）和 Practice（習(xí)）呜袁。比如：learnt 就可以因?yàn)樯舷挛牡牟煌硎緝煞N意思敌买。一種是”經(jīng)歷過學(xué)習(xí)的過程，但不一定掌握”阶界，另一種則是真正學(xué)會(huì)了虹钮。
當(dāng)說到學(xué)習(xí)，往往想到的都是“輸入”：看書（雖然買了也未必會(huì)看）膘融，看博客芙粱，看代碼，看視頻…… 然后練習(xí)氧映，直到掌握春畔。
然而，僅有輸入是不夠的岛都，學(xué)習(xí)還應(yīng)當(dāng)有”輸出“：形成博客律姨、開源軟件、演講甚至是培訓(xùn)工作坊臼疫。有一句很著名的話叫做：“教是檢驗(yàn)學(xué)習(xí)成果的唯一標(biāo)準(zhǔn)择份。”是不是真的掌握了烫堤，教一下別人荣赶，你會(huì)意識到“學(xué)習(xí)的錯(cuò)覺”凤价。
在這里，我要強(qiáng)調(diào)一種重要的輸入途徑：從過往的經(jīng)驗(yàn)教訓(xùn)中反思讯壶，總結(jié)料仗，并形成團(tuán)隊(duì)的經(jīng)驗(yàn)。很多事情過去了伏蚊，無論成敗立轧，往往缺乏總結(jié)。這無法讓團(tuán)隊(duì)成長躏吊，因?yàn)槌蓴∪珣{”運(yùn)氣“氛改。
學(xué)習(xí)的目的在于指導(dǎo)今后的實(shí)踐，無論成敗比伏，都會(huì)降低未來失敗的概率胜卤，多做“正確的事”，少做“錯(cuò)誤的事”赁项。
而只有學(xué)，沒有習(xí)悠菜。只有輸入舰攒，沒有輸出，或者只向外看蒂秘，不向內(nèi)看，都是片面的學(xué)習(xí)方式造成。我推薦的學(xué)習(xí)方式則是以輸出作為學(xué)習(xí)目標(biāo)骇吭，對知識和信息進(jìn)行加工燥狰，思考在讶，實(shí)踐僧诚，提煉的過程遮婶。
畢竟，判斷一個(gè)人的知識不再于他的輸入湖笨，而在于他的輸出旗扑。因?yàn)橹v出來，才是自己的慈省。
不要指責(zé)
很多問題棘手是因?yàn)槿藗儾魂P(guān)注如何解決問題臀防，而關(guān)注這個(gè)問題究竟是誰該負(fù)責(zé)。如果團(tuán)隊(duì)在責(zé)任歸屬的問題上花的時(shí)間很多边败，那么這就是一個(gè)指責(zé)文化的制度袱衷。在這種情況下，團(tuán)隊(duì)成員為了自保笑窜，會(huì)避免承擔(dān)責(zé)任和解決問題致燥。因此，很多事情沒有進(jìn)展排截，于是嫌蚤，整個(gè)組織沉浸在一種”不求有功辐益，但求無過“的氛圍下慢慢凝結(jié)，最后僵化脱吱。
我們常常聽到“零容忍”智政，然而對問題的”零容忍“往往是很漂亮的口號。但它往往指的是”發(fā)現(xiàn)問題掩蓋問題“箱蝠。以前人們都說续捂，不怕有問題，就怕看不見問題抡锈。而現(xiàn)在很多問題的出現(xiàn)并不是“黑天鵝""事件疾忍，而是"灰犀牛"事件。恰恰是對問題的選擇性失明導(dǎo)致了不可挽回的結(jié)果床三。
在實(shí)踐 DevOps 的時(shí)候一罩，需要先測試一下有多少裝睡的人。因?yàn)?strong>沒有解決不了的問題撇簿，只有不愿承擔(dān)的責(zé)任聂渊。
分享/共擔(dān)
Share 在英文里有兩個(gè)意思，一個(gè)和別人分享四瘫，另一個(gè)是和別人共同承擔(dān)汉嗽。在 DevOps 的上下文里二者兼有，一方面是作為學(xué)習(xí)的結(jié)果的產(chǎn)出找蜜。另一方面是避免組織陷入不愿承擔(dān)責(zé)任的文化饼暑。對于團(tuán)隊(duì)作戰(zhàn)來說，一個(gè)人犯錯(cuò)洗做，不是他一個(gè)人的責(zé)任弓叛，而是集體的責(zé)任〕现剑”當(dāng)你用一個(gè)指頭指著別人的同時(shí)撰筷，另外四個(gè)指頭也指著自己。
我們要相信沒有不良的人畦徘，只有不良的制度毕籽。當(dāng)出現(xiàn)了問題，從制度上而不是從個(gè)人的角度分析問題出現(xiàn)的原因井辆。而且要能總結(jié)原因关筒，形成新的制度。如果一個(gè)問題不在制度上去避免杯缺，那么還會(huì)發(fā)成下一次平委。
如果什么都是 DevOps ，那么 DevOps 實(shí)際上什么也不是
如果把所有 DevOps 相關(guān)的內(nèi)容加總就能得到 DevOps夺谁，那和沒有定義 DevOps 一樣廉赔。如果我們沒辦法確定”什么不是 DevOps“，那同理我們也很難定義 DevOps 是什么匾鸥。
我試圖從上文中的認(rèn)識里蜡塌，提取出一些 DevOps 的必要元素來構(gòu)成 DevOps 的概念。這些元素缺一不可勿负，但單獨(dú)拿出來又不能構(gòu)成完整 DevOps 的概念馏艾。這樣既可以保證對 DevOps 的完整理解，又避免 DevOps 概念過大難以下手奴愉。
根據(jù)我自己的實(shí)踐琅摩，我認(rèn)為 DevOps 包括以下幾點(diǎn)原則：
- DevOps 有一個(gè)明確的目標(biāo)：通過充分的合作解決由于責(zé)任模糊而相互推諉的問題。（沒有 DevOps 痛點(diǎn)的團(tuán)隊(duì)自然也沒有 DevOps 的動(dòng)力）
- DevOps 是一個(gè)團(tuán)隊(duì)屬性而不是個(gè)人屬性锭硼，這個(gè)團(tuán)隊(duì)需要處理開發(fā)和維護(hù)任務(wù)房资。（有單一任務(wù)都不算是 DevOps 團(tuán)隊(duì)，因?yàn)闆]有合作解決 DevOps 痛點(diǎn)的動(dòng)機(jī)）
- DevOps 是一種團(tuán)隊(duì)改進(jìn)檀头，對于團(tuán)隊(duì)的表現(xiàn)有明確目標(biāo)和度量轰异。（沒有度量的改進(jìn)就是耍流氓）
- DevOps 是一種團(tuán)隊(duì)工作方式和文化，它包括了一系列促進(jìn) Dev 和 Ops 合作的具體技術(shù)和實(shí)踐以達(dá)到上述目標(biāo)暑始。（ DevOps 也不是缺乏技術(shù)的理論空談 ）
因此搭独，以下的描述都不是 DevOps：
- DevOps 不是一個(gè)職務(wù)或者角色，因?yàn)?DevOps 是團(tuán)隊(duì)屬性廊镜。
- 不存在” DevOps 團(tuán)隊(duì)“牙肝，只存在”以 DevOps 方式工作的團(tuán)隊(duì)“。
以上是我過去三年的 DevOps 實(shí)踐和咨詢經(jīng)歷嗤朴，希望能給正在做 DevOps 的你一些參考和提示配椭，并祝愿你在 DevOps 的實(shí)踐過程中更加順利。
