作者 |  老壯

眼中的ToB業務

自己算是阿里的老兵了，從實習開始一直投身在 toB 業務的質量保障領域內，不能說是資深的專家，但所經歷的、感受的業務特點和體會還是具有一定的代表性，希望能通過這篇文章，總結一下過往，并能和已經躬身進入這個業務領域，以及將要進入的同學們產生一些共鳴。

服務專有釘客戶的這兩年，更像是場戰斗，只有躬身入局的勝利者才能這個競爭激烈的市場上存活。專有釘的深度用戶已經將專有釘作為日常工作的一部分，跟我們使用釘釘一樣，是生產力工具;再小的體驗問題，再小概率出現的偶發問題，在大規模日活下，都極易被放大和激化。

即便都是協同辦公的業務訴求，也會因為客戶行業特性不同而大相徑庭。所帶來的定制化需求量會隨著不同行業客戶的增加出現指數上升，這對產品架構的適配、產品研發交付服務鏈路上的資源投入均帶來巨大的挑戰。

雖然服務這些不同行業的頭部客戶很艱難，但是一旦認可我們，口碑就會在這些行業內迅速傳播，帶動客戶的增長。

結合跟 ToC 產品的對比，我眼中 ToB 業務特別明顯的特點有如下幾個：

質量保障的難度

2年的建設，專有釘已經成為國內第一大政務協同辦公平臺產品。對于這份答卷很驕傲，組織也給予了認可，但同時，焦慮、壓力也在持續積累，因為這個業務實在是太難做了。

1.客戶對質量容忍度極低

專有釘在釘釘產品矩陣中，所承擔的責任是服務好政府客戶、行業頭部大型企業客戶。這些客戶最大的特點，對數字化是有較深的理解和應用，并非小白客戶。我們需要展現出較他們更強的專業性，較之前他們所使用產品更好的體驗，他們才能接受我們，認可我們，把我們當成數字化改革的同路人。

原先做公司內部產品，在項目周期緊張的情況下，最先想到的解決方案就是保障主干業務，但做專有釘不能固化這樣的意識，因為有 VIP 客戶這種角色存在。他們是決策者，但也是一個個人，不同人的產品使用路徑、所認為的核心產品功能均不同，但有一個相同點，就是對質量的容忍度都極低，客戶認為，已經為產品買單了，高質量就應該是標配。這帶來的結果是“主干業務”的定義變得邊界模糊，在有限的項目周期內，如何做到測全?

另一個特點，是出現問題時，有人可能會質疑，這明顯是你們系統運行指標監控沒做好。但公有云上常規的系統指標監控方案在專有云環境下，通常無法運轉。問題排查難度大，造成口碑積累的難度也極大。

2.安全生產難做

專有釘跑在專有云環境中，資源、數據、產品，所有的一切都屬于客戶所有，做安全生產，一要嚴守用戶信息安全，二要嚴控方案所消耗的資源成本。專有云網絡基礎設施復雜，目前尚無成熟的全鏈路問題排查工具，且不同客戶環境的云底座、中間件差異大，方案復用度低。

組織協同配合困難，安全生產會涉及產研、交付、一線運維、二線運維、三方isv，且后四者在不同的項目也通常會由不同的公司組織來承接。能力參差不齊，職責清晰的難度大。

3.測試技術融入研發過程的迫切性高

專有釘產品在極其有限的版本周期內，既要實現 70~80 個業務需求，又要嚴格遵守質量門禁，壓力極大。質量團隊在堅守質量原則的基礎上，需要在研發自測階段提供給研發效率高、覆蓋廣的測試能力，以此將質量風險消滅在項目前期。

開放生態的背景下，大規模的isv產出物將融入專有釘產品，質量團隊需要做質量兜底。將 isv 納入到質量保障體系中，任重而道遠。

4.云原生適配難度大

專有云發展了多年，市場上不乏競品?？蛻艨粗袑Ｓ嗅數膶I性，但要讓他替換昂貴的云底座成阿里云飛天底座，可能就會迎難而退，發展云原生是出路之一。 當前云原生產品缺少標準化，這對測試工作就是場災難。辛苦完成了測試，由于客戶現場部署架構不同，所用的云原生產品規格不同，導致 bug 頻出，打臉的同時也無奈。非標下，測試結論無法復用，甚至顯得無意義。

當前缺少成熟的安全生產、質量保障的云原生產品，線上可運維性差，穩定性保障能力不足，巧婦難為無米之炊。

5.測試工作具有專業性難度

除了要攻克專有云的技術屏障，在其之上測試功能、性能、安全生產能力建設外，還需要針對核心業務做業務專項測試，比如 IM、音視頻、文檔等。

略有成效的方法

上述難點有些是做專有釘產品第一天就要面對的，比如專有云的技術屏障，而有些是在業務發展中逐漸出現，比如云原生的適配難度。應對這些難點的策略方法也同樣并非一蹴而就，在攻克老問題，迎接新問題的反復中，專有釘質量團隊也沉淀了一套適配當前 ToB 業務的質量保障體系，體系取名“定坤”。

1.數據為基礎

專有釘產品從誕生便以推動政企客戶數字化改革為己任，高質量、高穩定、優體驗是這個產品必有的特性，保障體系從建設之初便和產品本身一樣，以數字化來驅動，把所有可定義的過程、結果均盡可能地做了結構化，并在其基礎上做加工、分析、決策、驅動。

數字化驅動質量風險防控

質量/過程風險數據的結構化，需要標準化的研發流程、缺陷流轉規則做匹配，讓離散的數據通過規則分析，具備決策和驅動能力。專有釘的研發流程將集團產品 Aone 的能力用到了極致，需求管理、版本管理、缺陷管理全部標準化執行，完全可以作為 Aone 的樣板工程存在。

數字化推動研發測試能效提升

專有釘的客戶對數據極其敏感，數據安全等級極高，引流回放等的獲取均存在天然屏障，如何獲取盡可能多的脫敏數據，用到質量保障策略和方案中，是急需但必須謹慎對待的課題。

線上客戶數據獲取困難，但線下每一個功能用例的執行流量卻蘊含著價值，流量基于 jvm-sandbox 獲取?？梢詮闹型诰虺鰏ql執行、緩存使用等過程中的性能隱患;也可以沉淀出業務調用鏈路，基于此，結合故障等級定義、監控覆蓋情況、預案覆蓋情況，形成產品安全生產能力視圖和工作臺，直觀、高效地開展安全生產工作。下圖就是其中一條流量，存在緩存重復調用的性能隱患。

數字化推動產品體驗提升

專有釘產品以客戶端作為用戶體驗的前沿陣地，集團提供了較為成熟、豐富的移動端專項評測能力，我們在此基礎上完善了整體調度、自動觸發執行，以及自動生成競品報告等能力，用競品分析數據來推動客戶端體驗的提升。專有釘在 PC 端有著更加廣泛的應用前景，科創端是當前國家大力發展的方向，而集團缺少相應的專項評測能力，我們采取了自建的模式，目前已具備端穩定性、端性能的PC端專項評測能力。

2.風險防控為基調

由于客戶的容忍度低下，交付周期又極短，無法通過長時間的灰度或者靠出現問題后做改進的方式來提升產品穩定性，而必須在轉交付前做好充足的測試、防控工作。

高可用測試防控穩定性風險

阿里云飛天底座相對成熟，但云原生不同，商用剛開始，尚未經受過磨煉，在交付前必須進行高可用測試。這里要給阿里云 ADP 團隊做個廣告，他們已有相對成熟的平臺來進行中間件的高可用測試，業務團隊只需整理出基于業務的測試場景即可。

故障演練防控安全生產能力不足帶來的風險

最理想的狀態是在每個版本轉交付前，將增量業務的故障等級定義做完善，同時梳理出增量業務的全鏈路，并進行故障演練，推動完善安全生產能力，包括監控、故障降級/恢復預案、強弱依賴治理等等(當然現實比較殘酷，項目周期過于緊張，無法每個版本都進行常態化演練)。專有云上缺少免費的演練平臺支持(富裕的可以參考下AHAS)，我們采用專有化chaosblade的方案來實現能力，同時搭建平臺用來沉淀演練場景，便于常態化高效執行。

容量規劃防控機器資源風險

專有云上的容量規劃完全是理想很美好，現實很殘酷的工作。最早做容量規劃的時候，過于單純，將“具備線性擴容”能力認為是云上機器的標配能力。但現實十足的打臉，實際測試下來完全不具備線性擴容能力，這導致在實驗室環境測試下來的容量需求，做推算后和實際不符，必須在每個專有云環境下做真實的性能壓測，成本和可行性都備受挑戰。當前雖然用了各種算法來做盡可能接近的估算，但依然無法減少真實壓測這一環節的資源消耗。

項目研發過程質量風險管理

基于質量、風險數據，結合標準化的研發、交付、服務流程，制定了全生命周期軟件質量分體系，覆蓋了版本研發階段、交付階段以及上線使用階段整個生命周期，分成準入準出標準和質量分兩個載體。當前版本研發階段的質量分和標準相對成熟，質量分用于事后總結，做后續版本的問題規避，而標準則代表著能否進入集成回歸，能否轉交付。

要達到標準，獲得質量高分，均是有前人總結的方法論，結合這些方法論，并融合質量分數據現狀，“在合適的時機智能化地提供解決方案，規避風險”，這是當前建設中的質量風險管理能力的目標。

3.研發效能做加持

2年，我們一直在為業務奔跑，但只要有間隙，提升研發效能必定被提上日程，因為我們堅信這是提升幸福感的出路之一。

自測工作臺提升自測效能

要做好開發自測，首先要做的是聯合開發，跟PM爭取到固定的、合適的自測時間。我們提供了開發主動要求的功能自動化、測試用例，同時提供了專有云下的服務鏈路調試、版本前后鏈路對比、測試數據工廠、服務MOCK、基于流量數據的性能隱患識別、性能問題初步篩查等增值能力?！霸皆绨l現 bug，修復成本越低”，這乃亙古不變的道理。未來要思考的是，即使自測時間被榨干，也能在提測前充分自測。

分層自動化提升測試效能

自動化從來沒有像當前如此被需要，測試團隊需要，研發團隊也需要，交付團隊更需要，根本還是業務特性和當前所處階段決定?；ヂ摼W產品搬的迭代周期，軍工級的產品品質要求。通過自動化做越多的內容，就有越多的人力出來覆蓋那些原本無人力、無技術覆蓋的部分。自動化測試我們認定分層的理念，不同層就應該用合適的自動化手段。

專有云服務端低代碼自動化平臺具備支持 LWP、HSF、HTTP接口測試的能力，同時能支持服務端SDK的自動化測試。之所以叫“低代碼”，是因為這個平臺從孕育開始(在宜搭出現之前)就開始秉承“低代碼”的理念，讓所有想做接口自動化的同學能上手，無關編碼能力，目前提供了簡單配置實現、流量自動生成兩種用例生成方式。下圖是配置頁面：

客戶端不僅采用了 UI 自動化做端到端的功能覆蓋，同時對 JSAPI、端上 SDK支持自動化測試。UI自動化還需要考慮一碼多端適配，即一套代碼能在不同的端穩定運行，端越多，自動化發揮的價值就越顯著，節省的人工投入就越可觀。

自動化不僅僅體現在功能測試上，在性能測試、客戶端體驗專項測試，均是優先考慮通過自動化來實現。一站式性能測試平臺實現從執行、結果分析、瓶頸定位、基線控制的閉環自動化?？蛻舳梭w驗的大多數專項測試均能自動觸發執行，自動生成競品對比分析報告。在產品版本質量保障過程中，自動化也無所不在，自動生成質量日報、自動生成轉交付申請、自動生成版本質量報告、每天定時自動播報風險......

質量標準提升組織協同效能

釘釘希望攜手合作伙伴一起投入數字化改革的浪潮中，隨著生態開放，釘釘提供底層能力，讓 ISV 在上面隨意暢享，實現他們的夢想。夢想的實現不能務虛，而是需要實實在在的協同機制、約定來保障，質量就是所需要保障的其中一塊。專有釘的開放平臺上連接了數千個 ISV 產出的應用、數量龐大的 SDK 和 API，為了保護自己，也更好的協助 ISV 提供高質量的產品，測試團隊制定了ISV 產物的質量準入標準，同時逐步將我們用的成熟的測試能力提供給 ISV，讓質量保障更加的容易，更加的公平。

結語

專有釘產品當前的質量保障體系勢必需要應對更深層次的挑戰，以持續保障我們的專有釘以軍工級的質量來幫助到我們的客戶，始終讓體系的名字“定坤”實至名歸。