[[348623]]

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

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

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

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

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

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

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

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

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

#3：錯誤地采用KUBERNETES

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

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

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

最佳做法：

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

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

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

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

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

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

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

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

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

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

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

#5：無法維持的測試自動化

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

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

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

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

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

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

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

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

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

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

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

#7：無緣無故地走向多云

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

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

結(jié)論

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

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