易觀數(shù)科 | 快速迭代能否真正提升效率？
易家分享錄? 第1期
每一次分享，都是一次新的啟航。易觀內(nèi)部每周例行開展技術(shù)分享活動，對于分享人而言是一次精神上的挑戰(zhàn)和鍛煉，對于聽眾來講亦會帶來新的思考和收獲。贈人玫瑰，手留余香?，F(xiàn)將分享內(nèi)容以“易家分享錄”欄目化的形式輸出，以饗更多讀者。
本期分享嘉賓是易觀運維工程師盆哥，他以快速迭代為主題，探討了如何提高開發(fā)效率和增長實踐的問題，一起來聽聽他的分享吧~
“快速迭代”是當下IT互聯(lián)網(wǎng)圈的流行標語，其思路源于敏捷開發(fā)模式——部分上線-反饋-修改-上線-再循環(huán)，因此又可稱之為敏捷迭代。對比完備測試后上線的傳統(tǒng)迭代， 敏捷迭代具有問題發(fā)現(xiàn)快和上線速度快的優(yōu)點，這既是互聯(lián)網(wǎng)思維的精髓，又是占得市場先機的法寶。
現(xiàn)實中不少團隊在嘗試敏捷迭代，但換來的結(jié)果卻是日常熬夜上線搞的大家身心疲憊，團隊的戰(zhàn)斗力也急劇下降，可謂殺敵800自損1000。
敏捷迭代儼然成了一些工程師眼中的——七傷拳。那么敏捷的快速迭代到底能不能幫助團隊提升效率嗎？大概可能吧！對于上述悖論我想從在易觀數(shù)科工作兩年多的實際案例中給出答案。
易觀剛開始做方舟這款大數(shù)據(jù)產(chǎn)品時候，也是在開發(fā)交付問題上遇到了比較大的挑戰(zhàn)。開發(fā)初期新功能需求比較密集，且穩(wěn)定性不夠好，需要頻繁給客戶升級新功能或是修復(fù)bug，團隊也是自然而然地運用了敏捷迭代的方法，有問題改問題，有需求做需求。
每次上線都需要實施團隊上前方操作，研發(fā)人員后方待命，一旦出現(xiàn)問題研發(fā)就會直接沖到第一線輔助。這個模式雖然取得了一些不錯的成績，但是伴隨著客戶數(shù)量的增漲各團隊已經(jīng)是不堪重負。
直到公司層面為了更好的服務(wù)客戶在公司內(nèi)部提出了“貼身研發(fā)”的概念時候暴了雷，“貼身研發(fā)”即客戶需求至上，快上加快，這樣一來需求的數(shù)量和隨機性都突增。
研發(fā)和實施團隊由于壓力太大，便站出來反對頻繁的迭代上線——認為還不如等功能都做好一次交付給客戶來的省事，于是和產(chǎn)品團隊“吵成”一鍋粥，一時間團隊幾乎到了奔潰邊緣。
但這也成為了促使團隊深入反思蛻變的轉(zhuǎn)折點。團隊一起開會討論，徹底梳理整個研發(fā)模式和交付流程的每一個環(huán)節(jié)，最終得出的結(jié)論是當前交付上線成本過高嚴重占用了團隊的資源。
方舟大平臺大數(shù)據(jù)組件多達10個以上，且多是集群私有化部署，屬于重交付運維的產(chǎn)品服務(wù)。每一次上線不但要在技術(shù)層面去調(diào)控更新眾多大數(shù)據(jù)組件，還要和客戶做大量的前期溝通，這樣交付上線成本必然比較高。
欲練絕世武功，先練心經(jīng)，心中要有數(shù)。為了印證交付上述結(jié)論，我們透過問題看本質(zhì)，用數(shù)字來剖析背后隱含的規(guī)律。
首先建立工作量估算不完全數(shù)學(xué)模型：
工作量=需求個數(shù)（批次） X ?(平均開發(fā)成本+平均測試成本) ?+ 線上Bug個數(shù) X (平均Bug修復(fù)成本+平均測試成本) ? + ?上線次數(shù) X 上線成本 X 上線用戶數(shù)
Workload = PRNum X (DevCost + TestCost) ?+ ?BugNum X (BugCost +TestCost) + PubNum X PubCost ?X UserNum
引入bug 率的概念：
傳統(tǒng)模型:
上線次數(shù)近似等于Bug個數(shù)：PubNum = BugNum
假設(shè)全部上線后發(fā)現(xiàn) bug ，立即修復(fù)上線
WorkloadA = PRNum X (DevCost + TestCost) ?+ BugNum X (BugCost +TestCost) + BugNum X PubCost ?X UserNum
WorkloadA = ?PRNum X (DevCost + TestCost ?+ gBugCost +gTestCost +gPubCost ?X UserNum)
敏捷模型:
上線次數(shù)近似等于需求個數(shù)（批次） ?PubNum = PRNum
假設(shè)線上bug都在下一次迭代中解決的, 只計算BugCost，不會增加額外上線成本
WorkloadB = PRNum X (DevCost + TestCost) ?+ ?BugNum X (BugCost +TestCost) + PRNum X PubCost ?X UserNum
WorkloadB = PRNum X (DevCost + TestCost ?+ gBugCost +gTestCost + PubCost ?X UserNum)
將兩種模型進行對比：WorkloadA - WorkloadB= ?PRNum X PubCost ?X UserNum X（g-1）
由此可得出：
第一，傳統(tǒng)模式一次上線在bug率比較低的的情況下實際上工作量最小的。說明特定情況下，“敏捷迭代還不如等功能都做完一次上線省事”說法；
第二，團隊 bug 率 g 大于1，傳統(tǒng)模式的工作量會逐漸大于敏捷模式工作量 。說明傳統(tǒng)模式對于bug率比較敏感，bug 率控制的不好的話就是一個無底洞；
第三，交付上線成本 PubCost 是造成敏捷模工作量上升的關(guān)鍵因素。說明敏捷模式相對于傳統(tǒng)模式對交付成本比較敏感，客戶數(shù)越多成本越高。
以上數(shù)學(xué)模型證實了交付上線成本過高導(dǎo)致總體迭代成本急劇上升的結(jié)論，同時易觀大數(shù)據(jù)團隊開啟了一輪降低交付成本的計劃。
易觀的做法主要包括以下幾點：
在發(fā)布方式上：借助易觀自研強大的調(diào)度器實現(xiàn)版本或補丁發(fā)布完全自動化、版本 changelist 生成完全自動化、每日自動發(fā)布版本可多達到10個以上；
交付方法上：通過自動化工具的應(yīng)用實現(xiàn)一鍵大數(shù)據(jù)集群部署、一鍵在線或離線版本升級，最快10分鐘內(nèi)完成從代碼提交到交付客戶完成；
交付一致性方面：通過對產(chǎn)品的架構(gòu)改造，并配合版本管理體系的標準化實現(xiàn)增量交付，全量覆蓋能夠確保交付出去的版本內(nèi)容完全可控；
溝通方式上：基于以上方式實現(xiàn)結(jié)合版本信息管理平臺實現(xiàn)最高效的溝通是不言而喻，Only number 便可了如指掌。
經(jīng)過以上4點變革，易觀方舟團隊打通了敏捷迭代環(huán)節(jié)中交付障礙，構(gòu)建了完整且清晰敏捷閉環(huán)，加快了迭代速度的同時卻沒有較多增加的成本，讓團隊可以專注在產(chǎn)品研發(fā)本身，這成為易觀方舟在如此短的時間里能取得喜人成績背后的力量。
直面自己的問題和敢于變革是易觀在20年時代大潮下沉淀下的信經(jīng)，也希望我們的經(jīng)歷能夠鼓勵到對數(shù)據(jù)科學(xué)孜孜不倦的你！
歡迎投遞簡歷到hr@analysys.com.cn郵箱
更多招聘詳情，請點擊“閱讀原文”~
●職業(yè)路徑|初級運營在易觀如何轉(zhuǎn)型顧問式銷售
●易觀|聚集一批優(yōu)秀的人，做成一件有意義的事
●探秘|支撐月活6億用戶兩級的易觀數(shù)科SDK團隊
●探秘|在易觀數(shù)科，遇見更好的自己
???更多招聘詳情，請點擊“閱讀原文”
