阿爾法狗機器戰勝人類，伺候機器的運維在哪裡？
2016年3月最火爆的新聞，莫過於谷歌的alphago機器4:1大勝李世乭了。一時間各界議論紛紛，我的前同事，運維界非著名段子手 @orroz 在自己微博上寫了兩段話：
跟其他運維工程師覺得這個職業將消失不同，我對運維職業是持極端樂觀態度的，也許運維職業將是人類最後一個職業。很可能祂們在能自理之前還需要我們伺候……也說不定，某幾個運維工程師因為某種不知道的原因還會被祂們當寵物留下來，成為人類的最後的延續。
我終於明白這個圖片的寓意了，它其實預示了人類未來的命運。
看完一笑~
但是笑完以後，回頭想想，運維和圍棋手，其實還真有相像的地方：傳統說法中，與研發相比，運維總被認為是“更靠經驗的”；一如我們說“人類棋手的經驗和大局觀”。
我們知道，運維的“操作”，已經是可替代的了，IaaS、PaaS、運維自動化，諸多概念的落地，環境部署、軟體安裝不再是運維的主要工作職責。運維的職位名稱，從系統管理員到運維工程師到產品工程師到站點可靠性工程師，一步步遠離了基礎裝置層面。
那，有沒有可能，運維的“經驗”，也是可以被機器替代掉的呢？
運維經驗
我們先看看運維的經驗到底是什麼？
- 一個4核CPU的伺服器，loadavg跑到10+，我們就會說：負載過高了。應對辦法最簡單的就是“加機器”。
- 一個web服務，每秒請求超過1000，響應變慢了，我們就會說：還在用apache啊？快換nginx吧。
- 要是動態服務呢，就會說：做個動靜分離唄，加個快取層唄。
這就是運維屆的“定式”和“俗手”。
但是不巧，定式並不能一路保送我們最後順利完工。
就好像這五場世紀大戰一開始，人類棋手總覺得alphago水平不行——“職業初段的人都應該知道下這裡才對啊”。但是一百多手不知不覺過去，局面就是不利了！
運維經驗的坑
比方前面說的第一條經驗，這幾乎已經是運維共識了。但是把環境考慮進來：這如果是一臺虛擬機器呢？這如果掛載的是一個遠端儲存呢？這如果執行的是一個無法水平擴充套件的事務系統呢？
是的，“加機器”只能死得更慘（此處應配有那兩把著名的劉強東之刀）。
所以，經驗是否真的能成立，有賴於更復雜和深層次的分析。就像圍棋依賴於算力一樣。
大資料那麼美好麼
文章寫到這裡，似乎我要開始鼓吹運維界要如何如何上馬大資料乃至機器學習了？
這種玩法看起來確實高大上，但實際上，並沒有那麼美好！我們不要忘了：運維始終是一個IT支出向的工作。DevOps運動中說運維加快部署就是賺錢，那也是間接的，花錢是直接的。還是引用另一個微博上有關alphago的段子：
alphago跑了1000個CPU，李世乭吃了一餐飯，比一下資源消耗就知道誰贏了。
運維工程師擁有前所未有之多的機器資料，理論上當然可以通過大資料探勘，通過機器學習獲得相當多的收穫。但是這些收穫跟能間接帶來的收益相比，價效比如何呢？
拿監控資料來說，我們知道監控產生的，大多是時序數值。對於時序數值的分析，金融界早有數十年的演算法研究和積累。運維工程師照搬過來，未嘗不可。但這其中一些演算法消耗的CPU運算，沒準比本身業務系統執行消耗的還高，那這個花費顯然就不可能投入。
《人工智慧的未來》作者，神經學家Jeff Hawkins成立的numenta公司曾經對市面上各種號稱處理時序資料異常探測或者預測分析的開源實現做了對比性測試。結果，真正能滿足“時序、動態”前提的都不多，有些演算法長達一個小時都完成不了測試。更好玩的是：有的測試場景中，隨機選異常點都有25.9%的準確率。
測試見：https://github.com/numenta/NAB（當然我這裡不是來推銷說HTM演算法是人工智慧未來，畢竟alphago是DNN呢）。
廢話這麼多，到底該怎麼辦？
又要深入分析，又要控制能耗。最好的辦法，就是把不確定性降低，在一個較完善的運維體系框架基礎上做資料分析，可以大大縮小資料集，降低複雜度。
運維體系怎麼才算完善，已經有很多文章在講了。分析本身如何入手，其實簡單演算法也未必不好。百度雲在SREcon15上的分享，推薦觀看。線上資料通過簡單的3-sigma、ks-test、holt-winters、LOESS來生成異常點，然後僅對異常點採用Viterbi計算同比的異常區域發出實際告警，配合通用的tracing呼叫鏈系統使用。
最後回到文章開頭的段子：機器為啥留下幾個運維工程師？或許因為這幾個運維當初給機器安排的都是算3-sigma這樣輕鬆的活，一報還一報吧 。