AI giúp đội IT phân biệt traffic thật và traffic tấn công DDoS

Bizfly Cloud

3521

25-06-2026

Một nền tảng thương mại điện tử có lượng truy cập tăng mạnh vào các khung giờ flash sale gặp vấn đề khó xử lý: Không biết đâu là traffic mua hàng thật, đâu là traffic tấn công DDoS đang đội lốt người dùng. Bizfly Cloud AI được triển khai để hỗ trợ đội IT phân tích log, nhận diện bất thường và đưa ra cảnh báo có ngữ cảnh trước khi hệ thống quá tải.

Bối cảnh khách hàng và áp lực cần thay đổi

Khách hàng trong case study mô phỏng này là một doanh nghiệp thương mại điện tử vận hành website, ứng dụng di động, hệ thống thanh toán và nhiều landing page chiến dịch. Đội IT nội bộ gồm nhóm System Admin, DevOps và SRE chịu trách nhiệm duy trì uptime trong các đợt sale lớn. Mỗi ngày hệ thống ghi nhận nhiều lớp dữ liệu khác nhau từ CDN, Anti DDoS, Load Balancer, firewall, application log và hệ thống giám sát máy chủ.

Áp lực lớn nhất xuất hiện ở những thời điểm traffic tăng nhanh trong thời gian ngắn. Với đội marketing, đó có thể là tín hiệu tốt vì chiến dịch đang chạy hiệu quả. Nhưng với đội vận hành, cùng một biểu đồ tăng traffic có thể là người dùng thật, bot thu thập dữ liệu, crawler không kiểm soát hoặc một đợt tấn công DDoS tầng ứng dụng. Nếu phản ứng chậm, hệ thống có nguy cơ nghẽn tài nguyên; nếu chặn quá tay, doanh nghiệp có thể tự làm mất đơn hàng thật.

Trước khi triển khai Bizfly Cloud AI, đội IT chủ yếu dựa vào dashboard giám sát, rule thủ công và kinh nghiệm của từng kỹ sư trực ca. Cách làm này vẫn có hiệu quả trong các tình huống quen thuộc, nhưng lại gặp khó khi pattern tấn công thay đổi liên tục. Trong thực tế tôi thấy, vấn đề không nằm ở việc thiếu log, mà nằm ở chỗ log quá nhiều, phân tán và không được nối lại thành một bức tranh đủ rõ để ra quyết định nhanh.

Bài toán lớn khách hàng cần giải quyết

Bài toán không chỉ là “phát hiện DDoS” theo nghĩa kỹ thuật. Điều khách hàng cần là một cơ chế giúp đội IT hiểu được bản chất của traffic trong từng thời điểm, từ đó quyết định nên cho qua, giới hạn, yêu cầu xác thực, chặn theo rule hay chuyển sang phương án bảo vệ mạnh hơn. Khi traffic thật và traffic tấn công trộn lẫn trong cùng một khung giờ, dashboard truyền thống thường chỉ cho thấy hệ thống đang tăng tải, còn nguyên nhân thật sự thì phải phân tích thêm.

Các bài toán chính được xác định trong giai đoạn khảo sát gồm:

• Khó phân biệt traffic mua hàng thật và traffic tấn công tầng ứng dụng: Website ghi nhận nhiều request vào trang sản phẩm, giỏ hàng và API thanh toán. Đội DevOps khó biết đó là người dùng đang săn sale hay bot đang tạo tải giả để làm nghẽn backend.

• Log nằm rải rác ở nhiều hệ thống khác nhau: CDN có access log, Anti DDoS có cảnh báo riêng, Load Balancer có metric kết nối, application server có lỗi 4xx và 5xx, còn hệ thống đơn hàng lại nằm trong một dashboard khác. Khi sự cố xảy ra, SRE phải mở nhiều màn hình cùng lúc để đối chiếu thủ công.

• Rule chặn thủ công dễ gây false positive: Một số IP hoặc user agent có hành vi bất thường nhưng vẫn có thể là traffic thật từ đối tác, app mobile hoặc nhà mạng dùng NAT. Nếu chặn theo rule quá rộng, hệ thống có thể ảnh hưởng đến khách hàng thật trong thời điểm doanh thu cao.

• Cảnh báo thiếu ngữ cảnh vận hành: Hệ thống giám sát có thể báo tăng request, tăng lỗi 5xx hoặc tăng CPU, nhưng không giải thích chuỗi nguyên nhân. Người trực ca phải tự suy luận xem nên mở rộng tài nguyên, bật rule bảo vệ, điều chỉnh cache hay chuyển sự cố lên cấp cao hơn.

• Không có cơ chế học lại từ sự cố cũ: Sau mỗi đợt tấn công, đội IT thường có log và biên bản xử lý, nhưng tri thức này không được biến thành workflow tái sử dụng. Lần sau gặp pattern tương tự, đội trực ca vẫn mất thời gian phân tích lại từ đầu.

Các bài toán này liên quan chặt với nhau vì cùng xuất phát từ một điểm nghẽn: Dữ liệu vận hành chưa được hợp nhất theo ngữ cảnh sự cố. Nếu chỉ xử lý từng phần riêng lẻ, doanh nghiệp có thể phát hiện tín hiệu bất thường nhưng vẫn không biết nên hành động thế nào. Vì vậy, case study này được thiết kế theo hướng xây một workflow AI hỗ trợ phân loại traffic, tổng hợp bằng chứng và đề xuất phương án phản ứng theo mức rủi ro.

Cách Bizfly Cloud AI được triển khai trong case study này

Trong case study này, Bizfly Cloud AI được đặt vào lớp phân tích vận hành nằm giữa hệ thống log và đội IT. AI không thay thế Anti DDoS, CDN hay firewall, mà nhận dữ liệu từ các hệ thống đó để phân tích theo ngữ cảnh. Dữ liệu đầu vào gồm access log từ CDN, request path, IP, ASN, user agent, tần suất truy cập, mã phản hồi HTTP, tỷ lệ cache hit, số lượng kết nối bất thường, cảnh báo từ Anti DDoS, metric từ Load Balancer và log lỗi từ origin server.

Trước khi đưa vào AI Agent, dữ liệu được chuẩn hóa theo các nhóm trường cố định. Ví dụ: Nhóm định danh nguồn truy cập, nhóm hành vi request, nhóm tác động lên hạ tầng, nhóm dấu hiệu bất thường và nhóm dữ liệu kinh doanh như thời gian chạy campaign hoặc khung giờ flash sale. Khi triển khai với dữ liệu phân tán, vấn đề không nằm ở AI trước mà nằm ở cách chuẩn hóa nguồn dữ liệu. Nếu một request ở CDN không nối được với lỗi ở backend hoặc trạng thái chiến dịch marketing, AI rất dễ đưa ra nhận định thiếu bối cảnh.

Workflow của Bizfly Cloud AI được thiết kế theo nhiều lớp xử lý. Lớp đầu tiên gom các tín hiệu bất thường như tăng request đột biến, truy cập lặp vào một endpoint, tỷ lệ cache miss tăng bất thường, nhiều IP cùng dùng một mẫu user agent hoặc tăng lỗi từ một nhóm quốc gia. Lớp thứ hai so sánh các tín hiệu đó với hành vi traffic thật trong các chiến dịch trước, lịch marketing, dữ liệu đơn hàng và trạng thái hệ thống. Lớp thứ ba tạo kết luận theo dạng: Traffic có khả năng là người dùng thật, traffic nghi ngờ bot, traffic tấn công tầng ứng dụng hoặc traffic cần theo dõi thêm.

Đầu ra không chỉ là một cảnh báo ngắn. Bizfly Cloud AI tạo một bản tóm tắt sự cố có ngữ cảnh cho DevOps và SRE, gồm mô tả pattern, nhóm endpoint bị ảnh hưởng, mức độ rủi ro, bằng chứng log tiêu biểu, tác động lên hạ tầng và đề xuất hành động. Với các tình huống rủi ro thấp, AI có thể gợi ý theo dõi thêm hoặc giới hạn rate theo phạm vi hẹp. Với tình huống rủi ro cao, AI đề xuất kích hoạt rule bảo vệ, tăng mức kiểm tra, chuyển traffic qua lớp lọc phù hợp hoặc tạo ticket sự cố để trưởng nhóm phê duyệt.

So sánh hiệu quả trước và sau triển khai

Trước khi dùng Bizfly Cloud AI, doanh nghiệp vẫn có các công cụ bảo vệ hạ tầng cần thiết. Tuy nhiên, phần phân tích ngữ cảnh còn phụ thuộc nhiều vào con người, đặc biệt khi traffic thật và traffic tấn công xuất hiện cùng lúc. Sau POC, thay đổi dễ thấy nhất không phải là AI tự xử lý toàn bộ sự cố, mà là đội IT có một lớp trợ lý phân tích giúp rút ngắn thời gian đọc log và giảm tranh luận trong lúc hệ thống đang chịu tải.

Thay đổi quan trọng nhất trong case study này là đội IT không còn nhìn traffic theo từng chỉ số rời rạc. Một đợt tăng request được đặt cạnh hành vi người dùng, endpoint bị gọi, tỷ lệ lỗi, trạng thái cache và lịch chiến dịch. Nhờ vậy, quyết định kỹ thuật có cơ sở hơn. AI không làm thay người trực ca, nhưng giúp họ có đủ dữ liệu để hành động nhanh và ít rủi ro hơn.

Quy trình triển khai Bizfly Cloud AI

Quy trình triển khai được thiết kế theo hướng POC trước, mở rộng sau. Với bài toán DDoS, nếu triển khai quá rộng ngay từ đầu, đội IT rất khó kiểm soát độ chính xác của cảnh báo và mức độ ảnh hưởng đến người dùng thật. Vì vậy, phạm vi ban đầu nên tập trung vào một nhóm website, một số endpoint quan trọng và các khung giờ có lịch sử phát sinh traffic cao.

1. Khảo sát hiện trạng và xác định bài toán chính: Đội triển khai làm việc với CTO, Head of IT, DevOps và SRE để xác định các tình huống cần ưu tiên: DDoS tầng ứng dụng, bot tạo tải giả, cache miss bất thường hay tăng lỗi backend. Ở bước này, cần thống nhất rõ thế nào là traffic thật, thế nào là traffic nghi ngờ và tình huống nào cần con người phê duyệt.

2. Thu thập, làm sạch và phân nhóm dữ liệu đầu vào: Dữ liệu từ CDN, Anti DDoS, Load Balancer, firewall, application log và hệ thống giám sát được gom về theo các trường chung. Các nguồn dữ liệu thiếu timestamp chuẩn, thiếu mã endpoint hoặc thiếu thông tin phản hồi cần được làm sạch trước, nếu không AI sẽ khó nối chuỗi sự kiện.

3. Thiết kế AI Agent hoặc workflow theo từng vấn đề nhỏ: Workflow được chia thành các nhánh như phát hiện bất thường, phân loại traffic, tóm tắt cảnh báo và gợi ý playbook phản ứng. Mỗi nhánh có tiêu chí đầu vào, logic đánh giá và đầu ra riêng để đội IT dễ kiểm tra.

4. Tích hợp với hệ thống hiện có như website, ticket, giám sát, CDN và Anti DDoS: Bizfly Cloud AI được kết nối với các nguồn log và dashboard đang có, thay vì bắt doanh nghiệp thay đổi toàn bộ hệ thống vận hành. Với các hành động có rủi ro như chặn traffic hoặc thay đổi rule, workflow nên dừng ở mức gợi ý hoặc tạo ticket chờ phê duyệt.

5. Chạy thử POC với phạm vi nhỏ: POC nên bắt đầu với một website hoặc một nhóm endpoint có rủi ro cao như trang đăng nhập, giỏ hàng, API tìm kiếm hoặc API thanh toán. Trong giai đoạn này, đội IT so sánh kết luận của AI với nhận định của kỹ sư trực ca để phát hiện điểm sai lệch.

6. Đo lường, tinh chỉnh và mở rộng triển khai: Sau POC, đội triển khai đánh giá chất lượng cảnh báo, tỷ lệ cảnh báo nhiễu, mức độ hữu ích của bản tóm tắt và khả năng hỗ trợ ra quyết định. Khi workflow ổn định, doanh nghiệp có thể mở rộng sang nhiều domain, nhiều hệ thống hoặc nhiều loại sự cố hơn.

Kinh nghiệm thực tế là không nên bắt đầu bằng mục tiêu “AI chặn DDoS tự động”. Mục tiêu hợp lý hơn là giúp đội IT nhìn đúng bản chất traffic trước, rồi mới tính đến tự động hóa một phần phản ứng. Với dữ liệu bảo mật và vận hành, việc phân quyền cũng rất quan trọng: Người xem báo cáo, người được duyệt rule, người được cấu hình hệ thống và người chỉ nhận cảnh báo phải được tách rõ ngay từ đầu.

Kết quả và giá trị doanh nghiệp nhận được

Sau khi triển khai ở phạm vi POC, giá trị đầu tiên doanh nghiệp nhận được là giảm tải cho đội trực ca trong các thời điểm traffic tăng mạnh. Thay vì phải đọc nhiều màn hình log song song, SRE nhận được một bản tóm tắt đã gom sẵn các dấu hiệu quan trọng. Bản tóm tắt này không thay thế quá trình kiểm tra kỹ thuật, nhưng giúp người trực ca biết nên bắt đầu từ đâu và cần kiểm chứng điểm nào trước.

Giá trị thứ hai nằm ở việc chuẩn hóa cách phản ứng sự cố. Trước đây, mỗi kỹ sư có thể đánh giá mức độ nghiêm trọng theo kinh nghiệm cá nhân, dẫn đến cách xử lý không đồng nhất giữa các ca trực. Khi Bizfly Cloud AI đưa ra phân loại traffic, mức rủi ro, bằng chứng log và gợi ý playbook, đội IT có một ngôn ngữ chung để trao đổi. Việc chuyển cấp lên trưởng nhóm hoặc CTO cũng dễ hơn vì thông tin đã được tóm tắt theo cấu trúc rõ ràng.

Giá trị thứ ba là khả năng mở rộng vận hành mà không phải tăng tương ứng nhân sự giám sát. Khi doanh nghiệp có thêm landing page, thêm chiến dịch hoặc thêm endpoint API, workflow AI có thể tiếp tục học từ dữ liệu đã chuẩn hóa. Không có số liệu thật nên không nên nói AI giúp giảm bao nhiêu phần trăm thời gian hay chi phí. Nhưng ở góc độ vận hành, thay đổi quan sát được là đội IT bớt phụ thuộc vào việc “người giỏi nhất phải luôn có mặt” trong mọi đợt cao điểm.

AI chưa làm được gì trong case study này

AI chưa thể tự chịu trách nhiệm cho các quyết định quan trọng như chặn diện rộng, thay đổi chính sách bảo vệ, giới hạn truy cập theo quốc gia hoặc can thiệp vào luồng thanh toán. Những quyết định này có thể ảnh hưởng trực tiếp đến doanh thu, trải nghiệm khách hàng và quan hệ với đối tác. Vì vậy, Bizfly Cloud AI trong case study này đóng vai trò phân tích, tổng hợp, gợi ý và tự động hóa một phần quy trình, không thay thế toàn bộ đội IT.

AI cũng cần dữ liệu đầu vào đủ sạch, đủ quyền truy cập và được cập nhật liên tục. Nếu log thiếu trường quan trọng, timestamp lệch nhau hoặc dữ liệu campaign không được đưa vào workflow, kết luận của AI có thể thiếu chính xác. Con người vẫn cần kiểm soát các tình huống ngoại lệ, dữ liệu nhạy cảm, quyết định có tác động lớn và các trường hợp mà AI đánh dấu là chưa đủ bằng chứng.

FAQ

1. Bizfly Cloud AI có tự động chặn traffic DDoS không?

Trong case study này, Bizfly Cloud AI không được thiết kế để tự động chặn mọi traffic nghi ngờ. Vai trò chính là phân tích log, phân loại traffic, tổng hợp bằng chứng và gợi ý hướng xử lý cho đội IT. Với các hành động có rủi ro cao như chặn diện rộng hoặc thay đổi rule bảo vệ, doanh nghiệp nên giữ bước phê duyệt của con người. Cách làm này an toàn hơn, nhất là với website có nhiều traffic thật trong giờ cao điểm.

2. Làm sao AI phân biệt traffic thật và traffic tấn công?

AI không chỉ nhìn vào số lượng request. Workflow phân tích nhiều tín hiệu cùng lúc như tần suất truy cập, endpoint bị gọi, hành trình người dùng, user agent, IP group, mã phản hồi, tỷ lệ cache miss, lỗi backend và bối cảnh chiến dịch. Khi các tín hiệu này được đặt cạnh nhau, AI có cơ sở để phân loại traffic theo mức nghi ngờ. Kết quả vẫn cần đội DevOps hoặc SRE kiểm chứng trong các tình huống nhạy cảm.

3. Doanh nghiệp cần chuẩn bị dữ liệu gì trước khi triển khai?

Doanh nghiệp nên chuẩn bị log từ CDN, Anti DDoS, Load Balancer, firewall, application server và hệ thống giám sát hạ tầng. Nếu có dữ liệu chiến dịch marketing, dữ liệu đơn hàng hoặc lịch flash sale, nên đưa vào workflow để AI hiểu bối cảnh traffic tăng. Quan trọng nhất là dữ liệu cần có timestamp thống nhất và các trường đủ rõ để nối chuỗi sự kiện. Nếu dữ liệu quá rời rạc, giai đoạn làm sạch sẽ mất nhiều thời gian hơn phần cấu hình AI.

4. Giới hạn lớn nhất của AI trong bài toán DDoS là gì?

Giới hạn lớn nhất là AI không thể hiểu đúng nếu dữ liệu đầu vào thiếu ngữ cảnh hoặc bị sai lệch. Một đợt traffic tăng có thể là khách hàng thật, bot hợp lệ, bot xấu hoặc tấn công có chủ đích, nên AI cần nhiều lớp dữ liệu để đưa ra nhận định đáng tin cậy. AI cũng không nên là bên ra quyết định cuối cùng cho các hành động ảnh hưởng lớn đến người dùng. Trong mô hình phù hợp, Bizfly Cloud AI hỗ trợ người vận hành ra quyết định nhanh hơn, nhưng không thay thế trách nhiệm kiểm soát của con người.

5. Case study này phù hợp với nhóm doanh nghiệp nào?

Mô hình này phù hợp với doanh nghiệp có website, app hoặc API thường xuyên chịu traffic cao và có rủi ro bị tấn công DDoS. Các nhóm phù hợp gồm thương mại điện tử, tài chính, truyền thông, SaaS, game, giáo dục trực tuyến và các nền tảng có giao dịch theo thời gian thực. Nếu đội IT đang phải đọc log thủ công trong mỗi đợt cao điểm, đây là bài toán nên được ưu tiên. Với doanh nghiệp nhỏ hơn, có thể bắt đầu bằng POC trên một số endpoint quan trọng trước.

6. Khi nào nên triển khai POC thay vì triển khai toàn hệ thống?

Nên triển khai POC khi doanh nghiệp chưa có đủ dữ liệu đánh giá độ chính xác của cảnh báo AI. POC giúp đội IT kiểm tra workflow trên phạm vi nhỏ, ví dụ một domain, một nhóm API hoặc một chiến dịch có lịch traffic rõ ràng. Sau giai đoạn này, doanh nghiệp có thể tinh chỉnh tiêu chí phân loại, ngưỡng cảnh báo và quy trình phê duyệt. Cách triển khai từng bước giúp giảm rủi ro và tạo niềm tin cho đội vận hành.

Kết bài

Bài toán phân biệt traffic thật và traffic tấn công DDoS không thể giải quyết tốt nếu chỉ nhìn vào một vài biểu đồ tăng tải. Doanh nghiệp cần một quy trình nối được log kỹ thuật, dữ liệu hạ tầng, bối cảnh chiến dịch và kinh nghiệm xử lý sự cố thành một luồng phân tích có thể kiểm chứng.

Trong case study mô phỏng này, Bizfly Cloud AI giúp biến quá trình đọc log và đánh giá traffic từ một công việc phụ thuộc nhiều vào kinh nghiệm cá nhân thành một workflow có dữ liệu đầu vào, tiêu chí phân loại, đầu ra và bước phê duyệt rõ ràng. Đây là nền tảng để đội IT phản ứng nhanh hơn với DDoS mà vẫn hạn chế rủi ro chặn nhầm người dùng thật.