Blog chia sẻ kiến thức FPT Cloud

Nhằm nâng cao tính chủ động trong vận hành, cải thiện hiệu suất xử lý backup job và tăng độ minh bạch trong giám sát dịch vụ, FPT Cloud chính thức cập nhật FPT Backup Native 1.7 với loạt cải tiến quan trọng.  Phiên bản mới tập trung vào 4 mục tiêu chính: Cho phép xóa các restore point cũ không còn nhu cầu sử dụng, bổ sung cơ chế thông báo khi backup job bị disable, tối ưu tốc độ thực thi job, đồng thời cải thiện quản lý dữ liệu lưu trữ và retention policy. Những nâng cấp này giúp đội ngũ kỹ thuật giảm thao tác thủ công, kiểm soát tốt hơn tài nguyên backup và duy trì hệ thống vận hành ổn định hơn trong thực tế. 1. Tối ưu tốc độ xử lý Job với Job Quota Enforcement  FPT Backup Native 1.7 tối ưu cơ chế refresh quota và cập nhật trạng thái tài nguyên, giúp rút ngắn chu kỳ đồng bộ từ 10 phút xuống còn 5 phút.  Việc rút ngắn thời gian đồng bộ không chỉ giúp hệ thống phản hồi nhanh hơn mà còn góp phần nâng cao hiệu quả điều phối trong quá trình thực thi backup job. Với các môi trường có nhiều tác vụ vận hành đồng thời, đây là cải tiến mang ý nghĩa thực tế, giúp giảm độ trễ, tăng tính liền mạch và cải thiện hiệu suất xử lý tổng thể của dịch vụ backup. 2. Phát triển luồng Auto Requeue trên EPS  Bên cạnh hiệu năng xử lý, FPT Backup Native 1.7 cũng được bổ sung cơ chế Auto Requeue trên EPS nhằm xử lý các action thất bại do lỗi tạm thời từ hạ tầng hoặc hệ thống. Trước đây, khi action bị fail, quá trình xử lý thường dừng lại hoàn toàn và yêu cầu đội ngũ kỹ thuật can thiệp thủ công để thực hiện lại. Với cơ chế mới, hệ thống có thể tự động đưa action trở lại hàng đợi để re-run theo cơ chế kiểm soát phù hợp.  Lợi ích thực tế của tính năng này gồm:  Tăng tỷ lệ thành công củajob: Nhiều lỗi tạm thời được hệ thống tự xử lý lại thay vì kết thúc fail ngay từ đầu. Giảm thao tác manual re-run: Đội ngũ vận hành không cần can thiệp lặp lại cho các lỗi ngắn hạn, giúp tiết kiệm thời gian xử lý. Cải thiện mức độ tự động hóa: Hệ thống vận hành ổn định hơn, giảm phụ thuộc vào thao tác thủ công. Tăng độ ổn định hệ thống: Dịch vụ backup duy trì trạng thái hoạt động ổn định hơn trong quá trình thực thi thực tế. 3. Hỗ trợ xóa Restore Point trực tiếp trên Unify Portal  FPT Backup Native 1.7 bổ sung khả năng Delete Restore Point trực tiếp trên Unify Portal cho toàn bộ 4 cụm dịch vụ backup từ 2021 đến 2024.  Về mặt vận hành, đây là nâng cấp giúp đồng bộ tính năng quản trị giữa các cụm dịch vụ, đồng thời trao thêm quyền chủ động cho doanh nghiệp trong việc kiểm soát dữ liệu backup. Khi các restore point không cần thiết được dọn dẹp kịp thời, hệ thống có thể giảm tải dung lượng lưu trữ, tối ưu tài nguyên hạ tầng và hỗ trợ doanh nghiệp kiểm soát chi phí hiệu quả hơn. Hình 1: Action delete restore points 4. Cải thiện Upload Multipart trên S3 cho cụm 2021–2022  Phiên bản 1.7 tiếp tục tối ưu cơ chế upload multipart lên S3 object storage cho các cụm dịch vụ 2021–2022.  Đây là cập nhật tập trung vào hiệu năng và độ ổn định của quá trình truyền tải dữ liệu, đặc biệt quan trọng với các workload backup dung lượng lớn. Nhờ nâng cấp cơ chế này, hệ thống giúp giảm lỗi upload thất bại, tăng độ ổn định khi thực hiện backup dữ liệu lớn và cải thiện hiệu suất truyền tải dữ liệu một cách rõ rệt. 5. Khởi tạo thông báo khi backup job bị disable  Không chỉ tập trung vào hiệu năng, FPT Backup Native 1.7 còn tăng cường khả năng giám sát dịch vụ thông qua cơ chế Notify khi backup job bị disable, áp dụng cho cả user và admin. Khi backup job bị vô hiệu hóa, hệ thống sẽ chủ động gửi thông báo để các bên liên quan nắm bắt kịp thời tình trạng dịch vụ.  Tính năng này mang lại giá trị rõ rệt trong vận hành thực tế. Thay vì chỉ phát hiện sự cố khi phát sinh hậu quả, đội ngũ kỹ thuật có thể sớm nhận biết job đã bị disable, xác định nguyên nhân và chủ động đưa ra hướng xử lý. Điều này không chỉ giúp tăng tính minh bạch trong quản trị, mà còn hạn chế rủi ro job bị tắt ngoài ý muốn, đồng thời hỗ trợ truy vết nguyên nhân sự cố dễ dàng hơn trong những tình huống cần kiểm tra hoặc đối soát.   Hình 2: Job Disable bởi hệ thống  Hình 3: Job Disable bởi user Hoàn thiện năng lực vận hành backup cho doanh nghiệp  Có thể thấy, FPT Backup Native 1.7 không đơn thuần là một bản cập nhật tính năng, mà là bước hoàn thiện quan trọng ở lớp vận hành dịch vụ backup. Thông qua các cải tiến về, phiên bản mới giúp doanh nghiệp chủ động hơn trong quản trị backup, giảm tải áp lực vận hành thủ công và nâng cao độ ổn định của toàn hệ thống.  Trong bối cảnh dữ liệu ngày càng trở thành tài sản cốt lõi của doanh nghiệp, những cải tiến ở lớp vận hành như FPT Backup Native 1.7 không chỉ giúp đội ngũ kỹ thuật làm việc hiệu quả hơn, mà còn góp phần bảo đảm tính liên tục và an toàn cho toàn bộ hệ thống.  Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud:  Hotline: 1900 638 399 Email: support@fptcloud.com Support: m.me/fptsmartcloud 

Trước khi đi vào vấn đề, cần làm rõ một điều: relational database và SQL không phải công nghệ lỗi thời. Relational Database (Cơ sở dữ liệu quan hệ) là một mô hình lưu trữ dữ liệu dưới dạng các bảng (tables) gồm các hàng và cột - rất giống với cách chúng ta nhìn một file Excel. Điểm đặc biệt là các bảng này không đứng độc lập mà có mối quan hệ (relationship) chặt chẽ với nhau thông qua các trường dữ liệu chung. SQL (Structured Query Language) chính là ngôn ngữ tiêu chuẩn dùng để "nói chuyện", truy vấn và thao tác với các cơ sở dữ liệu quan hệ này. Sự kết hợp này tạo nên một hệ thống cực kỳ chặt chẽ, hoạt động dựa trên bộ quy tắc bất di bất dịch mang tên ACID (đặc biệt là tính Atomicity - Nguyên tố và Isolation - Độc lập). Các quy tắc này đảm bảo rằng: hoặc là giao dịch của bạn thành công trọn vẹn hoặc là thất bại và hệ thống quay về trạng thái ban đầu chứ không bao giờ có chuyện lấp lửng hay sai lệch dữ liệu. Chính nhờ nền tảng vững chắc đó, phần mềm kế toán doanh nghiệp, hệ thống ngân hàng lõi, nền tảng quản lý giao dịch tài chính vẫn đang chạy ổn định. Vậy tại sao ngày càng nhiều engineering team đang gặp vấn đề với relational database khi hệ thống scale? Relational database được thiết kế khi hệ thống phần mềm điển hình có kiến trúc khá đơn giản: một ứng dụng trung tâm, một database, lượng truy cập ổn định và dự đoán được. Tuy nhiên, lấy ví dụ một nền tảng e-commerce trung bình ở Việt Nam giờ có thể gồm hàng chục ứng dụng vận hành độc lập, quản lý đơn hàng, thanh toán, kho hàng, gợi ý sản phẩm, thông báo đẩy, điểm thưởng và mỗi ứng dụng do một nhóm khác nhau phát triển. Đi kèm đó là lượng truy cập không còn ổn định. Một chiến dịch khuyến mãi có thể đẩy số lượng yêu cầu lên hàng chục lần chỉ trong vài phút. Thêm một điểm khác biệt so với hiện nay là yêu cầu về dữ liệu thay đổi liên tục. Nhóm sản phẩm cần thêm thuộc tính mới cho từng danh mục hàng hóa. Nhóm thiết kế cần ghi lại thêm hành vi người dùng. Nhóm phân tích cần dữ liệu theo thời gian thực. Khi đặt relational database vào bối cảnh này, ba điểm lệch pha bắt đầu bộc lộ. Ba điểm lệch pha giữa SQL và hệ thống hiện đại 1. Một database phục vụ quá nhiều ứng dụng - điểm nghẽn không ai tính đến Hãy hình dung thế này: một nhà bếp trung tâm phục vụ mười quầy bán hàng cùng lúc. Khi tất cả đều đặt đơn vào giờ cao điểm, vấn đề không phải là thiếu nguyên liệu mà là nhà bếp không thể xử lý tất cả cùng một lúc. Theo đó, nếu trong trường hợp nhiều bộ phận phần mềm dùng chung một relational database, kịch bản tương tự xảy ra. Khi một bộ phận chạy tác vụ nặng, ví dụ xuất báo cáo, gửi thông báo hàng loạt, nó chiếm dụng tài nguyên của hiệu năng của Database chung, kéo chậm tất cả các bộ phận còn lại dù chúng hoàn toàn không liên quan. Đây là vấn đề của kiến trúc thiết kế database, không phải vấn đề tối ưu. Viết lại câu truy vấn hay thêm chỉ mục tìm kiếm không giải quyết được khi nguyên nhân gốc rễ là tất cả đều đang tranh nhau một kho dữ liệu duy nhất. Câu chuyện thực tế: Một startup fintech tại Đông Nam Á từng gặp chính xác tình huống này. Khi hệ thống bắt đầu gửi thông báo đẩy hàng loạt vào buổi sáng - thời điểm người dùng hoạt động nhiều nhất, tốc độ xử lý giao dịch của toàn bộ hệ thống giảm đáng kể. Sau nhiều tuần tìm nguyên nhân, đội kỹ thuật nhận ra rằng bộ phận gửi thông báo và bộ phận xử lý thanh toán đang tranh nhau tài nguyên trên cùng một kho dữ liệu. Giải pháp cuối cùng không phải là tối ưu code mà là tách dữ liệu của hai bộ phận ra khỏi nhau. 2. Dữ liệu bị phân tán ở nhiều nơi và hợp nhất là điều không đơn giản Relational database có khả năng kết hợp dữ liệu từ nhiều bảng trong một câu truy vấn duy nhất. Đây là một trong những điểm mạnh nhất khiến nó phù hợp với báo cáo và phân tích phức tạp. Nhưng trong hệ thống hiện đại, mỗi bộ phận phần mềm thường quản lý dữ liệu riêng của mình. Thông tin đơn hàng ở một nơi, thông tin khách hàng ở một nơi khác, thông tin sản phẩm ở nơi khác nữa. Khi đó, việc tổng hợp dữ liệu từ nhiều nguồn không còn là một câu truy vấn đơn giản nữa. Nó trở thành một chuỗi các bước gọi qua lại giữa các bộ phận, tổng hợp kết quả ở tầng ứng dụng, và xử lý nhiều tình huống lỗi có thể xảy ra ở từng bước. Thao tác trước đây mất vài phần nghìn giây giờ có thể mất vài trăm lần lâu hơn và có thể gặp sự cố ở nhiều điểm khác nhau trong chuỗi xử lý. 3. Cấu trúc dữ liệu cứng nhắc - khi database chậm hơn nhịp độ kinh doanh Relational database được thiết kế với cấu trúc dữ liệu chặt chẽ: mỗi bảng có các cột xác định sẵn, mỗi cột có kiểu dữ liệu cố định. Tính chặt chẽ này là lợi thế khi dữ liệu ổn định và ít thay đổi. Nhưng nó trở thành rào cản khi sản phẩm cần thay đổi nhanh. Thêm một trường thông tin mới vào bảng dữ liệu đang có hàng chục triệu bản ghi trên hệ thống đang chạy thực tế không phải thao tác đơn giản. Tùy vào cách hệ thống được cấu hình, thao tác này có thể khóa bảng dữ liệu đó trong vài phút đến vài giờ đồng nghĩa với việc hệ thống gián đoạn. Ngay cả khi có công cụ hỗ trợ, quy trình vẫn đòi hỏi: viết kịch bản chuyển đổi dữ liệu, kiểm tra trên môi trường thử nghiệm, phối hợp giữa nhiều nhóm, và triển khai theo từng bước để tránh sự cố. Kết quả thực tế: những thay đổi nhỏ trong cách lưu trữ dữ liệu thêm một thuộc tính sản phẩm, ghi nhận thêm một loại hành vi người dùng, thay đổi cách tổ chức thông tin khuyến mãi tốn nhiều ngày công sức của đội kỹ thuật mà không trực tiếp tạo ra giá trị cho người dùng. Nhân con số đó với tần suất thay đổi trong một quý, và ta thấy cấu trúc dữ liệu cứng nhắc đang âm thầm làm chậm tốc độ phát triển sản phẩm theo cách khó đo lường nhưng rất thực tế. SQL vẫn là lựa chọn đúng, cho đúng bài toán Ba vấn đề trên không phải lý do để từ bỏ relational database. Đây là lý do để hiểu rõ hơn khi nào nó là lựa chọn tốt nhất. Vấn đề nảy sinh khi áp dụng relational database cho những bài toán khác với bản chất thiết kế của nó: dữ liệu sản phẩm cần thay đổi cấu trúc thường xuyên, thông tin người dùng với nhiều thuộc tính lồng nhau, luồng sự kiện từ hàng triệu người dùng, hay nội dung số với định dạng đa dạng. Khi hệ thống bắt đầu mở rộng, câu hỏi không còn là "SQL hay NoSQL?" mà nên là: Dữ liệu của ứng dụng/dịch vụ này cần được tổ chức như thế nào để có thể mở rộng độc lập, thay đổi cấu trúc mà không gây các tác động đến kết nối và sự liền mạch, và phục vụ đúng các yêu cầu truy cập của nó? Với một số hệ thống, câu trả lời vẫn là relational database. Với một số hệ thống khác, đặc biệt là những nơi dữ liệu thay đổi cấu trúc thường xuyên hoặc cần mở rộng linh hoạt theo chiều ngang - câu trả lời dần hướng về phía các mô hình database khác. Document database là một trong những mô hình được nhiều hệ thống lớn lựa chọn cho nhóm bài toán thứ hai. Trong bài tiếp theo, chúng ta sẽ đi vào câu hỏi thực tế nhất: relational database và document database khác nhau ở đâu — và khi nào nên chọn loại nào cho từng phần của hệ thống? Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud:  Hotline: 1900 638 399 Email: support@fptcloud.com Support: m.me/fptsmartcloud 

Trong ngành F&B, sự tăng trưởng sẽ kéo theo áp lực lên toàn bộ hệ thống vận hành - từ xử lý đơn hàng, quản lý khách hàng đến đảm bảo trải nghiệm trên hàng trăm điểm bán. Đó cũng là bài toán mà Golden Gate - một trong những hệ thống F&B lớn tại Việt Nam - phải đối mặt khi bước vào giai đoạn tăng tốc mở rộng.  Tăng trưởng càng nhanh - Thách thức công nghệ càng lộ rõ Với quy mô khoảng 600 nhà hàng, hơn 35 thương hiệu và gần 50 hệ thống ứng dụng vận hành đồng thời, Golden Gate là một ví dụ điển hình cho độ phức tạp của bài toán công nghệ trong F&B. Khi số lượng điểm bán và thương hiệu tăng lên, hệ thống không chỉ phải xử lý nhiều hơn, mà còn phải xử lý trong những điều kiện khó dự đoán hơn - đặc biệt là các thời điểm lưu lượng tăng đột biến. Ở giai đoạn đầu, những giới hạn của hệ thống có thể chưa rõ ràng. Nhưng khi bước vào “pha” mở rộng nhanh, các thách thức bắt đầu xuất hiện. Đó là độ trễ trong giờ cao điểm, là việc triển khai thay đổi hệ thống mất nhiều thời gian hơn dự kiến, hay sự phụ thuộc vào các thao tác thủ công để duy trì vận hành ổn định. Những vấn đề này không xảy ra đồng loạt, nhưng tích tụ theo thời gian và dần trở thành lực cản đối với tăng trưởng. Đáng chú ý, trong ngành F&B, những thách thức này không dừng lại ở hệ thống mà nhanh chóng phản ánh ra trải nghiệm khách hàng. Với hơn 18 triệu lượt khách mỗi năm, bất kỳ gián đoạn nào trong quá trình đặt bàn, gọi món hay thanh toán đều có thể ảnh hưởng trực tiếp đến doanh thu và mức độ hài lòng. Chính những áp lực này buộc Golden Gate phải nhìn lại toàn bộ nền tảng công nghệ, không phải để tối ưu từng phần, mà để tái cấu trúc một cách tổng thể. Không chỉ là chuyển đổi hạ tầng, mà là một bài toán đồng phát triển Thay vì tiếp cận theo hướng “triển khai Cloud”, Golden Gate lựa chọn một hướng đi khác: bắt đầu từ bài toán vận hành và tìm lời giải công nghệ phù hợp. Đây cũng là điểm khởi đầu cho quá trình hợp tác với FPT Cloud. Trong quá trình triển khai, FPT không chỉ đóng vai trò là nhà cung cấp hạ tầng mà còn tham gia trực tiếp vào quá trình đánh giá và thiết kế lại hệ thống cùng đội ngũ IT của Golden Gate. Toàn bộ các ứng dụng, hạ tầng và luồng dữ liệu được rà soát để xác định đâu là điểm nghẽn thực sự ảnh hưởng đến khả năng mở rộng và vận hành. [caption id="attachment_71564" align="aligncenter" width="2560"] Anh Đào Văn Hoàn - Head of ITS, Golden Gate Group chia sẻ về hiệu quả chuyển đổi lên Cloud. Ảnh: FPT Smart Cloud.[/caption] Từ đó, một kiến trúc mới được xây dựng với mục tiêu không chỉ cải thiện hiệu năng mà còn tạo ra một nền tảng có thể mở rộng linh hoạt theo nhu cầu thực tế kinh doanh. Việc chuyển đổi lên Cloud vì vậy không đơn thuần là thay đổi nơi đặt hệ thống, mà là chuyển đổi cách hệ thống vận hành - từ mô hình hạ tầng cố định sang mô hình có thể co giãn theo thời gian thực. Quá trình này đòi hỏi sự phối hợp chặt chẽ giữa hai bên, bởi với các hệ thống quy mô lớn, không tồn tại một “mô hình chuẩn” có thể áp dụng sẵn. Mỗi quyết định về kiến trúc đều phải gắn trực tiếp với đặc thù vận hành của doanh nghiệp. Triển khai trong thời gian ngắn, nhưng không đánh đổi sự ổn định Một trong những thách thức lớn nhất của các dự án chuyển đổi hạ tầng là làm sao vừa thay đổi hệ thống, vừa không ảnh hưởng đến hoạt động kinh doanh đang diễn ra. Với Golden Gate, yêu cầu này càng khắt khe hơn khi hệ thống phải vận hành liên tục trên toàn chuỗi. Toàn bộ 12 ứng dụng với khoảng 70 máy chủ đã được chuyển đổi lên nền tảng Cloud trong thời gian ngắn, nhưng vẫn đảm bảo không gián đoạn vận hành. Để làm được điều đó, quá trình triển khai được chia thành nhiều giai đoạn với các phương án như chạy song song hệ thống, kiểm thử tải và cắt chuyển có kiểm soát. Điều này cho thấy trong các dự án chuyển đổi quy mô lớn, công nghệ chỉ là một phần của bài toán. Phần còn lại nằm ở phương pháp triển khai và khả năng kiểm soát rủi ro - nơi sự phối hợp giữa đội ngũ FPT Cloud và Golden Gate đóng vai trò quyết định. Khi hạ tầng không còn là điểm nghẽn của tăng trưởng Sau khi hoàn tất chuyển đổi, giá trị của việc hợp tác bắt đầu thể hiện rõ ở cách hệ thống vận hành. Khả năng tự động mở rộng giúp hệ thống thích ứng linh hoạt với các đợt traffic tăng đột biến, thay vì phụ thuộc vào dự báo trước hoặc can thiệp thủ công. Điều này đặc biệt quan trọng trong ngành F&B, nơi doanh thu thường tập trung vào các khung giờ cao điểm. Ở cấp độ vận hành, việc chuẩn hóa hạ tầng và áp dụng các công cụ giám sát tập trung giúp doanh nghiệp chuyển từ trạng thái phản ứng sang trạng thái chủ động. Các sự cố có thể được phát hiện sớm và xử lý nhanh hơn, giảm thiểu ảnh hưởng đến khách hàng. Đồng thời, việc rút ngắn thời gian triển khai và cập nhật hệ thống cũng tạo điều kiện để Golden Gate linh hoạt hơn trong việc phát triển sản phẩm, triển khai chương trình marketing và thử nghiệm các mô hình dịch vụ mới. Khi đó, công nghệ không còn là yếu tố cần “theo kịp”, mà trở thành nền tảng hỗ trợ doanh nghiệp đi nhanh hơn. Từ một dự án công nghệ mở ra nền tảng cho tăng trưởng dài hạn Điểm đáng chú ý trong quá trình hợp tác giữa FPT Cloud và Golden Gate không nằm ở việc “chuyển đổi thành công”, mà ở cách tiếp cận. Thay vì coi Cloud là một sản phẩm, hai bên tiếp cận như một nền tảng cần được thiết kế và vận hành cùng nhau. Khi hạ tầng không còn là giới hạn, doanh nghiệp có thể tập trung vào những yếu tố tạo ra giá trị thực sự: trải nghiệm khách hàng, tối ưu vận hành và khai thác dữ liệu. Đồng thời, nền tảng công nghệ linh hoạt cũng mở ra dư địa cho các bước phát triển tiếp theo, từ mở rộng hệ sinh thái số đến đáp ứng các yêu cầu về quy mô và quản trị trong dài hạn. Trong bối cảnh ngành F&B ngày càng cạnh tranh, câu chuyện này phản ánh một xu hướng rõ ràng: lợi thế không còn nằm ở việc doanh nghiệp có công nghệ hay không, mà ở cách xây dựng và vận hành nền tảng công nghệ phù hợp nhằm giải quyết bài toán hiện tại, cũng  trở thành nền móng cho tăng trưởng bền vững. Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud:  Hotline: 1900 638 399 Email: support@fptcloud.com Support: m.me/fptsmartcloud 

Trong nhiều ngành nghề kinh doanh, câc dịp cao điểm như flash sale, sự kiện tri ân, Lễ Tết...thường dẫn đến lượng truy cập lớn trên hệ thống. Và kịch bản quen thuộc thường xảy ra: hệ thống bắt đầu chậm, sau đó lỗi hàng loạt chỉ sau vài phút traffic tăng. Điều đáng nói ở đây là gì? Đội ngũ vận hành đã có sự chuẩn bị. Server được tăng gấp đôi, thậm chí gấp ba tài nguyên từ chiều hôm trước. Hệ thống giám sát (Monitoring) đã bật cảnh báo từ sớm. Nhưng mọi nỗ lực dường như vô nghĩa và hệ thống vẫn "chết đứng" ngay vào những phút đầu tiên nổ ra sự kiện. Tại sao một hệ thống được chuẩn bị kỹ lưỡng về hạ tầng vẫn sập? Câu trả lời nằm ở một góc tối ít ai ngờ tới và thường bị bỏ qua đầu tiên: Không phải do Web Server đuối sức, cũng không phải do nghẽn băng thông mà thủ phạm chính là Database. Hệ thống của bạn không sập đơn thuần vì lượng traffic quá đông. Nguyên nhân cốt lõi là do kiến trúc hệ thống vốn dĩ không được sinh ra để phục vụ quy mô khổng lồ đó. Có 3 điểm nghẽn bóp nghẹt dòng chảy dữ liệu và cả ba đều liên quan trực tiếp đến cách Database được thiết kế từ gốc, chứ không phải do cách nó được phân bổ tài nguyên vận hành. 1. Khi Vertical Scaling chạm giới hạn của Database Một phản xạ phổ biến khi hệ thống bắt đầu chậm là nâng cấp phần cứng của server database. CPU được tăng thêm lõi xử lý, RAM được mở rộng, ổ lưu trữ được thay bằng loại có tốc độ cao hơn. Cách tiếp cận này được gọi là vertical scaling nhằm tăng sức mạnh cho một máy chủ duy nhất. Trong giai đoạn đầu, vertical scaling thường mang lại cải thiện rõ rệt. Các truy vấn dữ liệu (database queries) được xử lý nhanh hơn và thời gian phản hồi của hệ thống giảm xuống. Tuy nhiên, cách mở rộng này có một giới hạn tự nhiên: toàn bộ dữ liệu và toàn bộ truy cập vẫn đang tập trung vào một node database duy nhất. Khi lưu lượng truy cập tiếp tục tăng, database server dần trở thành một “điểm nghẽn trung tâm”. CPU có thể chạm ngưỡng sử dụng tối đa, hàng nghìn truy vấn đồng thời bắt đầu cạnh tranh tài nguyên, và thời gian xử lý mỗi request tăng lên nhanh chóng. Ở giai đoạn này, việc tiếp tục nâng cấp server thường mang lại hiệu quả rất hạn chế. Bởi dù phần cứng có mạnh đến đâu, một database đơn lẻ vẫn phải xử lý toàn bộ workload của hệ thống. Vấn đề lúc này không còn là server yếu, mà là kiến trúc database chưa được thiết kế để mở rộng theo lưu lượng truy cập. 2. Giới hạn kết nối: khi Database hết “làn xử lý” Hãy hình dung database như một trạm thu phí trên cao tốc với 200 làn xe cố định. Ngày thường, xe đi lại mượt mà. Nhưng vào 12:00 ngày 4.4, 50.000 xe đổ vào cùng lúc. Dù mỗi làn xử lý rất nhanh tuy nhiên ùn tắc vẫn xảy ra từ hàng cây số trước trạm. Trong hầu hết các hệ thống web, mỗi request từ người dùng sẽ cần một kết nối tới database để đọc hoặc ghi dữ liệu. Số lượng kết nối này được quản lý thông qua cơ chế gọi là connection pool. Trong điều kiện bình thường, cơ chế này hoạt động rất ổn định. Các request được phân phối qua các kết nối sẵn có và database xử lý chúng với độ trễ rất thấp. Nhưng khi traffic tăng đột biến, số lượng request đồng thời có thể tăng gấp hàng chục lần trong vài giây. Khi đó, toàn bộ connection pool nhanh chóng bị sử dụng hết. Những request mới buộc phải chờ kết nối trống trước khi được xử lý. Điều đáng chú ý là ở nhiều sự cố production, database server vẫn còn tài nguyên CPU và RAM. Tuy nhiên, vì tất cả các kết nối đều đã được sử dụng, hệ thống vẫn không thể xử lý thêm request mới. Trong một số trường hợp, tình hình còn trở nên tệ hơn khi ứng dụng bắt đầu tự động retry các request bị timeout. Những request retry này tạo thêm kết nối mới tới database, khiến connection pool cạn nhanh hơn và tạo ra hiệu ứng quá tải dây chuyền 3. Write Storm — sự bùng nổ lượng truy cập từ E-commerce và Fintech Trong các hệ thống có nhiều giao dịch như thương mại điện tử hoặc fintech, một vấn đề khác thường xuất hiện khi lượng giao dịch hoặc truy cập tăng mạnh: write storm trong database. Relational database được thiết kế để đảm bảo tính chính xác và nhất quán của dữ liệu. Khi một giao dịch đang cập nhật một bản ghi, database thường khóa tạm thời bản ghi đó để tránh việc nhiều giao dịch thay đổi dữ liệu cùng lúc. Trong ngày thường, cơ chế này hoạt động hoàn hảo. Nhưng trong flash sale và khi 10.000 người cùng bấm "Thanh toán" trong 3 giây cho cùng một sản phẩm theo đó tất cả 10.000 transaction đó đang tranh nhau một row lock. Kết quả: không phải 10.000 transactions xử lý song song. Mà là 10.000 transactions xếp hàng tuần tự, mỗi cái chờ cái trước hoàn thành. Trong các hệ thống có lưu lượng giao dịch lớn, hiện tượng này có thể lan rộng rất nhanh và trở thành nguyên nhân chính khiến database phản hồi chậm hoặc ngừng xử lý request mới. Bài toán thực sự không phải là server, mà là kiến trúc Database Nhìn lại, ba nguyên nhân trên đều dẫn tới một kết luận giống nhau: trong các hệ thống có lượng người dùng lớn, việc mở rộng server chỉ là một phần của bài toán. Yếu tố quan trọng hơn là cách kiến trúc database được thiết kế để xử lý lưu lượng truy cập tăng dần theo thời gian. Trong giai đoạn đầu của một sản phẩm, việc sử dụng một relational database chạy trên một node duy nhất là hoàn toàn hợp lý. Nó giúp hệ thống đơn giản, dễ vận hành và đảm bảo tính nhất quán của dữ liệu. Nhưng khi hệ thống phát triển và lượng giao dịch tăng lên, kiến trúc này bắt đầu bộc lộ giới hạn. Việc tập trung toàn bộ dữ liệu và toàn bộ truy cập vào một điểm duy nhất khiến database trở thành nút thắt cổ chai của toàn bộ hệ thống. Đó là lý do nhiều tổ chức khi thiết kế hệ thống ở quy mô lớn thường bắt đầu bằng một câu hỏi khác: Database cần được tổ chức như thế nào để hệ thống có thể phân tán tải và mở rộng theo lưu lượng truy cập, thay vì dồn toàn bộ áp lực vào một máy chủ duy nhất? Câu hỏi này chính là điểm khởi đầu của nhiều kiến trúc database hiện đại.

Trong bối cảnh các mối đe dọa an ninh mạng ngày càng tinh vi, nền tảng FPT AppSec đã khẳng định năng lực khi xuất sắc giành giải Đồng (Bronze) tại hạng mục Application Security của Cybersecurity Excellence Awards. Đây là một trong những giải thưởng uy tín do Cybersecurity Insiders tổ chức, với hơn 600.000 chuyên gia an ninh mạng và CNTT toàn cầu tham gia đánh giá. Các đề cử được xét duyệt dựa trên những tiêu chí khắt khe về tính sáng tạo, hiệu quả, tác động và khả năng bảo vệ doanh nghiệp trước các mối đe dọa ngày càng phức tạp.  Chia sẻ về khoảnh khắc nhận giải, anh Bùi Song Toàn – Leader dự án – cho biết: “Thật ra lúc đầu mình không có cảm xúc gì hoành tráng lắm, chủ yếu là nhẹ nhõm. Nhẹ nhõm vì hướng anh em chọn từ đầu là đúng“. Với anh, giải thưởng không chỉ là thành tích mà còn là một sự xác nhận: “Giải này như một cái gật đầu từ bên ngoài: ‘Ừ, đúng rồi đó“.  FPT AppSec là nền tảng Application Security Posture Management (ASPM) được phát triển nhằm giải quyết một trong những thách thức lớn nhất hiện nay: tình trạng phân mảnh và thiếu tính chủ động trong bảo mật ứng dụng, đặc biệt trong môi trường cloud-native.  Khác với các phương pháp truyền thống vốn dựa vào nhiều công cụ rời rạc và các đợt quét định kỳ, FPT AppSec cung cấp khả năng quan sát liên tục đối với toàn bộ bề mặt tấn công của ứng dụng. Nền tảng này cho phép tổng hợp và phân tích các lỗ hổng, điểm yếu bảo mật và yếu tố rủi ro trong một bức tranh thống nhất, từ đó giúp doanh nghiệp đưa ra quyết định chính xác và kịp thời.  Anh Bùi Song Toàn (áo cam) và team FPT AppSec. Đáng chú ý, bài toán khó nhất mà team phải đối mặt không nằm ở công nghệ mà ở cách xác định giá trị thực của bảo mật. Như anh Toàn chia sẻ: “Bài toán khó nhất không phải về code, mà về mục tiêu: làm sao để bảo mật thực sự có ích chứ không chỉ có mặt“.  Thực tế, nhiều công cụ bảo mật hiện nay tạo ra khối lượng lớn cảnh báo nhưng lại thiếu khả năng định hướng hành động. Điều này khiến đội ngũ phát triển khó ưu tiên xử lý, dẫn đến hiệu quả bảo mật không như kỳ vọng. Xuất phát từ vấn đề đó, đội ngũ đã dành nhiều thời gian để tìm lời giải cho câu hỏi: “Làm sao để nói cho đúng nguy cơ nào thực sự nguy hiểm?“.  Một trong những điểm khác biệt nổi bật của FPT AppSec đến từ nền tảng nghiên cứu chuyên sâu. Sản phẩm được xây dựng dựa trên kinh nghiệm thực tiễn trong việc phát hiện và công bố các lỗ hổng bảo mật, qua đó tích hợp góc nhìn của “attacker” vào quá trình phân tích và ưu tiên rủi ro. Như anh Toàn nhấn mạnh, đây là quá trình “đi từ thực tế”: tự nghiên cứu lỗ hổng, tham gia coordinated disclosure và chuyển hóa hiểu biết đó thành logic đánh giá rủi ro trong sản phẩm.  Không chỉ dừng lại ở việc phát hiện, FPT AppSec còn hỗ trợ doanh nghiệp chuyển đổi từ cách tiếp cận bảo mật dựa trên tuân thủ sang mô hình quản trị rủi ro chủ động. Bằng việc đặt các lỗ hổng trong bối cảnh vận hành thực tế, nền tảng giúp giảm thiểu tình trạng “alert fatigue” và nâng cao hiệu quả xử lý.  Theo anh Toàn, điều giúp sản phẩm ghi điểm với hội đồng quốc tế không nằm ở cách “trình bày”, mà ở bản chất giải pháp: “FPT AppSec giải một bài toán thật, theo cách thật. Không phải marketing“. Đồng thời, toàn bộ mô tả sản phẩm đều có thể kiểm chứng từ chính hoạt động nghiên cứu và triển khai thực tế của team.  Là một sản phẩm thuộc hệ sinh thái của FPT Smart Cloud, FPT AppSec tiếp tục khẳng định năng lực nghiên cứu, phát triển và làm chủ công nghệ của FPT trong lĩnh vực an toàn thông tin.  Giải thưởng lần này không chỉ là sự ghi nhận về mặt chuyên môn mà còn mở ra cơ hội để các giải pháp “Make in Vietnam” tiến xa hơn trên thị trường quốc tế. Với team phát triển, đây cũng là một cột mốc để nhìn lại và tiếp tục tiến lên. Như anh Toàn chia sẻ: “Giải thưởng này là lý do để mình nhìn lại xem đã đi đúng hướng chưa, nhưng không phải lý do để dừng lại“. 

Trong nhiều năm, F&B được nhìn nhận là ngành xoay quanh mặt bằng, sản phẩm và trải nghiệm tại chỗ. Tuy nhiên, nhận định này đã trở nên lỗi thời khi quy mô kinh tế số Việt Nam đã vượt mốc hàng chục tỷ USD và tiếp tục tăng trưởng mạnh, kéo theo sự bùng nổ của các dịch vụ tiêu dùng trực tuyến như giao đồ ăn và đặt bàn qua app. Điều này khiến mỗi trải nghiệm ăn uống ngày nay không còn dừng ở “món ăn”, mà được quyết định bởi tốc độ xử lý đơn, độ ổn định hệ thống và khả năng cá nhân hóa theo thời gian thực. Khi mà doanh thu có thể tăng vọt chỉ trong vài giờ cao điểm, mọi giới hạn về công nghệ đều nhanh chóng trở thành điểm nghẽn tăng trưởng. Đặc thù vận hành khiến F&B trở thành một bài toán công nghệ phức tạp Điểm làm nên sự khác biệt của F&B không nằm ở quy mô lớn hay nhỏ, mà nằm ở tính “không ổn định có hệ thống” trong vận hành. Khác với nhiều ngành có nhu cầu tương đối dự đoán được, F&B thường xuyên phải đối mặt với những biến động đột ngột về lưu lượng - nơi nhu cầu có thể tăng vọt chỉ trong vài giờ cao điểm và nhanh chóng quay về mức bình thường ngay sau đó. Chỉ trong vài giờ cao điểm của các dịp lễ hoặc chiến dịch marketing, lượng truy cập hệ thống có thể tăng vọt nhiều lần so với bình thường. Chính đặc điểm này khiến cho bài toán công nghệ trong F&B không còn đơn thuần là “đủ dùng", mà phải luôn trong trạng thái sẵn sàng thích ứng. Nếu hệ thống không kịp phản ứng lại, hậu quả không chỉ là chậm đơn hay lỗi app, mà là trải nghiệm khách hàng bị gián đoạn ngay tại thời điểm họ sẵn sàng chi tiêu nhất - thời điểm mang tính quyết định về doanh thu. Song song với đó là sự phức tạp đến từ mô hình vận hành đa thương hiệu. Một doanh nghiệp F&B quy mô lớn không chỉ quản lý một chuỗi, mà thường vận hành hàng chục thương hiệu khác nhau, mỗi thương hiệu lại có định vị, tệp khách hàng và mô hình vận hành riêng. Điều này kéo theo hàng loạt hệ thống ứng dụng song song - từ POS, CRM, loyalty cho đến các ứng dụng dành cho khách hàng. Vấn đề không chỉ là “có bao nhiêu hệ thống”, mà là làm thế nào để những hệ thống này vừa độc lập đủ để linh hoạt, vừa kết nối đủ để tạo thành một bức tranh vận hành thống nhất. Áp lực càng trở nên rõ rệt hơn khi đặt trong bối cảnh tăng trưởng nhanh của thị trường. Không ít doanh nghiệp đặt mục tiêu mở rộng từ vài trăm lên hàng nghìn nhà hàng trong vòng vài năm. Khi đó, hạ tầng công nghệ không còn đơn thuần là công cụ hỗ trợ, mà trở thành yếu tố quyết định xem doanh nghiệp có thể mở rộng nhanh đến đâu. Nếu hệ thống không đủ linh hoạt, mỗi lần mở thêm điểm bán sẽ kéo theo một chuỗi các điều chỉnh phức tạp về hạ tầng, khiến tốc độ tăng trưởng bị chậm lại đáng kể. Ở một góc nhìn khác, F&B cũng là ngành có “ngưỡng chịu lỗi” gần như bằng không. Một sự cố hệ thống trong giờ cao điểm không chỉ ảnh hưởng đến một giao dịch, mà có thể tác động đồng thời đến hàng trăm, hàng nghìn khách hàng. Điều này khiến yêu cầu về độ ổn định và khả năng phục hồi của hệ thống trở nên khắt khe hơn rất nhiều so với nhiều ngành khác. Chính những đặc thù này đã đẩy quá trình chuyển đổi số trong F&B đi nhanh hơn so với nhiều lĩnh vực khác. Tuy nhiên, điều đáng chú ý là chuyển đổi số trong ngành không bắt đầu từ công nghệ, mà bắt đầu từ áp lực vận hành và kỳ vọng của khách hàng. Các doanh nghiệp có thể triển khai ứng dụng khách hàng, xây dựng chương trình loyalty hay đầu tư vào dữ liệu, nhưng nếu nền tảng hạ tầng phía dưới không đủ linh hoạt, mọi nỗ lực phía trên sẽ nhanh chóng chạm trần. Đây là điểm mà nhiều doanh nghiệp nhận ra: chuyển đổi số không chỉ là “thêm một lớp công nghệ”, mà là tái thiết lại nền móng vận hành. Trong bức tranh đó, Cloud dần trở thành lựa chọn mang tính nền tảng. Không chỉ bởi khả năng mở rộng linh hoạt, mà còn vì Cloud cho phép doanh nghiệp chuyển từ tư duy đầu tư cố định sang vận hành linh hoạt, từ phản ứng bị động sang chủ động thích ứng với biến động. Golden Gate Group: Khi chuyển đổi công nghệ trở thành đòn bẩy tăng trưởng Golden Gate Group là một ví dụ điển hình cho cách một doanh nghiệp F&B quy mô lớn tiếp cận bài toán công nghệ. Với hơn 500 nhà hàng thuộc hơn 40 thương hiệu tại 42 tỉnh thành toàn quốc - số lượng được dự kiến sẽ tiếp tục tăng trưởng trong tương lai - đặt áp lực lớn lên đội ngũ công nghệ phải sẵn sàng cho bài toán vận hành liên tục.Trong giai đoạn sử dụng mô hình hạ tầng truyền thống mỗi lần cần tăng tài nguyên cho vận hành, Doanh nghiệp này cần phải có thời gian chuẩn bị và chi phí đáng kể, trong khi khả năng dự phòng và giám sát còn hạn chế. Điều này tạo ra một nghịch lý: doanh nghiệp có thể sẵn sàng về mặt kinh doanh để tăng trưởng, nhưng hệ thống công nghệ lại trở thành điểm nghẽn. [caption id="attachment_71479" align="aligncenter" width="2560"] Anh Đào Văn Hoàn - Head of ITS, Golden Gate Group chia sẻ tại một sự kiện tại Hà Nội.[/caption] Quyết định chuyển đổi lên Cloud không đơn thuần là một thay đổi về hạ tầng, mà là một bước tái cấu trúc toàn diện. Toàn bộ hệ thống được đánh giá lại, thiết kế kiến trúc mới và thực hiện chuyển đổi trong một lộ trình ngắn nhưng kiểm soát chặt chẽ. Việc hoàn tất chuyển đổi hàng chục ứng dụng trong thời gian chỉ khoảng một tháng, với yêu cầu không làm gián đoạn vận hành tại các điểm kinh doanh, cho thấy mức độ quyết liệt cũng như năng lực triển khai của đội ngũ. Điều quan trọng hơn nằm ở những gì diễn ra sau đó. Khi hệ thống có khả năng tự động mở rộng theo nhu cầu, bài toán traffic đột biến không còn là rủi ro lớn. Khi môi trường phát triển và vận hành được chuẩn hóa, tốc độ triển khai sản phẩm được rút ngắn đáng kể. Và khi toàn bộ hệ thống có thể được giám sát theo thời gian thực, việc xử lý sự cố chuyển từ bị động sang chủ động. Nói cách khác, với Golden Gate Group công nghệ không còn là “chi phí cần tối ưu” mà giờ đây trở thành “đòn bẩy giúp tăng tốc” trong chiến lược dài hạn của doanh nghiệp này. Từ hạ tầng đến hệ sinh thái: Bước đi tiếp theo của F&B Điểm đáng chú ý là chuyển đổi công nghệ trong F&B không dừng lại ở việc tối ưu vận hành hiện tại. Khi nền tảng hạ tầng đã đủ linh hoạt, doanh nghiệp có thể bắt đầu xây dựng những lớp giá trị cao hơn, đặc biệt là xoay quanh dữ liệu và trải nghiệm khách hàng. Việc kết nối các hệ thống rời rạc thành một nền tảng dữ liệu thống nhất cho phép doanh nghiệp hiểu khách hàng ở mức sâu hơn - không chỉ là họ mua gì, mà còn là họ có xu hướng quay lại khi nào, phản ứng ra sao với từng loại ưu đãi, hay khả năng chi tiêu trong từng bối cảnh. Đồng thời, Cloud cũng tạo điều kiện để mở rộng các dịch vụ số như ứng dụng khách hàng, chương trình thành viên hay các kênh bán hàng trực tuyến, mà không cần lo ngại về giới hạn hạ tầng. Khi đó, F&B không còn là một chuỗi nhà hàng, mà dần trở thành một hệ sinh thái dịch vụ xoay quanh trải nghiệm ẩm thực. Ngành F&B đang bước vào một giai đoạn mà tăng trưởng không còn phụ thuộc chủ yếu vào số lượng cửa hàng, mà phụ thuộc vào khả năng vận hành ở quy mô lớn với hiệu quả cao. Trong bối cảnh đó, công nghệ - đặc biệt là Cloud và các kiến trúc hiện đại - đóng vai trò như nền móng cho toàn bộ chiến lược phát triển. Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud:  Hotline: 1900 638 399 Email: support@fptcloud.com Support: m.me/fptsmartcloud 

FPT Database Engine chính thức giới thiệu tính năng Point-In-Time Recovery (PITR). Đây là bước tiến quan trọng trong việc nâng cao khả năng dự phòng và hồi phục dữ liệu cho các doanh nghiệp đang vận hành cơ sở dữ liệu trên nền tảng Cloud. Point-In-Time Recovery (PITR) là gì? PITR là tính năng cho phép người dùng khôi phục dữ liệu MySQL hoặc PostgreSQL về một thời điểm cụ thể (Timestamp) trong quá khứ. Thay vì chỉ có thể khôi phục về các bản backup cố định theo ngày, PITR cung cấp sự linh hoạt tối đa để "du hành thời gian" về sát thời điểm xảy ra sự cố. Tính năng này là lá chắn bảo vệ dữ liệu khỏi: Lỗi thao tác người dùng: Xóa nhầm database hoặc table. Sự cố ứng dụng: Dữ liệu bị hỏng hoặc ghi đè do lỗi logic từ phía phần mềm. Rủi ro mất mát dữ liệu: Đảm bảo tính toàn vẹn và tuân thủ các chính sách bảo mật khắt khe Cơ chế hoạt động và Phạm vi hỗ trợ Đặc điểmMySQL PITRPostgreSQL PITRCơ chế chính+ Hệ thống cho phép cấu hình bật tính năng PITR để kích hoạt cơ chế lưu trữ binary log (binlog) + Hệ thống duy trì backup full định kỳ và Binlog liên tục theo lịch đã cấu hình. Binlog được lưu trữ an toàn theo retention policy được định nghĩa cho backup full. + Người dùng chỉ cần chọn thời điểm (timestamp) cần khôi phục trong phạm vi retention. + Hệ thống sẽ tạo một database instance mới được phục hồi đến thời điểm đó (không ghi đè lên instance hiện tại).Khôi phục cơ sở dữ liệu PostgreSQL đến thời điểm chỉ định (timestamp) hoặc LSN cụ thể trong khoảng thời gian lưu giữ WALPhạm vi hỗ trợCloud Database (Single node hoặc HA cluster).Cloud Database (Single node hoặc HA cluster).Thời gian lưu trữMặc định 7 ngày (có thể tùy chỉnh).Mặc định 7 ngày (có thể tùy chỉnh).Phương thức phục hồiKhôi phục về một Instance mới (không ghi đè instance gốc).Khôi phục về một Instance mới (không ghi đè instance gốc). Hướng dẫn sử dụng nhanh trên FPT Cloud Portal Người dùng có thể dễ dàng quản lý PITR thông qua giao diện Portal hoặc API của FPT Database Engine: Kích hoạt PITR: Enable PITR khi enable dịch vụ Backup. Truy cập cluster -> Mở tab Backup & Restore -> Enable PIT Thực hiện khôi phục: Truy cập Portal Cloud Database → Chọn MySQL/PostgreSQL Instance. Mở tab Backup & Restore -> chọn tab Restore. Chọn Recover to point in time Nhập thời điểm cần khôi phục → Xác nhận thao tác. Hệ thống sẽ tạo một instance mới từ dữ liệu khôi phục tại thời điểm bạn chọn. Những lưu ý quan trọng Với MySQLVới PostgreSQLPITR chỉ hoạt động khi:- Binary log đang bật- Instance có ít nhất một phiên bản full backup hợp lệ+ Thời điểm khôi phục phải nằm trong khoảng retention binlog.+ Thời gian khôi phục phụ thuộc dung lượng dữ liệu & tốc độ I/O.+ Trong môi trường HA, PITR được thực hiện từ node primary.+ Chỉ khả dụng cho các instance đã bật tính năng archived WAL logs.+ Thời điểm khôi phục hợp lệ nằm trong thời gian lưu giữ WAL (theo backup retention và thời điểm bật tính năng archived WAL Log).+ Việc khôi phục có thể mất vài phút tùy dung lượng dữ liệu và tốc độ I/O. Với việc bổ sung tính năng Point-In-Time Recovery, FPT Database Engine tiếp tục khẳng định cam kết mang lại giải pháp an toàn, tin cậy và tuân thủ các tiêu chuẩn bảo vệ dữ liệu cao nhất cho khách hàng.

Tại sự kiện Partner Appreciation Day 2026 thường niên của hãng công nghệ Veeam, FPT Smart Cloud được vinh danh đối tác Platinum - cấp độ đối tác cao cấp nhất trong hệ thống phân hạng đối tác của Veeam, đồng thời là đối tác duy nhất tại Việt Nam đạt được cấp độ cao cấp nhất này.  [caption id="attachment_71461" align="aligncenter" width="2560"] Đại diện FPT Smart Cloud nhận chứng nhận từ hãng công nghệ Veeam tại sự kiện.[/caption]   Để đạt được cột mốc này, FPT Smart Cloud đã phải đáp ứng các tiêu chuẩn khắt khe về chứng chỉ kỹ thuật, và đặc biệt là sự hài lòng của khách hàng trong việc triển khai, vận hành các giải pháp Offsite Backup & DRaaS (Disaster Recovery as a Service). Việc trở thành đối tác cấp cao nhất của Veeam là cột mốc quan trọng khẳng định năng lực cung cấp dịch vụ của FPT Cloud tới khách hàng doanh nghiệp tại Việt Nam.  Theo đó, các khách hàng sử dụng dịch vụ trên nền tảng điện toán đám  mây FPT Cloud sẽ nhận được những lợi thế đặc biệt về: (1) Chuyên môn kỹ thuật cao cấp: Khách hàng được tư vấn và hỗ trợ bởi đội ngũ kỹ sư có trình độchuyên môn cao nhất, được đào tạo trực tiếp từ Veeam; (2) Giải pháp tối ưu hóa: Tiếp cận các kiến trúc hệ thống tiên tiến nhất, đảm bảo dữ liệu luôn khả dụng và an toàn trước mọi rủi ro an ninh mạng; (3) Hỗ trợ ưu tiên: Với tưcách là đối tác chiến lược cấp cao, khách hàng sẽ nhận được sự hỗ trợ kỹ thuật ưu tiên ở mức cao nhất từ hãng, giúp giải quyết các vấn đề phát sinh một cách nhanh chóng nhất; (4) Chi phí hiệu quả: Khách hàng được hưởng lợi từcác chính sách giá và chương trình ưu đãi tốt nhất của Veeam thông qua FPT Smart Cloud.  Chị Phương Anh, Nguyễn - Channel Manager, CLV, Veeam chia sẻ: “Với vai trò là đối tác Platinum VCSP, FPT Smart Cloud đại diện cho cấp độ hợp tác cao nhất trong hệ sinh thái Veeam Cloud & Service Provider. Cột mốc này không chỉ phản ánh hiệu quả kinh doanh ấn tượng, mà còn thể hiện năng lực kỹ thuật chuyên sâu, chất lượng dịch vụ vượt trội và cam kết lâu dài trong việc cung cấp các dịch vụ bảo vệ dữ liệu đáng tin cậy, an toàn và có khả năng mở rộng cho khách hàng tại Việt Nam.”  Veeam Software là hãng công nghệ có trụ sở đặt tại Thụy Sĩ, được thành lập từ năm 2006, tập trung vào lĩnh vực sao lưu và phục hồi dữ liệu. Các sản phẩm của Veem được Gartner đánh giá có chất lượng dẫn đầu thị trường trong nhiều năm liền. Veeam có hơn 450.000 khách hàng doanh nghiệp trên toàn thế giới đang sử dụng các sản phẩm Veeam để sao lưu, phục hồi và duy trì tính liên tục cho hệ thống CNTT.  Tìm hiểu thêm thông tin chi tiết về dịch vụ sao lưu dữ liệu của FPT Cloud. Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud:  Hotline: 1900 638 399 Email: support@fptcloud.com Support: m.me/fptsmartcloud