UPYUN 創業于2005 年,當時服務器使用的網卡還是Marvell的芯片,要通過自定義內核和驅動源代碼做編譯才能驅動起來。而十年后在運維方面已經產生了翻天覆地的變化,本文系統地總結了 UPYUN 的云運維的野蠻成長、踩過的坑以及現階段的狀況。
運維的藝術
運維的藝術是彈性。首先,從無到有,這非常重要。無論運維做得多厲害,只是前面的“1”之后,加上多少“0”而已。從無到有很困難,但它是可以實現的,全力以赴去做,增長會很迅猛。
運維總共有幾條線呢?
-
二是從小到大。當服務器的數量達到有多少屏都看不全的時候,監控的手段就變得非常重要。這時候有一種方法是白盒運維;
一家公司從小到大,不可能一口吃成胖子。第一階段的重點是可用,第二階段著重把現有的技術用好,第三階段就要讓它變得更好用。
隨著業務增長越來越快,客戶的要求越來越高。在UPYUN 的架構里面有了非常深入的應用,做了二次開發。當服務器數量越來越多,運維自動化越來越快的時候,如果監控做不上去,很容易失控。因此運維的技術彈性可控,是很好的方式。
架構是計劃出來的,不是設計出來的,在不同的時間和階段,要用不同的方法實現目標。并不是發展得越快越好,而是要接地氣。
運維的法寶
運維的法寶是三位一體。其一是運維自動化和流程化,方法有很多種。原來我做的是車載,既然要做到12兆,里面不可能有拍攝,一個拍攝的包沒三、四十兆做不到。目標是一樣的,一定要會用工具,把容易出錯的事情用腳本規范好。
其二是監控常態化,及時報警及隔離,觸發補救措施。事故不可能無緣無故的發生,肯定是之前的工作留下了什么隱患,需要及時查清。要對異常采取及時的處理,UPYUN 使用第一人稱的腳本做監控,發生異常狀況它就會出來匯報。
最明顯的是DDos攻擊,總是事后才發現,因為流量打過來,最先感知的應該是網卡。針對這點,UPYUN用腳本捕捉網卡的異常上升流量,可以接收到它“臨死前”發出的警報,運維人員就可以根據這個及時把受攻擊的節點摘掉。
其三是性能可視化,運維要對自己的業務負責,提供連續的健康度報表,以爭取資源。因為運維需要拿到機器或足夠的硬件,否則工作很難進行。當運維和老板或是上級講技術點時,如果他們聽不懂,就可以把報表拿給他們看。這就是性能可視化的一個重要的意義。
方向比努力更重要,流程比補位更重要,方法比拼命更重要。在2015年,UPYUN 都在做流程的改進,之前太粗放了。
部署自動化
部署自動化的三個要素:應用、網絡、硬件+系統。第一期時UPYUN用awk、sed、bash,第二期換成了Ansible+playbook,第三期開始使用cmdb+Ansible。發布流程之前很不規范。比如運維需要cmdb+Ansible的結合,但發現還沒做,怎么辦呢?就可以用定時定點的方式規定好星期三做發布、星期二做測試。屆時大家去一個會議室,事先設定好,屆時開始觀察。星期五繼續觀察,發現有問題就回退。
這些只是中間過程,因為運維知道我要做什么。定下目標之后,中間的過程就可以很好的控制。起初UPYUN和H3C做對接,購買它的設備,它提供技術解決方案,F在做到BFD,有多個數據中心,可以用光纖做互通。
現在UPYUN 不僅有兩根裸纖,還有八個口。UPYUN從北京、中山等數據中心做最近路徑的選擇。國內的中轉機房,像電信、聯通和移動,對于堆迭、靜態聚合,云存儲是內網做冷存儲,公司跟交換機做堆迭,因而吞吐量有保證,交換機也可以備份。
隨著體量越來越大,UPYUN從IDC拿到的籌碼也就更大,比如2G的保底量,他們給UPYUN起三層,無論在抗攻擊能力、網絡拓撲結構上,有更大的靈活度。拿到 A 輪融資以后,UPYUN的第一件事,就是把網絡設備升級成萬兆交換機。因為前面有LOVS,可以做擴展擴容。而如果網絡無法擴容,要擴這個點的話,業務就必須切掉。因此跟機房談一個萬兆口甚至是兩個萬兆口時,必須網絡先行。硬件直接跳到嵌入式小系統,當機器只有一塊盤的時候,把它從五變到六,機器就必須下架。
如果用小系統就會發現,這里有兩種介質:U盤和磁盤。如果要升級系統,UPYUN可以把系統切到小系統,對磁盤做操作系統的寫入,前后不超過三分鐘。UPYUN 現在可以做到上千臺的機器從來不在公司出現,直接把系統寄到生產線,在生產線上把U盤插上去,從生產線連接到機房,機房人員插線后,UPYUN 的運維團隊就可以進行遠程控制。
這是最基本的系統,它不會將UPYUN的敏感數據帶進去。否則的話,這么多CDN機器發到公司,要解包、安裝系統、測試等,運維會忙不過來的。在部署自動化方面,UPYUN有完善的工具和流程。
如今,很多大會都在談運維自動化,這跟企業的系統架構設計緊密相關。當運維在架構上保證降級后,很多事情需要推動開發來做,開發部門要配合你降低維度。不久之前,UPYUN 就曾經做過一次降級,還是相當成功的。
監控常態化
監控常態化,這其中包含了很多的經驗教訓。監控要素不全面,監控性能跟不上是比較大的問題。通過總結經驗,UPYUN發現zabbix當采集了1000+多臺服務器的各種監控指標后,性能就跟不上了。
監控要分等級。100臺可以靠肉眼監控,100至1000臺就需要用Zabbix 和第一人稱報警。UPYUN 有自己的業務監控,還有全國節點分布圖,UPYUN 有大約3000多臺服務器,就把數據做匯總,進行數據可視化的處理,成功實現帶寬質量圖、ELK數據分析、小米監控。UPYUN 對小米監控的部分功能進行了二次開發,現在它的整體性能要比Zabbix好很多。
此外,還有UPYUN自行開發的“狗眼”監控系統。它能夠監測到每一個子系統的響應速度。包含全國節點帶寬圖,它用紅色、綠色、藍色進行狀態標記,還可以顯示各節點的服務器數量。UPYUN“雙十一”入駐蘑菇街時,就可以通過該系統看到所有機房的實時數據監控。其實,監控策略很簡單:每天盯三個最慢的機房,逐個排查原因,這是做SLA的保證。
今年上半年,運維團隊的口號是“發現問題比客戶及時”,但可惜一直做不到。這是因為客戶是24小時在線上,每次都是客戶比我們快,這讓人很苦惱。而在用了ELK的日志大數據分析后,UPYUN 很多時候就可以做到先于客戶發現了。
性能可視化
關于性能可視化,現在可以做到在緩存軟件上做Nginx+lua。我們同時用兩個,其中一個負責SSD,ATS可以做到秒級重啟,上面有LVS做負載均衡。運維不能保證這個集群里ATS同一時間存取,但如果內容泄露過多,就得強制重啟。因此UPYUN 現在招了兩個專職人員研究ATS源代碼。另外,UPYUN 自研了擁塞算法。第三方提供的算法可用性很低,但是它們的內核在UPYUN升級很快,Linux的代理升級要與應用程序一樣快,而內核的升級會提升性能。
2015年5月份左右,UPYUN 開始關注Mesos+Docker,之前一直選擇OpenStack主要是出于節約成本的考慮。而在發現Docker很好用后,團隊開始集中精力研究Docker。ELK可以做很多事情,可以看到低于100毫秒、300毫秒、500毫秒、1000毫秒,有4xx、5xx的比例,數據報表一點點小波動都可以看到差異。UPYUN曾經做過測試,沒使用優化內核算法和使用了新的hybla擁塞算法,從3.18的內核升到4.1的內核,數據會有提升。Kernel要自己把握,3.18到4.1的時候,我們曾經遇到過一個問題:內網做TCP的時候做大包調整很爽。但放到外圍CDN的時候,4.0出現了Bug。4.0的內核在因特爾1000的網卡雙向組合的時候會無響應,而3.18的內核接入就沒問題。它的好處顯而易見,但一定要把握度。
運維的煩惱
作為運維人員,會有很多煩惱。第一點,運維很多時候都要扮演“接盤俠”和“背鍋俠”的角色,因為公司要有一個人出來承擔責任。如果運維能夠在這個壓力下解決問題,獲得老板認可,那你就是合格的。
另一點是頻繁申請和更換資源,F在OpenStack和Docker都有這方面需求。Ansible和Mesos也很實用,現在幾千臺服務器都有Docker。第三是監控不到位,這點可以用ELK和Hadoop來解決。第四是消除單點,這一塊可以借助LVS+Haproxy。在硬件方面,雙電源、雙電力、多運營商、雙交換機、雙機柜、多機房這些配置,需要根據業務不同的發展階段做權衡,來進行選擇。
運維的指導思路
運維的指導思路。首先是與人無關:要將機器負載均衡做得滾瓜爛熟。用腳本、Playbook做機器生成,跟人無關。其二是與己無關:要舍得把東西交出去給下屬做,自己不斷學習新的東西。第三是與狀態無關:運維要做無狀態和擴展性,有些程序員很喜歡有狀態,這就要考驗你、工程師和CTO的能力,推動程序員去做。最后一點是與數量無關:要做部署的恒定,運維話語權的增長,很多時候是在業務突飛猛進時,運維成本仍保持不變,自己在老板心中的威信就會提升。
運維的修煉

關于運維的修煉。首先是要閑下來,多掌握技術;其次是走出去,多參加活動,多互相學習、交叉分享;第三是多問為什么,學思結合,掌握更多信息,學以致用。而自己講的東西要深入淺出,所有人都聽得懂。
核心關注:拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業務管理理念,功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理,全面涵蓋了企業關注ERP管理系統的核心領域,是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處:拓步ERP資訊網http://www.guhuozai8.cn/
本文標題:云運維的啟示與架構設計
本文網址:http://www.guhuozai8.cn/html/consultation/10839720014.html