友情提示，本文為軟文，如有不妥請關閉。

很多人對我以前做過的事情很好奇，雖然我對他們有所了解，而且我似乎也對他們有所了解。所以，這段歷史說來話長，明天我只講一部分，我的一些淵源與系統運維有關。

讓我們從上個世紀開始。1996年還是1997年，我不記得了。還在讀書的時候，在北大校園網找到了一本大陸黑客的教科書。后來在微博上看到他了！）趙茂華虎利用CGI信息泄露漏洞獲取了北大估測中心一臺服務器的文件。之后，我使用破解程序嘗試解鎖了很多密碼，包括管理員帳戶。，但成功完成了登錄操作。其實我什么都不敢做，但我想說點什么，即便如此，文件是什么，系統的文件目錄是什么意思，管理員賬號的權限是什么服務器運維外包，還有什么是這個cgi漏洞的觸發機制？這是完全未知的。

簡單來說，就是一個無知的新手，按照劇本做了一個根本看不懂的操作。但我覺得這是我第一次接觸并嘗試了解所謂的服務器系統。

1998 年，我的第一份工作是做一些 Web 開發。期間，我把公司的人才網站系統從+asp+改成了linux+php+mysql。我大概是第一個在國外開發php的程序員，這段時間我還在國外用。網絡嗅探總監的root密碼登錄公司服務器，然后發給總監炫耀。之后對方沒有限制我的root權限。但此時，我的理解比以前更加有限?；局纖eb服務、數據庫服務、動態腳本的協作方式。我也知道所謂的系統賬戶權限、目錄權限、文檔、文檔是什么。除此之外，它仍然是空白的。

我第一次創業是在1999年，當時和華圖網合作，就是謝文老師給的資源。我可以自己寫一些程序。美術設計被網友外包，放在華圖網服務器上。我不關心請求的數量，也不關心運維。后來換了廣告交易所，突然就爆發了。請求猛增，各種服務器都支撐不住了。謝文老師也離開了華圖。，我向綠盟科技的沉老師借了28000，買了的主機。那時候服務器運維外包，托管真的很貴。之后請華圖網兼職運維人員協助維護服務器。

后來，雖然我是別人家的工程師，但有問題總不方便打擾。每次著急的時候，不知道要等多久才能等到對方回復，于是就開始就各種問題征求意見，讓對方帶一些資料過來解決我自己。我自己解決了。后來逐漸學會了安裝各種系統，優化調整參數。起初，我不知道如何使用搜索引擎。后來，在我學習了搜索引擎之后，我知道了更多的東西。之后，我也開始展示一臺服務器如何支持每晚幾千萬的動態腳本請求（十五年前的廉價服務器在當時被認為是非常好的），以及一年不宕機的穩定性如何。

2004年底統計完畢，面臨新的挑戰。與之前相比，系統更復雜，響應請求的頻率更高，但程序與服務層的結合更緊密，包括緩存管理，包括定時任務，包括守衛。過程中也有比較奇特的故障。此時，僅靠系統參數優化是無法解決問題的。你必須自己編寫更多的應用層監控腳本，試圖在問題發生之前記錄錯誤信息和系統狀態。, 重播故障和問題點。但是，當時每個統計服務器都是獨立支持業務的。雖然有很多服務器，但似乎沒有集群，

幾年后，我沒有太多的運維經驗。直到2009年進入4399，才開始搭建社區平臺。那個時候上海公司剛剛起步，招聘的本地運維人員之前并沒有處理并發的概念，我們也不是那個有錢的。暴發戶，只能回到技術優化的老路了。隨著流量的增加和服務器的擴展，由于業務數據必須保持統一一致，開始了解集群、中間件、負載均衡、讀寫分離、分庫等。對于各種架構問題，我們還在不斷的探索和前行，不斷的踩坑不斷的教雜費，然后編寫各種監控分析腳本，尋求問題回放和定位。我在之前的文章中也談到了一些經驗。

例如，整個系列的文章都可以在這里看到。

直到后來，我也開始幫助很多同學分析解決負載優化的問題。我也開始以建筑師的名義參加一些建筑會議，并做了一些分享?？梢哉f，就算技術不好，最后還是處理了。很多中小型公司的通病，可以算得上是跌跌撞撞的平價架構師。

像這樣的話，我想說一件事，還好，時代在不斷進步。一是硬件的改進，解決了很多以前單機的麻煩問題；那么云服務的誕生，每一個優秀的云服務商背后，都有一幫優秀的云服務商。運維工程師和架構師通常不被大中型公司聘用。優化了哪些參數，安全優化，集成了各種解決方案和服務，資源可以自由擴展。許多令人頭疼和復雜的事情現在都一點點了。鍵盤完成了。說真的，這對中小型公司來說確實是個好消息。我經歷和見證了太多的中小型創業公司。在業務快速發展的情況下，我有太多不可持續的運維頭暈的案例。其次，我琢磨了一些昨天晚上看起來微不足道的非常小的技術細節，花了很長時間才解決。

我們還是講技術的價值，我們自己去理解和感知核心技術，掌握技術細節，雖然很有價值；而技術的分支和領域數不勝數，誰能包羅萬象？誰能填滿科技的技能樹？在這些實際情況下，只有正確的技術工具和技術方案才能正確選擇，大大簡化并增加了技術成本。它本身也是一項技術，具有極高的價值。對于企業來說，這個價值或許可以讓你節省大量的研發預算，大大提高運營效率。

回過頭來看，我們用過云主機和云服務，能不能高枕無憂，專心開發？對不起，不是。

很多時候，我們遇到的系統問題來自于我們自己的應用，比如顯存泄露，比如數據庫鏈接沒有被釋放等等；這時候就需要進行更加深入和多樣化的跟蹤分析，進而定位困境點或者故障點，這就要求在云服務的基礎上，還需要做各種跟蹤和分析。分析，也就是我之前經常做的，寫監控腳本，保存各種對分析有用的信息，然后在遇到故障和問題后繼續分析日志，定位和調整我們的問題。

不過，時代還在發展，好在這樣的工作也有了很大的改進，這就是APM技術，（應用性能管理）。我們可以采取預防措施來找出問題，而不是等待故障來反思問題。我們可以有更多的時間和計劃來解決問題，而不是在出現問題后通宵達旦地緊急處理，祈禱休養時不要變壞。

如果你不知道這一點，我想你可能不得不走我走過的路。老實說，我真的不想重蹈覆轍。那天晚上服務器崩潰被客服電話吵醒的時候，我已經經歷了太多。

去年8月18日，中國首屆應用性能管理大會將在上海召開。組織者是我們熟悉的老同學。他們曾成功主辦過QCon全球軟件開發大會、 和InfoQ China的全球架構師大會。還有聽云科技，APM技術領域唯一的上市公司。

整個會議設置包括性能可視化、服務器端應用監控實踐、人工運維、CDN加速、數據庫性能優化、移動端性能優化、基于云架構的性能優化、HTML5調優最佳實踐8個主題。

代表講師包括但不限于以下

相關議程是各大一線互聯網公司的實際解決方案。任何解決方案，只要適合你的企業應用場景，都可以說是有價值的。

讓代碼“”介入閱讀原文買票，然后就可以在20%off的基礎上轉移利潤。