【AWS徵文】AWS的架構完善框架會成爲業界標準嗎？

前幾天AWS中國開了在線技術峯會，宣佈咱成了AWS中國的戰略合做夥伴和第一家中國的受權增值推廣商（Value Add Promoter），一塊兒幹從銷售到渠道還有MSP服務的活，目測又有不少事情要折騰了。

讓我更感興趣的實際上是以後AWS CTO Werner Vogels談的架構完善框架（Well-architected Framework）。這個框架是一整套的設計雲上系統的方法論，包括卓越運營（Operational Excellence），安全性（Security）, 可靠性（Reliability）, 性能效率（Performance efficiency） 和成本優化（Cost optimization）五大支柱。經過描述關鍵概念，設計原則和架構的最佳實踐，爲架構師提供了一致性的方法論，評估架構和實施的設計原則。

這部分的工做一直都是雲託管服務（Managed Service）裏專業服務（Professional Service）的重要組成部分。咱們在具體的工做中，一般也使用相似的方法給客戶提供這五個方面的建議和意見。我記得六七年前AWS已經有過一篇白皮書講這個，我當年也看過。未曾想到了今天，這篇白皮書已經被擴展成了特定領域的框架設計，動手實驗，還提供了一個自動分析的工具能給客戶建議，關鍵仍是免費的！這麼折騰下去，怕是專業幹高端諮詢的團隊要擦汗了，畢竟他們的吃飯家伙正在被蠶食。

AWS提供了特定行業和領域的架構完善框架白皮書，例如金融服務，分析，機器學習，IoT，HPC，Serverless等等。我我的以爲金融服務這個白皮書寫得有點水，故意迴避了銀行核心系統架構，其餘幾個技術領域的白皮書仍是很專業的。

不只是AWS，微軟也有相似的框架，叫作Microsoft Azure Well-Architected Framework，內容結構幾乎徹底同樣，也是成本優化，卓越運營，性能效率，可靠性，安全性五部份內容，給出了基於Azure的各方面建議。不過微軟只提供了一個Review的問卷，讓客戶本身選擇獲得相關的建議，跟AWS那個自動分析工具比仍是有差距。

鑑於亞馬遜在雲計算領域的領先優點，讓我來近距離再看一下這個框架裏提到的內容。看看他有沒有可能成爲雲計算的架構設計框架的事實標準。畢竟AWS在Gartner今年 9 月1日發佈的雲基礎設施和平臺服務魔力象限裏排名第一，遙遙領先。

框架介紹

AWS架構晚上框架實際上是一個平衡的方法論，在定義裏他說得很清楚：在設計架構的時候，咱們根據業務的上下文，在5個支柱之中取得平衡。根據商業決策決定工程上的優先級。咱們可能由於要優化成本而下降開發環境的可靠性，或者爲了關鍵的業務場景提升可靠性而增長成本。安全和卓越運營比較通用，雖然沒有明顯的取捨，可是依然對成本有重要的影響。

傳統IT的環境下咱們一般使用中心化的IT架構，基於TOGAF或者Zachman框架設計企業架構（像不像中臺的概念？）。而在雲上，AWS傾向於把能力分佈到不一樣的團隊，而不是用一箇中心化的團隊（像不像區塊鏈裏去中心化的概念？）。這種分佈式的方法產生了決策的風險，不過AWS說他們經過實踐（practices）和機制（mechanisms）減輕了這種風險，先讓各團隊知足內部標準，而後逐漸提升標準，推進技術和業務發展。AWS說，這種分佈式的方法由亞馬遜領導力原則支持，我頓時驚掉了下巴，這個高大上的帽子絕對是政治正確，可是寫在一份技術文檔裏真的合適嗎？

插一句，亞麻的領導力原則有14條，包括

顧客至尚（Customer Obsession）

主人翁精神（Ownership）

創新簡化（Invent and Simplify）

決策正確（Are Right, A Lot）

好奇求知（Learn and Be Curious）

選賢育能（Hire and Develop the Best）

最高標準（Insist on the Highest Standards）

遠見卓識（Think big）

崇尚行動（Bias for Action）

勤儉節約（Frugality）

贏得信任（Earn Trust）

刨根問底（Dive Deep）

勇於諫言 服從大局（Have Backbone; Disagree and Commit）

達成業績（Deliver Results）

技術架構文檔和領導力文化緊密相連，這個和阿里的政委思想政治玩法也是同出一轍。由於有了這個思想武器的指導，因此亞麻的框架也不斷改進。無論是新團隊，仍是現有的團隊，都可以在這個框架下知足廣大客戶日益苛刻的要求。

順便吐槽一句，這14條領導力的原則真是條條反人性，能所有作到真是太難了。話說回來也確實蠻有道理，比虛無縹緲微言大義的《論語》《道德經》啥的，實操效果好多了。

這個框架的通常設計原則有六個：

中止對容量需求的猜想

以生產規模進行系統測試

經過自動化讓架構試驗更簡單

容許不斷演化的架構

利用數據來驅動架構

經過實際演練（Game Day）不斷改進

接下來就是對五大支柱進行分析和討論了。畢竟作一個軟件系統就像造房子同樣，結構問題會致使樓房倒塌。對五大支柱的分析和設計會幫助咱們構建一個穩固有效的系統。這個講得仍是頗有道理的，無論是軟件系統，仍是組織架構的設計，一開始你們都差很少，到了必定規模之後，很差的結構問題早晚會出現，嚴重的可能會致使系統崩潰。

卓越運營

卓越運營主要包括了對開發和有效運行的支持能力，得到運營的洞見以及持續改進支持流程和過程來得到業務價值。

卓越運營的設計原則包括：

運營即代碼

用頻繁的，小的和可逆的改變

常常改進運營程序

預期失敗

從運營失敗中學習

卓越運營有四方面的最佳實踐：組織，準備，運營，演進。在這四個部分裏，AWS提出了各類須要注意的點和須要回答的問題：

組織（Organization）

OPS 1：如何決定優先級

OPS 2：如何定義組織架構來支持業務產出

OPS 3：組織文化如何支持業務產出

準備（Prepare）

OPS 4：如何設計工做負載以理解它的狀態
OPS 5：如何下降缺陷，簡化修復，並改進生產流程
OPS 6：如何減輕部署風險
OPS 7：如何知道你準備好對工做負載的支持

運營（Operate）

OPS 8：如何理解你的工做負載的健康狀態

OPS 9：如何理解運營的健康狀態

OPS 10：如何管理工做負載和運營的事件

演進（Evolve）

OPS 11：如何演進運營

其實卓越運營的核心就是自動化（Automation），運營的錯誤都是人的問題，自動化越多，錯誤就越少，內部的流程不斷改進能夠不斷下降運營錯誤的發生。

安全性

安全性包含了利用雲技術來提升安全性，保護數據，系統和資產。它的設計原則包括：

實現嚴格的身份基礎

啓用可追溯性

在全部層上應用安全

自動化安全最佳實踐

保護在傳輸中的和靜態的數據

讓人遠離數據

爲安全事件作好準備

安全的最佳實踐分爲六個部分：安全，身份和訪問管理，偵查，基礎設施保護，數據保護，事故響應。

安全（Security）

SEC 1：如何安全地運營工做負載

身份和訪問管理（Identity and Access Management）

SEC 2：如何管理人和機器的身份

SEC 3：如何管理人和機器的權限

偵查（Detection）

SEC 4：如何檢測和調查安全事件

基礎設施保護（Infrastructure Protection）

SEC 5：如何保護網絡資源

SEC 6：如何保護計算資源

數據保護（Data Protection）

SEC 7：如何對數據進行分類

SEC 8：如何保護靜態數據

SEC 9：如何保護傳輸中的數據

事故響應（Incident Response）

SEC 10：你如何預測、應對和從事故中恢復

安全裏最關鍵的設計要點叫作Zero Trust，就是零信任，全部的這些問題都是在問這個零信任的問題怎麼解決。

可靠性

可靠性談的是工做負載如何按照預期的方式正確地，持續地運行。咱們須要對工做負載全生命週期進行運營和測試。它的設計原則包括：

自動從故障中恢復

測試恢復流程

經過水平擴展增長聚合工做負載的可用性

中止猜想容量

自動化管理變動

可靠性的最佳實踐有四個部分，分別是基礎，工做負載架構，變動管理，故障管理。

基礎（Foundations）

REL 1：如何管理服務配額和限制

REL 2：如何規劃網絡拓撲

工做負載架構（Workload Architecture）

REL 3：如何設計工做負載服務架構（面向服務架構SOA或者微服務架構）

REL 4：如何在分佈式系統中設計交互以防止故障

REL 5：如何在分佈式系統中設計交互以減輕或抵禦故障？

變動管理（Change Management）

REL 6：如何監控負載資源

REL 7：如何設計工做負載來適應需求變化

REL 8：如何實現變動

故障管理（Failure Management）

REL 9：如何備份數據

REL 10：如何使用故障隔離來保護工做負載

REL 11：如何設計工做負載以抵禦組件故障

REL 12：如何測試可靠性

REL 13：如何規劃災難恢復（DR）

在考慮可靠性的時候，咱們能夠考慮一個叫作爆炸半徑（Blast radius）的概念。爆炸半徑的意思是是系統發生故障時可能承受的最大影響，要構建可靠的系統，須要最小化任何單個組件的爆炸半徑。

性能效率

性能效率包括了有效使用計算資源來知足系統需求，以及在需求變動和技術演化過程當中維持效率。它的設計原則有：

讓先進技術平民化

分鐘級全球化

使用無服務架構

多作實驗

考慮「機械同情」（Mechanical Sympathy）。這裏解釋一下，Mechanical Sympathy是賽車手Jackie Steward最先說的，而後被Martin Thompson用在了軟件設計上。原話是:「You don’t have to be an engineer to be a racing driver, but you do have to have Mechanical Sympathy.」 你沒必要成爲一名工程師才能成爲一名賽車手，但你必須有機械同情。編寫代碼也是同樣，你不須要成爲一名硬件工程師，可是須要了解底層的運做模式，並在設計軟件時考慮到這一點。咱們有太多的碼農沒有打破砂鍋問到底的精神，只是隨便搭搭積木把功能實現了就好，不知道底層模塊的實現方式，出現問題了徹底沒有辦法解決。

好吧，搞技術的碼農仍是很是有文化的。性能效率的最佳實踐包括選擇，複查，監控和權衡。

選擇（Selection）

PERF 1：如何選擇最優性能架構

PERF 2：如何選擇計算方案（實例，容器，函數）

PERF 3：如何選擇存儲方案（對象存儲，塊存儲和文件存儲）

PERF 4：如何選擇數據庫方案

PERF 5：如何配置網絡方案

複查（Review）

PERF 6：如何利用新的發佈演進工做負載

監控（Monitoring）

PERF 7：如何監控資源以保證他們正常工做

權衡（Tradeoffs）

PERF 8：如何利用權衡改進性能（下降一致性，持久性，空間換時間，延遲）

在考慮性能效率的時候，把服務想成牛，而不是寵物（cattle, not pets）。在傳統機房模型下，服務器又貴又經不起折騰，因此咱們把他理解成寵物，要不少關愛。而在雲的模型下，服務器就是老黃牛，幾秒鐘就能夠建立，徹底不須要關愛。

成本優化

成本優化包括用最低的成本運行系統來交付商業價值，它的設計原則包括：

實現雲的財務管理

採用消費模式

衡量整體效率

別再把錢花在毫無差異的重擔上

分析並肯定支出

成本優化的最佳實踐包括：實踐雲財務管理，支出和使用意識，成本效益的資源，管理需求和供給資源，隨時間優化。

實踐雲財務管理（Practice Cloud Financial Management）

COST 1：如何實現雲財務管理

支出和使用意識（Expenditure and usage awareness）

COST 2：如何控制用量

COST 3：如何監控用量和成本

COST 4：如何解除資源使用

成本效益的資源（Cost-effective resources）

COST 5：在選擇服務時如何評估成本

COST 6：在選擇資源類型、規模和數量時，如何達到成本目標

COST 7：如何使用價格模型下降成本

COST 8：如何規劃數據傳輸費用

管理需求和供給資源（Manage demand and supply resources）

COST 9：如何管理需求和供給資源

隨時間優化（Optimize over time）

COST 10：如何評估新服務

在咱們考慮雲上的成本優化的時候，考慮OpEx而不是CapEx，即考慮運營性支出，而不是資本性支出。雲畢竟是租用的生意，須要不斷考慮持續的成本。

價值觀又來了！

在這個框架下，AWS建議創建持續輕量級的Review流程，用不責備的方法不斷進行深度分析，對架構進行改進。經過根緣由分析（Root Cause Analysis），在關鍵的節點和產品發佈的時候開始Review。

不斷分析提升固然是必須的，也是反人性的，大量的工程師和技術人員是不肯意的，因此仍是得經過價值觀來推動。在這個技術框架的文章裏，它提到了一些新的團隊對這種框架設計的抵觸可能，例如：

「咱們太忙了！」

「咱們沒有時間對結果作任何事情「

「咱們不但願別人知道咱們解決方案的祕密」

說得真是挺到位的，咱們的一些技術團隊在要求提升效率或者橫向對比的時候，也會找到相似的藉口和理由。我也理解了AWS的員工流失率有點高的緣由。剛纔提到的AWS領導力原則條條都是反人性，多數人是作不到的，這裏也是同樣。不過正由於如此，才讓AWS成爲一家如此成功的偉大公司吧。

這個框架自己是一個雲計算架構裏很好用的方法論，若是有興趣的同窗還能夠去AWS官方網站上找到更詳細的內容。做爲北美富士康的亞馬遜在技術文檔裏也融入了他的文化主張，就更有意思了。從這個角度上來講，這個框架成爲業界標準彷佛是沒可能了。

對於數字化轉型而言，數字化技術並非轉型的關鍵，文化纔是。在這點上亞馬遜作得愈來愈有趣。固然，優秀的公司都是能找到一羣承認公司價值觀的人一塊兒把事情作好的，亞馬遜是這樣，特斯拉是這樣，連阿里巴巴和華爲也是這樣，凡事搞到最後，其實都是人事。