今天我們回顧一個(gè)線上bug煤惩，bug的背景是這樣的：
攜程收購(gòu)了去哪兒戈稿，但是攜程的用戶(hù)體系和去哪兒的用戶(hù)體系還沒(méi)有完全的統(tǒng)一笛质，也就是說(shuō)用戶(hù)要區(qū)分?jǐn)y程用戶(hù)和去哪兒用戶(hù)泉沾。
攜程和去哪兒各有一個(gè)app，分別叫做攜程旅行和去哪兒旅行妇押，攜程的用戶(hù)使用攜程旅行app跷究，而去哪兒用戶(hù)，則使用去哪兒旅行用戶(hù)敲霍。
現(xiàn)在有一個(gè)頁(yè)面叫程信分首頁(yè)俊马，這個(gè)頁(yè)面攜程和去哪兒用戶(hù)都可以看到丁存，頁(yè)面的地址是：
http://{domain}?originChannel={originChannel}，其中 originChannel 參數(shù)就是用來(lái)標(biāo)識(shí)這個(gè)用戶(hù)是從哪個(gè)app過(guò)來(lái)的柴我，如果是攜程用戶(hù)解寝，originChannel=CTRIP，如果是去哪兒用戶(hù)艘儒，originChannel=QUNAR因?yàn)橐恍┰蛄祝瑪y程旅行app里面的跳轉(zhuǎn)鏈接originChannel參數(shù)配置錯(cuò)誤了，導(dǎo)致用戶(hù)在攜程端訪問(wèn)這個(gè)頁(yè)面的時(shí)候彤悔，使用了地址：
http://{domain}?originChannel=QUNAR嘉抓。程信分首頁(yè)會(huì)解析originChannel參數(shù)，并且用于發(fā)后端請(qǐng)求晕窑，由于是攜程的用戶(hù)抑片，但是傳遞給后端的確實(shí)QUNAR，導(dǎo)致后端判斷用戶(hù)類(lèi)型錯(cuò)誤杨赤，引發(fā)了異常敞斋。
最終這個(gè)線上bug產(chǎn)生的影響是，用戶(hù)在攜程端疾牲，進(jìn)入程信分首頁(yè)后會(huì)報(bào)錯(cuò)植捎。
這個(gè)bug怎么解決呢？
有兩個(gè)方案阳柔，一個(gè)是修改攜程端的originChannel參數(shù)焰枢，修改為CTRIP就好了；另外一個(gè)方案是舌剂，不要讓后端信任前端的參數(shù)济锄，后端自己根據(jù)用戶(hù)的登錄態(tài)來(lái)判斷是攜程的用戶(hù)還是去哪兒的用戶(hù)，這樣霍转，前端免除了配置originChannel的工作荐绝，因?yàn)闆](méi)有配置，也就不會(huì)發(fā)生配置出錯(cuò)的可能了避消，另外后端根據(jù)用戶(hù)的登錄態(tài)來(lái)進(jìn)行判斷低滩，會(huì)更準(zhǔn)確，更安全(防止有人篡改originChannel)岩喷。
其實(shí)之前已經(jīng)發(fā)生過(guò)一次這種線上問(wèn)題恕沫，不過(guò)當(dāng)時(shí)受影響的用戶(hù)量比較小，所以后端同學(xué)當(dāng)時(shí)沒(méi)有引起注意纱意，也沒(méi)有按照第二種方案來(lái)修復(fù)婶溯。
由此產(chǎn)生的一個(gè)影響是，更多的用戶(hù)在這次bug中受到了影響，而且為了排查和解決這個(gè)問(wèn)題爬虱，前端、后端腾它、產(chǎn)品跑筝、測(cè)試等一票人，耗費(fèi)了周六一早上的時(shí)間瞒滴，有個(gè)前端同事已經(jīng)去門(mén)了曲梗，不得不打了半個(gè)多小時(shí)的車(chē)回來(lái)修復(fù)問(wèn)題，還有一個(gè)后端同事妓忍，因?yàn)樾迯?fù)問(wèn)題虏两，公司的年會(huì)也沒(méi)來(lái)得及去。
一次疏忽世剖，換來(lái)了百倍的成本定罢，謹(jǐn)記！
