環(huán)信馬曉宇：環(huán)信的SaaS敏捷開發(fā)實(shí)踐

近日，由Worktile主辦的「2019敏捷大會(huì)--北京站」在北京東升國際科學(xué)園成功舉辦，環(huán)信聯(lián)合創(chuàng)始人馬曉宇受邀出席，并結(jié)合自己創(chuàng)業(yè)過程中的所見、所得、所想做了《SaaS敏捷開發(fā)實(shí)踐》主題分享，與到場的200余位來自各大公司的企業(yè)高管、CTO、研發(fā)總監(jiān)、敏捷教練、項(xiàng)目經(jīng)理等共同探討了以敏捷開發(fā)的“ 流程—實(shí)踐—思想—團(tuán)隊(duì)轉(zhuǎn)型 ”為主題的相關(guān)內(nèi)容。

現(xiàn)場，環(huán)信聯(lián)合創(chuàng)始人馬曉宇從一個(gè)云服務(wù)創(chuàng)業(yè)公司的角度，分享了該如何去實(shí)現(xiàn)敏捷開發(fā)，以及在親身創(chuàng)業(yè)實(shí)踐中的經(jīng)驗(yàn)和教訓(xùn)。以下是根據(jù)馬曉宇現(xiàn)場演講內(nèi)容進(jìn)行的梳理部分：

1.SaaS需求管理，有何輕重緩急之分?

創(chuàng)業(yè)公司的需求來自項(xiàng)目經(jīng)理、研發(fā)、客戶等方方面面，也會(huì)經(jīng)常面臨各種各樣的bug。就bug的輕重緩急而言，環(huán)信聯(lián)合創(chuàng)始人馬曉宇總結(jié)了三種類型的bug，即嚴(yán)重bug,功能bug,性能bug。

結(jié)合自身的創(chuàng)業(yè)經(jīng)驗(yàn)，馬曉宇認(rèn)為比較嚴(yán)重的bug，需要團(tuán)隊(duì)立刻去執(zhí)行，去解決;而功能性的bug需要團(tuán)隊(duì)進(jìn)行排期，可能會(huì)花幾周的時(shí)間去迭代修復(fù)的;談到性能bug，他認(rèn)為是最難解決的，舉例來說，當(dāng)我們在設(shè)計(jì)的時(shí)候，系統(tǒng)一上線就能支持百萬用戶甚至億級用戶的自由伸縮，往往是不現(xiàn)實(shí)的。環(huán)信的系統(tǒng)從最開始上線，到現(xiàn)在經(jīng)歷了多個(gè)版本迭代，最終從測試用戶，上百用戶，到現(xiàn)在的幾千萬日活。所以，在SaaS需求管理上需要去平衡不同功能的需求程度。

2.關(guān)于SaaS迭代開發(fā)，應(yīng)注意什么?

創(chuàng)業(yè)公司在服務(wù)端上線周期基本上是一個(gè)月，上線有兩個(gè)注意事項(xiàng)，一個(gè)是回退方案，即做到要求的方案都可以回退，遇到問題時(shí)可以及時(shí)做到回退。另一個(gè)是兼容性問題，一個(gè)產(chǎn)品面對不同的用戶存在這不同的兼容性問題，這時(shí)我們需要做開關(guān)，如果產(chǎn)品上線可能造成某方面的損失，可以選擇做降級開關(guān)來處理，保證部分功能實(shí)現(xiàn)。

移動(dòng)端的上線需要注意發(fā)版問題，馬曉宇舉例說，當(dāng)做工具云時(shí)，在很短的周期內(nèi)出了一版，但是沒有測到嚴(yán)重的bug，隨即上線了后續(xù)更新的版本，這就會(huì)在用戶體驗(yàn)上大打折扣。

3.SaaS灰度發(fā)布系統(tǒng)是如何運(yùn)作的?

做SaaS有一個(gè)基于租戶的灰度發(fā)布。一是AB測試，AB測試是一種用于提升產(chǎn)品轉(zhuǎn)化率、優(yōu)化獲客的方法。當(dāng)我們想測試哪個(gè)注冊頁面轉(zhuǎn)化率高時(shí)，我們就可以上線兩個(gè)版本的頁面，通過一周、一月的注冊數(shù)據(jù)監(jiān)測比例來衡量哪個(gè)頁面效果好。在做云服務(wù)，SaaS時(shí)，就是基于租戶的驗(yàn)證，同樣可以適用這種方法。

前后端灰度，就是所有的前端根據(jù)cookie中的租戶id，轉(zhuǎn)發(fā)到不同版本的后端服務(wù)。如果進(jìn)來之后，cookie解決這個(gè)租戶ID，就可以寫個(gè)腳本，根據(jù)當(dāng)前給的配置對應(yīng)的版本打造對應(yīng)的服務(wù)，這是一個(gè)常用的功能。

移動(dòng)端灰度，就是移動(dòng)端登錄后，從路由服務(wù)器請求訪問地址。以做移動(dòng)端的經(jīng)驗(yàn)來說，某一個(gè)用戶想登到指定的版本如何來做?我們可以做DNS解析，就是手機(jī)端不是先去試圖訪問服務(wù)，而是先去訪問我們做的解析入口，當(dāng)前是哪個(gè)租戶，用戶ID是多少，移動(dòng)端什么版本，應(yīng)該訪問哪個(gè)后臺(tái)版本，然后整個(gè)服務(wù)會(huì)打造相應(yīng)的后臺(tái)版本。如果公司有海外客戶，就可以通過DNS解析到海外的配置，移動(dòng)端的路由可以根據(jù)不同用戶的區(qū)域做不同的配置，鏈接到不同的服務(wù)和版本。

在活動(dòng)的演講環(huán)節(jié)，講師為嘉賓傾囊分享，嘉賓與講師思維碰撞，為活動(dòng)掀起了陣陣高潮。

Worktile高級架構(gòu)師，WTC成員，孫敬云

分別從研發(fā)的困境、DevOps是什么、對DevOps工程化的個(gè)人分析以及DevOps的實(shí)戰(zhàn)入門這幾個(gè)方向來為大家?guī)怼禗evOps實(shí)戰(zhàn)：工程化管理你的DevOps平臺(tái)》

“有很多的工具用起來真的是無孔不入，什么東西都能幫你解決，基本上不需要你打開任何的東西，你只需要鍵盤鼠標(biāo)點(diǎn)一點(diǎn)就能解決。但是我相信沒有最好的實(shí)踐，只有最合適的實(shí)踐，每個(gè)團(tuán)隊(duì)如果想實(shí)踐DevOps，只有你不斷的探索，你才能找到你自己團(tuán)隊(duì)中最合適的那個(gè)DevOps解決方案。因?yàn)椋赫J(rèn)真可以把一件事做對，用心可以把一件事做好。”

石墨文檔研發(fā)負(fù)責(zé)人，李子驊

圍繞關(guān)注“非功能需求”與“DevOps相關(guān)”兩個(gè)關(guān)鍵性的話題為大家?guī)矸窒怼睹艚菟枷朐诋a(chǎn)品周期的延伸》

“產(chǎn)品周期指數(shù)指的是我們產(chǎn)品的迭代周期，我們知道一個(gè)產(chǎn)品可能會(huì)有需求的提出，需求的評審，需求的確定，以及我們實(shí)際的開發(fā)測試和交互。我們知道從01年敏捷開始到現(xiàn)在已經(jīng)有越來越多的項(xiàng)目在使用敏捷。其實(shí)現(xiàn)在敏捷已經(jīng)變成一種常態(tài)，這個(gè)時(shí)候討論敏捷的被大家的忽略點(diǎn)就變得非常有意義。”

著名精益&敏捷轉(zhuǎn)型專家—王明蘭

從我們現(xiàn)在所處于的不確定性、異變性的時(shí)代環(huán)境著手，為大家?guī)矸窒怼洞蛟霽UCA時(shí)代的敏捷型組織》

“VUCA最早來源于冷戰(zhàn)時(shí)期，由美國哈佛商學(xué)院提出。講的是在現(xiàn)在這個(gè)時(shí)代，世界越來越不確定性，越來越異變，越來越不可預(yù)測，我們已經(jīng)進(jìn)入到了VUCA時(shí)代，我們再也不能用原來的那種傳統(tǒng)的、計(jì)劃驅(qū)動(dòng)的方式來工作，因?yàn)闀r(shí)代太不確定性，大家要擁抱變化。敏捷本身也是從2001年敏捷研修院起來也是在那樣一個(gè)時(shí)代背景下，越來越發(fā)展壯大。如果倒回來很多年之前，敏捷不會(huì)發(fā)展壯大，因?yàn)槲覀冞€沒有進(jìn)入這樣的時(shí)代。”

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。