1、貝殼業務帶來的質量挑戰前端
如上圖左上部分是買房的業務場景與電商業務場景的對比,電商通過選購、下單、接單、配送、完成,幾步就能把商品買了,但房產交易中的環節就很是複雜。
好比處理二手房,先四處尋找房源,找到後進行委託,讓經紀人去代看,房子合適了會簽約,再房屋覈驗、資質審查,對方可能會進行解抵押,再網籤,這時須要作房屋評估,以後面籤、批貸、繳稅、過戶,領取房產證,客戶還會抵押到銀行,再放款,最後還有一個物業交割纔會結束。這其中有多類角色協同,跨部門,跨組織,甚至和政府打交道。
二手房只是其中一個業務領域,貝殼的業務還有新房、裝修、租賃等各類業務形態;從業務視角來看它貫穿業務前臺、中臺、saas服務、基礎設施多個領域,共同完成一次房產交易。
中間是貝殼的業務架構,前端經過 C 端的貝殼、鏈家的 APP、M、PC、小程序爲C端用戶提供服務,經過 B 端的 Link、A+等APP、PC 服務爲經紀人提供做業平臺。在重點場景中有 400 電話、IM 的即時通信。整個流程中,咱們會有搜索推薦、VR實勘、交易平臺等等。
下面是 SaaS 中臺,圍繞着房源、客源、經濟人,多個環節一塊兒工做。最下面是基礎設施,有樓盤字典、安全風控、大數據、基礎架構,有各類各樣的技術設施支撐房產交易的運營。
最右邊是技術架構上,咱們如今用戶觸達層有 android,ios app,小程序,PC/M站,IoT, 接入層是網關,流量和業務網關,服務層多使用微服務架構,存儲層等以redis,mq,hadoop 等開源的組件爲主。
經過對貝殼業務架構、技術架構以及業務場景來分析,貝殼的業務特色以下:
(1)業務複雜
鏈路長,線上線下角色多,數據量多且複雜。
(2)形態多樣
從 IoT 到直播領域,VR,到大數據,機器學習,到服務億萬用戶的各類應用,橫跨多種領域和應用形態。
(3)技術多變多樣
貝殼業務發展很是快,伴隨着業務組織調整也多;同時也有很是多的框架和組件版本;伴隨着業務發展須要須要很是多的重構,升級工做。
(4)微服務化
貝殼的一個變化流程從採購軟件到自研單體到微服務,業務底層基礎設施日均幾十億的調用,也讓技術迭代很是快,基本已全面擁抱微服務。因爲業務的特色,因此咱們在高性能,高可用和安全上有特別的要求。
python
上述詳細了介紹貝殼業務特色,這樣的特色會帶來各類挑戰:
(1)微服務下的量變質不變
微服務從 soa 發展過來,被愈來愈多的企業 it 生態所採用,它高內聚,低耦合的特徵,豐富的開源組件,確實可讓業務需求快速被交付出去。但對測試來講挑戰更大了,模塊變多了,發佈變多了,測試一次任務變複雜了,迴歸輪次和範圍變多,環境更不穩定, 同時咱們還要保持高性能,高可用。
(2)歷史債務協同非標的質量損耗
多種技術棧,多類重構,會持續放大咱們的迴歸工做量,不同的研發工做,協同交流方式,都會加大咱們的質量損耗。
(3)複雜業務下的測試數據,環境與迴歸
產業互聯網因爲線上線下的結合,再加上微服務的技術體系,測試數據,環境搭建和迴歸的難度更加大了,一次測試須要有房源,客源,經紀人,合同,樓盤等多個系統配合,嚴重的狀況會涉及到幾百個字段聯調,怎麼快速構造環境和數據驗證邏輯正確性,這些都很是挑戰咱們的基礎設施建設。
(4)跨多領域質量解決方案
因爲形態多樣,和以前提到的組織變化快,咱們在歷史上有不少質量領域的問題和解決方案嘗試,如:移動端的,頁面的,服務端的,性能的,接口等等,如何複用能力和抽象共性,而不是否是散點的解決,很是考驗咱們的質量架構設計能力。
質量問題涉及各環節、各角色,系統全面且高可用的提高質量和效率要靠體系化建設。
android
2、貝殼質量體系ios
各種業務、產品形態的質量保障的底層邏輯都是相似的,分紅看的見的質量,難看見的質量和看不見的質量。
看的見的質量好感覺,好比這個工廠流水線的成品,是好的,壞的。
難看見的是中間這個車牀的過程工藝,機械臂的規格,抓取的力度,流水線的速度,這些因素可能會致使最後的成品的好壞,這是須要仔細觀察才能看見的部分。跟古代的行軍打仗同樣,一次戰役的勝利,可能在兵操演練,沙盤推演這些過程細節中決定了,最後打的一刻只是過程的檢驗,好的質量也是同樣的,這一部分難看見,但須要被看見。
最後是看不見的那一部分, 也是很關鍵的一部分。 好的質量在最初的設計,研發的編碼,架構選型,產品的交互,需求設計,異常的考慮在最開始被設計好的。質量意識能力會帶來好的過程,最後是好的質量、好的交付物,好的交付物又會經過平臺經過中間的過程工藝平臺和交付物質檢的平臺推進整個質量意識的提高。
咱們的質量體系建設也是圍繞這幾部分展開的,技術,產品形態有千種變化,這個背後的邏輯是一致的。質量體系也是按這個來構建。
面試
咱們經過這個框架策略明確了質量部的目標,作事原則,和崗位角色,分工協做機制。
最下面的是你們作事的原則層, 咱們但願經過標準化,線上化,平臺化來作質量建設,以平臺帶動組織的質量能力,而且經過各項指標讓組織能自我迭代。
最終大目標是經過業務 QA 推動組織轉型升級,經過技術促進商業價值健康快速交付,組織最後的質量要高,而質量是全部人努力才獲得的。
細節方面,最底層的質量意識會標準化貝殼產業的全流程規範,從需求到發佈,全流程規範化、標準化,質量賦能體系也會有質量分、質量培訓等等,提升質量意識。
redis
這裏有四張網, 分別對應看得見的質量檢查平臺 KeTest, 難被看見的過程工藝部分KeOnes,和質量意識提高部分,以及線上運營能力部分。
(1)KeTest平臺
KeTest 平臺統一質量和解決方案標準,把各專項能力一站式提供,爲全集團賦能,總體對各業務作質量保障,尤爲產業互聯網在自動化迴歸,數據,環境,高性能,高可用等部分作深刻的能力建設。
(2)KeOnes平臺
KeOnes 平臺從開發編碼到發佈全環節打通協同能力,解構了產研 28 個環節,數十個系統信息孤島,並經過 ci,cd 流水線能力,集成 KeTest 的質檢能力建設 4 道質量閘門,在各環節快速反饋質量問題,經過 KeTest,KeOnes 絕大部分質量問題能在線下環節發現。
(3)線上環節
在線上環節,咱們經過自動化巡檢,監控,預案演練,熔斷,限流,降級等能力保障線上運行的穩定性。
(4)線下環節
在線下環節,咱們會持續作質量意識提高的事項,標準制定,考試經過,培訓,活動從源頭提高人和組織的質量能力。
每一部分具體怎麼作呢?下文將會詳細爲你們展開。
sql
3、貝殼質量體系建設docker
微服務化架構下接口特別多,鏈路長,模塊也多,迴歸成本,自動化建設成本都很高,sosotest提供了多模式的使用方式適合不一樣能力的測試人員,和不一樣場景的業務,能快速編寫自動化用例。
目前自動化用例製做支持網頁和python後臺編寫的模式,也支持http,dubbo多種協議類型,同時提供mock,用例錄製,自動生成等能力,解決鏈路長,模塊多的狀況,在此基礎上,自動化用例也和持續集成,自測,線上巡檢深度整合發揮價值。
目前用例數有4.6W,全集團87%的業務線在使用sosotest,其中也有很多研發貢獻的用例,某些業務線近30%用例由研發貢獻。基礎類的服務100%已經接入。
數據庫
Diff測試在大型互聯網系統比較經常使用,因此咱們調研了業內的流量回放方案後,自助研發了基於流量回放的Diff測試平臺-KeDiff。
平臺流量採集是經過公司的監控系統獲取到線上日誌,爲了減小對服務影響,咱們採用的是離線方式。針對日誌解析後,首先在基準環境回放3次,獲取到一些動態變化的噪音,好比時間戳等參數,而後分別在對比環境和基準環境回放,將請求返回的json進行對比,並去除噪音,最終輸出差別報告。這就是Diff平臺的實現原理。
截止目前,Diff平臺承接了貝殼65個子系統,110個服務的業務,完成數2600+次迴歸測試,執行過1370萬+條Case,測試效率提高50%。
將來,Diff平臺還有三大規劃;第一拓展更多協議的支持,例如Dubbo協議、Rpc協議;第二Diff報告的完善,經過代碼覆蓋率進行更精準的測試分析;第三Diff平臺與質量中臺和KeOnes系統的打通,成爲QA測試中的質量卡點和更便捷的提效工具
json
虛擬城市是另一個解決產業互聯網線上線下鏈路長,角色多,非標體系環境比較有特點的建設。
google以前有sandbox 沙盒測試的概念, 貝殼打造了一個全業務的沙盒,從數據底層,到終端業務,這個環境貫穿始終,涉及幾十個系統,有超過5000+測試帳號,線上巡檢,驗收,問題復現均可以用這個環境來驗證,同時也應用在新業務,好比開城等全線上測試, 運營同窗也利用該環境來宣講、演示。
(1)環境治理
微服務架構下,環境治理也是老大難的問題:配置維護難 、擴展成本高 、環境使用亂。
咱們構建了測試容器雲平臺,提供統一的環境治理能力,底層封裝了K8S,在編譯構建,配置管理,測試數據管理及環境擴展等方面有相應的支持。也在借鑑泳道的模式,有一套主幹環境,每次特性修改,只拉起對應工程的環境,其餘模塊去連主幹環境。目前接入的項目有1000+, 有效環境1600+。
首先,配置管理上,平臺提供多語言類型配置標準化模板抽象方案,配合各業務方進行配置改造,平臺實現一套環境內的配置模板自動實例化。
其次,環境擴展上,結合容器化技術,實現服務及外部資源無需申請,提供配置管理和服務基準庫解決方案,實現環境一鍵複製,快速擴展,動態伸縮。
最後,在環境管理上,提供不一樣類型環境的使用規範和約束,統一管控,包括路由配置,環境佔用,自動部署,回滾等機制。
目前全公司接入項目1000多個,有效環境套數1600多套。
(2)數據構造
長鏈路,多角色,非標的業務特性,讓一次測試的數據構造變得比通常業務更加麻煩,海豚平臺一站式提供測試所需數據的平臺。經過這個平臺,把全部測試同窗的數據準備的經驗和複雜的流程沉澱下來,讓一個普通的qa,以及rd、pm都能直接使用,快速的構造出數據,使數據構造工做變得更輕鬆和高效。
平臺的優點:
第一,是低門檻。熟悉業務的測試同窗添加功能後,其餘不熟悉業務的人也能夠方便的造數據,他只要知道本身想要什麼數據,就能夠構造出來。
第二,是靈活性。平臺有多種構造數據的方式,靈活組合數據配置單。而且平臺有提供給外部的接口調用,用於自動化case等。
第三,是可視化。全部人構造的數據內容和執行狀況、平臺的使用狀況的流量統計,都能一目瞭然。
平臺的總體架構:主要的3個組成部分:環境信息部分、構造方式部分,數據生成部分。
環境信息部分,統一維護數據構造所依賴的一些基礎信息;構造方式部分,支持數據構造的多種構造方式,如sql執行、dubbo請求、http請求、kafka消息、redis操做等,複雜的構造場景可能還須要這些構造方式的組合形式。
貝殼服務端性能測試平臺 KePTS 是面向貝殼服務端業務的一站式性能測試數據構造和性能測試執行的壓測平臺。
KePTS旨在持續簡化性能測試執行的工做,讓開發和測試同窗能夠將更多的精力迴歸到關注服務端性能問題自己。
KePTS的優點:
(1)數據自動化
業務壓測數據的構造的有效性、真實性和快捷性,一直以來都是貝殼服務性能測試的痛點,KePTS支持從服務端日誌按照定製規則篩選請求,自動構造爲線上壓測請求,執行壓測的同窗只需編輯簡單的規則,就能生成壓測數據用於壓測。
(2)腳本自動化
KePTS底層依賴的發壓能力了來自開源壓測工具grinder,發壓使用groovy腳本。爲下降壓測執行門檻,方便非JAVA背景同窗快速上手,KePTS封裝了多種典型的壓測場景做爲模板,並根據壓測數據自動生成壓測腳本,下降壓測工具的使用門檻。
(3)靈活可擴展
壓測數據節點和發壓節點靈活可擴展,適合全鏈路級別的線上壓測,賦能貝殼多個方向的核心服務端業務。
基於KePTS,服務端性能測試效率提高超30%,執行和支持了104次全鏈路及線上容量,支持超過300次各種線下壓測和故障演練,攔截150+性能問題攔截,助力貝殼服務端性能容量類故障數的持續收斂,打造高質量的貝殼服務端中後臺。
KeMTC 平臺是貝殼移動端測試一站式工具平臺,爲貝殼移動端提供通用的自動化測試方案。
從上至下看,數據化度量是衡量KeMTC的效果和業務應用平臺的程度的,主要用來指導平臺解決問題的能力和平臺的升級改進。
如經過發現Crash問題數量,來衡量客戶端的穩定性;經過自動化case數,來衡量客戶完成自動化的能力;經過雲真機的使用次數,來衡量雲真機的提效能力;經過平臺的訪問量、項目接入量,來衡量平臺的承認程度。
流程提效,做爲KeMTC當前的目標,主要關注當前產研過程的各個環節,部分環節能夠經過KeMTC進行提效。藍色的部分就表明,可經過KeMTC的能力,能夠優化的流程環節。綠色指經過其餘平臺能夠進行提效。KeMTC主要關注於藍色的流程點。
App穩定性、自動化等4個專項平臺是KeMTC的核心能力工具,每一個工具平臺又有其針對的解決問題的手段。
拓展能力和公共能力,做爲核心能力的補充項。拓展能力指在開發這4個工具過程當中,延伸出的非計劃內的功能,能夠做爲將來更多工具項的切入點。公共能力是指幾個工具項通用的一些功能,也是能夠給其餘工具可以使用的功能。底層就是公司內的一些基礎設施了。
以上是一站式平臺一部分的能力項作的介紹,接下來會對難看見產業協同過程的平臺作介紹,包括對它的應用也重點講講CI / CD的部分。
中間是CI / CD流水線的建設,下面是數據AI,從需求、測試、線上目標,CICD流水線分四五個階段,拆分出來幾十個環節,爲何要作KeOnes這件事?
首先是協同方式不一樣,有時不停開站會,對質量來講,過程質量損失特別多,信息傳遞會失真,因此咱們統一搬到了線上,對CI / CD也從新作了標準化的建設。
需求階段項目迭代、需求作了管理,研發階段會支持CR、環境搭建、測試准入,測試階段會作自動化測試、專項測試,發佈階段以前發佈也有多個系統,把它統一到一個發佈系統,爲這個發佈系統導入各項能力。
好比怎麼去作發佈、健康度檢查,如何預發、銷售量、全量。線上運營跟線上監控打通,這是CI / CD的流水線,他的各類能力項跟它是深度結合的,包括性能測試等等跟它也有深度的結合。
CI / CD內部也有個迎合項目,從需求、建立、拉一個分支、合併、發佈上線各個環節拆分開都出流水線,每一個動做都自動驗證,分支拉出來跑一些Case,從中間到要發佈上線人工卡點完成後又在另外環境跑,就是把結果反饋快速回饋出來。
好比每次構建會在統一在一個羣裏,失敗也會及時發出通知,羣裏天天能夠看到多少分支建立、拉取,構建有沒有問題,是否是能夠經過。
規則是代碼掃描、自定義的規則進行檢查,包括第三方的業務上的規則,均可以裏面去檢查,也應用了Diff等等各方面的能力項。
質量意識很是重要,帶着質量意識去作貝殼產業全流程的規範。質量部會對CTO線各個研發產品進行考試,就在一年前,全部的人蔘加了考試,如何寫需求、提測、線上出現故障5分鐘以內應該作什麼、第一時間如何止損,而後再作什麼?一切變成標準化的動做宣佈、宣貫、考試,通過考試也方便了產業協同平臺不用面對非標業務的場景。
中間是貝殼發佈的質量指標白皮書,定義瞭如何看全環節的質量,各個環節指標究竟要看哪些,這個指標也會跟各個團隊的研發對齊。
將來會造成貝殼分,對每一個組織和我的經過指標去給評分和評價,全面質量管理的細節,清楚交付質量、構成質量、發佈和運營質量,目前很是關注故障和5分鐘定位問題的佔比和需求變動等。
質量意識建設上也有雙環驅動,一部分驅動團隊、一部分驅動我的、團隊會對其進行質量診斷,由QA對雙週的各類質量作診斷,數據是怎麼樣的、有什麼風險、實時的告訴你們,也會展開多種質量活動。
好比去掃描誰改得最多、單測自測怎麼樣,也會發質量認證。我的會被分配一些質量任務,這些任務完成得好會有質量積分,目前已經開始在啓動這件事,找Bug、對ADC進行培訓,雙環聯動,對員工有一些激勵和認證和榮譽晉升的加分。
貝殼也作了千人衆測,海外版要發行的時候,公司不少人蔘與衆測,線下經紀人、線上法務、財務都參與,也跟研發團隊中心一塊兒啓動,若是自測得好會頒發自測證書和獎牌,也有一些相關活動,經過各類質量活動提高用戶體驗和線上系統穩定性造成產業意識關注質量。
故障治理是貝殼裏頗有特點的地方,有一個一兩千人的貝殼消防團隊,貝殼發生故障時,消防隊第一時間會看到,信息傳達很是快,這創建了對線上故障問題處理響應的操做機制,是貝殼的特點,貫徹得很完全,另外是對故障的定級抓得很是的嚴格,會讓質量的保障獲得重視。
4、貝殼質量保障體系將來發展
5、Q & A
Q:出現故障貝殼如何追責、如何防止甩鍋?A:出現故障貝殼怎麼追責,這個問題問得特別好,透明真實是第一要素,當故障出來的時候在羣的「消防隊」當即會爆發出來。咱們對QA要求是若是有問題、故障異常等第一時間在大羣裏面暴露,暴露完了之後,把發生的進度狀況在裏面透明化。如何防止甩鍋,故障誰都不肯意看到,你們相互甩鍋是由於以爲故障很差,不但願它發生在本身身上。可是有時不這樣,有架構師說,每一個故障都是像金子通常寶貴。QA、RD或者不相關架構師,甚至有故障專家組會很真實剖析問題自己,找到根因,理解透徹後和你們對齊,不會由於故障就懲罰,不會有通報批評。 Q:系統發佈會自動更新配置庫嗎?A:在發佈時咱們也有變動的流程,無論是一次代碼變動、配置變動、數據庫變動都會經過一個線上平臺發佈出去。配置庫是否是能夠管理起來是嗎?這是線上化管理起來的,有一些配置平臺去負責,坦率的說咱們的配置的平臺也有在收斂,咱們作太多了,在配置平臺比較多的狀況下,整個微服務裏面在配置中心來作,有些是業務封裝是業務線上的平臺,全部這些都是能夠追溯的。
Q:質量監控體系如何創建?A:監控有多種監控,前端監控研發團隊也有燈塔、海神,QA也有自動化運維,偏業務的監控線上跑。端上有QA的自動化,後端蒐集各個服務,服務也有監控、日誌也會蒐集,查看日誌的異常,流量監控檢測各類反饋碼、定製監控指標,測試的階段自動化能力經過持續集成跑、自動去跑,有問題能夠及時告警出來。 Q:混沌工程何時開始,實現效果怎麼樣?A:混沌工程剛剛起步,前面也沒有真正作,可能會結合研發運維,在低峯時段好比凌晨考慮哪些服務要啓動其降級熔斷,在上游作一些內容看全部團隊對這個響應是否是足夠快、是否是工具化的,甚至能夠不用消防隊資源,但目前還不算特別的成熟的建設,下一次騰訊雲分享會對細節作介紹了,爭取作得更好。 Q:質量意識建設應該從哪入手?貝殼如今取得了哪些成效?A:質量意識的建設須要自上而下,須要有團隊的氛圍。我剛CTO面試的時候談到百度工程師文化、谷歌工程師文化,好的工程師文化下的質量意識必定是自然好的,若是不是那就須要有不少手段,好比剛來的時候不停普及質量三段論,要參加考試,作完以後85分以上纔是經過,甚至要求高層也參與考試,因此入手應該是自上而下的造成團隊氛圍。 Q:貝殼取得哪些成效?A:一直在作,成效是故障變少了一些,前面也說了四個9,若是一個研發工程師可以關注到他的代碼掃描出來的結果,主動進行修改;若是一次發佈是 R D本身可以看到 Ke Ones 各類數據,能夠點按紐發出去,這個團隊質量已經很強的、文化也很好,咱們有不少業務團隊研發會寫自動化的case,會主動貢獻,甚至有時候排名在有些QA排名之上,這是長期活動讓其有了這種意識。 Q:混沌工程實現自動化和智能化在貝殼有規劃嗎,實現難點和關鍵點有哪些?A:混沌工程和作的各項Diff、引流,它的實現難點都是否是在質量自己,而在於整個研發體系IT生態是怎樣的,監控是否是足夠好,對線上的服務運維調度是否是足夠的牢固很關鍵,若是連線上發生的狀況都不知道,也沒法作降級熔斷,咱們若是去作混沌工程就是不停埋炸彈,這確定是不行的,IT生態裏面微服務的架構,各方面組件使用得是否規範,關鍵點是突破這些基礎設施。 智能化是有規劃的,在移動端的自動化的時候,對圖像的識別包括將來作Diff也用一部分的AI,也是開源的,智能化應用場景很是多,包括Diff如何篩選線上流量,流量跟最後運行的代碼關係如何關係得上,性能如何自動識別性能優先,此次性能是否經過,也有不少應用場景咱們是有規劃的咱們也在招人。 Q:選擇 jenkins 而不選擇其餘的 如 k8s等的緣由是什麼?A:選擇jenkins是歷史上就用得比較多,持續集成作得比較好的仍是jenkins。 k8s是容器化的集成平臺,上層的應用平臺,包括也有團隊最開始沒有 k8s,直接用原生的去作事,可是後面逐漸統一。前幾年也用docker作環境隔離,其實用docker作事情也依賴於基礎架構、IT生態,作容器化須要找好路由關係,這些解決得好就好推動,作路由的時候用各類服務目錄,把每一個分組作好,標籤對應就比較容易。 Q:虛擬城市是否是能夠替換預發佈環境?A:虛擬城市沒有準備替換預發佈環境,虛擬城市有各類用途,預發佈各個模塊之間也有預發佈,虛擬城市是徹底從B端、C端到後端徹底的打通,線下和線上的應用都很是的成熟,各個業務線、各個模塊預發佈,比較封閉的環境都沒法這樣作,因此不能去替換,雖然預發佈虛擬城市能夠用來作演示,但他們的關係不是徹底的同樣的,因此沒有準備作替換。 Q:貝殼質量部的文化建設是如何進行的,目前還在招聘哪方面的人才,期待加入?A:這個問題太好了,咱們貝殼質量部成立一年多,文化建設很是好,咱們有不少活動:去年質量部的活動是去作飛盤,兩人三組,包了一個體育場去PK,分了二十個組,各個組PK,你們玩得高興,組隊玩王者榮耀,也有籃球社區,也能夠組隊踢足球。
咱們內部也有微信羣,每天鬥圖和聊天,最近這一年鬥圖少了一些,由於特別忙,忙也是由於缺乏同窗、缺各大牛。咱們招聘崗位是各方面都是有的,前面提到的混沌工程智能化開發同窗就很須要,針對移動端、服務端偏業務,包括對各類質量解決方案特別有理解的同窗咱們也很須要,把建設持續交付經驗能夠推進業務團隊作變化的這種同窗咱們也須要,工做兩三年的同窗想在一個比較不錯的組織裏面去進行職業生涯成長,貝殼質量部就是很不錯的團隊,能夠幫助作各項提高,咱們對P四、P五、P八、P9的同窗有不一樣項目去一塊兒成長,高階的管理崗位也在招聘,因此崗位很是充分,歡迎你們投遞簡歷,郵箱地址:xiangxu003@ke.com.