一.前言
運(yùn)維的基礎(chǔ)工作通常是針對(duì)現(xiàn)有系統(tǒng)及項(xiàng)目的，例如服務(wù)器、各類云產(chǎn)品，正在運(yùn)行的項(xiàng)目、監(jiān)控、賬號(hào)權(quán)限管控，項(xiàng)目上線等等，是寬泛而繁瑣的，少有建設(shè)性的內(nèi)容。
那當(dāng)我們接手一套新的系統(tǒng)，就有必要將它本身及周邊進(jìn)行完善?？赡苌贁?shù)公司有較為全面的運(yùn)維體系，有我們的桌面運(yùn)維，網(wǎng)絡(luò)運(yùn)維，安全運(yùn)維，研發(fā)運(yùn)維、數(shù)據(jù)庫運(yùn)維以及系統(tǒng)運(yùn)維或應(yīng)用運(yùn)維等專業(yè)團(tuán)隊(duì)，而更多的公司運(yùn)維可能只有1-2個(gè)。以上的崗位工作都需要完成，但以下我們著重會(huì)聊到應(yīng)用運(yùn)維。
在接觸新環(huán)境時(shí)，面對(duì)的是上任留下的坑，這比開發(fā)接手代碼要更加嚴(yán)峻。交接的資料其實(shí)不應(yīng)該只是賬號(hào)密碼、工作流程，工作注意事項(xiàng)，更重要的是操作維護(hù)文檔，因?yàn)橄到y(tǒng)很少有簡單的環(huán)境，即便有，也會(huì)存在一些微妙的項(xiàng)目邏輯關(guān)系，稍有不慎，就有可能釀成線上問題，現(xiàn)在大多都是微服務(wù)的結(jié)構(gòu)，增加了系統(tǒng)維護(hù)的復(fù)雜性。
例如接手后領(lǐng)導(dǎo)要你部署使用docker部署一個(gè)java服務(wù),從正式環(huán)境復(fù)制一個(gè)到測(cè)試環(huán)境，結(jié)果啟動(dòng)后出問題了，可能是啟動(dòng)參數(shù)與目前環(huán)境不匹配，可能是連接權(quán)限未放開，可能是啟動(dòng)后連接的是生產(chǎn)的數(shù)據(jù)庫，如果程序啟動(dòng)后清空或者修改了一些歷史數(shù)據(jù)，令人細(xì)思極恐。
這種問題很常見，就我目前就遇到不少，好多配置信息寫的很模糊，項(xiàng)目與項(xiàng)目之間耦合度非常高，沒準(zhǔn)就牽扯到哪個(gè)系統(tǒng)了，牽一發(fā)而動(dòng)全身，是關(guān)也不敢關(guān)，改也不敢改，作為一名運(yùn)維工程師，我們居然會(huì)不敢動(dòng)一個(gè)項(xiàng)目！
所以要打造一個(gè)鐵桶出來，這是一個(gè)創(chuàng)造性的過程，也是我們深入項(xiàng)目的過程。只有更深入的了解項(xiàng)目，才能更好的去維護(hù)項(xiàng)目。
●做好一個(gè)運(yùn)維的基礎(chǔ):
●對(duì)自己當(dāng)前的環(huán)境和任何東西都應(yīng)該非常清楚；
●要有監(jiān)控，切實(shí)有用的可以發(fā)現(xiàn)問題的監(jiān)控；
●任何東西都要有備份，可以用于快速恢復(fù)，也要做恢復(fù)演練。
進(jìn)階∶
針對(duì)系統(tǒng)做優(yōu)化處理；
針對(duì)工作流程做優(yōu)化處理
這就是上述大綱了，后續(xù)會(huì)詳細(xì)說明的，其實(shí)也是大眾路線，先標(biāo)準(zhǔn)化、流程化，再自動(dòng)化。
二.基礎(chǔ)
2.1項(xiàng)目摸底
在接手系統(tǒng)后，先要確保能日常維護(hù)，對(duì)整套系統(tǒng)做一個(gè)摸底，一般包括以下幾項(xiàng)：
●項(xiàng)目簡介
●賬號(hào)密碼表
●項(xiàng)目資源管理配置清單
●各種結(jié)構(gòu)流程圖
●部署維護(hù)文檔
●項(xiàng)目監(jiān)控策略匯總表
●項(xiàng)目應(yīng)急操作手冊(cè)
項(xiàng)目簡介
我們可以從當(dāng)前項(xiàng)目的業(yè)務(wù)范圍，即項(xiàng)目的功能是什么？以及項(xiàng)目負(fù)責(zé)人及相關(guān)人員是誰，方便我們后面更好的項(xiàng)目對(duì)接。
賬號(hào)密碼表
賬號(hào)密碼表中應(yīng)詳細(xì)記載各服務(wù)器、平臺(tái)、系統(tǒng)的登錄用戶名及密碼，另外還應(yīng)該有權(quán)限記錄表，記錄給誰開過權(quán)限，登錄賬號(hào)又是什么，以上種種，此處僅是距離，需要記錄的東西很多，切記一定要準(zhǔn)確清晰。
項(xiàng)目資源管理配置清單
這里面我覺得至少包含但不限于4個(gè)sheet表：服務(wù)器清單，項(xiàng)目域名信息，項(xiàng)目服務(wù)信息，第三方服務(wù)資源清單，每種信息都應(yīng)該列出項(xiàng)目所有環(huán)境的信息，例如正式和測(cè)試環(huán)境等。
各種結(jié)構(gòu)項(xiàng)目流程圖
例如此項(xiàng)目的網(wǎng)絡(luò)拓?fù)鋱D，系統(tǒng)架構(gòu)圖，從這個(gè)拓?fù)鋱D中我們可以看到此架構(gòu)使用了多少臺(tái)服務(wù)器，整個(gè)邏輯流程是怎樣的。例如我們可以從域名開始摸，域名對(duì)應(yīng)的Ddos防護(hù)，下面是負(fù)載均衡，再下面是每個(gè)模塊的服務(wù)。每個(gè)服務(wù)需要連接哪個(gè)庫，又需要和哪個(gè)服務(wù)進(jìn)行交互。
部署維護(hù)文檔
此文檔可包含詳細(xì)的安裝步驟，配置文件中的數(shù)據(jù)庫等地址指向都要寫清楚，那么如何檢驗(yàn)此文檔的實(shí)用性呢？將此文檔交接給另外的同事，可以達(dá)到遷移恢復(fù)，復(fù)制項(xiàng)目的目的。
項(xiàng)目監(jiān)控策略匯總表
主要包含目前的監(jiān)控策略，可分為基礎(chǔ)監(jiān)控和業(yè)務(wù)監(jiān)控?；A(chǔ)監(jiān)控為CPU、內(nèi)存、網(wǎng)絡(luò)帶寬等服務(wù)器基礎(chǔ)資源監(jiān)控；業(yè)務(wù)監(jiān)控則是針對(duì)服務(wù)本身的監(jiān)控，此監(jiān)控可暴露出當(dāng)前的項(xiàng)目問題。此表可方便與項(xiàng)目負(fù)責(zé)人對(duì)接項(xiàng)目監(jiān)控問題，或方便以后查詢監(jiān)控是否有遺漏等。
項(xiàng)目應(yīng)急操作手冊(cè)
項(xiàng)目已知的問題，經(jīng)常發(fā)生的問題的處理方法，解決方案等。
可能很多小伙伴認(rèn)為上面部分內(nèi)容是業(yè)務(wù)上的東西了，覺得運(yùn)維沒必要去學(xué)，開發(fā)讓擴(kuò)展部署幾個(gè)服務(wù)，部署就是了，反正這塊是開發(fā)要負(fù)責(zé)的，出了業(yè)務(wù)問題開發(fā)排查即可。
2.2做一個(gè)好輔助
那這根本沒有體現(xiàn)運(yùn)維的價(jià)值。相信很多人玩過LOL，當(dāng)時(shí)也著迷其中，記得有句話，在LOL小隊(duì)5人中，通常由隊(duì)長來擔(dān)任輔助。因?yàn)檩o助空閑時(shí)間更多，可以看到全局的內(nèi)容，這句話放到運(yùn)維身上也同樣適用。
開發(fā)、測(cè)試都忙著對(duì)禪道中滿屏的任務(wù)清單進(jìn)行工作，需求、測(cè)試任務(wù)源源不絕，相信很多程序員都面臨過產(chǎn)品或者運(yùn)營作死的需求，尤其是互聯(lián)網(wǎng)公司，項(xiàng)目需要進(jìn)行快速迭代，有多個(gè)需求歸類到一個(gè)版本中，大約2周一個(gè)版本，要在12天內(nèi)開發(fā)完成，2天內(nèi)進(jìn)行預(yù)發(fā)布環(huán)境的發(fā)版測(cè)試，這段測(cè)試期需要一邊解決bug，一邊完成新的需求。
項(xiàng)目版本需求的排期都到3個(gè)月后了，并不是開發(fā)寫完就可以休息了，后面任務(wù)只不過稍微提前了而已。測(cè)試也是一樣，緊跟著開發(fā)進(jìn)行功能驗(yàn)證，也是忙得不行。
那出現(xiàn)問題后，其它崗位并沒有太多精力排查和關(guān)注性能等方面，都著眼于當(dāng)前任務(wù)的開發(fā)，趕工期。那運(yùn)維其實(shí)可以作為一個(gè)指揮官，并非是可有可無的角色，現(xiàn)在不被重視只是因?yàn)榇蠖鄶?shù)運(yùn)維并沒有意識(shí)到這個(gè)重要性。
開發(fā)除非是全棧業(yè)務(wù)都熟練，就一個(gè)小團(tuán)隊(duì)20開發(fā)2測(cè)試1運(yùn)維來說，開發(fā)都只研究自己的模塊，每當(dāng)出現(xiàn)問題就很難定位具體點(diǎn)，需要運(yùn)維對(duì)整體系統(tǒng)要了解，系統(tǒng)+業(yè)務(wù)才能更好管理和排查。
2.3學(xué)習(xí)業(yè)務(wù)
對(duì)于具體業(yè)務(wù)如何清楚了解，最好的方式是直接順著現(xiàn)有資料捋順?biāo)?，遇到不明白的地方去問開發(fā)，將相應(yīng)結(jié)構(gòu)進(jìn)行畫圖和文檔進(jìn)行維護(hù)好，那在公司中你的價(jià)值會(huì)成倍增加的。相信也會(huì)讓領(lǐng)導(dǎo)更多的看到你落地的工作，且也會(huì)讓同事們?cè)敢庀嘈拍愕哪芰ΑI(yè)精神比知識(shí)更加重要。
當(dāng)然不僅是為了更好維護(hù)系統(tǒng)，也是為了未來優(yōu)化做準(zhǔn)備。不用明白代碼方面的，只要知道整體流程。
我們現(xiàn)在就有這種問題，某個(gè)模塊連接哪個(gè)庫都不知道，有時(shí)候突然發(fā)現(xiàn)測(cè)試的服務(wù)器竟然連接著生產(chǎn)的某個(gè)庫，還用的公網(wǎng)連接（環(huán)境間VPC或安全組隔離），這要不一開始搞清楚，不去主動(dòng)了解，那帶來的問題、安全隱患會(huì)在后面某個(gè)時(shí)刻讓你難受。
一個(gè)簡單例子是有個(gè)老舊的電商項(xiàng)目，幾臺(tái)應(yīng)用服務(wù)機(jī)器+一個(gè)Mysql數(shù)據(jù)庫，當(dāng)時(shí)問了一圈人大家都說應(yīng)該是不用了，已經(jīng)到新的上面了。也沒有去保存?zhèn)浞葜苯觿h除了，沒過幾天就有使用者聯(lián)系說還在用。。。
這種盲區(qū)在我們快300臺(tái)服務(wù)器里還有大量的存在，要是運(yùn)維人員不主動(dòng)去了解，那開發(fā)也沒時(shí)間去看的，這個(gè)隱患會(huì)無限期擱置，還是上面說的，會(huì)在某個(gè)時(shí)刻咬你一口。
在我們大致了解整體結(jié)構(gòu)后，以文檔進(jìn)行驅(qū)動(dòng)，先建立好空白文檔頁。重點(diǎn)中的重點(diǎn)是我們的拓?fù)鋱D、服務(wù)配置清單，起碼項(xiàng)目的架構(gòu)，是什么服務(wù)要了解清楚。
具體要了解哪些，我這里只能大致描述，再具體一些的地方應(yīng)當(dāng)根據(jù)你的項(xiàng)目情況再去統(tǒng)計(jì)。
●了解域名走向，請(qǐng)求走向；
●了解各服務(wù)之間的搭配，例如rabbitmq哪些程序在用，用來做什么；
●每個(gè)模塊程序之間如何通信的，需要如何進(jìn)行交互；
●了解各服務(wù)作用，當(dāng)出現(xiàn)問題后，我們可以快速準(zhǔn)確地判斷出大概是哪個(gè)服務(wù)的原因。
但業(yè)務(wù)還是要了解的，流程圖也依然要畫，畫圖我目前用的在線工具：processon，如果你覺得免費(fèi)的可用文件數(shù)量不夠，上面可以付費(fèi)購買團(tuán)隊(duì)模式，不是很貴。
2.4標(biāo)準(zhǔn)與流程
做好圖后，開始到系統(tǒng)里去整理，做標(biāo)準(zhǔn)化、流程化。建立好以下幾個(gè)標(biāo)準(zhǔn)：
●服務(wù)名稱命名：可根據(jù)項(xiàng)目環(huán)境或用途進(jìn)行命令
●端口規(guī)范：可根據(jù)項(xiàng)目環(huán)境或用途進(jìn)行劃分
●IP地址規(guī)劃：可根據(jù)項(xiàng)目環(huán)境及區(qū)域進(jìn)行劃分
●服務(wù)部署目錄
●日志輸出目錄
●備份存放目錄
●工具包存放目錄
●數(shù)據(jù)存放目錄
●腳本存放目錄等其它常用目錄固定位置
流程：
●各服務(wù)資源預(yù)算制作流程
●服務(wù)器購買交付流程
●服務(wù)部署/上線/維護(hù)流程
●賬號(hào)&權(quán)限添加流程
●備份定期恢復(fù)驗(yàn)證演練流程
●定期檢查項(xiàng)目資源使用流程
●故障報(bào)告管理流程
其實(shí)凡是資源都做規(guī)范了，凡是要多次重復(fù)做的都流程化，防止遺忘。這兩樣也是為了后面自動(dòng)化打基礎(chǔ)，將重復(fù)操作自動(dòng)執(zhí)行。
這兩塊整完，說明對(duì)系統(tǒng)做維護(hù)沒有任何問題了，只要不是新東西，起碼現(xiàn)有項(xiàng)目都可以管理好。
簡單畫個(gè)思維導(dǎo)圖，標(biāo)準(zhǔn)化的范疇主要包含但不限于以下內(nèi)容：
2.5維護(hù)
在項(xiàng)目不擴(kuò)展優(yōu)化的情況下，要維護(hù)好當(dāng)前資源，需要用到監(jiān)控與備份的幫助。有效的監(jiān)控可以及時(shí)發(fā)現(xiàn)問題，避免人力重復(fù)巡檢。完善的備份可以在出現(xiàn)任何系統(tǒng)問題的時(shí)候（非功能BUG），立刻進(jìn)行恢復(fù)，簡單方便快速有效。
監(jiān)控具體可以針對(duì)業(yè)務(wù)做技術(shù)選型，一般是zabbix，容器或k8s就Prometheus，需要圖形展示監(jiān)控?cái)?shù)據(jù)就grafana，另外還有小米的運(yùn)維監(jiān)控服務(wù)Open-Falcon。
備份如果用云服務(wù)就簡單很多，可以使用腳本定時(shí)備份傳到OSS里。物理機(jī)可可以寫一些腳本，將任何有狀態(tài)的東西都備份出來。例如數(shù)據(jù)庫、配置文件、日常腳本、服務(wù)日志、等等和純凈系統(tǒng)有差異的東西。
三.進(jìn)階
3.1系統(tǒng)&服務(wù)優(yōu)化
系統(tǒng)或服務(wù)的優(yōu)化比較常見，一般是更改配置文件，使得服務(wù)可以承接更多并發(fā)，可以抗更多壓力。
這些有大把的文檔可以看，這里不重復(fù)了，主要提幾點(diǎn)注意的地方。
每次使用新服務(wù)器前，應(yīng)進(jìn)行系統(tǒng)初始化配置；
優(yōu)化并不是改改配置就行，需要對(duì)每個(gè)參數(shù)及整套系統(tǒng)都有深入理解；
改配置的時(shí)候要慎重，不要想當(dāng)然，很可能你這里為了減少圖片的帶寬占用開啟了壓縮，結(jié)果改完就崩潰了，線上的圖片顯示不完全了；
做優(yōu)化方案的時(shí)候，要有層次，可以從最簡單便宜的地方來。例如從結(jié)構(gòu)上優(yōu)化、去掉一些沒用的模塊，可以釋放很多資源；
做安全方案也是，VPN+堡壘機(jī)（如jumpserver）可以解決99%日常安全隱患，而不是去從花費(fèi)高、細(xì)節(jié)的地方先去實(shí)現(xiàn)。
3.2工作流程優(yōu)化
上面說了，其它崗位很繁忙，很難有精力做其它事，這里除了系統(tǒng)還有流程上的。他們遇到一些工作流程性問題，即使可以解決，但也很難停下腳步。
運(yùn)維的用戶是內(nèi)部人員和服務(wù)器，所以工作可以分為可見和不可見（相對(duì)于部門）。所以在維護(hù)設(shè)備和服務(wù)器之余（服務(wù)器不會(huì)總出問題），可以將精力放到維護(hù)devops上，也就是工作方法。
例如當(dāng)我們需要統(tǒng)計(jì)我們?cè)品?wù)資源時(shí)，如果我們使用人工采集，就需要單獨(dú)一個(gè)人花費(fèi)可能數(shù)天的時(shí)間進(jìn)行統(tǒng)計(jì)。那解決這個(gè)問題很簡單，做一個(gè)自動(dòng)采集云服務(wù)的工具，再由我們進(jìn)行檢查及表格美化即可。
再比如工作中大量的zabbix報(bào)警，可能相對(duì)沒有那么緊急，會(huì)不會(huì)污染我們的報(bào)警工具，釘釘或微信等。那么對(duì)于業(yè)務(wù)不可用的情況做一個(gè)電話報(bào)警是不是更好呢，這樣也不用時(shí)時(shí)刻刻盯著釘釘報(bào)警。
看著差別不大，盯著也不礙事，實(shí)際是運(yùn)維價(jià)值的體現(xiàn)。再說幾個(gè)例子，當(dāng)前登錄zabbix啊，jenkins、gitlab或禪道、OA或其他各種系統(tǒng)等都是單獨(dú)賬號(hào)，那搞LDAP是不是更好。或者做一個(gè)內(nèi)部使用的常用網(wǎng)址導(dǎo)航頁，這樣會(huì)不會(huì)使用更加便捷。
SQL語句的執(zhí)行，經(jīng)常需要DBA在服務(wù)器中執(zhí)行，那么做一個(gè)SQL審核平臺(tái)，例如archer，隨時(shí)隨地都能審核開發(fā)人員提交的SQL進(jìn)行執(zhí)行。同樣對(duì)于開發(fā)人員而言，測(cè)試或開發(fā)在正式或測(cè)試環(huán)境查詢數(shù)據(jù)時(shí)用WEB版的數(shù)據(jù)庫在線審計(jì)平臺(tái)是不是比每個(gè)人用navcita更加安全和可控方便？
那jenkins發(fā)版后在釘釘加一個(gè)提醒是不是好點(diǎn)？開發(fā)提交代碼后，自動(dòng)發(fā)布更新項(xiàng)目是不是更加簡單高效？
這些看似沒有也沒事，但當(dāng)你發(fā)現(xiàn)某個(gè)開發(fā)遇到一些麻煩的影響時(shí)，你去解決，這就是內(nèi)部的貢獻(xiàn)，就像LOL中的輔助，在總攬大局，在推動(dòng)devops的發(fā)展。
devops的概念炒了這么多年，更多人也在追求這種更高層次的工作方式，看內(nèi)容基本都是運(yùn)維的，開發(fā)的很少。這也和開發(fā)埋頭工作不無關(guān)系，所以還是輔助最強(qiáng)！
當(dāng)然人家用SVN好好的，你換gitlab當(dāng)然不愛用，雖然SVN各種麻煩，但他熟悉了。如果大家不支持，可以去和領(lǐng)導(dǎo)談，寫一寫計(jì)劃書，整體運(yùn)維體系規(guī)劃這種。如果你真的有想法，領(lǐng)導(dǎo)也許真的對(duì)你的想法有興趣，但如果領(lǐng)導(dǎo)懶得看，那可以換下一家了，這家真的不值得付出，因?yàn)橥笥嗌己芡纯?。如果支持的不多，關(guān)注不到你（很常見，好多公司沒運(yùn)維主管，就CTO），那可以將計(jì)劃書拆分幾個(gè)小塊，一點(diǎn)點(diǎn)改革，盡量和效果關(guān)聯(lián)上。
例如現(xiàn)在要推廣kubernets，那你首先要研究明白kubernets，也要懂docker，找到痛點(diǎn)才行。再去說這個(gè)kubernets的好處，找到kubernets的特點(diǎn)，例如它的資源調(diào)度、故障遷移更有利于項(xiàng)目運(yùn)行，對(duì)公司效率的變化?；蛘咄矫尜N。一套測(cè)試環(huán)境可以省下xxxx錢，那數(shù)十個(gè)項(xiàng)目，一個(gè)月就可以節(jié)省xxx錢，寫的務(wù)實(shí)一點(diǎn)，效果還是很震撼的。
做任何工作不是只埋頭做，還要和領(lǐng)導(dǎo)多交流，我們應(yīng)該主動(dòng)打破上下級(jí)之間的沉默，將我們的想法講給里領(lǐng)導(dǎo)聽，獲得領(lǐng)導(dǎo)的想法，雖然很多事情小公司不注重，但你做了和沒做是兩碼事。你比別的同事多提出了一些概念，你在公司就是先驅(qū)者，大家會(huì)覺得你挺厲害，技術(shù)大牛，一直在推動(dòng)發(fā)展。這里講開發(fā)他們也不是傻子，devops人家都聽過的，隨意你推動(dòng)，大家都會(huì)歡迎的。職場(chǎng)之路困難與機(jī)遇并行。
3.3規(guī)矩
開發(fā)人員寫代碼的時(shí)候，都會(huì)探討一下怎么寫，出一個(gè)方案，畫一個(gè)流程圖，用什么技術(shù)。新臨時(shí)增加的需求也是如此，起碼接到的個(gè)人會(huì)先想好思路。
但到運(yùn)維這里好像就隨意起來了，加安全組直接通知下就添加了，備注隨意寫寫，當(dāng)對(duì)方不用的時(shí)候也忘記了刪除。“規(guī)矩”也是要建立的，這樣才能讓人信服，而不是誰都能指揮你，然后加出問題、改出問題了，鍋又到你身上。
當(dāng)然不能傻傻的和別人對(duì)著做，大家都討厭規(guī)矩太多，那要在方便的基礎(chǔ)上建立一些流程即可，例如申請(qǐng)白名單可以發(fā)一封申請(qǐng)郵件，備注一定要清晰明了，利用python腳本定時(shí)檢查采集安全組規(guī)則進(jìn)行檢查，防患于未然。
3.4運(yùn)維管理平臺(tái)
運(yùn)維自動(dòng)化平臺(tái)的建設(shè)本質(zhì)是運(yùn)維團(tuán)隊(duì)服務(wù)化能力的變現(xiàn)過程，它讓我們從大量重復(fù)無規(guī)律的人肉操作中解放出來，專注于運(yùn)維服務(wù)質(zhì)量的提升。
由于文章篇幅所限，就不和大家全面介紹整個(gè)自動(dòng)化平臺(tái)的設(shè)計(jì)思路，簡單說一下我個(gè)人的一些心得：
第一是循序漸進(jìn)的原則，在自動(dòng)化運(yùn)維體系建設(shè)過程中，我們首先可以構(gòu)建一個(gè)基礎(chǔ)的服務(wù)器批量操作平臺(tái)，先把一部分需要重復(fù)執(zhí)行的工作搬到平臺(tái)上來，再依據(jù)運(yùn)維的需求豐富這個(gè)操作平臺(tái)的功能和提升效率，最后把周邊的系統(tǒng)打通，相互對(duì)接，形成完整的自動(dòng)化運(yùn)維體系。
第二是考慮可擴(kuò)展性。設(shè)計(jì)系統(tǒng)的時(shí)候，功能或者設(shè)計(jì)方面可能不用考慮那么多，但是要考慮當(dāng)服務(wù)器數(shù)量發(fā)生比較大的擴(kuò)張時(shí)，系統(tǒng)是否還能支撐，比如數(shù)量級(jí)從十到百，或者上千了，這個(gè)系統(tǒng)是否還是可用的。
第三是以實(shí)用為目的。這在我們系統(tǒng)中也是有體現(xiàn)的?？梢钥紤]借鑒市面上比較成熟的工具進(jìn)行自研。為什么不建議直接使用呢？因?yàn)槟壳俺Ｒ姷拈_源運(yùn)維管理平臺(tái)并不是有團(tuán)隊(duì)專人維護(hù)，如果使用過程中出現(xiàn)問題，排查難度將非常高。當(dāng)然不可否認(rèn)的是參考的價(jià)值。所以建議優(yōu)先考慮開源方案加一部分二次開發(fā)。
