本文講的是微服務，容器和運維：猜猜現在誰來擔責【編者的話】容器技術和devops為我們帶來了新的開發模式，本文為大家帶來了應對職責分離帶來的問題的寶貴經驗。
貫穿軟體生命週期共享相同的容器是
容器化devops帶來的優點之一，它簡化了開發與運維團隊之間的關係。這個共享能力與傳統裸機（bare metal）或是虛擬環境下的開發工作是如此的不同。並且，如此一來也改變了**遷移到生產環境時的最終責任人。
在傳統的開發場景中，很多it組織不能為開發和qa團隊提供與生產環境相同的基礎設施，因此他們會在精簡版本上測試，即使它們一點都不同。例如，在vmware商店，開發者也許會使用
vagrant工具
來編寫和測試**。
當開發團隊將**交付給運維，以便在生產環境中部署，然而它卻未能正常工作時，挑戰就出現了。「在我的機器上明明能工作的啊」，這句話已經成了此類場景的慣用語，但這對決解如何讓正常工作的**更快地從開發者遷移到生產環境的問題沒有任何幫助。在devops和容器的新紀元裡，開發者必須對最終產品承擔更多責任。
容器已經改變了業界動態（dynamic）。這是第一次，開發者的**和環境可以被未經變動地交付給運維。實際上，在
為雲重新設計it組織
一文中，這種敏捷構件是下一代it組織的前提。
將**和環境打包交付帶來的好處正是大家對容器技術如此狂熱的原因之一。在最佳實踐中，關於這個現象的屬於是「非易變**」，意為一旦應用離開開發團隊，就不會再實施**變更。如果為了修復乙個問題或者改變一項配置，需要改動**，你就需要建立乙個新的**發布上游部門，然後將之推向下游部門使用。
這是乙個強有力的正規化。運維僅專注於將交付的容器部署到生產執行環境，而不是為了能夠正確部署而改動應用。許多人褒獎容器，因為它允許運維不必再為應用的正確部署擔負責任，使得他們可以確保容器執行環境的穩定。
但這並不像聽起來的一樣簡單。事實上，將下一代應用作為容器部署是具有挑戰性的。應用自身的動態性，不斷遷移的執行拓撲，以及難以避免的基礎設施故障，都意味著提供可靠的容器執行環境並不只是一項小的功績。此外，消除應用執行的運維責任也引起了其他問題：總得有人為確保應用正確部署負責。如果運維不扮演這個角色，那麼誰來「接鍋」？
在devops和微服務的時代，理想的應用部門為其**提供支援，在問題發生時解決問題，並發行新的構件來修復它們。然而，將責任劃歸建立容器的應用運維團隊並不是解決應用問題的萬靈藥，微服務應用場景下尤是如此。
還記得在忍者刀的廣告裡，敘述者會說，「
等等，還有更多（內容）
」，然後陳述購買刀的其它好處嗎？微服務應用的運維亦是如此。相比於將問題提交給問題容器的負責部門，基於容器的應用運維擁有更多的好處，因為很多微服務組建需要依靠其他服務才能正確執行。例如，有乙個微服務用來計算貨運費，它可能需要依賴其他微服務來獲取貨物（會被分發）的履行中心到客戶所處位置的距離。
誰來為應用的啟動、可用性以及正確響應負責？如果你認為應該有其他的應用團隊，那麼你離答案就比較接近了。
如果乙個問題在某個應用團隊裡被開發者發現，那麼在識別問題的起因，並發現責任實際上在別的團隊後，這個問題就需要被提交到那個團隊來修復。
這就是微服務能夠對你如何運維應用產生一系列改變的原因。運維責任的分布引起了一些重要的挑戰：應用問題如何被跟蹤、修復和鎖定（fixed）。
絕大多數it組織需要著力於如何為應用問題「遺留」轉移責任，或者向上交予開發團隊。這個運維模式的基礎是能夠加速**變更落實到生產環境的自動化devops的能力。它需要使用非易變構件，並且它也要求應用團隊能夠使用和生產環境類似的環境。
大多數基於微服務的應用元件都會呼叫其它服務，這就意味著開發團隊必須持有應用在生產中會使用的服務的可用版本。那些服務可能並不需要是可擴充套件的或是全功能的，只要具有開發團隊所需的最小功能即可。
此外，為了提供軟體問題和跨組織邊界的關聯問題的根源分析，良好的監控和日誌功能也是必不可少的。如果乙個問題關聯到乙個應用部門，那麼該部門必須有能力來定位服務**現問題的位置。如果引起問題的原因位於另乙個服務中，那麼第乙個部門應該能夠為第二個部門提供資料，以使得他們能夠追蹤其服務內的問題，並建立補丁來修復問題。
開發者必須承擔更多的運維責任已是板上釘釘，我們亦可斷言，容器會為開發和運維提供清晰的分界點，並使得後者能夠集中精力於提供優秀的容器執行環境，有種過度簡化的意味。
相對於傳統的方式，將**部署到生產環境而言，轉向非易變**和共享構件是一次巨大的進步，但這並不能掩蓋乙個事實：總得有人承擔應用運維的責任。這就如同容器並不能避免應用問題一樣。它僅僅意味著責任可以被劃分給那些標記著最適合解決問題的團隊。是的，開發者會承擔更多責任。但是有如此多的責任需要處理。
唯一合理的解決方案是，向前看，分而治之——每個團隊必須承擔的應用生命週期的部分職責。但是，並不像「丟到牆外，讓他們解決」的舊應用世界，這種處理事情的新方式也需要跨團隊協作。最後，我們將會看到運維職責變得像航空母艦甲板上的船員一樣——每個小組有自己所承擔的職責，
但所有的團隊為同乙個目標而協作。
原文發布時間為：
2016-06-21 孫科
微服務，容器和運維：猜猜現在誰來擔責
微服務實踐 服務運維
監控的基本目標是掌控在生成環境中的服務執行狀況，在系統發生故障後及時報警，並能夠通過監控資訊快速定位問題。監控的另乙個目標是故障預警，在故障發生之前根據設定的規則提前感知並通知維護人員，或者自動做出運維決策。監控所涉及的指標 微服務的監控策略 對於微服務架構的系統，其監控通常由四大模組組成 資料收集...
docker 運維 mysql伺服器容器
root bluesky docker file pwd root docker file root bluesky docker file mkdir p mysql conf mysql配置檔案，放置my.cnf root bluesky docker file mkdir p mysql da...
微服務架構轉型需要關注的運維監控的技術和建議
系統架構的公升級，需要引入服務註冊 如consul，入門見 服務間的互動方式也需要與之進行適配 運維平台的公升級，建議引入日誌收集 如fluentd，入門見 分布式跟蹤 如zipkin，入門見 和儀錶盤 如vizceral grafana 等 運維效率和自動化水平的提公升也迫在眉睫，否則無法應對例項...