魅族的互聯(lián)網(wǎng)業(yè)務(wù)起步較早，從 2011 年開始，到 2014 年才真正轉(zhuǎn)變?yōu)橐患乙苿?dòng)互聯(lián)網(wǎng)公司。隨著業(yè)務(wù)的增長(zhǎng)，魅族的運(yùn)維架構(gòu)在不斷的變更優(yōu)化，運(yùn)維團(tuán)隊(duì)面臨著越來越大的挑戰(zhàn)，服務(wù)器規(guī)模從 2000 年只有 5 臺(tái)的規(guī)模擴(kuò)展到 2016 年超過了 6000 多臺(tái)。

[[195025]]

下面主要從三個(gè)方面介紹魅族基礎(chǔ)架構(gòu)的運(yùn)維之路：

• 發(fā)展歷程;
• 運(yùn)維體系實(shí)踐;
• 運(yùn)維的未來展望。

魅族運(yùn)維的艱難蛻變

這幾年，工程師圍繞質(zhì)量、效率、流程、成本展開運(yùn)維，并且發(fā)現(xiàn)工作中遇到的問題，慢慢由運(yùn)維轉(zhuǎn)化成技術(shù)運(yùn)營(yíng)，需要優(yōu)化工作流程，提高運(yùn)維的技術(shù)能力。這其中包括填坑、標(biāo)準(zhǔn)化，自動(dòng)化、流程化和數(shù)據(jù)化，以及對(duì)未來混合云運(yùn)營(yíng)的一個(gè)展望。

下面按照發(fā)展歷程中的各個(gè)時(shí)代進(jìn)行說明：

遠(yuǎn)古時(shí)代

2011 年，公司規(guī)模比較小，只有機(jī)柜 1 個(gè)，服務(wù)器 5 臺(tái)，業(yè)務(wù)線 2 條，主要存在的問題有：

• 機(jī)房穩(wěn)定性差。服務(wù)器經(jīng)常宕機(jī)，系統(tǒng)要重裝，這些需要人力支撐。

相應(yīng)的解決方法：在穩(wěn)定性方面，運(yùn)維團(tuán)隊(duì)有 IDC 的操作人員協(xié)助工程師做一些管理和操作，另外通過帶外的管理口對(duì)服務(wù)器做一些操作，對(duì)系統(tǒng)進(jìn)行重裝。

• 監(jiān)控造成的損失。服務(wù)器上線之后沒有及時(shí)地監(jiān)控，出現(xiàn)故障之后不能及時(shí)解決，業(yè)務(wù)的穩(wěn)定性得不到保障。

相應(yīng)的解決方法：一些自動(dòng)化的腳本，在自動(dòng)監(jiān)控方面早期部署了 Nagios Cacti，來監(jiān)控系統(tǒng)穩(wěn)定性，網(wǎng)絡(luò)以及業(yè)務(wù)穩(wěn)定性。

• 架構(gòu)單點(diǎn)。業(yè)務(wù)上線之后沒有部署高可用架構(gòu)，對(duì)業(yè)務(wù)的穩(wěn)定性有影響，比如官網(wǎng)、論壇等等。
• 相應(yīng)的解決方法：在架構(gòu)單點(diǎn)方面，主要靠人為來驅(qū)動(dòng)，推動(dòng)業(yè)務(wù)部署高可用架構(gòu)，提高業(yè)務(wù)的可用性。

石器時(shí)代

魅族逐步向移動(dòng)互聯(lián)網(wǎng)開始轉(zhuǎn)型，架構(gòu)如下：

IDC 還是 1 個(gè)，機(jī)柜增長(zhǎng)了 30 個(gè)，服務(wù)器和虛擬機(jī)的數(shù)量增長(zhǎng)了 800 臺(tái)，業(yè)務(wù)線拓展到 100 個(gè)，人力方面，運(yùn)維人員擴(kuò)展到了 12 個(gè)，存在的主要問題有：

• 機(jī)房存在著很多 IBM 的包箱、EMC 的存儲(chǔ)，運(yùn)維成本很高。在虛擬化方面，運(yùn)維團(tuán)隊(duì)使用的是 VMware vSphere 解決方案，它的管理和運(yùn)維成本比較高。

如何解決這個(gè)問題呢?跟大多數(shù)的互聯(lián)網(wǎng)公司一樣，魅族逐步使用 X86 服務(wù)器來代替，提高業(yè)務(wù)的穩(wěn)定性，節(jié)省了成本。

• 機(jī)房資源不足，擴(kuò)容難，以及資源管理問題。因?yàn)闃I(yè)務(wù)發(fā)展比較快，相應(yīng)的業(yè)務(wù)需求多且緊急，所以裝機(jī)和交付的速度完全跟不上業(yè)務(wù)的發(fā)展需要。

為了解決這個(gè)問題，運(yùn)維團(tuán)隊(duì)把主要業(yè)務(wù)分到多個(gè)機(jī)房部署，并且在各個(gè)機(jī)房部署冗余資源，除了滿足業(yè)務(wù)需求的同時(shí)還滿足一些計(jì)劃外的需求。另外，運(yùn)維團(tuán)隊(duì)在資源管理方面搭建了一個(gè) CMDB，來統(tǒng)一管理線上的資產(chǎn)，使得資源管理效率獲得很大提升。

• 網(wǎng)絡(luò)不穩(wěn)定，活動(dòng)日或者發(fā)布日的流量突增。面對(duì)這個(gè)問題，解決辦法首先是在硬件上更換核心網(wǎng)絡(luò)設(shè)備，配置上有所提升，保證在流量較大的時(shí)候，設(shè)備的承載方面沒有問題。

另外，在帶寬上做冗余，這樣在網(wǎng)絡(luò)流量突增的情況下，業(yè)務(wù)也不會(huì)因此造成影響。同時(shí)，網(wǎng)絡(luò)架構(gòu)也變成了 2.0 架構(gòu)，即多機(jī)房，在網(wǎng)絡(luò)層面使用虛擬化，大二層架構(gòu)。1.0 架構(gòu)是單機(jī)房，網(wǎng)絡(luò)層面沒有做虛擬化，使用的是 HSRP。

• DB 服務(wù)器的 IO 問題導(dǎo)致的業(yè)務(wù)壓力。早期 DB 使用的是 SAS 磁盤，讀寫頻繁的時(shí)候，就會(huì)帶來一些 IO 問題。

針對(duì)這一問題，運(yùn)維工程師對(duì) ssd 磁盤或者 pciessd 進(jìn)行測(cè)試，根據(jù)業(yè)務(wù)的特性為不同的業(yè)務(wù)配備 ssd 或者 pciessd 來滿足業(yè)務(wù)的 IO 需求。

批量操作和監(jiān)控不完善，以及監(jiān)控的覆蓋率問題。因?yàn)闃I(yè)務(wù)發(fā)展快，資源使用包括服務(wù)器的規(guī)模增多，給一些批量的操作帶來很大的人力成本。這時(shí)，工程師通過部署 Ansible 來做一些批量的操作。

而且監(jiān)控會(huì)聯(lián)動(dòng) CMDB，定時(shí)對(duì)線上運(yùn)營(yíng)中的機(jī)器做一個(gè)巡檢，巡檢到未加監(jiān)控的機(jī)器就會(huì)定時(shí)給相關(guān)人員發(fā)郵件，通知他們來解決監(jiān)控覆蓋率低的問題。

• 安全性低，主要體現(xiàn)在早期所有的業(yè)務(wù)員都可以登錄線上所有機(jī)器，沒有權(quán)限限制或者管理。另外一個(gè)是來自外網(wǎng)的攻擊。

針對(duì)這個(gè)情況，工程師結(jié)合帳戶管理平臺(tái) CMDB 對(duì)用戶做一些權(quán)限的劃分。比如某個(gè)賬號(hào)在 CMDB 上只能訪問哪幾個(gè)業(yè)務(wù)，只能登陸這幾個(gè)業(yè)務(wù)的機(jī)器。而且還有一個(gè)操作的審計(jì)，后面還可以跟蹤。

青銅時(shí)代

伴隨著上述問題的解決，魅族進(jìn)入了青銅時(shí)代：兩地三中心。具體是機(jī)柜擴(kuò)展到 150 個(gè)，服務(wù)器擴(kuò)展到 4000 臺(tái)，業(yè)務(wù)線也發(fā)展到 200 多條。在人力方面，系統(tǒng)有 35 個(gè)業(yè)務(wù)人員來支撐。主要問題包括：

• 標(biāo)準(zhǔn)化率低，維護(hù)成本越來越高。針對(duì)這一點(diǎn)，運(yùn)維團(tuán)隊(duì)對(duì)標(biāo)準(zhǔn)化進(jìn)行了梳理，包括軟件標(biāo)準(zhǔn)化、系統(tǒng)標(biāo)準(zhǔn)化和硬件標(biāo)準(zhǔn)化等。
• 在系統(tǒng)標(biāo)準(zhǔn)化方面，工程師開發(fā)了巡檢平臺(tái)，主要從系統(tǒng)常規(guī)、系統(tǒng)安全、系統(tǒng)內(nèi)核等幾個(gè)維度定時(shí)進(jìn)行巡檢，對(duì)出現(xiàn)問題的機(jī)器進(jìn)行整改，確保線上標(biāo)準(zhǔn)化覆蓋率 100%。
• 業(yè)務(wù)架構(gòu)單點(diǎn)的問題。因?yàn)闃I(yè)務(wù)發(fā)展比較迅速，架構(gòu)單點(diǎn)的情況比較嚴(yán)重。解決方案是人工推動(dòng)，先梳理現(xiàn)有的單點(diǎn)架構(gòu)業(yè)務(wù)，然后去部署高可用架構(gòu)。
• 此時(shí)，運(yùn)維團(tuán)隊(duì)在架構(gòu)上做冗余，部署兩地三中心，當(dāng)單個(gè)機(jī)房出現(xiàn)故障的時(shí)候，業(yè)務(wù)的可用性可以得到保障。這時(shí)架構(gòu)進(jìn)入 3.0 架構(gòu)，使用三網(wǎng)分離，DCI 增加了專線，流量?jī)?yōu)先專線，專線出問題后再轉(zhuǎn)到 VPN。
• 供應(yīng)商單一。這個(gè)供應(yīng)商就是服務(wù)器供應(yīng)商，還有網(wǎng)絡(luò)設(shè)備供應(yīng)商，因?yàn)楣?yīng)商單一會(huì)帶來成本和定制化方面的問題。
• 所以，運(yùn)維團(tuán)隊(duì)先建立了一套自己的運(yùn)維設(shè)置標(biāo)準(zhǔn)，然后引入多個(gè)廠商來檢測(cè)它的兼容性、穩(wěn)定性，以及業(yè)務(wù)系統(tǒng)也是聯(lián)系多個(gè)廠商，來建立標(biāo)準(zhǔn)。
• 與此同時(shí)，也會(huì)制定 SLA 標(biāo)準(zhǔn)、定制化標(biāo)準(zhǔn)，如后續(xù)有新的采購(gòu)需求，都需要按照此標(biāo)準(zhǔn)執(zhí)行。
• 配置管理準(zhǔn)確性低。服務(wù)器從上線到下線，它的狀態(tài)改變?cè)诹鞒坦芾碇袥]有很好的解決方案，導(dǎo)致現(xiàn)有的梳理不準(zhǔn)確。
• 針對(duì)這個(gè)情況，運(yùn)維團(tuán)隊(duì)首先建立了一整套的服務(wù)器生命周期管理流程，從服務(wù)器的引入、生產(chǎn)、運(yùn)營(yíng)、下線等來確保 CMDB 數(shù)據(jù)準(zhǔn)確性，并且會(huì)結(jié)合一個(gè)工單平臺(tái)，該工單平臺(tái)會(huì)跟 CMDB 進(jìn)行對(duì)接。
• 比如啟動(dòng)開發(fā)的時(shí)候，工程師會(huì)發(fā)起 CMDB 的業(yè)務(wù)數(shù)，還有所在部門、產(chǎn)品線，最后當(dāng)整個(gè)工單走完時(shí)，CMDB 會(huì)自動(dòng)去更改，狀態(tài)也會(huì)由待運(yùn)營(yíng)狀態(tài)改變?yōu)檫\(yùn)營(yíng)中，整個(gè)過程全部是全自動(dòng)的，不需要人工參與。
• 業(yè)務(wù)的突增造成機(jī)房規(guī)模的突增。因?yàn)轺茸逭讲饺牖ヂ?lián)網(wǎng)時(shí)代，業(yè)務(wù)發(fā)展迅猛，此時(shí)面對(duì)業(yè)務(wù)的資源需求，不能及時(shí)交付。
• 解決方案是由原來的 cobbler 升級(jí)至裝機(jī)平臺(tái)，轉(zhuǎn)化為無人職守安裝，裝機(jī)平臺(tái)和 CMDB 對(duì)接，并在各個(gè)機(jī)房保持一定的資源冗余率，以滿足業(yè)務(wù)計(jì)劃外的資源需求。后期，工程師使用容量管理對(duì)業(yè)務(wù)機(jī)器的資源使用情況進(jìn)行審核。
• 故障多樣性。在供應(yīng)商多的情況下，由于每個(gè)廠商的配件可能不一樣，故障后的日志收集方案不一樣，導(dǎo)致故障發(fā)生時(shí)需要定義各個(gè)廠商的日志收集方式、維修人員授權(quán)等等操作，造成太多的溝通成本，這在效率維度也是一個(gè)痛點(diǎn)。
• 針對(duì)這個(gè)問題，工程師統(tǒng)一了各廠商的日志收集方式，在業(yè)務(wù)高可用方面，部署高可用架構(gòu);當(dāng)發(fā)生故障的時(shí)候，無需和業(yè)務(wù)進(jìn)行溝通，直接關(guān)機(jī)進(jìn)行硬件的維修操作。接著，工程師按月對(duì)故障進(jìn)行分析，并建立知識(shí)庫(kù)，后續(xù)對(duì)出現(xiàn)的這一類故障可以快速進(jìn)行處理。

鐵器時(shí)代

鐵器時(shí)代從 2016 年 1 月份到現(xiàn)在，魅族的業(yè)務(wù)仍呈增長(zhǎng)趨勢(shì)?，F(xiàn)在的規(guī)模，IDC 有多個(gè)，機(jī)柜大約 200 個(gè)，服務(wù)器數(shù)量超過了 6000 臺(tái)，業(yè)務(wù)線大約 200 個(gè)，平臺(tái)業(yè)務(wù)人員增長(zhǎng)到 43 個(gè)。這個(gè)時(shí)代，問題還是有很多：

• 對(duì)于監(jiān)控和告警的數(shù)據(jù)，一直沒有量化數(shù)據(jù)。當(dāng)然也不可能達(dá)到可視化的一個(gè)效果，比如月度短信告警數(shù)量統(tǒng)計(jì)時(shí)，無法在平臺(tái)維度直接統(tǒng)計(jì)數(shù)據(jù)和展示數(shù)據(jù)，進(jìn)而折算短信成本。

針對(duì)這個(gè)情況，運(yùn)維團(tuán)隊(duì)做了統(tǒng)一的告警平臺(tái)，并與基礎(chǔ)監(jiān)控和業(yè)務(wù)監(jiān)控結(jié)合。各個(gè)平臺(tái)告警數(shù)據(jù)統(tǒng)一從告警平臺(tái)進(jìn)行收斂、匹配策略后，在發(fā)送給相應(yīng)的用戶，這樣告警數(shù)據(jù)對(duì)比各個(gè)平臺(tái)單獨(dú)的告警數(shù)據(jù)就會(huì)減少很多，一方面減少了告警風(fēng)暴，另一方面告警數(shù)據(jù)可以在平臺(tái)進(jìn)行展示和統(tǒng)計(jì)，提高了工作效率。

• 機(jī)型套餐多，業(yè)務(wù)需求個(gè)性化。根據(jù)線上的業(yè)務(wù)特性，比如說高 IO 類、一線、在線存儲(chǔ)類、熱點(diǎn)類，工程師對(duì)線上的業(yè)務(wù)做一個(gè)分析，最后讓機(jī)型跟業(yè)務(wù)的特性做整合。

另外，工程師還會(huì)對(duì) CMDB 占比較小的業(yè)務(wù)做整合，比如說 A 業(yè)務(wù) 100 臺(tái)，B 業(yè)務(wù)只有 2 臺(tái)，對(duì)于這種占比小的 B 業(yè)務(wù)，可以根據(jù)業(yè)務(wù)網(wǎng)做一個(gè)業(yè)務(wù)特性，劃定為某一個(gè)業(yè)務(wù)的特性，然后跟不同的機(jī)型進(jìn)行整合。

• 業(yè)務(wù)成本高，ROI無法量化，比如某個(gè)業(yè)務(wù)投入的人力成本和開發(fā)成本遠(yuǎn)遠(yuǎn)大于它的產(chǎn)出成本這樣的情況。

針對(duì)這個(gè)問題，工程師的處理方式分為兩個(gè)維度：一是使用容量系統(tǒng)對(duì)資源進(jìn)行使用率的考核，對(duì)于資源使用率較低的機(jī)器，推動(dòng)業(yè)務(wù)進(jìn)行業(yè)務(wù)混布，或者業(yè)務(wù)遷移至配置較低的機(jī)器上面。二是建立營(yíng)收體系，搭建營(yíng)收平臺(tái)，統(tǒng)計(jì)各個(gè)業(yè)務(wù)的運(yùn)營(yíng)成本和營(yíng)收成本。

• 工作流程化。前面提到建立了服務(wù)器生命周期管理的一整套流程，但是運(yùn)維團(tuán)隊(duì)沒有一個(gè)很好的平臺(tái)管理進(jìn)行任務(wù)進(jìn)度查看，很多事情還是靠郵件溝通，這帶來的人力成本很高。

所以，建立了工單平臺(tái)，它完全遵循服務(wù)器生命周期的那一套流程，用于記錄各個(gè)工單的流程、處理情況、處理人、耗時(shí)等等，同時(shí)也方便后續(xù)的工單跟蹤情況。

而且工單平臺(tái)和 CMDB 對(duì)接，申請(qǐng)者提交需求的時(shí)候，會(huì)拉取 CMDB 業(yè)務(wù)樹和部門進(jìn)行填寫，當(dāng)工單完結(jié)的時(shí)候，會(huì)自動(dòng)掛載業(yè)務(wù)以及修改服務(wù)器運(yùn)營(yíng)狀態(tài)，還有對(duì)此業(yè)務(wù)的運(yùn)維人員可以進(jìn)行自動(dòng)填寫的功能，大大提高了工作效率。

• 資源利用率，就是使用容量平臺(tái)來監(jiān)控各個(gè)產(chǎn)品線的資源使用情況，然后對(duì)資源使用率較低的業(yè)務(wù)進(jìn)行混布或者遷移方案。
• 預(yù)案管理。運(yùn)維團(tuán)隊(duì)部署兩地三中心，在多個(gè)數(shù)據(jù)中心部署業(yè)務(wù)，當(dāng)單個(gè)數(shù)據(jù)中心出現(xiàn)故障的時(shí)候，可以快速切換到別的 IDC 服務(wù)器，確保服務(wù)正常的運(yùn)行。另外也會(huì)對(duì)專線進(jìn)行定時(shí)切換演練，以測(cè)試專線切換后是否有問題發(fā)生。

上面講述了從 2011 年到現(xiàn)在，整個(gè)歷程中出現(xiàn)的問題，運(yùn)維團(tuán)隊(duì)是如何解決的。還需要詳細(xì)說明兩點(diǎn)，一個(gè)是業(yè)務(wù)的增長(zhǎng)從 5 臺(tái)到 6000 臺(tái)，速度很快，這很考驗(yàn)基礎(chǔ)設(shè)施的建設(shè)。

另外一個(gè)是很考驗(yàn)交付效率能力，網(wǎng)絡(luò)架構(gòu)從 1.0 升級(jí)到 3.0，用裝機(jī)平臺(tái)解決工單系統(tǒng)，跟CMDB聯(lián)動(dòng)，降低我們的操作頻率。

在成本控制方面，對(duì)于一個(gè)有海量互聯(lián)網(wǎng)業(yè)務(wù)的公司來說，微優(yōu)化可以節(jié)省很多成本，運(yùn)維團(tuán)隊(duì)主要從三個(gè)方面進(jìn)行成本控制：

• 資源使用率;
• 供應(yīng)商方面;
• 內(nèi)部營(yíng)收。

魅族運(yùn)維體系實(shí)踐

魅族的運(yùn)維體系跟大部分的互聯(lián)網(wǎng)公司一樣，采用多級(jí)分層模式，所有業(yè)務(wù)和 DB 都部署了高可用架構(gòu)，技術(shù)平臺(tái)跟業(yè)務(wù)平臺(tái)也有很多的系統(tǒng)，比如發(fā)布平臺(tái)、監(jiān)控平臺(tái)等等。

在自動(dòng)化過程中，運(yùn)維團(tuán)隊(duì)根據(jù)遇到的情況定義優(yōu)先級(jí)，進(jìn)行任務(wù)分解，先做最容易的，能提高效率的點(diǎn)，再做整合，通過各個(gè)子系統(tǒng)的整合，形成適合自己的自動(dòng)化運(yùn)維框架。下面挑選幾個(gè)比較主要的系統(tǒng)談一下：

監(jiān)控系統(tǒng)

監(jiān)控系統(tǒng)采用 server-proxy-client 架構(gòu)，Client 端的 Agent 會(huì)定時(shí)主動(dòng)上報(bào)數(shù)據(jù)至 proxy 中做臨時(shí)緩存，proxy 會(huì)定時(shí)將臨時(shí)緩存的數(shù)據(jù)上報(bào)給 server 端存儲(chǔ)在數(shù)據(jù)庫(kù)，進(jìn)而將數(shù)據(jù)展示在 Zabbix 界面。

對(duì)監(jiān)控模板標(biāo)準(zhǔn)化，針對(duì)不同的業(yè)務(wù)定義不同的模板，然后在 Zabbix 平臺(tái)定義告警匹配的動(dòng)作，每個(gè)業(yè)務(wù)的運(yùn)維/開發(fā)人員接收自己負(fù)責(zé)業(yè)務(wù)的告警。

監(jiān)控覆蓋率方面會(huì)先發(fā)郵件給相應(yīng)的人員去處理問題，以保證覆蓋率由早期比較低的一個(gè)百分比到達(dá)一個(gè)百分百的狀態(tài)，后續(xù)也會(huì)每天巡檢，讓覆蓋率一直維持在百分之百的狀態(tài)。

統(tǒng)一告警平臺(tái)

之前，所有的告警信息都從 Zabbix 平臺(tái)發(fā)出，服務(wù)器出現(xiàn)故障后，短信和郵件告警就會(huì)很多，如果不處理，則會(huì)一直告警，出現(xiàn)短信轟炸。針對(duì)此情況，運(yùn)維團(tuán)隊(duì)開發(fā)了告警平臺(tái)。

它的工作機(jī)制是：在統(tǒng)一告警平臺(tái)中，將服務(wù)的匹配策略和故障合并，當(dāng)告警信息從 Zabbix 生成后，通過預(yù)先設(shè)定的腳本發(fā)送給告警平臺(tái)，在觸發(fā)策略，最后故障合并后，在觸發(fā)告警升級(jí)策略，即告警首先通知接收人，如 10 分鐘沒處理，則升級(jí)給團(tuán)隊(duì)處理。

運(yùn)維團(tuán)隊(duì)通過統(tǒng)一告警平臺(tái)降低了運(yùn)營(yíng)成本。從上圖可以看到，左邊是應(yīng)用級(jí)，應(yīng)用級(jí)包括 CPU、內(nèi)存等，右邊根據(jù)業(yè)務(wù)排序，哪個(gè)業(yè)務(wù)按月、按天，這塊后續(xù)需要優(yōu)化。下面是一個(gè)月的尾天，哪天的告警比較多，可以根據(jù)這天的情況估計(jì)一下，保障后面的故障不會(huì)發(fā)生。

工單平臺(tái)

工單平臺(tái)包括服務(wù)器所有流程，和自定義功能，可以減少跟開發(fā)同事的溝通成本，開發(fā)只需要運(yùn)維人員提需求，不同的需求使用不同的節(jié)點(diǎn)，直接查看工單的處理狀態(tài)。

比如說 OP 審核節(jié)點(diǎn)，以及開發(fā)審核節(jié)點(diǎn)，最后整個(gè)工單流程完成之后，所有的產(chǎn)品實(shí)現(xiàn)自動(dòng)化。生命周期管理自動(dòng)化，工單流程的可視化、可追蹤。

巡檢平臺(tái)

早期，運(yùn)維團(tuán)隊(duì)出現(xiàn)過內(nèi)核參數(shù)設(shè)置未生效的問題，iptables 處于打開狀態(tài)，導(dǎo)致宿主機(jī)在大流量和高并發(fā)量的情況下網(wǎng)卡容易丟包，影響多個(gè)業(yè)務(wù)的穩(wěn)定性。

工程師意識(shí)到在 OS 層，做定制化和標(biāo)準(zhǔn)化，通過巡檢系統(tǒng)發(fā)現(xiàn)非標(biāo)準(zhǔn)機(jī)器，定時(shí)整改。系統(tǒng)巡檢主要包括系統(tǒng)初始化檢測(cè)、系統(tǒng)常規(guī)檢測(cè)、系統(tǒng)內(nèi)核檢測(cè)、系統(tǒng)安全檢測(cè)和下線檢測(cè)。巡檢平臺(tái)可以按季、按月生成一個(gè)巡檢標(biāo)準(zhǔn)率，建立標(biāo)準(zhǔn)體系，提升工作效率。

更安全的堡壘機(jī)

如上圖的堡壘機(jī)架構(gòu)是在不同機(jī)房部署主備堡壘機(jī)，兩臺(tái)堡壘機(jī)之間的數(shù)據(jù)是同步的，用戶可以申請(qǐng)軟件或者硬件的 Token，然后通過 RSA 認(rèn)證登錄到堡壘機(jī)。

此時(shí) IDC 賬戶管理平臺(tái)會(huì)對(duì)登錄用戶進(jìn)行審計(jì)把控，包括用戶管理、登錄記錄、分配權(quán)限、操作記錄等等，最后登錄到服務(wù)器上。這樣可以有效提高線上系統(tǒng)的安全。

流程管理

運(yùn)維團(tuán)隊(duì)建立了整套的服務(wù)器生命周期管理，從產(chǎn)品，服務(wù)器的引入，到生產(chǎn)、運(yùn)營(yíng)、下線，分為幾類：資源交付類、資源調(diào)動(dòng)類還有一個(gè)生命周期末端流程。

結(jié)合工單平臺(tái)，它已經(jīng)正式線上運(yùn)行了，這一套流程建立之后，OP 跟開發(fā)之間的溝通成本，節(jié)約的時(shí)間已經(jīng)大約是之前的 2 倍多了。

容量系統(tǒng)

所有數(shù)據(jù)都來自于監(jiān)控系統(tǒng)，比如 CPU、內(nèi)存、IO 能力，工程師通過容量系統(tǒng)調(diào)取數(shù)據(jù)作一些分析，對(duì)使用率比較低的功能做一些整改，從上面可以看到閱讀或者按天的資源使用率情況。

另外，工程師也會(huì)做業(yè)務(wù)成本的考核，算是一個(gè)附加功能，主要是做了一個(gè)內(nèi)部營(yíng)收平臺(tái)，對(duì)內(nèi)的各個(gè)業(yè)務(wù)通過一些核算來關(guān)注每一個(gè)業(yè)務(wù)的運(yùn)營(yíng)成本和產(chǎn)出。這樣每個(gè)部門的成本關(guān)注度也相應(yīng)提升了五倍。

魅族運(yùn)維未來展望

魅族希望內(nèi)外兼修，打造精益化運(yùn)營(yíng)，通過運(yùn)維自動(dòng)化、監(jiān)控自動(dòng)化、安全管理、流程管理來提高服務(wù)質(zhì)量。同時(shí)，工程師也會(huì)協(xié)同開發(fā)平臺(tái)，大數(shù)據(jù)平臺(tái)，為業(yè)務(wù)提供更優(yōu)的服務(wù)。

本文來自魅族云平臺(tái)系統(tǒng)架構(gòu)師梁鵬在聽云應(yīng)用性能管理大講堂—《魅族基礎(chǔ)架構(gòu)運(yùn)維之路》分享總結(jié)，原文有刪減。

[[195029]]

梁鵬

魅族云平臺(tái)系統(tǒng)架構(gòu)師梁鵬

來自魅族云平臺(tái)，主要負(fù)責(zé)魅族系統(tǒng)運(yùn)維、平臺(tái)建設(shè)和自動(dòng)化的工作。