Tất cả chúng ta đều biết bài tập này, phải không? Sau khi chúng tôi hoàn thành việc thay đổi mã và [hy vọng] thử nghiệm nó trên máy cục bộ của mình, chúng tôi sẽ đẩy thay đổi đó sang giai đoạn tiếp theo trong chu trình. Thử nghiệm cục bộ rất thiên vị và lý tưởng nhất là chúng tôi muốn xác thực thay đổi trong một môi trường ổn định hơn (và cũng không chỉ tuân theo quan điểm của kỹ sư đã thực hiện thay đổi). Ở đây, một bước tiếp theo có vẻ rất tự nhiên: Đẩy các thay đổi sang môi trường chạy thử đáng tin cậy và nhờ các đối tác (QA, PM, các kỹ sư khác) trợ giúp xác thực trước khi chuyển các thay đổi. Tiếp theo là sửa lỗi và xác thực lại cho đến khi chúng tôi tin rằng nó đủ tốt để đưa vào sản xuất. Tuyệt vời! Tuy nhiên, trong hầu hết các bối cảnh, điều này đơn giản là không xảy ra. Có thể do nhiều lý do khác nhau, nhưng bất kể lý do là gì, hậu quả là chúng ta thường phải thúc đẩy các thay đổi đối với máy chủ sản xuất trước khi chúng được kiểm tra hoặc xác nhận đủ tốt. Vấn đề là… Nếu có thứ gì đó bị hỏng thì sao? Trên thực tế, làm thế nào để phát hiện vấn đề sớm hơn? Tin tốt: Bạn có thể áp dụng một số công cụ và phương pháp thực hành để giúp việc kiểm tra và xác nhận trong sản xuất không chỉ là phương pháp an toàn cho bạn và công ty của bạn mà thậm chí có thể là một ý tưởng hay. Đường cơ sở: Số liệu Trước khi chuyển sang thử nghiệm trong sản xuất, chúng ta phải nói về các số liệu: Chúng ta cần chúng để xác thực rằng thay đổi mà chúng ta đang vận chuyển mang lại hiệu quả mong muốn, không gây ra tác dụng phụ không mong muốn, sản phẩm vẫn ổn định, v.v. -các số liệu đã được thiết lập, về cơ bản chúng tôi không biết gì khi triển khai các thay đổi. Chúng ta sẽ đề cập đến các số liệu trong nhiều chủ đề trong bài viết, vì vậy hãy cùng xem xét hai loại số liệu khác nhau mà chúng ta nên lưu ý. Số liệu kinh doanh Các số liệu liên quan đến kinh doanh như KPI, mục tiêu và hành vi của người dùng phải được theo dõi sau khi thực hiện các thay đổi để đánh giá tác động. Trước khi có bất kỳ thay đổi nào, hãy xác định các số liệu dự kiến sẽ bị ảnh hưởng. Điều quan trọng không kém là các số liệu về lan can, các chỉ số về những gì không nên thay đổi. Những thay đổi không được dự đoán trước trong các lan can này có thể báo hiệu các vấn đề với thay đổi mới và cần phải xem xét lại. Số liệu kỹ thuật Khi các số liệu kinh doanh được xác định, điều quan trọng là phải hiểu các số liệu kỹ thuật. Đây là những điều cơ bản để đảm bảo hệ thống luôn hoạt động tốt khi có những thay đổi được đưa ra theo thời gian. Ở đây chúng ta đang nói về độ ổn định của hệ thống, tỷ lệ lỗi, âm lượng, hạn chế về công suất máy, v.v. Các số liệu kỹ thuật tốt cũng hữu ích trong việc giải thích các vấn đề được quan sát thấy trong các số liệu kinh doanh hoặc nhanh chóng tìm ra nguyên nhân gốc rễ của sự hồi quy. Ví dụ: giả sử chúng tôi nhận thấy người dùng ít tương tác hơn với một tính năng cụ thể sau khi giới thiệu phiên bản cuối cùng. Việc tăng thời gian chờ yêu cầu hoặc tỷ lệ lỗi có thể nhanh chóng cho thấy dịch vụ/điểm cuối nào đang gây ra sự cố. Giám sát Chúng tôi có các số liệu kinh doanh và kỹ thuật được xác định rõ ràng, tốt! Bây giờ chúng ta phải theo dõi họ. Có nhiều cách để làm điều đó, nhưng bước đầu tiên phổ biến là xây dựng trang tổng quan theo dõi các số liệu theo thời gian, giúp dễ dàng phát hiện những thay đổi bất thường. Thậm chí còn tốt hơn nếu bảng điều khiển cho phép lọc nhanh dữ liệu dựa trên các phân khúc cụ thể có thể đặc biệt phù hợp với doanh nghiệp. Tích cực giám sát bảng thông tin là một cách hay để nhanh chóng hình dung được tác động của một thay đổi mới trong hệ thống. Một số công ty coi việc giám sát tích cực quan trọng đến mức họ thậm chí còn bố trí các ca giám sát 24/7 để phát hiện và giải quyết vấn đề càng sớm càng tốt. Một cách tốt khác để theo dõi số liệu là thông qua việc phát hiện và cảnh báo tự động. Đối với các số liệu chính, cảnh báo có thể cung cấp thông báo theo thời gian thực khi có điều gì đó không ổn. Giả sử chúng tôi bắt đầu triển khai một tính năng và vài phút sau khi quá trình bắt đầu, chúng tôi nhận được cảnh báo cho biết tỷ lệ lỗi đang tăng lên trên một ngưỡng cụ thể. Thông báo sớm này có thể ngăn chúng tôi truyền bá sự thay đổi hơn nữa trong quá trình sản xuất và cứu chúng tôi khỏi rất nhiều vấn đề! Cuối cùng, điều quan trọng là phải lưu ý đến lượng thông tin chúng ta cần và trong hoàn cảnh nào. Mặc dù bảng thông tin rất hữu ích trong việc cung cấp cái nhìn trực quan về hiệu suất của sản phẩm và hệ thống, nhưng việc thêm 1.000 biểu đồ khác nhau sẽ mang lại nhiều nhầm lẫn hơn là làm rõ ràng. Tương tự, nếu chúng tôi nhận được 1.000 cảnh báo mỗi ngày thì chúng tôi không thể điều tra và xử lý chúng và cuối cùng chúng sẽ bị bỏ qua. Hạ cánh an toàn hơn Số liệu được xác định, giám sát tại chỗ, thật tuyệt! Bây giờ chúng ta hãy xem xét một số công cụ và chiến lược giúp chúng ta tránh được sự cố, phát hiện sự cố sớm hơn và giảm thiểu tác động trong sản xuất. Tùy thuộc vào cách thiết lập môi trường sản xuất, một số trong số này sẽ khó triển khai hơn những môi trường khác và thậm chí có thể không có nhiều ý nghĩa khi kết hợp lại. Tuy nhiên, mỗi hạng mục ở đây có thể giúp chúng ta tiến gần hơn đến môi trường sản xuất an toàn và ổn định. Kiểm tra tự động Các thử nghiệm tự động, thường bị loại bỏ khi các dự án không đi đúng hướng, có thể đẩy nhanh quá trình phát triển và thực hiện các thay đổi trong quá trình sản xuất an toàn và nhanh chóng hơn. Các vấn đề được phát hiện càng sớm thì chúng có thể được khắc phục càng nhanh, do đó làm giảm tổng thời gian dành cho quy trình. Quá trình hoàn nguyên các thay đổi, sửa chữa và đẩy chúng trở lại thường rất căng thẳng và có thể lấy đi thời gian quý báu. Nhắm tới phạm vi kiểm thử 100% với các bài kiểm thử đơn vị, tích hợp và từ đầu đến cuối có thể là lý tưởng cho hầu hết các dự án. Thay vào đó, hãy ưu tiên các bài kiểm tra dựa trên nỗ lực so với lợi ích. Các số liệu có thể hướng dẫn điều này: việc bao gồm các tính năng kinh doanh cốt lõi có thể quan trọng hơn các tính năng thích hợp ít tác động hơn, phải không? Bắt đầu với các tính năng cốt lõi, mở rộng khi hệ thống phát triển. Quá trình xuất bản sang sản xuất phải bao gồm việc chạy bộ thử nghiệm trước khi triển khai vào sản xuất. Kiểm tra thất bại sẽ tạm dừng xuất bản, ngăn chặn các vấn đề về sản xuất. Tốt hơn là nên trì hoãn việc phát hành một tính năng hơn là phát hiện ra nó hoàn toàn gặp trục trặc vào ngày hôm sau. Thức ăn cho chó Dogfooding là quá trình phát hành một tính năng để thử nghiệm nội bộ trước khi đến tay người dùng cuối cùng. Trong quá trình dogfood, tính năng này được cung cấp trong phiên bản chính thức nhưng chỉ dành cho người dùng nội bộ (nhân viên, thành viên nhóm, v.v.). Bằng cách này, chúng tôi có thể kiểm tra và xác thực xem tính năng mới có hoạt động như mong đợi hay không bằng cách sử dụng dữ liệu sản xuất thực mà không ảnh hưởng đến người dùng bên ngoài. Có nhiều chiến lược khác nhau cho việc dogfood. Để có cái nhìn tổng quan đơn giản hóa, chúng ta có thể nhóm chúng thành hai nhóm lớn hơn: : Ví dụ: điều này phổ biến trên các ứng dụng iOS/Android, nơi chúng tôi có các công cụ tích hợp để phát hành phiên bản ứng dụng mới cho những người dùng cụ thể và sau đó cung cấp phiên bản tương tự này cho công chúng tại các cửa hàng. Dogfood đầy đủ đồ tạo tác : Đôi khi, không thể (hoặc thậm chí không muốn) dogfood toàn bộ vật phẩm nhưng chúng tôi vẫn có thể cho phép dogfood dựa trên thông tin người dùng cụ thể. Ví dụ: giả sử chúng ta có thể xác định nhân viên bằng cách duyệt qua một số dữ liệu. Sau đó, ứng dụng có thể được cấu hình để bật/tắt một tính năng cụ thể bằng cách kiểm tra dữ liệu này và phân nhánh người dùng theo hành vi mong muốn. Khi đó, ứng dụng sẽ chứa cả hai tính năng nhưng chỉ một số người dùng sẽ bị ảnh hưởng bởi thay đổi mới. Chúng ta sẽ quay lại một số khái niệm này trong các chủ đề tiếp theo. Cho chó ăn có chọn lọc Phát hành Canary Bản phát hành Canary là một quy trình phát hành trong đó thay vì triển khai các thay đổi trong quá trình sản xuất cho tất cả các máy chủ cùng một lúc, thay đổi sẽ được cung cấp cho một tập hợp con nhỏ trong số đó và được theo dõi trong một thời gian. Chỉ sau khi xác nhận rằng thay đổi là ổn định, nó mới được đẩy sang môi trường sản xuất. Đây là một trong những công cụ mạnh mẽ nhất để thử nghiệm các tính năng mới và những thay đổi có tính rủi ro, do đó làm giảm khả năng xảy ra sự cố trong quá trình sản xuất. Bằng cách thử nghiệm thay đổi trên một nhóm người dùng, chúng tôi có thể dừng/hoàn nguyên quá trình triển khai nếu phát hiện bất kỳ vấn đề nào, tránh ảnh hưởng đến hầu hết người dùng. Triển khai xanh xanh Triển khai Blue Green, một phương pháp thực hành DevOps, nhằm mục đích ngăn chặn thời gian ngừng hoạt động bằng cách sử dụng hai cụm máy chủ (Xanh lam và Xanh lục) và chuyển đổi lưu lượng sản xuất giữa chúng. Trong quá trình triển khai tính năng, các thay đổi sẽ được xuất bản cho một bộ (Xanh lục) trong khi vẫn giữ nguyên bộ kia (Xanh lam). Nếu có vấn đề phát sinh, lưu lượng truy cập có thể nhanh chóng được hoàn nguyên về máy chủ Blue vì chúng vẫn chạy với phiên bản trước đó. Triển khai Blue Green thường tương phản với Bản phát hành Canary mà chúng ta đã thảo luận trước đó. Chúng tôi sẽ không đi sâu vào chi tiết của cuộc thảo luận này, nhưng điều quan trọng là phải đề cập đến vấn đề này để giúp chúng tôi quyết định công cụ nào phù hợp hơn cho công việc của mình. Kill Switch và chuyển đổi tính năng Kill switch không bắt nguồn từ bối cảnh công nghệ phần mềm và cách tốt nhất để hiểu cách sử dụng chúng là nhìn lại mục đích và thiết kế ban đầu. Trong máy móc được sử dụng trong công nghiệp, công tắc tắt là cơ chế an toàn giúp tắt chúng nhanh nhất có thể thông qua một tương tác rất đơn giản (thường là một nút đơn giản hoặc công tắc bật/tắt). Chúng tồn tại cho các tình huống khẩn cấp, để ngăn chặn một sự cố (chẳng hạn như trục trặc máy móc) gây ra một sự cố thậm chí còn tồi tệ hơn (thương tích hoặc tử vong). Trong công nghệ phần mềm, kill switch phục vụ một mục đích tương tự: Chúng tôi chấp nhận mất (hoặc tắt) một tính năng cụ thể nhằm cố gắng duy trì hoạt động của hệ thống. Việc triển khai ở cấp độ cao là kiểm tra điều kiện (xem đoạn mã bên dưới), thường được thêm vào điểm bắt đầu của một thay đổi hoặc tính năng cụ thể. if (feature_is_enabled('feature_x')) {xNewBehaviour();} else {xOldBehaviour();} Ví dụ: giả sử chúng tôi đang chuyển quá trình di chuyển sang API mới của bên thứ ba. Mọi thứ đều ổn trong các thử nghiệm, ổn định trong bản phát hành canary và sau đó thay đổi được triển khai 100% vào sản xuất. Sau một thời gian, API mới bắt đầu gặp khó khăn về số lượng và các yêu cầu bắt đầu không thành công (bạn có nhớ các chỉ số kỹ thuật không?). Vì chúng tôi có tính năng ngắt kết nối nên các yêu cầu API có thể được hoàn nguyên ngay lập tức về API cũ và chúng tôi không cần phải hoàn nguyên về phiên bản trước đó hoặc nhanh chóng gửi bản sửa lỗi nóng. Về mặt kỹ thuật, kill switch thực sự là một trường hợp sử dụng cụ thể của các nút bật tắt tính năng (còn gọi là cờ tính năng). Khi chúng ta đang thảo luận về chủ đề này, cần đề cập đến một lợi ích tuyệt vời khác của việc chuyển đổi tính năng: Cho phép phát triển dựa trên đường trục. Nhờ các nút chuyển đổi tính năng, mã mới có thể được đưa vào sản xuất một cách an toàn, ngay cả khi mã đó chưa hoàn thiện hoặc chưa được thử nghiệm. Giữ hành vi cũ có thể truy cập được Đoạn mã được minh họa ở trên có lẽ khiến một số người trong chúng ta băn khoăn liệu đó có thực sự là một mẫu tốt hay không, với cả hành vi cũ và mới tồn tại trong ứng dụng cùng một lúc. Tôi đồng ý rằng đây có thể không phải là trạng thái kết thúc mà chúng tôi mong muốn cho cơ sở mã của mình, nếu không, mọi đoạn mã sẽ bị bao quanh bởi các mệnh đề if/else, khiến mã không thể đọc được ngay lập tức. Tuy nhiên, không phải lúc nào chúng ta cũng nên vội vàng xóa bỏ hành vi cũ. Có, việc dọn sạch mã ngay khi nó ngừng sử dụng là điều rất hấp dẫn và tránh các khoản nợ kỹ thuật. Nhưng bạn cũng có thể để nó ở đó một thời gian dưới sự chuyển đổi tính năng. Đôi khi, có thể mất một thời gian cho đến khi tính năng mới ổn định và việc có tùy chọn dự phòng là một cơ chế an toàn trong trường hợp chúng ta cần quay lại tính năng đó, dù chỉ trong một thời gian ngắn. Vòng đời của mỗi bản phát hành là khác nhau và bạn nên theo dõi thời điểm thích hợp để loại bỏ mã cũ. Việc giữ mã sạch sẽ và giảm chi phí bảo trì sẽ tránh được tình huống ngược lại, trong đó, mặc dù chúng tôi đã tắt tính năng này trong mã, nhưng tính năng này có thể đã bị hỏng trong khoảng thời gian kể từ khi nó bị tắt. Kiểm tra bóng Một trong những kỹ thuật yêu thích của tôi để thực hiện các thay đổi an toàn hơn được gọi là thử nghiệm bóng hoặc chế độ bóng. Nó bao gồm việc thực thi cả hành vi cũ và mới để so sánh kết quả nhưng vô hiệu hóa một số tác dụng phụ của hành vi mới nếu có. Chúng ta hãy xem ví dụ đơn giản này: int sum(int a, int b) {int currentResult = currentMathLib.sum(a, b);int newResult = newMathLib.sum(a, b);logDivergences(a, b, currentResult, newResult);return currentResult;}void logSumDivergences(int a, int b, int currentResult, int newResult) {if (currentResult != newResult) {logger.warn( 'Divergence detected when executing {0} + {1}: {2} != {3}',a, b, currentResult, newResult);}} Mặc dù cả hai phép tính tổng đều được thực hiện, nhưng phép toán mới chỉ được sử dụng để so sánh và ghi lại sự phân kỳ. Kỹ thuật này đặc biệt hữu ích để theo dõi những thay đổi phức tạp của hệ thống và chúng tôi mong đợi sự tương đương giữa hành vi cũ và mới. Một trường hợp sử dụng tuyệt vời khác là khi chúng tôi phải thực hiện các thay đổi đối với những sản phẩm mà chúng tôi không quen thuộc lắm hoặc khi chúng tôi không biết rõ những trường hợp đặc biệt nào có thể bị ảnh hưởng bởi thay đổi dự kiến. Trong các trường hợp phức tạp hơn, chúng tôi có thể cần phải tắt một số tác dụng phụ trước khi bật thử nghiệm bóng. Ví dụ: giả sử chúng tôi đang triển khai API phụ trợ mới để đăng ký người dùng và lưu vào DB, trả về ID người dùng. Chúng tôi thậm chí có thể có sẵn một DB ẩn để thực hiện toàn bộ quy trình, nhưng chắc chắn không nên gửi email “Đăng ký thành công” hai lần, một email cho mỗi API phụ trợ. Cũng trong ví dụ tương tự, chúng ta sẽ cần logic so sánh sâu hơn, vì việc chỉ so sánh các ID người dùng được trả về sẽ không hữu ích lắm. Cuối cùng, điều quan trọng là phải hiểu những gì cần được theo dõi và kiểm tra cũng như những tiêu chí nào sẽ được áp dụng nếu không đạt được sự cân bằng. Trong một số trường hợp quan trọng, chúng tôi sẽ phải lặp lại quá trình thử nghiệm bóng cho đến khi kết quả hoàn toàn giống nhau. Ở những nơi khác, có thể có một số % khác biệt khi việc triển khai mới mang lại những lợi ích bổ sung lớn hơn tổn thất. Nhật ký Ngay cả với các biện pháp bảo vệ mạnh mẽ, hệ thống vẫn có thể gặp trục trặc. Khi điều đó xảy ra, chúng ta cần có khả năng hiểu được điều gì đang xảy ra với mức độ chi tiết phù hợp, nếu không, có thể cực kỳ khó tìm ra cách khắc phục hiệu quả. Đây là nơi các bản ghi đến để tiết kiệm thời gian. Mặc dù việc ghi nhật ký không phải là một khái niệm mới và có nhiều giải pháp dễ thực hiện nhưng việc đảm bảo ghi nhật ký hiệu quả là một thách thức. Thông thường, nhật ký không rõ ràng, quá phức tạp, thiếu hoặc chứa đầy các mục nhập không liên quan, khiến việc khắc phục sự cố trở nên khó khăn. Tuy nhiên, nhật ký không chỉ dùng để giải quyết vấn đề. Việc ghi nhật ký thích hợp sẽ hỗ trợ việc xác minh tính hiệu quả của các tính năng và thay đổi mới. Bằng cách lấy mẫu các mục nhật ký, người ta có thể theo dõi hành trình của người dùng và xác nhận hệ thống hoạt động như dự định. suy nghĩ cuối cùng Vận chuyển mã đến nơi sản xuất đôi khi nguy hiểm nhưng chúng tôi có nhiều chiến lược để làm cho quá trình này an toàn hơn nhiều. Ngay cả khi chúng tôi xác định được vấn đề, điều quan trọng là phải biết điều gì có thể chấp nhận được hay không. Không phải tất cả các thất bại đều phải dẫn đến việc khôi phục. Điều gì sẽ xảy ra nếu chúng ta đang cố gắng khắc phục một lỗ hổng bảo mật nghiêm trọng hoặc tuân thủ quy định mới? Việc có các tiêu chí rõ ràng và hiểu tầm quan trọng của thay đổi là rất quan trọng để xác định thời điểm hủy bỏ hoặc tiếp tục trong trường hợp có vấn đề. Quay trở lại từ đầu, các số liệu chính giúp chúng ta trong quá trình đưa ra quyết định. Hạ cánh an toàn nhé mọi người!
