研發員工指南-流程篇
這是一個新的產研團隊、新研發員工加入我們的技術體系所應遵循的技術流程規範、工具、原則合集，也是我們花費了昂貴學費換來的……經驗教訓。
1。前言
這是一個雄心勃勃、擁有強大技術傳承和寶貴技術財富的寶藏團隊，我們曾經：
2011年組建團隊，當年成為中國團購市場和本地團購市場雙料第一
2012年推行
RCA
注1
報告制度
2013年從
JobCenter
注2
、
NotifyServer
注3
和
IDCenter
注4
開始起步，量身定製自己的通用中介軟體
2014年開始開發自己的大資料技術體系
2015年所有商業應用遷入
Docker
容器叢集
2016年研發協作三劍客
CloudEngine
注5
+
iDB
注6
+
SimpleWay
注7
橫空出世，至此我們完成了“雲原生=
DevOps
注8
+
持續交付
+
微服務
+容器化”的改造
2018年社餐和團餐業務均已接入
異地雙活
注9
體系
2017年至2019年曆經整整三年久久為功的不懈努力，大資料平臺“數芯”日臻完善，已經基本覆蓋了大資料六大體系：資料採集遷移，開發協作排程，資料視覺化，資料開放共享，平臺運維管控和資料資產管理
2019年
大中臺
注10
技術體系如期收官
與業務鐵軍一路並肩走來，秉持著“平凡人可為非凡事”的信念，我們創造了無數輝煌：
帶領團隊從千團大戰中成功突圍，行業內唯一一個在正面戰場擊敗過美團的團隊（2011、2012年團購業務市場份額超過美團）
帶領團隊歷經5年廝殺成為中國第一家O2O行業納斯達克上市公司
培養出成熟的電商技術團隊，經歷過多次O2O電商大促，自主建設了異地雙活體系，日活1000+萬筆交易
量身定製了本地生活服務所需的大中臺支撐體系，集團名下各個公司各條業務線所有線上線下業務均已流程化、電子化、數字化
O2O業務最高時覆蓋全國123個城市，產品覆蓋40萬家線下門店使用
我們擁有高執行力的團隊基因，具有超強的多業務線齊頭並進能力：
啟動某行業的資訊化業務，僅一年多的時間，峰值週日均移動交易筆數 782萬筆/日
某支付營銷產品正式上線，僅僅8個月後，就交出了漂亮的答卷：活躍門店5萬家，峰值週日均交易筆數450萬筆/日
為什麼我們如此優秀？總結起來大致有三條：
一，戰役文化：有仗打仗，沒仗造仗
二，資料驅動：總部為業務鐵軍提供資料、工具、策略和打法，實時排程
三，大中臺體系：快速支撐新業務，技術支撐體系為交易保駕護航
經過十年積澱，我們形成了一系列流程、制度和原則，打造了完整的技術支撐體系和大資料中臺體系，下面我將逐一介紹。
注1：Root cause analysis （RCA） is a method of problem solving that triesto identify the root causes of faults or problems that cause operating events。我們還進一步定義了RCA報告的標準格式。
注2：JobCenter，我們2013年自研的定時任務排程與管理平臺，2015年起支援任務執行容器化。
注3：NotifyServer，2013年自研的非同步訊息可靠通知管理平臺。
注4：IDCenter，一個內部各個中介軟體能統一使用的使用者認證和許可權管理中心，中介軟體門戶。
注5：CloudEngine（簡稱CE），2016年開始自研的研發協作平臺。
注6：iDB，2015年自研的資料庫自動化運維平臺。CE出現後，打通了CE與iDB的流程。
注7：SimpleWay（簡稱SW），2016年開始自研的運維自動化平臺。CE出現後，打通了CE、iDB與SW的流程，前後貫通，一站式管理線下線上環境，透明管理混合雲。
注8：DevOps，一種思想和工作模式，提倡開發和運維協同工作，以實現快速部署和快速響應。工信部軟體司把它翻譯為“研發運營一體化”。
注9：異地雙活，指在生產環境全網靈活地在多個異地機房之間排程客戶和使用者，實現了自由擴容和多機房容災的目標。
注10：大中臺，業界定義不一，具體到我司，定義是將我司在本地生活服務領域苦心經營多年獲得的核心能力隨著業務不斷髮展、業務線不斷增多以數字化形式沉澱到平臺，不斷地將能力標準化、通用化，形成以流程、服務和資料為中心，構建起資料閉環運轉的運營體系，保證我司以及上下游合作伙伴更高效地進行業務探索和創新。
2。流程篇
一般性的流程，各家網際網路公司大同小異，我就不再贅述。下面講到的流程，要麼與我們的專有技術體系密不可分，要麼不遵守就會出大簍子。
流程大致可分為以下五類：
1。運維類
2。硬體類
3。軟體類
4。配置管理類
5。資料類
2。1運維類流程
講運維流程之前，我們先定義一下線上業務故障和事故的級別：
P0
：核心業務重要功能不可用且大面積影響使用者。響應時間：立即
P1
：核心業務重要功能不可用，但影響使用者有限，如僅影響內部使用者。響應時間：小於15分鐘
P2
：核心業務周邊功能不可用，持續故障將大面積影響使用者體驗。響應時間：小於15分鐘
P3
：周邊業務功能不可用，輕微影響使用者體驗。響應時間：小於4小時
P4
：周邊業務功能不可用，但基本不影響使用者正常使用。響應時間：小於6小時
很快我們就會用到這個故障級別。
2。1。1故障處理善後流程
很多研發同學誤以為線上出現問題後，有BUG就修BUG，修完就萬事大吉了。這是一種非常不負責任的工作習慣，說嚴重點，這屬於有始無終、有頭無尾、毫無責任感。BUG雖然不與個人績效掛鉤，但是誰捅的簍子誰負責到底。
修完BUG之後，還有三件事需要做：
1。評估影響範圍並糾正
2。撰寫RCA報告並通報
3。舉一反三防範風險
做完這三件才叫處理完了。
（一）評估影響範圍並糾正
線上出現問題後，很有可能會出現幾種我們不希望看到的情況：
資料庫出現髒資料：不僅僅是資料錯誤，最可怕的是資料不一致；
客戶
或
使用者
注1
的資產被錯誤處置：比如重複扣款，結算金額算錯，支付渠道費率變更錯誤；
首先，我們必須認認真真地評估事故的影響範圍，影響了多少條資料？影響了多少位使用者？涉及到多少客戶？其次，我們還需要逐一糾正這些錯誤。
注1：客戶和使用者的區分為：
面向C（Customer）的時候：未註冊使用者統一稱為“使用者”，已註冊使用者統一稱為“會員”；
面向B（Business）的時候：一般來說我們屬於B2B2C商業模式，B端商戶是我們的客戶。
（二）撰寫RCA報告並通報
查缺補漏之後，
責任人必須撰寫RCA報告，並將報告發送給CTO審閱，最後由CTO向全員通報
。
圖2。1 《黑匣子思維》
這裡我要重點推薦《黑匣子思維》（馬修·薩伊德2017年7月出版）這本書，航空業的“黑匣子思維”與一般人思維的根本區別在於：
一般人認為錯誤是不好的，出於本能會為錯誤找各種藉口。而這套方法論會把錯誤看成進步的契機。犯錯的人要改正，沒犯錯的人也要自省，從而杜絕重複犯錯，使整個組織，甚至整個行業都能從中獲益。
比如下面三個例子就是把錯誤變成行業進步的契機：
因衣索比亞航空961號的錯誤而要求救生衣必須出艙後再充氣
因UPS航空6號班機的錯誤而要求鋰電池必須隨身攜帶
因911事件而要求所有的飛機都安裝密碼駕駛艙門
航空業更願意正視錯誤，飛行員們總體上說對自身的失誤都抱著公開和坦誠的態度，畢竟一旦出錯就有可能身死道消。這個行業裡有強勢且獨立的組織專門負責對空難進行調查，失敗不會被當成控訴某一位飛行員的理由，而會被視為能讓所有飛行員、航空公司和管理者們學習進步的一次寶貴機會。
所以在日常技術工作中，對於事故處理，我們一向遵從航天二十字訣：
定位準確、機理清楚、可以復現、措施有效、舉一反三
。我們堅持每錯必查、錯了又錯就整改、每錯必寫，用身體力行告訴每一個研發員工直面錯誤、公開技術細節、分享給所有人，長此以往，每一次事故都會變成我們的寶貴財富，成為團隊的傳承和家底。
RCA報告的標準格式為：
背景知識（可選）
問題現象
影響範圍
問題原因
問題分析過程（可選）
解決辦法
後續處理措施（可選）
經驗教訓
RCA型別：如程式碼問題、實施問題、配置問題、設計問題、測試問題等
（三）舉一反三防範風險
有時候大家在RCA報告裡寫的“解決辦法”其實只是短期解決辦法而已，治標不治本。而作為公司裡最認真的、最負責的團隊，我們不僅僅需要亡羊補牢，還需要一勞永逸。
第一個例子：Redis雙機房資料不一致引發機具收款不能核銷紅包
某日，機具收款，使用者的openIDA和unionID落庫華北機房；次日，該使用者掃碼開啟小程式，openID B和unionID落庫，觸發兩個openID帳號合併事件，同時清理Redis快取，但程式碼只清理了華北機房快取，未清理華東機房的，導致華東機房存在髒資料。
對此如何一勞永逸解決問題呢？不能依賴於程式設計師每一次都記得修改多活機房的每一份資料，需要一個自動化機制。所以對於這種資料量不大（如低於1GB）的Redis埠，可以引入我司 的
Rotter
注2實現跨機房 Redis 實時同步。
注2：Rotter，我們自研的跨機房Redis實時同步管控系統。
2。1。2開源軟體定期更新機制流程
我們很多RCA報告總結起來就一個根本原因：開源軟體（類庫/元件）版本有BUG，被我們撞上了，新版本可能已經修復了這個BUG。所以我總是強調，對於開源軟體，最佳實踐是
保持版本更新很重要，千萬別死在那些早已被修復的BUG上
。
所以我們會這麼做：
1。定期由運維同學發起檢查，與研發同學一起確定哪些升級確有必要，升到哪一個版本
2。線上下環境先升級，觀察兩週時間，經歷幾個應用更新週期，由測試同學確認本次升級不影響業務
3。再在線上環境升級，注意一個機房一個機房的升級，別一次性把雙活機房都升級了。升一個，觀察一天，經歷完整的早中晚交易高峰時段，再升另一個
第一個例子：P0級，JDBC驅動的致命缺陷
2015年4月22日（週日）晚間，線上TaskMall工程頻繁報警，分析JVM表明在記憶體使用上確實存在問題，有大量物件不正常堆積。田志全進一步分析堆疊資訊發現，系統中有大量的CancelTask定時任務需要執行，分析JDBC原始碼發現它確實會導致CancelTask物件大量累積，從而引發頻繁FullGC。他還發現，MySQL 最新的JDBC驅動已經解決了這個缺陷……
事後線上下復現了這個問題，頻繁的大資料查詢場景下，mysql-5。1。34驅動的效能遠優於 mysql-5。0。7驅動。所以同志們啊，一定要及時升級驅動！千萬不要迷信所謂的官方出品，不要長年累月使用同一個版本的驅動或開源系統。小組長們要定期核查自己的業務用了哪些驅動或系統，要不要升級到最新穩定版本。
第二個例子：升級未成功的例子
2018年負責開發IoT平臺的潘軍發現一個致命缺陷，用來與智慧裝置做MQTT協議通訊的RabbitMQ叢集中部分節點重啟會造成裝置不能訂閱訊息。後臺報錯資訊為：
404，<<“NOT_FOUND -no binding 。shadow。get。…… between exchange ‘amq。topic’ in vhost ‘/’and queue ‘mqtt-subscription- ……qos1’ in vhost‘/’”>>
GitHub上早在2016年就有人提過這個問題，一直沒有被解決，原始碼貢獻者最後一次回答這個問題是在2018年的6月5號，但依然沒有解決。
後來這個BUG在2019年3月8日釋出的3。7。13版本里fix掉了：
Bug Fixes
Binding and unbindingoperations could fail with a NOT_FOUND channel exception if bindingtables got out of sync。
所以我決定為了規避叢集腦裂重大風險，雖然危險但還是要升級，剛好可以在春節前趁著絕大多數裝置都停機了，做一次升級。線下在此之前已經測試了一個月之久，業務一切正常。
線上版本由原來的3。7。7版本變更為3。8。9版本，也一切正常。但一個月後，開學季到來了。3月3日中午12點之後，RabbitMQ叢集開始發瘋，如下圖所示。表現為：在Connections沒有異動的情況下，各個節點的記憶體快速上漲並打滿。
圖2。2 RabbitMQ發瘋
最終迫於無奈，我們只好退回到老版本。
2。1。3核心業務上線觀察機制
經常維護核心業務的老兵都知道，系統釋出之後，不經歷幾個交易週期的波峰波谷，真不敢說釋出成功。經歷過多次磨難之後，我們定義了這樣的觀察機制：
釋出時機的選擇
灰度釋出 小心求證
釋出後觀察視窗
重大變更間隔釋出
（一）釋出時機的選擇
雖然說持續釋出可以讓大家隨時釋出，但是對於本地生活服務的核心業務，也有不建議釋出的時間視窗。
早中晚三個就餐高峰肯定是不建議釋出的
。
歷史上有好幾次慘痛教訓，釋出之後等效能開始告警的時候，卻發現故障處理小分隊都去吃飯了，等一個一個電話叫回來，小事故拖成了大事故。
（二）灰度釋出 小心求證
我們的SW有灰度釋出能力。對於核心系統，
新功能首次上線的時候，務必灰度釋出，小心求證
，不要全量釋出，以免造成大面積影響。可以在SW裡設定灰度規則，按照不同的流量規則（比如按商戶id，或按流量百分比，或按URL地址關鍵字，或按訪問IP地址等）做灰度驗證。
（三）釋出後觀察視窗
很多開發同學沒經歷過大流量系統，還習慣於釋出後等了幾分鐘就欣喜地下班跑路了。效能出現問題有一個發展的過程，量變引起質變。所以我們約定，核心系統釋出後，所有參與同學必須
一起留下來觀察至少半小時
。測試負責人宣佈釋出成功，讓大家走才能走。
（四）重大變更間隔釋出
核心系統重大更新，或者關鍵元件重大升級，必須錯開：第一天升級，第二天觀察，第三天再升級，第四天觀察。按照這個間隔釋出原則，核心系統升級一般會選擇：
週二和週四
。
不允許選擇週五做重大升級
，否則等到週六高峰期出事的時候，很多人都聯絡不上，就算電話聯絡上，也難以統一指揮和及時處理。
第一個例子：P1級，升配雙活機房RDS
我們一家公司的資料庫管理員於某日凌晨將華北和華東機房的主力RDS資料庫做了升配。在雲計算時代，對資料庫做升配降配本是一個很平常的操作。
卻不料從早高峰就出現了效能惡化的徵兆，到了午高峰前夕，形勢已不可收拾，雙活機房的主力RDS資料庫均出現了CPU使用率不高、IO正常、但連線數飆升、連線耗時過長、處理能力下降的現象，連累我司支付閘道器以及上游支付應用堵塞，交易失敗率升高。
11點41分，DBA做了RDS資料庫主備切換，備庫成為了主庫，一瞬間效能恢復了，更加說明這是阿里雲自己的問題。
當天我司一直在與阿里雲技術支援工程師溝通，對方以及資料庫核心值班人員和服務專家團隊始終未能定位問題。直到6月2日下午阿里雲團隊定位了問題，通知我司，可以簡單理解為還是阿里雲RDS資料庫的執行緒池老問題，又一次被我們撞了出來。
2019年12月25日至27日，我們一家公司做了RDS資料庫降配，例項核心小版本為rds_20191212，這個版本有BUG，因而在大訪問量的情況下引發了主備頻繁切換。事發後，阿里雲釋出了公告，隨後做了緊急修復，關閉了thread pool預設特性。
但進入2020年，它的核心小版本rds_20200331版本中該引數沿用了最佳化後的引數模板，所以thread pool特性又被打開了。我們升配升到了這個小版本之後，由於我們業務訪問量大，很快暴露了這個問題，主庫效能下降。
所以
對阿里雲RDS資料庫做升配或降配的時候，一定要單個機房順序操作，升一個觀察一天，不要一下子全升
。
第二個例子：P0級，升級雙機房關鍵工程
某日，某業務線同時升級了雙活機房的ERP工程。
結果到了早餐時段，全國多地反饋，支付寶支付時報“獲取顧客賬戶資訊失敗”。只是支付寶使用者被掃隨機出現問題，不涉及微信支付，也不涉及支付寶使用者主掃。
由於雙機房都升級了，所以一時之間難以確定根本原因在我方，還是在支付寶。查詢無果，雙機房均回滾版本，此類錯誤絕大部分消失。
所以強調一萬遍都不為過，
大型釋出上線，先上單機房，觀察一天之後再上另一個機房，就不會這麼狼狽
，連是自己的錯誤，還是支付寶錯誤，都分不清楚。華東更新了，華東有問題，華北沒問題，一目瞭然。
2。1。4重大節假日封機房機制
週六日還好，大家不會一窩蜂離開北京。但是每逢重大節假日，員工們就會提前坐火車坐飛機離開北京，即使有人值班，在此之前的更新發布也會變成一個非常危險的動作，很有可能帶來無盡的災難。
所以我們痛定思痛，由達摩院質量控制部負責人出頭約定：
每逢佳節必封版
。
第一，打一個提前量，比如提前一週封版。
第二，封版之後嚴禁做任何系統更新。
第三，如確需上線，比如緊急bugfix，必須獲得CTO的審批。
2。3軟體類流程
軟體其實包羅永珍，前後端開發，小程式開發，APP客戶端開發，太通用的流程我們就不講了。
2。3。1資料庫訪問帳號的申請和審批流程
新加入進來的同學，可能還沒有意識到我們這套技術支撐體系給大家提供了哪些好處，這是一個曾經歷過四大事務所做企業內部安全審計、登陸過NASDAQ的團隊，我們不是一個初創團隊，我們致力於讓每一個有志於成為獨角獸、有志於境外上市的初創團隊有一個成功的IT基礎：
依法合規
：有了研發協作三劍客CE+iDB+SW，大資料協作魔盒，以及它們底層依賴的TouchStone，MDC，CloudBase，磐石……（如下圖所示），直接獲得合規性，輕鬆應對上市審計，即，第一，環境變更，有稽核記錄，有操作記錄，事後可回溯，第二，使用者崗位職責與系統使用者許可權相符合，責權利對稱；
體驗統一，快速遷移，快速複製
：我們這個技術團隊的人，不管是雲縱雲停業務，還是禧雲資訊業務，不管是北京還是武漢秦皇島，不管是應用部署在線上，線下，私有云，還是公有云，認知和體驗一致，便於培訓、維護和遷移。
圖2。9 體系中第一層是完成流程協作的幾個系統
為了嚴格保證員工崗位職責與使用者許可權相符，為了避免發生各種不必要的流血事件（比如刷庫刷錯，比如一個慢查打掛資料庫，比如刪庫跑路），我們約定：
測試環境和生產環境的資料庫，統一由資料庫管理員也就是DBA管理，開發員工沒有許可權操作；
DBA管理資料庫的重要工具之一就是我們自研的iDB。
研發同學可以透過iDB提交兩種資料庫帳號的開通和許可權分配：
工程帳號
：工程訪問資料庫（讀庫或寫庫）的帳號；
個人帳號
：申請開通個人帳號及相應資料表和欄位許可權之後，方可使用iDB的“線上資料查詢”功能查詢指定機房、指定資料庫的資料。
實際例子：我要的是我以為，不是你以為
某日午高峰剛剛過去，13點23分，阿里雲簡訊報警：
【阿里雲】雲監控-應用分組下雲資料庫RDS版例項於<13：23>發生報警，
CPU使用率（98。7>80。0）
，
持續時間1分鐘
。
可怕嗎？
首先，這是峰值日，全國員工都在一線作戰共同打交易峰值。其次，在此之前機房已經為此封版，我千叮嚀萬囑咐。
結果還是有人頂風作案！
原來是一位研發員工“以為”高峰期已經過了，所以他透過堡壘機來直連 MyCat查詢交易庫，用count（*）語法查詢某個時間段內的交易筆數。交易庫做了水平分庫，拆為32個庫，因為他輸入的SQL語句沒走索引，所以32個庫併發查，一把就把RDS所在的宿主機的CPU利用率打到100%，長達一兩分鐘。
我不要你以為，我要的是我以為！
是不是隻需要叮囑大家不要在交易高峰期查詢生產資料庫就可以了呢？
不！
是！
的！
如果放大時間軸，以年為單位，只要這個口子開著，早晚會有人“不小心”把核心業務的關鍵資料庫查掛！
而且他還是用工程所使用的資料庫帳號，直連 MyCat，你不把 MyCat 日誌與堡壘機登入日誌對照，還真不一定能找到“兇手”。
所以我們應該怎麼做呢？
第一條，從技術上杜絕所有研發同學直連MySQL/MyCat的可能性：
堵住技術人員在沒有任何監管的情況下直接查生產資料庫（含私有云和公有云）的同時，必須給他們一條通路，那就是：第一，用 iDB，第二，用資料開放實驗室。iDB的線上資料查詢功能，本來也有攔截高危SQL的能力。
第二條，從技術上杜絕所有工程（包括PHP）配置檔案裡寫明文密碼的可能性：
CE和iDB建設之初，我要求的是高度自動化。工程師只是在iDB裡為應用訪問某個環境裡的資料來源申請工程帳號而已，部署和上線釋出對他來說是透明的，他根本不需要接觸到資料庫密碼這件事。他不知道明文密碼，也就沒有機會犯錯。
2。3。2核心交易流程定期壓力測試流程
每年雙十二之前，阿里巴巴和螞蟻都會對合作夥伴做壓測。以2016年為例，壓測是按照下面這四個場景逐個壓雲縱的縱橫客系統，每次壓測大約持續3～4個小時，按50 QPS遞增，直至2000QPS停止壓測：
集點加減
查詢集點詳情
集點兌換及領券（含集點凍結、領券，訊息通知，集點解凍，集點扣減等功能點）
組合壓
即既有單場景介面壓測，也有組合場景（多個介面串起來）。
除了介面壓測之外，還有一種全鏈路壓測，它適用於這種場景：第一，針對鏈路長、環節多、服務依賴複雜的系統，全鏈路壓測可以更快更準確地定位問題；第二，系統必須有完備的監控報警，在壓測出現問題的時候可以隨時終止操作；第三，有明顯的業務峰值和低谷。比如說美團採用自主開發的pTest壓測工具對核心交易做全鏈路壓測。
在全鏈路壓測的研究中，業界基本形成了四種解決方案：
第一種是
基於TCP/HTTP流量錄製和回放
，如網易的tcpcopy，twitter的diffy，都是在應用外部基於網路層實現流量的錄製、回放和倍數放大。
第二種是
基於Java AOP錄製和回放
，在Java應用內透過AOP切面程式設計方式實現的流量錄製和回放，並且有Mock機制，可實現寫流量的迴歸驗證。阿里早年間有一個DOOM，後來它被放入阿里雲的雲效裡，這是一個收費專案。據稱阿里內部幾乎所有交易核心系統都透過DOOM去做引流回歸測試。
第三種是
基於介面和預置CSV資料
，典型代表是阿里雲的PTS和ARMS（Application Real-Time Monitoring Service）服務。PTS+ARMS就是個
JMeter注4
線上豪華版，所以JMeter指令碼可以轉為PTS指令碼。
第四種是
基於RPC呼叫錄製和回放
，如滴滴的RDebug。
毋庸諱言，核心交易流程更新頻繁，如果不定期做一次體檢，早晚會出事，而且一出事就是大事。
壓測應由達摩院質量控制部發起，各個業務產研團隊必須通力配合
。
大家要注意做壓測的初心，做壓測方案的時候別跑偏了。壓測的目的有四條：
第一條，
瞭解現狀
，得到現有應用方案在一個或多個特定配置下的效能基準值。
第二條，
效能調優
，根據壓測，必然能夠暴露很多問題，比如我們認為怎麼著也得壓到1000 QPS吧，但實際上壓到500 QPS服務就爆掉了，那就得調優了。
第三個，
把握未來
，根據基準定期觀察新版本的效能是上升了還是下降了，所以幾個大版本釋出之後必須再安排一次壓測。
第四個，
容量預估
，交易筆數翻一倍怎麼擴容，翻兩倍怎麼擴，不能拍腦袋。
實際例子：PTS+ARMS
2019年7月，針對ERP系統、開放平臺和支付閘道器這條鏈路做了基於阿里雲PTS+ARMS和
支付寶擋板機注5
的壓力測試方案。
圖2。15 壓力測試的主要工作內容
出於安全考慮，本次壓力測試與原有業務做了物理隔離，同時引入了支付寶擋板機，形成了以下三個特點：
壓測環境業務形成閉環
與生產機房物理隔離
啟用了與生產環境完全獨立的外網域名
同時為了便於識別，訂單生成規則和生產環境也不一樣。
本次壓測的大致做法為：
將已有的JMeter指令碼匯入PTS自研互動中，使用 PTS 自研引擎；
或匯入JMeter指令碼並使用原生JMeter引擎進行壓測，PTS 提供自定義的壓力構造和監控資料匯聚等產品服務；
或使用PTS自研雲端錄製器，零侵入錄製業務請求並匯入PTS自研互動中進行進一步設定；
監控工具：OpenFalcon，以及阿里雲的監控工具，可以對Mesos、MyCat、Nginx、Redis、ZooKeeper等的I/O、CPU、記憶體使用情況、平均負載情況、ESTAB連線數進行監控。
當然，上述方案開發、搭建和維護的成本太高，也並不是最優選擇。
注4：Apache JMeter是一款經典的基於Java的壓力測試工具。
注5：支付寶擋板機是支付寶提供的，可以免費使用的支付閘道器mock系統。
2。4配置管理類流程
一個專業的技術團隊可以沒有云原生，可以沒有大中臺，可以沒有中介軟體，但不能沒有配置管理。從配置管理上一葉知秋，能看出一個團隊是否專業，能走多遠。
2。4。1日常程式碼分支管理流程規範
我司程式碼統一使用Gitlab做維護和管理，但不對公網開放。
注意事項：
嚴禁開發同學私自上傳專案程式碼到公有的程式碼託管平臺上
。受國內外開源思想影響，程式設計師愛逛各大開源社群、程式碼託管平臺，時常會在無意間將公司的工程程式碼釋出到公網！這樣會被全網白帽子、駭客和生態維護者（如螞蟻）偵測到，導致伺服器的IP地址、使用者名稱密碼、資料庫帳號密碼等洩露，引發不可收拾的災難。這些程式碼託管平臺包括但不限於：Github、GoogleCode、碼雲、碼市、CSDN Code、百度效率雲等。
實際例子：外部安全事故
2015年4月14日，多位Yahoo北京前員工將內部程式碼包括金鑰上傳到了github，以至於他們的安全部門開出了S0 tickets。
2017年8月28日，大疆宣佈“大疆威脅識別獎勵計劃”，然而在此之前，大疆農業事業部某員工將企業私有原始碼上傳到了github。就職於大疆競對公司Department13公司的美國人Kevin Finisterre向大疆提交了一份31頁的報告，列出了他與其同事找到的漏洞，包括透過github找到的大疆AWS的SSL憑證金鑰的漏洞。2019年4月上旬，深圳法院對事件中進行該違規操作導致程式碼和金鑰洩露的員工作出了一審判決，該員工被以侵犯商業秘密罪判處有期徒刑六個月，並處罰金20萬元。
2。4。1。2分支管理
為了減輕開發人員拉取和合並分支的壓力，常用分支只維護以下四個：
開發分支（Feature）
測試分支（Release）
上線分支（Release-online）
穩定分支（Master）
對照下圖，我們下面一一論述。
圖2。17 分支管理示意圖
（一）開發分支
由研發經理從Master分支上拉取作為研發人員開發使用，對應的分支為Feature。對應多個開發任務，新增版本號即可。
（二）測試分支
開發自測完成後，由研發經理合併到測試分支（Release），提交給測試人員進行測試驗證。
（三）上線分支
測試完成後，測試人員傳送郵件給開發人員、產品經理、達摩院質量控制部。驗收通過後，研發經理將測試透過的Release分支合併到Release-online分支，再由測試人員做上線前驗證。
（四）穩定分支
Release分支上線後，對應的功能驗證透過，再經過一天業務高峰低谷的執行，確認無問題後，將Release-online分支合併到Master分支。
（五）緊急分支
僅僅針對線上的緊急BUG必須立即修復的，從Master分支拉取Hotfix分支做緊急上線，上線驗證透過必須合併到Master分支。
注：本文源自《CLOUDZ集團研發員工指南》，為禧雲資訊內部編著的技術交流資料。
