運維人員須要有產品觀

摘要

        運維工程師要掌握硬件、軟件、操做系統、開發等多方面的知識，核心目標是爲億萬用戶使用的產品保駕護航。運維工程師應該在紅海中尋找藍海的思惟模式，培養產品觀，由外至內地思考，突破傳統運維的壁壘，開拓創新。

 

       在不少「外人」的眼中，運維工程師的工做不過是搬機器、調網絡、裝軟件、處理故障、7×24小時值班，簡單而又枯燥至極。但事實並不是如此，運維工做涵蓋不少技術領域，運維工程師要掌握硬件、軟件、操做系統、開發等多方面的知識，核心目標是爲億萬用戶使用的產品保駕護航。

       當今互聯網行業的發展突飛猛進，新技術層出不窮。爲了適應發展趨勢，運維工程師只有提高技術能力才能更好地完成艱鉅的運維任務，必需要對傳統運維發出自我挑戰。
       在360，運維團隊由基礎運維團隊、網絡運維團隊和應用運維團隊三部分組成。咱們將運維從技術支持領域升級，進行產品化改進，核心目標是爲了下降運維成本、縮短研發週期、讓產品試錯更廉價。理想很豐滿，現實很骨感，從最初服務少許項目、幾十臺服務器，發展到大量具備數億用戶的項目，咱們也在不斷摸索，在試錯中成長。

        在這個過程當中，咱們經歷了兩次重要的升級。

 

第一次升級：運維工具化

        運維工做中有不少瑣碎的、重複的事情，初期咱們只有兩個IDC，服務器數量有限，項目數量也較少，靠純手工勞做還能夠應付。但隨着時間的推移，項目暴增，隨之IDC和服務器的數量也成倍增加，同時360各項目都是小團隊在作，開發風格不一樣、習慣各異，但極致要求響應速度，若是運維工做按照以前方式進行，很難知足需求。大勢所趨，咱們必須進行工具化升級，將重複的事情自動化。

       在工具化過程當中，咱們秉着低成本、拿來即用的原則，借鑑業界成型的方案，同時將精力用在對開源軟件的研究中，有開源工具就毫不本身憑空創造。初期，咱們只圍繞開源軟件作周邊腳本開發，不動核心代碼，在實踐中總結經驗。例如，在最基礎的部署軟件環境中，咱們基於YUM搭建了本身的包管理系統，將經常使用軟件打包，同時根據項目作成模板，這樣不管是初始安裝仍是擴容都能在分分鐘完成。配置文件管理利用Puppet完成，服務器批量操控依賴SaltStack。就這樣咱們的運維兵器譜在不斷地豐富。

      另外，運維工做離不開監控報警，這是一件讓無數運維人苦不堪言的事情。而會休息纔會工做，監控體系必須優化。

      咱們的監控大概分爲系統級、應用級、項目邏輯和用戶體驗四部分。

一、系統級主要監控硬件和網絡等；

二、應用級主要監控經常使用軟件的健康情況；

三、項目邏輯監控主要模擬用戶行爲探測項目功能點是否運行正常；

四、用戶體驗監控主要聯動博睿和基調等第三方監控一塊兒優化用戶體驗。

        咱們用過的工具不少，開源工具備Nagios、 Cacti、Ganglia、Zabbix等，同時本身也開發了一些針對項目場景的監控工具，但萬變不離其宗，都是圍繞上述幾個維度進行監控，而後再進行分級預警和報警。

       爲了減小報警騷擾，咱們分級處理，將報警分爲郵件預警、短信報警和瘋狂短信報警。

以磁盤空間監控爲例：

一、天天下午6點，統計磁盤使用率超過80%的機器，發出郵件預警，下班前解決；

二、在預警的基礎上，超過85%觸發短信報警；超

三、過90%就要持續報警，避免事故的發生。

       此外，隨着服務器數量的增多，硬件故障在所不免，架構設計須要考慮高可用方案，冗餘範圍內的服務器故障會以郵件預警的方式發出，避免對運維工程師的騷擾。

        有了監控工具和分級機制，還須要有好的制度。爲了大部分人能夠安心休息，咱們天天有專人負責處理常規報警，遇到沒法解決的問題纔要求他人協助。次日的負責人要針對第一天的報警找出根本緣由，並盡力解決，由於若是沒法根治，困擾將持續發生。所謂線上無小事，實際工做中複雜場景引起的問題數不勝數，因此能夠寬容第一次錯誤，但不能接受一樣問題發生第二次，要不斷地總結和完善。

       工具化是運維的必經之路，是向更高層發展的基礎，面對運維這樣複雜的學科，這樣一個極其磨鍊人意志的工種，運維工程師須要用聰明的方式解決複雜的問題，節省時間，去作更有意義的事情。

 

第二次升級：運維產品化

        我剛提出運維產品化時，有朋友開玩笑說，你作後端運維吃苦受罪這麼多年，看着產品經理吃香的喝辣的，羨慕嫉妒也想轉行作產品吧。也有人說，你是在偷換概念，不就是作自動化運維平臺嘛。

        其實提出這個概念，一方面是源於有了足夠的工具化積累；另外一方面是想換一種思路作運維，培養產品觀，站在用戶的角度思考問題，讓處於後端的運維工程師主動挖掘需求，圍繞運維作更多的探索，提高團隊技術能力，解決海量用戶帶來的問題。

        有了這個想法，就須要將無形的技術轉變爲有形的產品形態，同時要賦予它好的寓意。咱們的產品取名爲HULK——綠巨人，意在讓小夥伴們藉助巨人的肩膀成長，輕點鼠標，指揮若定。

       想到作這個平臺，源於對實際工做需求的觀察。產品經理有了創新點以後，開發工程師就想以最快的速度上線，但又會很痛苦，由於產品就比如寶塔明珠，塔基須要一層層地蓋。而開發工程師是與運維工程師合做最緊密的兄弟，「兄弟有可貴拔刀相助」，所以咱們明確了開發工程師就是運維平臺的用戶，運維工程師在平臺的建設中扮演了多重角色，是建設者也是使用者，但目標是爲用戶解決問題，讓咱們的用戶有極致的用戶體驗。

       基於這些想法，咱們勾畫出了宏偉藍圖，提供一個塔基：

一、第一層提供核心基礎服務，如Web、RDB、NoSQL等；

二、第二層提供通用基礎服務，構造一個完美的平臺，讓開發工程師受益。

       但勾畫的平臺功能大而全，需求都是咱們替用戶假想的，這樣作的後果就是進展緩慢，但作出的功能沒人用。咱們在失敗中反思，意識到需求還得從平常工做中去挖掘，平臺上每一個功能模塊都必須解決用戶的痛點。互聯網精神惟快不破，要圍繞「快」找痛點。早期開發和運維的合做中，更多的是郵件、IM及當面溝通，跨團隊的溝通成本是第一個痛點。初期平臺建設中，咱們從加速流程開始進行摸索，以「需求任務流」爲核心，將通用需求規範流程，統一需求提交頁面，同時儘可能爲用戶提供選項，而不是隨意填寫，儘可能減小溝通成本，同時爲徹底自動化打好基礎。因爲完整的自動化流程開發成本比較高，初期咱們還「投機取巧」，用戶提交需求之後，只是把格式化的郵件發送給運維工程師。運維工程師使用半自動化工具幹活，完成後再經過平臺任務流告知用戶結果，手工操做的部分是隱藏在平臺後面的，用戶不得而知。就用這種方式，咱們的平臺積累了很多用戶和口碑。

以後咱們將平常需求分層、分類：

一、主機類包括主機申請、帳號受權、軟件部署等；

二、Web類包括配置文件管理、域名管理等；

三、DB類包括建庫、建表、SQL審覈、受權等。

      再攻克技術難點將一個個需求實現徹底自動化，點點鼠標解決問題。

       關於需求任務流，還有個小插曲，標準的任務流由提交、審覈、駁回/經過組成。但這個流程太死板，例如用戶提交的一個需求，在審覈的過程當中有待商榷，運維工程師會和開發工程師溝通，最終達成一致意見便可，而若是按標準流程須要駁回再提交。爲了讓用戶少一次操做，咱們增長了管理員可編譯功能。有些同事反對這樣作，以爲不符合常理。不過有時候常理是須要結合實際場景打破的，就爲了讓用戶使用更簡單。

        近期爲了進一步提高項目試錯階段的速度，咱們在平臺上推出了一個新功能：「項目孵化器」。以典型的Web業務爲例，以往，申請Web Server、帳號、數據庫實例、負載均衡等是提給運維最基本的需求，每一步都是時間成本。使用「項目孵化器」能夠最大限度解決這個痛點，只需在平臺上進行兩個步驟：第一步填寫業務名稱，預估峯值QPS；第二步選用MySQL、MongoDB、Redis等相關數據庫資源。兩步以後，Web Server、數據庫實例等所需資源會瞬間展現在用戶面前，同時包管理、配置文件管理、代碼發佈系統、監控系統等配套輔助功能隨之開通。

       與以前的模式相比，效率和規範化都有明顯提升。提及來很神奇，但實現理念很簡單，咱們提煉平常項目中的通用方案，構建資源池，在項目發展初期最小量匹配資源。在孵化器的設計階段，咱們聽到了不少不一樣的聲音。例如，讓用戶填信息不夠全面，架構太簡單不知足所有需求，諸如此類問題，讓人頭痛欲裂。通過過往項目分析及用戶調研，發現項目尚處於試錯階段，快速試錯是首要需求。至於項目發展中衍生出來的需求，能夠再用平臺擴展功能去解決。

        當利用孵化器創建一個試錯項目以後，用戶進入平臺想看見什麼？展示形式如何？還能作什麼？這些問題隨之而來。

        衆所周知，項目中的關聯關係是個複雜的問題，解決很差，就像人心渙散沒法聯動。爲了解決此問題，首先咱們肯定平臺各功能模塊以項目名爲主鍵，將項目的域名、負載均衡、Web Server、數據庫、通用基礎服務等相關聯。項目後期各功能模塊的擴容能夠藉助關聯關係自動化完成。例如增長一臺Web Server，便可自動部署軟件環境，完成相關節點受權、上傳代碼、測試上線。

        展示形式上咱們借鑑社交網站的實現方案，以「個人項目」爲中心，用戶進入平臺之後默認頁展現項目在平臺中用到的各功能模塊信息，例如域名、主機數量、數據庫實例和監控指標等。作到信息清晰可見，操控簡單易用。

       在平臺建設中，咱們一直遵循兩個準則：

第一，把事情由複雜變簡單；

第二，給用戶極致的用戶體驗。

        所謂極致，就是要超出用戶的預期，但只有挖掘用戶潛在的需求，才能作出超出預期的功能。傳統的運維模式，大可能是開發工程師提需求，運維工程師知足需求，運維工程師主動推動的意識不夠。360的文化中有很重要的一點是Ownership，一個項目的成功與失敗，運維工程師是有責任的，所以須要在平常工做中時刻提醒本身「這個項目是個人，爲了讓項目變得更好，咱們須要主動思考，爲開發工程師提供更多的增值服務」。例如一個項目上線前，會默認部署日誌收集模塊，收集彙總後進行訪問日誌自動化分析，以時間維度展現訪問量走勢，同時輔以IP地址分析模塊展現地域及運營商分佈。同時基於訪問日誌狀態碼作進一步的頁面分析，而後以日、周、月維度生成一份體檢報告，以及應對方案推送給開發工程師。這些增值服務是超出預期的，拉近了開發工程師和咱們的距離，一塊兒去探討、改進，作出更多有利於項目發展的功能。

 

結束語

       運維工做在一家公司中相當重要，但傳統的運維模式必定程度上限制了運維工程師的技術發展，更抑制了創新思惟，咱們須要利用運維「寬泛技術」定位的優點開拓思路。

      例如運維工做須要和不少開發團隊合做，協助架構設計，在這個過程當中會接觸到不少開發團隊的技術積累，能夠把各家之所長進行聚合，將一些基礎服務進行平臺化改造，資源共享。也能夠根據項目的須要，主動作技術研究，將基礎服務作成一個個小產品，提供給開發團隊使用，幫助項目縮短研發週期，穩定發展。在當今技術背景下，運維工程師應該在紅海中尋找藍海的思惟模式，培養產品觀，由外至內地思考，突破傳統運維的壁壘，開拓創新。