Site Reliability Engineering
Preface
Lời mở đầu
Software Engineering giống như nuôi dạy những đứa trẻ: giai đoạn trước khi sinh cực kỳ đau đớn và khó khăn, nhưng quá trình sau đó mới là lúc cần nhiều công sức nhất. Tuy nhiên, ngành kỹ thuật phần mềm thường dành nhiều thời gian nói về giai đoạn đầu hơn là những gì diễn ra sau đó dù ước tính rằng 40-90% tổng chi phí của một hệ thống phát sinh sau khi nó được xây dựng xong.
Xem thêm về sự biến động của ước tính này tại Facts and Fallacies of Software Engineering, Addison-Wesley Professional, 2002 - R. Glass.
Một mô hình công nghiệp phổ biến cho rằng phần mềm một khi đã được triển khai, sẽ luôn hoạt động “ổn định” trên môi trường production, và do đó cần ít sự chú ý hơn từ các kỹ sư phần mềm, là hoàn toàn sai lầm. Nhìn từ góc độ này, chúng ta thấy rằng nếu software engineering tập trung vào thiết kế và xây dựng hệ thống phần mềm, thì phải có một ngành khác tập trung vào toàn bộ vòng đời của các đối tượng phần mềm, từ sáng tạo, triển khai và vận hành, tinh chỉnh cũng như cuối cùng là việc gỡ bỏ một cách yên bình. Ngành này sử dụng - và cần sử dụng - một loạt các kỹ năng khác nhau, nhưng quan tâm đến các vấn đề riêng biệt so với các nhóm kỹ sư khác. Hôm nay, câu trả lời của chúng tôi chính là lĩnh vực mà Google gọi là Site Reliability Engineering.
Vậy chính xác thì Site Reliability Engineering (SRE) là gì? Chúng tôi thừa nhận rằng đây không phải một tên gọi rõ ràng cho những gì chúng tôi làm - hầu hết các kỹ sư đảm bảo độ tin cậy tại Google đều thường xuyên được hỏi thực sự họ đang làm gì.
Mở rộng khái niệm một chút, trước tiên và quan trọng nhất, SRE là những kỹ sư. Chúng tôi áp dụng các nguyên tắc của khoa học máy tính và kỹ thuật vào thiết kế và phát triển các hệ thông tính toán: thông thường là những hệ thống phân phối lớn. Đôi khi, nhiệm vụ của chúng tôi là viết phần mềm cho những hệ thống đó cùng với các đồng nghiệp phát triển sản phẩm; cũng có lúc, nhiệm vụ của chúng tôi là xây dựng các thành phần bổ sung mà những hệ thống đó cần, chẳng hạn như sao lưu hoặc cân bằng tải, lý tưởng là có thể tái sử dụng trên nhiều hệ thống; và đôi lúc, nhiệm vụ của chúng tôi là tìm cách áp dụng các giải pháp hiện có vào những vấn đề mới.
Tiếp đó, chúng tôi tập trung vào độ tin cậy/ổn định (reliability) của hệ thống.
Đối với mục đích của chúng tôi, reliability được hiểu là "Xác suất một hệ thống sẽ thực hiện một chức năng được yêu cầu mà không gặp lỗi trong điều kiện đã nêu ở một khoảng thời gian nhất định," theo định nghĩa trong Practical Reliability Engineering, 5th edition: Wiley, 2012 - P. O’Connor & A. Kleyner.
Ben Treynor Sloss, Phó chủ tịch điều hành mảng vận hành 24/7 của Google, người đã tạo ra thuật ngữ SRE, cho rằng reliability là tính năng cơ bản nhất của bất kỳ sản phẩm nào: một hệ thống không thể hữu ích nếu ta không thể sử dụng nó! Vì tính reliability thực sự rất quan trọng nên các SRE sẽ tập trung vào tìm cách cải thiện thiết kế, hoạt động của hệ thống để tăng khả năng mở rộng (scalable), đáng tin cậy (reliable) và hiệu quả (efficient) của nó. Tuy nhiên, chúng tôi chỉ tiếp tục nỗ lực theo hướng này đến một mức độ cụ thể: khi hệ thống đã “đủ tin cậy”, chúng tôi sẽ đầu tư vào việc thêm tính năng hoặc xây dựng sản phẩm mới.
Các hệ thống phần mềm mà chúng tôi quan tâm chủ yếu là các trang web và dịch vụ tương tự; chúng tôi không thảo luận về độ đáng tin cậy ở khía cạnh phần mềm dùng cho nhà máy điện hạt nhân, máy bay, thiết bị y tế hoặc hệ thống quan trọng, an toàn khác. Tuy nhiên, chúng tôi so sánh cách tiếp cận của mình với những phương pháp được sử dụng trong các ngành công nghiệp khác xem thêm ở chương Lessons Learned from Other Industries
Cuối cùng, SRE tập trung vào việc vận hành các dịch vụ được xây dựng trên những hệ thống máy tính phân tán của chúng tôi, từ ứng dụng lưu trữ quy mô toàn cầu, email dành cho hàng trăm triệu người dùng, cho đến công cụ tìm kiếm như Google. “Site” trong tên của chúng tôi ban đầu đề cập đến vai trò của SRE trong việc duy trì hoạt động của trang web google.com, mặc dù hiện nay chúng tôi đã vận hành nhiều dịch vụ hơn, trong đó có những ứng dụng không phải là trang web, từ cơ sở hạ tầng nội bộ như Bigtable đến các sản phẩm dành cho nhà phát triển bên ngoài như Google Cloud Platform.
Mặc dù chúng tôi đã mô tả SRE như một ngành khá rộng, nhưng cũng sẽ không quá ngạc nhiên nếu nó tiếp tục xuất hiện trong thế giới dịch vụ web đang phát triển một cách cực kỳ nhanh chóng, với nền tảng có thể là từ những đặc điểm đặc biệt của hạ tầng Google. Và cũng không có gì ngạc nhiên khi trong tất cả những điều cần tập trung sau khi triển khai phần mềm thì độ tin cậy - reliability chính là yếu tố chúng tôi coi là quan trọng nhất. Lĩnh vực dịch vụ web, vừa bởi vì quá trình cải thiện và thay đổi phần mềm ở server-side bị giới hạn, vừa bởi việc quản lý những thay đổi đó thường liên quan chặt chẽ đến các sự cố đa dạng mà trở thành nền tảng tự nhiên khiến các phương pháp của chúng tôi trở nên giá trị.
Dù được phát triển tại Google và trong cộng đồng web nói chung, chúng tôi cho rằng lĩnh vực này có cả những bài học áp dụng được cho các nhóm và tổ chức khác. Cuốn sách này là một nỗ lực để giải thích cách SRE làm việc: vừa để các tổ chức có thể áp dụng những gì chúng tôi đúc kết được, vừa để chúng tôi có thể xác định rõ hơn vai trò và ý nghĩa của thuật ngữ này. Với mục tiêu đó, chúng tôi xây dựng cuốn sách sao cho các nguyên tắc chung và phương pháp cụ thể được phân tách, để khi thảo luận về một chủ đề cụ thể trong môi trường tại Google, người đọc sẽ thông cảm và không ngại rút ra những kết luận hữu ích ứng dụng cho trường hợp của chính họ.
Chúng tôi có cung cấp một số tài liệu hướng dẫn - mô tả về môi trường production của Google tương ứng với một số phần mềm nội bộ cũng như phần mềm có sẵn công khai - điều này sẽ giúp hiểu rõ hơn về bối cảnh của những gì chúng tôi nói và giúp nó có giá trị ứng dụng hơn.
Tóm lại, tất nhiên tập trung vào tính reliability cho software và system engineering là tốt. Tuy nhiên, chúng tôi công nhận rằng các tổ chức nhỏ hơn có thể đang tự hỏi làm thế nào để sử dụng tốt nhất những kinh nghiệm được đúc kết ở đây? Tương tự như bảo mật, bạn nên quan tâm đến độ tin cậy càng sớm càng tốt. Nó có nghĩa rằng ngay cả khi một tổ chức nhỏ có nhiều vấn đề cấp thiết cần ưu tiên và việc lựa chọn phần mềm của bạn có thể sẽ khác với những gì Google đã chọn, thì vẫn đáng để áp dụng việc quản lý tính reliability ngay từ đầu một cách nhẹ nhàng, nhờ đó khi mở rộng kiến trúc sau này sẽ ít tốn kém hơn so với ứng dụng cho một cấu trúc không có sẵn nền móng. Việc quản lý này sẽ gồm một số phương pháp tối ưu cho quá trình đào tạo, giao tiếp và thảo luận đã đem đến hiệu quả cho chúng tôi, trong đó nhiều phương pháp có thể ngay lập tức được sử dụng cho tổ chức của bạn.
Đối với quy mô từ startup đến tập đoàn đa quốc gia, có thể đã có người trong tổ chức của bạn đang thực hiện công việc SRE dù không được gọi hoặc công nhận như vậy. Một cách khác để bắt đầu trên con đường cải thiện tính reliability cho tổ chức của bạn là công nhận chính thức công việc đó, hoặc tìm những người này và khuyến khích những gì họ đang làm - đưa cho họ những phần thưởng xứng đáng. Họ là những người đứng trên ranh giới giữa hai cách nhìn khác nhau: giống như Newton, người đôi khi không phải được gọi là nhà vật lý học đầu tiên, mà là nhà giả kim cuối cùng trên thế giới.
Nếu xem xét từ quan điểm lịch sử, ai có thể là SRE đầu tiên?
Chúng tôi thích việc coi Margaret Hamilton từ MIT, người được NASA mượn để làm việc trong chương trình Apollo, đã có tất cả những đặc điểm quan trọng của một SRE đầu tiên. Theo lời bà ấy, “một phần của văn hóa là học hỏi từ tất cả mọi người và tất cả mọi thứ, bao gồm cả những điều mà người ta ít mong đợi nhất”.
Một ví dụ điển hình là khi con gái nhỏ của cô, Lauren, đến làm việc cùng cô một ngày, trong khi một số thành viên của nhóm đang chạy các kịch bản nhiệm vụ trên máy tính mô phỏng. Như những đứa trẻ nhỏ thường làm, Lauren đã đi khám phá xung quanh và khiến cho một nhiệm vụ bị sập khi vô tình bấm vào các phím DSKY, cảnh báo về một trường hợp có thể xảy ra nếu chương trình tiền khởi động, P01, được chọn một cách ngoài ý muốn bởi một phi hành gia khi thực hiện nhiệm vụ trong quá trình bay thực sự. (Vô tình khởi động P01 sẽ là một vấn đề lớn bởi vì nó xóa dữ liệu điều hướng và máy tính không được trang bị để điều khiển tàu khi dữ liệu điều hướng bị mất.)
Với bản năng của một SRE, Margaret đã gửi một yêu cầu thay đổi chương trình để thêm đoạn mã đặc biệt để kiểm tra lỗi vào phần mềm trên bảng điều khiển máy bay, phòng ngừa trường hợp một phi hành gia vô tình chọn P01 khi bay. Tuy nhiên đội ngũ cấp cao tại NASA đã coi đây là điều không cần thiết: đó là điều không thể xảy ra bao giờ! Vì vậy, thay vì thêm đoạn mã kiểm tra lỗi, Margaret đã cập nhật tài liệu quy định nhiệm vụ để truyền đạt việc “Không chọn P01 trong quá trình bay.” (Rõ ràng việc cập nhật này đã khiến nhiều người trong dự án, luôn được nhắc đi nhắc lại rất nhiều lần rằng các phi hành gia sẽ không mắc bất kỳ sai lầm nào, cảm thấy cực kỳ thích thú - Bởi các phi hành gia đã được đào tạo để trở nên hoàn hảo rồi.)
Biện pháp bảo vệ mà Margaret đề xuất chỉ được coi là không cần thiết cho đến nhiệm vụ tiếp theo, trên Apollo 8, chỉ vài ngày sau khi cập nhật thông số kỹ thuật. Trong quá trình bay vào ngày thứ tư với sự có mặt của các phi hành gia Jim Lovell, William Anders và Frank Borman, Jim Lovell đã vô tình chọn P01 - xảy ra vào đúng ngày Giáng Sinh - gây ra rất nhiều rối loạn cho tất cả mọi người. Đây là một vấn đề quan trọng, vì trong trường hợp không có cách khắc phục, việc thiếu dữ liệu định vị có nghĩa là các phi hành gia sẽ không bao giờ có thể trở về. May mắn thay, việc cập nhật tài liệu trước đó đã đề cập rõ khả năng này và trở nên giá trị trong việc tìm ra cách tải lên dữ liệu có thể sử dụng và khôi phục nhiệm vụ trong một khoảng thời gian không nhiều để có thể lãng phí.
Như Margaret nói, “hiểu rõ cách vận hành hệ thống không đủ để ngăn ngừa lỗi do con người gây ra”. Sau đó, yêu cầu thay đổi phần mềm để thêm tính năng phát hiện lỗi và khôi phục vào chương trình tiền khởi động P-1 đã được chấp thuận.
Mặc dù sự cố Apollo 8 xảy ra cách đây nhiều thập kỷ, nhưng có rất nhiều điều liên quan trực tiếp đến cuộc sống của các kỹ sư ngày nay cũng như tiếp tục trong tương lai. Do đó, đối với các hệ thống mà bạn đang quản lý, các nhóm mà bạn đang làm việc và các tổ chức mà bạn đang xây dựng, hãy nhớ giữ góc nhìn SRE: sự cẩn thận và tận tâm, niềm tin vào giá trị của việc chuẩn bị, tài liệu, và nhận thức về những gì có thể gặp sự cố, kết hợp với mong muốn mạnh mẽ để ngăn chặn nó.
Chào mừng bạn đến với ngành nghề mới của chúng ta!