阿里雲宕機故障 - 思考如何保障系統的穩定性

本文轉載於本人的微信公衆號中的文章，最新文章請關注右側公衆號。

目錄
背景與挑戰
何爲系統穩定性
影響系統穩定性因素
如何保障系統穩定性
總結

1、背景與挑戰

1. 背景

3月3日凌晨，阿里雲宕機故障 --- 驚魂三小時的故障，讓華北地區很多公司的APP、網站和內部系統紛紛癱瘓。消息瞬間佔領的社交、媒體的頭條。有網友調侃道到，「一大波程序員、運營和運維從被窩爬起來去公司幹活了」、「 阿里雲一年一宕機，今年特別早」。
  擁有雄厚資金、技術和大量的人才的阿里雲尚且如此，那麼咱們中小公司又要如何見招拆招？
  在《微服務架構實踐》文章中提到，咱們面對的業務主要知足兩大類業務需求：面向餐飲企業在餐飲新零售下的經營需求、運營需求和麪向產品及運營團隊。能夠理解爲咱們就是爲餐飲企業提供信息化解決方案的ISV。沒錯就你大腦中浮現的，相似給三大運營商、電力企業等承接作信息化系統的公司。
  公司的SaaS平臺中，有一條產品線 --- 外賣（此外賣非彼美團、餓了麼外賣）姑且稱之爲「雲平臺外賣」，咱們在哪些方面作了穩定性、又是如何落地的？咱們從一個用戶視角的訂單全生命週期流程中，來看下咱們「雲平臺外賣」處在什麼環節：

• 以普通用戶的視角來看，一個外賣訂單從下單後，會經歷支付、商家接單、配送、用戶收貨、售後及訂單完成多個階段。

• 以技術的視角來看，每一個階段依賴於多個子服務緊密配合，確保訂單順利完成。

2. 挑戰

• 流程較長且實時性要求高
  外賣訂單業務是一個須要即時送的業務，對實時性要求很高。從用戶訂餐到最終送達用戶，通常在1小時內。若是最終送達用戶時間變長，會帶來槽糕的用戶體驗。

• 訂單量高且集中
  一天內訂單量會規律變化，訂單會集中在中午、晚上兩個「飯點」附近，而其它時間的訂單量較少。這樣，飯點附近系統壓力會相對較大。

咱們的「雲平臺外賣」是處在商家接單的環節；商家接單，也是一個很是複雜的處理流程，咱們抽象成簡單的流程：

咱們面臨的挑戰:

• 「實時」接單無延遲

• 「實時」接單無丟單

任何一種狀況發生，客戶都會面臨着營業額減小甚至客戶門店被外賣平臺關閉的風險。

2、何爲系統穩定性

軟件系統的穩定性，很難有一個恰當的模型表述。若是採用數字量化的話，咱們也能夠採用SLA服務協議說明系統的穩定性。
正所謂「千里之堤，潰於蟻穴」，看似可有可無的代碼片斷可能會帶來總體軟件系統的崩潰。

3、影響系統穩定性因素

軟件系統穩定性影響因素比較多，咱們從軟件工程開發過程當中，梳理出常見的因素：
咱們要在軟件設計的階段，要充分考慮系統穩定性因素；一旦考慮不周，當線上系統面臨快速增加的業務時，噩夢就會連連。

4、如何保障系統的穩定性

1. 系統穩定性保障的指導思想

• 負反饋調節法

• 肯定目標，並加入控制條件；根據反饋結果不斷調整，朝着可能性空間縮小的方向發展，使目標差在一次次控制中慢慢減小

2. 系統穩定性保障的基本準則

• 規範流程

• 本身不做死

• 不被隊友搞死

• 多部門間的協做聯動

3. 系統穩定性保障的技術措施

咱們從多個方面經過嚴謹的流程、架構、技術、測試以及運維保障系統等手段來保障系統的穩定性。可是，要保障系統的持續健康運行，還須要多部門間的積極的協助聯動。

5、總結

上述梳理，咱們知道線上系統故障主要是：

• 自身系統的問題

• 外部系統的問題

• 基礎設施的問題

全部的軟件系統問題，最終癥結在於架構、產品質量和技術工程方面的問題。
需求千萬條，質量第一條。架構不合理，開發運維兩行淚。

-EOF-