在不創(chuàng)建復雜的新設置的情況下證明你的平臺價值。

翻譯自 New to Platform Engineering? Try a Thin Self-Service Layer 。

隨著越來越多的公司評估是否應該投入平臺工程，其中最大的問題之一是從何處開始。著手構(gòu)建一個內(nèi)部開發(fā)平臺可能是一項艱巨的任務：云原生計算基金會的白皮書中列出了 13 個能力，涵蓋了從開發(fā)環(huán)境和 API 到可觀測性和制品存儲等方面。因此，了解要構(gòu)建的內(nèi)容本身就是一項任務。

這就是為什么建議將你的平臺視為一個不斷發(fā)展的產(chǎn)品，而不是一個有終點的項目。然而，并非每個人都有幸能夠從一開始就組建一個完整的產(chǎn)品團隊來進行內(nèi)部項目。那么應該怎么辦呢？

Legal-tech 初創(chuàng)公司 Relativity 通過一個自助服務操作，將一個需要數(shù)周時間的流程縮短為幾個小時，將其平臺推向了大聯(lián)盟。團隊沒有重新架構(gòu)基礎(chǔ)設施和服務，而是在現(xiàn)有平臺之上創(chuàng)建了內(nèi)部開發(fā)者門戶作為一個簡潔的層。

通過在現(xiàn)有基礎(chǔ)上添加一個簡潔的層，實現(xiàn)自助服務功能，是驗證你的平臺潛力并迅速產(chǎn)生價值的好方法。這種精益方法的好處是雙重的：你為開發(fā)人員提供了實實在在的價值，推動了你的平臺的有機采用。而且你可以向利益相關(guān)者提供具體數(shù)據(jù)，為更大的項目奠定基礎(chǔ)。

自助服務和黃金路徑

在請求基礎(chǔ)設施時，開發(fā)人員與 DevOps 之間的工單交互是平臺工程的核心承諾之一。但是自助服務能力不僅僅是授予資源訪問權(quán)限。自助服務通常是提供黃金路徑的理想途徑，可以幫助鞏固實踐并減輕開發(fā)人員的認知負擔。

為開發(fā)人員提供選擇自己工具的自主權(quán)可以提高其創(chuàng)造力和生產(chǎn)力。然而，在一個不斷向左移動的世界中，這意味著開發(fā)人員必須找出如何將 CI/CD、QA、安全性和其他關(guān)注點整合到他們的代碼庫中。另一方面，這種動態(tài)導致了需要支持碎片化技術(shù)棧的 DevOps 和系統(tǒng)管理員。雙方最終會一次又一次地重新發(fā)明輪子，增加安全和合規(guī)風險，并最終面臨過度勞累的問題。

自助服務能力可以緩解開發(fā)人員和運維人員的這種情況。通過黃金路徑，開發(fā)團隊可以獲得構(gòu)建應用程序的可靠方式，并專注于開發(fā)業(yè)務價值，而不是重寫部署設置。此外，專注于提供內(nèi)置最佳實踐的自助服務能力是有意義的，否則你可能面臨大量低性能應用程序和資源的問題。

開發(fā)者門戶：平臺的簡潔層

在面向?qū)ο缶幊讨?，facade 模式用于將復雜的結(jié)構(gòu)抽象在一個公開有限和范圍功能的類后面。在某種程度上，開發(fā)人員和 DevOps 使用的工單系統(tǒng)就是 facade 模式的一個例子：平臺的復雜性被掩蓋在一個委婉的聊天背后。

相反，可以使用基于 Backstage 的開發(fā)者門戶作為平臺的 facade 。開發(fā)者門戶可以提供多種好處，但我只想專注于自助服務的動力：軟件模板。

Backstage 中的軟件模板（也稱為腳手架）使用類似于 GitHub Actions 的語法，使用 YAML 編寫。它們允許你定義用戶必須填寫的輸入，以便運行模板，然后指定要執(zhí)行的步驟。通常，你可以通過復制一個樣板庫或代碼片段開始，然后在多個云服務中運行操作，例如在 PagerDuty 中注冊服務或執(zhí)行 Terraform 腳本。

即使你自行托管，使用 scaffolder 啟動 Backstage 也可以很簡單，而且通過 Roadie.io 等托管的 Backstage 解決方案可以更加輕松。通過腳手架，你可以為開發(fā)人員提供一個統(tǒng)一的入口點，以查找自助服務選項，甚至可以讓 DevOps 將他們的流程集成到一個統(tǒng)一的用戶界面下。

自助服務涉及政治因素

通過腳手架將各種工具整合到一個統(tǒng)一的門戶中是一個相對低成本的舉措。你不需要龐大的預算或面臨復雜的技術(shù)問題才能開始。你將在定義和實施特定自助服務操作時遇到最多的工作和挑戰(zhàn)。

第一步是確定低懸果實：哪些流程對于開發(fā)人員和運維人員而言造成了最大的困擾？如果你無法對你的軟件交付生命周期進行正式的用戶體驗研究，花些時間與開發(fā)人員交流，找出摩擦點。

一旦你選擇了一個對軟件模板有重大影響的使用案例，就開始與所有相關(guān)方進行協(xié)商。你將發(fā)現(xiàn)自己在旅程開始時要處理重大的內(nèi)部政治問題。畢竟，“黃金路徑”對基礎(chǔ)設施、可靠性、安全性、法律以及其他相關(guān)團隊來說意味著不同的東西。

重要的是要提供一個足夠健壯的自助服務操作；你不希望人們生成復雜的應用程序或配置錯誤的資源。建立合理的標準和基線政策，使團隊在部署到生產(chǎn)環(huán)境時感到滿意，并使開發(fā)人員輕松自如。

然而，要注意不要過度規(guī)定。如果你試圖推動一個過于嚴格的模板，開發(fā)人員可能會完全避免使用它。此外，你不可能涵蓋組織中的所有用例，因此確保開發(fā)人員可以自定義如何使用你的模板。

結(jié)論：模板是活的

將 Backstage 的腳手架設置為抽象你基礎(chǔ)設施復雜性的簡潔層，可以是向開發(fā)人員和利益相關(guān)者證明你的平臺價值的一種資源有效的方式。

Lunar Bank 就是這種模式的一個例子。這家廣受歡迎的斯堪的納維亞銀行使用腳手架作為開發(fā)人員請求資源的獨家接觸點。在 Lunar ，開發(fā)人員甚至無法創(chuàng)建 GitHub 倉庫，而不使用確保金融機構(gòu)需要的嚴格合規(guī)級別的軟件模板。

開始自助服務的一種方式是確定一個減少開發(fā)人員和運維人員摩擦的使用案例。然后，采取外交角色，就安全性、運維、基礎(chǔ)設施和其他需要為生產(chǎn)發(fā)布做出貢獻的團隊的黃金標準達成一致。

一旦得到所有人的認可，將這個共同決定作為一個軟件模板在 Backstage 中實施，并向你的開發(fā)人員提供。內(nèi)部開發(fā)者倡導會起到很大的作用！向他們展示你知道他們的困境，并為他們解決問題努力。請記住，正確實現(xiàn)自助服務能力是一個迭代的過程，所以一定要聽取開發(fā)人員的反饋。