淺談技術價值

淺談技術價值

最近事情不多，便想著整理下過去一段時間的想法和思考。自己大概算了下工作時間差不多也有 9 年時間，斷斷續續的思考技術在整個互聯網業務環節中的價值。

有人可能會想技術能有什么價值？不就搬磚碼代碼嗎嘛，還想翻天了不成。是的，不少數會認為主要就是實現產品需求，并保證線上運行的代碼不出問題就已經謝天謝地了。至于想改變世界，大哥快醒醒，別做夢了，快點搬磚，給后面的人少挖點坑就闊以了.....

說了這么多，其實，我不太同意上面的觀點。套用星爺說的一句話：【做人如果沒夢想，跟咸魚有什么區別】

基于此，今天我主要從保障服務穩定、提能增效、賦能業務三個角度來談談技術價值

服務穩定性

線上服務的穩定性直接決定了產品的業務數據。試想一下，淘寶在雙十一零點的時候，登錄如果掛了，阿里會損失多少 GMV 和用戶體驗。

那我們該怎么樣提高服務質量和穩定性呢？先大概的從架構層面講一下，我們一般采取限流、降級、超時、重試、冗余等策略，來保障穩定性，具體詳細的操作后面會專門寫一篇文章討論下【如何提高服務的穩定性】

提能增效

互聯網行業唯快不破，如果你們的產品比競爭對手早上線，就能有更大機會超過對手，搶先一步占領市場份額。那怎么樣提高團隊的研發效率呢？

• 首先，我們應該從整體出發來提高研發效率，其中階段包括開發、測試、運維。如果只衡量開發環節效率，就會出現開發人員日均代碼行很多，甚至每天超過 1K 行以上。但是這個會使需求提前上線嗎？不一定，如果該需求產生的 bug 很多，沒有做單元測試和集成測試，更沒有進行聯調，我們就會花費更多時間都在修復 bug 和回歸測試上。整體來看，這個需求的實現效率其實不高，只是將前面該做的事情挪到后面來做，同時這么做的話，會極大的增加風險，到測試和運維階段才會發現。

• 其次，應該量化從接收到需求發起階到線上運行為結束，里面每個耗時的階段都標記下。如果是聯調階段耗時比較長，我們就需要考慮搭建日常穩定的聯調環境。如果回歸測試的時間較多，我們要考慮建立 API 自動化測試來減少回歸時間等等

• 最后，可以采用測試前置和線上迭代周期減少來采用量化的思維體現出來，就像古話說的好：if you can't messure it ,you can't improve it

賦能業務

這塊其實是技術人員可以在老板面前可以炫耀的資本，可以通過引入新的技術，新的算法模型，來提高用戶拉新促活或者 GMV 。

比如大家使用頭條的 App 來閱讀文章或者看抖音視頻，都會涉及到現在很火的推薦系統。那么，某天技術人員引入某個深度排序模型，優化了召回和排序，結果使業務指標 CTR 或者 CVR 都提高了很多。這些一頓操作后，對應的技術同學感覺腰也直了不少，說話也不哆嗦了，對應的成就感也不一樣了。

最后，以上只是個人的淺薄之言，不期望每個人都認同，僅做參考，不喜勿噴~