楊經(jīng)營

58到家運(yùn)維專家

• 多年互聯(lián)網(wǎng)運(yùn)維經(jīng)驗(yàn)，2015年加入58到家，精通Linux操作系統(tǒng)，見證了58到家運(yùn)維體系從0到1的建設(shè)，主要負(fù)責(zé)運(yùn)維自動(dòng)化、平臺(tái)化在58到家的應(yīng)用及推進(jìn)工作。

• 現(xiàn)任58到家技術(shù)委員會(huì)成員，負(fù)責(zé)58到家運(yùn)維體系整體發(fā)展方向與技術(shù)選取。
  

近幾年公有云已日趨成熟、穩(wěn)定，成為很多中小型互聯(lián)網(wǎng)公司的首選，其成本、易維護(hù)、輕資產(chǎn)、可靠性、基礎(chǔ)設(shè)施、技術(shù)支持這幾方面公有云和傳統(tǒng)IDC相比有著獨(dú)特的優(yōu)勢，尤其是當(dāng)公司整體資源體量較小（硬件IDC成本在100萬/年以下）時(shí)，該優(yōu)勢會(huì)非常明顯。

4年前，2016年初58到家決定All in 公有云。

2015年10月份，58到家獲得阿里、平安、KKR聯(lián)合投資，到家各項(xiàng)業(yè)務(wù)取得了飛速的發(fā)展，經(jīng)58到家技術(shù)中心管理層決策，58到家正式開啟了由IDC機(jī)房遷移至公有云的"凌云"之路。

從計(jì)劃遷移，到IDC機(jī)房-公有云專線打通、公有云全量部署線上資源（服務(wù)器、數(shù)據(jù)庫），筆者有幸全程參與并作為運(yùn)維組的接口人推進(jìn)實(shí)施，整體的架構(gòu)遷移《從IDC到云端架構(gòu)遷移之路》有詳細(xì)記載。

有一點(diǎn)要說明的是對(duì)于WEB站點(diǎn)的遷移，運(yùn)維內(nèi)部采用的基于Nginx upstream模塊實(shí)現(xiàn)逐步切流量至云端服務(wù)，相對(duì)于萬網(wǎng)、DNSPod商業(yè)DNS的權(quán)重調(diào)整方式來說，更加符合我們58到家當(dāng)時(shí)的遷移需求，做到了真正的平滑、極速切換和回退，解決了運(yùn)營商緩存的難題。

凌云項(xiàng)目從基礎(chǔ)資源的準(zhǔn)備，到線上環(huán)境遷移完成，歷時(shí)114天，涉及2T+數(shù)據(jù)（不包含大數(shù)據(jù)），遷移的服務(wù)160+，涉及數(shù)據(jù)庫70+，全體的技術(shù)同學(xué)投入到了該歷史性的項(xiàng)目中，相信每一個(gè)參與其中的戰(zhàn)友必定收獲滿滿。

凌云項(xiàng)目結(jié)束后，58到家正式開啟了基于公有云的技術(shù)升級(jí)之路，這其中也包含了運(yùn)維，對(duì)于機(jī)器、資源、域名、云端各項(xiàng)服務(wù)，云端都能夠?qū)崿F(xiàn)快速部署、實(shí)施和交付，這個(gè)是云的明顯優(yōu)勢。

但是隨之而來的，我們也面臨了很多問題：如2016年上半年遷云不久即被我們遇到的多年不遇的公有云城際網(wǎng)出口故障，導(dǎo)致業(yè)務(wù)中斷2小時(shí)以上，到家核心庫使用的havip產(chǎn)品問題導(dǎo)致數(shù)據(jù)庫連續(xù)2小時(shí)以上的故障，BI使用的服務(wù)器的性能一直在報(bào)瓶頸，價(jià)格成本的增長與我們的預(yù)期變化較大，從初次部署時(shí)月總費(fèi)用到價(jià)格翻倍只用了幾個(gè)月的時(shí)間（梳理清費(fèi)用都去哪兒了、誰花的錢最多需要一周甚至更長時(shí)間）。

當(dāng)時(shí)運(yùn)維3人，RD研發(fā)150+人，運(yùn)維每天面對(duì)的都是重復(fù)性的需求申請(qǐng)、各種線上問題、資源查詢等，基本處于被動(dòng)應(yīng)對(duì)、救火的階段，很多資產(chǎn)、申請(qǐng)都不可追溯甚至無主，某個(gè)服務(wù)的交接、遷移涉及梳理、確認(rèn)時(shí)，效率非常低，運(yùn)維內(nèi)部的資產(chǎn)維護(hù)還是基于excel模式，如下圖所示：

基于上述狀況，運(yùn)維需要打造運(yùn)維平臺(tái)來為我們整體的工作提效，2016年10月份，運(yùn)維第一代運(yùn)維平臺(tái)正式啟動(dòng)開發(fā)，架構(gòu)圖如下：

第一代運(yùn)維的靚照如下圖所示：

運(yùn)維平臺(tái)的誕生，解決了我們資源歸屬、資源成本計(jì)算的問題，解決了運(yùn)維手動(dòng)添加NAT外網(wǎng)權(quán)限的問題，解決了費(fèi)用拆分至各業(yè)務(wù)線的問題，解決了技術(shù)人員離職歸屬資產(chǎn)變更的問題，解決了域名、資產(chǎn)歸屬查詢的問題，一定程度的解放了運(yùn)維的雙手。

2019年4月份，隨著我們的Python開發(fā)妹子加入運(yùn)維團(tuán)隊(duì)，我們的第二代運(yùn)維平臺(tái)正式起航，開始了持續(xù)演進(jìn)之路，附架構(gòu)圖：

現(xiàn)運(yùn)維平臺(tái)核心功能點(diǎn)&解決的問題：

支持部門維度的資產(chǎn)、費(fèi)用導(dǎo)出，對(duì)于各部門產(chǎn)生的云端資源費(fèi)用，一目了然，可查詢、無異議，哪個(gè)部門是消費(fèi)大戶查一下，就知道。

支持服務(wù)器資源歸屬、服務(wù)器使用率、是否可以部署新服務(wù)進(jìn)行建議，以前我們遇到的發(fā)現(xiàn)某個(gè)IP在瘋狂的調(diào)用我們，不知道是哪個(gè)部門的？現(xiàn)在只要查一下，就知道。

當(dāng)夜深人靜、華燈初上時(shí)，我們還為上完線后要立即刷新某個(gè)靜態(tài)文件而走一通申請(qǐng)流程而苦惱嗎？運(yùn)維平臺(tái)已經(jīng)通過調(diào)用公有云cdn接口并結(jié)合權(quán)限控制，實(shí)現(xiàn)也FEleader層面自助刷新功能，啥時(shí)刷新，你說了算（當(dāng)然，惡意刷新會(huì)上我們的黑名單哦）。

將內(nèi)部DNS、公有云、商用DNS產(chǎn)品整合在一起。之前運(yùn)維新增、變更某個(gè)域名，可能需要登錄各個(gè)DNS管理平臺(tái)，現(xiàn)有的域名管理已將幾個(gè)平臺(tái)整合在一起，一個(gè)界面搞定了全部。

將運(yùn)維的grafana監(jiān)控整合進(jìn)運(yùn)維平臺(tái)，業(yè)務(wù)同學(xué)直接可以在此查各自服務(wù)器等監(jiān)控信息。

對(duì)于業(yè)務(wù)線同學(xué)來說，可以在此根據(jù)域名關(guān)鍵字、端口、iP等維度查詢自己想要的信息，省去了和運(yùn)維溝通的成本；對(duì)于運(yùn)維來說，運(yùn)維通過集成、調(diào)用nginx域名添加、集群擴(kuò)容、域名下線、集群下線等http接口，實(shí)現(xiàn)一站式業(yè)務(wù)需求管理，極大的提升了運(yùn)維的工作效率。

根據(jù)平臺(tái)功能模塊，添加不同維度的管理權(quán)限，進(jìn)而實(shí)現(xiàn)分權(quán)限使用。

嵌入業(yè)務(wù)同學(xué)需要用到的各種需求、申請(qǐng)?zhí)釄?bào)站點(diǎn)以及只讀賬號(hào)介紹、家政神奇的nb命令介紹、域名規(guī)范、工單郵件規(guī)范、堡壘機(jī)站點(diǎn)、運(yùn)維工單站點(diǎn)等等，站點(diǎn)導(dǎo)航中全部都有以后大家只需要記住運(yùn)維平臺(tái)一 個(gè)域名即可^_^。

運(yùn)維平臺(tái)現(xiàn)在長這個(gè)樣子： 

從2015年11月至今，58到家運(yùn)維平臺(tái)經(jīng)歷了不同的發(fā)展階段，一路風(fēng)雨兼程，與我們一起見證58到家的發(fā)展，后續(xù)我們的運(yùn)維平臺(tái)將持續(xù)演進(jìn)、優(yōu)化，進(jìn)一步推廣自動(dòng)化，為業(yè)務(wù)同學(xué)、為運(yùn)維內(nèi)部、為其他有需求的平臺(tái)，提供助力，讓我們一起攜手，共同努力，走過2020這注定不平凡的一年！

“學(xué)則思，思則變，變則通，通則達(dá)，達(dá)則濟(jì)天下，運(yùn)維、QA、RD、FE是一家”與大家共勉！

Q1：成本管理和相關(guān)規(guī)范是怎么規(guī)劃和落地的？

 A：運(yùn)維平臺(tái)建立之前，最初是完成由運(yùn)維人工管理、確認(rèn)，季度性維度對(duì)整體資源進(jìn)行梳理，并產(chǎn)出相關(guān)資源使用情況報(bào)告。

運(yùn)維平臺(tái)成本中心模塊建立后，結(jié)合我們zabbix資源使用率相關(guān)信息，就能夠?qū)崿F(xiàn)自動(dòng)化的管理，可以根據(jù)我們自行制定的資源使用規(guī)范（例如服務(wù)器cpu內(nèi)存整體使用率低于40%的情況下需要對(duì)服務(wù)器降配或者暫時(shí)不能新申請(qǐng)服務(wù)器等）。

借助于運(yùn)維平臺(tái)以及公有云的費(fèi)用中心接口，將成本明確的拆分的各個(gè)使用方，后續(xù)定期給其發(fā)送資產(chǎn)使用報(bào)告，對(duì)于嚴(yán)重浪費(fèi)的部門限期資源整合等，這樣就能將成本管理簡易化，讓使用方和運(yùn)維都心中有數(shù)，逐步提高全體對(duì)資源、成本的控制、節(jié)約的意識(shí)。

Q2：運(yùn)維平臺(tái)與云機(jī)器（不同云平臺(tái)）的數(shù)據(jù)怎么打通獲?。?/span>

A：不同公有云的互聯(lián)互通，是使用多云的企業(yè)面臨的非?，F(xiàn)實(shí)的問題，我建議大家直接使用第三方做多云互通的公司，通過第三方公司的專線形式實(shí)現(xiàn)多云的內(nèi)網(wǎng)互聯(lián)。如果有自己的IDC托管機(jī)房，可以從IDC機(jī)房云廠商分別拉專線以IDC為中轉(zhuǎn)點(diǎn)進(jìn)而實(shí)現(xiàn)混合云環(huán)境的內(nèi)網(wǎng)互聯(lián)。

Q3：把當(dāng)前公司內(nèi)部系統(tǒng)和云廠商，進(jìn)行整合到現(xiàn)在的一個(gè)平臺(tái)上，阻力大不大？通常會(huì)有哪些阻力？

A：這個(gè)內(nèi)部系統(tǒng)和云相關(guān)的功能整合，如果是運(yùn)維內(nèi)部系統(tǒng)的話內(nèi)部可以消化，阻力可以忽略。如果涉及其他部門的系統(tǒng)要整合在一個(gè)平臺(tái)，需要運(yùn)維和系統(tǒng)負(fù)責(zé)人協(xié)調(diào)好，最好是由雙方的leader層面達(dá)成一致后再實(shí)行，要不然跨部門、甚至跨云的整合，阻力肯定是有的并且不會(huì)小。

Q4：您這邊容器及K8S監(jiān)控是怎么整合的？

A：容器和K8S的話，我們計(jì)劃今年下半年開始推，使用公有云的容器相關(guān)產(chǎn)品，監(jiān)控的選型使用Prometheus。

Q5：對(duì)于ECS/RDS/OSS/CDN這些IaaS、PaaS服務(wù)，以及對(duì)于業(yè)務(wù)的不同運(yùn)行環(huán)境（開發(fā)、測試、預(yù)生產(chǎn)、生產(chǎn)等）都有對(duì)應(yīng)的成本優(yōu)化最佳實(shí)踐嗎？

A：我們現(xiàn)在是不同的環(huán)境，分別部署了相應(yīng)的整套服務(wù)，生產(chǎn)、開發(fā)、測試、預(yù)發(fā)布，成本優(yōu)化還是基于我上文提到的利用運(yùn)維平臺(tái)成本中心的功能，去做整體的優(yōu)化。其實(shí)個(gè)人認(rèn)為要逐漸培養(yǎng)全體技術(shù)具備主人翁的意識(shí)、成本控制意識(shí)，資源的最大化利用自然就能做到水到渠成，而不是作為我們的一個(gè)包袱。

Q6：請(qǐng)問您這邊的監(jiān)控中心是怎么規(guī)劃實(shí)現(xiàn)的？

A：目前58到家在做的監(jiān)控中心項(xiàng)目，是集成了我們FE、運(yùn)維、DB、架構(gòu)的對(duì)應(yīng)監(jiān)控的負(fù)責(zé)人，在整體的集合、開發(fā)、聚合我們各個(gè)監(jiān)控系統(tǒng)的資源，最終目標(biāo)是匯聚、定制化開發(fā)為我們?nèi)w技術(shù)服務(wù)的全方位資源、服務(wù)監(jiān)控體系。

Q7：對(duì)于安全，運(yùn)維會(huì)額外多做很多事情，但不考慮安全又有隱患，怎么拿捏這個(gè)度？

A：很多中小型公司，前期是沒有專職安全人員的（我們58到家最初也是這樣，我們的安全完全依賴于同城安全團(tuán)隊(duì)對(duì)我們的支持），這個(gè)時(shí)候安全相關(guān)的很多工作會(huì)落到運(yùn)維同學(xué)身上，因?yàn)榛ヂ?lián)網(wǎng)安全法對(duì)于涉及個(gè)人敏感信息等的網(wǎng)站的管控越來越嚴(yán)格，建議沒有專職安全同時(shí)存在著很多安全問題無處著手的中小型公司，可以最低成本請(qǐng)專業(yè)的安全團(tuán)隊(duì)來協(xié)助解決自己面臨的安全方面的問題。

這方面我想說的是術(shù)業(yè)有專攻，運(yùn)維之于安全方面的專業(yè)度畢竟有限，建議大家交給專業(yè)的人來做安全方面的事情。

Q8：上文提到有zabbix和Prometheus，是不是Prometheus監(jiān)控業(yè)務(wù)和服務(wù)層，zabbix監(jiān)控基礎(chǔ)設(shè)施層，混合使用？

A：Prometheus的監(jiān)控我們規(guī)劃是對(duì)容器方面的監(jiān)控，基礎(chǔ)設(shè)施層如K8S底層的ecs可以選擇zabbix或者Open-Falcon去實(shí)現(xiàn)，這個(gè)建議根據(jù)自己業(yè)務(wù)的實(shí)際需求來即可。

服務(wù)層面的監(jiān)控，如果大家公司的技術(shù)棧是java并且沒有專職的架構(gòu)團(tuán)隊(duì)來開發(fā)業(yè)務(wù)監(jiān)控的話，可以使用美團(tuán)開源的CAT監(jiān)控。

Q9：監(jiān)控有沒有二次開發(fā)，能讓業(yè)務(wù)負(fù)責(zé)人自助添加監(jiān)控？

A：讓業(yè)務(wù)負(fù)責(zé)人自助添加監(jiān)控我們現(xiàn)在是在我上文提到的監(jiān)控中心里面有規(guī)劃，后續(xù)會(huì)統(tǒng)一開發(fā)、實(shí)現(xiàn)。

對(duì)于運(yùn)維自身的監(jiān)控平臺(tái)來講，如果我們有專職的運(yùn)維開發(fā)來支持，可以進(jìn)行二次開發(fā)。如果沒有，建議以能解決自己的實(shí)際需求、痛點(diǎn)為出發(fā)點(diǎn)重新來審視這個(gè)問題。