從 Leader 的角度理解 DevOps

在上一篇【從員工的角度理解 DevOps】中，我們從普通員工的視角理解了 DevOps。

現(xiàn)在來看看，從團(tuán)隊(duì) Leader 的角度，如何理解 DevOps。

回顧

回顧一下上一篇文章中的內(nèi)容，在上一篇文章中，我們盡量以通俗語言去說明什么是 DevOps，什么是 Agile。

簡單講，從員工的視覺來說，就是根據(jù)一個(gè)規(guī)則，拿著一系列工具，按照某個(gè)流程來干活兒。

1: Agile 是一堆很虛的方法論，復(fù)雜工具集合，適合產(chǎn)品線去使用。

2: DevOps 把研發(fā)線需要的方法論，復(fù)雜工具也納入了進(jìn)來，同時(shí)運(yùn)維也加入了。

從員工角度理解 DevOps 是什么樣的？

員工感覺不到從 DevOps 或 Agile 獲益，是普及環(huán)節(jié)出了問題，員工不知道怎么去運(yùn)用。

Agile 使得產(chǎn)品線員工們，有了先進(jìn)的方法論，研發(fā)線員工們的生產(chǎn)力沒有得到提升。

Agile（敏捷開發(fā)）或者 Lean（精益開發(fā)）并不是軟件領(lǐng)域的大佬們憑空想出來的，而是由工業(yè)制造領(lǐng)域得到了驗(yàn)證。

Agile（敏捷開發(fā)）是項(xiàng)目管理，產(chǎn)品研發(fā)流程方法論集合, 解決生產(chǎn)流程優(yōu)化，團(tuán)隊(duì)協(xié)同問題。

Agile 的使用者包含了【產(chǎn)品經(jīng)理，項(xiàng)目經(jīng)理，研發(fā)&測試，團(tuán)隊(duì) Leader】，DevOps 把【運(yùn)維】【決策者】這個(gè)角色也引入了進(jìn)來。

Agile 的方法論集中在了【項(xiàng)目管理】【產(chǎn)品管理】【團(tuán)隊(duì)管理】，DevOps 補(bǔ)充了【產(chǎn)品運(yùn)維】【客戶管理】。

換個(gè)角度，理解 Agile

從員工的角度來說，Agile 就是一系列需要遵守的規(guī)矩，例如，站會(huì)，Scrum 等等。

然而，對于 Leader，角色則應(yīng)是 Agile 的實(shí)施者。

注意，雖然 Leader 的角色變成了規(guī)矩的制造者，實(shí)施者，但不代表 Leader 只負(fù)責(zé)指揮，這是常見的錯(cuò)誤現(xiàn)象。

Leader 的疑問

問1：跟兄弟們提了無數(shù)次 Agile，為什么就是不執(zhí)行？

問2：產(chǎn)品經(jīng)理，項(xiàng)目經(jīng)理倒是按照 Agile 模版創(chuàng)建任務(wù)，為什么項(xiàng)目一直延期？

問3：引入了 Agile，為什么產(chǎn)品質(zhì)量還是上不去？

問4：為什么團(tuán)隊(duì)里還是沒有人愿意提建議？

問5：每個(gè)月都在做 1v1 溝通，但是還是有人離職？

問6：酒也喝了，罵也罵了，為什么兄弟們還是不服我？

問7：老板一直在質(zhì)疑效率，該做的都做了，到底哪里除了問題？

問8：花大價(jià)錢請了資深員工，效率還是上不去，是怎么回事？

接下來，我們以 Amazon 文化為例，簡單來聊一聊針對這些問題 Amazon 是如何做的，會(huì)有一些啟發(fā)。

1.了解團(tuán)隊(duì)生產(chǎn)力

身為 Leader，如果不了解團(tuán)隊(duì)的生產(chǎn)力，任何規(guī)劃都無從談起。

Leader 先要問一下自己，我的團(tuán)隊(duì)生產(chǎn)力如何？

相信很多 Leader 都沒有想過這個(gè)問題，我們以 Amazon 內(nèi)部的一個(gè)細(xì)節(jié)作為例子。

Amazon 的 Leader 對于團(tuán)隊(duì)的生產(chǎn)力是非常了解的，每一個(gè) Sprint 里，Task 的完成效率，代碼提交次數(shù)，Code Review 的頻率，故障處理的是時(shí)間等等。

在每一次的雙周會(huì)中，Leader 都會(huì)拿出這些數(shù)據(jù)，跟團(tuán)隊(duì)一起過一遍。注意，這里不是去【罵員工】做的慢，而是客觀評估。

Leader 通過這些細(xì)節(jié)數(shù)據(jù)，評估團(tuán)隊(duì)的當(dāng)前生產(chǎn)力。有了生產(chǎn)力數(shù)據(jù)，自然也能發(fā)現(xiàn)問題。

通過數(shù)據(jù)了解當(dāng)前團(tuán)隊(duì)生產(chǎn)力，leader 應(yīng)該對項(xiàng)目進(jìn)展，預(yù)期，有一桿秤。

2.了解你的團(tuán)隊(duì)

很多 Leader 都認(rèn)為了解團(tuán)隊(duì)。不過，真是如此嗎？我們根本不可能讓員工對 Leader 掏心置腹，不要有這種幻想。

從團(tuán)隊(duì)管理的角度來講，掏心置腹也不是一個(gè)好辦法，與其如此，倒不如去了解員工在團(tuán)隊(duì)里要什么？無非就這么幾個(gè)。

薪酬待遇

升職空間

學(xué)習(xí)空間

工作與生活平衡

避免內(nèi)卷

Leader 在與員工 1v1 的時(shí)候，是否會(huì)談?wù)撋鲜龅膯栴}？還是拿著項(xiàng)目【畫餅】，重復(fù)著：只要你干得好，都會(huì)有的。

Amazon 的 Leader 在與員工 1v1 的時(shí)候，經(jīng)常會(huì)談?wù)撨@些問題，而且非常直接。

比方說，在談?wù)撋殕栴}的時(shí)候，他們會(huì)提出目前無法升職的原因，比如，獨(dú)立完成的項(xiàng)目還不夠，代碼提交還不夠等等。同時(shí)，還會(huì)在后續(xù)的時(shí)間里，安排解決這類問題。

如果，一個(gè)員工經(jīng)常加班加點(diǎn)也完不成任務(wù)，Leader 會(huì)主動(dòng)提出疑問，是不是我安排的任務(wù)不合理，導(dǎo)致你的工作生活打破了平衡。

Amazon 的 Leader 通過這種簡單直接方式與員工溝通，得到每一個(gè)人在工作方面的想法，并解決問題。

了解團(tuán)隊(duì)，不是去了解每一個(gè)人的性格，喜好，而是去了解員工對團(tuán)隊(duì)的【期望值】是否一直在持續(xù)。

3.了解你的團(tuán)隊(duì)業(yè)務(wù)

一個(gè)團(tuán)隊(duì)里，最了解團(tuán)隊(duì)業(yè)務(wù)的人應(yīng)該是 Leader，而不是研發(fā)和產(chǎn)品。

某些情況下，員工升到 Leader 之后，就開始把經(jīng)歷全都放到了【管理】中。

久而久之，連業(yè)務(wù)里的核心架構(gòu)，數(shù)據(jù)，排期，需求等都不了解。最后，會(huì)出現(xiàn)這種情況。

Leader 向上匯報(bào)的時(shí)候，團(tuán)隊(duì)的員工跟著一起寫 PPT。

還是以 Amazon 為例，Amazon 的 Leader 對于內(nèi)部的核心業(yè)務(wù)是非常了解的，而且是實(shí)時(shí)的，并不是過期的數(shù)據(jù)。

所以，當(dāng) Amazon 的 Leader 們?nèi)ビ懻摳笮晚?xiàng)目的時(shí)候，整個(gè)流程會(huì)非常平滑，不會(huì)出現(xiàn)因?yàn)椴皇煜I(yè)務(wù)而卡頓的情況。

那他們是如何做到的？

其實(shí)很簡單，就是通過每天的晨會(huì)，周會(huì)以及項(xiàng)目討論會(huì)。比如，Amazon 的 Leader 一定會(huì)參加每天的晨會(huì)，因?yàn)槌繒?huì)是拿到業(yè)務(wù)實(shí)時(shí)情況的最好途徑。

再比如，項(xiàng)目架構(gòu)討論會(huì)也是 Leader 必參加的會(huì)議。

身為團(tuán)隊(duì) Leader，可以不是業(yè)務(wù)/技術(shù)最牛的人，但必須是最了解業(yè)務(wù)的人。

4.根據(jù)生產(chǎn)力，團(tuán)隊(duì)，業(yè)務(wù)制定規(guī)則

了解了生產(chǎn)力，團(tuán)隊(duì)狀況，以及業(yè)務(wù)，Leader 的下一個(gè)任務(wù)就是制定規(guī)則了。

在之前的文章中，我們也提到過，引入 Agile 的時(shí)候，一定不要抄襲。我們應(yīng)該做的是，根據(jù)業(yè)務(wù)需要制定規(guī)則。

我們會(huì)在后續(xù)的文章中，闡述如何根據(jù)不同業(yè)務(wù)屬性，決定規(guī)則側(cè)重點(diǎn)。

在 Amazon 的時(shí)候，分別在兩個(gè)不同的團(tuán)隊(duì)工作過。兩個(gè)團(tuán)隊(duì)的業(yè)務(wù)雖然都屬于云計(jì)算，不過業(yè)務(wù)屬性明顯不一樣。

第一個(gè)團(tuán)隊(duì)，不會(huì)和客戶有直接的接觸，屬于底層業(yè)務(wù)，所以，Leader 在制定規(guī)則時(shí)候，側(cè)重點(diǎn)放在了穩(wěn)定性，自動(dòng)化。

第二個(gè)團(tuán)隊(duì)，會(huì)和客戶有直接接觸，所以，Leader 制定規(guī)則的時(shí)候，側(cè)重點(diǎn)放在了功能迭代，監(jiān)控告警，自動(dòng)化。

規(guī)則要以一個(gè) Sprint 為周期，隨時(shí)可變。

5.了解工具的使用

規(guī)則離不開工具，所以工具的選擇以及使用是非常重要的。

身為 Leader，要非常了解團(tuán)隊(duì)工具的使用，而不是每次都跟員工去要數(shù)據(jù)。

Amazon 的 Leader 幾乎不會(huì)出現(xiàn)跟員工要數(shù)據(jù)這種情況。他們對于業(yè)務(wù)的工具使用非常嫻熟，甚至高于員工。

不要讓員工成為 Leader 的工具人。

6.讓員工具備解決問題的能力

硬實(shí)力：寫代碼，對編程語言的了解，使用 Redis，使用 Spring 等能力，來源于學(xué)校。

軟實(shí)力：解決問題的能力，比如，解決客戶提出的疑問，解決故障，系統(tǒng)重構(gòu)，代碼質(zhì)量，創(chuàng)新思維等，來源于公司。

根據(jù)個(gè)人的親身經(jīng)歷，如果對比北美大廠員工和國內(nèi)大廠員工的能力的話：

硬實(shí)力，在大家都在一個(gè)起跑線上，有些時(shí)候，國內(nèi)的員工硬實(shí)力要更強(qiáng)。

軟實(shí)力，國內(nèi)員工就稍遜一籌。

對于 Leader 來說，更需要員工具備強(qiáng)大的軟實(shí)力，即，解決問題的能力，而不是只懂得執(zhí)行的能力。

這也是為什么 Leader 在工作的時(shí)候，感覺到很累，什么事情都要親力親為，員工做出來的東西，跟 Leader 的期望有差距的原因。

在 Amazon，有一個(gè)對每一個(gè)員工的評估標(biāo)準(zhǔn)，叫做 Ownership。工作中，如果員工發(fā)現(xiàn)了某個(gè)問題，那么員工就要自己獨(dú)立解決這個(gè)問題。

包括，設(shè)計(jì)，實(shí)現(xiàn)，測試，部署，評估，運(yùn)維。如果中間出現(xiàn)困難，Leader 會(huì)主動(dòng)提供資源，幫助完成任務(wù)。

在 Amazon 幾乎所有的工作任務(wù)都是如此，久而久之，員工對于工作的態(tài)度有了轉(zhuǎn)變，即，要把事兒干好，而不是干完。

同時(shí)，對整個(gè)業(yè)務(wù)也會(huì)有大局觀，任何環(huán)節(jié)出了問題，每一個(gè)員工都可以出來解決問題。

員工本身也會(huì)有成就感。試想一下，如果寫了100行代碼，就結(jié)束這個(gè)任務(wù)的話，員工是不會(huì)有任何成就感的，只有親身經(jīng)歷100行代碼如何在業(yè)務(wù)中體現(xiàn)價(jià)值，才會(huì)有成就感。

給員工發(fā)揮的空間，給予認(rèn)可，同時(shí)要主動(dòng)給予幫助，以提升解決問題的能力。

換個(gè)角度，理解 DevOps

從員工的視覺，DevOps 擴(kuò)充了 Agile，并且把運(yùn)維角色也引入了進(jìn)來。從而研發(fā)線的員工也開始遵循 DevOps 的方法論，提升效率。

對于 Leader 來說，高度要更高一些。身為 Leader，在理解 DevOps 的時(shí)候，需要從四個(gè)角度去理解 DevOps，這也是 DevOps 的核心。

CAMS：

文化 Culture

自動(dòng)化 Automation

評估 Measurement

共享 Sharing

這四個(gè)核心，根據(jù)不同的團(tuán)隊(duì)規(guī)模，有著不同的方法論，Leader 需要根據(jù)自身情況而定。然而，普及 DevOps 的時(shí)候，一定要抓住這四個(gè)核心。

Leader 的疑問

問1：打造團(tuán)隊(duì)文化，太虛了，我該從何入手？

問2：我的團(tuán)隊(duì)里大家相互不服，很難一起合作。

問3：已經(jīng)安排員工進(jìn)行自動(dòng)化改造，效果甚微。

問4：已經(jīng)加了監(jiān)控告警，但是質(zhì)量還是上不去。

問5：在團(tuán)隊(duì)里進(jìn)行了幾次知識(shí)分享會(huì)，不過持續(xù)不到1個(gè)月就黃了。

問6：DevOps 把產(chǎn)品，研發(fā)，運(yùn)維，測試都引入了進(jìn)來，不過大家還是按照以前的方式來工作。

我們在討論 Agile 的時(shí)候，講述了6個(gè)需要注意的方向。身為 Leader，把握住這6個(gè)方向，可以達(dá)到【了解團(tuán)隊(duì)，運(yùn)營團(tuán)隊(duì)】的基本目的。

接下來，就應(yīng)該圍繞 CAMS，來提升團(tuán)隊(duì)的生產(chǎn)力了。

1.不要讓文化成為空談

一個(gè)企業(yè)一旦規(guī)模大起來之后，都會(huì)有文化出現(xiàn)，無論是成文的文化，比如，【科技向善】，【客戶為先】等等，還是非成文的文化。

要想讓文化深入到員工，不是一兩次動(dòng)員會(huì)或者一個(gè)勁地洗腦就能搞定的。大到一個(gè)項(xiàng)目，小到一個(gè)任務(wù)，都不能偏離文化，否則，對于文化的敬畏也就沒有了。

Amazon 有一個(gè)著名的 Leadership Principles，用16個(gè)語句，體現(xiàn)了 Amazon 的企業(yè)文化。

之前提到的 Ownership 就是其中之一。

Amazon 在平時(shí)工作中，充分利用了這16句真言。

比如，Leader 在對員工進(jìn)行評估的時(shí)候，會(huì)根據(jù) 16個(gè)原則來逐一進(jìn)行溝通，并且給出改進(jìn)意見和幫助。

在遇到項(xiàng)目優(yōu)先級的時(shí)候，也會(huì)運(yùn)用到此原則，16個(gè)原則中的第一條就是【洞察客戶】，即，如果某個(gè)項(xiàng)目關(guān)系到【客戶真正的需求】，那么無條件提前。

在架構(gòu)設(shè)計(jì)上，有爭執(zhí)的時(shí)候，會(huì)運(yùn)用到【發(fā)明和簡化】這個(gè)原則，以簡單，但是可用性好的設(shè)計(jì)為準(zhǔn)。

如果還是沒有辦法得到結(jié)論，就會(huì)運(yùn)用【贏得信任】這個(gè)原則，邀請高級別程序員來旁聽。

縱觀，Amazon 的做法，無論是安排任務(wù)，員工評估，產(chǎn)品設(shè)計(jì)等等環(huán)節(jié)，Leader 都在運(yùn)用著企業(yè)文化來運(yùn)營團(tuán)隊(duì)，這也是為什么新員工在 Amazon 不會(huì)出現(xiàn)迷茫的原因。

文化要體現(xiàn)在工作內(nèi)容中。

2.自動(dòng)化，要循序漸進(jìn)，每個(gè)人都參與進(jìn)來

自動(dòng)化就是一個(gè)技術(shù)范疇了。不過，這里我們先不講有哪些自動(dòng)化工具可以使用。

我們談一談進(jìn)行自動(dòng)化改造過程中可能出現(xiàn)的問題。

常見問題：

Leader 通常希望別的團(tuán)隊(duì)，或者公司幫我完成自動(dòng)化。

團(tuán)隊(duì)里，只有個(gè)別人負(fù)責(zé)自動(dòng)化，而且只負(fù)責(zé)自動(dòng)化，比如自動(dòng)化交付。

想在短時(shí)間內(nèi)，完成全流程自動(dòng)化。

自動(dòng)化是有了，產(chǎn)品質(zhì)量還是老樣子。

我們來看看 Amazon 的自動(dòng)化是一種什么體驗(yàn)。

Amazon 里，有一個(gè)部署神器，叫做 pipeline（不是 AWS 官網(wǎng)上的 Code Pipeline）。這個(gè) Pipeline 主要負(fù)責(zé)代碼的構(gòu)建，部署操作。

Pipeline 本身做的非常開放，團(tuán)隊(duì)可以根據(jù)需要，自行安排流程。

每一個(gè)新員工在入職的時(shí)候，第一堂課學(xué)習(xí)的就是如何使用 Pipeline，即，如何部署。新員工入職的前幾個(gè)月，很多任務(wù)也是部署上線。這在國內(nèi)可并不多見。

團(tuán)隊(duì)中，每一個(gè)員工都能熟練掌握 Pipeline 的操作，并且 Pipeline 流程的修改也會(huì)根據(jù)不同服務(wù)模塊，不斷進(jìn)行改變。

比如，某些模塊需要在部署前，進(jìn)行壓力測試，研發(fā)就會(huì)在 Pipeline 里添加壓力測試功能，當(dāng)然這也需要員工從頭到尾負(fù)責(zé)到底。

一個(gè) Pipeline 的自動(dòng)化，要做到新手操作不會(huì)出現(xiàn)故障，代碼跟著自動(dòng)化流程隨時(shí)改進(jìn)。

自動(dòng)化不是別人給我做全套，而是根據(jù)需要組裝。

3.絕不能忘了評估

在國內(nèi)工作的經(jīng)歷中，我發(fā)現(xiàn)【評估】這個(gè)階段是最容易被大家忽略的一部分。

什么是評估？其實(shí)，簡單點(diǎn)說的話，就是：怎么去判斷產(chǎn)品現(xiàn)在運(yùn)行的好還是不好？

我在面試新人的時(shí)候，也會(huì)經(jīng)常問這個(gè)問題，大概50%的人，不知道從何下手，大概40%的人會(huì)提出添加監(jiān)控告警，只有不到10%的人會(huì)愿意繼續(xù)深入探討【評估】。

這種情況其實(shí)是不好的，因?yàn)椋阋溃愕目蛻羰歉鶕?jù)【評估結(jié)果】來買單的，呈現(xiàn)給客戶的，也是產(chǎn)品的評估。

Amazon 對于評估這一塊兒做的非常嚴(yán)格。

在 Amazon 里，什么樣的微服務(wù)模塊，才可以上線？講一講我當(dāng)時(shí)的經(jīng)歷。

當(dāng)時(shí)，我負(fù)責(zé)了一個(gè)很小的功能模塊，功能很簡單，就是轉(zhuǎn)發(fā)客戶郵件，邏輯代碼寫下來，可能都用不到 2天。不過當(dāng)時(shí)，對于一個(gè)新人的我，就這么一個(gè)微服務(wù)，

花了我2個(gè)月的時(shí)間，才上線。這也是 Amazon 的一個(gè)風(fēng)格，一個(gè)新人，都要經(jīng)歷這么一個(gè)任務(wù)。

從最初的設(shè)計(jì)文檔，Review 超過3次，代碼框架，邏輯實(shí)現(xiàn)，單元測試，都需要團(tuán)隊(duì)進(jìn)行 Code Review。

還要邀請安全團(tuán)隊(duì)，進(jìn)行一次安全性評估。

然后，這個(gè)微服務(wù)的 Pipeline 也要自己根據(jù)特性，進(jìn)行搭建。

還有就是監(jiān)控指標(biāo)，監(jiān)控 Dashboard，告警策略，以及觸發(fā)告警之后的操作手冊。

只有你的微服務(wù)具備了上述的評估標(biāo)準(zhǔn)，才可以上線。

那這種看似【浪費(fèi)時(shí)間】的做法好不好？如果你去接手這種微服務(wù)的后期維護(hù)的話，你愿不愿意？

評估不是簡單的監(jiān)控內(nèi)存指標(biāo)，而是對整個(gè)流程的評估。

4.共享要成為習(xí)慣

很多團(tuán)隊(duì)都嘗試過進(jìn)行知識(shí)分享，或者跨團(tuán)隊(duì)知識(shí)分享。不過效果并不太好，因?yàn)檫@種強(qiáng)制學(xué)習(xí)的氛圍，很枯燥，也提不起員工的興趣。

即使學(xué)到了東西，也不知道什么時(shí)候去運(yùn)用。

Amazon 也會(huì)有不少分享，其中 COE 是最有意思的一個(gè)。

所謂 COE 就是拿著大事故，大問題，進(jìn)行分享，當(dāng)然，這不是批斗會(huì)，真是在分享經(jīng)驗(yàn)。

我在 Amazon 的那幾年，也因?yàn)椴僮鞑划?dāng)，或者代碼錯(cuò)誤，進(jìn)行過2次 COE，會(huì)議氛圍非常和諧，給出的事故細(xì)節(jié)非常客觀，有什么說什么。

請來的大佬們，也會(huì)根據(jù)自己的理解給出建議。注意，大佬們是對【系統(tǒng)】給建議，而不是對【人】給建議。

除了團(tuán)隊(duì)內(nèi)部的 COE，整個(gè)部門，整個(gè)公司也會(huì)有 COE，這種影響到了整個(gè)公司業(yè)務(wù)線的 COE 會(huì)在全公司直播，而且是大佬們在激烈地討論。

對員工們來說，從這種事故中獲取經(jīng)驗(yàn)，要比知識(shí)分享獲取經(jīng)驗(yàn)要深刻地多。

其次，Amazon 每天的晨會(huì)也是分享的一個(gè)重要手段，大家在談?wù)撁刻旃ぷ鞯臅r(shí)候，會(huì)隨性分享出自己的經(jīng)驗(yàn)以及收益。（所以，不要硬性規(guī)定晨會(huì)必須在15分鐘內(nèi)完成）

拿著問題/事故去共享，而不是知識(shí)分享。

總結(jié)

DevOps 對于 Leader 來說，是制定規(guī)矩的一個(gè)框架，就跟我們寫代碼一樣，如果想寫得好，就要深入了解框架，DevOps 亦如此。

Leader 在推行 DevOps 的時(shí)候，要隨時(shí)根據(jù)情況進(jìn)行調(diào)整，要讓員工們都參與進(jìn)來，而不是我說你寫。

DevOps 敏捷開發(fā)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。