楊經營

DBAplus社群出品

讀完需要

10

分鐘

速讀僅需 4 分鐘

本文根據楊經營老師在〖Deeplus直播第216期〗線上分享演講內容整理而成。（文末有獲取本期PPT&回放的途徑，不要錯過）

楊經營

58到家運維專家

• 多年互聯網運維經驗，2015年加入58到家，精通Linux操作系統，見證了58到家運維體系從0到1的建設，主要負責運維自動化、平臺化在58到家的應用及推進工作。

• 現任58到家技術委員會成員，負責58到家運維體系整體發展方向與技術選取。
  

近幾年公有云已日趨成熟、穩定，成為很多中小型互聯網公司的首選，其成本、易維護、輕資產、可靠性、基礎設施、技術支持這幾方面公有云和傳統IDC相比有著獨特的優勢，尤其是當公司整體資源體量較小（硬件IDC成本在100萬/年以下）時，該優勢會非常明顯。

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

1

? ?

石器時代那道坎

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

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

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

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

2

? ?

All in 公有云的“坑”

凌云項目結束后，58到家正式開啟了基于公有云的技術升級之路，這其中也包含了運維，對于機器、資源、域名、云端各項服務，云端都能夠實現快速部署、實施和交付，這個是云的明顯優勢。

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

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

3

? ?

應運而生的“58 到家運維平臺“

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

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

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

4

? ?

“苦盡甘來”持續演進：第二代運維平臺

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

現運維平臺核心功能點&解決的問題：

4.1

? ?

成本中心

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

4.2

? ?

資產管理（服務器）

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

4.3

? ?

CDN 文件刷新管理

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

4.4

? ?

域名管理

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

4.5

? ?

監控平臺集成

將運維的grafana監控整合進運維平臺，業務同學直接可以在此查各自服務器等監控信息。

4.6

? ?

集群域名管理

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

4.7

? ?

用戶管理、系統配置

根據平臺功能模塊，添加不同維度的管理權限，進而實現分權限使用。

4.8

? ?

站點導航

嵌入業務同學需要用到的各種需求、申請提報站點以及只讀賬號介紹、家政神奇的nb命令介紹、域名規范、工單郵件規范、堡壘機站點、運維工單站點等等，站點導航中全部都有以后大家只需要記住運維平臺一?個域名即可^_^。

運維平臺現在長這個樣子：?

五、未來規劃

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

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

>>>>

Q&A

Q1：成本管理和相關規范是怎么規劃和落地的？

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

運維平臺成本中心模塊建立后，結合我們zabbix資源使用率相關信息，就能夠實現自動化的管理，可以根據我們自行制定的資源使用規范（例如服務器cpu內存整體使用率低于40%的情況下需要對服務器降配或者暫時不能新申請服務器等）。

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

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

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

Q3：把當前公司內部系統和云廠商，進行整合到現在的一個平臺上，阻力大不大？通常會有哪些阻力？

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

? ?

Q4：您這邊容器及K8S監控是怎么整合的？

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

Q5：對于ECS/RDS/OSS/CDN這些IaaS、PaaS服務，以及對于業務的不同運行環境（開發、測試、預生產、生產等）都有對應的成本優化最佳實踐嗎？

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

Q6：請問您這邊的監控中心是怎么規劃實現的？

A：目前58到家在做的監控中心項目，是集成了我們FE、運維、DB、架構的對應監控的負責人，在整體的集合、開發、聚合我們各個監控系統的資源，最終目標是匯聚、定制化開發為我們全體技術服務的全方位資源、服務監控體系。

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

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

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

Q8：上文提到有zabbix和Prometheus，是不是Prometheus監控業務和服務層，zabbix監控基礎設施層，混合使用？

A：Prometheus的監控我們規劃是對容器方面的監控，基礎設施層如K8S底層的ecs可以選擇zabbix或者Open-Falcon去實現，這個建議根據自己業務的實際需求來即可。

服務層面的監控，如果大家公司的技術棧是java并且沒有專職的架構團隊來開發業務監控的話，可以使用美團開源的CAT監控。

Q9：監控有沒有二次開發，能讓業務負責人自助添加監控？

A：讓業務負責人自助添加監控我們現在是在我上文提到的監控中心里面有規劃，后續會統一開發、實現。

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

---

獲取本期PPT

請添加右側二維碼微信

獲取直播回看鏈接，請點擊閱讀原文↓

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。