交流心得

期望：

穩定（不要等到crash了才去優化），

安全（涉及使用者資訊的密碼及隐私資訊

1、都不能明文存儲--防止拖庫；

2、都不能明文傳輸，要進行hash

3、管理平台的登陸密碼不能自定義，隻能由使用系統提供的符合密碼強度的。

）

幾個常用的英語口語：overhead,go ahead,

DEV: Development System
SIT:  System Integration Testing 系統內建測試
PET: Performance Evaluation Test 性能評估測試
UAT: User Acceptance Testing 使用者驗收測試



測試的順序一般為: 
SIT--> PET--> UAT

SIT(System Integration Testing)系統內建測試，也叫做內建測試，是軟體測試的一個術語，在其中單獨的軟體子產品被合并和作為一個組測試。它在單元測試以後和在系統測試之前。
内部測試SIT :System   Integration   TestCase  
根據用例描述測試每一個場景，優化系統性能，送出資料庫性能excution plan給DBA review。對系統進行壓力測試（必要情況下送出到APCC的壓力測試組進行測試）。裡程碑：完成内部測試報告和得到DBA的上線準許。
內建測試在已經被單元測試檢驗後進行作為它的輸入模式，組織它們在更大的集合，和遞送，作為它的輸出，內建系統為系統測試做準備。內建測試的目的是校驗功能、性能和可靠性要求，配置在主設計項目中。

UAT(User Acceptance Testing)使用者驗收測試，通常是由最終軟體的使用者（通常這些使用者不了解軟體的具體邏輯，而對業務邏輯卻相當熟悉）進行的測試，是以是面向最終使用者的測試，結束之後通常就可以釋出生産環境了。
使用者根據用例描述測試每一個場景，回報系統issue。開發人員基于issue對系統影響和對業務impact判斷，适當的修正系統或記錄業務需求，根據業務優先等級，內建進下一個演進階段。 裡程碑：UAT Sign off。使用者簽收目前系統功能

差別與聯系：
SIT是內建測試
UAT是驗收測試
從時間上看，UAT要在SIT後面，UAT測試要在系統測試完成後才開始。
從測試人員看，SIT由公司的測試員來測試，而UAT一般是由使用者來測試。
它們兩個之間的專注點是不一樣的.UAT主要是從使用者層面這些去考慮和着手測試,而SIT主要是系統的各個子產品的內建測試      

根據項目特點，将核心關注定位于：安全、穩定

通過在雲上擴充，來解決并發量大的問題。通過雲服務商提供的路由級DDOS防禦措施，來提高系統的穩定性和安全性。

請求黑洞：ddos的一個請求發到伺服器後，伺服器不再響應。就像所有物質遇到黑洞後，都有去無回

黑洞路由

黑洞路由，便是将所有無關路由吸入其中，使它們有來無回的路由，一般是admin主動建立的路由條目。

提到黑洞路由就要提一下null0接口。

null0口是個永不down的口，一般用于管理，詳見null0的詞條

admin建立一個路由條目，将接到的某個源位址轉向null0接口，這樣對系統負載影響非常小。

如果同樣的功能用ACL（位址通路控制清單）實作，則流量增大時CPU使用率會明顯增加。

是以，設定黑洞路由一直是解決固定DOS攻擊的最好辦法。

相當于洪水來臨時，在洪水途經的路上附近挖一個不見底的巨大深坑，然後将洪水引入其中。

黑洞路由最大的好處是充分利用了路由器的包轉發能力，對系統負載影響非常小。

在路由器中配置路由黑洞完全是出于安全因素，設有黑洞的路由會默默地抛棄掉資料包而不指明原因。

一個黑洞路由器是指一個不支援PMTU且被配置為不發送“Destination Unreachable--目的不可達”回應消息的路由器。

可以這樣看:

如果一個路由器不支援PMTU并且配置為不發送ICMP Destination Unreachable消息資料包，那麼源主機可能發送一個永遠得不到路由的大資料包。因為路由器沒有給源主機發回應消息，主機不能确定PMTU就是問題的所在。但如果源主機端啟用了PMTU，則源主機在重試幾次大的MTU之後，如果還收不到路由器的應答，那源主機自動将PMTU設定為576bytes.

請求轉發和日志管理，使用了nginx在收到請求時打日志，然後elk來收集Nginx記錄的日志。nginx相關知道要重點熟悉一下

redis的問題，并發量比較高redis連接配接會不夠用，這時雲服務提供商redis服務的價格比較貴了，需要自己搭建主從結構的redis緩存。這個搭建及使用的相關需要熟悉一下。自己搭建redis服務，為了保證可能性，需要使用KeepAlive來自啟動

因為java應用使用apache commons pool來管理redis連接配接。這個開源元件需要深入了解下。java應用到redis伺服器的一個連接配接，對應ObjectPool裡的一個PooledObject,如果的确是連接配接不夠用，則自己搭建redis伺服器，使用ssd盤，再配一塊好的網卡，通過内網連接配接即可。

java 應用方面，可能需要在使用redis連接配接方面進行優化。事務是否能降低對redis的連接配接具體代表什麼意思，因為一個事務中要多次向redis伺服器請求，這個連接配接的複用到底是什麼含義，是指Commons pool中不再新建立PooledObject，使用已有的，還是Commons Pool中每個PooledObject是保持與redis伺服器的一個長連接配接。

确定事務中降低java應用到redis連接配接的确切含義，看看降低的是什麼連接配接。 Commons pool中的PooledObject是否與redis伺服器保持長連接配接。

關于網際網路公司對接口測試的看法：

（1）好處：一個接口測試人員，可以成為app和背景的防火牆，能提高app的聯調效率。

理由是：接口測試人員已經會測出一些bug，這樣背景接口提供給app使用時，就會提高效率

（2）看格局：app 背景接口開發完成-->接口測試人員（有一台接口測試人員的測試環境）-->app開發人員使用的環境（準生産環境的測試環境）-->釋出到生産環境

産品提出的需求，需要測試人員，開發人員共同了解（大多數情況下了解的并不一緻),這中間就會扯皮。經過接口測試，肯定還有bug，app開發人員發現bug，回報給測試或開發，測試開發更改後，釋出到SIT，然後測試人員測試完成後，再釋出到UAT，由app開發人員使用。

app發現bug，到修複，至少要部署兩次，測試兩次（開發人員的那次也算吧。從流程上看，開發人員的代碼品質堪憂！！）

現在暴露的問題：

（1）從開發完成到app開發人員能用，鍊條比較長，周期也比較長。換而言之，就是開發人員不行嘛

一個是開發人員開發習慣或能力不行；開發人員、測試人員、産品 三者之間對同一個功能點了解可能 都不一樣。中間的扯皮也很耗時間

（2）app開發時發現bug，到修複完成，需要的時間比較長。原因見上

作為業務不是很複雜的小公司，小項目，沒必要搞接口測試人員。

理由如下：

參與的人越多，對同一功能點的了解分歧的地方越多，内耗（浪費時間）也越多

小公司項目開發要快速疊代，缺的就是時間，是以少一個環節，就可以提高效率

下一個問題：

開發人員開發品質的問題，如果自己都搞不清楚相關邏輯，怎麼可能開發正确。

需要調整開發習慣，提高開發品質。

提到的“秒懂”的問題，的确是一個問題，與人打交道的确是一個問題，遇到官僚習氣比較重的人，需要怎麼處理呢。  少搭理，根據崗位做自己該做的，其它的不與其它産生交集即可。

不講辦事方式和方法的上司力，就是耍流氓。的确。

Leader需要具備的物質：上司力，溝通能力，執行力

上司力：不知道在說什麼，不就是頂着一個頭銜

所謂的上司力，展現在溝通能力上，不就是看人下菜碟。也就是君君臣臣的邏輯，買的一方，會對賣的一方，多一點遷就。表示出現的就是熱情的稱兄道弟，在話語上，對方怎麼爽，怎麼拍而已。

溝通能力，是不是就是按照對方能懂的方式，把相關意圖，讓對方能明白？？  隻要能達到這個目标即可

執行力，具體在開發上，會糾結于一些細節，而忽略了具體是要做什麼了。按照靈活小步快走的邏輯，就是手推車、自行車、機車、三輪車、小轎車

喜怒不形于色，和什麼人都能打交道。是因為目标明确，隻要不影響目标的因素，都可以自動忽略掉，把目标完成後，就結束溝通即可。  格局。

溝通不是說話，是完成一個目标。  說話僅僅是溝通的一個途徑，一種表現形式

聽到不喜歡的，喜歡皺眉 

我懂你很難，改變你也不容易，那就讓你懂我，這樣相對而言容易的多

滿足虛榮心，拿好聽話甜乎

面對有權勢的人，巴結一下，也很正常嘛

高層，需要正正常劃和分解所有的工作，發放到下面去

然後由公司各個階層的人，完成這些工作，

創造出利潤，才能給股東一個交待

公司所有員工 圍繞的軸心是什麼？

工作

軸心就是工作

上司看到的不是員工之間發生了什麼，也不關注這個工作是誰完成的

沒有檢查前面的内容，但在最後簽字，這就代表要為所有的内容負所有的責任

簽字意味着承擔所有的責任