云服務(wù)真的靠譜嗎？靠譜的云服務(wù)至少要具備這

時間：2022-07-01 20:39:01 | 來源：建站知識

時間：2022-07-01 20:39:01 來源：建站知識

云服務(wù)真的靠譜嗎?

相信對這個問題每個人心里都有不同的答案。我今天想講的是如何客觀的去回答這個問題, 其中結(jié)合了 Coding 的一些實踐和思考。

廣義范圍的“靠譜” 有幾個比較重要的點。

第一個點就是 Availability (可用性)，24x7隨時可用。一個靠譜的云服務(wù)一定是可用性非常高的。

第二點是 Access Control，可控性一定要好，非云服務(wù)你可以上個鎖，云服務(wù)如何能做到可控性很好，很難。

第三點是 災(zāi)難恢復(fù)，是軟件就會有問題。怎么樣積極的面對這個問題，這是任何一個云廠商都要誠實面對的問題。

可用性

首先第一點我們看來講一下可用性，可用性只有一個評判標(biāo)準(zhǔn)，就是 SLA，Service Level Agreement，更多的時候是 SLO, 只是 Objective。 一個東西是不是高可用，那么就問他幾個九，敢不敢拿出來說一下。

實實在在的看著這個圖說話，3個9基本上是國內(nèi)云服務(wù)的基礎(chǔ)線。也就是說**云服務(wù)至少要做到3個9才稱為基本上可用**，是合格性產(chǎn)品。如果是做不到這個，你的東西就只是玩具，快回去好好把技術(shù)內(nèi)功修煉修煉再出來刷臉。從3個9邁向4個9，也就是99.99%的可用性，每年只有52.6分鐘的時間是不可用的。

以前的谷歌搜索可用度大概是全球5個9到6個9之間，每一個小節(jié)點都是5個9不到6個9之間。想想吧，這其實是很可怕的一個概念。**因為這里包含了可能發(fā)生的一切事故**，不管什么不可抗力，都是扯淡。地震、洪水、臺風(fēng)、大樓震塌了，也是5分鐘內(nèi)恢復(fù)服務(wù)。

相比之下，大部分國內(nèi)的IDC機房都是按照99%設(shè)計的，一年至少3天是不可用，這3天給你花在元旦一天，春節(jié)一天，國慶一天，省點時間給你機動(笑)。這里不可用就是不可用，求爺爺告奶奶也照樣不能用。

所以說 SLO 直接反映一個云服務(wù)的靠譜程度：

從99%到3個9，是基本可以靠堆人和運氣解決的;

從3個9到4個9，考驗的是運維自動化的能力，災(zāi)備的能力;

從4個9往上基本考驗的是服務(wù)基礎(chǔ)架構(gòu)、業(yè)務(wù)設(shè)計的能力。

我們也在3個9到4個9之間努力, 這個還是很有難度的。如果一個云服務(wù)廠商在注釋里加了句“不可抗力排除在外”，這是非常不合適的。

那么如何提升可用性：

Design For Redundancy, 第一是一定要做到所謂的**“無狀態(tài)微服務(wù)”**，去掉單點故障。 首先是“微服務(wù)”， 一個服務(wù)分解的越簡單，出錯的面就越小，失敗模式就越固定。然后是“無狀態(tài)”，這樣才可以做到無限擴展。 這個很難的， 很多時候最后拆來拆去都發(fā)現(xiàn)有一個數(shù)據(jù)庫在最后，這個數(shù)據(jù)庫就做不到無狀態(tài)，永遠只能有一個數(shù)據(jù)庫，一個數(shù)據(jù)庫實例在那擺著，可用性永遠上不去。

有了無狀態(tài)的微服務(wù)這種架構(gòu)，還要做到 N+2。很多時候很多廠商連N都不知道(因為從沒有做過壓力測試，性能分析)，何談N+2?

Design For Gradual Deployment, 第二就是要**支持灰度發(fā)布**。一個服務(wù)要前進，任何軟件組件都要改，都會改。更新操作會直接提高你系統(tǒng)出問題的可能性。想要提高可用性，**必須將發(fā)布的代價降低**。只有能夠做到說我上線一個新功能，只給某幾個用戶用，其他的用戶不受這個影響。這樣才能提高你整個系統(tǒng)作為一個整體的可用性，

Design for Clustering: 第三點是要**區(qū)分 Cluster management 和 App Managment 的概念， 把資源的調(diào)配和服務(wù)調(diào)配分開。**

Design for Automation ，最后一點是**自動化**。一個靠譜的云服務(wù)，從設(shè)計之初就把人的因素排除在運行之外。整個系統(tǒng)應(yīng)該是全自動化運行的，不需要你人來干預(yù)。云服務(wù)初期買了二三臺個服務(wù)器，服務(wù)器放在那，有人天天盯著它才正常運行，這還有可能，上了規(guī)模之后顯然是不可能的。這是最關(guān)鍵的一點。任何一個云服務(wù)到現(xiàn)在內(nèi)部都是非常復(fù)雜的，他就像這個漫畫里邊這樣，每一個人操作它的時候，面前有無數(shù)的按鈕，無數(shù)的可能性。除了問題之后，如果讓一個人馬上搞清楚弄明白立刻解決，這是不可能的，只能自動化。

而且其實更多的時候都是人的操作帶來的問題，更新一個軟件，更新一個服務(wù)器都不可避免的有人要參與。如果不做自動化，早晚會出問題。

任何的靠譜的云服務(wù)廠商至少要做到以下幾點：

第一個SLA一定要達到4個9，你達不到這個4個9基本上相當(dāng)于你這個服務(wù)就是一個玩具，根本沒有辦法依賴你。

第二個是一個數(shù)量級，甚至兩個數(shù)量級以上的預(yù)研。

第三就是 Automation 自動化。這就是實踐中的一個經(jīng)驗。

可控性

接下來我們看一下可控性。 一提 Access Control 最關(guān)鍵的一點是要 Defense in Depth。就好比你想一下從自己家到公司辦公室要經(jīng)過多少層門，每個門的存在就是一層防御，每個門有不同的開鎖方式能擋住不同的人。

云服務(wù)也是一樣的，Access Control 做得越好，這個云服務(wù)越安全。首先從**最基礎(chǔ)的 Physical Security 開始**。 有一句話說的好，任何軟件上的花招都抵不過一個螺絲刀。評判一個云服務(wù)是否靠譜，先看他們是否做好了 Physical Security，如果沒做， 這個服務(wù)就是瞎扯。

如果一個云服務(wù)想過這個問題，說明他真正的認(rèn)識到安全的重要性了。 什么機柜上鎖，指紋識別，聲紋識別，臉型識別，虹膜識別，姿態(tài)識別什么什么的，怎樣也不嫌多。(笑)

那么接下來， 我們看一下邏輯上的Access Control機制。

第一點：秘密的管理。

任何云服務(wù)都有一堆秘密，這個秘密可能是服務(wù)器Root密碼，也可能是交換機的密碼什么的，這些東西怎么去保管，怎么去分發(fā)，直接體現(xiàn)了一個云服務(wù)廠商的靠譜程度。

任何一個云服務(wù)廠商正常運轉(zhuǎn)不可能把秘密都寄托在單個人身上，也不可能讓全公司人全都知道。 秘密管理怎么來做，這是一個很關(guān)鍵一點。Coding 使用的是 GPG Multi-recipent 加密，如果另外一個廠商能把這個事情跟你講清楚，這個云服務(wù)才靠譜。

第二點：審核記錄.

任何云服務(wù)要看他的靠譜程度， 就問他有沒有， 如何實現(xiàn)的審核記錄系統(tǒng)。 審核記錄應(yīng)該是獨立于其他所有業(yè)務(wù)組件之外一個關(guān)鍵組件，他應(yīng)該記錄了你這個系統(tǒng)里面發(fā)生的所有的事情。審核記錄是唯一、真實、可靠的數(shù)據(jù)來源。

第三點：運營系統(tǒng)的權(quán)限分級。

任何一個云服務(wù)廠商都有這個運營后臺，這個運營后臺肯定做一個權(quán)限分析，哪些人可以看到統(tǒng)計分析，我們網(wǎng)站有多少新用戶，趨勢是什么樣的。有些東西是敏感數(shù)據(jù)，除了我們運維有限幾個人，沒有人能夠訪問用戶的數(shù)據(jù)，再細節(jié)的東西，都是**嚴(yán)格把控**的，公司大部分人都絕對沒有任何的 Code Access。

Access Control 做到這里就行了么?還差得遠，想要做的好， 還有以下幾點:

第一點：Fine-grained/Rolebased Access Control.

很多云服務(wù)，從外面看起來碉堡了，但是只要接入公司網(wǎng)絡(luò)上就可以隨便改數(shù)據(jù)庫(笑)。

如果一個公司認(rèn)為他內(nèi)網(wǎng)絕對安全，那么他的服務(wù)就是絕對不靠譜。Accesss Control 首先要做到角色為基礎(chǔ)，**每個角色給固定的 ACCESS 權(quán)限**，第二點，必須**更細粒度**，具體到每一個 HTTP handler, 每一個 RPC 都要權(quán)限校驗，否則就是正在瞎扯。

第二點：Identity Delegation。

大部分的云服務(wù)的設(shè)計都是一堆超級管理員進程，這些超級管理員進程可以改一切數(shù)據(jù)，做一切事。每個bug都會影響到整個服務(wù)的數(shù)據(jù)安全。 Identity Delegation就是改變了這個事情，在入口處(和用戶直接接觸處)發(fā)了一個令牌，**以后所有的操作都帶著這個令牌去操作用戶數(shù)據(jù)**，沒有令牌就改不了。 這樣大大降低了某個bug影響所有用戶數(shù)據(jù)的可能性。

第三點: Application Level Encryption

其實大家都知道，加密很損耗性能，但是如果哪個云服務(wù)廠商沒有做數(shù)據(jù)加密，就說明你對這個數(shù)據(jù)真的是關(guān)心不夠，基本屬于耍流氓。

第四點：對應(yīng)用層漏洞的關(guān)注度

我在這里介紹一下，OWASP，是一個開源網(wǎng)站，里面有所有市面上一些常見的網(wǎng)絡(luò)應(yīng)用的安全漏洞列表，如何去處理，如何去防范它。這里列出了十大關(guān)鍵問題，如果你不知道這個列表， 那就說明你對安全的關(guān)注還不夠，趕緊上這個網(wǎng)站去看看。Coding 跟烏云，F(xiàn)reeBuf 都有合作，體系化，系統(tǒng)化的去解決這個問題。如果哪個廠商不關(guān)注這個事情，這個云服務(wù)就是不合格的。

災(zāi)難恢復(fù)

最后講一講 Disaster Recovery

一個云服務(wù)， 你問他你這個東西好用嗎，好用，安全嗎?安全。出問題怎么辦，不知道，沒人跟你說的明白。這是典型的不靠譜。

0 - 15 min：

如果一個云服務(wù)掛了，從故障開始到十五分鐘結(jié)束還沒有恢復(fù)，排除大型災(zāi)難的可能性 ，基本可以認(rèn)為他們不靠譜。

零到十五分鐘這個時間，是一個很大的關(guān)鍵時間點，他基本上是人力的極限，從出問題收到自動化報警，然后趕緊電腦打開，連上VPN，發(fā)現(xiàn)問題，處理問題，做到最快15分鐘基本上可以說是極限了。

就算你的運維團隊都是24小時不合眼電腦不離身，15分鐘內(nèi)恢復(fù)服務(wù)也需要兩個關(guān)鍵點：**第一常駐，第二熱備。**

常駐熱備災(zāi)難恢復(fù)系統(tǒng)，也就是說你必須有一套一模一樣的系統(tǒng)隨時跑著，生產(chǎn)系統(tǒng)掛了，自動切換到備用系統(tǒng)上。常駐熱備，是**隨時隨地可以切換，隨時隨地可以開始服務(wù)，能完全接管不受影響。**

你一臺機器的電被拔了，硬盤掛了，宇宙射線擊中了你的CPU，你也可以自動無縫切換。

大家還記得前一段雷擊、挖光纜的事情嗎，很多人說被雷擊了我就掛了這很正常。其實用戶管你什么原因， 你掛了就是掛了，為什么沒有常駐熱備系統(tǒng)?為什么會掛?小服務(wù)更應(yīng)該有這個能力，雙系統(tǒng)跨云部署，有了這個才有能力做 Master Slave Automated Failover?？孔V的云服務(wù)廠商才會給你講到這一點。

15 min - 3 hour：

這里的3個小時是個虛數(shù)，根據(jù)你的業(yè)務(wù)重要程度你可以自行定義。 3個小時是什么的意思呢，不管你什么樣的問題，如果你三個小時之內(nèi)修不好，你的網(wǎng)站就消失了。大家對你這個云服務(wù)的廠商的能力的信任程度就基本歸0 了。 想想如果 Coding 突然掛了，突然不能訪問了，再回來的時候基本就告別互聯(lián)網(wǎng)了，對大家的打擊、損失是無法承受的。

十五分鐘到三個小時，這是我們目前定的一個標(biāo)準(zhǔn)，不管什么災(zāi)難，三個小時之內(nèi)如果恢復(fù)不了服務(wù)，說明我們工作做得不到位。達到這一點沒有捷徑，唯一的一點就是要有**應(yīng)急備案，要隨時演練**。

我們隨時假定一個場景，外星人入侵了，搞壞了XXX(笑), 你們給我模擬恢復(fù)一下 Coding 的系統(tǒng)。這是比較高級大的演練。平時也有小的演練，三五個人聚在一起。如果有一臺機器重啟不起來怎么辦?所有的都是 Operational Readiness Drill 平時不斷的練，不斷的有準(zhǔn)備。

要做到這一點：Immutable Infrastruture。**可重現(xiàn)部署**。

很多云，包括 Coding 以前也是這樣，我開一個新機器以后，一些人裝了一些軟件。之后辭職了，突然有一天這個機器掛了就沒招了。除了把這臺機器修好了，什么也做不了。想要災(zāi)難恢復(fù)，你就要把這個東西做到可重現(xiàn)。**要清晰的知道這個機器上，裝了什么東西，為什么裝這個東西。**

做不到這一點的云服務(wù)廠商，沒有資格說我們是一個靠譜的云服務(wù)。

最后再說一下**備份系統(tǒng)**。備份系統(tǒng)好像是個挺簡單的東西，跑起來，平時也不怎么用管，然后他就解決問題了嗎?!說的好像備份系統(tǒng)一定備份了你想要的數(shù)據(jù)， 就算他備份了全部數(shù)據(jù)，好象就是百分之百不會丟東西的一樣。

每一個備份系統(tǒng)都有一個叫 Durability 指標(biāo)。也就是備份系統(tǒng)的靠譜程度。不管什么媒介，都有可能掛掉，寫到硬盤上，硬盤可能壞，寫到磁帶上，磁帶也會壞， 寫到紙上，紙都可能爛掉。就算這些都不壞，你也可能宇宙射線來了，打了一下這個硬盤。硬盤受什么強磁場某一個位置就變了，你整個東西還是訪問不了。這些東西不考慮，硬說一個備份系統(tǒng)百分之百可靠，這都是自欺欺人。

Coding 原來也沒有好的備份系統(tǒng)，我們最近在搞 AWS Glacier，它有一個大的磁帶庫，你把東西存進去的話，自動轉(zhuǎn)存到磁盤、磁帶上，定期維護。 AWS Glacier 有一個算法，每個硬盤大概多長時間壞一次，每個磁帶多長時間壞一次。最后得出來他們的Durability 可以做到11個9。

如果一個云廠商連這樣一個系統(tǒng)都不舍得去關(guān)注的話，你對用戶的數(shù)據(jù)太不在乎了。

有了備份，最最重要的還是恢復(fù)。 如果一個備份系統(tǒng)不能隨時演習(xí)細粒度的恢復(fù)，那他就是沒用的，關(guān)鍵時刻他一定掉鏈子，想都不用想。

最后的最后， 很多人說這么多云服務(wù)哪家靠譜，哪家安全。我覺得只能和大家共勉啦，Coding 做得還不夠多，很多東西都是在探索中，希望跟大家一起多交流，把云服務(wù)搞得更靠譜。

注：本文依據(jù)孫宇聰在 SegmentFault D-Day 北京場的演講內(nèi)容整理，并授權(quán)首發(fā)于“高效運維”公眾號。10月11日，SegmentFault 將在上海舉辦D-Day，圍繞 Docker 主題。