知識
互聯網時代，知識是一個特別簡單的問題。互聯網就是一個非常有效的知識存儲系統，對很多問題而言，“我來為你 Google-下"都是高效且往往也是高產的回答。關于操作Web基礎結構的幾乎你想知道(或不想知道)的任何事情，你猜對了，都在Web上。
把自己限制在Web上查找信息，喔喔，那就局限了。在這個過程中，盡管感覺不同，可你并非獨自一人。你有同伴，如同你需要他們一樣，他們也同樣需要你。用戶組(各種各樣)遍及全球，這可是分享知識的絕佳場所。
要是你正讀到這里的話，你肯定早已經知道書本對于獲取知識的價值了，所有資深的Web運維工程師的一個共同點是都擁有一個相當規模的書架。試著在你的組織內部成立一個圖書俱樂部，如果你的組織太小，那就在本地用戶組里問問，看有沒有同道者。
互聯網行業的一個獨特之處就是幾乎所有東西都是公開的，事實上，有專有權的東西也是極少的，而更為獨特的是，幾乎所有規范文本都是免費的。互聯網是怎么工作的?交換這里有IE的規范說明交換的原理；IP:這里有RFC791；TCP:RFC793；HTTP:RFC2616。你可以讀讀這些規范文本，從而對互聯網的工作原理有一個透徹的理解。這些協議規定了網絡服務的規則，你對這些協議的理解越深，你的決策就會越有水平。但不能就此止步!TCP可能是在RFC793中描述的，但TCP的各種細節、擴展以及后來的“發展”都是在RFC1323、2001、2018、2581等文本中描述的，所以，還需要進一步深入研究。或許研究一下TCP是從哪里來的，也是值得的:請看RFC761。
讓我們再來看看理論與實踐的難解之謎。TCP的RFC就是理論，每個操作系統中實現TCP棧的代碼就是實踐。理論與實踐的輝煌撞擊(glorious collision)就是不同TCP實現之間互操作性(或互不操作性)的微妙之處，而由此產生的爆炸就是慢速的下載，掛起的會話，以及沮喪的用戶。
在你走在從學徒到師傅的路途中，盡可能多地占有信息是你的職責，這樣你的大腦才能將那些細微之處進行排序、過濾、關聯，使其成為一幅簡明、精確的圖畫，從而有助于你的決策一一不管是長期的架構設計的關鍵決策，還是臨時的排除故障的決策。
工具
工具，在我的經驗里，是計算史上持續時間最長、言辭最激烈的爭論之 對Emacs、Subversion對Git、Java對PHP一從不同陣營的爭論開始，迅速地演化為愚蠢的門派之戰。
簡單的事實是，雖然這些工具各有優缺點，然而人們使用這些工具卻都取得了成功。為什么人們要使用所有這些不同的工具呢?為什么我們還要制造更多的工具呢?當ThomasCarlyle和 Benjamin Franklin說“人類是使用工具的動物”和“人類是制造工具的動物”時，我認為他們道出了人類本性中某種重要的東西。因為制造與使用工具是我們的本性那為什么我們還要進行無謂的爭論呢?雖然 Thoreau/在某些問問題上很尖刻，但他的評論“人類已經成為他們的工具了”，我覺得在現代語境下，也是同樣準確的。
這個簡單的事實，在Emerson那里得到了最好的表達:“所有的工具和機器歸根到底都只是人類肢體和感覺器官的延長。”這很好地道出了那個古老的格言:師傅不是用工具煉成的。在互聯網應用的環境中，你會看得更清楚，五花八門的語言、平臺、技術都能夠成功地組合在一起，將這些成功地構建為一個架構的，不是Java或PHP，而是設計與實現它的工程師一一那些師傅們。
工程上的一個真理是，不管在用的工具是什么，要了解你的工具，這是在這個行業登堂入室的前提。你的工具必須成為你的肢體和感覺器官的延長。對于工程師和非工程師都同樣深入了解，不要僅僅為了一張證書。你必須了解工具的效果，以及與環境的交互能力 清楚的是，事情發生時，再抱著本工具說明書來看，則無異于遠水救近火。對你的工具要句話，必須要實用。
運維工程師的工具箱中的一個強有力的工具，就是系統調用跟蹤器(system call tracer)，系統不同，這個工具也可能稍有差別。Solaris的是truss，Linux的是strace，FREEBSD的是
ktrace，而Mac OS X本來是ktrace，可后來換成了用處不大的 truss系統調用跟蹤器就是一個窺視孔，透過這個孔，你可以看到操作系統在用戶空間和內核空間的交互作用，換句話說，如果不是計算密集的操作，這個工具能夠告訴你應用程序正在請求什么，滿足這個請求花了多長時間。
在Solaris、Opensolaris、 FREEBSD、Mac OS X，以及其他一些平臺中，Dtrace具占有獨特的地位。但Dtrace卻應該在這里提一下。Dtrace在系統可觀測性(system observability)方面是一個巨大的飛躍，有經驗的工程師通過這個工具，可以獲得對系統更為深人的理解，這在以前是不可能做到的。然而， Dtrace就像神諭一樣玄妙深奧，一方面是其深邃的洞察力，另一方面就是答案的質量取決于問題的質量。從另一方面來說，系統調用追蹤器的預言就像雪崩一樣洶涌而來很容易引你上鉤，但要在大量的輸出信息中找到所需要的東西，卻是一個真正的挑戰。
我們怎么談論起雪崩和神渝來了?支撐Web的架構沒有固定的形態，一般也都是異質的環境，從這點來看，這倒是一個恰當當的比喻。使用 strace探測你的Web服務器正在做什么肯定非常令人興查(而且不用花太多時間，一般也都能做些優化)。但發生問題時，除非是非常有經驗的工程師，你要是第一次查看那些輸出，則對你基本上沒有價值，事實上，卻反而浪費你大量的時間與精力。問題在于，這是一件需要經驗才能對付的事情，而你只是個新手。在發生“問題”時，從這樣的工具中查看輸出，試圖找出不尋常的模式，是符合邏輯的。很清楚，你如果在正常操作模式下都不能使用探測工具的話，則比較的基礎也就不存在了。從而所有輸出模式都是不尋常的。那些看起來與題有關的模式，其實并不是，這種情況經常碰到，導致在這上面浪費了大量時間。
傳播關于工具的爭論往往是重要的，這樣你就能夠針對工具對問題的適用性進行選擇，而不會僅限于自己的個人喜好。 FREEBSD項目是一個極好的例子，它的發布管理絕對是一流的，使用的工具卻是被大多數人認為完全過時的版本控制系統(CVS)。許多成功的架構是建立在PHP語言之上的，而PHP卻缺乏很多現代語言都具有的一些特性。而從另一方面來看，很多項目，雖然裝備了最強有力的工具，仍然失敗了。靈巧地運用工具的能力，比工具本身的質量要重要得多。話雖如此，有經驗的工程師還是應該手邊備一件合適的高質量工具的。
經驗
任何情況下，經驗都是最有力的武器之一。經驗意味著太多的東西，所以特別重要。從最本質的意義上來說，經驗意味著良好的判斷力，而良好的判斷力卻是從很多失敗中取得的。從理論與實踐的沖突中，我們可以看出殘酷與美麗。沖突無疑有犧牲一一數據丟失、服務中斷、激怒用戶，以及金錢損失一一但同時，沖突的完整情景和病理卻有著深邃的美:職責受到了挑戰(你可能因此而丟掉飯碗)，非預期的結果也得以彩顯，而比這些更重要的，這是你成為病理學家(pathologist)千載難逢的機會，而且對于理論與實踐在哪里分道揚鑣會有更加深入的理解。
經驗與知識是緊密相關的，知識可以認為是他人經驗的總結。你有了這些知識，并不就能把握知識背后的深刻意蘊，這是需要直接經驗才能獲得的。經由經驗磨礪的洞察力(這種洞察力在僅有知識的情況下是不會有的)具有洞幽燭微的能力，才能夠探出問題所在，而知識背后的深刻意蘊則能夠讓你靈活應用學得的教訓，解決這里的問題。
經驗既是一個名詞，也是一個動詞:獲得經驗，與應用經驗，同樣容易(也同樣困難)。
無經驗者的機構化挑戰
盡管獲得經驗就像簡單的“做事”一樣容易，但在Web運維中，就是一個制造糟糕判斷并從中脫險的過程。然而，問題在于:身處這樣一個激烈競爭的行業，有哪一個機構愿意讓
自己的員工制造糟糕判斷呢?回答這樣的問題并執行這樣的計劃，對于想擁有職業Web運維工程師的任何一家公司，都是基本的要求。這個問題的答案分為兩部分:一陰，一陽。
首先，為了讓初級和中級工程師制造糟糕判斷，必須保證安全。這通過將每次糟糕判斷的責任和造成的損失控制在一定的限度內來實現，環境(工作區、網絡、系統、代碼)要能夠完整地從偶爾的糟糕判斷中脫險。你肯定不希望被通到這樣的份上，僅僅由于一次糟糕判斷，就將員工炒魷魚(雖然我知道這不能完全避免，但總是一個美好的目標)。失誤越大，從教訓中學到的就越深入和持久。這讓我們進入了答案的第二部分
相同的糟糕判斷水遠不要犯第二次。錯誤可以發生，糟糕的判斷事實上也總會遇到，但不能從自己的錯誤中學到數訓，是不可原諒的。雖然意外總是存在的，你應該期待并倡導這樣一種文化:對重復糟糕判斷的零容忍。
“資深運維”的概念
一直困擾著我的一個問題，是初級運維工程師申請資深職位。他們的想法是知識決定了一個人在團隊中的地位，正像其他領域一樣，這是絕對錯誤的。一名資深工程師最大的特點是其致與可靠的良好判斷力，很顯然，這要在需要做出判斷的場合經受鍛煉，而且有一個簡單的數學算法需要做出判斷的場合的困難程度乘以任職期限。在一個經常發生災難性性事故的運維團隊中空降，是可以在“快車道”上迅速成長的。在一個位置上待10年，從來沒有做出過挑戰性的決策也是可能的，其結果就是，沒有積累起任何有價值的經驗。
X一代(甚至Y一代)奉行即時滿足的文化。我與一大批的工程師共同工作過，他們期望他們的“職業路徑”在5年之內能夠達到最高位置，只是因為他們非常聰明。我認為對這么一大批人來說是不可能的，不是每個人都能夠做到資深工程師。就算5年之后，你做到了資深工程師，難道這就是你的頂峰了嗎?再一個5年之后，你就不累積寶貴的經驗了嗎?到時候應該是什么呢?“超級工程師(super engineer)”?5年之后又是什么呢?“無敵工程師(super- duper engineer)”?我認為我們這個行業的年輕人不值得為此煩惱，真實情況是，極少有工程師會在Web運維領域干上15年。我們這個行業的變化性很強，很多人被選拔到了管理崗位，或作為企業家冒險運維自己的事情去了。
對進入這個領域而沒有什么經驗的工程師，我的忠告是:耐心。然而，這句箴言明顯自相矛盾，在你能夠領悟其真意之前，你的耐心恐怕早就跑光了。
紀律
紀律，在我看來，是我們這個行業中最大的災難。Web運維，從其進人結構規劃、過程設設計、人員訓練之后，業績就非常槽糕。作為我工作的一部分，我做了很多評估，走訪了很
多公司，對他們的組織結構、運維實踐、整體架構進行復審，以便能夠識別出一但業務規模上來之后，什么時候以及哪里會出問題。
猜猜我經常看到什么?我看到的是懶懶的牛仔和持槍歹徒，這是狂野西部(Wild，WildWest)啊。情經常被吹噓為程序員的必需品質，在Perl社區(這一點已經成為其符咒的一部分)，其意義并非真如字面所示(在符咒中已經進一步簡化為野做)，而是通過盡可能正確面高效地做事，從而為解決同樣同題，面盡可能地少做工作一這其實離橫情已經很遠了。不幸的是，程序設計和運維領域的其他人卻將真正的懶惰作為一種我稱之為“我的地盤你休想”的做慢。
紀律就是可控制的行為，來自于培訓、學習和實踐。以我的經驗，紀行律應該是Web運維團隊最普通的要素，缺乏紀律的結果就是不協調、效率低下。
紀律不是通過書本可以教的東西，必須通過實踐養成。你接手的每個任務都要用長遠的眼光來對待。對你的崗位和職責要長期經營，處理問題的解決方案要5年之后還能夠滿意，這些是實踐的良好基礎，紀律從此實踐中即可養成。
軟件工程(一個密切相關的領域)在紀律上卻有不錯的成績，我覺得這挺有諷刺意味的。我猜Web運維領域缺乏紀律性的根本原因是缺乏職業路徑，這看起來好像是一個雞與蛋的問題，我X對這個行業很快就會有一個明確的職業路徑還是充滿信心的。
參與職業的網站建設規劃設計，對于在這個行業工作的工程師來說，肯定是是非常重要的。Web已經在那兒了，架構在Web上的服務正在變得越來越關鍵，Web運維“職業”是不可缺少的。通過參與，你就更能夠確信，當初吸引你進來的這種工作的特質，將持續你的整個職業生涯。
本文地址：http://knowyourextract.com//article/3303.html
