12小時上線“新冠肺炎同程查詢工具”，開發者這樣狙擊疫情
“擴散!急尋這235個車次、航班同行人”
“緊急尋人!急尋Z264、Z265列車同行人!”
“急尋同行旅客,這趟到瓊海的動車發現確診患者”
……
新型肺炎潛伏期長則14天，春運高峰大大增加了疫情防控難度。一條條跳動在新聞上的患者同行信息，就是一個個防控疫情的關鍵節點。
狙擊疫情，必須分秒必爭!
信息不斷更新，來源多樣繁雜，如何讓人們快速確認是否與新型肺炎確診患者同行，從而迅速進行診斷和隔離?1月27日，一款由幾位開發者從上午11點緊急開發，到晚上11點已在朋友圈傳播的“新型肺炎同程查詢工具”就已上線——輸入日期、車次以及地區，即可查詢是否與已披露的確診患者同行。
網站：http://2019ncov.nosugartech.com/
“有人是醫務人員，所以他們去了;有人是警察，所以他們去了。我們是工程師，我們可以用自己的技能做一些力所能及的小事，希望可以幫到大家”。今天，阿里妹采訪到成都無糖信息技術有限公司聯合創始人兼CTO，也是工具的開發者童永鰲。在他的故事里，我們看到了中國開發者的力量。
童永鰲在辦公
工具上線后，累計訪問量已突破3500萬次，并獲得人民日報的點贊轉發。
做力所能及的小事，幫助大家共度難關
阿里妹：能否簡單介紹新冠病毒確診患者同程查詢工具的開發初衷?
童永鰲：最開始的原因很單純，就我自己有查詢需求。我們日常接觸到的疫情信息里包含尋找患者的同程者這塊內容一般就是以圖片為載體，一張圖羅列了患者曾經搭乘過的交通工具、車次、日期等信息。通過圖片逐條查找信息，一來是有可能看漏信息，二來是查找起來確實不太方便，每次都要從頭查找。
作為一個程序員，我比較“懶”，一條條的去翻歷史記錄很麻煩，于是就想到把數據摳下來，用搜索工具去查找更加方便。
阿里妹：工具開發團隊是如何在短時間內建立起來的，團隊里都是志愿者嗎?
童永鰲：最初的團隊成員都是我自己認識十多年的老網友。我們原本就在一個群里，平時會閑聊。我看到央視的新聞之后，就在群里說了想要做個工具的想法。他們也非常支持，就直接開始做。團隊中還有一個人是我公司的，因為工具需要運行維護，我就把公司的運維主管拉進來。也考慮過志愿者，但如果一開始公開招募的話，整個周期會很長。
最開始我畫了一張簡單的布局圖丟到群里，把前端、后端、數據收集的工作安排出去就立馬開始干活了。其實是一種很簡單、粗暴的方式。后面陸續加入一些志愿者，他們看到工具之后，通過郵件的方式聯系，并加入我們。我們再把這些志愿者拉到群里，他們協助我們收集整理數據。
最初大家在群里討論工具時手畫的簡單原型圖
阿里妹：能否分享一下查詢工具最開始的設計思路?
童永鰲：工具本身用到的技術比較簡單。先把網上現有的圖片和文字內容統一做信息整合，放到數據庫中。然后再做一個檢索工具，就成了現在大家看到的樣子。
一開始并沒有想太多，總體思路很直接。有想法之后就立刻開始動手搭建網頁。先是在網上查找公開的信息，交通工具就包含：火車、飛機、公交車、出租車等。所以，初步設計數據庫中可能用到的這些字段。
接下來就是考慮用戶可能會用什么方式來查詢，查詢的關鍵詞等。我就把自己當成用戶，假設自己使用這個工具的話，我需要查些什么?我想到的第一點是日期，先查詢我哪天乘坐交通工具。第二點就是貼合車次做具體檢索。另外是地區搜索，如果用戶在某個位置，那么這個地區的火車、飛機等是否存在已確診患者。
前面兩點是后臺數據庫設計，最后就是界面設計?？紤]完這兩個設計，就直接開始動手做了。
阿里妹：從開始到工具上線過程大概用了多少時間?上線后有哪些工作要做?
童永鰲：開發大概用了半天，1月27日 上午11點左右有了這個想法，下午5點左右，功能上基本就已經做好了。后來又花了6個小時整理數據，晚上11點就發朋友圈了。
后期維護上花費的時間比較多，團隊成員每天都會花17個小時甚至更久來維護，這幾天大家基本上早上9點到晚上2點都在工作。剛開始確實沒想到數據會突然增多，信息量大了之后我們就要做一些功能上的加強，比如：處理數據流暢機制、改動代碼以及回復網友郵件等。事情多又相對比較雜，但是每一件事情都必須仔細對待。
阿里妹：開發和維護的過程中遇到過哪些挑戰?
童永鰲：最大的挑戰來自于數據整理。這個工具在初版的時候，用到的數據是央視整理過的，數據是現成的，整理起來相對容易些。后期信息量越來越大，整理信息的難度也越來越大。現在我們也會靠自己去篩選信息。一方面通過爬蟲做信息初篩，另一方面靠網友給我們反饋信息。我們會要求網友提供鏈接，把鏈接批量爬蟲回來后，從鏈接中做一些信息提取的工作。從目前的數據來看，爬蟲來的信息和網友提供的信息大概是五五分。
另外一個挑戰來自于訪問量的暴漲，完全沒想到訪問量會這么大。第二天訪問量開始暴增的時候，最開始的版本架構就扛不住了。
阿里妹：能簡單說下訪問量的增長過程嗎?面對流量暴漲，是怎么扛過去的?
童永鰲：1月28號是上線第二天，訪問總量是450萬。第二天晚上八點開始就是一個幾何級數的增長，從一個小時10萬訪問量跳到300萬。29號和30號總量在2000萬左右。
最開始用的是的朋友的服務器，一兆帶寬1G內存。上線第一天，因為配置太低，無法容納100人同時在線的訪問量。后來就直接調用第三方的CDN，我們嵌入遠程資源，就不用自己扛資源訪問的這一塊流量。但隨著訪問量越來越高，我們發現單臺服務器要扛千萬級的流量很難做。 于是我們取了個巧，把頁面和數據文件生成靜態的。相當于把庫里的數據生成一個靜態的文件，再把頁面和數據都放到阿里云的OSS上面。讓阿里云的OSS對象存儲去扛住高并發、高流量，我們自己就不用擔心流量壓力了。
阿里妹：需要錄入的信息大概多少?如何確保數據的準確性?
童永鰲：總量在500-600條左右。最早的信息是100多條，現在已錄入300多條。后端還沒錄入的信息大概還有250-300條左右，待錄入的信息中包括重復的。
數據確認是一個漏斗狀的篩選過程。網上搜集來的信息經過驗證、去重后會越來越少。數據量大的時候用自動化方式采集，數據量小就可以直接通過人工采集。在審核步驟上大概過程是：初始線索 -> 網友整理 -> 內部人員整理(核實糾正普遍性錯誤)-> 內部人員錄入(核實單條錯誤)-> 提交(審核單條錯誤)-> 復查(有原文鏈接失效或新聞報道后續修改的情況)。
后來人民日報推送工具的時候，他們幫我們重新把數據認真地再審核一遍。
對于信息我們會逐層把關，越到后面關鍵的步驟，數據把關人越少越好。人越多的話，犯錯的可能性也隨著增大。而且中間涉及到一個信任問題，特別是后面的審核的這個步驟，除了我最信任的朋友和公司的制作人，沒讓其他人介入。
在時間上，現在錄入速度沒有之前那么快了。因為我們對數據的準確性要求越來越嚴格，需要花大量的時間去核實。對我們來說，及時性排第二位，準確性才是第一位。
阿里妹：對工具的性能會做什么改進嗎?
童永鰲：現階段最主要的還是后端數據，首先是準確性，其次是及時性。功能上并沒有打算把它復雜化。如果有些新想法，可能會單獨去做嘗試。
當然，還是希望疫情能夠早點結束，就不用考慮這些啦。
阿里妹：接下來會迎來一個返程高峰，有沒有大流量的預備方案?
童永鰲：我們現在已經不太擔心高并發、大流量的問題了，主要是對數據的準確性要求更高。我們自己現在錄入做數據的時候，感覺已經有點強迫癥了，精神高度緊張，生怕敲了一個數字，需要反復確認。
阿里妹：這次疫情來勢兇猛，你認為開發者的參與對于阻止疫情的蔓延起到了哪些幫助?
童永鰲：這個比較難判斷。假設我是工具的使用者，我也只是做個查詢確認而已。至于它對疫情起到多大的幫助，我感覺不出來。我覺得醫生是最有幫助的，而工具能夠給大家提供一定的參考意義，我覺得就足夠了。 這兩天也收到一些網友的郵件，有的很簡單，就四個字：謝謝你們?？粗鋵嵑芘摹?/p>
阿里妹：作為一個老開發者，有沒有什么建議可以分享給同行?
童永鰲：這幾天也沒有時間、精力想太多。我想，對于程序員來說，寫代碼不能當成一份工作，應該當它是一個工具。從這個角度，很容易想到做疫情同乘者查詢工具，因為我只是拿一個編程語言來解決我自己想解決的生活中的問題而已，并不是說我要做一個什么項目，從產品角度去考慮這件事。
對開發者來說，建議他們嘗試把編程變成了解決日常生活需求的一個東西，而不是單純地看成工作去對待，可能就會有更多的東西好出來。
共抗疫情，我們能贏
“能做事的做事，能發聲的發聲。有一分熱，發一分光。”疫情沒有旁觀者。感謝開發者們用科技的力量點亮星光。
在新型肺炎同程查詢工具之外，阿里妹還看到了，GitHub上的「wuhan2020」防疫信息收集平臺，以及目前還在征集開發者的外來人員登記系統、消毒檢查登記系統、學生健康報備管理系統、違紀舉報系統、物資管理系統等項目。
我們誠摯邀請所有開發者集思廣益，如果你有能幫助到戰勝疫情的小工具、好想法，歡迎在下方留言。共抗疫情，我們能贏!
