容器使快速開發應用成為可能。keith townsend強調了在部署應用之前監控是運維的挑戰快速把概念從想法轉為產品的願望驅動了原生雲（cloud-native）的開發工具的採用。容器的趨勢就是一項允許快速開發的技術的例子。
使用如docker這樣的平台，在發布產品的時候，乙個開發者在產品主機上和在他們的膝上型電腦上使用相同的docker映象。那麼在管理產品應用的時候，容器和微服務的使用有什麼影響呢？組織和公司可以使用相同的工具，還是需要利用新的途徑？
微服務和容器
為了理解容器的影響，考慮微服務這個和容器伴生的概念是重要的。微服務是把應用開發分解為小的分布式的程序的方法。乙個典型的微服務的例子是web伺服器。隨著對應用的需求的增加，乙個應用可以產生一系列另外的apache web伺服器，每個都執行在各自的容器中。當對應用的需求減少，之前生成的微服務例項所消耗的資源可以被釋放。
容器的生存期是短暫的。資料和系統設定只有在每個容器的執行生命期內才存在。容器的這個短暫的生命期的屬性使他適合微服務架構。每當乙個應用需要產生乙個新的微服務的時候，應用向容器管理器傳送服務請求。
乙個應用或者應用系統可以產生幾十乃至上千的容器，他們可能只持續幾秒鐘，也可能永遠保持。
乙個受到挑戰的例子：監控
從技術角度來看，應用的監控傳統上存在於服務端。服務端團隊為監控乙個作業系統例項提供一系列預設的統計指標和告警。隨著運維年份的增加，除了對作業系統的監控，監控團隊也會為應用服務新增一些監控能力。然而這些監控目標是有狀態的。產品的虛擬機器通常是使用靜態的配置項，傳統的應用也不會產生只持續幾秒鐘的微型的虛擬機器。
這類環境的靜態屬性使服務與虛擬機器之間是一對一或多對一的對映。如果乙個虛擬機器罷工，那麼服務就罷工。服務端團隊就可以僅依靠虛擬機器的狀態來警告應用團隊服務是否可用。微服務的架構打破了這種關係。容器和虛擬機器採用不同的體檢表。
devops（開發運維模式）來拯救
容器監控是乙個對devops有現實需求的領域。然而devops是乙個被用濫了的概念。在一些場景，devops指像puppet和 chef這樣的工具。而在其他一些場景，它又是融合開發和基礎設施執行的概念。
在乙個完美的世界，應用監控應該是應用設計的一部分。雖然資料中心管理器可以繼續上報乙個容器的主機的整體健康狀況，但開發和運維團隊需要合力來實現應用層面的監控。
python運維工程師前景 運維工程師的前景怎麼樣
我覺得因該是有前途的，看個人能力和努力程度，本人現在正在往此方向發展。隨著國家大力提倡網際網路 網際網路時代會加速普及，運維大有作為。只是隨著雲計算時代的來臨，傳統運維崗位可能會大大減少，而掌握雲計算方面運維的工程師將會迎來新的天地。結合上面說的網際網路環境，加上最近幾年的經歷，讓我覺得雲計算遮天蔽...
web運維的可擴充套件性考慮 zz
b 1.優化 b 不要過度優化。這可能會從你的重要函式中拿走一些寶貴的資源。不要過早考慮擴充套件。考慮你系統當前面臨的或可能支援的 10 倍負載，在大多數情況下會影響生產效率。在無法滿足 2 個或 3 個服務前，關聯式資料庫還是不錯的選擇。為了水平擴充套件性而優化和重構前，先優化單個節點的效能。b ...
Hotmail運維 管理超大型服務的挑戰
現狀 hotmail目前擁有遍及全球的一萬多臺伺服器，每天處理數十億的電子郵件事務，儲存量數千兆兆 pb 總共聘用不到100名系統管理員進行管理工作。在增加伺服器數量的同時保持管理人員人數不變，即可管理性也是一項挑戰。資料移植需要考慮複雜的效能規劃 資料中心空間以及能源消耗問題。自行構建的管理工具包...