- Google SRE tổng kết kinh nghiệm nâng cao độ tin cậy từ giai đoạn vận hành dựa trên các trung tâm dữ liệu nhỏ và script Python, đến môi trường đã mở rộng quy mô tính toán hơn 1.000 lần và quy mô mạng hơn 10.000 lần
- Trong ứng phó sự cố, độ an toàn của biện pháp giảm thiểu phải được ưu tiên hơn hành động nhanh; quy trình khôi phục sai có thể làm gia tăng thất bại dây chuyền thay vì giảm sự cố
- Các trường hợp của YouTube và Google Calendar cho thấy sự cần thiết của triển khai canary để giới hạn thay đổi toàn cục, Big Red Button có thể hoàn tác ngay lập tức, và kiểm thử tích hợp để xác minh đường đi thực tế
- Khi phụ thuộc cốt lõi sụp đổ như sự cố token OAuth năm 2017, không chỉ người dùng mà cả hệ thống ứng phó nội bộ cũng bị lung lay, nên cần kênh liên lạc dự phòng và cơ chế suy giảm hiệu năng duyên dáng
- Rollout thường xuyên, giảm thiểu tự động, diễn tập khôi phục thảm họa và đa dạng hóa phần cứng là các nguyên tắc thực tiễn giúp giảm MTTR và tránh điểm lỗi đơn trong các hệ thống phân tán phức tạp
Những thay đổi về quy mô mà Google SRE trải qua trong 20 năm
- 20 năm trước, Google vận hành hai trung tâm dữ liệu nhỏ; mỗi trung tâm có hàng nghìn máy chủ, và hai liên kết mạng 2,4G được kết nối theo dạng vòng
- Khi đó, việc vận hành phụ thuộc nhiều vào các script Python như
Assigner,Autoreplacer,Babysittervà các tệp cấu hình chứa tên từng máy chủ - Một cơ sở dữ liệu máy nhỏ gọi là MDB được dùng để sắp xếp và duy trì liên tục thông tin của từng máy chủ
- Hiện nay, sức mạnh tính toán đã tăng hơn 1.000 lần, mạng đã lớn hơn hơn 10.000 lần, nhưng nỗ lực vận hành trên mỗi máy chủ đã giảm và độ tin cậy của stack dịch vụ đã tốt hơn
- Công cụ vận hành đã phát triển từ tập hợp script thành hệ sinh thái dịch vụ, rồi tiếp tục thành nền tảng tích hợp cung cấp độ tin cậy nền tảng
Nguyên tắc ứng phó rút ra từ sự cố YouTube
- Năm 2016, YouTube gặp sự cố toàn cầu trong 15 phút do lỗi trong hệ thống cache bộ nhớ phân tán, khiến khả năng phục vụ video bị gián đoạn
- Biện pháp giảm thiểu sự cố phải tương xứng với mức độ nghiêm trọng của sự cố
- Trong sự cố YouTube, quy trình cắt giảm tải (load-shedding) nguy hiểm không khắc phục được sự cố mà còn tạo ra thất bại dây chuyền
- Biện pháp giảm thiểu rủi ro cao trong trường hợp tốt nhất có thể giải quyết sự cố, nhưng trong trường hợp xấu nhất có thể hoạt động sai và kéo dài thời gian gián đoạn
- Ngay cả trong tình huống nghiêm trọng đến mức phải đi vòng qua quy trình chuẩn, vẫn cần quan sát và đánh giá mức độ nghiêm trọng trước khi lựa chọn
- Cơ chế khôi phục phải được kiểm thử đầy đủ trước tình huống khẩn cấp thực tế
- Lần đầu chạy một quy trình giảm thiểu nguy hiểm ngay trong lúc sự cố chẳng khác nào lần đầu dùng thang khi đang sơ tán khỏi đám cháy ở tòa nhà cao tầng
- Cần xác nhận trước rằng quy trình khôi phục thực sự thực hiện việc cần làm, và người phụ trách biết cách thực thi
- Bản thân việc kiểm thử cũng có tác dụng giảm rủi ro khi thực hiện biện pháp đó
- Mọi thay đổi phải giới hạn phạm vi ảnh hưởng bằng triển khai canary
- Thay đổi cấu hình cache đã gây hậu quả ngoài ý muốn, làm tê liệt nghiêm trọng dịch vụ YouTube trong 13 phút
- Nếu thay đổi toàn cục được triển khai dần theo chiến lược canary, sự cố có thể đã được giới hạn trước khi ảnh hưởng toàn cầu
- Tài liệu liên quan gồm bài báo về chiến lược canary và video bài trình bày tại SREcon
Rollback và kiểm thử học được từ sự cố Calendar
- Các thay đổi rủi ro cần có Big Red Button được định nghĩa trước
- Big Red Button là một cơ chế an toàn đơn giản, dễ thực thi để đảo ngược nguyên nhân tạo ra trạng thái không mong muốn
- Từng có trường hợp một kỹ sư rút nguồn máy tính để bàn trước khi thay đổi lan truyền, suýt nữa tránh được một sự cố lớn
- Khi lên kế hoạch cho các rollout quan trọng, cần cân nhắc “Big Red Button của tôi là gì?”, và mọi phụ thuộc dịch vụ nên có một cơ chế có thể thực thi trong tình huống khẩn cấp
- Bài viết liên quan là Generic Mitigations
- Chỉ kiểm thử đơn vị là chưa đủ; cần kiểm thử tích hợp
- Kiểm thử đơn vị xác nhận từng thành phần riêng lẻ hoạt động như kỳ vọng, nhưng không tái hiện đầy đủ môi trường runtime và yêu cầu production
- Kiểm thử tích hợp được dùng để xác minh liệu các workload và task có thể cold start hay không, và các thành phần có cùng nhau tạo ra hệ thống mong muốn hay không
- Trong sự cố Calendar, đường đi kiểm thử khác với đường đi sử dụng thực tế, nên dù có nhiều bài kiểm thử, chúng không giúp đánh giá thay đổi sẽ hoạt động thế nào trong thực tế
Sự cố token OAuth năm 2017 và tính liên tục vận hành
- Tháng 2 năm 2017, do các token OAuth không thể sử dụng, hàng triệu người dùng bị đăng xuất khỏi thiết bị và dịch vụ, và 32.000 thiết bị OnHub cùng Google WiFi đã thực hiện khôi phục cài đặt gốc
- Việc đăng nhập thất bại khiến yêu cầu khôi phục tài khoản thủ công tăng 10 lần, và Google mất khoảng 12 giờ để khôi phục hoàn toàn sau sự cố
- Ứng phó sự cố cần có kênh dự phòng tách biệt với kênh liên lạc chính
- Khi đó, các nhóm kỳ vọng có thể quản lý sự cố bằng Google Hangouts và Google Meet
- Nhưng trong tình huống 350 triệu người dùng bị đăng xuất khỏi thiết bị và dịch vụ, việc phụ thuộc vào dịch vụ của Google là không phù hợp
- Cần chuẩn bị và kiểm thử các kênh liên lạc dự phòng có phụ thuộc được tách biệt
- Dịch vụ cần tiếp tục hoạt động theo cách suy giảm hiệu năng duyên dáng (graceful degradation) ngay cả trong tình huống ngoại lệ
- Chỉ chia tính khả dụng thành “hoàn toàn bình thường” hoặc “hoàn toàn ngừng hoạt động” là không đủ
- Nếu vẫn duy trì được chức năng tối thiểu trong chế độ suy giảm, có thể mang lại trải nghiệm người dùng nhất quán hơn
- Suy giảm hiệu năng có thể không hiển thị với người dùng, và dịch vụ cần được thiết kế để tiếp tục vận hành ngay cả trong các tình huống ngoại lệ
Thảm họa, tự động hóa, rollout và đa dạng hóa phần cứng
- Khả năng chống chịu thảm họa và kiểm thử khôi phục là yếu tố cốt lõi của chiến lược liên tục kinh doanh
- Kiểm thử khả năng chống chịu xác minh liệu dịch vụ hoặc hệ thống có thể trụ vững trước sự cố, độ trễ và gián đoạn hay không
- Kiểm thử khôi phục xác nhận liệu dịch vụ có thể trở lại trạng thái bình thường sau khi bị tắt hoàn toàn hay không
- Cần giả định cả các tình huống cực đoan như thiên tai hoặc tấn công mạng, như trong Weathering the Unexpected
- Hoạt động để nhóm xem xét các kịch bản theo kiểu tabletop game như “Điều gì xảy ra nếu một phần kết nối mạng bị ngắt bất ngờ?” cũng hữu ích
- Với các sự cố có tín hiệu rõ ràng, tự động hóa giảm thiểu là phương tiện để giảm MTTR
- Tháng 3 năm 2023, nhiều thiết bị mạng tại nhiều trung tâm dữ liệu gần như đồng thời gặp lỗi, gây mất gói trên diện rộng
- Trong sự cố kéo dài 6 ngày này, khoảng 70% dịch vụ bị ảnh hưởng ở các mức độ khác nhau tùy theo vị trí, tải dịch vụ và cấu hình tại thời điểm xảy ra lỗi mạng
- Tỷ lệ dịch vụ bị ảnh hưởng: {p:70}
- Nếu có tín hiệu rõ ràng rằng một lỗi cụ thể đã xảy ra, có thể tự động khởi động các biện pháp giảm thiểu vốn thực hiện thủ công để giảm MTTR
- Đôi khi tốt hơn nên tránh ảnh hưởng đến người dùng trước, rồi mới phân tích nguyên nhân gốc
- Khoảng cách giữa các rollout càng dài thì càng khó đánh giá độ an toàn của thay đổi
- Tháng 3 năm 2022, sự cố hệ thống thanh toán khiến khách hàng không thể hoàn tất giao dịch, và ngày cộng đồng Pokémon GO bị hoãn
- Nguyên nhân là việc xóa một trường cơ sở dữ liệu duy nhất; vì việc sử dụng trường đó đã được gỡ khỏi mã, thay đổi này có vẻ đáng lẽ phải an toàn
- Tuy nhiên, do chu kỳ rollout chậm ở một số phần của hệ thống, hệ thống live vẫn đang sử dụng trường đó
- Trong các hệ thống phức tạp gồm nhiều thành phần, độ trễ rollout dài khiến việc đánh giá độ an toàn của một thay đổi cụ thể trở nên rất khó
- Với kiểm thử phù hợp, rollout thường xuyên có thể giảm các thất bại bất ngờ kiểu này
- Một phiên bản phần cứng toàn cầu duy nhất có thể trở thành điểm lỗi đơn
- Nếu giao một chức năng quan trọng cho thiết bị thuộc một model duy nhất, vận hành và bảo trì có thể trở nên đơn giản hơn
- Nhưng nếu model đó gặp vấn đề, chức năng quan trọng ấy sẽ không còn được thực hiện
- Tháng 3 năm 2020, một thiết bị mạng có lỗi zero-day chưa được phát hiện đã bộc lộ lỗi khi mô hình lưu lượng thay đổi; cùng một model và phiên bản được dùng trên toàn mạng, dẫn đến sự cố đáng kể theo khu vực
- Nhờ có nhiều backbone mạng, lưu lượng ưu tiên cao có thể được chuyển sang các tuyến thay thế vẫn còn hoạt động, tránh được sự cố toàn diện
- Các lỗi tiềm ẩn trong hạ tầng quan trọng có thể ẩn mình cho đến khi một sự kiện bề ngoài vô hại xảy ra; duy trì hạ tầng đa dạng có thể là khác biệt giữa một sự cố có vấn đề và một sự cố toàn diện
1 bình luận
Các ý kiến trên Hacker News
Bài viết rất hay và có vẻ áp dụng rộng rãi. Không có phần nào kiểu “chuyện này chỉ đúng ở Google” cả
Kênh liên lạc, kênh dự phòng, và cả dự phòng cho kênh dự phòng đó thực sự rất quan trọng. Ở Netflix, khi chọn nhà cung cấp cho hệ thống dùng trong lúc sự cố, chúng tôi luôn kiểm tra xem nó có chạy trên AWS hay không; còn ở reddit, chúng tôi đặt một IRC dự phòng trên máy chủ văn phòng phòng khi IRC chính không dùng được
Tôi nghe nói Google cũng có máy chủ IRC dự phòng trên AWS, nhưng đó có thể chỉ là truyền thuyết. Điểm cốt lõi là phải có kênh liên lạc phụ càng độc lập với hạ tầng của mình càng tốt
Đội đó nằm trên đường đi trọng yếu, nên nếu hệ thống của chúng tôi gây ra cuộc gọi báo sự cố, khả năng Google.com cũng sập cùng với Google Meet không hề thấp. Vì Gmail nên email cũng không dùng được, vì Google Fi nên điện thoại công việc cũng không dùng được, ISP ở nhà lại là Google Fiber/Webpass, nên cần thêm các lớp dự phòng
Vì vậy ở Google thực sự có máy chủ IRC dự phòng cho liên lạc. Tôi sẽ không nói nó đặt ở đâu, nhưng chính vì lý do đó mà nó được đặt rõ ràng bên ngoài hạ tầng Google
Về chuyện “áp dụng rộng rãi và không chỉ đúng ở Google”, thứ tôi gần như không thấy ở nơi khác là phòng khẩn cấp vận hành. Ý là một phòng bảo mật có VPN dự phòng vào môi trường vận hành
Một ngày nọ SAN vận hành gặp vấn đề, làm trung tâm dữ liệu on-premises sập, và Atlassian cũng chết theo. Không có Jira, không có Confluence, CI/CD có lẽ cũng không còn, cũng không có tài liệu quy trình khôi phục được sắp xếp, chỉ còn lại tri thức bộ lạc
Mọi người nổi giận, và họ có lý do. Đặt hệ thống đối diện khách hàng và hệ thống liên quan đến hạ tầng vào cùng một giỏ là cực kỳ nguy hiểm
Ít nhất là 2 năm trước, khi tôi vẫn còn làm ở đó, thì là như vậy
Một lúc nào đó tôi muốn nghe lời giải cho vấn đề khởi động lạnh hoàn toàn. Các công ty có stack tự xây khổng lồ đều có phụ thuộc vòng trong hạ tầng cốt lõi
Mạng định nghĩa bằng phần mềm cần một số phần mềm phải chạy để bắt đầu định tuyến gói tin trở lại; máy không có đĩa cần nơi lưu trữ để khởi động; dịch vụ xác thực cần quyền truy cập lưu trữ để bootstrap việc cấp quyền bảo mật
Hiện nay họ xử lý bằng cách vận hành nhiều region độc lập, rồi bootstrap một trung tâm dữ liệu đã tắt hoàn toàn từ hạ tầng hiện có. Nhưng tôi chưa từng nghe câu chuyện nào về việc đưa toàn bộ stack lên lại từ trạng thái mất điện hoàn toàn
Vài năm trước, khi Facebook làm hỏng hoàn toàn mạng vận hành, các máy vẫn bật và vẫn còn một phần kết nối nội bộ. Nếu một sự kiện như bão Mặt Trời quy mô lớn làm lưới điện toàn cầu ngừng hoạt động lâu đến mức máy phát điện cũng cạn hết, không có gì đảm bảo các đám mây như AWS hay GCP chắc chắn sẽ hồi sinh
Có lẽ họ có những trung tâm dữ liệu chuyên dụng nhỏ với nguồn điện dự phòng xuất sắc và khả năng cách ly hoàn toàn khỏi xung điện trên lưới điện
Ở phần trên của stack, nó hữu ích để theo dõi các phụ thuộc mà tác giả thư viện âm thầm thêm vào; ở phần dưới, nó giúp bảo đảm những thứ đáng lẽ ở đáy thì thật sự nằm ở đáy
Chúng tôi cũng khởi động và tắt các cụm tự động ảo để quy trình được tài liệu hóa không trở nên lỗi thời, và trong 6 năm làm SRE, tôi đã thấy quy trình đó giảm từ 90 ngày xuống dưới 1 giờ
Những việc như quản lý khóa mã hóa toàn cục cần đối tượng vật lý cũng được diễn tập khởi động lại từ đầu định kỳ, và các cuộc diễn tập DiRT hằng năm cố gắng bảo đảm không cá nhân, đội hay văn phòng nào trở thành điều kiện bắt buộc để hệ thống tiếp tục vận hành
Nếu bắt đầu muộn thì sẽ rất đau đớn, nhưng nếu làm vậy ngay từ đầu, bạn sẽ nhanh chóng quen và có thể phát hiện sớm các thay đổi gây hỏng hoặc những phụ thuộc kỳ lạ
Cũng có thể áp dụng cho phần cứng. Kiến trúc sẽ thay đổi để chịu được tình huống thứ gì đó bị rút ra hoặc được khởi tạo lại. Bạn sẽ cần nhiều tự động hóa hơn, quản lý phiên bản và quản lý thay đổi nhiều hơn; đổi lại, không chỉ phòng tránh sự cố và khôi phục nhanh hơn, mà toàn bộ công việc cũng nhanh và đơn giản hơn. Đó là một thay đổi văn hóa lớn
Theo tôi nhớ, một phần cách tiếp cận được xem là thông tin nhạy cảm nên tôi sẽ không nói chi tiết hơn
Cũng thú vị nếu biết lưới điện nào đã khởi động lạnh nhiều nhất. Lý tưởng thì nơi đó hẳn đã làm rất tốt. Tôi đoán là đâu đó ở Caribe hoặc châu Phi
Tuy nhiên, khởi động lạnh một lưới điện nhỏ, chẳng hạn một đảo xa chỉ có một máy phát diesel và điện mặt trời, có thể quá dễ nên không phải nghiên cứu tình huống tốt
Rõ ràng Internet tự thân không thể khởi động lạnh như lưới điện xoay chiều. Có quá nhiều AS. Chỉ cần nghĩ một chút AS nghĩa là gì, bạn sẽ hiểu vì sao một lần khởi động lạnh được điều phối và diễn tập trước là bất khả thi
Để tìm hiểu sâu hơn về chủ đề này, tôi đang đọc gần xong Building Secure and Reliable Systems của Google; đây không phải là tài liệu đọc nhẹ nhàng mà gần như là một giáo trình đúng nghĩa
Đây là một cuốn sách khá thú vị, và nhiều nội dung trông có vẻ như lẽ thường, nhưng như cách nói rằng bản thân cụm “lẽ thường” đã là một mâu thuẫn, nó hữu ích để làm mới toàn bộ kiến thức trong một lần
Gần đây tôi nghe nói một vài công ty đã giải thể tổ chức SRE và chuyển thành viên sang các nhóm SWE. Có tin đồn rằng LinkedIn, Adobe, Robinhood đã làm như vậy
Vì thế tôi bắt đầu nghĩ liệu SRE có phải là sản phẩm phụ của nền kinh tế bong bóng khi tiền dễ kiếm còn nhiều hay không. Không thể vận hành mà không tốn chi phí lớn để duy trì một nhóm SRE riêng sao?
Cũng như quản trị viên hệ thống hay QA tester phần lớn đã biến mất và nhiều chức năng được chuyển sang các nhóm phát triển phần mềm, tôi tự hỏi 10 năm nữa SRE có còn tồn tại không
Nhưng hiện nay sa thải vẫn tiếp diễn, nên không nhiều công ty quan tâm đến điểm đó. Xu hướng đưa lập trình viên vào xử lý vấn đề, dù đó không phải lĩnh vực chuyên môn của họ, là một xu hướng trong ngành sẽ không biến mất, và sẽ càng rõ hơn trong giai đoạn suy thoái
Lập trình viên full-stack là một ví dụ điển hình: gộp hai vai trò lại nhưng không trả lương gấp đôi
Tuy vậy, tôi vẫn cho rằng ý chính còn lại là đúng. Ngày nay, vì DevOps, phạm vi năng lực cần có ở lập trình viên đã rộng hơn và chồng lấn đáng kể với SRE. Các công ty có khả năng sẽ thu hẹp đội SRE và phân tán trách nhiệm sang lập trình viên
Một lý do lớn khác là tự động hóa. Nếu đọc kỹ trang được liên kết trong thời gian dài, có thể thấy ở thời kỳ đầu của Google, SRE làm rất nhiều việc thủ công, như quan sát biểu đồ bằng tay khi triển khai
Khi đó, ngay cả Google cũng chưa tự động hóa hệ thống đủ tốt, nên SRE là thiết yếu. Nếu xem câu chuyện Sisyphus https://www.usenix.org/sites/default/files/conference/protec..., có thể phần nào hiểu được việc Google thất bại trong lần đầu đưa tự động hóa tiêu chuẩn vào đã bảo đảm tính ổn định việc làm của SRE như thế nào
Việc chuyển giao vận hành phần mềm do chính mình viết cho người khác là không hợp lý. Cứ đưa SWE vào lịch on-call là được. Nếu họ nghĩ thao tác thủ công là phương án tốt nhất, hãy để họ tự làm; nếu ở mức đó thì nên sa thải vì là kỹ sư tồi
Phỏng vấn thì khắt khe như vậy, nhưng rốt cuộc lại không biết chiếc máy tính mà mình lập trình hoạt động ra sao thì thật kỳ lạ. Những thứ như cách hệ điều hành hoạt động cũng có trong chương trình đại học, vậy mà việc đẩy chúng sang nhiều vị trí và chức danh vốn chủ yếu do những quản trị viên hệ thống tự học đảm nhiệm cũng kỳ lạ
Tất cả SWE giỏi mà tôi biết đều hiểu hệ điều hành, máy tính và mạng hoạt động như thế nào
Những việc mà SRE thường làm hiện nay như tự động hóa chung, cung cấp công cụ phát triển, cải thiện trải nghiệm lập trình viên đang chuyển sang nhóm platform. Tôi cho rằng vai trò này sẽ thay đổi rất lớn trong tương lai
Một nhóm SRE có thể hỗ trợ nhiều nhóm phát triển, và các nhóm phát triển thường dành rất ít thời gian cho hạ tầng phức tạp hoặc các khía cạnh của hệ thống phân tán, vì đó không phải lĩnh vực họ lo nghĩ hằng ngày
Vì vậy, việc có một tổ chức hạ tầng vận hành như một đơn vị khác với các nhóm phát triển chuyên biệt là hợp lý. Dù gọi đó là SRE, nhóm SRE SWE, hay đơn giản là hạ tầng, khi đạt đến một quy mô nhất định, các mối quan tâm xuyên suốt nhiều nhóm sẽ nhiều lên và việc tách riêng như vậy sẽ rẻ hơn
Khi có SRE chuyên trách, bạn có những chuyên gia thực sự về vận hành, các hệ thống liên quan, công cụ, cảnh báo, v.v., và cũng có trách nhiệm rõ ràng đối với kết quả. Nhưng vì họ không hoàn toàn sở hữu chính hệ thống mà họ duy trì, nên có thể nảy sinh vấn đề tổ chức
Có thể xảy ra chuyện “chúng tôi muốn phát hành X nhưng SRE phản đối”, hoặc ngược lại, và những người không phải SRE có thể không còn chịu trách nhiệm với mã khó hỗ trợ
Ngược lại, các nhóm kỹ thuật không có SRE có thể giảm những vấn đề tổ chức/xã hội như vậy, nhưng độ tin cậy vận hành sẽ trở thành một trong nhiều ưu tiên
Trên thực tế, tôi cho rằng nhiều công ty đang quyết định rằng họ không coi độ tin cậy là kết quả kinh doanh quá quan trọng. Điều này đặc biệt đúng khi chi phí cơ hội của phát triển tính năng tăng lên
Tự động giảm thiểu sự cố là thứ thật sự phải suy nghĩ rất lâu. Trong 30 năm sự nghiệp, tôi đã nhiều lần thấy tự động giảm thiểu làm vấn đề tệ hơn. Vì vậy cần cân nhắc kỹ xem có thật sự cần tự chữa lành hay không
Năm 2014, tôi đã xây dựng một giải pháp báo cáo crash trên di động dùng nội bộ công ty; một phần backend chạy trên một máy chủ duy nhất, với Redis là điểm lỗi đơn lẻ. Quy trình failover là bán tự động, nên phải có người xác nhận cảnh báo là hợp lệ rồi mới khởi động
Nếu nó sập thì cũng không có thiệt hại tiền bạc thực tế; tệ nhất là các lập trình viên ứng dụng di động chỉ bất tiện trong chốc lát. Trong 10 năm vận hành, số lần phải failover đếm trên hai ngón tay là đủ
Dù là hệ thống không có SLA, uptime của nó còn tốt hơn nhiều hệ thống nội bộ quan trọng hơn nhiều
Ngược lại, có thể nhìn các trường hợp của GitHub: https://github.blog/2023-05-16-addressing-githubs-recent-ava..., https://github.blog/2018-10-30-oct21-post-incident-analysis/, https://www.datacenterknowledge.com/archives/2012/12/27/gith...
Tất nhiên GitHub vận hành ở quy mô lớn hơn rất nhiều. Ý chính là redundancy và tự động giảm thiểu làm tăng độ phức tạp, và theo định nghĩa chúng hoạt động trong các tình huống không lường trước khi gần như chưa được kiểm thử
Vì vậy hãy cân nhắc SLA và chi phí khi xảy ra sự cố, rồi cân bằng với độ phức tạp sẽ thêm vào để ngăn sự cố. Khoảng năm 1998, tôi từng ghép hai máy NetApp thành cấu hình high availability; khi một máy hỏng, nó làm hỏng luôn toàn bộ đĩa của máy còn lại. Đó là bài học đầu tiên của tôi
Cũng vào khoảng thời gian đó, chuyện tương tự xảy ra với hai tường lửa Cisco PIX, và từ đó về sau tôi luôn thận trọng với high availability cùng failover/giảm thiểu tự động
Tôi tò mò trong thực tế người ta xử lý nút đỏ lớn và việc suy giảm hiệu năng có chủ ý, theo từng bước, như thế nào. Đặc biệt là làm sao bảo đảm chúng vẫn hoạt động trong lúc hệ thống đang gặp vấn đề
Ví dụ, có dùng feature flag dựa trên cơ sở dữ liệu không; nếu có thì khi chính cơ sở dữ liệu hoặc API truy cập bị quá tải thì làm gì
Hay dùng các flag khởi động tĩnh như biến môi trường; trong trường hợp đó làm sao bảo đảm chúng được triển khai đủ nhanh. Hoặc liệu có cách hoàn toàn khác không
Ngay cả khi không dùng redundancy ở một số phần của đường dẫn trọng yếu, nếu hệ thống đủ đơn giản để mọi maintainer đều nắm được trong đầu và có thể dễ dàng khởi động lại hoặc rollback, thì đó có thể là lựa chọn tốt hơn
Nhưng khi công ty bắt đầu đưa ra các cam kết như “uptime five nines”, thì để thiết kế hệ thống vừa duy trì được cam kết đó vừa tiếp tục phát triển và cải tiến, một mức độ phức tạp nhất định là cần thiết
Ở Google, nếu một cluster cụ thể được đánh giá là không khỏe, họ thường xuyên thực hiện “backend drain”, và có hệ thống ở tầng API/load balancer để xử lý việc này nhanh chóng
Ở nơi khác, tôi cũng từng thấy xử lý bằng flag ở cấp ứng dụng. Kiểu như chạy
kubectl edit, rõ ràng không lý tưởng, nhưng vẫn hoạt độngThứ nhất, phải giữ đơn giản. Tốt nhất chỉ là kiểm tra flag đơn giản, không có logic tinh vi hay kho dữ liệu phức tạp
Thứ hai, đặt càng gần nguồn càng tốt nhưng không nên quá tin client. Có thể có phiên bản cũ, độ trễ lan truyền, lỗi, nên tốt nhất là cả client lẫn server đều có thể chọn chế độ suy giảm; nếu chỉ chọn được một phía thì phía server tốt hơn
Thứ ba, phải kiểm thử thường xuyên bằng traffic thật. Đừng tin môi trường test; cần có các bài kiểm thử định kỳ quy mô nhỏ như 0,1% và các bài kiểm thử quy mô lớn được lên lịch. Nếu chưa kiểm thử thì khi cần nó sẽ không hoạt động; nếu một năm trước từng chạy được thì giờ rất có thể không còn chạy được. Một cơ chế chưa được kiểm thử có thể gây hại nhiều hơn là giải quyết vấn đề
Ví dụ giả sử bạn thêm một tính năng mới hiển thị ảnh đại diện bên cạnh bình luận trên Hacker News. Dĩ nhiên mọi thứ đều đã được làm thành microservice, nên giả sử trình tạo trang frontend gọi đến profile service, profile service truy vấn rồi trả về vị trí ảnh
Như một phần của kế hoạch phát hành, cần ghi lại quy trình nút đỏ lớn sẽ làm theo nếu component mới làm quá tải profile service hoặc kho lưu ảnh. Tức là chạy lệnh ở tầng mạng để giới hạn tốc độ các request bên ngoài tới service của tôi, và trong tình huống khẩn cấp có lẽ đặt về 0
Việc truy vấn sẽ thất bại, nhưng trình tạo trang được thiết kế để suy giảm từ từ, vẫn render phần văn bản bình luận mà không có ảnh đại diện
Đây không phải tài liệu thiết kế thực tế, cũng không phải lời khuyên nên xây dựng cái gì hay xây dựng thế nào; chỉ là một hình vẽ bằng bút sáp để minh họa ý chính
Tôi từng làm bằng CDB (constant database) của djb, cũng từng thấy các trường hợp poll file cấu hình JSON qua API hoặc dùng dbm/gdbm/Berkeleydb/leveldb
Cách này có thể mở rộng cho các nút đỏ lớn khác. Không thanh lịch, nhưng tôi đã nhiều lần vận hành các service kiểm tra sự tồn tại của một file để quyết định có cung cấp health check hay không. Việc đưa một node ra khỏi vòng quay của load balancer dễ như tạo một file
Điểm cốt lõi là nếu cơ sở dữ liệu gặp sự cố, hệ thống phải dùng cấu hình tốt đã được xác nhận gần nhất làm mặc định
Tôi thật sự muốn nhấn mạnh câu “cơ chế khôi phục phải được kiểm thử đầy đủ trước khi xảy ra tình huống khẩn cấp”. Là một người bất ngờ trở thành SRE ở Google và được biết đến toàn công ty vì dùng sai phủ định kép, đây là việc cực kỳ quan trọng cần làm đúng ngay từ đầu
Nếu Googler nào tò mò, hãy tìm username của tôi trong nội bộ, bạn sẽ thấy tôi đã tạo ra một tác động lớn đến mức không thể đo đếm như thế nào
Cách rẻ nhất để ngăn sự cố là bắt được chúng từ sớm trong vòng đời. Lỗi phần mềm khá giống côn trùng ngoài đời. Ban đầu là trứng, tức ý tưởng thay đổi; ấu trùng mới nở là POC đầu tiên. Đến khi chạm tới môi trường vận hành thì nó đã là con trưởng thành
Bạn hỏi chẳng phải còn các giai đoạn trước khi trưởng thành sao? Đúng vậy. Ứng dụng phải đi qua nhiều giai đoạn trước khi chín muồi. Tìm ra lỗi trước khi nó lớn hết cỡ và đẻ trứng thì rẻ hơn rất nhiều
Nếu triển khai canary khó và rollback cũng có vấn đề, thì cần thêm nhiều kiểm thử hơn trước khi triển khai lên production. Phải phát hiện lỗi sớm bằng càng nhiều cách càng tốt: linter, kiểm thử đơn vị, kiểm thử end-to-end, profiler, synthetic monitor, bản sao production chỉ đọc, kiểm thử hiệu năng, v.v.
Feature flag, tương thích ngược, v.v. cũng hữu ích, nhưng không thể thắng được Shift Left
Nếu bạn quan tâm đến một danh sách tương tự từ góc nhìn của người làm SRE 15 năm trong các lĩnh vực FinTech, ngân hàng, quỹ đầu cơ và tiền mã hóa, tôi khuyên đọc bài này: https://x.com/alexpotato/status/1432302823383998471?s=20
Nếm thử: “25. Nếu có một rule engine mà việc tạo quy tắc mới còn dễ hơn tìm quy tắc hiện có bằng điều kiện lọc, thì cuối cùng sẽ có cả đống quy tắc trùng lặp”
“Một kỹ sư đã gửi thay đổi suýt gây sự cố, rồi rút điện máy tính để bàn trước khi thay đổi được lan truyền, nhờ vậy suýt soát tránh được một sự cố lớn” là sao vậy?
Kết quả là các SWE hạ tầng không xây những nút bấm thật, mà ngồi cả ngày viết mấy CLI ngớ ngẩn. Đến lúc tôi rời đi thì chuyện này đã thay đổi khá nhiều
Tôi nghĩ Google nên công khai nhiều hơn các sự cố nội bộ. Sự cố này đặc biệt nổi tiếng trong nội bộ
Ngay cả ở quy mô khổng lồ, các công cụ shell và CLI client RPC vẫn có thể chạm tới mọi máy trên toàn thế giới khá nhanh
psshChuyện đó là 10 năm trước nên tôi không biết giờ còn dùng như vậy không, nhưng cách đó nhanh đến đáng ngạc nhiên. Có thể đó là một việc kiểu như thế
Nhưng 20 năm trước thì chuyện đó hẳn phổ biến hơn, và ngay cả bây giờ vẫn có thể xảy ra ở các tổ chức nhỏ