楊經(jīng)營(yíng)

DBAplus社群出品

讀完需要

10

分鐘

速讀僅需 4 分鐘

本文根據(jù)楊經(jīng)營(yíng)老師在〖Deeplus直播第216期〗線上分享演講內(nèi)容整理而成。（文末有獲取本期PPT&回放的途徑，不要錯(cuò)過(guò)）

楊經(jīng)營(yíng)

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

• 多年互聯(lián)網(wǎng)運(yùn)維經(jīng)驗(yàn)，2015年加入58到家，精通Linux操作系統(tǒng)，見(jiàn)證了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)勢(shì)，尤其是當(dāng)公司整體資源體量較小（硬件IDC成本在100萬(wàn)/年以下）時(shí)，該優(yōu)勢(shì)會(huì)非常明顯。

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

1

? ?

石器時(shí)代那道坎

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

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

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

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

2

? ?

All in 公有云的“坑”

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

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

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

3

? ?

應(yīng)運(yùn)而生的“58 到家運(yùn)維平臺(tái)“

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

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

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

4

? ?

“苦盡甘來(lái)”持續(xù)演進(jìn)：第二代運(yùn)維平臺(tái)

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

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

4.1

? ?

成本中心

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

4.2

? ?

資產(chǎn)管理（服務(wù)器）

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

4.3

? ?

CDN 文件刷新管理

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

4.4

? ?

域名管理

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

4.5

? ?

監(jiān)控平臺(tái)集成

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

4.6

? ?

集群域名管理

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

4.7

? ?

用戶管理、系統(tǒng)配置

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

4.8

? ?

站點(diǎn)導(dǎo)航

嵌入業(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)在長(zhǎng)這個(gè)樣子：?

五、未來(lái)規(guī)劃

從2015年11月至今，58到家運(yùn)維平臺(tái)經(jīng)歷了不同的發(fā)展階段，一路風(fēng)雨兼程，與我們一起見(jiàn)證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)，提供助力，讓我們一起攜手，共同努力，走過(guò)2020這注定不平凡的一年！

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

>>>>

Q&A

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)的部門限期資源整合等，這樣就能將成本管理簡(jiǎn)易化，讓使用方和運(yùn)維都心中有數(shù)，逐步提高全體對(duì)資源、成本的控制、節(jié)約的意識(shí)。

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

A：不同公有云的互聯(lián)互通，是使用多云的企業(yè)面臨的非常現(xiàn)實(shí)的問(wèn)題，我建議大家直接使用第三方做多云互通的公司，通過(guò)第三方公司的專線形式實(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ì)劃今年下半年開(kāi)始推，使用公有云的容器相關(guān)產(chǎn)品，監(jiān)控的選型使用Prometheus。

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

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

Q6：請(qǐng)問(wèn)您這邊的監(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é)人，在整體的集合、開(kāi)發(fā)、聚合我們各個(gè)監(jiān)控系統(tǒng)的資源，最終目標(biāo)是匯聚、定制化開(kāi)發(fā)為我們?nèi)w技術(shù)服務(wù)的全方位資源、服務(wù)監(jiān)控體系。

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

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

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

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í)際需求來(lái)即可。

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

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

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

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

---

獲取本期PPT

請(qǐng)?zhí)砑佑覀?cè)二維碼微信

獲取直播回看鏈接，請(qǐng)點(diǎn)擊閱讀原文↓

想要加入中生代架構(gòu)群的小伙伴，請(qǐng)?zhí)砑尤汉匣锶?strong>大白的微信

申請(qǐng)備注（姓名+公司+技術(shù)方向）才能通過(guò)哦！

擴(kuò)展閱讀架構(gòu)師成長(zhǎng)系列阿里技術(shù)專家都鐸：一文搞懂技術(shù)債2020-09-23Erik Dietrich：二十年的編程，教會(huì)我的五件事！2020-09-22支付寶研究員兼OceanBase總架構(gòu)師楊傳輝：我在數(shù)據(jù)庫(kù)夢(mèng)之隊(duì)的十年成長(zhǎng)路2020-09-21Mobvista首席架構(gòu)師蔡超：工作感悟之失敗與成功，我的8點(diǎn)總結(jié)2020-09-20 奈學(xué)教育CEO孫玄：成為一個(gè)有情懷的工程師，我的12點(diǎn)思考2020-09-19 架構(gòu)師，是否需要寫代碼？2020-09-18 Netstars CTO陳斌：架構(gòu)師的成長(zhǎng)之路2020-09-17 阿里技術(shù)專家麒燁：修煉測(cè)試基本功2020-09-16 愛(ài)奇藝數(shù)據(jù)中臺(tái)負(fù)責(zé)人馬金韜：數(shù)據(jù)中臺(tái)建設(shè)與應(yīng)用2020-09-14 數(shù)之聯(lián)CTO方育柯：技術(shù)的意義在于成就他人2020-09-13 東方證券首席架構(gòu)師樊建：企業(yè)微服務(wù)架構(gòu)轉(zhuǎn)型實(shí)踐2020-09-12 紅帽資深解決方案架構(gòu)師魏新宇：云原生應(yīng)用構(gòu)建之路2020-09-10 蘇寧智能 BU大數(shù)據(jù)中心數(shù)據(jù)治理團(tuán)隊(duì)負(fù)責(zé)人韋真：數(shù)據(jù)治理“三字經(jīng)”，超實(shí)用！2020-09-09 螞蟻資深算法專家周俊：從原理到落地，支付寶如何打造保護(hù)隱私的共享智能？2020-09-08 阿里高級(jí)技術(shù)專家簫逸：如何畫好一張架構(gòu)圖？2020-09-07 阿里巴巴閑魚架構(gòu)負(fù)責(zé)人王樹彬：萬(wàn)億交易規(guī)模技術(shù)架構(gòu)實(shí)踐2020-09-05 58轉(zhuǎn)轉(zhuǎn)技術(shù)總監(jiān)駱俊武：監(jiān)控系統(tǒng)選型？必讀本篇！2020-09-04 螞蟻集團(tuán)高級(jí)架構(gòu)師郭援非：分布式數(shù)據(jù)庫(kù)是金融機(jī)構(gòu)數(shù)字化轉(zhuǎn)型的最佳路徑2020-09-03 工行高級(jí)經(jīng)理林承軍：工行基于 MySQL 構(gòu)建分布式架構(gòu)的轉(zhuǎn)型之路2020-09-02 平安銀行吳建峰：RocketMQ 在銀行的應(yīng)用和實(shí)踐2020-09-01 阿里高級(jí)技術(shù)專家張建飛：應(yīng)用架構(gòu)分離業(yè)務(wù)邏輯和技術(shù)細(xì)節(jié)之道2020-08-31END ? ??#接力技術(shù)，鏈接價(jià)值#點(diǎn)分享點(diǎn)點(diǎn)贊點(diǎn)在看

總結(jié)

以上是生活随笔為你收集整理的58到家运维专家杨经营：业务上云后运维平台的演进之路的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。