某客戶計畫通過p2v工具遷移500臺左右映象至阿里雲華北1（青島），在應用資料遷移傳輸過程中是把使用者的系統盤、資料盤的資料通過公網傳輸到阿里雲中轉ecs例項上。
某客戶6.12-6.13號批量遷移100臺基本正常，從2018.6.13號晚10點左右開始連線阿里雲中轉ecs例項就出現中斷，現象為在客戶端telnet中轉ecs例項8703埠提示connection closed by foreign host. 但檢查中轉ecs例項的http 服務8080正常，而且其它地方測試中轉ecs例項8073埠、8080埠服務均正常。
6.20-6.21恢復正常後，繼續批量遷移了130臺左右，但6.25號開始又問題重現。
12點左右開始，客戶再次重現問題。
在客戶側telnet 10次都失敗了，在阿里雲ecs側（47.104.79.200，i-m5ecitgdpobfwwrzb6bm）抓包如上rsync_server.cap。同時在其它地方telnet 正常。
和客戶修改傳輸埠為8702測試了一下，telnet 10次全部成功，換回8703就不行了。這個跟網路運營商一貫的封埠的手法很類似，應該是埠被記錄並限制了。
客戶臨時改埠方案也行不通了，修改了2次埠都是傳了一部分之後就被強制斷開了，報一樣的傳輸錯誤。但是在其他地方telnet中轉ecs測試傳輸正常。
1）從歷史抓包資訊來看，初步判斷是安全策略或網路質量導致請求超時。
syn表示建立連線，
fin表示關閉連線，
ack表示響應，
psh表示有 data資料傳輸，
rst表示連線重置。
2）同時，從客戶反饋的網路架構環境來看，客戶網路環境部署了一些ddos、fw等的安全防護的裝置。
3）重新啟動遷移任務進行測試，此時段網路傳輸正常。
1）從客戶反饋的出口監控流量上看已經達到了頻寬上限200m。
2）客戶側通過檢查fw上的log日誌暫未發現異常資訊。
3）由於時間關係，總結並計畫第二天排查的思路：
（1）請***客戶資料中心部門畫一下當前的網路拓撲圖，明天和阿里雲專家一起開會介紹。
（2）請***客戶資料中心部門和運營商確認：如果超過了目前購買的200m頻寬，運營商會如何處理？協調讓運營商取消限制進行一次測試。
（3）後續遷移，啟用遷移工具限流，設定總流量不超過100m。
（4）請***客戶資料中心部門，將遷移時的3個隨機ip（nat出去的外部位址）修改為1個，然後進行測試。
按昨晚計畫的排查思路，客戶介紹網路環境，從中了解到客戶idc部署了流量清洗antiddos裝置、鏈路負載均衡f5、h3c m9006防火牆裝置等。大致的網路環境如下所示：
檢視antiddos、m9006日誌、策略等，均未發現異常資訊。
將原來的移動線路切換至聯通線路，將snat設定為乙個公網ip x.x.x.62,同時將頻寬限流為20m進行遷移測試，此時p2v遷移工具傳系統盤、資料盤均正常。
源伺服器測試：
其它公網環境：
1）在客戶網路環境網際網路區最外層跟運營商對接互聯的華為c6850裝置上設定聯通問題ip（x.x.x.62），也即是原來snat設定的公網ip。測試此時聯通線路是否正常的.排除定位是聯通線路問題還是企業內部網路問題，把範圍定位.
2）在c6850 測試8703埠不通，但可以訪問外部網路，跟源遷移伺服器情況一致，基本可以判斷此異常問題跟客戶網路環境無關。
更換snat公網位址測試8703埠通過，即將聯通外網ip x.x.x.62更改為x.x.x.60).基本上可以確定客戶的x.x.x.62 8703埠被上游運營商、雲廠商封堵或攔截。
1）阿里雲網路排查，聯絡「網路運營服務台」協助定位。
2）阿里雲安全策略排查，聯絡阿里雲安全同事。
3）切換電信線路進行復盤遷移測試（移動、聯通線路均已測試且都能重現同樣的問題出來，但為了讓客戶更加積極配合我們進行排查問題，故繼續又選電信線路進行測試，儘管理論上三家運營商同時封埠的概率很低）。
1）09：30 諮詢阿里雲-安全部李xx，從描述的現象看很像是安全攻擊。
2）10：30 聯絡阿里雲-安全部陳xx，陳xx通過安全運營平台檢視到攔截資訊。
3）12：30阿里雲-安全部陳xx把客戶的公網ip新增為白名單後問題解決。
資料遷移中斷，影響專案正常進行。
安全策略：本次資料遷移網路異常主要是命中了阿里雲的「防惡意攻擊的安全策略」。
觸發場景：在短時間內的大批量臨時的ecs消耗（建立到釋放）場景可能會觸發。
資料檔案遷移案例
一 在資料庫開啟的情況下 sql alter database rename file oracle product 11.2.0 dbhome 1 dbs dms.dbf to oracle oradata dcs dms.dbf alter database rename file oracle...
資料應用案例 基於機器學習的web異常檢測
0.背景 a.硬規則的異常檢測容易被黑客繞過，並且無法應對0day攻擊 同時規則構造和維護成本高。b.引入機器學習技術，但是web入侵樣本稀少，變化多樣，對模型訓練造成難度 1.思路 基於profile的方法，對正常訪問日誌建模，與正常流量不符的視為一場流量 2.方法 1 基於統計學習模型 對正常流...
利用FastCopy遷移應用資料
某個應用系統，由於前輩應用系統設計不當，導致以下幾個長期存在的問題 1.ip鏈路不穩定，經常發生iscsi丟盤現象，需要重啟整個系統才能掛載上。2.容量不足，隨時都有溢位的可能。為了行文的方便，加上以下的環境描述 windows 2003 應用資料型別 sql server 2000 文件資料 掛載...