中型企業的運維平臺

這是一個未經驗證的假設，just a dump of my current thought。

大部分小企業的運維就是 ssh 加一些 fabric 腳本就能夠搞定了。極端大型的企業，好比 google twitter，好比騰訊 SNG，百度等，都有一套很是完善和複雜的運維平臺。我認爲，這裏存在一個潛在的市場機會，那就是對於那些中型企業（好比機器數量大於100，小於1000），他們的集羣規模已經使得手工加腳本管理變得有些痛苦，可是還不足夠痛苦到老闆願意花錢僱一個全職的運維開發的團隊的地步。若是咱們能夠把 google 規模的運維平臺，讓這些中型企業「低成本」的方式接入，收取小於一個全職運維開發團隊工資的費用，那麼就能夠有利可圖。

假設一：google式的集羣管理平臺比中型公司本身拿開源方案攢出來的要好用

一鍵式發佈。全景式儀表盤。各類自動故障替換。
提供強大功能的同時，不帶來特別高的管理複雜性（出問題了調試定位困難），也不帶來特別高的學習使用成本。
作一個這樣的運維平臺是不容易的。

假設二：能夠低成本的接入

若是接入意味着每個功能都須要運維寫一堆腳本，設置開發要按照集羣管理方式進行源代碼的改造，那麼就不能叫低成本接入。若是監控告警須要按照規矩在代碼裏埋特定的上報代碼，須要配置一堆複雜的參數，那麼也不能叫低成本接入。

關鍵技術一：統一的版本交付方式
運維平臺無非就是幹這麼幾件事情，配置文件修改，進程起停，以及監控告警。進程起停最困難的一個步驟是讓把進程須要的版本包安裝好。在沒有 docker 以前，這是一件很是困難的事情。一個進程有無數的依賴包，python/ruby/java 這個級別的，也有操做系統級別的 deb/rpm。docker 使得版本交付變成了集裝箱的模式，一個容器把全部的依賴包都包含進去了。進程拉起變成了一個很容易標準化的操做。

關鍵技術二：動態服務路由託管技術
運維裏最困難的就是不一樣ip之間的服務依賴管理。當一個ip要被下掉的時候，一堆相關聯的依賴服務須要更新配置文件。smartstack 是 airbnb 開源的動態路由託管方案，可讓兩個ip之間再也不緊耦合的綁定在一塊兒。一個ip要下掉，只須要在動態路由裏作一下替換就能夠了。詳情能夠看他們的博客：http://nerds.airbnb.com/smartstack-service-discovery-cloud/
若是你認爲這種作法是劍走偏鋒，只適合小公司那你就錯了。google開源的容器管理方案用的是一樣的技術：https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/ser...
當進程和端口所有託管給運維平臺以後，運維平臺能夠拿這個把整個發佈變動的自動化體系都創建起來。

關鍵技術三：通用監控平臺
以 datadog 爲表明的新一代監控公司，提供了靈活schema的時間序列採集存儲和告警方案。一套監控平臺，能夠給你的cpu使用率告警，也能夠給你的網站的訪問量異常下跌告警。不管業務領域如何，通用監控平臺提供的多維度，多值列的採集存儲方案，可讓你只要把數據報上來就能夠把一切監控好。
底層的核心技術是一個 data pipeline，加上一個基於 lucene/elasticsearch 的時間序列數據庫。監控是最容易被中型公司外包出去的業務，因此這方面的創業公司也最多。可是中國的國情是網絡傳輸成本大於計算成本，因此如何在客戶計算中心內完成採集，計算存儲，而不是把源數據都發過來是一個關鍵問題。

關鍵技術四：通用異常檢測
傳統的監控平臺須要運維配置各類閾值。理想中的智能數據中心，用戶只須要把數據源指定好。剩下的採集，上報存儲，異常檢測都是自動的。根據各類算法，利用數據的相關性和週期性自動給出異常告警，無需運維再去配置閾值。

總結： 當市場再也不被幾個巨型巨頭佔據，一批中型公司崛起的時候，當這些中型公司的架構開始向 micro-service，scale out 的方向發展的時候，當 docker 等技術讓「低成本」標準化接入變成可能的時候，這三個條件將迸發出一個運維平臺服務（ops platform as a service）的市場。