該放棄正在墮落的「RNN和LSTM」了

摘要： 阿里巴巴千億交易背後，如何儘可能避免發佈故障？在面對實際運維過程當中遇到的問題該如何解決？近日，在剛剛結束的 GOPS·深圳站大會上，阿里巴巴運維技術專家少荃，給咱們帶來了解決方案和思路。

前言

近幾年，咱們在發佈效率和穩定性方面作了很多工做，其中效率簡單的說就是發佈耗時，一個是發佈的速度，好比一個應用是1個小時發佈完成，仍是5分鐘發佈完成？另外一個是人員介入，開發在發佈過程當中是否須要介入處理各類發佈過程當中出現的問題？這二者都作好了，才能說是發佈效率提高了。穩定性最基礎的是系統的穩定性，保障系統的可用，而最關鍵的是要保障經過系統來進行發佈的應用的穩定性，不會由於發佈而致使服務不可用等故障出現。

效率這塊咱們在集團內比較受好評的產品是SP2P的文件分發系統，叫作蜻蜓，咱們根據阿里自身的一些特色，實現了一套安全高效的P2P分發，同時在P2P的協議上引入了超級節點，就是S，提高了P2P網絡的啓動速度，目前已經開源。穩定性這塊咱們去年作了一個產品，叫作無人值守發佈，對發佈進行檢測，看看發佈是否會引發問題，來提高發布的可靠性，今天就和你們一塊兒交流下這方面的心得。

線上發佈之痛

咱們爲何要在穩定性方面投入大量精力呢？先讓咱們來看一個笑話。

變動故障

這個笑話可能沒那麼可笑，可是它真真切切的說明了一個問題：理想和現實的差別，你覺得是有四個單身狗陪你，可是實際倒是另外兩對情侶。這個和咱們作生產環境的發佈是同樣的，咱們覺得憑藉咱們出色的邏輯思惟能力，已經把全部場景都想到了，測試也作的很充分了，可是，發佈上線後，常常會遇到實際結果和預期不一致，故障發生了。咱們針對阿里的故障產生緣由作了統計，其中很大一部分都是線上變動引發的，相信在座各位也會遇到或者製造過故障，開發和運維的同窗對故障都是很敬畏的。

故障你們都遇到過，可是故障的影響差別會比較大。有些故障多是故障發現後處理了一會就恢復了，有些故障則可能會致使嚴重的後果。因此咱們須要儘可能避免變動帶來的故障。

業務挑戰：阿里的特殊業務場景

回到阿里，咱們都知道，去年雙11的成交額已經達到了1682億，想象下，這麼大的交易額下，若是出現了故障，那會怎麼樣？

阿里如今的業務多樣化發展，新零售、線下支付等一些新的業務場景，要求咱們對故障更加敏感，要可以更好地避免故障，更快地發現和處理故障。想一下，若是是線下場景，好比用支付寶坐地鐵，若是出現幾分鐘的服務不可用，那會怎麼樣？

如何纔能有效的避免故障發生呢？

那麼，如何才能在發佈的時候有效的避免故障發生呢？

靠「蒙」？你們知道確定不行。但是細想一下，不少時候確實或多或少在「蒙」。我我的是有過相似感覺的。咱們雖然不會隨便到不通過測試就進行線上發佈，可是雖然已經通過了多輪測試，確定仍是沒有辦法覆蓋線上各類複雜多樣的場景的，而這些沒有辦法覆蓋的場景，就只能靠運氣去"蒙"了，運氣好的，這些場景沒有問題，運氣很差，恰好就其中一個場景出問題，出現故障了。

一般來說，爲了儘量不要去「蒙」，咱們會對上線流程加入各類驗證環節，來保證發佈儘量可靠。例如發佈前，咱們會經過各類測試來驗證功能是否ok，包括單元測試、集成測試等，發佈過程當中，咱們會經過一些發佈策略，例如先預發(預發佈是一種特殊的線上環境，和線上使用一樣的資源，好比數據庫等，可是不會有用戶流量進來)、而後灰度、而後分批滾動發佈等方式，逐步將變動更新到線上，發佈完成後，又會藉助一些故障預警系統，例如像阿里有GOC來儘早的發現故障，進行處理，這些環節的這些手段都已經有成熟的系統來進行支持，可是發佈的時候，咱們經常仍是內心沒有底。

"人工智能"的解決方案

那麼，還有什麼辦法可以幫助咱們儘量地保障發佈質量呢？你們可能都已經在作了：就是"人工"智能的發佈保障。

在發佈過程當中，盯着各類屏幕，去看各類數據，來人肉的判斷本次發佈有沒有問題。在阿里，這些屏幕包括：監控、發佈單、機器、GOC故障預警等。監控可以反映出來當前系統的一些情況，例如機器的負載是否上去了，接口的成功率是否降低了，發佈單則能讓咱們瞭解當前的發佈狀況，有多少機器已經更新到新版本了，有多少還在跑舊版本，有多少機器啓動又遇到異常了等等，盯着機器則能夠看一些日誌信息，是否有一些新的異常出現了，異常的量是否很大等等，GOC讓咱們在故障發生的第一時間就能知道，結合本身發佈的內容判斷是不是本次發佈引發，須要進行處理。

這種方式相比以前讓人放心多了，是由於如今咱們看到的是最真實的線上環境的狀況，而不是單單的測試數據。可是這種人肉盯屏的方式也存在着很大的問題，首先是成本過高了，發佈過程當中須要有熟練工盯着各類屏幕去看，片刻不離，其次是人的因素太大了，一樣的發佈狀況，不一樣的人分析出來的結果可能徹底是不同的，即便是同一我的，由於狀態或者其餘方面的緣由，針對一樣的一些數據，可能分析出來的結果也不同，另外，人也有侷限性，各類數據刷新很快，肉眼分析的方式根本都來不及看。

既然這種盯屏的方式被證實是有效的，可是存在一些問題，那麼咱們就考慮經過系統化來解決這些問題，因此，就有了"無人值守發佈"。

無人值守發佈

無人值守發佈主要是把上述過程自動化、智能化。經過自動化採集這些實時的線上核心數據，進行智能化分析，迅速對發佈情況進行判斷，是否有故障發生，有的話則當即終止當前發佈。

無人值守發佈的兩大核心能力，一個是故障檢測，一個是異常推薦。故障檢測主要是發現如今的問題。異常推薦主要是防範於未然，是指發佈出現了問題，可是不必定會引發故障，這些異常給開發的同窗透明出來，須要開發注意，比較常見的是出現了一些異常，這些異常從絕對數量或者漲幅來看沒有很是明顯，但多是須要處理的。

什麼是無人值守發佈

首先是發佈單詳情頁面中的無人值守信息展現，發佈單詳情頁面是發佈過程當中最常會去看的頁面，因此咱們選擇把無人值守檢測出來的一些信息展現到這個頁面，在一個頁面中把能夠作的事情都作掉。固然，並非說開發同窗必定要本身去刷這個頁面纔可以知道當前發佈是否有異常，當發佈出現異常的狀況下，系統會先自動暫停當前的發佈，而後經過釘釘等一些通知方式，告知開發的同窗，你的某個發佈出現了異常，須要你去看下。

這些展現的信息包括了左側的當前發佈是否有異常的概要信息，經過概要信息，能夠知道當前發佈有沒有問題，若是有問題，能夠看右側的問題分類，是基礎監控指標出問題了，仍是業務指標出問題了，或者是日誌出問題了，日誌出問題具體是哪一個日誌有問題了，在這裏均可以看到。

若是這裏的信息還不夠來判斷是否發佈有問題，那麼點擊查看詳情，能夠看到更加詳細明確的異常信息，來進行判斷。

無人值守發佈的時候須要應用接入到無人值守發佈系統，固然大部分狀況下這是一個自動化的過程，系統會判斷應用是否符合接入標準，若是符合，會自動接入，可是也有一些狀況會致使應用沒法自動接入，這種狀況下，也會告知用戶當前應用是否接入了，若是未接入，須要作一些配置或者改造來接入。

無人值守發佈詳情