在過去幾年中，我多次幫助多家企業(yè)實現(xiàn)云服務(wù)的完善，安全且可靠。雖然這些公司的問題都不一樣，但問題類型本質(zhì)上還是可以歸類的。這也是本文將會介紹的十誡。

我將這些多年實踐總結(jié)出來的十誡分為兩種類型：一種是針對商業(yè)決策者（高管），另一種針對技術(shù)決策者（技術(shù)團(tuán)隊中的工程師和管理者）

 類型一 面向商業(yè)決策者

1.不要把云僅當(dāng)著一個技術(shù)問題

敏捷或DevOps轉(zhuǎn)型被廣泛認(rèn)為是涉及某種程度的自上而下的組織變革。這包括新的職責(zé)、新的工作方式以及團(tuán)隊之間新的溝通方式。您不能僅僅是指望通過買一個“DevOps Box”就能達(dá)到成功。

你的云計算采用與此無異。不要認(rèn)為云計算僅僅是通過另一種方式交付同樣的舊技術(shù)和工作方式。“遷移與轉(zhuǎn)移”的思維方式最終會導(dǎo)致昂貴且臃腫的云計算采用失敗。

在成功采用云計算作為優(yōu)先選擇的企業(yè)中，開發(fā)、運維、安全甚至財務(wù)等各個方面都會采取新的架構(gòu)。請花時間理解并包容必需的深層次變化。

圖片

2.從一開始就進(jìn)行培訓(xùn)

你不能只是下達(dá)一個自上而下的組織強制采用云計算的命令，然后就離開，并期望會發(fā)生好的事情。

云計算是一場大規(guī)模的技術(shù)技能和團(tuán)隊職責(zé)的轉(zhuǎn)變。擁有對云計算技術(shù)的深刻理解的人才并不常見，在市場上也并不易于獲得。合作伙伴可以提供幫助，但最終你還是需要有一個計劃，從內(nèi)部培養(yǎng)這種專業(yè)知識。

在較大的企業(yè)中，建立云計算卓越中心是一個不錯的開始，但我也看到過這些努力最終被劃分為又一個信息孤島。你不能只是創(chuàng)建一個“云團(tuán)隊”；你必須更廣泛地推動一種文化，這意味著要在幾個月甚至幾年的時間里，細(xì)心設(shè)計云計算技能在整個組織中的普及。

是的，培訓(xùn)確實花費是很多，但云計算的本質(zhì)是讓你能夠用相同數(shù)量的人工實現(xiàn)更高的價值。因此，將招聘預(yù)算的一部分轉(zhuǎn)移到培訓(xùn)團(tuán)隊：當(dāng)你的團(tuán)隊掌握使用由云服務(wù)提供商維護(hù)的服務(wù)時，你會對他們的成就感到驚訝。

設(shè)定正確的重點，提供適當(dāng)?shù)募畲胧愕膯T工將會逐漸實現(xiàn)轉(zhuǎn)變。

圖片

3.將云計算視為價值中心

我們?nèi)匀豢吹揭恍┢髽I(yè)主要是出于節(jié)約成本的考慮選擇云計算，盡管這樣的企業(yè)比以往減少了——并且出于不錯的理由。你選擇云計算不是為了花更少的錢，而是為了創(chuàng)造更大的價值。

這就是為什么我喜歡把云計算描述為“IT的殺手級應(yīng)用”的想法：就像電子表格讓早期的個人電腦成為可取之處，云計算獨自就能超越您IT投資的成本。

如果你的組織能夠充分利用，云計算能夠提升上市時間、創(chuàng)新速度和敏捷度。

一些公司會在云計費單上陷入困境，因為它是他們能看到和理解的與云計算采用相關(guān)的唯一指標(biāo)——盡管它是一個令人痛苦的指標(biāo)。成功指標(biāo)，如價值產(chǎn)生的速度，并不是不可能衡量，但是需要有意識地努力建立和評估。

優(yōu)先考慮實驗，知道成功的標(biāo)準(zhǔn)，您就會發(fā)現(xiàn)云計算所產(chǎn)生的價值遠(yuǎn)遠(yuǎn)超過了成本。

4.從小開始，但不要無準(zhǔn)備

很容易陷入幾個月或甚至幾年的云計算等待期。在Andy Jassy最近的re:Invent主題演講中，他指出了一家組織，盡管該組織自吹自擂地宣稱他們采用了云計算，但實際上他們只是部署了一些小的實驗項目。雖然這種方法可能有利于您技術(shù)團(tuán)隊的簡歷打造，但對于業(yè)務(wù)而言卻沒有價值。

你在剛開始采用云計算時不會一下子就搞對，但不要讓這種擔(dān)憂阻止你開始行動。選擇一個適中的工作負(fù)載，認(rèn)真嘗試將其運行在云上，找出短板，進(jìn)行改進(jìn)，重復(fù)，并不斷擴大對云計算的了解。

認(rèn)真對待云計算，就會得到認(rèn)真的結(jié)果。

圖片

5.信任你的合作伙伴

企業(yè)在云計算的門檻處陷入數(shù)月甚至數(shù)年的困境的一個原因是什么？他們意識到變革可能是復(fù)雜的，他們不想出錯。

出于這個原因，在云計算的過程中介紹可信的合作伙伴是有道理的——那些在這條道路上走過，既知道陷阱，也知道捷徑的人。

（順便說一句，這也是支持公共云的一個很好論點。你真的認(rèn)為你能比AWS更好地管理數(shù)據(jù)中心，或者比微軟更好地構(gòu)建開發(fā)者工具嗎？對鎖定的擔(dān)憂在歷史上是合理的，并且有其存在的價值，但最終你必須與能夠適當(dāng)利用風(fēng)險的供應(yīng)商合作。）

尋找你可以信任的云計算和咨詢合作伙伴，然后給予他們足夠的自由度，讓他們幫助你實現(xiàn)持久的積極變化。

圖片

 類型二 面向技術(shù)決策者

6.不要因個人喜好選擇技術(shù)棧

在技術(shù)決策中，存在這樣一條普遍的建議：對于大多數(shù)問題，都應(yīng)該采用經(jīng)得起時間考驗的長期使用的解決方案。沒人因為寫了另一個Rails應(yīng)用程序或者任何類似的東西而被解雇。

這條建議在不發(fā)生重大破壞性前進(jìn)躍進(jìn)的世界中是合理的。然而，云計算改變了情況，因為一些新技術(shù)很大程度上減少了你需要管理的內(nèi)容，同時增加了你提供的基礎(chǔ)規(guī)模和功能。

例如，AWS的Amplify服務(wù)在移動端和后端開發(fā)的實時性方面進(jìn)步很大。基于低代碼、專注于模式的API開發(fā)方法絕對是優(yōu)秀的；與云本地數(shù)據(jù)存儲的緊密集成是更好的。并且因為AppSync后端是一個云服務(wù)，它會隨著時間的推移不斷改進(jìn)，而你不必做任何事情。可能需要你花幾周時間才能完全熟悉。但是，在這種情況下，投入一些時間學(xué)習(xí)的回報是持久的。

關(guān)鍵是，你的感覺可能會出賣你。你需要冷靜地評估哪些工具和服務(wù)能為你提供最大的收益。

圖片

7.時間是最珍貴的資源；全力優(yōu)化

你每天都接觸到的最昂貴的資源不是你的生產(chǎn)數(shù)據(jù)庫集群、應(yīng)用服務(wù)器群或日志框架。而是你的日程安排。

你和你的團(tuán)隊擁有有限的周期來構(gòu)建和維護(hù)技術(shù)。不要浪費時間重復(fù)造輪子。

舉個不幸的個人例子，我之前的工作中花費了大量時間從零開始構(gòu)建一個全棧式的部署框架和管道工具。雖然最終這個部署管道確實為業(yè)務(wù)提供了一定的價值，但代價是數(shù)千小時的工程時間。

如果我和團(tuán)隊更多地依賴現(xiàn)有的云服務(wù)，我們可以在更短的時間內(nèi)完成同樣的功能，用來從事更有價值的項目，而不用總是解釋給管理層我們在干什么。

鑒于云原生開發(fā)高度重視使用現(xiàn)成的服務(wù)，它使你在日程表上有更多寶貴的時間可用。

圖片

8.更早地開始在云上構(gòu)建。不，比那還早一點。

我已經(jīng)一直在鼓勵“本地測試代碼，云上測試服務(wù)”的理念。隨著無服務(wù)器開發(fā)在技術(shù)棧中的位置越來越高，維護(hù)獨立于云之外的本地開發(fā)環(huán)境的價值也越來越小。

如果必須這么做，可以在本地迭代代碼；在遠(yuǎn)程棧（顯然不是生產(chǎn)棧）部署的角色和資源上進(jìn)行測試。你在開發(fā)生命周期中越早這么做，發(fā)現(xiàn)權(quán)限和配置問題的速度就越快，在生產(chǎn)環(huán)境中出現(xiàn)意外情況的可能性也就越小。

我認(rèn)為對此有最好理解的供應(yīng)商是Stackery。我非常喜歡他們的“cloudlocal”開發(fā)概念，盡管我覺得這個名字不太可能流行。他們的命令行工具是我知道的唯一一個目前支持在本地執(zhí)行AWS Lambda函數(shù)，并使用與云部署版本相關(guān)聯(lián)的角色的工具。（當(dāng)你調(diào)用本地函數(shù)時，他們會將信任關(guān)系注入到該角色中。）我預(yù)測，其他主要的無服務(wù)器部署框架，如AWS SAM和Serverless Framework，也將很快為此提供更好的支持。這是未來的發(fā)展趨勢。

圖片

9.忽略虛假的問題

你可能認(rèn)為工作中本來就有足夠多的真實問題，無需捏造虛假問題。不幸的是，軟件工程師非常擅長找到那些真正不重要的問題的解決方案。

例如，你的應(yīng)用程序真的需要跨區(qū)域嗎？如果整個AWS us-east區(qū)域都宕機了，你的應(yīng)用程序需要保持可用性嗎？你會花多長時間維護(hù)多區(qū)域的事務(wù)一致性，你會花多少錢來復(fù)制數(shù)據(jù)，而不是每隔特別長一段時間就優(yōu)雅地短暫停機？

移植性是一個巨大的虛假問題。就像有人說過，如果你正在使用Kubernetes，你必須是很聰明：這是必須的，而不是一種恭維。協(xié)調(diào)服務(wù)網(wǎng)絡(luò)、服務(wù)代理、入口路由等是一項非常復(fù)雜的任務(wù)。

我甚至看到人們在無服務(wù)器應(yīng)用中設(shè)計復(fù)雜的抽象層，以便他們在需要選擇不同的云服務(wù)商時可以隨時更換技術(shù)。

一個真正明智的技術(shù)決策者明白，你可以擅長的事情范圍是很小的。利用云服務(wù)，從箱子里獲得經(jīng)過生產(chǎn)硬化的體系結(jié)構(gòu)，然后在其上構(gòu)建你獨特的功能。

如果你必須使用Kubernetes，可以考慮使用一些像EKS on Fargate或SpotInst Ocean這樣的管理服務(wù)，它們可以隱藏許多冗長的細(xì)節(jié)（并且可以在超低價的點實例上調(diào)度容器）。

更不用說，你可以通過與云服務(wù)提供商更緊密地集成獲得很多優(yōu)勢。直到云服務(wù)提供商表明他們將鎖定掠奪性的價格（這迄今沒有發(fā)生），你的時間可能更值得用來交付功能。

我的決策流程很簡單：不要只注重代碼，忽視云服務(wù)。

圖片

10.通過展示價值來創(chuàng)造動力

作為一名技術(shù)決策者，一個可以直接參與代碼開發(fā)的人，你特別適合找出在你的領(lǐng)域中可以產(chǎn)生最大影響力的技術(shù)。

如果你無法獲得關(guān)于一個設(shè)計決策的贊同，而你覺得該決策有明顯的好處，你可以試著在云端為它制作一個原型——這通常可以迅速而且廉價。

作為技術(shù)決策者，你可以給企業(yè)提供一個強有力的理由：你已經(jīng)構(gòu)建了業(yè)務(wù)所需要的東西。它運行得快，并且易于維護(hù)。

圖片

不管你是商務(wù)決策者還是技術(shù)決策者，云遷移的成功最終取決于你是否愿意接受不舒服感：去挑戰(zhàn)自己能夠構(gòu)建產(chǎn)品的界限，摒棄舒適圈，并信任那些為你指明前進(jìn)道路的供應(yīng)商和合作伙伴。

如有相關(guān)問題，請在文章后面給小編留言，小編安排作者第一時間和您聯(lián)系，為您答疑解惑。

原文地址：https://www.trek10.com/blog/ten-commandments-for-cloud-decision-makers