互聯網公司工做一年心得體會

     時間過的很快，從一個小公司跳槽的58同城已經一年啦（去年5月26日正式入職）。雖然58同城比起一線互聯網企業仍是有着差距，可是對於從小公司出來的我，受益仍是匪淺的，本身不論技術仍是眼界都有了很大提高 ，加上作的項目是從0到1的內部創新項目，感悟會更爲多一,下面整理下這一年來的相關收穫和相關落地方案。(文筆很差，想到哪裏就說到哪裏)

 

1.數據驅動

        相信每一個互聯網公司都會很是重視這一起，都有本身的數據可視化平臺，能夠查到每一個業務線的詳細數據。這些是業務數據，能夠提供相關參考，作相關業務調整和戰略發展。除了公司層面的數據平臺，各個業務線也有本身關心的數據指標，一切用數聽說話。大的方面不用強調，這裏就從一些小的方面說一些數據驅動。根據業務創建相關數據指標，造成數據漏斗，產品和研發，能夠看到漏斗每一層的相關數據和轉化率，才能圍繞漏斗提高作相關改進，業務推展才能有序推展。因此程序員們要有數據意識，多關注數據變化，用數據驅動業務發展。

好比咱們的新項目，從一開始就創建了相關數據指標，數據報表天天郵箱會收到10幾個

包括：用戶行爲數據，總體數據，A/B測數據，埋點統計，渠道來源數據，增加數據，流量數據，具體業務的漏斗數據，人效數據，具體業務的統計數據，項目執行進度，核心數據的變動記錄等。

2.監控/報警/腳本       

        隨着業務的不斷髮展，站點和服務愈來愈多，互相之間的依賴也比較多。出了問題程序員要第一時間感知到，所以監控和報警是很是重要的。公司層面確定有相關的監控和報警方案，好比58的先知系統，能夠設置http請求的超時閥值報警。服務平臺管理也能夠設置分佈式服務的訪問量，拋棄量，異常量的報警。架構部的平臺也能夠看到整個系統，從上到下的請求鏈，每一個方法的請求時間，以及各個服務的訪問量，訪問時間，異常量等等。

        本身的業務線也能夠圍繞着服務是否可用，作如下的監控，腳本都比較簡單，參考網上的一些例子應該就能夠很快實現。

站點存活的心跳檢測，好比某個服務掛了，致使站點不可用

硬盤的監控，常常會出現一些程序打日誌，把硬盤給快跑滿了。

數據庫的相關檢測，好比檢測請求量，數據庫鏈接。

緩存服務檢測，好比緩存服務的內存使用狀況，鏈接狀況。

數據庫檢測，好比查看是否有髒數據。

實時任務的檢測，好比監聽消息總線，是否有消息堵塞，日誌是否滾動。

服務的日誌檢測，好比查看相關站點的日誌，看裏面是否有程序異常，發送相關報警

...

        其實監控程序也不復雜，基本上都是一些簡單的shell命令經過crontab，鏈接相關服務，查看數據是否異常，發送短信報警（把發短信功能作成一個http請求，經過crul 或者wget 調用接口傳參短信報警）。

        另一個須要強調的服務性能監控，也是程序員須要注意的地方。

        好比，咱們對公司的分佈式服務作了一個監控插件，裏面有一個全局過濾器，每一個請求都會進行統計，定時發送到另一個服務中進行計算和報警。天天會有報表，統計各個服務的請求次數和每一個接口的請求時長，以及超時接口排名。不少問題均可以經過這個監控得以發現，好比某個服務或者某個接口的平均訪問時間過長，就須要進行優化。有段時間老大天天都會訂着報表看，咱們就須要想着辦法進行優化。只有對服務的性能有清楚的認識，才能保證系統的可用性。

        另外要對各個站點和服務，進行日誌採集和監控，以報表的形式反饋出來，是程序員就會出bug，咱們也不能一天到晚訂着日誌。因此經過這些監控，咱們能夠看到服務的相關問題，進行解決。

    

 

3.會用linux，懂shell

        58核心業務不清楚，反正本身的業務線，程序員(RD)和測試（QA）均可以拿到服務器的相關權限，58這邊由QA負責部署上線，可是RD有時候也須要本身動手。包括部署站點，部署服務，殺進程，啓服務，寫腳本，運行腳本，查看日誌，異常定位分析，因此程序員們要懂linux的經常使用命令，另外java相關的監控命令也要知道

 

4.不只僅只有web應用

        作後臺開發的，不只僅侷限於web開發，除了前面提到的不少shell腳本，平時工做涉及的好比郵件報表，esb消息隊列任務，業務定時任務都是獨立於web程序的任務。好比用java作一些定時任務，以前業務線基於Quarz封裝了一個任務框架，或者本身寫java方法，經過contab定時調用。不少java程序員可能脫離了web容器，都沒單獨寫過java應用。

        爲何面試的時候會問jvm的相關問題？ 除了一些框架和服務提供的配置以外， 本身寫java應用也是要用到這些的，設置相關jvm參數，加載相關的資源，傳參獲取環境參數等等。

 

5.不只僅只有數據庫

        假如須要是作一些數據統計，以前可能都會想辦法把數據存在數據庫中，經過數據庫的sql進行統計。好比回覆短信的人都會哪些，有多少人蔘與了這個活動。其實不少數據不是業務相關的，均可以考慮用其餘辦法。好比記日誌，從日誌分析獲取數據。好比pv,uv,用戶行爲分析，瀏覽記錄，後臺的操做記錄等等，均可以經過日誌記錄下來，經過日誌清洗獲取相關數據。

        目前58的大數據平臺基本上流程就是： 業務線埋點，輸出log，flume採集日誌到hdfs，經過mr清洗日誌到hive。基本上作好數據埋點，不少數據統計都不須要改程序，傳遞不一樣參數，經過hive就能夠進行數據統計

 

6.都是單表查詢

        以前使用oracle，線上使用各類鏈接查詢，聚合函數，存儲過程。如今線上要求都是單表查詢。容許數據庫表冗餘，要麼單表查詢，要麼在業務中組裝數據。

        若是數據量大就分表 ， 若是數量大且併發大，分庫分表。 設置好主鍵生成策略和路由策略。在數據庫上層封裝一層查詢索引，根據條件索引查詢id串，根據id串去各個數據庫並行查詢。另外數據量到另一個級別，就可能須要nosql的解決方案了，好比58內部的WTable。

        固然一些統計相關的能夠用一些連接查詢，可是生產環境不能使用。

7.併發/緩存

        58的用戶量仍是比較大的，業務中不免會涉及到58的相關業務。好比咱們經過esb消息總線拿到數據，一天處理幾百萬或上千萬的數據。或者對大數據平臺天天幾百T的數據作分析，跑任務。接觸到業務邏輯和遇到的問題，也是小公司通常不多遇到的。因此併發相關的問題，多多少少也都會遇到。

        另外作一些活動運營，或者服務接到主站服務中，都須要考慮服務的併發請求量，考慮QPS。目前本身瞭解的相關指標，web站點達到600QPS，服務達到2000QPS，剩下就能夠堆機器了。若是想提高QPS，簡答的就是加緩存，可是固然有不少業務場景不是加緩存就能夠解決的。

 

8.全棧

        公司比較大，作的業務分的就比較細，好比由美工作設計和頁面，由前端負責作頁面和js交互，其實後臺程序員只用寫好服務就行。所以校招的程序員大部分對前端js都不熟悉也不多用到。可是對於寫管理系統的，沒有前端FE支持，可能就須要先後端通吃了。不過不少人仍是很優秀的，很快就能夠學習上手的。

 

9.解決方案都有

        畢竟公司不算小，除了公司的核心重量級業務，各業務線都不會遇到太大的技術瓶頸。開發過程當中，遇到問題，基本上均可以找到各類辦法去解決。因此遇到問題，去聊，去搬。技術上都不是問題，只要有人，很短的時間，pc，m，app三端就出來了。

 

10.開發流程

        58的開發量程還算是比較正規的，通常都會提早要求PM需求，RD體現批註需求，而後進行需求評審，技術評審，RD排期，開發，提測，上線。RD須要對排期負責，保證開發進度。

 

11.技術體系，述職

        58技術體系，走的是T序列（參考百度），校招基本T3， T4就是高級程序員了，T5基本上都是組長了，業務線從T4到T5是一道坎兒。T序列升級須要述職，感受仍是比較有難度的。公司大部分應該是T4的。因此在公司若是混日子，基本上是待不下去的。因此平時在開發中，就須要考慮完整的技術方案，作好相關設計，這樣述職的時候纔會比較輕鬆。

        58內部也會有各類技術講座，也會邀請業內的大牛，總體技術氛圍仍是不錯的。

 

12.公司的發展變化

        雖然來58基本沒接觸到主站的相關業務，可是也見證了公司的一些變化。好比去年公司全部業務線切換到騰訊雲機房，58大數據平臺換了兩版，愈來愈高大上。提供了hive的雲窗，能夠直接開放給pm去查詢數據。

架構部的服務平臺，提供了先知系統，scf服務管理，wcache，wlist，wtable等本身的服務。前段時間換logo，三端改版。互聯網公司確實變化比較快。因此程序員也要不斷提升，才能夠跟上公司的步伐。