記一次線上問題及反思

背景介紹

咱們團隊是作程序化廣告的，我所在小組主要作 DSP 方向，對接外部 ADX，提供廣告檢索服務（對廣告系統不熟悉的不要着急，後面有時間會給你們分享廣告相關的文章）

10 月 21 日上線了一個支持頭條的需求，其實主要就是在展現和點擊監控連接中增長了一個宏，好比請求 url 爲：xxx.com/n/d/?fid=aaa&h_oaid={OAID}，當咱們的廣告競價成功後通常就會展現到頭條上，當廣告展現後，頭條會給咱們發送展現通知，若是用戶點擊後，也會給咱們發送點擊通知，這樣咱們就能夠根據這些回調進行計費。但當我晚上上完線後，陸續收到了線上報警，廣告曝光比前一天同時刻降低超過 50 % 的報警。覺得是上線波動致使，就繼續上線了，半夜十二點左右報警愈來愈頻繁 ......

排查過程

10 月 21 日 半夜

經過看監控平臺，發現獲勝數據是正常的，只是展現和點擊出了問題，而後看業務日誌（其實咱們排查的過程有問題，應該先看 tomcat 請求日誌的），發現頭條的展現和點擊回調沒有請求過來，但此次需求只是在 url 中增長了 h_oaid={OAID}的宏呀，難道是它影響了？

此時能夠回滾的，但是回滾比較麻煩，咱們採起的方式是把本次上線的宏去掉後從新上了一版，發現問題解決了，至少止損了，先睡覺吧，次日再排查

10 月 22 日

22 號到了公司開始聯繫頭條方但願可以一塊兒排查下，由於咱們懷疑是連接中新增長了宏，可能頭條方沒有給咱們發起回調，咱們給對方提供了一些惟一請求標識，通過一段時間的排查和溝通，發現頭條確實給咱們發了回調請求，可是他們沒有把宏給替換，因此返回的 url 請求中依然帶着 {OAID} 這個宏，並且咱們返回的狀態碼是 400，重點來了。咱們猜想難道是特殊字符 { 和 }影響了？（這裏也暴露了一些知識點的匱乏），趕忙查看 tomcat 的日誌，果不其然，日誌早就已經說明了問題，只是一直沒關注系統系統，光看業務日誌了。

經過異常信息，咱們能夠知道是特殊字符違反了 RFC 規範，因此咱們把 {OAID} 去掉後解決了問題，正常應該是頭條幫咱們把宏替換掉的，這樣就不會有違反規範的特殊字符，請求也就能夠正常響應了

解決過程

經過查資料，咱們發現 tomcat 的一些版本仍是容許請求 url 中帶有 |，{，} 這三個特殊字符的，只是須要修改下配置文件，以下

tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}

該配置在 tomcat 一下版本生效

- 8.5.x for 8.5.12 onwards
- 8.0.x for 8.0.42 onwards
- 7.0.x for 7.0.76 onwards

咱們線上的 tomcat 版本是符合的，只是咱們沒有采起這種修改配置文件的方法，只是先把宏給去掉了，等頭條上線最新的替換宏的代碼，咱們再次上線

固然後面咱們從運維團隊要到了出問題時間段的 nginx 請求日誌，過濾出有問題的請求，而後從新跑數計算影響了多少數據，這個從新跑數的過程也須要紮實的 linux 基礎和對業務的深刻理解，由於最開始對業務理解不足，跑的數據是有問題的。

反思

前面說的有些囉嗦了，其實就是請求 url 中帶有特殊字符，違反了 RFC 規範，致使返回 400 狀態碼，這暴露出該知識點處在個人知識盲區，並且應該早些查看 tomcat 系統日誌，而不是一直關注業務日誌，畢竟請求進入到 tomcat 後，纔會有業務日誌。

通過此次線上問題，總結下個人反思

1.必定要敬畏線上報警短信，既然報警必定是有緣由的
2.自測的時候，多測試一些 bad case ，固然這也取決於本身的知識點和經驗
3.排查問題，不能太依賴業務日誌，要遵循一些流程，從根源查找問題緣由
4.在對接外部系統時，必定要溝通好，考慮全面些
5.不斷完善本身的知識庫，固然這也須要不斷踩坑的經驗積累
6.要對業務深刻理解才能寫出正確的代碼
7.團隊的力量是強大的，期間很是感謝個人隊友們的支持

歡迎關注公衆號 【天天曬白牙】，獲取最新文章，咱們一塊兒交流，共同進步！