2021年10月22日，在雲栖大會的《雲上運維最佳實踐》分論壇，映客進階技術總監黃繼發表了主題為“7天從開發到上線，雲上高效運維實踐與探索”的演講，為大家闡述映客團隊如何在較短時間内快速完成業務的開發，同時還要保障業務上線後的穩定運作、快速擴充、通路品質和資料化營運等經驗。
本文根據他的演講整理而成，主要分為三個部分：
一、映客業務的效率問題與挑戰。
二、應對思路與實踐探索。
三、未來方向與規劃。
圖：映客進階技術總監黃繼
映客業務的效率問題與挑戰
說到映客，在大部分人了解或認識裡，映客就是一個直播的平台。但實際上，映客是有一系列泛娛樂化的各種APP，比如有線上相親、香港地區的電商直播、陌生人的音視訊社交等。截止到目前為止，映客大約有40個業務線上營運。
在映客内部，我們非常鼓勵去做新賽道探索和内部創業。是以，我們每年都還會有十多個新的業務被立項、開發和投入上線。在這個大的背景下，時間和效率對我們來說至關重要。
在時間短這個前提下，對我們主要造成的問題或者一些挑戰就來自于這三個方面：
1. 業務需快速做功能疊代。尤其在APP上線初期，有大量的業務需求和功能去完善，我們需要一個比較完善的工具平台和智能化體系。
2. 驗證周期短。在資料營運方面，大部分産品在上線之初就設計好了付費、盈利的模式。是以産品會在非常短的時間周期内進行驗證。隻要驗證可行，就會馬上轉入流量推廣和增長獲客的階段。
3. 服務品質。因為我們業務驗證周期很短，在這個周期之内，很可能會遇到突發的使用者新增。是以我們希望所有的使用者，都有比較好的使用者體驗。這就要求在業務剛上線的初期，在穩定、通路速度等方面，要達到成熟業務的标準。
在剛開始的時候，我們大部分産品的必要功能就很多，比如支付、稽核、使用者觸達等。這些功能在初期就是必備功能，涉及到很多團隊，需要多方去溝通和對接；其次，内部的流程有時候也會影響工作效率；在服務品質方面和資料營運方面，初期沒有什麼投入，大家的精力基本都在功能上。
如果說把這些問題都拉到一個比較長的周期來看，其實不是太大的問題。但在我們的場景裡，我們希望在業務上線的時候就已經解決了這些問題，或者能夠盡快解決這些問題。
我們的解決思路大緻分為四個次元：
1. 靈活，努力完善我運維體系和服務治理體系，進而加快内部的疊代效率；
2. 解耦，通過解耦讓業務更加的純粹，隻需要關心自己的業務邏輯；
3. 複用，這麼多業務中有一些功能是相同的，把這些功能作為公共服務提供；
4. 場景化，比如說使用者注冊之後，會涉及到風控、稽核、資料可視化和使用者觸達等。我們把部分能力做了整合，讓它在快速獲得這些能力。
我們給自己定了一些目标和口号，比如我們的目标是“711”，口号是“讓業務更專注業務”。“711”意思是7個雙端的研發可以在1周時間開發上線1個APP。具體實踐的過程是：
◾ 首先，提前做統一的資源管理；
◾ 其次，在内部所有的業務之間統一服務架構；
◾ 第三，做标準的公共服務元件；
◾ 最後，沉澱我們自己的業務場景和閉環。
應對思路與實踐探索
下圖是我們應對思路與實踐探索示意圖，底層主要是統一資源的管理，上面兩層是為服務端和用戶端提供的開發架構的服務元件，橫向部分是将第三方服務和我們自己内部的服務去做一些場景提煉和沉澱。
最早，我們先從統一資源管理開始做，其中公有雲也提供了一些管控的能力。但為什麼我們還要考慮自己來做呢？
1.多雲支援。這裡最早是為了解決服務品質，在發生故障時友善做熱備切換。
2.去差異化。如果雲擴充了，互相之間會有不同和差異。對于業務層，我們需要把這些差異做到屏蔽，讓他們覺得平滑和透明。
3.自有體系。在這個基礎上更容易建立自己的自有體系，包括運維自動化的體系和服務管理的體系。
4.成本管理。因為我們需要在很早階段就做更精細的成本管控，是以我們需要看APP的次元，去看大家的費用消耗或者資源使用情況。
上圖是目前所有的運維工具和平台的體系。右邊最下面是CloudAPI層，我們把所有公有雲提供的資源，隻要能支援API接口的都做了接入。在這個基礎之上，按資源的分類去做相對應的管理工具和平台，包括安全組，因為它的變更頻率非常高，是以我們對安全組做了抽象和重新設計，還有一個對應的管理平台。這些資源一旦被開通和投入線上使用，都會和我們自己的服務樹做關聯綁定。
這棵服務樹就是右邊黑色的圖，在這個樹上按照産品、子系統、功能子產品進行業務拆分。因為這個樹上記錄了每個業務和資源的對應關系，是以服務樹和内部其他的系統進行關聯和關聯。
比如與監控系統關聯，可以實作監控自動地添加和删除。這棵樹不但是運維管理的基礎視角，還是内部其他系統資料源。是以它的資訊需要準确及時，不能是靜态或者手動回複。那麼我們如何動态維護和管理這棵樹呢？我們通過和上層服務治理結合的方式實作。
先介紹一下自動化運維裡三個基本的概念。
◾ 首先是Service Tag，即微服務子產品。當它橫向排列展開時就是如圖的字元串。在這個字元串裡包含了子系統的資訊、服務系統的資訊、子產品的名字。如果把它豎向排列，就和服務樹一樣，它很多時候可以通過這個Tag生成服務樹。
◾ 再往上是service Name，包含服務名字、子系統。這兩個有相似性，本質是一個東西，隻是一長一短。長的這一塊更偏向資源和運維管理，短的這個更偏向服務應用。
◾ 再往上就是Appid，即業務的辨別。Appid下關聯了很多業務屬性，比如業務的負責人，相關的業務屬性等。
這三個基礎的概念，底層有一個關聯的邏輯關系，可以梳理業務下面的服務，服務所關聯的資源。這三個是一一對應的關系。我們所有的自動化運維體系圍繞這三個來展開的。
具體運作的模式，這裡簡單跟大家介紹一下。如果建立了一個新的業務。它首先在映客雲平台上立項添加；然後生成和業務對應的屬性；其次，通過一些接口或者生成工單的形式通知運維平台做基礎資源的準備。
同時，研發可以開展代碼開發的工作。在代碼開發的同時，它需要先到KAE平台建立和生成serviceName和serviceTag的字元串。當這個業務在平台釋出線上之後，業務和資源的對應關系會自動生成關聯到樹上。基于服務樹，我們進一步做自動監控，基于KAE平台進一步做遠端配置、流量錄制。同時業務還會生成一些源資料給大資料做計算分析。生産資料也利用service和Appid資訊去決定生産到什麼樣的隊列，去做一些隔離和優先級劃分等等，最後落地到大資料。
業務在最初建立時，會和我們的資料平台去做關聯。當源資料生成之後，對應的資料就能可視化，和APP相關的資料都會和映客雲做一個關聯。
為了讓所有業務都能遵守這樣的機制，我們提供了統一的一套開發架構。這套架構提供了一些能力，包括日志、監控上報等基礎功能。圍繞這個架構，我們也做了周邊的腳手架，以便快速生成一個項目。對于整個架構依賴的公共資源，我們抽取出來進行集中的統一管理和運維。
下一階段做一些通用公共服務元件的提煉，包括短信、推送、加解密、埋點等服務。這些都變成公共服務，并且盡可能讓它實作自助對接。我們在用戶端也同樣做了類似的事情，比如熱修複、網絡優選、通用埋點。我們都提供一個公共的能力。
包括對于一些第三方，我們也做了一些提煉。這個設計圖底層就是音視訊SDK所提供的能力，在高階應用接口這一層，我們按照房間操作和使用角度去提供接口。通過這樣的方式，我們去實作底層SDK接口快速切換，來做到對業務層更加透明。
在業務場景化這一塊，我們内部主要在使用的是使用者、金融、IM這三塊。比如使用者，我們對基本的注冊/登入，風控、推廣投放和資料可視化能力進行了整合。
這些整合過的能力，我們盡可能讓它自助配置，自助的對接。我們現在設計的一個目标就是每個元件可以在30分鐘内完成接入，達到可連調的條件。
經過上面幾個階段的發展之後，我們主要的變化和收益在研發人員這邊。
一是他們可以跨業務的靈活遷移。比如說這個項目要去做了，它可以快速從其他産品裡抽調人手。如果不做了，這些人可以快速分散到其他業務裡；
二是他們更多時間是聚焦在業務邏輯上，是以可以降低一些經驗要求。在業務端，我們對業務可以減少開發的工作量；很多元件可以快速對接，我們目前大部分都可以做到30分鐘-1小時完成；
三是底層服務更新更加透明，而且這些服務有專人維護，更加成熟穩定，避免業務之間重複踩坑。最後是一些預設的功能整合。
我們整套體系從最初100%基于公有雲來去搭建和建設，某種程度上也符合最近比較流行的雲原生理念。在上圖，左邊是初期已經開始在用的一些服務，右邊是随着現在公有雲産品越來越豐富和完善，我們也陸續用了更多的一些能力。大家在準備上雲，或者在雲上運維裡，不可避免都會遇到類似這樣的問題，比如說雲的定位是什麼？雲上産品越來越豐富，到底直接使用還是考慮自研？雲需不需要去做混合雲，或者做多雲架構？我覺得這個需要根據業務和場景來做具體的分析和決策。
我個人認為這些問題在可控性、遷移性和低投入，這三個角度去尋找平衡。而這三個角度某種程度上點像一個不太嚴謹的CAP理論。隻能占有兩個，犧牲掉一個或者放棄掉其中一個。在映客最初的定位裡，我們更多側重在可控性和可遷移性上。
未來方向與規劃
針對未來，我們要做的一些事情。
首先，持續建設多雲熱備架構，以及遷移能力的加強，這方面主要考慮是服務品質。随着公有雲本身的穩定性和可用區域越來越多。這件事情變成一個重要，但不緊急的事情。但是對于一些大面積故障，或者區域性故障，我們仍然是不可接受的。
其次，中台化相關的能力，主要針對海外。因為我們越來越多的業務開始去探索海外市場。這一塊我們的積累沉澱還很少。
最後，更多的場景化。讓業務可以更簡單，比如客服或者智能投放的能力。