Edit安全
本篇和下篇文章均爲InfoQ專訪內容。
性能優化
InfoQ：您從事運維行業已經8年了，根據您的我的經驗和理解，一個全面的運維繫統須要完成哪些工做呢？服務器
趙成：這是個比較大，可是很是好的一個問題。這個問題大，是由於它能夠轉譯爲運維的範疇問題，簡單說就要討論運維究竟是作什麼的。微信
若是這問題沒有思考和解釋清楚的話，那麼對於一個非運維同窗，從外行的視角看，每每會簡單粗暴地認爲，運維就是搬機器拉網線的，高級一點的會熟練地編寫Shell、Python和Perl腳本。而若是一個運維同窗對這個問題理解不清楚，那麼短時間內將會影響他在工做中的定位，長期會影響他的職業道路的發展和選擇。架構
因此，我想仍是要花些篇幅把這對這塊的理解講清楚。運維
關於運維的範疇，個人理解總結下來應該包括五個維度：效率、穩定、安全、體驗和成本。其中效率和穩定多是運維同窗最本職最應該優先作好的事情；安全、體驗和成本是運維同窗在基礎作好的前提下，可以更進一步的方向。下面詳細說明一下：
(1).效率
這裏重點指的是平常運維例行工做的效率，由於這些工做是運維最基礎的工做：資源分配&回收、域名配置、VIP配置、持續集成&發佈、應用部署、應用擴容&縮容等。一般提到的運維自動化，大可能是集中在這些工做上，由於這些工做偏平常和重複。性能運維自動化的目標就是解放運維的生產力，提高運維效率，下降人爲失誤，把運維的能力沉澱到運維的技術平臺上，讓周邊的人和系統依賴的是運維的能力，而不是運維的人，同時運維的同窗能夠有更多的精力去作更有價值的事情。目前業界自動化的解決方案很是豐富，也造成了必定的方法論和套路，因此建議多借鑑業界經驗，優先把這些問題解決掉。優化
(2).穩定（質量）
能夠經過監控、全鏈路、強弱依賴、限流降級、容量評估、預案平臺等措施，讓業務運行更加穩定。作好這一點，須要有相對比較獨立、專業的監控和穩定性平臺來支持。spa這部分目標是最大程度地保障系統的穩定性和運行質量。即便出現問題，也可以快速發現、快速響應、快速（自動）恢復。.net
(3).安全
安全，是橫向與運維同等甚至更加劇要的專業領域。但同時又是跟運維緊密相關的，運維一樣要關注安全，由於安全出現致使的問題，每每也會給運維帶來沉重的防禦和修復成本。咱們常常提到的安全類關鍵詞，各種主機安全、DB安全、Web安全、應用安全等等，與此相關的還有漏洞、DDos、CC等。(4).體驗
這裏提到的體驗，指的是終端用戶的訪問體驗。對於非功能或非產品的使用體驗，運維最須要關注的是訪問速度。開發團隊的同窗，可能更多的注意力會放在本身負責的代碼以及該部分的性能問題，不會關注到端到端全流程的性能和體驗。而運維能夠站在全局的角度來審視和治理整個端到端的全鏈路性能狀況，並給出對應的性能優化建議。(5).成本
成本問題，也就是技術ROI（投入產出比）的問題。當系統規模和體量變大以後，掌控在運維手中的各種資源，將佔整個研發團隊支出的大頭。若是沒有很好的成本控制意識和策略，資源體量將會持續增大，甚至是翻倍或指數級的增加，對於公司成本會是很是大的負擔和壓力。運維工做者須要考慮到服務器CPU資源利用率的提高（引伸出來各類虛擬化、容器或雲資源的使用）、IDC&CDN流量帶寬使用的管控，還有人力的投入和成本的管控。如何使得系統可以更高效地被充分利用起來，如何可以最大限度的減小成本支出，是咱們必需要去考慮的問題。
問題小結：
以上即是我理解的運維，能夠看到這個運維範疇其實能夠是很大的；或者這樣來講，只要最終是跟線上業務運行相關的工做，都是運維要關注的。若是運維僅僅是片面和狹隘地給本身限定一個範圍，沒法作到提早統籌和規劃，便很容易變成被動響應的角色。提到的幾個維度，在一個公司裏，包括蘑菇街，都會有不一樣的專業團隊來承擔，好比咱們就有安全團隊、穩定性團隊等等。可是在平常工做中，運維團隊跟這些團隊是不分彼此的， 由於每一項工做或項目最終要以線上實際現狀爲導向，而運維是最清楚和了解這些細節的，同時最終產品或功能都要經過運維來落地和運營。
因此，以上的幾個維度不是孤立存在的，而是相互影響和互爲依賴的。好比若是實現了效率高、穩定性好、體驗優越、安全等級高；那麼必然地，系統更加容易管控，成本（硬件、帶寬和人力）會降低。再好比，穩定性相關的工做好比全鏈路、容量評估作的好，提高體驗的工做開展起來也更加方便。因此，運維是貫穿整個軟件生命週期的持續性工做，對待運維工做也必需要有更全局的視角。
此外，當業務體量增加到必定程度時，運維體系和運維效率若是不能匹配地支撐，必定會阻礙業務發展。所以，在技術團隊中必定要 對運維有一個正確的理解和定位。
InfoQ：這幾類工做是否均可以實現運維自動化？
趙成：這是必定能夠的。我想不只僅是要實現運維自動化，做爲技術人，咱們目標就是將全部的人工操做實現自動化。自動化是咱們的方向、思路和技術實現的方式。
InfoQ：一個傳統系統，若是想實現運維自動化，您建議應該從哪裏先開始呢？
趙成：我建議兩個方面上入手：
1) 必定要標準先行，作到技術的標準化。這包括資源標準化、OS的基礎配置標準化、基礎軟件（如Tomcat、JVM）配置標準化、應用配置標準化、流程規範標準化等等。作到了標準化，消除了各類差別，才能爲後續的自動化開發鋪平道路。舉個例子，下圖是咱們Java應用部署和目錄配置標準，全站幾百個Java應用都遵循這套標準，咱們的持續集成、發佈及部署，只須要基於這個標準開發一套便可。反之，若是每一個應用的套路各不相同，那開發和適配的工做量可想而知；當系統擴大到了必定體量以後，就再也不是單純的自動化能解決的問題了。
目錄配置標準：
這裏談談Docker，Docker的一個核心目標就是-Develop,Ship And Run Any Application, Anywhere.爲了達到這個目標，Docker提供了一系列的標準技術套件，來保證各類環境的一致性。因此從根本上講，Docker解決的是應用標準化問題，跟上述咱們所說的思路不謀而合，殊途同歸，可是Docker的抽象層面更高。簡單說明一下：
a、熟悉Docker的同窗都知道，下圖是Docker容器的High Level架構圖，其中的Docker Engine的做用就是屏蔽和隔離應用與基礎設施的耦合，從而讓應用能夠Develop,Ship And Run Anyweher.這裏Docker作到了基礎設施向上層提供的服務的標準統一。
b、再進一步，Docker Engine提供了標準的REST API 和CLI，來與Docker中的Container、Image、Network和Data vlolumes這些對象來交互，從而將Docker的使用方式進行了標準化。
c、跟應用配置關係最緊密的Dockerfile，若是要構建一個Image鏡像，這個是最關鍵的配置，裏面定義了標準的語法命令格式和語法規則，從而保證了無論是何種的應用，最終均可以經過Dockerfile的配置模式，從而實現應用構建的標準化。
d、其它相似Docker Registry等也是相似的思路，這裏就不展開講了。
總結下來，能夠看到爲了作到標準統一，作到發佈和部署效率的提高，從而能夠催生出Docker這樣火熱的技術，說明作標準是多麼的重要。
蘑菇街爲整個運維體系的標準化（以下圖）下了很大的功夫，實現自動化運維以前，必定是標準先行，而且要標準化一切！
2) 接下來在技術和建設上，我想按照順序來一個漸進的過程應該是：CMDB、應用配置管理和持續集成&發佈。
a、CMDB：這運維自動化的基石，重要性不言而喻。有特別要說明的一點，不然外界容易對CMDB產生錯誤的認識：CMDB不只僅是硬件和資源的信息記錄，更重要是要創建起應用與資源之間對應關係。創建了這個關聯關係，以此爲基礎，配套着應用配置管理、監控、發佈、穩定性等系統的建設，才能最終造成體系化的運維平臺，這樣的平臺纔有力量和生命力，不然只是碎片化的運維模式。
應用配置管理（上圖中的應用服務）：
前面提到的標準化部分，涉及到基礎環境、基礎軟件和應用配置的信息；這些大量的信息在後續的自動化過程當中會被使用到，須要藉助應用配置管理平臺更好更便捷地管理起來。
這裏須要提示一點：讓CMDB只提供最基礎的資源信息和應用-資源的關聯關係，不指望把基礎的CMDB作得太重。起初蘑菇街把這些信息放到了CMDB的系統中，可是實現起來後發現CMDB變成了一個大雜燴，所以後來把這些信息剝離出來放到了應用配置管理中。
c、持續集成和發佈：從咱們自身發展的過程看，在Java應用服務化以後，應用的數量會大大增長，同時單個應用迭代週期和速度也會更快，這正是服務化的優點。
不過也帶來了挑戰，即對發佈效率和發佈中服務穩定性產生了更高要求。若是這個環節跟不上，會直接影響業務上線甚至是公司商業策略上的執行。
所以，CMDB和應用配置管理兩個基礎工做作好以後，必定要優先將這一部分作起來。經過發佈系統的開發，咱們的DevOps的理念和協做方式也就是這樣開展起來的。
原文連接：http://www.infoq.com/cn/news/2016/09/DevOps-automation-operation-2
本文分享自微信公衆號 - 成哥的世界（forrest_thinking）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。