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