監控系統、日誌系統、配置管理系統以及部署系統
　　以前公司在監控、日誌分析、應用配置和部署的工作方面都是徒手操作，若將徒手變為自動化，對於上流的網際網路公司都急切需要這些自動化管理系統。無數生產的問題以及生產效率的問題都是因為監控、日誌、配置以及部署所造成的。做這些自動化管理的系統需要投入大量人力和物力，而且還要專心致志做相關研究才能將這些系統做完做好。
    思考下這些系統的做法以及會使用到的相關技術：
　　監控系統

    監控系統很好理解，它的作用是監控線上系統的執行狀況，如果線上系統發生問題，那麼監控系統會將問題及時的通知到每一個相關的人員。小公司這樣的工作是一個半自動化的狀態，很多工作還是需要大量人力的投入才能完成，但大公司的監控系統已經實現了監控自動化，雖然大公司的系統比小公司的多的多，但是他們監控的人力的成本卻是少之又少。大型網際網路公司的系統往往是成百上千，伺服器則是成千上萬，因此自動化的監控絕對不是看不到產出的而一定是可以實實在在創造價值的。

    對如此龐大的資源進行監控，需要考慮很多，首先要定義一些監控的維度，一般最大是系統級別，其次是系統下的功能模組，再細點就是方法層面的，在實際的開發中，一般會從功能模組和方法上控制，這些控制好了，系統級別的監控也就相應的做到了。一般這種監控肯定也是會使用到打點的技術，也就是在程式合適的地方引入監控程式，當系統執行出現異常的時候，監控程式會及時的將資訊傳遞到監控的伺服器，伺服器將這些問題記錄下來後通過簡訊，郵件的方式通知給相關人員。方法級別的監控比較好做，只要監控程式捕獲到了程式執行的異常就行，而功能模組的監控則是需要相關人員定義一套捕獲規則，當功能模組觸發到不符合規則的地方，監控系統就會給相關人員發出警報，監控的實時性可以達到秒級，效率是非常高的。監控系統做的要人性化，所有的操作都可以在一個Web的管理系統裡完成，這個管理系統也是用了大量的視覺化圖表的方式，直觀且易於操作，同時還有相關的績效管理功能，實在是非常的強大。
    日誌系統

    通過日誌查詢線上系統的問題，這是解決生產問題的唯一方式，但是對於檢視網際網路系統的日誌是一件非常痛苦的事情，因為網際網路的系統幾乎沒有單點，都是分散式的，所以檢視日誌的時候就需要查詢很多臺伺服器，如果碰到程式本身的日誌寫的不太合理，那麼查問題幾乎是一件大海撈針的事情，此外，在公司裡，生產環境往往都是被嚴格的管理起來的，只有很少數的人可以直接檢視生產日誌，一般人員想看生產日誌常常會有一大堆冗長的審批過程，這些審批過程保證了生產系統的穩定性和安全性，但是惡果就是嚴重拉長了問題解決的時間，那麼如果有一套實現辦公自動化的日誌系統那就是非常棒的一件事情了，大公司就自己研發了一些這樣的日誌系統，它的日誌系統定義了一套日誌的規範，應用系統的開發人員可以按這個規範打出日誌，該系統除了能打出符合日誌規範的日誌，還能將應用系統自身的日誌拉到日誌系統裡，這些日誌的檢視不再是通過命令列在控制檯裡看，而是由專門的Web系統來進行檢視，他們的Web系統做的挺棒的，可以分組分類的檢視相關係統的日誌，這些日誌在規定的時間裡會自動重新整理，同時使用者也可以在Web系統裡像控制檯那樣實時的檢視相關的日誌，只有有相關檢視日誌許可權的人，隨時隨地不受限制的檢視到系統的執行情況。日誌系統的設計上某些地方和監控系統類似，也要做到非侵入式，儘量降低系統對生產系統的影響。比較特別的是，在Web系統裡看到日誌並不是儲存在生產系統上的日誌，而是存放在日誌系統裡的日誌，也就是說該日誌系統會實時的同步生產系統的日誌，這種同步不是盲目的，而是會根據一個的規則同步到日誌系統，這種規則可以保證在Web系統裡很容易定位到那個系統，那個功能模組的日誌。大量日誌儲存絕不可能用關係資料庫完成，那麼想高效的查詢到日誌就得使用搜索技術，使用solr進行搜尋的。當然保證日誌叢集的可靠性，zookeeper就得上場了，zookeeper已經是做分散式系統不可避免的技術了。
    統一配置系統

　　系統的配置一般是指將一些環境的引數，系統的引數或者是某些會經常變化的資訊用一種特殊的檔案儲存起來，這樣利於系統的維護和擴充套件，java裡通常使用xml檔案和properties檔案儲存配置資訊，而那些會經常改變的資訊通常會使用properties檔案儲存，這種配置管理方式對於規模不大或者變更很少的系統而言十分有效，但是對於網際網路公司的大型系統以及一些關聯度很高的系統而言，當系統運維到一定程度，配置檔案可能是最讓人沮喪和痛苦的事情，特別是維護它們的方式是通過人力的方法，其潛在的風險也是非常之大的。zookeeper一個重要特性就是配置管理，一些大公司實現的統一配置系統就是通過zookeeper來實現的。統一配置系統同樣也是視覺化的，使用者不用直接到生產機器上修改配置，重啟伺服器，而是直接在Web管理系統裡操作，配錯了可以修改，也可以進行回滾。

　　自動化部署系統

    生產部署是一個專案的最後一步，也是壓力最大、風險最高的一步，如果最後上線部署失敗了，這種感受就猶如進行了一次辛苦的長跑，眼看就要到達終點了，沒想被一塊大石頭絆倒了，甚至還會掉到坑裡，最後還要挨領導批，那滋味可不好受。

    小公司系統部署的問題很多，不同的環境，如：開發環境、測試環境、偽釋出環境和生產環境，開發環境和測試環境對開發人員來說可以控制，這個操作除錯都很方便，這個都比較好。但開發環境和測試環境同偽釋出環境同生產環境基本上是完全隔離的，而且不同環境之間的環境配置，系統配置等等都存在或多或少的差異。經常發生，測試環境執行好好的程式到了偽釋出環境就出現問題，更揪心的是，測試環境和偽釋出環境都沒問題，上了生產出問題了，而且是環境造成，這就使每一次部署操作都是小心翼翼的，部署後任然還要投入大量的人力和時間進行監控和測試。

    大公司的環境其實比小公司的還要複雜，它們甚至在偽釋出環境和生產環境之間還有一些模擬的環境，還可進行灰度釋出。模擬的環境是可以直接從生產上摘取一個伺服器，部署新開發的程式，讓相關人員進行測試驗證，而且部署環境的切換也是有專門的Web系統進行管理，不同環境之間可以做到平滑的過渡。這樣部署操作不僅是安全性以及在效率上都有很大的提升。

    總結
　　大公司一般有幾千名的開發人員卻只需要20幾個運維人員，因為有強大的開發團隊可以支撐內部管理系統的研發，內部管理系統的監控和運維作用，加大了應用系統的穩定和容災，這就大大減少了運維人員的工作量。
　　由此可以看到網際網路的技術遠比傳統的企業軟體複雜的多，網際網路的技術基本都是分散式的，因此執行緒、程序、通訊、分散式技術以及分散式的可靠性是十分的重要。上面描述的這四種系統，也不是大公司自創的，也是大量借鑑與美國牛叉的大型網際網路公司，例如facebook，谷歌等等。

----------------------------------------------------------------

BAT級別的公司都定製自己的監控運維工具，一般公司使用開源的就足夠了，常用的開源工具：

監控：ganglia, nagios, zabbix, zenoss...
日誌：logstash, flume, sentry...
配置管理和自動化：puppet, chef, fabric, rundeck...

持續交付：本書提到了許多提高系統開發質量的方案。

51cto有個雜誌叫 linux運維趨勢，也介紹了此方面的內容，可以參考學習
-------------------------------------------------------------------------------