百分點 To B轉型之路:技術中臺及DevOps的建設實踐

2019-09-13 06:38:25

作者 | 代其鋒
編輯 | 田曉旭
本文整理自 2019 年 ArchSummit 全球架構師峰會深圳站百分點資深架構師代其鋒演講話題《ToB 技術實踐:挑戰與破局之道》。

我今天分享的內容主要包括:百分點在發展 ToB 業務過程中遇到的挑戰;針對這些挑戰,我們在技術建設和組織建設方面的思考;最後,我會針對整個轉型過程做個總結。

一.轉型之痛  

百分點是成立於 2009 年,成立之初,主要是給企業提供基於推薦的 SaaS 服務。2014 年,百分點開始嘗試企業級交付,當時我們主要是給傳統企業提供包括大資料、人工智慧等方面的服務,比如為企業做資料的拉通,使用者畫像,當時我們的很多思想在業界還是比較領先的。2016 年,百分點響應國家一帶一路的政策,開始將我們的資料智慧技術賦能給海外國家,當前我們的業務已經覆蓋除了歐美之外的所有地區。

SaaS 服務的場景比較簡單,主要是根據使用者的網路行為做個性化推薦,我們當時服務了電商、媒體行業等一千多家客戶。如果客戶想要在首頁推薦某些商品,可以將需求提交給研發經理,拿到需求之後,研發經理會先對需求做一個分析,比如使用者的業務流程,能拿到的資料有哪些,要在哪些地方展現推薦等,有了這些資訊就可以直接對接後端開發了,大概一週的時間就可以開發上線。整個價值鏈非常短,主要以研發驅動為主,上線之後,我們通過大資料分析,會及時的看到效果,例如客戶 PV 變化、推薦轉化率等。

2013 年,電商行業經歷了泡沫期,很多電商企業經營的都不好,這對百分點也產生了一定影響,企業畢竟需要盈利。因此,我們開始思考轉型的問題。在這個階段,我們看到了一些傳統企業存在的困難,他們實際上沉澱了很多非常有價值的資料,但是這些資料在企業的資料庫中並沒有發揮出價值,一方面受限於資料處理能力,另外一方面在資料的運用上缺乏重視和理解,我們開始考慮是否能夠藉助大資料等新技術幫助這些企業做數字化轉型。

2014 年,我們做了 ToB 業務轉型之後的第一個客戶,幫助客戶進行使用者畫像和推薦,收集完資料之後,再進行資料拉通,然後給客戶提供使用者畫像和推薦服務。

但是這個專案,我們做得比較痛苦,投入也非常大,整個專案執行了 7 個月,包括一個專案經理、三個諮詢參與其中,20 個技術在客戶現場,30 個研發在後端支援。為什麼會做得很痛苦呢?主要原因是我們還在用以前做 SaaS 的討論做專案,所以不可避免地遇到了一些問題,例如流程問題,諮詢在和客戶溝通需求之後,沒有沉澱出一個很好的需求文件,只畫了一個大致的原型圖就交給研發,裡面的業務互動過程,展現的資訊等都沒有明確,導致了大量返工工作。另外,大家的配合做的也不好,比如研發給的軟體包經常在現場跑不起來,部署文件、軟體包等都非常不規範,溝通成本很高。

我們做事的方法存在很多問題,另外就是心理上的挑戰,之前做 SaaS 業務,大家認為我與客戶是在同一水平線,客戶提需求,我們負責完成,整個是研發驅動的過程。而在企業級交付領域,我們需要主動去了解客戶需求、主動去服務客戶,需要具有極強的客戶服務意識。

SaaS 服務與企業級交付有何不同呢?

SaaS 服務的價值鏈非常短,使用者提出需求給到研發,研發經理就可以很快地把使用者需求轉化成研發。而且因為使用者需求很簡單,使用者也不關心具體的研發過程,只需交付產品即可,所以整個產品的交付週期也非常短,涉及的人員也很少。並且,我們已經把這個過程標準化了,提供的產品也標準化了。

而在企業級交付領域,客戶需求是多元化的,沒有標準化的產品,更多的工作不在於研發,在於要去了解使用者需求,並把使用者需求轉化成研發能夠執行的產品需求。最後交付的不僅只有系統,還包括文件、培訓工作、部署手冊等等。企業級交付不僅是一個研發的過程,更多的是一種全方位服務,過程要求會更加標準,不然很難去應對使用者的需求變化,也很難保證交付的高效。

目前百分點的業務包括 SaaS、To B 業務,業務增長了 10 倍,人員規模由 150 人擴充套件到 800 人,每年交付的專案超過一百個。下面我要解釋一下我們是如何做到的。

二.技術建設  

首先介紹一下我們的技術體系,百分點的主要賽道是大資料和人工智慧,所以我們提供給客戶的解決方案都是圍繞大資料和人工智慧來展開的。整個技術體系的最底層是大資料的全棧技術,包括資料儲存、資料處理和整個資料生命週期管理,我們有全套的資料中臺解決方案;再往上,我們提供了智慧的分析和決策系統;所有的這些系統都執行在我們的私有云平臺上。

目前,我們每個月差不多並行實施 50 個專案,每個專案的週期不一樣,有的專案 6 個月,也有的專案 5 年、10 年,而在人員配備方面也會根據專案週期進行調整,小專案可能一個產品 + 運維就可以了,大專案可能需要 30 到 40 人。

我們在技術上如何去支撐這些專案呢?

我們技術建設的思路可以分為三個方面:

  • 具備資料應用技術中臺能力:因為要應對各個業務線,應對不同的專案,而每個專案中又有些共性的需求,這些共性需求基本都集中在大資料和 AI 層面,所以我們建設了自己的資料中臺、AI 中臺以及部分業務中臺。

  • 產品研發的落地,需要一整套全面的研發方法論支撐:為了提高研發效率,百分點有一套完善的 DevOps 體系,讓開發、測試、運維能夠高效協作。

  • 全面深度的技術拉通:把各個業務線的技術進行拉通,統一技術支撐體系,為百分點跨行業和團隊提供能力升級。

為什麼要建設中臺?建設中臺的本質是為了提效,同時提高專案交付的質量,我們有專門的人員來建設中臺,提高中臺的質量。通過技術中臺,我們也可以提高百分點的品牌,在行業產生影響力。

在組織上,百分點其實還沒有專門的中臺部門,所有的中臺都是在業務中沉澱出來的,我們沉澱的幾款中臺產品目前都有專門的團隊進行支撐,同時這些中臺產品也在嘗試進行商業化,比如我們為企業提供資料中臺,基本的 NLP 能力等。

目前,我們的中臺主要包括資料平臺、業務中臺和 AI 中臺。

其中,資料平臺和 AI 中臺,不僅是內部使用,同時也承接了商業化的目標,我們會在資料平臺中新增行業屬性、行業模型幫助企業建設資料中臺。例如,如果是人口型別的資料中臺,我們會內建一些人口模型,包括欄位怎麼命名、欄位的取值範圍、資料的質量規範等。

AI 中臺與資料中臺類似,媒體行業、社交行業等領域的 AI 能力不太一樣,例如我們要做情感分析,那麼就要分析社交資料、電商評論資料等,因此,我們針對這些資料會提供專門的分析介面。

業務中臺的實踐,當前我們做的還比較少。我們有很多業務線,但每個業務線並沒有形成非常完備的解決方案,很多業務線其實還處於前期探索階段,很難去從業務線中沉澱出真正能夠支撐所有業務線的業務中臺。目前我們更多的是沉澱了一些通用的業務中臺,例如使用者中心、許可權管理、OSS、流程引擎等。

在技術中臺方面,我們的大資料平臺、AI 中臺、流程引擎、使用者中心 & 許可權管理方面做得比較紮實,也收到了不錯的效果。

DevOps 的目標是提高研發效率。最早的時候,我們沒有 DevOps 概念,開發做開發的事,部署做部署的事,開發完之後,打個包丟給運維去部署,部署完之後,就進行測試、上線。整個過程中溝通效率特別低,部署完全是靠人工的。後來,我們做 SaaS 服務,業務同樣比較單一,如果運維不能部署,開發直接上。但是,到了做企業級交付時,並行實施的專案非常多,完全依賴人工顯然是不靠譜的。

因此,我們引進了自動化構建工作 Jenkins,開發完成之後,通過 Jenkins 去構建程式碼,進行部署。雖然 Jenkins 的入門門檻比較低,但是在執行過程中也會存在一些困難,例如需要寫自動化指令碼,這對研發來說可能就是個大難題;比如面對環境的問題,很多服務可能需要部署到一臺機器上,但不同專案依賴的版本不同,這時就容易造成衝突。

之後,我們又引進了 Docker,基於 Docker 做 CI/CD 的整合,開發完之後,提交到 Git,自動地做程式碼構建,並通過 Jenkins 把映象打出來,然後在雲平臺上進行部署。部署之後,我們還可以做一些配置修改,自動化報警、容災等等,通過這一方法,我們整個開發部署能夠在分鐘級完成。

上圖是整個 DevOps 流程,因為專案和資源都在雲平臺上,所以首先要去申請資源,技術負責人向運維負責人申請專案資源,並在平臺上填寫需求,例如 CPU、Core、Memory、節點等的數量。然後租戶管理員管理專案分配的情況,一般來說我們會分開發、測試和準上線環境,我們在自己的環境做好測試開發,在準上線環境中模擬每個環節。研發在提交程式碼之後,需要編寫 JenkinsFile、DockerFile,運維完成之後直接打包執行在 K8s 的叢集上。從提交到看到效果,5 分鐘之內就可以搞定。

這是我們自研的 Sextant 雲平臺,提交程式碼之後,完成程式碼構建,並把程式碼執行在 K8s 上。

目前我們並沒有把所有應用遷移到 DevOps 平臺上,上線的應用大概有一百多個,部署和叢集利用率都提高了,而且因為研發和運維無相互依賴,運維專注工具化,研發專注業務系統,所以整個協作效率也提高了。

後續我們的 DevOps 還會有一些升級,主要包括以下內容:

  • 計算專案資源 & 成本評估:因為我們採用的是專案制,這些專案基本上都是由各個事業部承擔,資源也是有成本的,所以我們下一步就是核算專案成本,防止事業部隨意申請資源;

  • 質量度量:量化團隊的質量報告,檢視大家是否遵守了程式碼規範,分析日誌,從各個角度評估業務質量;

  • 智慧運維:預測系統故障,提前預警;預測系統資源使用,提前預警;分析日誌,評估系統監控;效能分析,呼叫關係鏈分析。

  • 智慧建議:根據系統訪問量、資源使用等給出資源建議;根據訪問趨勢,對空閒資源給出建議。

To B 業務專案多,涉及人員龐雜,如何做技術管理呢?如果不做技術管理的話,大家使用的技術棧都不一樣,使用的工具也不一樣,做事的方式也不一樣,必然會出現一些問題,面對知識傳承以及人員變化都很難去響應。

因此,技術拉通就對 To B 業務至關重要。

在技術拉通方面,百分點成立了公司的技術管理委員會,委員都是來自於各個業務線的資深架構師。除此之外,我們還有專家組,專家組主要是在各個職能中比較資深的人員。實際上,百分點拉通了公司所有事業部的專案和業務線。目前,我們有數十個業務線,成立了 7 個技術小組,每兩週會進行一次會議,討論技術規範的執行情況。

之前做 SaaS 服務的時候,我們技術特別多樣化,充分尊重大家的技術選擇。但是轉型到 To B 業務之後,就遇到了很多問題。舉個例子,如果從其它專案組抽調開發人員,他可能還需要花費時間熟悉另外一種程式語言,而且專案交付之後,可能還需要長期維護,這時如果人員流失,新人是很難接手該專案的。

所以,我們更堅定了要做技術拉通工作,現在百分點技術棧主要使用 Java 和 Python 兩種程式語言,以 Java 為主,Python 主要用來做一些資料分析的工作;前端用 React,程式碼託管用 git。同時,我們也制定了編碼規範,在提交時會審查程式碼,如果編碼不符合規範,不允許提交。短期來看,可能會對大家造成一些影響,但長期來看,還是有好處的,隨便開啟一個專案,所有人都能夠在十分鐘之內瞭解專案的結構。

協作方式我們也做了統一,所有的專案資料都在 Wiki 上;百分點的內部溝通使用的是 zoom us,同時我們還自己開發了翻譯管理工具,可以在平臺上看到所有的翻譯內容,避免出現重複翻譯,提高協作效率;在需求 Bug 管理方面,我們自研了適合自己工作方式的工具——PMP。

百分點也有一些自研的開源工具,主要是內部使用,例如 License 服務、正則庫、前端元件庫、微服務配置中心、自動化安裝服務、監控中心等。這些內部的共享庫複用率極高,大大節省了大家的交付成本。

三.組織建設  

To B 業務以專案為主,當專案很多且執行週期較長時,就需要一個比較好的組織管理方式來把流程標準化,這樣整個組織才可以以更標準化的方式來運作。

我們主要是以這三個方面來做組織建設,首先是統一思想,大家的思想步調需要一致,並在此基礎上提升大家的技能,當然這裡的技能包括軟技能、硬技能各個層面,例如管理技能、溝通技能、技術技能等。有了思想和技能的指導,那我們也有相應的這種方法去落實組織管理。

思想建設的目標就是統一大家的思想,有了共同的目標之後,才能去圍繞這個目標去做事情。在思想建設上,我們強調為客戶創造價值,因為 To B 專案一定是為企業、客戶服務的,只有給客戶創造出價值,客戶才會為你買單。其次,要有成本意識,企業級交付需要格外注重計算能效、管控成本;最後,我們也會做一些思想宣傳。

在具體實踐方面,我們主要有學習分享、談話和團建三種方式。

  • 學習分享:我們內部會組織關於文化價值觀的分享,讓大家談談自己對文化的理解,講講自己的故事;

  • 談話:團隊 Leader 會定期與大家交流,瞭解大家的思想狀態;

  • 團建:我們會定期組織團建,拉近大家感情。

以上活動,百分點成立了一個部門專門去落實,就是我們的組織發展部。

因為我們是以流程為驅動的,所以我們的組織建設方法也是圍繞流程來運轉的,從專案啟動、需求收集、開發、部署、交付,都有一套完善的專案交付方法論。

我們在每個專案中設定了節點,每個專案管理的節點都有具體負責人,對於該節點的輸出,我們會有明確的規範,例如產品需求文件需要包含哪些內容,概要設計如何寫,相關的程式碼約束和規範等等。

在技能方面,我們主要採取了三種方式:管理培訓、軟實力培訓、技能培訓。

  • 管理培訓:主要是針對中層研發為主,中層研發其實是企業中的實際執行者,中層研發管理的好會大大提高企業效率。

  • 軟實力培訓:針對全員培養大家綜合能力,內容包括高效溝通、衝突解決等。

  • 技能培訓:提高大家的技術水平,包括微服務實踐、高併發實踐、機器學習等。

如何落實組織建設呢?我們是有一個核心班子,這個核心班子大概有 30 多個人,同時我們還成立了相應的部門,包括組織發展部、QA 組運營組、技術管理委員會,共同去落實思想、方法和相關技能的培訓。

四.總結  

百分點做 To B 業務已經有 5 年多,也沉澱了很多自己的思考。To B 業務做起來很困難,一般來說,需要在一個行業裡紮根三到四年,才能見到成效,團隊管理、研發人員情緒都有很大挑戰。而且 To B 業務不僅是個技術問題,更多的是需要大傢俱有客戶服務意識,需要去了解客戶,教客戶如何使用系統,給客戶講清楚產品的價值等等,只有客戶成功了,我們的事情才能成功。因此,做 To B 業務一定要從內而外的對組織和個人進行升級,從思想到技術,都需要我們修煉好內功,方能應對 To B 行業面臨的挑戰。


活動推薦

與無人駕駛(或輔助駕駛)技術類似,AIOps 目標是通過數值驅動手段,藉助演算法、建模、推理等方法輔助 DevOps 提升效率,把經驗問題轉變為一個算力問題。在12月6日北京ArchSummit會議上,屆時會邀請阿里等公司技術專家來分享AI探索經驗,歡迎點選“閱讀原文”瞭解細節。


已同步到看一看



熱點新聞