“你在團(tuán)隊(duì)里是做什么的尝盼？”
“DevOps吞滞。”
“DevOps是什么呢盾沫？”
“DevOps是一種文化裁赠、一種實(shí)踐，目標(biāo)是加快軟件迭代速度赴精，讓團(tuán)隊(duì)更快交付價(jià)值佩捞。”
“能不能具體點(diǎn)蕾哟，你們?nèi)粘９ぷ鞯闹饕獌?nèi)容是什么一忱？”
“修Pipeline...”

作為一名開(kāi)發(fā)，在剛涉足DevOps領(lǐng)域的時(shí)候谭确，最難的就是和傳統(tǒng)運(yùn)維撇清關(guān)系帘营；等到DevOps不再被當(dāng)成是運(yùn)維，又容易被當(dāng)成是專職修Pipeline的人琼富。

DevOps在一遍遍被人們提及仪吧、一次次在項(xiàng)目中被實(shí)踐時(shí)，也在不斷地被重新定義鞠眉，DevOps是什么薯鼠？這個(gè)問(wèn)題可能到現(xiàn)在也比較難說(shuō)清楚，但是項(xiàng)目中的“DevOps”做了些什么械蹋，卻是清晰可見(jiàn)的出皇。

本文就結(jié)合筆者的切身經(jīng)歷，談一談關(guān)于DevOps交付的價(jià)值以及在企業(yè)轉(zhuǎn)型過(guò)程中遇到的一些問(wèn)題哗戈。

背景介紹

客戶是一家澳洲大型金融保險(xiǎn)企業(yè)郊艘，其IT部門(mén)總?cè)藬?shù)在千人以上，維護(hù)應(yīng)用兩百余個(gè)。在經(jīng)歷了幾年的收購(gòu)和合并之后纱注，在業(yè)務(wù)上指定了“將收購(gòu)來(lái)的多個(gè)品牌進(jìn)行整合”的大方針畏浆，于是IT部門(mén)也開(kāi)始面臨系統(tǒng)整合、業(yè)務(wù)線整合狞贱、網(wǎng)站合并的問(wèn)題刻获，同時(shí)客戶正在將他們的服務(wù)逐漸從自建數(shù)據(jù)中心向AWS公有云服務(wù)上遷移。

團(tuán)隊(duì)概覽

在數(shù)字化轉(zhuǎn)型的漫漫長(zhǎng)路中瞎嬉，該企業(yè)已經(jīng)在內(nèi)部搭建起了一套持續(xù)交付系統(tǒng)蝎毡，以Jenkins為中心，有制品庫(kù)氧枣、依賴管理沐兵、代碼管理、任務(wù)管理系統(tǒng)便监，敏捷實(shí)踐成熟扎谎。

我所在的團(tuán)隊(duì)是在整個(gè)組織向DevOps轉(zhuǎn)型中的一個(gè)比較關(guān)鍵的團(tuán)隊(duì)，肩負(fù)著CI/CD優(yōu)化茬贵、持續(xù)交付改進(jìn)簿透、運(yùn)維能力輸出的重任。類似的團(tuán)隊(duì)?wèi)?yīng)該在很多DevOps轉(zhuǎn)型的組織里都有解藻，負(fù)責(zé)維護(hù)CI/CD基礎(chǔ)設(shè)施老充、搭建應(yīng)用開(kāi)發(fā)腳手架、維護(hù)基礎(chǔ)設(shè)施變更螟左、做各種自動(dòng)化的工作（姑且就將這類團(tuán)隊(duì)稱之為Platform團(tuán)隊(duì)）啡浊。

比較特殊的是我在的這個(gè)團(tuán)隊(duì)實(shí)行輪崗制，由產(chǎn)品團(tuán)隊(duì)的成員（通常是開(kāi)發(fā)人員）定期輪換到Platform團(tuán)隊(duì)胶背，帶著在產(chǎn)品團(tuán)隊(duì)遇到但是沒(méi)能解決的問(wèn)題巷嚣，在這個(gè)團(tuán)隊(duì)中尋求最佳實(shí)踐和解決方案，一段時(shí)間后（通常是三個(gè)月）钳吟，開(kāi)發(fā)人員從Platform團(tuán)隊(duì)回到開(kāi)發(fā)團(tuán)隊(duì)廷粒，同時(shí)將DevOps技能和最佳實(shí)踐帶到產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)。

整個(gè)Platform團(tuán)隊(duì)基本維持在3-5人的規(guī)模红且，有一個(gè)IM（Iteration Manager迭代經(jīng)理）坝茎，其余全是開(kāi)發(fā)人員。

取得的成就

回顧過(guò)去的五個(gè)月暇番，Platform團(tuán)隊(duì)一共經(jīng)歷了10個(gè)迭代（每個(gè)迭代兩個(gè)星期）嗤放，我梳理了一下每個(gè)迭代的工作內(nèi)容，整理出主要成就如下：

• 圍繞CI/CD做了很多優(yōu)化壁酬，比如簡(jiǎn)化Jenkins slave創(chuàng)建流程次酌、給自動(dòng)化腳本（基礎(chǔ)設(shè)施代碼）貢獻(xiàn)了許多新功能恨课。
• 新技術(shù)試點(diǎn)，比如嘗試將靜態(tài)文件部署到AWS S3中代替Apache服務(wù)岳服。
• 為應(yīng)用設(shè)置監(jiān)控剂公，更新了基礎(chǔ)設(shè)施腳本用于開(kāi)啟監(jiān)控，并協(xié)助應(yīng)用團(tuán)隊(duì)將配置腳本應(yīng)用到各個(gè)環(huán)境吊宋。
• 團(tuán)隊(duì)之間的溝通诬留，了解開(kāi)發(fā)團(tuán)隊(duì)痛點(diǎn)，幫助開(kāi)發(fā)團(tuán)隊(duì)找到能夠解決問(wèn)題的團(tuán)隊(duì)（權(quán)限贫母、責(zé)任劃分、知識(shí)傳遞）盒刚，技能培訓(xùn)等腺劣。
• 響應(yīng)變化，解決技術(shù)難題（雖然我認(rèn)為這更像是一個(gè)溝通+權(quán)限的問(wèn)題因块，但是其他所有團(tuán)隊(duì)都認(rèn)為是技術(shù)難題橘原，那我也就這樣認(rèn)為吧），以及修復(fù)一些類似于硬盤(pán)空間已滿涡上、網(wǎng)絡(luò)延遲趾断、權(quán)限的問(wèn)題。

遇到的問(wèn)題

當(dāng)然在交付價(jià)值的同時(shí)吩愧，有很多痛點(diǎn)是非常折磨人的：

• 權(quán)限分配：作為一個(gè)跨開(kāi)發(fā)團(tuán)隊(duì)工作的團(tuán)隊(duì)芋酌，不但沒(méi)有擁有比開(kāi)發(fā)團(tuán)隊(duì)更多的權(quán)限，甚至連開(kāi)發(fā)團(tuán)隊(duì)的一些權(quán)限都沒(méi)有雁佳，比如不能向開(kāi)發(fā)團(tuán)隊(duì)的代碼庫(kù)提交代碼(修改基礎(chǔ)設(shè)施代碼需要這個(gè)權(quán)限)脐帝，比如缺少Linux權(quán)限導(dǎo)致服務(wù)器底層問(wèn)題沒(méi)法直接修復(fù)，再比如 Jenkins 的問(wèn)題追蹤到了服務(wù)層需要維護(hù)Jenkins的團(tuán)隊(duì)支持糖权，因?yàn)樯婕暗紺I／CD的應(yīng)用是由別的團(tuán)隊(duì)在管理堵腹。

• 溝通效率：為了解決一個(gè)bug，有時(shí)候要花上兩周的時(shí)間發(fā)郵件星澳，找關(guān)鍵人物疚顷，組織會(huì)議，跟不同的人解釋五遍以上的上下文（技術(shù)細(xì)節(jié)的上下文是很繁瑣的）禁偎，最后解決問(wèn)題的人還很有可能不是自己團(tuán)隊(duì)的（沒(méi)有權(quán)限）腿堤。因?yàn)榇蠹移綍r(shí)都很忙，而且建卡工作的方式讓一部分人對(duì)團(tuán)隊(duì)請(qǐng)求幫助的問(wèn)題不是很熱心届垫，這種情況在溝通的時(shí)候如果表現(xiàn)得情商不夠高释液，對(duì)方就會(huì)要你發(fā)郵件給他們團(tuán)隊(duì)然后等 IM 建卡，規(guī)劃到迭代里再說(shuō)了装处，我遇到過(guò)一次這樣的情況误债，最后還是通過(guò)社工手段拿下了這個(gè)關(guān)鍵人物浸船，過(guò)程不可謂不曲折。

• 明確需求：Platform團(tuán)隊(duì)并不交付業(yè)務(wù)價(jià)值寝蹈，因此沒(méi)有BA(Business analyst業(yè)務(wù)分析師李命，通常扮演梳理需求的角色)，建卡的事基本都由IM和Dev來(lái)做箫老，雖然感覺(jué)上是合理的封字，但實(shí)施起來(lái)卻遇到很多問(wèn)題，究其根本就是對(duì)需求的定義和劃分不夠明確耍鬓，導(dǎo)致最后挪卡的時(shí)候大家都說(shuō)不準(zhǔn)這張卡算不算完成了阔籽，只能用拍腦袋的方式來(lái)決定。

• 質(zhì)量分析：同上牲蜀，團(tuán)隊(duì)缺少Q(mào)A(Quality Assurance笆制，質(zhì)量工程師，測(cè)試人員)涣达，Dev們都是自己做卡自己測(cè)在辆，有時(shí)候會(huì)結(jié)對(duì)測(cè)試，但也會(huì)因?yàn)閷?duì)需求理解不充分度苔，或者說(shuō)拆卡拆得有問(wèn)題匆篓，導(dǎo)致一些卡完成得質(zhì)量不夠，直接影響受依賴的卡寇窑。舉個(gè)例子鸦概，部署監(jiān)控需要自動(dòng)化腳本的兩個(gè)模塊支持，兩個(gè)模塊被分為兩張卡疗认，在做第一張卡的時(shí)候遇到了諸多問(wèn)題完残，好不容易把代碼提交到別人的版本庫(kù)里了，在做第二張卡的時(shí)候卻發(fā)現(xiàn)第一張卡代碼里多寫(xiě)了一對(duì)引號(hào)横漏，導(dǎo)致整個(gè)邏輯實(shí)現(xiàn)失敗谨设，這個(gè)時(shí)候再回過(guò)頭來(lái)改之前的代碼，又要重新解決之前遇到的各種問(wèn)題（溝通缎浇、權(quán)限扎拣，PS：這個(gè)時(shí)候做第一張卡的人還下了項(xiàng)目），周期和浪費(fèi)的工時(shí)是可想而知的素跺。

• 人員輪崗：這是 IM 一直很頭疼的一件事二蓝，Platform團(tuán)隊(duì)大量的時(shí)間花在給新來(lái)的團(tuán)隊(duì)成員輸入上下文、同時(shí)又有成員離開(kāi)團(tuán)隊(duì)要交接工作指厌、尤其在溝通重要的工作中刊愚，成員的離開(kāi)意味著需要新的人重新和干系人建立聯(lián)系，再者踩验，一些成員因?yàn)轫?xiàng)目上的痛點(diǎn)鸥诽，不是很有心思工作在團(tuán)隊(duì)的事務(wù)上商玫，而是更關(guān)心自己過(guò)段時(shí)間會(huì)被分配到那個(gè)團(tuán)隊(duì)，如此種種都對(duì)團(tuán)隊(duì)的價(jià)值交付造成了很大的困擾牡借。舉一個(gè)例子拳昌，有一個(gè)端到端測(cè)試工具一直由Platform團(tuán)隊(duì)維護(hù)，從我加入Platform團(tuán)隊(duì)開(kāi)始钠龙，這個(gè)測(cè)試工具就打算新增一個(gè)集成遠(yuǎn)程瀏覽器引擎的功能炬藤，這是一個(gè)非常有價(jià)值的功能，因?yàn)殚_(kāi)發(fā)團(tuán)隊(duì)長(zhǎng)期苦于瀏覽器版本支持過(guò)少碴里，端到端測(cè)試不穩(wěn)定沈矿；但是在實(shí)現(xiàn)過(guò)程中一直存在一個(gè)網(wǎng)絡(luò)問(wèn)題，這張卡先后被關(guān)閉咬腋、開(kāi)啟细睡、標(biāo)記完成、又重新開(kāi)啟帝火，經(jīng)歷了大概五六個(gè)人的手，困擾我們的網(wǎng)絡(luò)問(wèn)題直到Platform團(tuán)隊(duì)解散湃缎，都沒(méi)能解決犀填。

• 關(guān)鍵角色管理：做了什么很重要，有時(shí)候讓別人知道你做了什么比做了什么更重要嗓违。這一點(diǎn)在 Platform 團(tuán)隊(duì)體現(xiàn)的得尤為明顯九巡；在交付團(tuán)隊(duì)中，開(kāi)發(fā)如果發(fā)現(xiàn)資源不足蹂季，需要和TL(Tech Lead 或是Team Lead冕广，可以理解為項(xiàng)目組長(zhǎng))或者PM(Production Manager 產(chǎn)品經(jīng)理)溝通，如果缺少合適的匯報(bào)對(duì)象偿洁，一方面在團(tuán)隊(duì)需要外部支持或更多資源（比如權(quán)限）的時(shí)候得不到及時(shí)的支持撒汉，另一方面意味著團(tuán)隊(duì)缺少了更高的視角來(lái)實(shí)時(shí)回顧自己做的事情是否是正確的，方向有沒(méi)有走偏涕滋，或者是不是又在造別人造過(guò)的輪子睬辐。我在團(tuán)隊(duì)解散后的回顧會(huì)議中，IM還堅(jiān)持認(rèn)為我們團(tuán)隊(duì)被解散是因?yàn)闆](méi)有一個(gè)強(qiáng)有力的領(lǐng)導(dǎo)在背后支持宾肺，這也從側(cè)面反映了我們沒(méi)有找到合適的匯報(bào)人溯饵，告訴他，我們?cè)谧鍪裁聪怯茫?tīng)他說(shuō)丰刊，我們下一步可以做什么。

分析

問(wèn)題背后的原因及可能的改進(jìn)方案

團(tuán)隊(duì)解散后經(jīng)過(guò)一段時(shí)間的沉淀增拥，我針對(duì)以上痛點(diǎn)與過(guò)往的成員一一交談啄巧，了解了他們的想法寻歧，總結(jié)分析出了以下原因，以及可能的解決方案棵帽。

原因1：團(tuán)隊(duì)方向不清晰

不同于交付業(yè)務(wù)價(jià)值的產(chǎn)品團(tuán)隊(duì)熄求，Platform團(tuán)隊(duì)不對(duì)某一個(gè)具體的產(chǎn)品負(fù)責(zé)，也不直接產(chǎn)出業(yè)務(wù)價(jià)值逗概，加上Platform團(tuán)隊(duì)對(duì)交付的價(jià)值缺乏有效的指標(biāo)度量弟晚，造成了團(tuán)隊(duì)方向不清晰的狀況。

可能的改進(jìn)方案：Platform 團(tuán)隊(duì)?wèi)?yīng)該是屬于架構(gòu)師的一個(gè)機(jī)動(dòng)團(tuán)隊(duì)逾苫，在團(tuán)隊(duì)方向不清晰的時(shí)候應(yīng)該立即與利益相關(guān)者(Stakeholder)溝通卿城，即與架構(gòu)師取得聯(lián)系，取得高視角的資源铅搓，最好能建立交付價(jià)值指標(biāo)瑟押，比如Platform團(tuán)隊(duì)的目標(biāo)是加快持續(xù)交付，提高交付質(zhì)量星掰，那就可視化開(kāi)發(fā)團(tuán)隊(duì)發(fā)布周期多望、質(zhì)量報(bào)告，讓每個(gè)團(tuán)隊(duì)成員看到Platform團(tuán)隊(duì)交付價(jià)值的體現(xiàn)氢烘，從而明確團(tuán)隊(duì)方向怀偷。

原因2：團(tuán)隊(duì)角色缺失

在架構(gòu)師不能全權(quán)參與團(tuán)隊(duì)工作的情況下（甚至Platform團(tuán)隊(duì)還可能沒(méi)有IM），一幫Dev就很容易失去對(duì)團(tuán)隊(duì)整體的感知播玖，每個(gè)Dev只關(guān)心自己手里的工作椎工，迭代開(kāi)始初期容易考慮不到全局影響、不能準(zhǔn)確建卡蜀踏，迭代進(jìn)行時(shí)因?yàn)闆](méi)有合適的匯報(bào)人因而跨團(tuán)隊(duì)交流困難维蒙，迭代結(jié)束時(shí)沒(méi)有優(yōu)質(zhì)的回顧。
在Micromanagement Culture（微觀管理文化）中有一個(gè)Alignment(校準(zhǔn))和Autonomy(自治)兩個(gè)互斥的指標(biāo)果覆，我們使用這兩個(gè)指標(biāo)作為向量構(gòu)成四個(gè)象限颅痊，如下圖所示：

圖片來(lái)源：Spotify Engineering Culture

• 高校準(zhǔn)、低自治的團(tuán)隊(duì)由領(lǐng)導(dǎo)決定做什么以及怎么做局待，團(tuán)隊(duì)只需要執(zhí)行八千，這樣會(huì)形成“領(lǐng)導(dǎo)說(shuō)什么就是什么”的局面；
• 而高校準(zhǔn)且高自治的團(tuán)隊(duì)是由領(lǐng)導(dǎo)指出要解決的問(wèn)題以及原因燎猛，然后由團(tuán)隊(duì)成員相互合作共同找到問(wèn)題的解決方案恋捆；
• 低校準(zhǔn)、低自治的團(tuán)隊(duì)則缺乏活力重绷，只能循規(guī)蹈矩沸停；
• 而高自治、低校準(zhǔn)的團(tuán)隊(duì)成員可以做任何他們想做的事情昭卓，領(lǐng)導(dǎo)則很無(wú)助因?yàn)闆](méi)有人關(guān)心真正需要解決的問(wèn)題愤钾。

在敏捷團(tuán)隊(duì)中瘟滨，如果團(tuán)隊(duì)成員只剩下Dev，情形則很有可能變成圖中左下象限（也有些許右下）的情況能颁，要想達(dá)到右上象限的期望狀態(tài)杂瘸，需要提高自治，更多的是校準(zhǔn)伙菊。

可能的改進(jìn)方案：在意識(shí)到這個(gè)問(wèn)題的時(shí)候败玉，團(tuán)隊(duì)需要一個(gè)關(guān)鍵人物出面充當(dāng)領(lǐng)導(dǎo)者的角色，扮演這個(gè)角色的人必須關(guān)注團(tuán)隊(duì)交付價(jià)值镜硕、目標(biāo)和方向运翼，并且有強(qiáng)大的溝通能力讓團(tuán)隊(duì)成員目標(biāo)一致；和利益相關(guān)者加強(qiáng)溝通兴枯，保證團(tuán)隊(duì)方向不會(huì)跑偏血淌。

根本原因

Platform團(tuán)隊(duì)成立初期被定義為一個(gè)立意高遠(yuǎn)（DevOps轉(zhuǎn)型）的組織，但是在項(xiàng)目實(shí)施過(guò)程中變得越來(lái)越邊緣化财剖，其中有“人”的原因悠夯，有組織架構(gòu)的原因，當(dāng)然還有一些客觀原因躺坟。但我突然意識(shí)到這背后有一個(gè)原因一直忽視了疗疟，那就是——我們?cè)趯?shí)踐DevOps反模式。

國(guó)內(nèi)近年來(lái)一直在對(duì)DevOps如何落地爭(zhēng)論不休瞳氓，DevOps提倡的是打破開(kāi)發(fā)和運(yùn)維的部門(mén)墻，將開(kāi)發(fā)和運(yùn)維（的能力）放在一個(gè)團(tuán)隊(duì)栓袖。然而國(guó)內(nèi)大部分項(xiàng)目的現(xiàn)狀是匣摘，開(kāi)發(fā)不具備運(yùn)維技能和意識(shí)，也不愿意做“背鍋俠”（要求開(kāi)發(fā)做運(yùn)維一定程度上犧牲了開(kāi)發(fā)的利益裹刮，比如亞馬遜的開(kāi)發(fā)每隔一周會(huì)被要求24小時(shí)On-call）音榜。

因此一些公司選擇了在項(xiàng)目中先成立一個(gè) “DevOps團(tuán)隊(duì)” 作為過(guò)渡，再慢慢將CI/CD的理念和技能擴(kuò)散到其他團(tuán)隊(duì)捧弃，但是這種方式稍不注意就會(huì)變成“換了個(gè)名字的Ops ”赠叼，因?yàn)楣ぷ鲀?nèi)容相似，寫(xiě)腳本违霞、做高可用嘴办，這些是傳統(tǒng)運(yùn)維也會(huì)做的事情，這種形式非常不利于團(tuán)隊(duì)思維的轉(zhuǎn)變买鸽，“團(tuán)隊(duì)整體對(duì)最終交付物負(fù)責(zé)”才是DevOps的精要涧郊，而不是把團(tuán)隊(duì)按職責(zé)劃分（只對(duì)流程負(fù)責(zé)）。

這樣的要求無(wú)異是給項(xiàng)目成員增加了工作量和責(zé)任眼五，對(duì)他們提出了更高的要求妆艘。然而很多職員不愿意無(wú)回報(bào)地多背負(fù)一些責(zé)任彤灶，比如說(shuō)開(kāi)發(fā)，誰(shuí)不愿意每天寫(xiě)點(diǎn)代碼一提交就早早回家批旺，DevOps要求他們得看著新功能上線幌陕，確保無(wú)誤之后才能離開(kāi)；所以DevOps的推行在產(chǎn)品團(tuán)隊(duì)中是有阻力的汽煮，因此DevOps的成功不光需要團(tuán)隊(duì)內(nèi)部努力搏熄，也需要得到高層支持并掃除障礙。

反思

在一個(gè)不確定性多發(fā)的時(shí)代逗物，快速的從成敗經(jīng)驗(yàn)中學(xué)習(xí)比找尋正確的路徑更加重要搬卒。——ThoughtWorks高級(jí)咨詢師顧宇

• 盡早找到關(guān)鍵角色翎卓，并且管理好利益相關(guān)人契邀。這一點(diǎn)在一個(gè)扁平化組織里往往是最容易被忽視的，在意識(shí)到要和 Stackholders(利益相關(guān)者)建立聯(lián)系之前失暴，Platform 團(tuán)隊(duì)走了很多彎路坯门，也錯(cuò)失了很多機(jī)會(huì)。
• 讓事情發(fā)生比如何發(fā)生更重要逗扒。應(yīng)該說(shuō)在這5個(gè)月的工作中古戴，我認(rèn)為最有價(jià)值的是最后兩個(gè)迭代開(kāi)始真正搜集來(lái)自應(yīng)用團(tuán)隊(duì)的需求，開(kāi)始在兩地組織各個(gè)團(tuán)隊(duì)的 TL 開(kāi)會(huì)搜集痛點(diǎn)和解決方案矩肩。作為 Platform 團(tuán)隊(duì)的一員现恼，這件事其實(shí)我早就意識(shí)到會(huì)是非常有價(jià)值的，但始終沒(méi)有去做黍檩，總是顧慮不知道怎么去開(kāi)始叉袍、去推動(dòng)，擔(dān)心TL 們提出的問(wèn)題不能得到真正解決刽酱。但是最后這件事終于發(fā)生了喳逛，才意識(shí)到真的是非常有價(jià)值，而且早該這么做了棵里。關(guān)于這點(diǎn)在我還在 ThoughtWorks 試用期的時(shí)候我的 Buddy(由公司安排負(fù)責(zé)伴隨新員工渡過(guò)試用期的人) 給了我一個(gè)非常好的建議润文，就是決定在講一個(gè)分享之前先把日程表（邀請(qǐng)郵件）發(fā)出來(lái)，這種看似是“Deadline driven(截止日期驅(qū)動(dòng))”的方式殿怜，背后暗含了“這件事情必須發(fā)生”的道理典蝌，這和 MVP(Minumum viable product，產(chǎn)品原型) 的原理也是一樣的头谜，先上線赠法，再搜集反饋，迭代改進(jìn)；就算它是一個(gè)錯(cuò)誤的行為砖织，這也是一次有價(jià)值的試錯(cuò)款侵。

我們是否還需要DevOps團(tuán)隊(duì)

結(jié)合我自身的經(jīng)歷，“DevOps 團(tuán)隊(duì)”應(yīng)該是一次有價(jià)值的試錯(cuò)侧纯，讓我看到了這種方式的一些弊端新锈，應(yīng)用開(kāi)發(fā)團(tuán)隊(duì)自身如果不具備產(chǎn)品思維，要由一個(gè)獨(dú)立的團(tuán)隊(duì)去影響它們是很難的眶熬，這種實(shí)踐下的 DevOps 團(tuán)隊(duì)就像是披著 DevOps 外衣的 Ops 團(tuán)隊(duì)妹笆，不能產(chǎn)生理想的價(jià)值。

相比之下如果有一種自上而下的方式讓開(kāi)發(fā)團(tuán)隊(duì)基于已有業(yè)務(wù)基礎(chǔ)之上去優(yōu)化交付流程娜氏，并對(duì)每一個(gè)提交的最終價(jià)值負(fù)責(zé)拳缠，將產(chǎn)品思維真正植入到開(kāi)發(fā)團(tuán)隊(duì)，從而達(dá)到全局優(yōu)化的效果贸弥，這種做法才更符合真正的 DevOps 精神窟坐。

文／ThoughtWorks杜屹東