[[348623]]

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

#1：無適當工具全面投入微服務

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

問題開始于團隊不使用微服務，而對“微”則過于重視。從工具的角度來看，您現在將不得不處理更多的yml文件，docker文件，以及這些服務的變量之間的依賴關系，路由問題等。它們需要更新和維護。您的CI/CD設置，組織結構以及人員總數可能需要重新調整。

如果出于任何原因而進入微服務，請確保計劃足夠的時間來重組工具設置和工作流程。只需計算您需要維護的各個位置的腳本數量即可。考慮一下這將花費多長時間，由誰負責，以及哪些工具可以幫助您控制這一情況。如果選擇工具，請確保他們擁有一個用戶社區。

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

在很多情況下，容器化都是一項了不起的技術。但是，它帶有價值標簽，可能會影響您的生產率。從安全角度以及通過必要的配置和環境管理等方面來看，容器會增加開銷。如果您不同意團隊的某些約定，那么容器也會損害您的生產力和開發人員的經驗。

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

在開始大規模使用和在生產環境中使用容器之前，請先坐下并同意對您重要的配置約定。確保在代碼審查和回顧中始終如一地介紹這一點。重構這種體驗是一種痛苦。

#3：錯誤地采用KUBERNETES

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

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

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

最佳做法：

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

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

如果團隊真的希望開發人員自己管理Kubernetes集群，那么他們應該給他們足夠的時間來真正了解架構，設計模式，kubectl等，并真正專注于此。

#4：忘記做持續交付

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

經過精心調整的“持續交付”設置(無論是自行編寫的還是“即服務”的設置)，更是團隊工具鏈中的“粘合劑”：

它使從源代碼控制系統到CI-Pipeline，從數據庫到群集以及從DNS設置到IaC的所有不同組件都可以集成到簡化的便捷開發人員體驗中。

這是一種結構，維護和管理數量不斷增長的yml和配置腳本的方法。如果做得好，這將使您的開發人員可以利用CI-Pipeline構建的工件動態地啟動環境，并通過預配置的數據庫和已設置的一切進行全面配置。

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

通過精心設計的CD設置，可以改變開發人員的工作效率。它們使開發人員能夠自助服務，減少了團隊內部的依賴，同時提高了設置的可維護性。

使用這些做法的團隊會更頻繁，更快地發布，表現出總體上更高的績效和滿意度。

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

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

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

做得好的設置允許開發人員或測試人員動態啟動預配置的環境。嚴格外部化您的配置，并確保具有在部署時注入這些變量的配置管理。這帶來了許多積極的改進：

在正確的時間運行正確的測試，同時向開發團隊提供有效的反饋

開發人員可以獲得自主權，您可以減少關鍵人物的依賴性，

質量檢查人員現在可以通過功能環境測試子集，

質量檢查人員可以并行化測試，這樣可以節省時間，同時可以對數據的子集進行測試。

#6：自己管理數據庫

剛剛離開的隊友負責為客戶項目設置MongoDB，并且當然使用開源項目自己運行它。當然，切換是“完美無缺”的，當然，數據庫也沒有得到適當的保護，有一天晚上，它顯示了數據應該位于的位置：

而且當然：您檢查備份。發生語法錯誤。現在，您必須對所有數據進行反向工程。這是一個經常發生的真實示例。

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

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

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

作為一般規則：如果不是絕對必要，請不要進行多云。

結論

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

這是因為他們正在充分利用當今的一切。我每個月花費1個小時來查看我的個人工作流程，待辦事項列表以及組織應用程序的方式。為什么?因為如果您的流程效率低下，它實際上會在數周內加起來。這些微小的事情(例如搜索您的照片應用程序)會分散您的大腦。停下來一個月度過一個下午，以確保您的生產率得到精簡。這將幫助您專注于創新而不是配置，從而使團隊更快樂。