這里針對的是大中小型項目的業(yè)務系統(tǒng)運維架構(gòu)的設計，非互聯(lián)網(wǎng)型項目，一些個人經(jīng)驗和思路，拋磚引玉，供參考。

背景

對一般性的運維來說，自己應該是接觸幾年，一二三線多個城市，政務互聯(lián)網(wǎng)行業(yè)等都有，服務器基數(shù)在幾臺以幾百臺不等，業(yè)務微服務規(guī)模在100到幾千不等，本身并不是專業(yè)做運維的（比如數(shù)據(jù)庫DBA、網(wǎng)絡等，這些有專業(yè)人處理），偏向于業(yè)務服務模塊的運維設計管理，以下為一些設計經(jīng)驗。

概述

對于長期運行的業(yè)務，有好的運維工具，更有利于業(yè)務的穩(wěn)定。一般來說，業(yè)務性的運維管理從幾個維度，主要是IaaS層，中間件層，業(yè)務層，運行狀態(tài)層幾個進行的監(jiān)控管理，結(jié)合人工，手工，自動化能力角度進行設計，去掉重復的手工和低階的運維，使業(yè)務運維偏向于高階的思考，提升整個運維的管理能力，整體思路從以下幾點，我有我思：

以上幾個點為基礎(chǔ)的能力，中間還有很多，這里偏向于設計，具體細節(jié)由專業(yè)工程師去實施即可。

架構(gòu)設計

這里是整體運維管理的架構(gòu)設計，從多個角度和自動化能力的管理，架構(gòu)如下：

針對大的方向上面，不同的團隊和業(yè)務場景會有不同的業(yè)務方案。

基本上當前主要用到工具為以下工具，其它主流性的，用起來并不覺得多順手，比如藍鯨，自己偏向于腳本型管理，相對比較方便，主要使用技術(shù)工具如下：

基礎(chǔ)環(huán)境搭建

這里根據(jù)本身的業(yè)務場景需求進行取舍，并不是一下就要上全套，畢竟資源等各個方面會有一定的限制，這里基礎(chǔ)環(huán)境是整體的基礎(chǔ)，包括以下幾個點：

上面的工具注意配置下unit自動啟動，當然也可以使用容器，但是過程發(fā)現(xiàn)，有的時候容器并不是特別可靠。

自動化操作引擎搭建

自動化操作是所有的運維管理的基礎(chǔ)能力，也是一個統(tǒng)一的管理思路。這里的需要安裝好jenkins和gitea，這個是基礎(chǔ)。

自動化操作主要是結(jié)合pipeline+Ansible進行管理，通過ansible的host進行的各個服務主機的操作，這里建議的變量是存放在host當中，針對不同的業(yè)務場景替換host即可，在下次另一個環(huán)境的時候，直接導入jenkins備份文件即可。

ansible的hosts可配置比較多的變量，這些方便多業(yè)務場景的改變和運維環(huán)境的遷移。

運維日志的可視化

所有的運維工具還有業(yè)務運行都需要把日志文件進行可視化統(tǒng)一管理顯示，前期需要先搭建好日志平臺，這里主要是偏向于ELK+Kafka，小項目PlumeLog替換掉kafka更合適，因為他也可以不使用kafka，比如redis等輕量型隊列，不過還是比較推薦kafka，穩(wěn)定性還有日志收集一流，裝個單節(jié)點就可以。

也可以針對PlumeLog進行二次改造，之前就是進行了改造，畢竟Kibana的學習成本還有es的學習成本并不是每個運維人員會做的。

工單管理工具的安裝

這里的管理工具指的是Zbox，即將各個工單進行安裝配置和跟進，這里建議是結(jié)合Dingtalk一起，新版本Zbox對這塊的支持挺好的，可實時跟進，便于項目經(jīng)理和運維經(jīng)理實時跟進工單的處理狀態(tài)，這里比較推薦的，省去很多無謂的溝通成本。

當然，有些是不需要這個模塊，比如一些比較小的項目，但是中大項目或者需要長期跟進的話，建議這塊，也可以采購，之前采購過幾款，費用不少，但是效果貌似還沒有Zbox好。

規(guī)則引擎安裝

這里規(guī)則引擎主要是prometheus（貌似目前還沒有發(fā)現(xiàn)比這個更好的），比較輕量級，安裝起來也比較快，也可以安裝grafana，這里我自己不太喜歡grafana可視化，有空細調(diào)整的話也可以把grafana做得挺好的，但是自己一般是在它的官網(wǎng)上找到模板，沒什么空去看這個“好看”的大屏，平臺工具多就意味著入口很多，這也很麻煩，所以針對于自己來說，會更關(guān)注Dingtalk的信息，因為可以把這些狀態(tài)統(tǒng)一發(fā)到上面，如果是內(nèi)網(wǎng)不能使用Dingtalk的，Grafana是一個不錯的選擇，或者說Prometheus的Alerts也可以，預警信息也是一目了然的。

運維采集監(jiān)控

監(jiān)控采集功能即是上面工具的使用管理，主要的設計思路如下：

環(huán)境狀態(tài)可視化

環(huán)境指的是服務器、中間件、容器，這里集成的主要是prometheus的功能和node-exporter等，這些使用起來較為方便，基本上會把服務器的基礎(chǔ)狀態(tài)進行采集管理，普通的狀態(tài)基本上會滿足，包括中間件層和容器層也一樣，基于exporter進行采集， 輸入到Prometheus當中即可，這里rule規(guī)則主要引用git進行版本管理，同時使用prometheus的熱加載管理，結(jié)合jenkins+ansible腳本進行在線跟進更新發(fā)布。

rule腳本的管理根據(jù)運維的需求進行調(diào)整更新即可，可定時在線更新。這里的rules注意下規(guī)則的管理，一不小心有可能會造成N多的信息爆炸，那也是很恐怖的事情。

這里注意一點是，kuernates內(nèi)部一般也會安裝1個prometheus會更好地管理，注意不要跟物理機上的prometheus沖突就可以，當然，你也可以只用1個，但是k8s里的規(guī)則更新貌似不太好處理，會比較麻煩，之前的處理思路是jenkinsfile重新發(fā)布一下proemtheus，然后日志數(shù)據(jù)持久化。

業(yè)務運行狀態(tài)的監(jiān)控采集

這里主要分為兩部分，一部分是前端，另一部分是后端，還有一部分是關(guān)注的業(yè)務指標。

這里前端的采集主要是nginx的采集，處理好日志的json腳本，然后通過filebeat進行采集發(fā)送到kafka中，這里的數(shù)據(jù)量大的話，推薦kafka集群，同步通過elk進行展示，這里展示的效果因人而異，實際的效果可以很酷，但是我一般比較喜歡列表展示日志。

然后就是后端數(shù)據(jù)的處理，也可以使用filebeat進行容器采集，但是k8s也會帶有日志系統(tǒng)進行發(fā)送也可以，之前沒怎么用過，對于后端的數(shù)據(jù)，使用的是springboot的配置，進行動態(tài)的環(huán)境變量處理，即配置logback-spring.xml配置，添加多環(huán)境即可，這里有一些會考慮sky，可以結(jié)合鏈路跟蹤還有前后端請求狀態(tài)，這里也比較偏向于業(yè)務項目。

有的時候，工具太重了會比較影響，所以在業(yè)務日志采集這里，會采集關(guān)注的業(yè)務服務日志，并不是所有的都會采集。另一種方式是使用容器的nfs映射能力，映射到本地存儲，進行二次轉(zhuǎn)移，這些主要是看項目情況，大項目的采集會比較多，同時造成很多日志壓力，配置也比較高。

最后有一部分是業(yè)務指標的問題，業(yè)務指標的產(chǎn)生并不像日志那樣，會觸發(fā)錯誤。這里推薦根據(jù)業(yè)務情況然后進行一定的邏輯判斷，這里用得比較多的方式是定時的業(yè)務計算進行業(yè)務指標輸出，放到中間庫里面（比如mysql），觸發(fā)自動化定時巡檢獲取到，業(yè)務指標的監(jiān)控偏向于業(yè)務運行時的跟進。

運行狀態(tài)巡檢管理

運行狀態(tài)巡檢是一個每日進行的工具，比如異常容器有哪些，異常的nodes有些，異常的鏈接還有端口是否開通等，一些重復性的工作而且監(jiān)控工具無法觸達到部分，可以通過pipeline+ansible結(jié)合進行自定義處理，比較個性化，也是有必要的。

ansible運行的結(jié)果是可以輸出json的，這個方式更好的匯總的集成平臺上面（集成平臺這個是基于springboot開發(fā)的一個集成系統(tǒng)，比如簡單），用于收集一些運行時狀態(tài)，包括異常的統(tǒng)計，巡檢的情況反饋等，便于下面進行周日報的輸出。

運維管理平臺維護

維護主要包括腳本的管理和更新維護，巡檢之后進行的數(shù)據(jù)匯總和匯報，還有過程工單的跟進管理。

腳本的管理和維護

這有點個人喜好，為什么不喜歡使用一些管理平臺（比如藍鯨、ansible tower）即是如此，沒有統(tǒng)一的運維腳本管理，包括版本的管理，操作人員的審計，權(quán)限的配置管理等，對于上面的運行來說，過程有一套腳本可個性化的配置，是有這個必要的。

這里的維護主要是結(jié)合git版本管理進行，通過pipeline來進行腳本進行任務的編排管理，基于jenkins的調(diào)度和模塊化處理，基本上是滿足平時的90%的管理了，平時10%的可能遇到的機率比較少，另外可移交到人工管理上。

周日報的匯總管理

匯報機制和統(tǒng)計機制是運維改進的一個保障，通過統(tǒng)計發(fā)現(xiàn)問題頻率高的地方和影響業(yè)務地方。在收集到json數(shù)據(jù)之后，進行數(shù)據(jù)的統(tǒng)計分析管理，然后通過springboot自定義開發(fā)，獲取到統(tǒng)計結(jié)果，自定義周期發(fā)送出統(tǒng)計結(jié)果，可按天、周、季、年等方式。

這里的開發(fā)難度并不是特別大，實際也可以通過pipeline+groovy腳本進行統(tǒng)計處理，但是這個必要性并不是特別大，而且安全性不是很高，成本略高，建議寫個集成平臺程序就可。

過程工單的管理跟進

管理制度和過程主要還是看團隊的習慣還有實際情況，這里提的一個能力是工單的跟進集成，主要是zbox+dingtalk處理，然后進行匯總。

但是這里注意的是建議不要使用外部郵箱，因為發(fā)送記錄會存在外部郵箱一份，而且是運維內(nèi)容，這比較不安全，當然也可以申請內(nèi)部郵箱，這樣會更安心一些。

總結(jié)

以上為業(yè)務系統(tǒng)進行的運維管理架構(gòu)設計，偏向于應用層，主要目標是達到可跟進，可管理，自動化等能力。以上為一些經(jīng)驗參考設計。