如果你從事DevOps和雲原生工作，你可能聽說過平台工程是一門新學科，有望補充企業雲原生環境中DevOps的不足。 平台工程專注於構建內部開發人員平台 （IDP），以實現開發人員自助服務並減輕運營團隊的壓力。 雖然平台工程的正確實現可以大大提高開發人員的生產力和整體工程速度，但錯誤的實現可能會是乙個錯誤
許多組織現在正在盲目地構建和實施平台工程，因為他們迫切需要改善DevOps現狀。 在今天的文章中，我們將分析企業是如何步入平台工程實施的誤區。
第 1 步：將 DevOps 團隊重新命名為 Platform 團隊，但執行 TicketOps 工作
隨著平台工程的日益普及，越來越多的企業開始關注平台工程，決定建立IDP和平台工程團隊。 然而，在一些企業中，平台工程的實施只是將DevOps團隊更名為平台工程團隊，工程師們仍然花費大量時間處理工單和Slack訊息，沒有時間和精力搭建內部平台。
第 2 步：未能實現平台即產品的思維方式
在沒有真正將平台工程理念付諸實踐的情況下，平台團隊繼續以DevOps的思維方式工作，繼續為各種產品團隊編寫和實現管道和自動化。 “平台團隊”收到太多來自開發人員的請求，導致沒有時間和資源來定製長期的平台戰略和計畫，以“平台即產品”的思維方式構建可擴充套件的 IDP，並將平台即產品交付給其他團隊。
第 3 步：為運營團隊構建平台
隨著平台團隊越來越忙，團隊決定聘請更多的平台工程師。 這些工程師在DevOps部門擁有多年的經驗。 他們齊聚一堂，認真思考他們在工作過程中遇到的最大DevOps相關挑戰。 因此，工程師們開始設計平台來解決這些棘手的挑戰。 但是，由於它，這個平台對開發人員來說意義不大它只能解決運維問題該平台不是從開發人員的角度設計的，因此企業中的開發人員沒有購買該平台。
在這一點上，平台工程的設計和實施已經花費了公司大量的資金，但內部採用率並不令人滿意。
第 4 步：盲目使用新技術
隨著越來越多的平台工程師加入平台團隊，他們開始嘗試構建和利用 CNCF 剛剛發布的最新技術和工具。 無論企業是否需要，都可以嘗試用 GitHub Actions 替換 Jenkins，用 Kubernetes 替換所有現有的 VM，引入 Terraform，然後替換 Crossplane。 此時，開發成本不斷上公升，生產率不斷下降。
第 5 步：高度定製
由於每個團隊和每個組織都有獨特的需求，因此自定義工作流程開始無處不在。 反過來，這需要更多的自定義整合。 這時，工程師在一分鐘內為商店執行簡單的設定，然後部署到高度自定義的混合 Kubernetes 設定。
第 6 步：構建開發人員從未要求過的門戶**
當您想到平台工程時，您會想到 Developer Portal**。 這時，平台團隊嗅到了技術熱點，迫不及待地想嘗試一下。 平台團隊跳過了與開發人員的討論，並決定在現有基礎設施之上構建乙個門戶。 但是，開發人員不會像過去那樣自己使用門戶。 在這一點上，更多的錢被花了，但平台和門戶的採用率極低，生產力直線下降。
第 7 步：生成平台工程孤島
由於組織規模龐大，部門之間的溝通效率低下，中層管理者發起了多個平台工程計畫，而彼此之間沒有保持一致。 領導不干預，溝通不便，工作精力翻倍，但情況卻越來越糟。 最終，該企業擁有五個平台和五個團隊，其中大多數對開發人員的幫助根本不夠有效。 更多的人投資快於支出，但企業和開發商並沒有真正從中受益。
第 8 步：嘗試隱藏沉沒成本
在這個階段，企業中已經有許多平台，但由於它們不具有可擴充套件性並且不能真正工作，因此需要更換它們。 企業內部的管理者、業務人員和平台負責人開始為構建平台而產生的沉沒成本感到緊張。 為了隱藏這些成本，經理們開始建立有利的指標，試圖使整體平台效能和效能看起來合理。
總結
經過上述一系列的蜂蜜化操作，公司終於受不了了，開始抱怨平台工程沒有給企業帶來更多“炒作”的優勢。 這時，平台團隊解散，企業與其他同行的差距越來越大，最終慢慢被行業淘汰。
這個故事聽起來很可怕，對吧？不幸的是，我們已經看到一些公司在錯誤的道路上實施平台工程戰略。 在平台工程實施之前和實施過程中，企業需要明確自己的目標，並結合自身實際情況不要盲目追隨熱點並切換新技術，最適合您業務的策略是最適合您業務的策略