資深架構師Theo談統計學，業務與運維工程師的成長
原創【51CTO獨家專訪】過去兩天的O'Reilly Velocity China 2011的會議上，來自OmniTI的Theo Schlossnagle帶來了兩個系統運維們應該都很關注的話題：一個有關監控，另一個有關運維的職業生涯。觀看了兩個演講之后，51CTO編輯整理了一些大家可能會感興趣的話題，邀請Theo做了一個專訪，現在將專訪內容整理如下。Theo的兩個講座視頻和PPT在未來幾天可以在Velocity大會的官網上下載到，想要大概先了解一下的朋友們可以先到我的家園相冊看看部分Slides的照片：
嘉賓簡介
Theo Schlossnagle 是 OmniTI 的創始人和首腦，為高流量網站和其他需要可靠、可擴展架構工程的客戶設計和實施解決方案。他是高可擴展的 Momentum MTA 架構師，Fontdeck CDN 的架構師，Circonus SaaS 監控平臺背后的導師。Theo 參與很多開源社區，包括 OpenSolaris, Linux, Apache, PostgreSQL, perl以及其他很多。他是可擴展系統和分布式系統方面的作家，也是開源會議上的資深講師。
以下是采訪內容的文字整理：
51CTO：您在昨天有關監控的課程中講了很多統計學的內容。您認為DBA和運維們需要了解這些知識嗎？
Theo：我認為對于工程師而言，了解基礎程度的統計學是一項基本要求。因為我們每天都在關注系統的各項數據：硬盤是不是慢了？網絡是不是慢了？我們將“太慢”這個概念量化成具體的數值，從而理解這個系統。如果我們每天看這些數字，而沒有統計學的基本知識，那就說不上真正理解這些數字。
51CTO：像是Nagios和Cacti這樣的工具目前做到這一點了嗎？
Theo：算不上吧。Nagios做的僅限于提供一些數字——目前大部分系統都是這樣做的，它們被設計隔一段時間做一次檢查，比如每隔一分鐘做點什么動作，返回一個數字。而現實中，我們面對的很多行為，好比硬盤讀寫的行為，它往往在每一秒內會執行成百上千次，所以如果我們能夠仔細研究每一次讀寫的實際行為，通過這樣對硬盤讀寫的理解，肯定要遠遠超過只是取一個每分鐘的平均數。你想要了解***值是什么，***值是什么，你想要了解一個分布的情況，98%或者99%的讀寫速度在一個什么值，如此這般。這個我認為是我們需要的。
Cacti相對好一些，它目前提供了一些基本的統計功能，你可以查看數據的標準偏差，但是其他的相關數據還很有限。
51CTO：那么你們在OmniTI用的監控系統，是完全自己寫的，不是通過其他監控系統修改的是嗎？
Theo：是的，我們完全自己寫的整個監控系統。這個系統是開源的，而且監控數據寫入數據庫，你可以直接用來做統計分析，或者像很多專業數據分析人士做得一樣，將數據抽取出來，放到比如R這樣專業的統計工具當中去。用R來做統計相對高階一些，但是很多時候我們通過借助手冊的幫助，也可以很容易的做一些基本的分析。
比如你在網站上放了JavaScript監控代碼，它能夠返回每次頁面加載花費的時間。假設它放在那里跑了一天之后，收集到1億次用戶點擊，也就是1億個PV。你想知道的情況是，頁面加載的速度如何。如果給你一個1億次頁面加載時間的平均數，這個肯定是沒啥用的；你想知道的是分布的情況，有多少次訪問在1秒，有多少次訪問在10秒，等等。這樣就會收集到很多數據點，你需要一個視圖的方式明白的呈現出來這些數據代表了什么意思，那么這時候就可以用R語言。當然做這個也有其他的工具，但是R是最簡單、***的。
51CTO：運維工程師的工作，一直以來都無非是部署、監控、安全、備份、排障、調優這些。您認為這方面的工作在未來會有變化嗎？
Theo：我認為這些工作不會有太大的變化，只不過是有些工作變得越來越簡單了。備份數據，部署新的系統，我覺得這些方面的技術已經越來越好，越來越容易做。咱們每天工作按8小時來算，以前你可能花6個小時在分發、打包、部署、備份這些工作上面，而現在你可能只需要1個小時了。這樣下來，你就有更多時間考慮性能優化、資源規劃這些事情——你以前在這些事情上可能只有1小時的時間，但它實際上值得你花每天8小時。
51CTO：那您認為運維工程師這樣的技術人員應該多花時間去了解業務嗎？
Theo：哦，當然需要了。當然，他們不需要了解所有的業務；不過他們至少需要知道，自己管理的這些機器為什么在運轉？我自己見過這樣的事情：有一個系統在運行了好幾年之后，才發現這個系統早就沒有人在用了。那是一個數據倉庫的業務。最開始你有一個數據庫，以及一個數據倉庫。后來，又啟動了一個新的數據倉庫。所有用戶從舊的數據倉庫遷移到了一個新的數據倉庫，但是居然沒有任何人通知系統管理員！所以舊的系統還一直在跑著，磁盤陣列跑著，耗費著電力，還有一堆之前設計的自動化腳本在運轉。系統管理員一直也沒去看這個系統，以為還有人在用；而業務方面的人則沒有一個想起來要把舊的系統關掉。
51CTO：難道系統管理員不會覺得奇怪嗎？比如發現一直沒有用戶請求之類的。
Theo：哦，這個系統很久以前就沒有用戶提需求的，因為都完全自動化了。在一個數據倉庫系統里面處理的任務可能是將每天的銷售數據打包存檔，發郵件到某人的郵箱里面去。換了新系統之后，可能由于某種原因，也一直沒人去檢查那個舊的郵箱，所以就這么一直跑著了。
還有另外一種情況，比如帶寬的使用。你購買了一定的帶寬，但實際上未必需要用到那么多，不少企業對于這其中的成本浪費并不是特別明白。
還有另一個例子：我們有一個客戶，他們的首頁一開始不用緩存，因為頁面是動態顯示數據的，客戶說必須要讓頁面隨時顯示***的數據，比如最熱賣的產品之類的。因為客戶堅持不用緩存，最初我們在架構設計中只好為這個首頁安排了60臺機器。每次在軟件工程師提出要為頁面做緩存的時候，客戶就大搖其頭的否決：“不行不行，我們必須要顯示***的數據，不能讓首頁顯示老的數據”。***一個SA實在受不了了，問道：“顯示***數據的商業理由究竟是什么？難道1秒之前的數據都不行嗎？”客戶反饋說：“這個啊，1秒鐘當然是可以的啦。”所以***，60臺機器優化成了一臺。
所以我覺得很多時候，是人們之間沒有溝通清楚。我們沒有真正明白，究竟為什么要跑這個應用軟件。客戶丟過來一個問題，我們就埋頭解決這個問題，啟動機器，然后看到沒人抱怨，我們就當作沒問題了——這其中其實是很有問題的。
對于運維這個領域我一直是這樣理解的：運維（Operations）的本質是讓業務跑起來，而不是讓系統或是一堆計算機跑起來，所以身為運維，必須要去了解業務。如果他們不去了解業務，那么他們就不會明白如何讓業務***化的運行。在現實中，整個需求的傳遞往往是一條長鏈：業務需求傳遞給產品經理，產品經理傳遞給軟件工程師，軟件工程師再傳遞給系統管理員……而到了這里，可能我們早就不知道真實的需求到底是什么了。我認為就是應該將最原始的需求拿出來，大家在一起討論比較好。
51CTO：您的意思是我們要盡量減少這些中間人的存在嗎？讓用戶的需求直接傳達給實際干活兒的人？
Theo：我認為這是一個平衡的問題。在優秀的公司當中，整個鏈條是存在的，我們有產品經理，有專注交互的，有專注界面的，還有底層這些。我想說的是，從一開始，我們就需要來自軟件工程師、系統管理員和DBA們的參與，讓他們參與“定義問題”的過程。大家聚在一個屋子里面各抒己見，才能夠更好的理解各自的觀點。
51CTO：您在早上提到了運維的職業發展需要向“多面化”的方向走，那您認為以后這個領域仍然會按照系統管理員、運維、DBA這些職業進行劃分嗎？
Theo：哦，職業細分這方面肯定還是不會變的。你很難在每個方面都成為專家的。所謂多面化的意思是這樣的：在規模很大的公司里，尤其是在對性能優化非常關注的互聯網公司，比如淘寶這樣為這么多用戶提供服務的網站，他們遇到的問題都是很難解決的問題，他們會需要對各方面都熟悉的人才。因為在一屋子的人都是較窄領域的專家的時候，他們很難去“越界”的處理問題，因為缺乏在其他領域的能力。好比你遇到一個數據庫的問題，而這個問題如果你對數據庫下面的操作系統有一定了解的話，可能會很容易就發現問題所在了。
51CTO：那好比OmniTI招聘的話，你會期待一個什么樣的工程師？
Theo：這個問題真難……我們的話，首先會要求對方有很好的分析能力，能夠按照嚴格的科學方法去發現問題，然后解決問題。你知道，有太多的人會在還沒了解問題的時候就急急忙忙的跑去解決問題。我面試過的很多人，他們之所以沒有拿到這份工作正是因為這個原因。我會問他們一個問題，比如“我們的網站很慢。你要怎么做？”而他們沒有提出足夠多的問題，而是直接開始說“我會這樣這樣做”等等。他們根本連問題是什么樣子的都沒搞明白。而相比之下，那些更善于挖掘問題的應聘者——他們往往是相對不那么聰明的一群人——往往能夠給出更好的答案。
這是方法方面。第二就是，這個人必須愿意學習。這樣的人真的非常難找！
51CTO：那你們現在也會通過社交網絡等方式來尋找這樣的人嗎？
Theo：實話說吧，在招聘方面我們算不上多成功。我們的員工都非常的優秀，但是我們招聘的速度實在是跟不上需求。
社交網絡方面，我們主要關注代碼社區，比如Github；傳統的Job List方法也在用，招聘網站什么的。反正是什么方法都用唄。
51CTO：***一個問題。隨著云計算的發展，人們預測外包業務將會越來越多。這種情況下，您認為系統運維的就業環境是否會變得越來越局限？
Theo：這個我倒不完全這么認為。現在很多用云計算服務的主要還是小企業，他們的需求也就在50臺到100臺機器上下，在內部系統方面，肯定IT管理員是會減少的，因為像是搭建Exchange郵件服務或是配置電話交換機這種工作，放在哪個公司都差不多，外包在這個方向更有優勢；但是網站和Web應用就不一樣了，每一家網站的業務都是不一樣的，有定制，有優化，不太可能交給外包就能直接搞定。你搞電子商務的，把網站外包出去運營能行嗎？我覺得是不行的，因為這樣你就失去了你的差異競爭力。
所以我覺得以后會是這樣：Exchange這樣的同質化服務會趨向于外包；小規模的網站會采用相對通用的云服務而不專門聘請一個SA；而對于有一定規模的網站，即使他們的業務是托管在云平臺上運行的，他們也仍會需要一些了解企業業務的SA——他們了解如何從不同的角度思考，而且會在凌晨3點起來排障。他們可能會跟軟件工程師這個崗位融合，但不管職位叫什么，這些網站仍然需要這樣一批人。
51CTO：好的，十分感謝您接受我們的采訪！本次訪談到此結束。
【編輯推薦】
