[[348623]]

 關(guān)于開(kāi)發(fā)人員是如何因構(gòu)造其日常工作而導(dǎo)致生產(chǎn)力下降的文章很多。常見(jiàn)的一個(gè)例子是：在一天中安排了很多非必要的會(huì)議，因此沒(méi)人能進(jìn)入深度聚焦模式。今天，我想研究開(kāi)發(fā)人員生產(chǎn)力方面的最大殺手：配置和設(shè)置DevOps工作流程的方式。在幾乎所有情況下，我都遇到了一些捷徑可以幫助您避免大多數(shù)問(wèn)題。

#1：無(wú)適當(dāng)工具全面投入微服務(wù)

當(dāng)項(xiàng)目以整體設(shè)置中工作時(shí)，所有的工作都可以進(jìn)行。工具鏈已準(zhǔn)備好很好地處理這一個(gè)整體，但是，要更改一件小部分，需要部署整個(gè)整體。需要運(yùn)行端到端測(cè)試，以驗(yàn)證一切仍然正常。整體越大，效率越低。因此，團(tuán)隊(duì)繼續(xù)前進(jìn)并采用微服務(wù)。他們的初次經(jīng)驗(yàn)很棒，同事們可以獨(dú)立進(jìn)行單獨(dú)的服務(wù)，部署頻率提高，每個(gè)人都很高興。

問(wèn)題開(kāi)始于團(tuán)隊(duì)不使用微服務(wù)，而對(duì)“微”則過(guò)于重視。從工具的角度來(lái)看，您現(xiàn)在將不得不處理更多的yml文件，docker文件，以及這些服務(wù)的變量之間的依賴關(guān)系，路由問(wèn)題等。它們需要更新和維護(hù)。您的CI/CD設(shè)置，組織結(jié)構(gòu)以及人員總數(shù)可能需要重新調(diào)整。

如果出于任何原因而進(jìn)入微服務(wù)，請(qǐng)確保計(jì)劃足夠的時(shí)間來(lái)重組工具設(shè)置和工作流程。只需計(jì)算您需要維護(hù)的各個(gè)位置的腳本數(shù)量即可?？紤]一下這將花費(fèi)多長(zhǎng)時(shí)間，由誰(shuí)負(fù)責(zé)，以及哪些工具可以幫助您控制這一情況。如果選擇工具，請(qǐng)確保他們擁有一個(gè)用戶社區(qū)。

#2：未將配置外部化的容器

在很多情況下，容器化都是一項(xiàng)了不起的技術(shù)。但是，它帶有價(jià)值標(biāo)簽，可能會(huì)影響您的生產(chǎn)率。從安全角度以及通過(guò)必要的配置和環(huán)境管理等方面來(lái)看，容器會(huì)增加開(kāi)銷。如果您不同意團(tuán)隊(duì)的某些約定，那么容器也會(huì)損害您的生產(chǎn)力和開(kāi)發(fā)人員的經(jīng)驗(yàn)。

我看到的最常見(jiàn)的錯(cuò)誤是：將配置文件或環(huán)境變量構(gòu)建到容器中。容器化的核心思想是可移植性。通過(guò)硬編碼配置，您將必須開(kāi)始為每個(gè)單個(gè)環(huán)境編寫(xiě)文件和管道。您要更改URL嗎?很好，請(qǐng)繼續(xù)在20個(gè)不同的地方進(jìn)行更改，然后重新構(gòu)建所有內(nèi)容。

在開(kāi)始大規(guī)模使用和在生產(chǎn)環(huán)境中使用容器之前，請(qǐng)先坐下并同意對(duì)您重要的配置約定。確保在代碼審查和回顧中始終如一地介紹這一點(diǎn)。重構(gòu)這種體驗(yàn)是一種痛苦。

#3：錯(cuò)誤地采用KUBERNETES

所有人都對(duì)這個(gè)名為Kubernetes的開(kāi)源項(xiàng)目大肆宣傳。但是，Kubernetes很難保持運(yùn)行，也很難集成到您的開(kāi)發(fā)人員流程中，同時(shí)又要保持較高的生產(chǎn)率和經(jīng)驗(yàn)。很多事情都會(huì)出錯(cuò)：

Kubernetes最壞的情況：XY同事真的很想弄臟他的手，并在線找到了入門指南。他們?cè)诼銠C(jī)上建立了一個(gè)集群，它與該測(cè)試應(yīng)用程序一起很好地工作。然后，他們開(kāi)始遷移第一個(gè)應(yīng)用程序，并要求其同事開(kāi)始使用kubectl與集群進(jìn)行交互。現(xiàn)在，團(tuán)隊(duì)的一半專注于學(xué)習(xí)這項(xiàng)新技術(shù)?，F(xiàn)在，正在維護(hù)集群的可憐人將在第二個(gè)生產(chǎn)工作負(fù)荷達(dá)到第一的時(shí)候全職工作。CI/CD的設(shè)置完全沒(méi)有做好應(yīng)對(duì)這些的準(zhǔn)備，并且由于整個(gè)團(tuán)隊(duì)都在嘗試掌握Kubernetes，因此總體生產(chǎn)率正在下降。

可以做些什么來(lái)防止這種情況： Kubernetes是一項(xiàng)很棒的技術(shù)，如果做得正確，可以幫助獲得類似于PaaS的開(kāi)發(fā)人員體驗(yàn)。畢竟，它是Borg的后代。Borg是Google構(gòu)建的平臺(tái)，可讓其軟件工程師輕松構(gòu)建可大規(guī)模擴(kuò)展的應(yīng)用程序。因此，它是對(duì)Google內(nèi)部平臺(tái)的一種開(kāi)源解釋。

最佳做法：

團(tuán)隊(duì)盡可能不要自己建立和運(yùn)行準(zhǔn)系統(tǒng)群集，而應(yīng)使用托管的Kubernetes服務(wù)。閱讀有關(guān)托管Kubernetes集群最適合您的需求的評(píng)論。在我撰寫(xiě)本文時(shí)，從純粹的技術(shù)角度來(lái)看，谷歌Kubernetes引擎(GKE)到目前為止是最好的(盡管權(quán)限架構(gòu)仍然很痛苦–權(quán)限問(wèn)題，谷歌?)緊隨其后的是Azure Kubernetes Service( AKS)。亞馬遜的Elastic Kubernetes服務(wù)(Amazon EKS)并正在追趕。

使用自動(dòng)化平臺(tái)或持續(xù)交付API。它們使您可以在開(kāi)發(fā)人員看不見(jiàn)的情況下在K8上運(yùn)行工作負(fù)載。使所有人都暴露于整個(gè)設(shè)置的復(fù)雜性幾乎為零。我知道“每個(gè)人都應(yīng)該能夠做所有事情”的論點(diǎn)，但是變革的步伐是如此之快，而且自動(dòng)化管理的程度如此之高，以至于這確實(shí)沒(méi)有道理。

如果團(tuán)隊(duì)真的希望開(kāi)發(fā)人員自己管理Kubernetes集群，那么他們應(yīng)該給他們足夠的時(shí)間來(lái)真正了解架構(gòu)，設(shè)計(jì)模式，kubectl等，并真正專注于此。

#4：忘記做持續(xù)交付

“等等，我已經(jīng)有一個(gè)配置項(xiàng)工具”。常見(jiàn)的誤解是，如果有持續(xù)集成設(shè)置，則工作做得很好。您仍然缺少連續(xù)交付!許多供應(yīng)商創(chuàng)造了“ CI/CD工具”一詞，這并沒(méi)有給您帶來(lái)困惑，如果您擁有Jenkins，CircleCI等，則給您留下了連續(xù)交付的印象-事實(shí)并非如此。

經(jīng)過(guò)精心調(diào)整的“持續(xù)交付”設(shè)置(無(wú)論是自行編寫(xiě)的還是“即服務(wù)”的設(shè)置)，更是團(tuán)隊(duì)工具鏈中的“粘合劑”：

它使從源代碼控制系統(tǒng)到CI-Pipeline，從數(shù)據(jù)庫(kù)到群集以及從DNS設(shè)置到IaC的所有不同組件都可以集成到簡(jiǎn)化的便捷開(kāi)發(fā)人員體驗(yàn)中。

這是一種結(jié)構(gòu)，維護(hù)和管理數(shù)量不斷增長(zhǎng)的yml和配置腳本的方法。如果做得好，這將使您的開(kāi)發(fā)人員可以利用CI-Pipeline構(gòu)建的工件動(dòng)態(tài)地啟動(dòng)環(huán)境，并通過(guò)預(yù)配置的數(shù)據(jù)庫(kù)和已設(shè)置的一切進(jìn)行全面配置。

它可以用作配置狀態(tài)的版本控制系統(tǒng)，并具有可審核的記錄，以記錄部署在何處，以何種配置運(yùn)行，并允許您來(lái)回滾動(dòng)以及管理藍(lán)/綠/金絲雀的部署。

通過(guò)精心設(shè)計(jì)的CD設(shè)置，可以改變開(kāi)發(fā)人員的工作效率。它們使開(kāi)發(fā)人員能夠自助服務(wù)，減少了團(tuán)隊(duì)內(nèi)部的依賴，同時(shí)提高了設(shè)置的可維護(hù)性。

使用這些做法的團(tuán)隊(duì)會(huì)更頻繁，更快地發(fā)布，表現(xiàn)出總體上更高的績(jī)效和滿意度。

#5：無(wú)法維持的測(cè)試自動(dòng)化

沒(méi)有自動(dòng)化，就不可能進(jìn)行有效的測(cè)試。持續(xù)交付帶來(lái)了不破壞任何東西的持續(xù)責(zé)任。您需要不斷確保不要陷入倒置測(cè)試金字塔的 陷阱。為此，您需要能夠在開(kāi)發(fā)生命周期的正確點(diǎn)運(yùn)行正確的測(cè)試。

足夠的CI工具將幫助您將單元和集成測(cè)試放在正確的位置，而帶有配置管理和環(huán)境管理的CD工具將幫助您以可靠的方式運(yùn)行自動(dòng)化的端到端測(cè)試。

做得好的設(shè)置允許開(kāi)發(fā)人員或測(cè)試人員動(dòng)態(tài)啟動(dòng)預(yù)配置的環(huán)境。嚴(yán)格外部化您的配置，并確保具有在部署時(shí)注入這些變量的配置管理。這帶來(lái)了許多積極的改進(jìn)：

在正確的時(shí)間運(yùn)行正確的測(cè)試，同時(shí)向開(kāi)發(fā)團(tuán)隊(duì)提供有效的反饋

開(kāi)發(fā)人員可以獲得自主權(quán)，您可以減少關(guān)鍵人物的依賴性，

質(zhì)量檢查人員現(xiàn)在可以通過(guò)功能環(huán)境測(cè)試子集，

質(zhì)量檢查人員可以并行化測(cè)試，這樣可以節(jié)省時(shí)間，同時(shí)可以對(duì)數(shù)據(jù)的子集進(jìn)行測(cè)試。

#6：自己管理數(shù)據(jù)庫(kù)

剛剛離開(kāi)的隊(duì)友負(fù)責(zé)為客戶項(xiàng)目設(shè)置MongoDB，并且當(dāng)然使用開(kāi)源項(xiàng)目自己運(yùn)行它。當(dāng)然，切換是“完美無(wú)缺”的，當(dāng)然，數(shù)據(jù)庫(kù)也沒(méi)有得到適當(dāng)?shù)谋Ｗo(hù)，有一天晚上，它顯示了數(shù)據(jù)應(yīng)該位于的位置：

而且當(dāng)然：您檢查備份。發(fā)生語(yǔ)法錯(cuò)誤。現(xiàn)在，您必須對(duì)所有數(shù)據(jù)進(jìn)行反向工程。這是一個(gè)經(jīng)常發(fā)生的真實(shí)示例。

自我管理的數(shù)據(jù)庫(kù)有操作和安全風(fēng)險(xiǎn)。它們使人分心，無(wú)聊且不必要。使用Cloud SQL或其他產(chǎn)品并睡個(gè)好覺(jué)。我們通常會(huì)看到Aiven.io等公司提供的托管產(chǎn)品 。這些公司提供大多數(shù)數(shù)據(jù)庫(kù)，它們可以為您在所有大型云提供商上運(yùn)行它們，并且它們具有更多功能，更成熟和更復(fù)雜。而且，它們通常更便宜，并確保零鎖定，同時(shí)為開(kāi)發(fā)人員提供了更高的便利性，如果并駕齊驅(qū)，我將始終希望這樣做。

#7：無(wú)緣無(wú)故地走向多云

僅使用多云和嘗試將系統(tǒng)設(shè)計(jì)為不可知論和可移植的之間是有區(qū)別的。后者具有許多不同的優(yōu)勢(shì)，例如動(dòng)態(tài)環(huán)境，并且比使用多云更有意義。當(dāng)然，這是有歷史遺留的：有些團(tuán)隊(duì)一直在使用GCP，而其他部門則從AWS開(kāi)始，現(xiàn)在就在這里。其他包括專業(yè)化。有人可能會(huì)說(shuō)，GPU在GCP上比在AWS或成本原因上更有效地運(yùn)行。但是要真正浮出水面，您需要足夠的大小。簡(jiǎn)單的多云設(shè)置需要高度的自動(dòng)化，并且需要開(kāi)發(fā)人員屏蔽配置和設(shè)置任務(wù)。否則，最終會(huì)陷入腳本地獄。

作為一般規(guī)則：如果不是絕對(duì)必要，請(qǐng)不要進(jìn)行多云。

結(jié)論

我希望這些觀點(diǎn)能幫助您避免該領(lǐng)域中最大的錯(cuò)誤。記住妮可·福斯格倫(Nicole Forsgren)，杰茲·漢布爾(Jez Humble)和吉恩·金(Gene Kim)在他們的書(shū)“加速”中寫(xiě)道：“排名前1%的團(tuán)隊(duì)的發(fā)貨頻率是原來(lái)的 10倍”。

這是因?yàn)樗麄冋诔浞掷卯?dāng)今的一切。我每個(gè)月花費(fèi)1個(gè)小時(shí)來(lái)查看我的個(gè)人工作流程，待辦事項(xiàng)列表以及組織應(yīng)用程序的方式。為什么?因?yàn)槿绻牧鞒绦实拖?，它?shí)際上會(huì)在數(shù)周內(nèi)加起來(lái)。這些微小的事情(例如搜索您的照片應(yīng)用程序)會(huì)分散您的大腦。停下來(lái)一個(gè)月度過(guò)一個(gè)下午，以確保您的生產(chǎn)率得到精簡(jiǎn)。這將幫助您專注于創(chuàng)新而不是配置，從而使團(tuán)隊(duì)更快樂(lè)。