提升運維效率，積極推進運維穩定性及平台化建設，持續探索雲上能力，借助公共雲的幫助實作soul的自有業務疊代。
圖：任意門運維負責人尤首智
編者按：2021年12月10日，在阿裡雲雲上架構與運維峰會上，任意門（Soul）運維總監尤首智發表了主題為“Soul雲上運維架構創新實踐”的演講，和大家交流了Soul雲上運維方面遇到的問題、挑戰以及在平台化建設過程中的經驗分享。
尤首智曾就職于搜狐、奇虎、快手等知名網際網路企業，一直從事運維架構、存儲、DevOps相關的工作，是一名相關經驗非常豐富的“網際網路人”。2020年11月加入Soul之後，主要負責運維穩定性及平台化建設，推動DevOps體系落地。本文根據他的演講整理而成。
一、Soul雲上的問題與挑戰
在加入Soul之初，我就面臨着四個困難和三個亟待解決的問題：
第一、人力短缺。運維部門隻有4名同學，研發線隻有200個同學，對于一家年輕的公司來說，1：50這個比例是比較高的。
第二、無成型運維工具。工具是存在的，單點上看功能不完備，整體上看運維層面沒有串聯起來，這大大增加了運維成本。
第三、業務高速疊代。每周一個小版本，兩周一個大版本，這與公司業務線的發展體系有關，而且Soul也在不斷探索一些新的領域。
第四、基礎架構的缺失。這導緻接入和使用方式多種多樣，每個部門保持自己獨立的基礎架構，這種工作形态同樣也大幅提高了運維成本。
在這些困難下，我們認為，如何短期内提高運維效率，是Soul運維部門當時階段首要解決的問題。因為隻有提升了運維的效率提升，我們才有更多的時間去做更多的事情，包括提升業務的穩定性、更好地支撐業務快速疊代等。
二、運維效率提升
Soul對于運維提效制定了四個主要方向，同時也是我入職後落地工作的重要抓手：
01 解決雲上效率問題
Soul在平台建設的過程中使用了大量的阿裡雲的PaaS産品，并且在日常維護中産生的工單較多，Soul将大量的工單處理交給了阿裡雲的同學，組成短期快速實作閉環的工作鍊條，這個給了我們更多的時間去梳理公司現狀與問題，節省了極高的時間成本。
02 優化釋出平台
Soul也是用了中小型标配的Jenkins、以及一部分阿裡雲EDAS産品能力，這兩款産都不是一個完整的釋出體系，都有部分功能缺失，于是我們就選擇通過以下幾個方面建設CI/CD體系：
◾ 釋出周期：由于沒有固定的釋出視窗，大大延長了故障的時間，無法及時處理故障問題，降低了使用者的産品試用體驗。比如淩晨上線，到第二天上班才知道故障的發生。
◾ 完整疊代：從DEV環境到QA再到代碼掃描，再到灰階最後到線上，完整的疊代周期串聯是團隊當初急需要做的。
◾ 釋出效率：釋出當時面臨最大的問題是穩定性差，CI/CD一體執行，釋出底層salt和ansible執行效率低下；首先我們需要将CI、CD分離；編譯所需參數存儲于CMDB中，打包動作逐漸脫離jenkins，将編譯功能內建在釋出平台中；CD部分去掉salt，全部替換為ansible api；
◾ 參與度：降低運維的參與度，提高研發與平台互動度，讓運維有更多時間更多關注疊代内容、周期、釋出次數等。
03 CMDB建設
CMDB是運維最重要的一個資訊源，也是完整的運維體系的第一步。
Soul也将所有的資訊源都寫入到CMDB中，包括阿裡雲資産、自建應用資訊、服務建構參數及組織架構人員資訊。
存儲相關資訊的作用主要在于CI/CD、自動化運維、成本分析、報警、故障能夠與用戶端表現的直接關聯。CMDB建構并沒有在短期内一次性完成，是從阿裡雲的部分資産入手，最後到建構參數，逐漸補齊。随着CMDB的逐漸補齊，基礎環境的标準化也在初步推進。
04 運維工單平台的0-1
Soul運維工單平台是運維對研發甚至是對公司唯一的入口。在此之前内，部均使用郵件方式溝通，但随之而來的是郵件丢失、延遲的等問題， 導緻需求處理延誤、因權限管理不清晰而有部分同學自行操作，繼而發生各種問題。
Soul工單平台更接近雲管控，逐漸替代掉阿裡雲控制台的權限，同時我們使用工單的方式逐漸的規範研發同學對中間件和阿裡雲底層資源的認知，主要分三個階段：
階段一：純手工打造。工單平台抽象高頻的操作和需求，但依然是人工執行。這個階段的工單平台，更多僅像一個web入口，無太多自動化能力。
階段二：人工決策，自動執行。這個階段持續時間較長，工單需完成自動化能力補齊。
階段三：自動決策，自動執行。将業務對資源的需求與資源類型/資源規格轉化，常态化需求描述以及個性化需求描述，需要通過工單平台入口使得運維更加靠近業務。
到此階段，在半年時間内，運維自身效率已提到提升，有了更多的時間參與穩定性架構改造，同時運維人員也更多的精力關注業務動向。
三、穩定性建設
01 面臨的問題與挑戰
Soul不能“挂”是整個團隊最重要的OKR，原因是2020年Soul上過兩次熱搜，都是因為架構不穩定導緻站點異常進而引發熱議。
第二點是服務預警與快速恢複，這一部分是缺失的狀态，導緻故障發生後無法第一時間精準定位根因。
第三點是架構演進，Soul的業務體量在持續上漲，體量變大的架構演進是必然的。
02 故障定位與處理
穩定性的生命周期中，故障與非故障的時間占比是非常重要，非故障時間需要增加架構的穩定性建設、複盤、演練，才能讓故障的時間占比下降，使業務的穩定性向着更加健康的方向發展。最近一年時間裡，着重于穩定性建設時間，增加演練次數，下面也會着重分享穩定性改造的相關案例。
03 穩定性改造
在過去一年當中，穩定性建設方面，Soul大緻進行了上圖中的六個工作，我們将從中挑出三個較有代表性的方面展開分享。
改造1：監控系統的演進
2020年底，Soul的監控隻有AMRS，雖好用但不适合Soul，比如IT治理沒有做好，主機組+報警模闆+報警聯系人+組織架構+發送通知關聯不起來，導緻隻有運維收報警，研發同學收不到。運維同學隻能手動轉發給研發同學進行處理。
在K8s平台方面，Soul當時使用的是Promethues。Promethues最大的問題是無成型web互動，查詢及報警語句有相對較高的門檻。
到2021年3月，我們開始正式做監控治理，使用OpenFalcon進行底層雲産品的監控，同時将公司内部的多套Promethues及阿裡雲的Promethues服務進行合并，統一Promethues資料源。這樣公司裡面隻有兩款監控産品：一個面向底層資源，一個面向K8s。
2021年6月，我們開始自研監控系統OWL，從名字“貓頭鷹”上能看出來，我們希望它能代替運維同學在晚上值班。
OWL監控沿用OpenFalcon前端的頁面，相容Promethues資料，将Promethues的查詢及報警語句抽象出來，進行格式化的展示，并添加報警功能。這一點類似于grafana的promethues插件部分，目前已經将所有的報警整合在OWL報警平台當中，同時也實作了資訊采集及報警功能完善。
下一個階段是報警網關，報警網關還需要擁有報警接手+解決+報警更新的能力，友善運維同學對問題的跟蹤。随着報警逐漸的添加，報警的數量也逐漸在增長，也出現了報警資訊被淹沒的情況，為了友善運維同學對問題的跟蹤，報警網關進入了下一階段的疊代，報警接手+解決+報警更新，減少群裡的重複性報警的同時又不會漏掉關鍵報警。
改造2：接入層改造
上圖左側架構是Soul 2020年的架構，右側是最新的、改造後的架構。
左側架構中，SLB對接ACK pod及ECS；優點非常明顯，不會出現大故障，缺點則是可維護性較差，導緻小故障不斷，用戶端表現的很多異常，大部分來自接入層。
右側是新架構改造，統一接入層，開啟ingress入口模式，優勢是能夠輕松實作全鍊路的把控與追蹤以及成本的優化，統一的高防與WAF接入。
改造3：MySQL切換PolarDB
MySQL切換PolarDB是2020年，SOUL與阿裡雲深度合作的第一個項目，改造的背景是MySQL分庫分表機制有問題，磁盤與CPU不比對，單執行個體已超過阿裡雲SLA标準，達到了6T的資料。
而Soul的業務場景是讀多寫少，同時團隊也在考慮分布式DB，這兩個特性與PolarDB與Soul的比對程度非常高，團隊人員用了1個月時間，将大于1T的30組MySQL執行個體，全部遷移至PolarDB，遷移後無論是在費用、穩定性及使用率多個方面均正向收益。
對于以上的架構的改造，對于Soul來說，不一定是最好的，但卻是最實用的、短期内可以支撐業務的高速疊代方案。
四、未來方向
最後，分享一下Soul在2022要做的幾件事情：
1、繼續探索雲上能力。對于Soul這樣的中小型公司，底層技術能力部分其實可以依賴公有雲，特别是Soul在做多方向試探的業務場景，可以借助公共雲的幫助實作自有業務疊代。
2、私有的管理方式。對于公有雲的基礎能力，加上自定義的管理和接入使用方式，完全能夠助力業務的快速疊代。例如RDS、Redis，可以把它當作一個執行個體；ECS則可以看作是一台實體機，通過這樣的使用方式，來去掉IaaS層的壓力。
3、産品的PaaS化。Soul團隊也将深度學習阿裡雲的産品思維，将自有的PaaS産品做得更加産品化。
最後的最後，我希望緻敬每一位運維人，緻敬我們平凡中的不平凡。
點選大會官網，檢視尤首智在峰會上的精彩演講視訊。