楊經(jīng)營

58到家運維專家

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

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

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

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

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

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

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

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

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

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

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

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

第一代運維的靚照如下圖所示：

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

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

現(xiàn)運維平臺核心功能點&解決的問題：

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

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

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

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

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

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

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

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

運維平臺現(xiàn)在長這個樣子： 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Q7：對于安全，運維會額外多做很多事情，但不考慮安全又有隱患，怎么拿捏這個度？

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

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

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

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

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

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

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

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