Bạn đã bao giờ phát hiện một lỗi lạ trong ứng dụng trên chiếc điện thoại mới mua và báo cho nhà phát triển, rồi vài ngày sau nhận được phản hồi rằng họ đã nhận hàng trăm báo cáo từ những người gặp cùng vấn đề và bản sửa lỗi cũng đã sớm được phát hành chưa? Ngay cả những vấn đề mà một mình bạn khó đoán được nguyên nhân cũng thường được giải quyết nhanh đến bất ngờ khi nhiều người cùng xem xét. Quan niệm rằng càng có nhiều con mắt cùng quan sát thì lỗi càng dễ lộ diện chính là điều được thể hiện trong “Định luật Linus (Linus's Law)”.
Nói một cách đơn giản, định luật Linus là một quy tắc kinh nghiệm cho rằng “khi có đủ nhiều con mắt quan sát, mọi lỗi đều sẽ lộ ra ở chỗ nông”. Từ lâu, câu nói này đã được trích dẫn như một cách diễn đạt tiêu biểu giải thích sức mạnh của phương thức phát triển mã nguồn mở (Open Source), trong đó mã nguồn được công khai để bất kỳ ai cũng có thể xem xét.
Trong tài liệu này, chúng ta sẽ lần lượt tìm hiểu bối cảnh ra đời và ý nghĩa chính xác của định luật, cơ chế giúp nhiều con mắt phát huy hiệu quả, những trường hợp cho thấy giới hạn của định luật và cách vận dụng trong thực tế.
Nguyên lý và giới hạn của việc bảo vệ phần mềm bằng nhiều con mắt
Định luật Linus là gì?
Định luật này được lập trình viên người Mỹ Eric S. Raymond hệ thống hóa trong bài luận “Nhà thờ và khu chợ (The Cathedral and the Bazaar)”, công bố lần đầu năm 1997 và xuất bản thành sách năm 1999. Tên gọi được lấy từ Linus Torvalds, nhà phát triển người Phần Lan đã tạo ra nhân Linux đầu tiên vào năm 1991. Tại Hàn Quốc, định luật này thường được gọi theo cách phiên âm gần với phát âm tiếng Anh của tên Linus.
Raymond diễn giải định luật này chính xác hơn như sau: “Khi có đủ nhiều người thử nghiệm beta và người cùng phát triển, gần như mọi vấn đề đều được nhận diện nhanh chóng, và cách giải quyết sẽ hiển nhiên đối với một ai đó”.
(1) Mô hình nhà thờ
Đây là phương thức trong đó một nhóm nhỏ chuyên gia làm việc khép kín, thiết kế tỉ mỉ và chỉ công bố sản phẩm khi đã đạt mức độ hoàn thiện cao. Cách tiếp cận này cho rằng lỗi ẩn sâu và chỉ có thể tìm thấy qua quá trình kiểm thử lâu dài.
(2) Mô hình khu chợ
Đây là phương thức công bố sớm, thường xuyên và mở cửa để bất kỳ ai cũng có thể đóng góp ý kiến cùng đề xuất sửa đổi. Quá trình phát triển Linux đã diễn ra theo cách này, và Raymond cho rằng nhờ có nhiều người tham gia, lỗi nhanh chóng lộ diện.
Cơ chế giúp nhiều con mắt tìm ra lỗi
Cốt lõi của định luật Linus nằm ở chỗ những người khác nhau có thể chia nhau đảm nhận việc tìm lỗi và sửa lỗi. Dù người đầu tiên gặp vấn đề không biết nguyên nhân, một người khác nhìn thấy biểu hiện đó có thể nghĩ ngay ra cách giải quyết.
- Môi trường sử dụng đa dạng (Diverse Environments): Mỗi người dùng thiết bị và sử dụng theo cách khác nhau, khiến vấn đề lộ diện trong những tình huống mà nhà phát triển chưa kịp kiểm thử.
- Rà soát đồng nghiệp (Peer Review): Những nhà phát triển khác đọc mã nguồn và chỉ ra các sai sót mà người viết chưa nhận thấy.
- Gỡ lỗi song song (Parallel Debugging): Nhiều người cùng lúc truy tìm nguyên nhân, nhờ đó tìm ra manh mối nhanh hơn so với khi một người làm một mình.
(1) Người báo cáo biểu hiện lỗi
Khi người dùng gặp lỗi ghi lại cụ thể cách tái hiện lỗi, thời gian cần để khoanh vùng nguyên nhân sẽ giảm đáng kể.
(2) Người nhận ra nguyên nhân
Đối với nhà phát triển từng xử lý vấn đề tương tự, ngay cả lỗi có vẻ nằm sâu với người khác cũng có thể là một vấn đề nông, dễ nhận ra. Từ “nông” trong định luật chính là nói đến điều này. Càng có nhiều người tham gia, khả năng gặp được một người như vậy càng lớn.
Những trường hợp cho thấy giới hạn của định luật
[Trường hợp 1] Heartbleed ẩn mình suốt hơn 2 năm
Đoạn mã được đưa vào OpenSSL, phần mềm mã nguồn mở được sử dụng rộng rãi cho liên lạc mã hóa trên Internet, sau khi trải qua rà soát vào cuối năm 2011 có một khiếm khuyết. Khiếm khuyết này lan rộng từ bản phát hành tháng 3 năm 2012, nhưng mãi đến tháng 4 năm 2014 mới được công bố với tên gọi Heartbleed. Khi được công bố, ước tính khoảng 17% máy chủ web sử dụng chứng chỉ bảo mật đáng tin cậy, tương đương khoảng 50 vạn máy chủ, có nguy cơ bị ảnh hưởng. Tháng 9 cùng năm, Shellshock cũng được phát hiện trong Bash, chương trình xử lý lệnh được sử dụng rộng rãi trên Linux và các hệ thống khác; đây là khiếm khuyết đã ẩn mình khoảng 25 năm kể từ năm 1989.
[Trường hợp 2] Phần mềm cốt lõi được giao cho một nhóm nhỏ
Khi Heartbleed bị phát hiện, OpenSSL đang được một nhóm ít ỏi tình nguyện viên quản lý, trong đó chỉ có một nhà phát triển làm việc toàn thời gian. Điều này cho thấy ngay cả khi mã nguồn có thể được bất kỳ ai xem, lỗi vẫn có thể ẩn mình rất lâu nếu không có người thực sự xem xét kỹ lưỡng. Ngay sau sự việc, Linux Foundation đã cùng các doanh nghiệp lớn thành lập một quỹ hỗ trợ các dự án mã nguồn mở cốt lõi.
Cách phát huy định luật Linus trong thực tế
Kỹ sư phần mềm Robert Glass đã phê bình định luật này, viện dẫn nghiên cứu cho thấy số lỗi tìm được không tăng tỷ lệ thuận với số người rà soát, và số người rà soát hữu ích chỉ vào khoảng hai hoặc ba đến bốn người. Ngược lại, cũng có phân tích cho thấy các dự án mã nguồn mở càng phổ biến thì tỷ lệ sửa lỗi càng cao, nên cuộc tranh luận vẫn tiếp diễn đến nay. Sau cùng, điều quan trọng hơn số lượng con mắt là có bao nhiêu con mắt thực sự xem xét mã nguồn.
(1) Đưa việc rà soát mã nguồn thành quy trình
Nếu mọi thay đổi đều được ít nhất một đồng nghiệp đọc và phê duyệt trước khi áp dụng, bạn có thể thu được lợi ích từ nhiều con mắt, bất kể mã nguồn có được công khai hay không.
(2) Tập trung nhân lực và nguồn lực cho mã nguồn cốt lõi
Thành phần cốt lõi càng được nhiều dịch vụ dựa vào thì càng cần có người quản lý chuyên trách và được kiểm toán bảo mật định kỳ.
(3) Giúp việc báo lỗi trở nên dễ dàng
Khi người dùng có thể dễ dàng thông báo vấn đề và theo dõi tiến độ, những con mắt từ bên ngoài sẽ tự nhiên tập hợp lại.
(4) Bù đắp thiếu sót bằng công cụ tự động
Đối với lỗi giá trị biên mà con người dễ bỏ sót, việc kiểm tra lặp lại bằng công cụ kiểm thử tự động là cách làm hiệu quả.
Định luật Linus thể hiện trong một câu niềm tin rằng cộng tác mở có thể nâng cao chất lượng phần mềm. Tuy nhiên, như Heartbleed đã nhắc nhở, chỉ công khai mã nguồn là chưa đủ; định luật chỉ phát huy đầy đủ sức mạnh khi có người thực sự đọc và kiểm thử mã nguồn đó.
Tập hợp những con mắt thực sự xem xét mã nguồn đã được công khai chính là bước đầu tiên để có phần mềm an toàn.
