Khám phá những ẩn số chưa biết

Meta có một hệ sinh thái sản phẩm được hàng tỷ người dùng sử dụng mỗi ngày, cho dù là để kết nối xã hội hay tương tác với doanh nghiệp. Hàng tỷ người dùng này cũng yêu cầu chúng tôi phải liên tục - với tốc độ nhanh - cung cấp chức năng mới và điểm cải tiến trong những sản phẩm đó. Do cộng đồng người dùng lớn, chúng tôi phải thực hiện hàng nghìn thay đổi mã mỗi ngày để đáp ứng những kỳ vọng nêu trên.

Khi liên tục phát hành lượng lớn điểm cải tiến sản phẩm như vậy, tình trạng ứng dụng có thể sẽ gặp lỗi hồi quy, do đó làm giảm trải nghiệm người dùng. Tại Meta, chúng tôi có một lớp công cụ ngăn chặn tinh vi để tránh phát hành những thay đổi sản phẩm bị lỗi. Những công cụ ngăn chặn này sẽ giám sát các tín hiệu sản phẩm khác nhau và phát hiện lỗi hồi quy trước khi phát hành ứng dụng. Các tín hiệu nêu trên rơi vào 3 lĩnh vực, đó là hiệu suất, độ tin cậy (chức năng và hệ thống) và hiệu quả. Chúng được gọi chung là "PRE" của sản phẩm. Quá trình ngăn chặn bắt đầu từ những dấu vết quan sát và phân tích khác nhau thu thập được khi nhà phát triển viết mã. Ngoài ra, các công cụ quan sát và giám sát sẽ thu thập dữ liệu từ hoạt động sử dụng sản phẩm nội bộ trong những môi trường tiền sản xuất. Cả công cụ đảm bảo chất lượng thủ công và tự động đều kiểm tra sản phẩm trong các môi trường tiền sản xuất đó.

Mặc dù những cơ chế nêu trên tồn tại để đánh giá chất lượng của các thay đổi về mã trước khi phát hành chính thức nhằm tránh tác động đến người dùng, nhưng có thể xảy ra trường hợp các thay đổi tác động đến người dùng được phát hành chính thức, do đó cần tạo lại và phát hành chính thức các thay đổi đó một lần nữa. Để giảm thiểu khả năng xảy ra vấn đề ảnh hưởng đến lượng lớn người dùng, chúng tôi sử dụng nhiều cơ chế để từng bước phát hành công khai các thay đổi.

Khi có sự khác biệt so với chức năng mà người dùng kỳ vọng, chúng tôi sẽ xác định đó là lỗi hồi quy. Chúng tôi sử dụng tín hiệu dạng từ ngữ để chỉ ra rằng người dùng đang cho chúng tôi biết chức năng nào đó không đáp ứng kỳ vọng của họ. Chúng tôi thu thập một cách có hệ thống các tín hiệu lỗi hồi quy ngay khi có thể qua thông tin chi tiết về dữ liệu và mã được đo lường, sau đó nỗ lực giảm bớt tác động đến người dùng bằng cách triển khai bản sửa lỗi. Trong những trường hợp mà chúng tôi không nhận được tín hiệu mạnh từ công cụ của mình, chúng tôi sử dụng báo cáo của người dùng làm tín hiệu cho thấy đã xảy ra lỗi hồi quy. Người dùng có thể báo cáo thông qua nhiều cơ chế, chẳng hạn như lắc điện thoại để báo cáo sự cố khi đang ở trong ứng dụng vào thời điểm xảy ra sự cố.

Nhằm đảm bảo rằng chúng tôi đáp ứng nhu cầu của khách hàng và thực hiện điều đó nhanh nhất có thể - đôi khi trong cùng một ngày, Meta đã đầu tư rất nhiều vào một số chương trình và hệ thống nâng cao độ tin cậy để tăng khả năng phản hồi trên quy mô lớn.

Tín hiệu có thể đến từ người dùng công khai (cá nhân, công ty, nhóm, v.v.) hoặc từ người dùng nội bộ. Chúng tôi xem xét kỹ lưỡng các tín hiệu từ người dùng nội bộ để ngăn chặn những thay đổi không mong muốn xuất hiện trong quá trình phát hành chính thức. Lưu ý rằng tín hiệu là dữ liệu tổng hợp; ví dụ: tín hiệu bao gồm số lượng lỗi trên một triệu người dùng. Tín hiệu cũng có thể đến từ các công cụ và kịch bản thử nghiệm tự động, công cụ phát triển (chúng tôi cảnh báo nhà phát triển về những thay đổi có thể gây ra vấn đề liên quan đến thời gian chạy), nhật ký hệ thống và nhiều nguồn khác. Chúng tôi cũng có các công cụ khai thác những tín hiệu này để nhanh chóng xác định nguyên nhân và cách khắc phục thích hợp.

Sau khi xác định được lỗi hồi quy, chúng tôi sẽ nhanh chóng tìm những kỹ sư phù hợp để áp dụng và phát hành bản sửa lỗi. Tùy thuộc vào độ phức tạp của lỗi hồi quy, chúng tôi sử dụng một số phương pháp để xác định kỹ sư phù hợp, bao gồm cả việc tận dụng sự nhạy bén của Meta về công nghệ máy học. Do cách thức hoạt động của công nghệ máy học, đây sẽ là một quá trình liên tục khi chúng tôi phát hành các tính năng mới và đào tạo lại mô hình để bắt kịp sự thay đổi không ngừng.

Và rồi hồi kết cũng đến: Chúng tôi tiến triển từ việc phát hiện lỗi hồi quy, đến giảm thiểu, ngăn chặn và kiềm chế lỗi này một cách bền vững. Trong quá trình đó, chúng tôi tăng tối đa khả năng phản hồi, lợi nhuận trên vốn đầu tư và hiệu quả.

Trong phần tiếp theo, chúng ta sẽ thảo luận chi tiết hơn về cách xác định chắc chắn rằng đã xảy ra lỗi hồi quy cũng như cách ứng phó khi phát hiện lỗi đó.

Chuyển từ ẩn số sang lỗi đã biết và định lượng lỗi

Khi nói về những ẩn số, chúng tôi đang đề cập đến lỗi mà người dùng hoặc hệ thống gặp phải. Trước tiên, chúng tôi có thể tìm hiểu về lỗi có khả năng xảy ra từ một số nguồn khác nhau.

• Thử nghiệm tổng hợp về chức năng hoạt động bình thường của ứng dụng và sản phẩm cụ thể trong ứng dụng đó.
• Người dùng nội bộ đang thử nghiệm để tìm lỗi, có thể bao gồm đội ngũ thử nghiệm chuyên trách của chúng tôi hoặc cộng đồng người dùng rộng hơn trong Meta.
• Người dùng bên ngoài đang gặp sự cố khi sử dụng hộp thoại báo cáo sự cố trong ứng dụng của chúng tôi.

Những lỗi này là ẩn số cho đến khi thực sự được gắn cờ là sự cố mà người dùng gặp phải. Khi số lượng báo cáo lỗi như vậy đạt đến ngưỡng nhất định, chúng tôi xem đó là báo cáo lỗi thật, biểu thị một sự kiện hồi quy: thay đổi về mã gây ra lỗi mới và chúng tôi phải nhanh chóng tiến hành biện pháp giảm thiểu. Có 2 loại báo cáo chính:

• "Ẩn số đã biết" - khi mã được đo lường phát hiện và báo cáo lỗi hồi quy; đồng thời chúng tôi có một số công cụ giúp tạo ra tín hiệu này
• "Ẩn số chưa biết" - khi chúng tôi không phát hiện được lỗi hồi quy trong nội bộ và nhờ người dùng báo cáo lỗi hồi quy trong thực tế

Ngoài ra, lỗi hồi quy sẽ rơi vào một số hạng mục, chẳng hạn như liệu lỗi hồi quy có biểu thị lỗi mã, nội dung nào đó giống spam hơn hoặc một số trường hợp vi phạm chính sách nội dung khác hay không. Chúng tôi chú trọng vào lĩnh vực đầu tiên vì muốn giải quyết các vấn đề về trải nghiệm người dùng liên quan đến mã. Vậy giải quyết bằng cách nào khi người dùng báo cáo hàng nghìn vấn đề?

Tạo ra tín hiệu và thông tin chi tiết

Nhằm quản lý khối lượng lớn báo cáo, chúng tôi tạo ra các tín hiệu cụ thể để gắn cờ vấn đề. Loại tín hiệu đầu tiên là loại tín hiệu - với các ngưỡng được điều chỉnh phù hợp - cho chúng tôi biết rằng thực sự đã xảy ra sự cố hoặc lỗi hồi quy. Lưu ý rằng nhiều sự kiện có thể đã xảy ra tùy thuộc vào loại lỗi hồi quy. Ví dụ: một lỗi hồi quy có thể ảnh hưởng đến nhiều sản phẩm do có chung cơ sở mã. Chúng tôi tìm kiếm những điểm tương đồng như vậy và giải quyết như một sự cố đơn lẻ để điều chỉnh nguồn lực sao cho tối ưu. Biểu đồ bên dưới là một ví dụ minh họa cách chúng tôi có thể nhìn thấy sự khác biệt so với đường xu hướng biểu thị lỗi hồi quy.

Sau đó, chúng tôi thu thập các tín hiệu khác. Một số tín hiệu trong đó cho biết loại lỗi hồi quy mà chúng tôi có thể đang gặp phải. Những tín hiệu này cung cấp thông tin chi tiết về các triệu chứng liên quan đến lỗi hồi quy. Các thuật toán máy học được điều chỉnh cho sản phẩm cụ thể của Meta tạo ra những tín hiệu trên. Thuật toán sẽ phân tích báo cáo của người dùng để xác định nguyên nhân gây ra lỗi hồi quy, từ đó xác định đội ngũ kỹ thuật có thể giải quyết hiệu quả nhất bằng cách triển khai bản sửa lỗi mã hoặc biện pháp khác.

Nhiều tín hiệu khác cũng được tạo ra dựa trên dữ liệu nhật ký thu thập được. Những nhật ký chẩn đoán này có thể là nhật ký phía máy khách hoặc phía máy chủ được thu thập - với sự chấp thuận của người dùng - để giúp xác định nguyên nhân. Các ứng dụng lồng ghép quy trình chấp thuận thích hợp để xác định xem có thể thu thập loại dữ liệu này dựa trên quyền của người dùng hay không. Chúng tôi cũng tính đến tuổi thọ của dữ liệu này để tuân thủ các quy định hiện hành.

Nhờ kết hợp các tín hiệu, chúng tôi có thể tập trung vào lỗi hồi quy và chỉ định lỗi đó cho đội ngũ sản phẩm phù hợp để nhanh chóng giảm thiểu vấn đề, đồng thời khôi phục trải nghiệm của người dùng như những gì họ kỳ vọng.

Chúng tôi cũng có được thông tin chi tiết từ những kết quả ở dạng tổng hợp. Chúng tôi xem xét dữ liệu để tìm ra nguyên nhân gốc rễ chung và xác định xem có cần thay đổi để ngăn chặn lỗi hồi quy tái diễn hay không. Cách làm này là khía cạnh quan trọng để có một phương pháp hữu hiệu giúp giải quyết các vấn đề về trải nghiệm người dùng vì chúng tôi có thể giảm thiểu giao diện hồi quy theo thời gian.

Ứng dụng di động của chúng tôi không chỉ có đường dẫn điều hướng để người dùng báo cáo sự cố, mà còn cho phép người dùng chỉ ra sự cố bằng cách lắc thiết bị. Như thế, chúng tôi có thể thu thập được dữ liệu đo từ xa theo ngữ cảnh. Dữ liệu đo từ xa đó càng phong phú hơn thông qua các tín hiệu Hộp đen đến từ ứng dụng. Hộp đen giống như máy ghi dữ liệu chuyến bay, tự động ghi lại nhật ký nhất định (theo sự chấp thuận của người dùng) về chuyện gì xảy ra với ứng dụng tại thời điểm lỗi được báo cáo, qua đó chúng tôi có thể chẩn đoán sự cố hiệu quả hơn.

Toàn bộ dữ liệu đo từ xa nêu trên được ghép vào một tập hợp chế độ xem dòng thời gian để hỗ trợ đội ngũ kỹ thuật xác định nguyên nhân gây ra vấn đề. Do tần suất chúng tôi phát hành ứng dụng diễn ra nhanh chóng, cũng như các thay đổi về thành phần ứng dụng phía máy chủ, chúng tôi khó có thể xác định chính xác vấn đề nếu không có tính năng này. Khi có dữ liệu đo từ xa này theo thời gian, chúng tôi có thể phát hiện quy luật về lỗi hồi quy để ngăn chặn lỗi này xảy ra trong tương lai.

Mở rộng quy mô sang giao diện sản phẩm nhỏ hơn

Sau khi cải thiện khả năng tạo ra các tín hiệu có độ chính xác cao hơn, chúng tôi có thể tấn công nhiều hơn vào giao diện hồi quy - phần mà trước đây không phát hiện được. Giao diện biểu thị dịch vụ cụ thể trong một sản phẩm, chẳng hạn như Bảng tin hoặc Reels. Đây là một thách thức vì sản phẩm không chỉ có nhiều tính năng chi tiết, mà còn thường xuyên ra mắt tính năng mới. Vì vậy, giao diện hồi quy không chỉ lớn mà còn tăng theo thời gian. Do đó, chúng tôi phải liên tục điều chỉnh chiến lược phòng thủ và tấn công.

Nếu muốn mở rộng quy mô thì cần phải đáp ứng một số điều kiện:

1. Chúng tôi phải có phạm vi sử dụng chính xác và phân loại đúng các giao diện sản phẩm hiện có
2. Chúng tôi phải giảm giao diện hồi quy cho các sản phẩm hiện có (đọc phần ngăn chặn)
3. Chúng tôi phải mở rộng phạm vi tiếp cận của thuật toán sang những giao diện sản phẩm mới

Nếu không đáp ứng các điều kiện trên, chúng tôi có nguy cơ gặp phải một hệ thống cồng kềnh không thể quản lý do quy mô, độ phức tạp và tính không chính xác. Vì vậy, chúng tôi nỗ lực duy trì sự cân bằng đó, đồng thời điều hành hiệu quả các hoạt động hàng ngày.

Phát triển không còn lỗi

Khi liên tục giảm giao diện hồi quy (mà không mất cảnh giác), chúng tôi tăng cường tập trung vào các lĩnh vực quan trọng khác: ngăn chặn và khả năng sử dụng.

Việc ngăn chặn liên quan đến:

1. Làm cách nào để chúng ta rút ra bài học từ các lỗi hồi quy trước?
2. Chúng ta triển khai các biện pháp bảo vệ nào để những lỗi hồi quy này không tái diễn?
3. Làm cách nào để chúng ta đảm bảo theo thời gian rằng giao diện hồi quy tiếp tục giảm?

Như đã thảo luận trước đó, chúng tôi tổng hợp dữ liệu từ các lỗi hồi quy trước để rút ra bài học. Những bài học đó có thể chuyển thành:

1. Đặt các điểm đánh dấu trong mã để cảnh báo cho chúng tôi sau này khi vẫn còn ở trong môi trường tiền sản xuất, nhờ đó chúng tôi có thể ngăn chặn thay đổi không mong muốn khi phát hành chính thức
2. Tăng phạm vi thử nghiệm ở các cấp độ khác nhau để phát hiện những lỗi hồi quy như vậy
3. Tự thay đổi sản phẩm để giải quyết những vấn đề này

Việc ngăn chặn giúp chúng tôi liên tục dịch chuyển những lỗi hồi quy còn lại trong vòng đời phát triển, do đó tiếp tục giảm chi phí. Chúng tôi thực hiện việc này bằng cách lấy các tín hiệu phong phú thích hợp ở giai đoạn đầu của quá trình phát triển, bắt đầu bằng chu kỳ viết mã và phát hành tiền sản xuất. Cách này không chỉ cải thiện trải nghiệm người dùng mà còn cắt giảm chi phí phát triển, đồng thời giúp chúng tôi chuyển nguồn lực sang phát triển sản phẩm mới.

Nhờ cải thiện khả năng xử lý lỗi hồi quy hiệu quả hơn, chúng tôi có thể tập trung hơn vào các vấn đề liên quan đến khả năng sử dụng hoặc sự nhầm lẫn của người dùng. Đây là những mối quan tâm có giá trị cao hơn vì chú trọng vào việc cải tiến sản phẩm chứ không phải khắc phục. Theo thời gian, tỷ lệ vấn đề về khả năng sử dụng đối với lỗi hồi quy sẽ tăng lên, còn tổng số vấn đề về khả năng sử dụng cũng như lỗi hồi quy sẽ giảm xuống.

Cuối cùng, trải nghiệm người dùng sẽ liên tục được cải thiện theo cả khía cạnh chức năng lẫn khả năng sử dụng.

Bài viết này được hợp tác soạn thảo với Bijan Marjan - Giám đốc Chương trình Kỹ thuật tại Meta.