河貍家運維發展歷程，是從無到有的過程。河貍家起初聘請了一家外包公司幫助開發早期的產品，但使用中出現了一些問題。后來逐漸發現原來軟件部署上去之后，不只要進行增刪改查功能，還要有專門的運維工程師去線上運維做相關的工作。
運維團隊的職責也經歷了從不清晰到明確的過程。之前有的工程師同時兼做很多工作，日常工作40%、50%的時間都是做幫領導導報表，久而久之他變得非常郁悶，本職工作也很難做得好。
河貍家的運維，其實也是從黑盒到白盒的過程。作為一個程序員，個人會有很強的控制欲：如果說不知道要上線的東西源碼是怎么寫的，心里會很是慌兮兮的。運維希望各個數據都可以看得到，又全部都可以串起來。之前可能只是用簡單地監控讀取一些數據，但是其中整個請求串起來之后，代碼中出了什么問題，比如說活動的場景出現問題，可能就束手無策了。
此外，這還是從混亂到規范的過程。什么是混亂？大家很多都是從創業公司出來的，遇到過很多創業公司發展中的問題。在創業公司，包括團隊、人員、項目，都需要不斷地進行自我學習、提升和修煉，是一個不停成長的過程，因此不可能一下子都很完美。所以說在這個過程當中，公司整個項目，包括項目管理開發流程等等都是缺失的。
舉個例子，團隊做一個簡單的版本發布，怎么做呢？發布之前，產品和運維的同學給了你一些不同的功能提議，結果確定下來之后發布日期馬上就到了，這時候只能加班加點去開發。這種情況下去發布，運維半夜三更被叫起來去做，結果發布上去出現一堆問題，頓時傻眼了。這樣下來，運維的黑鍋越背越多，就被別人說成“不靠譜”。
這個時候需要反思。當團隊把來龍去脈想通之后，會認識到項目管理的過程都是一環扣一環，而往往最后一道環節是產品、技術、運維可以看見的這一部分。因此一旦出了問題，就得背黑鍋，前面的環節干了“壞事”的人都逃之夭夭了。把這個東西梳理清楚之后，規范就可以推行起來。項目管理到底要怎么管？提下我們的想法和思路。
項目管理的想法和思路
首先，是從業余到標準運維的思路。什么叫從業余到標準？之前線上的服務端用java的代碼比較多。以部署為例，在之前的部署當中，發包的過程是把手工的包丟過來，而后是手工腳本。有些同學改了代碼，發現線上跑的代碼跟你的對不起來。所以就要制定標準，這個標準是什么？包括軟件怎么打包、怎么部署、怎么成為一個標準的軟件上線，都需要去梳理；在框架方面，比如java工程能一鍵生成一個可執行、可交互的軟件。
此外，關于上線流程也研發了統一的系統，用這個流程去對接，包括SVN開發標準梳理等。前期推行時，開發同學可能不太適應，因為不管怎么說，從作坊式的走向規范化都不是件容易事。另外還建立了緊急發布環節：可以讓你通過審核，但是要找領導去批。當然大家一開始不適應找領導簽字。過了幾個月之后，統計緊急發布了多少，正常發了多少，為什么每天都是緊急發布？真的業務到了每天都需要發的情況嗎？這些問題都有據可查了。所以這個東西不僅僅是個標準，也可以作為記錄，充當是否合理的有力評判依據。
要從被動往主動去發展。我們一直希望運維能反過來推進一些事情：包括提前預測一些業務上的情況，以及未來業務的發展規劃等。當然這個實現起來可能很困難。
BAT有些系統很牛逼，做得很完美。但公司通過某個渠道把它拿過來，納為己用是不是就高枕無憂了呢？不是這樣的，技術沒有牛逼不牛逼、高大上不高大上，只有合適不合適，能不能在自己的場景里面適用。
運維在這個系統上線之后，不停地發現線上的問題，包括技術的、業務的，因而不停地去優化，讓公司軟件業務不斷地往好的方向發展。因為問題永遠不可能消除，學過矛盾各位的都知道，矛盾只可以轉移，不可以消滅，一個矛盾接著一個矛盾，我們只能兵來將擋、水來土掩。后臺有報警系統、用戶投訴、客戶投訴、后臺分析等，現在會統一提交到運維做綜合性的分析，再去判斷問題的可能性。比如是自身的問題就去做修復，如果不是我們這里的問題，就要跟研發等相應的團隊同學去溝通、配合。
運維在整個公司項目管理過程當中，其實是最后一個環節。所以運維把工作做好的前提是：把整個流程全部都串起來。只有把這個工作做好了，運維的工作才能做好。而如果這個工作不做好，運維永遠沒有話語權去反推其他部門。因此，流程可能不一定按照這種方式去走，但是一定要找到一條適合自己公司、自己場景的道路，去把這個流程規范好。
為什么要做監控系統？
在做這個系統之前，團隊曾面臨一些問題。第一，運維系統之前只是針對服務器，用zabbix等做了一些監控，接入了短信的報警。但后來發現監控一旦報警之后，首先沒人處理；其次報警沒有分類，具體報了什么無從知曉，沒什么意義；再次研發人員不關注運維，只是需求功能的疊加。之前研發團隊只關注開發功能，不關注上線之后代碼到底產生什么作用，運維好不容易把工作做好了，結果隔了一段時間，這些問題又來了。因為開發不關注這些東西，也不去審查這些問題，運維根本就沒法做到。
第二，研發團隊自身的能力也很難得到成長，因為他們永遠只是在開發功能，但是不知道功能上去之后對業務有什么影響，也根本不關注。久而久之，團隊也很難更好地成長，并且人員歸屬感、能力提升等等都會受到一系列的制約。最后，公司的系統成了一個黑盒，如果真的出了問題，除了底層zabbix可以報警之外，其他一無所知。只能隨便亂搞，不知道到底是哪里的問題，這時候真的是抓狂的。
提出這些問題之后，這個平臺開始建立，設想有這么幾個初衷：
第一，系統，基礎軟件，服務狀態等都是可以可視化的。
第二，整個流程是可以跟蹤到的。
第三，能對線上的流量，包括PV、UV進行統計和分析。
第四，可以定期跟蹤到線上的代碼性能情況，比如說代碼執行站最終性能卡在哪里，哪個函數調用比較慢等。
第五，希望對數據庫的慢查做一些分析。
第六，業務穩定性監測，比如說商品訂單支付可以做一些穩定性的監測。
第七，對報警做分級，做到可分支，多個通道都可以接入，可以短信、郵件包括微信報警。
第八，從運維的角度便于業務分析數據。
考慮自己的問題。不管是業務還是技術，可能運維只是考慮到系統服務器怎么運維，但產品也需要運維，如果沒有一些可視化的東西，你都不知道自己的數據是怎么回事。產品上線之后，久了也不知道問題出在哪里，這從廣義的角度也是一個運維的過程。
監控系統的解決方案
第一版的解決方案是這樣的：首先LVS請求進來，通過APP協議分發再到后端的agent、ngx，給它加了ID的概念，自己隨機生成，一直把后面的ID把整個請求流程貫穿起來。
河貍家在server端開發了一個agent功能，對java產品的日志做一些采集，采集完之后丟到后端里面去。與APP應用服務器部署在一塊。MonitorServer主要用于監控系統級軟件，通過MonitorServer定期去交互，取一些數據丟到隊列里面。
報警服務器其實是一個流失計算的過程，收到數據之后適時做一些Ctrl工作，有一些規則觸發之后，會激活后面進行報警處理。我們有一些rebport-server，也可以通過流失的方式，對一些報表，比如每日匯總的數據，通過這種方式計算，錄入到匯總表里面去。
第二個是采集模塊，采集java的內容，目前比較粗放，通過javaagent，嵌入一些采集數據的功能，把java業務相關的數據，代碼執行站通過這種方式采過來之后，丟往后端。MonitorServer，像redis就是基于Info&monitor命令實現的。我們沒有自己寫代碼，直接把別人的東西改了改，直接分到自己的MonitorServer里面去了。
此外，現在對于后端的dao/jdbc也做了一個工作，主要把傳輸執行的參數以及執行時間這一塊拿過來放到后端。當然這個東西不是實時去取，因為不管怎么弄，這塊數據無法實時獲取。javaagent通過自解碼能做的功能相對有限，因為在agent系統沒啟動之前，想做一些現成詞的工作會遇到很多問題。
在這種情況面，只能簡單地去實現幾個預估的現成丟在里面，預估的現成除非在硬件級別支持后臺異步，否則異步就是假的，隊列大小能搞多少呢？搞得再大，也不能解決在業務高峰期有很多數據丟過來時，隊列會撐滿的情況。這個時候，異步就變成了同步，后面全部都會被堵塞掉。所以在這種場景下面，采集的工作其實是，在一臺機器上面抽樣，在某個時間點取得一部分數據，通過這個時間點來采集。
數據完成之后，需要統計業務各個層次的情況。我們分裝了一個IP庫，主要是將GeoLite2、純真庫、Ip.cn貫穿起來，幾年日志里的IP地址和Geo地址都包含在里面。
這樣，平時的流量分析就可以統計到各個維度。現在，IP地址的排名、網絡狀態，還有哪個業務最高等都可以監控到。
做了這個監控之后，也發現了一些問題：4點鐘的時候，流量會很奇怪地突然下降，因此發現有人定期4點鐘來查我們的列表，因為IP地址都是零散的，所以不能直接通過肉眼觀察到這些問題。比如雙11那天，因為后端還用比較老的連接詞，但那時候連接詞堵不住了，有些代碼就堵住。在這種情況下，運維就可以直接排查，C3P0的隊列就可以重新排名。
另外，針對java的進程也做了一個健康度的采集，比如說CPU內存、YGC等等，都可以在這里展示出來。像數據庫慢查，每秒鐘的時間點都可以在這里看到。現在可以做郵件、手機、微信報警的配置。
架構的改進
隊列數據多了之后，由于隊列不是專用的，因此如果把它當隊列使用的話，做拓展、做集群都會遇到一些問題。后來改為直接用Spark-streaming來更換計算服務，用filter和aop替代javaagent來做字節碼增強。
上文提到一鍵生成可以運行的java工程，這是我們開發了一個jee-template，后期也會針對發布系統和監控系統開發源代碼。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：河貍家運維發展的歷程
相關文章
