一、貝殼業務帶來的質量挑戰
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）微服務化
貝殼的一個變化流程從採購軟件到自研單體到微服務，業務底層基礎設施日均幾十億的調用，也讓技術迭代非常快，基本已全面擁抱微服務。由於業務的特點，所以我們在高性能，高可用和安全上有特別的要求。
2. 貝殼業務帶來的挑戰
上述詳細了介紹貝殼業務特點，這樣的特點會帶來各種挑戰：
（1）微服務下的量變質不變
微服務從 soa 發展過來，被越來越多的企業 it 生態所採用，它高內聚，低耦合的特徵，豐富的開源組件，確實可以讓業務需求快速被交付出去。但對測試來說挑戰更大了，模塊變多了，發佈變多了，測試一次任務變複雜了，迴歸輪次和範圍變多，環境更不穩定， 同時我們還要保持高性能，高可用。
（2）歷史債務協同非標的質量損耗
多種技術棧，多類重構，會持續放大我們的迴歸工作量，不一樣的研發工作，協同交流方式，都會加大我們的質量損耗。
（3）複雜業務下的測試數據，環境與迴歸
產業互聯網由於線上線下的結合，再加上微服務的技術體系，測試數據，環境搭建和迴歸的難度更加大了，一次測試需要有房源，客源，經紀人，合同，樓盤等多個系統配合，嚴重的情況會涉及到幾百個字段聯調，怎麼快速構造環境和數據驗證邏輯正確性，這些都非常挑戰我們的基礎設施建設。
（4）跨多領域質量解決方案
由於形態多樣，和之前提到的組織變化快，我們在歷史上有很多質量領域的問題和解決方案嘗試，如：移動端的，頁面的，服務端的，性能的，接口等等，如何複用能力和抽象共性，而不是不是散點的解決，非常考驗我們的質量架構設計能力。
質量問題涉及各環節、各角色，系統全面且高可用的提升質量和效率要靠體系化建設。
二、貝殼質量體系
貝殼質量體系的建設，分成理論、策略和信息來進行講解。
1. 貝殼質量體系建設-質量三段論
各類業務、產品形態的質量保障的底層邏輯都是類似的，分成看的見的質量，難看見的質量和看不見的質量。
看的見的質量好感受，比如這個工廠流水線的成品，是好的，壞的。
難看見的是中間這個車牀的過程工藝，機械臂的規格，抓取的力度，流水線的速度，這些因素可能會導致最後的成品的好壞，這是需要仔細觀察才能看見的部分。跟古代的行軍打仗一樣，一次戰役的勝利，可能在兵操演練，沙盤推演這些過程細節中決定了，最後打的一刻只是過程的檢驗，好的質量也是一樣的，這一部分難看見，但需要被看見。
最後是看不見的那一部分， 也是很關鍵的一部分。 好的質量在最初的設計，研發的編碼，架構選型，產品的交互，需求設計，異常的考慮在最開始被設計好的。質量意識能力會帶來好的過程，最後是好的質量、好的交付物，好的交付物又會通過平臺通過中間的過程工藝平臺和交付物質檢的平臺推動整個質量意識的提升。
我們的質量體系建設也是圍繞這幾部分展開的，技術，產品形態有千種變化，這個背後的邏輯是一致的。質量體系也是按這個來構建。
2. 貝殼質量體系建設-策略
我們通過這個框架策略明確了質量部的目標，做事原則，和崗位角色，分工協作機制。
最下面的是大家做事的原則層， 我們希望通過標準化，線上化，平臺化來做質量建設，以平臺帶動組織的質量能力，並且通過各項指標讓組織能自我迭代。
最終大目標是通過業務 QA 推進組織轉型升級，通過技術促進商業價值健康快速交付，組織最後的質量要高，而質量是所有人努力纔得到的。
細節方面，最底層的質量意識會標準化貝殼產業的全流程規範，從需求到發佈，全流程規範化、標準化，質量賦能體系也會有質量分、質量培訓等等，提高質量意識。
3. 貝殼質量體系建設-細則
這裏有四張網， 分別對應看得見的質量檢查平臺 KeTest， 難被看見的過程工藝部分KeOnes，和質量意識提升部分，以及線上運營能力部分。
（1）KeTest平臺
KeTest 平臺統一質量和解決方案標準，把各專項能力一站式提供，爲全集團賦能，整體對各業務做質量保障，尤其產業互聯網在自動化迴歸，數據，環境，高性能，高可用等部分做深入的能力建設。
（2）KeOnes平臺
KeOnes 平臺從開發編碼到發佈全環節打通協同能力，解構了產研 28 個環節，數十個系統信息孤島，並通過 ci，cd 流水線能力，集成 KeTest 的質檢能力建設 4 道質量閘門，在各環節快速反饋質量問題，通過 KeTest，KeOnes 絕大部分質量問題能在線下環節發現。
（3）線上環節
在線上環節，我們通過自動化巡檢，監控，預案演練，熔斷，限流，降級等能力保障線上運行的穩定性。
（4）線下環節
在線下環節，我們會持續做質量意識提升的事項，標準制定，考試通過，培訓，活動從源頭提升人和組織的質量能力。
每一部分具體怎麼做呢？下文將會詳細爲大家展開。
三、貝殼質量體系建設
1. 基礎設施建設 - KeTest質量平臺
KeTest是爲貝殼集團整體質量提供的一站式解決方案平臺，類似QA的工作艙，核心提供5大能力，解決方案層面，爲各業務形態，提供工具，測試策略，環境，執行計劃，結果通知，幫助各業務團隊快速搭建質量解決方案, 質量能力能快速到一個標準水位。
質量學院是整體大家的知識大腦和經驗倉庫，也和質量素養具體活動，認證等打通。質量開放服務提供api輔助在消息，指標統計，基礎測試框架等通用邏輯部分，質量工具提供10餘種專項能力，比如自動化，性能，數據構造等，質量度量通用分析質量建設能力水位線。接下來會把裏面核心中比較有特色產能功能、特色專項的進行介紹。
2. 基礎設施建設-sosotest
微服務化架構下接口特別多，鏈路長，模塊也多，迴歸成本，自動化建設成本都很高，sosotest提供了多模式的使用方式適合不同能力的測試人員，和不同場景的業務，能快速編寫自動化用例。
目前自動化用例製作支持網頁和python後臺編寫的模式，也支持http，dubbo多種協議類型，同時提供mock，用例錄製，自動生成等能力，解決鏈路長，模塊多的情況，在此基礎上，自動化用例也和持續集成，自測，線上巡檢深度整合發揮價值。
目前用例數有4.6W，全集團87%的業務線在使用sosotest，其中也有不少研發貢獻的用例,某些業務線近30%用例由研發貢獻。基礎類的服務100%已經接入。
3. 基礎設施建設-KeDiff平臺
Diff測試在大型互聯網系統比較常用，所以我們調研了業內的流量回放方案後，自助研發了基於流量回放的Diff測試平臺-KeDiff。
平臺流量採集是通過公司的監控系統獲取到線上日誌，爲了減少對服務影響，我們採用的是離線方式。針對日誌解析後，首先在基準環境回放3次，獲取到一些動態變化的噪音，比如時間戳等參數，然後分別在對比環境和基準環境回放，將請求返回的json進行對比，並去除噪音，最終輸出差異報告。這就是Diff平臺的實現原理。
截止目前，Diff平臺承接了貝殼65個子系統，110個服務的業務，完成數2600+次迴歸測試，執行過1370萬+條Case，測試效率提升50%。
未來，Diff平臺還有三大規劃；第一拓展更多協議的支持，例如Dubbo協議、Rpc協議；第二Diff報告的完善，通過代碼覆蓋率進行更精準的測試分析；第三Diff平臺與質量中臺和KeOnes系統的打通，成爲QA測試中的質量卡點和更便捷的提效工具
4. 基礎設施建設-虛擬城市
虛擬城市是另外一個解決產業互聯網線上線下鏈路長，角色多，非標體系環境比較有特色的建設。
google之前有sandbox 沙盒測試的概念， 貝殼打造了一個全業務的沙盒，從數據底層，到終端業務，這個環境貫穿始終，涉及幾十個系統，有超過5000+測試賬號，線上巡檢，驗收，問題復現都可以用這個環境來驗證，同時也應用在新業務，比如開城等全線上測試， 運營同學也利用該環境來宣講、演示。
5. 基礎設施建設-環境治理+數據構造
（1）環境治理
微服務架構下，環境治理也是老大難的問題：配置維護難 、擴展成本高 、環境使用亂。
我們構建了測試容器雲平臺，提供統一的環境治理能力，底層封裝了K8S，在編譯構建，配置管理，測試數據管理及環境擴展等方面有相應的支持。也在借鑑泳道的模式，有一套主幹環境，每次特性修改，只拉起對應工程的環境，其他模塊去連主幹環境。目前接入的項目有1000+， 有效環境1600+。
首先，配置管理上，平臺提供多語言類型配置標準化模板抽象方案，配合各業務方進行配置改造，平臺實現一套環境內的配置模板自動實例化。
其次，環境擴展上，結合容器化技術，實現服務及外部資源無需申請，提供配置管理和服務基準庫解決方案，實現環境一鍵複製，快速擴展，動態伸縮。
最後，在環境管理上，提供不同類型環境的使用規範和約束，統一管控，包括路由配置，環境佔用，自動部署，回滾等機制。
目前全公司接入項目1000多個，有效環境套數1600多套。
（2）數據構造
長鏈路，多角色，非標的業務特性，讓一次測試的數據構造變得比一般業務更加麻煩，海豚平臺一站式提供測試所需數據的平臺。通過這個平臺，把所有測試同學的數據準備的經驗和複雜的流程沉澱下來，讓一個普通的qa，以及rd、pm都能直接使用，快速的構造出數據，使數據構造工作變得更輕鬆和高效。
平臺的優勢：
第一，是低門檻。熟悉業務的測試同學添加功能後，其他不熟悉業務的人也可以方便的造數據，他只要知道自己想要什麼數據，就可以構造出來。
第二，是靈活性。平臺有多種構造數據的方式，靈活組合數據配置單。並且平臺有提供給外部的接口調用，用於自動化case等。
第三，是可視化。所有人構造的數據內容和執行情況、平臺的使用情況的流量統計，都能一目瞭然。
平臺的整體架構：主要的3個組成部分：環境信息部分、構造方式部分，數據生成部分。
環境信息部分，統一維護數據構造所依賴的一些基礎信息；構造方式部分，支持數據構造的多種構造方式，如sql執行、dubbo請求、http請求、kafka消息、redis操作等，複雜的構造場景可能還需要這些構造方式的組合形式。
6. 基礎設施建設-性能測試平臺
貝殼服務端性能測試平臺 KePTS 是面向貝殼服務端業務的一站式性能測試數據構造和性能測試執行的壓測平臺。
KePTS旨在持續簡化性能測試執行的工作，讓開發和測試同學可以將更多的精力迴歸到關注服務端性能問題本身。
KePTS的優勢：
（1）數據自動化
業務壓測數據的構造的有效性、真實性和快捷性，一直以來都是貝殼服務性能測試的痛點，KePTS支持從服務端日誌按照定製規則篩選請求，自動構造爲線上壓測請求，執行壓測的同學只需編輯簡單的規則，就能生成壓測數據用於壓測。
（2）腳本自動化
KePTS底層依賴的發壓能力了來自開源壓測工具grinder，發壓使用groovy腳本。爲降低壓測執行門檻，方便非JAVA背景同學快速上手，KePTS封裝了多種典型的壓測場景作爲模板，並根據壓測數據自動生成壓測腳本，降低壓測工具的使用門檻。
（3）靈活可擴展
壓測數據節點和發壓節點靈活可擴展，適合全鏈路級別的線上壓測，賦能貝殼多個方向的核心服務端業務。
基於KePTS，服務端性能測試效率提升超30%，執行和支持了104次全鏈路及線上容量，支持超過300次各類線下壓測和故障演練，攔截150+性能問題攔截，助力貝殼服務端性能容量類故障數的持續收斂，打造高質量的貝殼服務端中後臺。
7. 基礎設施建設-KeMtc
KeMTC 平臺是貝殼移動端測試一站式工具平臺，爲貝殼移動端提供通用的自動化測試方案。
從上至下看，數據化度量是衡量KeMTC的效果和業務應用平臺的程度的，主要用來指導平臺解決問題的能力和平臺的升級改進。
如通過發現Crash問題數量，來衡量客戶端的穩定性；通過自動化case數，來衡量客戶完成自動化的能力；通過雲真機的使用次數，來衡量雲真機的提效能力；通過平臺的訪問量、項目接入量，來衡量平臺的認可程度。
流程提效，作爲KeMTC當前的目標，主要關注當前產研過程的各個環節，部分環節可以通過KeMTC進行提效。藍色的部分就代表，可通過KeMTC的能力，可以優化的流程環節。綠色指通過其他平臺可以進行提效。KeMTC主要關注於藍色的流程點。
App穩定性、自動化等4個專項平臺是KeMTC的核心能力工具，每個工具平臺又有其針對的解決問題的手段。
拓展能力和公共能力，作爲核心能力的補充項。拓展能力指在開發這4個工具過程中，延伸出的非計劃內的功能，可以作爲未來更多工具項的切入點。公共能力是指幾個工具項通用的一些功能，也是可以給其他工具可使用的功能。底層就是公司內的一些基礎設施了。
以上是一站式平臺一部分的能力項做的介紹，接下來會對難看見產業協同過程的平臺做介紹，包括對它的應用也重點講講CI / CD的部分。
8. 規則-產研協同平臺-Ke Ones
中間是CI / CD流水線的建設，下面是數據AI，從需求、測試、線上目標，CICD流水線分四五個階段，拆分出來幾十個環節，爲什麼要做KeOnes這件事？
首先是協同方式不同，有時不停開站會，對質量來說，過程質量損失特別多，信息傳遞會失真，所以我們統一搬到了線上，對CI / CD也重新做了標準化的建設。
需求階段項目迭代、需求做了管理，研發階段會支持CR、環境搭建、測試准入，測試階段會做自動化測試、專項測試，發佈階段之前發佈也有多個系統，把它統一到一個發佈系統，爲這個發佈系統導入各項能力。
比如怎麼去做發佈、健康度檢查，如何預發、銷售量、全量。線上運營跟線上監控打通，這是CI / CD的流水線，他的各種能力項跟它是深度結合的，包括性能測試等等跟它也有深度的結合。
CI / CD內部也有個迎合項目，從需求、創建、拉一個分支、合併、發佈上線各個環節拆分開都出流水線，每個動作都自動驗證，分支拉出來跑一些Case，從中間到要發佈上線人工卡點完成後又在另外環境跑，就是把結果反饋快速回饋出來。
比如每次構建會在統一在一個羣裏，失敗也會及時發出通知，羣裏每天可以看到多少分支創建、拉取，構建有沒有問題，是不是可以通過。
規則是代碼掃描、自定義的規則進行檢查，包括第三方的業務上的規則，都可以裏面去檢查，也應用了Diff等等各方面的能力項。
9. 質量意識標準建設-貝殼質量指標1.0發佈
質量意識非常重要，帶着質量意識去做貝殼產業全流程的規範。質量部會對CTO線各個研發產品進行考試，就在一年前，所有的人蔘加了考試，如何寫需求、提測、線上出現故障5分鐘之內應該做什麼、第一時間如何止損，然後再做什麼？一切變成標準化的動作宣佈、宣貫、考試，經過考試也方便了產業協同平臺不用面對非標業務的場景。
中間是貝殼發佈的質量指標白皮書，定義瞭如何看全環節的質量，各個環節指標究竟要看哪些，這個指標也會跟各個團隊的研發對齊。
未來會形成貝殼分，對每個組織和個人通過指標去給評分和評價，全面質量管理的細節，清楚交付質量、構成質量、發佈和運營質量，目前非常關注故障和5分鐘定位問題的佔比和需求變更等。
質量意識建設上也有雙環驅動，一部分驅動團隊、一部分驅動個人、團隊會對其進行質量診斷，由QA對雙週的各種質量做診斷，數據是怎麼樣的、有什麼風險、實時的告訴大家，也會展開多種質量活動。
比如去掃描誰改得最多、單測自測怎麼樣，也會發質量認證。個人會被分配一些質量任務，這些任務完成得好會有質量積分，目前已經開始在啓動這件事，找Bug、對ADC進行培訓，雙環聯動，對員工有一些激勵和認證和榮譽晉升的加分。
貝殼也做了千人衆測，海外版要發行的時候，公司很多人蔘與衆測，線下經紀人、線上法務、財務都參與，也跟研發團隊中心一起啓動，如果自測得好會頒發自測證書和獎牌，也有一些相關活動，通過各種質量活動提升用戶體驗和線上系統穩定性形成產業意識關注質量。
故障治理是貝殼裏很有特色的地方，有一個一兩千人的貝殼消防團隊，貝殼發生故障時，消防隊第一時間會看到，信息傳達非常快，這建立了對線上故障問題處理響應的操作機制，是貝殼的特色，貫徹得很徹底，另外是對故障的定級抓得非常的嚴格，會讓質量的保障得到重視。
四、貝殼質量保障體系未來發展
前面介紹了KeOnes、質量意識提升和工具平臺的細節，這部分講講保障體系未來的發展。前面做過總結，經過這一年多的建設，從19年的測試研發1：5提升到了1：9.2，故障率下降了74%，SLA達到4個9，吞吐量增長142%。
未來會做些什麼？首先是智能化測試，包括做用於自動生成圖像的自動化識別，未來更多的去往智能化應用做優化或者是AI、機器學習等方面。
混沌工程也會加強，QA會做故障演練預案，跟研發團隊一起做一些提高，看熔斷、降級是否足夠好，夠不夠快速，未來也會體系化這件事。
第三部分是Devops升級，藉助一些平臺上的工作機制來做，目前做了一部分，讓線上化之後也有數據，各種指標都可以看到，未來會對devops成熟度去做更精細化的認證管理等。
五、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，大家玩得高興，組隊玩王者榮耀，也有籃球社區，也可以組隊踢足球。
我們內部也有微信羣，天天鬥圖和聊天，最近這一年鬥圖少了一些，因爲特別忙，忙也是因爲缺少同學、缺各大牛。我們招聘崗位是各方面都是有的，前面提到的混沌工程智能化開發同學就很需要，針對移動端、服務端偏業務，包括對各種質量解決方案特別有理解的同學我們也很需要，把建設持續交付經驗可以推動業務團隊做變化的這種同學我們也需要，工作兩三年的同學想在一個比較不錯的組織裏面去進行職業生涯成長，貝殼質量部就是很不錯的團隊，可以幫助做各項提升，我們對P4、P5、P8、P9的同學有不同項目去一起成長，高階的管理崗位也在招聘，所以崗位非常充分，歡迎大家投遞簡歷， 郵箱地址：[email protected].
作者介紹：
項旭，貝殼找房基礎平臺中心質量平臺賦能部總監
負責貝殼多類產品線質量和效率保障，促進貝殼產研devops轉型升級，先後負責貝殼集團整體質量體系建設，產研協同平臺，服務治理等多個領域攻堅。2010～2018年曾任職騰訊，負責騰訊廣告，廣點通，開放平臺，認證空間等質量體系建設和質量保障工作，負責騰訊廣告系統平臺，流量業務，研發效率等團隊質量管理工作，具有多年大型互聯網複雜架構和業務形態質量保障經驗，質量和效能平臺建設，產研devops升級轉型的經驗。
本文轉載自公衆號雲加社區（ID：QcloudCommunity）。
原文鏈接：