復工大勢下,遠程辦公的科技企業只能「坐以待斃」嗎?

csdn 發佈 2020-03-15T17:14:05+00:00

作者| 張偉、胡姝琦、張爍責編 | 郭芮頭圖 | CSDN 下載自視覺中國出品 | CSDN2020 年,每個中國人都正在度過一個不同尋常的春節,疫情來勢洶洶刻不容緩。

作者 | 張偉、胡姝琦、張爍

責編 | 郭芮

頭圖 | CSDN 下載自視覺中國

出品 | CSDN(ID:CSDNnews)

2020 年,每個中國人都正在度過一個不同尋常的春節,疫情來勢洶洶刻不容緩。國家啟動重大突發公共衛生事件一級響應機制後,按照疫情防控的具體安排,每天進出公共空間的人員都需要測量體溫,而民生類的生產製造企業又不得不提前復工解決社會緊缺的物資以保證民眾的生活穩定,而隨著之後即將到來的復工潮和復學潮,如何實現在安全的前提下幫助企業和學校復工復學的工作迫在眉睫。市場上急需一款簡單、易用並且可以快速實施的解決方案,去幫助企業更好地記錄員工的體溫與身體情況,保障企業的安全生產,也可以讓園區管理人員隨時監督到企業的管理與落實情況,最大化的降低人員的精力與成本。

對於此需求,起碩實驗室的團隊成員們立刻遞交上了屬於我們自己的「請戰書」,自告奮勇的承接下了這份艱巨的任務。時間就是生命,全國都在與疫情賽跑,與時間賽跑,雷神山與火神山可以在 10 天之內平地而起,堪稱中國速度的奇蹟,那我們又為什麼不可以?如何短期內又快又好的開發出「智能防疫復工平台」便成了現階段最重要的使命,不但要短期內迅速上線,還要簡單易用,讓更多的人可以輕鬆的上手,要能支持大並發的數據請求,更要可以快速的更新疊代版本以便應對隨時都在變化的疫情與政策,這便成了我們這個團隊在接下來的日子裡每天都要面對的挑戰。

時間進度

2 月 2 日正月初 9 本來應該是每年返程復工的第一天,政府為了保障市面上的口罩供應和基礎的民生服務,有部分企業已經提前的開工,預計即將迎來的大批企業復工潮則推測是 2 月 11 日左右。而我們收到通知的那一天是 2 月 4 日,於是滿打滿算留給我們的開發時間僅有一周左右,我們需要在短時間內理清政府部門的訴求與工作流程,並且快速的提供並落地出一套簡單可行的解決方案。

那還等什麼,我們說干就干,時間就是生命,我們要全力以赴的與時間賽跑,跑贏就是勝利!

7 天過後系統順利上線,正式投入市場為 1 萬餘名員工服務,為了迎來第二天大批的復工潮,我們還緊急的進行了伺服器升級,以免因為早高峰出現的集中打卡上報情況而造成服務宕機。

之後的幾天時間,我們又因為疫情的發展與政策的調整,及時的根據需求支持復工平台的功能變更:從支持醫療物資企業復工增加到支持二產復工、三產企業復工,從重點疫情地區人員的篩選排查和隔離信息監控,升級為中低風險地區返回人員的兩點一線排查,再進而擴展到防外籍輸入性疫情傳播的重點人員監控,這些功能可以有效地根據不同人員的屬性進行不同級別的檢控力度,也在保證了生產安全與人員安全的情況下,最大力氣的推進企業復工復產。

為什麼效率很高?

項目目標明確,團隊高度認可

我們的客戶是天津市新冠狀病毒收治點周邊工業園區,該管委會管轄了下屬 240 多家的二產企業,和近 1000 家的三產企業,在疫情期間,該工業園區內有部分企業主要是生產疫情保障物資,他們在疫情期間內也是全面復工並加班加點趕工,努力多生產一些類似於口罩和防護服之類的物資,但是如何保障這些園區內的企業平穩有序的復工,減輕園區管委會的工作壓力,可以在較短的時間內上掌握園區各個職工的每天身體健康情況,是我們團隊工作關注的重點。

經過我們梳理,該平台的整體結構大概是這個樣子的。

後來經過我們的討論,發現訪客的小程序優先級沒有那麼高,那麼這個小程序的需求先砍掉,所以我們的目標就變的很明確,在一周的時間內,上線一個復工應急通的小程序,同時配備相關的後台管理系統。助力疫情生產物資企業的復工,也就是等於間接的為疫情的防控盡一把力,所以大家的目標明確,積極性也很高。

臨時組建老幹部研發團隊

因為 2 月 4 日天津市還屬於未復工的狀態,所以很多人還處在居家隔離的狀態,所以為了支撐這次緊急的項目,由起碩公司牽頭,聯合其他公司的技術力量合作,臨時組建了一個由有經驗的中高管組成老幹部研發團隊,團隊共有 6 個人,每個人平均的工作年齡在 7 年以上。因為疫情期間隔離的需要,團隊的全部成員都是居家遠程辦公。我們真正的想做一個小而美的團隊,做一個小而美的產品,奉獻給一線真正需要的用戶。我們的研發人力配比是這個樣子的:

團隊內部高效的溝通

因為疫情期間,大家都是居家辦公,如何做到不在同一個城市的這些人,能夠保持辦公室辦公一樣的高效溝通呢。我們這邊分享一下我們的經驗:

雷打不動的項目站會機制

從這個項目的第一天,完成項目啟動會起,我們就確定了項目站會機制。和敏捷中的項目每日站會不同的是,我們把站會的頻率提高到了一天兩次。早晨 9:00 一次站會,主要是明確當天的團隊目標,個人目標都向團隊目標對齊,同時同步風險和配合,這樣每天先把信息進行了拉平。到了晚上 6:00 的時候,我們會再開一個站會,目標是回顧今天工作的進展,遇到的問題,接來下開展每天下半場的

用產物來說話,儘量不溝通

其實溝通的目標是信息傳遞,而不是頻繁的電話、視頻、語音溝通。所以我們認為最高效的溝通,不是時時在線,而是對方給你一個眼神,你就明白什麼意思了。在復盤的時候,發現我們每天除了例會的時候,基本上不用太頻繁的溝通,因為我們工作產物,已經傳達了必要的信息。

1)產品 to 研發:

這是我們產品原型的部分截圖,原型標註很詳細,包括各種異常的狀態處理,所以研發在拿到這樣的產品原型時,基本就明白了,不需要再專門開一次產品需求會,節省了大量的時間。

2)後台 to 前端:

下圖是我們部分 swagger 的截圖,我們每個欄位都有詳細的注釋說明,所以在前後端在進行接口聯調的時候,基本上看協議就可以了,也不需要做太多的溝通,最優的時候一次溝通都不需要,就可以完成模塊功能的開發。

3)研發 to 測試 to 研發:

同樣我們以產品原型作為溝通的媒介進行產品功能的測試。為了快捷的目的,我們使用 Leagoo 的看板來記錄 Bug,同時記錄了相關的錯誤參數,這樣研發看到 Bug 以後,直接修復。

成熟的工具支撐

工欲善其事,必先利其器,這樣的道理大家都懂,可是在實踐中如何提高個人研發效率,提高團隊的產出,我們這裡介紹下自己的小經驗。

如何儘量少寫代碼,完成需求開發

首先,我們在團隊中有一個理念,就是儘量的少些代碼,對於一個需求,如果需要複雜的邏輯去實現,我們做的第一件事情不是立馬實現,會想太麻煩了, 有沒有簡單的方案?本著懶人的思想,我們重點安利一個後端的框架,mybaits-plus ,這個框架的代碼生成會做的更完善一些,從 Entity、Param、Vo 到 Controller、Service、ServiceImpl、Mapper 等代碼都會自動生成。有了這樣的利器,讓我們開發業務邏輯的時候,面對 100 個表和一個表,所付出的基本工作量是一樣,時間複雜度都是 o(1) , 下面是我們某一個業務中代碼生成截圖。

充滿成就感的看板

在這次敏捷項目的開發中, 我們儘可能的使用了看板,而且創造性的把需求和 Bug 放在了一起,每一項任務做完了,直接拖動看板,同時在群里吼一下。通知相關的同事進行下一步操作。

而且我們的看板要求日清,所以每天早晨會看到看板上堆積的任務越來越多,但是到了一天結束的時候,看板的任務從左邊移到了右邊,心裡就會帶著滿滿的成就感去休息,第二天再周而復始,看板的每一條,實實在在記錄了我們從無到有創造了一個產品的過程。

我們如何實踐 CI、CD

我們目前的研發流程轉移到了華為的 DevCloud 上面,所以就在 華為 DevCloud 上來實踐我們的 CI、CD 流程。下午是我們在 DevCloud 上面配置的流水線。

1)持續構建:

我們使用代碼觸發器的規則,每次提交到 dev 分支的代碼,都會觸發一次構建,這樣可以保證測試環境的內容是我們實施更新的結果,測試的同事隨時可以測試最新的功能。從下面的統計可以看出,我們單日的構建次數,最高可能在 20 多次以上,所以每天減少20 次的系統登錄和構建點擊,也確實節省了不少的工作量。

2)持續部署:

為了保障系統高可用,我們在 Nginx 後面負載 n 台業務伺服器,所以生活從環境的部署,我們也是通過腳本來控制,一次性部署N台伺服器,通過減少人員的直接操作,提高安全性和工作效率。

項目時間的充裕保障

在項目的時間管理上,我們可以分享的可能只有兩個點:

  • 做好個人的時間管理,因為大家都居家辦公,怎麼樣協調工作和生活、已經家人之間的關係,每個人各不相同,但是從結果來看,團隊中的每個人都能做到很好的時間管理。

  • 最大可能的保障項目上投入的時間,從目標確定到產品上線一周的時間內,大家基本都是凌晨 1:00 左右休息,早晨 7:00 多爬起來又繼續工作了,即使有各種工具利器的加持,但是艱苦奮鬥的作風也不能丟。

如何保障系統安全?

在儘可能端的時間內,上線一個可用的產品,但是並不意味著其他的方面就不管不顧,畢竟我們做的是一個實際使用產品,而且涉及到個人的敏感信息,一旦安全性問題處理不好,就會演變為事故。所以我們在系統的安全性方面做了下的考慮:

敏感信息處理

對於個人的敏感信息,我們做了兩方面的處理。

1)防止系統被拖庫、敏感信息加密存儲

我們系統中通過註解的方式對核心欄位進行註解標註,使用 AOP 的方式對民敏感的欄位做了對稱加密。

2)防止頁面截屏導致敏感信息泄露

為了防止身份證號等敏感的信息在頁面展示的時候,通過截屏的方式會把身份證號進行泄露,我們在前端頁面展示會後也加入*** 處理。下圖是一個示例。

3)儘可能操作日誌留底

我們在系統中還儘可能的記錄了用戶的操作日誌,防止有一些問題出現的時候可以進行追溯。

資料庫安全性保障

在資料庫安全性的方面,我們主要做了如下的考慮:

  • 禁止資料庫的公網訪問,保證只有 VPS 內部的機器可以訪問資料庫;

  • 設置數據訪問的 IP 白名單;

  • 刪除無用的用戶,例如 test 用戶;

  • 設置資料庫訪問的強密碼。

接口服務的安全性保障

在接口服務的安全性方面,我們主要做了如下的事情:

  • 在阿里雲上面申請了免費版本的個人證書,保證所有的 API 接口和管理後台,都使用https 的服務。

  • 使用 JWT 的 token 模式,token 信息做了多重的加鹽處理。拒絕使用 freshtoken 的策略,保障系統的安全性。

  • 使用 shiro 的認證和授權,保證系統的用戶只能在自己級別的範圍內獲取數據和管理數據。

如何保障系統的高可用?

系統壓力估算

在系統進行生成環境部署前,我們對系統的壓力進行了簡單的估算,按照 4 萬員工全部復工的場景,如果在極限情況需要再 1 分鐘內完成身體健康情況的上報過程,那麼系統可能面臨的峰值 QPS 為:40 000 / (1 * 60 ) = 666.67, 所以為了保險起見,我們使用簡單的分布式服務系統,一個 nginx + 兩台業務伺服器。

簡單的分布式服務 + 資料庫高可用

根據上下面的分析,我們最終的生產環境的配置如下圖所示,在資料庫的高可用和安全性方面,我們才用了華為雲的 RDS 服務,配置了主備的伺服器,保障數據的冗餘備份和安全。

監控和告警機制

為了監控生產環境現網的運行狀態,我們使用開源的 Zabbix ,對生產環境的伺服器進行了監控,同事配置了郵件的監控腳本,如果發現現網的請求時間 > 1 秒鐘,就會發郵件給相關的人進行提醒。下圖是我們的生產環境的監控截圖。

下圖是我們收到的告警郵件。

在疫情期間,我們獲得的那些肯定

2 月 18 日工業和信息化部辦公廳又發布《關於運用新一代信息技術支撐服務疫情防控和復工復產工作的通知》,支持運用網際網路、大數據、雲計算、人工智慧等新技術服務疫情監測分析、病毒溯源、患者追蹤、人員流動和社區管理,對疫情開展科學精準防控;引導企業加強網際網路應用能力,充分運用網上疫情防控資源和信息化工具,建立線上線下、聯防聯控的管理體系。

此時距離我們開發這解決方案已經過去一周時間,我們回顧這次經歷時,發現其實可以將我們的經驗分享出來,把經驗與思考整理一套方法論來供其他企業參考,以便在接下來進一步的防控工作到來之前,大家可以借鑑我們的經驗更快捷有效的搭建團隊與產品。

與此同時,我們參加了很多的公開分享,也有幸參加了像 CSDN 舉辦《中國遠程辦公大考線上峰會》及谷歌開發者社區組織的《智能技術助理復工——疫情給製造業帶來的基於與挑戰》等線上活動,與大家交流我們這一階段的心得與體會,我們也收到了大批媒體的競相報導,得到了市場的肯定。

總結與思考

這個春節真的不一樣,這世界仿佛被按下了暫停鍵,沒有人再去關心春晚是否精彩,沒有人再去走街串巷的拜年,沒有了熱火朝天的聊天聚會,沒有歡天喜地的遊玩逛街,我們低頭看著手機里飛速上漲的數字,窗外是大喇叭廣播反覆不停的播著口號,電視里正在播著一個個的逆行者在與病毒奮鬥的身影,這一切都在時刻提醒著我們,一場與新型冠狀病毒的戰「疫」正在打響,愈演愈烈,熱火朝天。

與病魔較量之時,作為我們普通人,為配合防疫管理措施和號召,大部分人能做的只有主動更改自己的過年安排,退掉了回家的車票,大門緊閉足不出戶,而在一線,則有人義無反顧的放下家庭與休息,選擇回歸崗位,或是與患者共渡難關,或是做著自己分內的工作,努力的維持著這個社會正常的運轉。

而作為一個有著使命感的技術團隊,我們無法安耐住心中的蠢蠢欲動,想用自己的雙手為我們這個正在被經歷著巨大考驗的社會貢獻一份力量。於是我們自告奮勇的聯繫了公司所在的開發區管委會,希望可以利用自己的開發能力,幫助政府人員解決在防疫過程中面臨一些實際的問題,來降低他們的工作壓力。

想要在一周的時間又快又好的完成一個產品的需求調研、產品設計、研發測試、生產部署等一系列環節,本身是一件具有挑戰性的工作,而且在實際的工作過程中,快和好本身存在一些矛盾點,所以我們每個環節都在進行權衡和斟酌,在效率、質量、可用性等各個方面進行取捨。

但是最終的結果是好的,我們系統的系統已經穩定運行 1 個月,隨著疫情的發展,已經陸續有 450 多家企業接入到系統中,各項工作也在有條不紊的進行當中。我們一周摸爬滾打的付出也得到相應的價值體現,使我們心理最感安慰的事情。

但是隨著系統的運行,我們也逐漸發現了一些系統的弊端,也一一列舉出來,供大家的參考,也為了日後的改進:

  • CI、CD 這一塊沒有進行自動化的測試,產品的測試功能,還是主要依賴於人工測試,這塊兒確實有很多的工作需要改進。

  • 通過現網的監控發現,我們現在的 web 服務和 後台服務使用了同樣的系統帶寬,在虛擬機帶寬吃緊的情況下,web 的一些 JS 文件加載較慢,所以後續可以考慮 CDN 的分發,進一步緩解帶寬的壓力。

  • 如果 4W 員工全部復工, 每天都要上報 3 次體溫的話,那麼記錄表一個月的數據增長量為:4W * 3 * 30 = 360W,那麼單表很快會達到 MySQL 單表性能的極限,所以數據的分庫分表工作需要進一步優化。

  • ……

最後我們希望疫情早日結束,我們研發的防疫復工平台早日下線,讓我們迎接美好的人間四月天。

作者簡介:

張偉:天津大學計算機科學碩士、曾就職科大訊飛,擁有 8 年的一線研發經驗,擁有 6 年的研發管理經驗、目前擔任起碩智能科技有限公司的CTO。

胡姝琦:起碩科技產品總監,產品及運營專家,在產品設計、產品管理、用戶增長、產品運營、開發者關係等方面有較為豐富的工作經驗。

張爍:起碩智能科技CEO,不設能力邊界的創業者。

☞美團十年,支撐全球最大規模外賣配送的一站式機器學習平台是如何煉成的?

☞比爾·蓋茨退出微軟公司董事會;蘋果 WWDC、微軟 Build 大會均改為線上舉辦;Rust 1.42.0 發布| 極客頭條

☞騰訊提結合ACNet進行細粒度分類,效果達到最新SOTA | CVPR 2020

☞我最喜歡的雲 IDE 推薦!

☞智能合約編寫之Solidity的高級特性

☞返鄂復工人員自述:回武漢上班,要先飛合肥,再由公司包車接回去

關鍵字: