Site Reliability Engineering
Part I. Introduction - Chapter 1 - Introduction
Phần I. Giới thiệu
Phần này sẽ cung cấp một số chỉ dẫn nâng cao về việc SRE là gì và tại sao nó khác biệt so với phần lớn các phương pháp trong ngành IT thông thường.
Ben Treynor Sloss, Phó Chủ tịch cấp cao chịu trách nhiệm về bộ phận kỹ thuật tại Google - và là người đặt ra thuật ngữ “Site Reliability Engineering” - đưa ra quan điểm của mình về ý nghĩa của SRE, cách hoạt động và sự so sánh với các phương pháp khác trong ngành công nghiệp, tại chương 1 - Introduction.
Chúng tôi cung cấp một hướng dẫn về môi trường production tại Google trong chương 2 - The Production Environment at Google, from the Viewpoint of an SRE, như một cách giúp bạn làm quen với vô số thuật ngữ và hệ thống mới mà bạn sẽ gặp trong phần còn lại của cuốn sách.
Chương 1 - Giới thiệu
Viết bởi Benjamin Treynor Sloss
Biên tập Betsy Beyer
“Hope is not a strategy.” - Traditional SRE saying
Có một sự thật chung mà ai cũng phải thừa đó là các hệ thống không thể tự vận hành bởi chính nó. Vậy hệ thống nên được điều hành như thế nào? Đặc biệt là một hệ thống tính toán phức tạp hoạt động ở quy mô lớn.
Service: một phần mềm sau khi được triển khai đến người dùng gọi là một dịch vụ.
Cách tiếp cận của System Admin đối với việc quản lý Service
Lịch sử cho thấy, các công ty đã thuê những người quản trị viên hệ thống (system administrator) để vận hành các hệ thống tính toán phức tạp.
Phương pháp tiếp cận của các system administrator, hay sysadmin, bao gồm việc kết hợp các thành phần của phần mềm hiện có và triển khai để chúng hoạt động cùng nhau cung cấp một service. Sysadmin được giao nhiệm vụ quản lý service, cập nhật và xử lý các sự kiện khi nó xảy ra. Khi hệ thống ngày càng phức tạp và lượng truy cập tăng, dẫn đến sự gia tăng tương ứng của các sự kiện và bản cập nhật, đội ngũ sysadmin mở rộng ra để tiếp nhận các công việc bổ sung. Vì vai trò sysadmin đòi hỏi một bộ kỹ năng khác biệt so với những gì yêu cầu từ các nhà phát triển sản phẩm, developer và sysdamin được chia thành hai nhóm riêng biệt: “development” và “operation/ops”.
Mô hình quản lý service của sysadmin có một số lợi ích. Đối với các công ty đang trong quá trình đưa ra quyết địch về cách vận hành và nhân sự cho một service, phương pháp này tương đối dễ triển khải: như một mô hình quen thuộc trong ngành công nghiệp, có rất nhiều ví dụ để học hỏi và mô phỏng. Có sẵn một nguồn nhân tài phù hợp ở mọi nơi. Có sẵn một loạt các công cụ phổ biến, các phần mềm và các công ty tích hợp để giúp vận hành những hệ thống được lắp ráp đó, nhóm các sysadmin sẽ không cần phải tạo ra một hệ thống từ đầu.
Phương pháp của sysadmin và sự chia tách development/ops kèm theo một số nhược điểm và rủi ro. Chúng có thể được chia thành hai loại chi phí: chi phí trược tiếp và chi phí gián tiếp.
Chi phí trực tiếp không phải là những khó nhận biết hay mơ hồ. Vận hành service với một đội ngũ dựa vào sự can thiệp thủ công để cập nhật và xử lý các vấn đề trở nên cực kỳ đắt đỏ khi nhu cầu service hoặc lượng truy cập tăng lên, bởi vì kích thước của đội ngũ sẽ phải tăng tỷ lệ với tải trọng lưu lượng do hệ thống tạo ra.
Chi phí gián tiếp của sự phân tách giữa development và ops có thể sẽ rất tinh vi, khó nhận ra, nhưng thường đắt đỏ cho tổ chức khi so sánh với chi phí trược tiếp. Những chi phí này phát sinh từ việc hai nhóm này khác nhau về lý lịch, kỹ năng và động cơ. Họ sử dụng từ ngữ khác nhau để miêu tả tình huống; họ mang những giả định khác nhau về cả rủi ro, khả năng và giải pháp kỹ thuật; họ có những giả định khác nhau về mức độ ổn định sản phẩm mục tiêu. Sự chia rẽ giữa hai nhóm có thể dễ dàng trở thành một vấn đề không chỉ về động cơ, mà còn về giao tiếp, mục tiêu và cuối cùng là niềm tin và sự tôn trọng. Hậu quả này là một bệnh lý.
Các đội ngũ vận hành (ops) truyền thống và đối tác của họ trong quá trình phát triển sản phẩm thường xuyên rơi vào tình huống xung đột, rõ nhất là trong việc phát hành phần mềm nhanh chóng lên môi trường production. Trong khi đội ngũ phát triển (developement) mong muốn triển khai một tính năng mới và nhìn thấy người dùng sử dụng chúng thì đội ngũ vận hành (operation) sẽ muốn đảm bảo service không gặp sự cố. Bởi vì hầu hết sự cố xảy ra do một loại thay đổi nào đó - cấu hình mới, tính năng mới được triển khai, hoặc một lượng người dùng mới - mục tiêu của hai đội ngũ này căn bản là đối nghịch nhau.
Cả hai nhóm đều hiểu rằng việc tuyên bố lợi ích của họ một cách thẳng thừng là không thể chấp nhận được (“Chúng tôi muốn phát triển bất cứ thứ gì, bất cứ lúc nào, mà không gặp trở ngại” so với “Chúng tôi không muốn thay đổi bất cứ điều gì trong hệ thống sau khi nó hoạt động”). Và do từ vựng và giả định về rủi ro khác nhau, cả hai nhóm thường phải sử dụng chiến thuật giao tranh hàng rào quen thuộc để thúc đẩy lợi ích của mình. Nhóm operation cố gắng bảo về hệ thống đang hoạt động khỏi rủi ro thay đổi bằng cách đưa ra các rào cản cho việc thay đổi. Ví dụ, các đánh giá để launch hoặc change có thể chứa tất cả mọi vấn đề từng gây ra sự cố trong quá khứ - đó có thể là một danh sách với độ dài tùy ý, nhưng không phải tất cả các yếu tố trong đó đều mang lại giá trị tương đương. Nhóm development sẽ nhanh chóng thích nghi. Họ sẽ có ít các “launch” và nhiều “flag flips”, “incremental updates” hay “cherrypicks” hơn. Họ áp dụng các chiến thuật tách vỡ sản phẩm để ít phải tuân thủ các đánh giá khi launch.
Cách tiếp cận của Google đối với việc quản lý Service
Xung đột không phải là một điều gì đó không thể giải quyết trong việc cung cấp dịch vụ phần mềm. Google đã chọn cách tiếp cận khác để vận hành hệ thông của chúng tôi: các nhóm Site Reliability Engineering của chúng tôi tập trung vào việc tuyển dụng những software engineer để vận hành các sản phẩm và tạo ra hệ thống để hoàn thành công việc mà trước đây thường được thực hiện bằng cách thủ công bởi sysadmins.
Vậy chính xác Site Reliability Engineering (SRE) tại Google là gì? Lời giải thích của tôi rất đơn giản: SRE là kết quả khi bạn yêu cầu một kỹ sư phần mềm thiết kế một nhóm vận hành. Khi tôi gia nhập Google vào năm 2003 và được giao nhiệm vụ quản lý một “Production Team” gồm bảy kỹ sư, cuộc đời của tôi cho đến thời điểm đó đã hoàn toàn là về software engineering. Vì vậy, tôi đã thiết kế và quản lý đội ngũ theo cách mà tôi muốn nếu như tôi làm việc như một SRE. Nhóm đó đã trưởng thành và trở thành đội ngũ SRE của Google ngày nay, với bản sắc được hình dung như một software engineer.
Một phần chính xây dựng nên phương pháp quản lý service của Google đó là cấu trúc của từng nhóm SRE. Tổng quan, các SRE có thể được chia thành hai kiểu chính.
50-60% là những Google Software Engineer, hoặc chính xác hơn, là những người đã được tuyển dụng qua quy trình tiêu chuẩn cho Software Engineer tại Google. 40-50% còn lại là những ứng cử viên gần như đạt đủ tiêu chuẩn Google Software Engineering (85-99% các kỹ năng yêu cầu), và có một bộ kỹ năng kỹ thuật có ích cho SRE, điều thường hiếm gặp đối với hầu hết các software engineer. Cho đến nay, kiến thức bên trong hệ thống UNIX và mạng máy tính (từ Layer 1 đến Layer 3) là hai loại kỹ năng kỹ thuật thay thế phổ biến nhất mà chúng tôi tìm kiếm.
Điểm chung cho tất cả các SRE là niềm tin và khả năng phát triển hệ thống phần mềm để giải quyết các vấn đề phức tạp. Bên trong nhóm SRE, chúng tôi theo dõi quá trình phát triển sự nghiệp của cả hai kiểu một cách cẩn thận và cho đến nay không tìm thấy sự khác biệt thực tế về mặt hiệu suất giữa các kỹ sư từ hai lĩnh vực khác nhau này. Trên thực tế, sự đa dạng và phong phú của đội ngũ SRE thường tạo nên các hệ thống thông minh, chất lượng cao, đây rõ ràng là kết quả của việc tổng hợp từ nhiều bộ kỹ năng khác nhau từ nhiều lĩnh vực.
Kết quả của việc tuyển dụng SRE theo phương pháp của chúng tôi là có được một đội ngũ những người (a) sẽ nhanh chóng trở nên buồn chán khi thực hiện các nhiệm vụ bằng tay và (b) có bộ kỹ năng cần thiết để viết phần mềm thay thế công việc trước đây phải làm thủ công, hoặc các giải pháp phức tạp. SRE cũng có xu hướng chia sẻ nền tảng học thuật và tri thức với phần còn lại của một tổ chức đang phát triển. Do đó, SRE về cơ bản đang làm công việc mà trước đây đã được thực hiện bởi một nhóm operation, nhưng lại sử dụng các kỹ sư có chuyên môn về phần mềm, và đặt cược vào việc những kỹ sư này có khuynh hướng và khả năng tự nhiên để thiết kế và triển khai tự động hóa bằng phần mềm để thay thế sức lao động của con người.
Theo định hướng, việc tập trung vào engineering là rất quan trọng đối với nhóm SRE. Nếu không có sự liên tục trong việc ứng dụng engineering, khi tải trọng vận hành tăng lên, đội ngũ sẽ cần nhiều người hơn mới có thể đáp ứng khối lượng công việc. Dẫn đến nhóm vận hành truyền thống phải mở rộng theo quy mô tuyến tính với kích thước service: nếu sản phẩm được hỗ trợ bởi service thành công, tải trọng vận hành sẽ tăng lên theo lưu lượng truy cập, xử lý. Điều đó có nghĩa là cần tuyển thêm nhân viên để thực hiện những nhiệm vụ tương tự lặp đi lặp lại.
Để tránh tình trạng đó, nhóm được giao nhiệm vụ quản lý service cần phải có kỹ năng lập trình, nếu không sớm muộn cũng sẽ bị “đắm tàu”. Vì vậy, Google đặt một giới hạn 50% công việc “ops” tổng hợp của tất cả các SRE - các yêu cầu hỗ trợ, trực điện thoại, thao tác thủ công… Giới hạn này đảm bảo rằng nhóm SRE có đủ thời gian trong lịch trình của họ để làm cho dịch vụ ổn định và có thể vận hành. Giới hạn này là một giới hạn trên; theo thời gian, nếu có thể tự chủ, nhóm SRE sẽ chỉ còn ít công việc vận hành và gần như hoàn toàn tham gia vào các nhiệm vụ “development”, bởi vì service về cơ bản có thể chạy và tự sử chữa: chúng tôi muốn các hệ thống hoàn toàn tự động (automatic), chứ không chỉ là tự động hóa công việc (automated). Trong thực tế, SRE sẽ liên tục đối mặt với những thách thức về quy mô và triển khai các tính năng mới.
Nguyên tắc cơ bản của Google là một đội ngũ SRE phải dành 50% thời gian còn lại để thực sự phát triển. Vậy làm thế nào chúng ta có thể thiết lập ngưỡng này? Trước tiên, chúng ta phải đo lường cách SRE sử dụng thời gian. Dựa trên kết quả đo lường đó, đảm bảo rằng các nhóm luôn dành ít hơn 50% thời gian của họ cho công việc phát triển để thay đổi phương pháp làm việc của mình. Thường thì điều này có nghĩa là chuyển gánh nặng vận hành (operation) một phần trở lại cho nhóm phát triển (development), hoặc tăng cường nhân sự cho nhóm mà không bị giao thêm trách nhiệm vận hành cho nhóm đó. Việc duy trì cân bằng này giữa công việc ops và dev cho phép chúng ta đảm bảo rằng các SRE có khả năng tham gia vào việc kỹ thuật sáng tạo và tự chủ, trong khi vẫn giữa được những kiến thức quý giá từ phía vận hành service.
Chúng tôi nhận thấy rằng phương pháp quản lý hệ thống quy mô lớn của Google SRE mang lại nhiều lợi ích. Vì SRE trực tiếp chỉnh sửa code trong quá trình nỗ lực để hệ thống của Google tự chạy, các nhóm SRE sẽ có đặc trưng về việc đổi mới nhanh chóng và sự chấp nhận các thay đổi lớn. Các đội ngũ như vậy có chi phí tương đối thấp - để hỗ trợ cùng một service bằng một nhóm chỉ tập trung vào operation sẽ yêu cầu một số lượng người đáng kể lớn hơn rất nhiều. Thay vào đó, số lượng SRE cần thiết để quản lý, duy trì và cải tiến một hệ thống tỉ lệ thuận nhỏ hơn với kích thước của hệ thống. Cuối cùng, không chỉ SRE tránh được sự kém hiệu quả của việc chia tách dev/ops, mà cấu trúc này còn cải thiện các nhóm phát triển sản phẩm của chúng tôi: chuyển đổi dễ dàng giữa các nhóm phát triển sản phẩm và SRE, đào tạo chéo lẫn nhau, cải thiện kỹ năng của những nhà phát triển gặp khó khăn trong việc học cách xây dựng một hệ thống phân tán hàng triệu lõi (million-core distributed system).
Mặc dù có những lợi ích rõ rệt, mô hình SRE cũng mang theo một loạt thách thức riêng. Một trong những thách thức liên tục mà Google đối mặt là việc tuyển dụng SREs: không chỉ có SRE cạnh tranh với các ứng viên giống như quy trình tuyển dụng phát triển sản phẩm, mà việc chúng tôi đặt mức tiêu chuẩn tuyển dụng cao về cả kỹ năng lập trình và kỹ thuật hệ thống khiến cho số lượng ứng viên tiềm năng rất hạn chế. Vì chúng ta là một lĩnh vực tương đối mới và độc đáo, nên không có nhiều thông tin trong ngành công nghiệp về cách xây dựng và quản lý một nhóm SRE (mặc dù hy vọng cuốn sách này sẽ đóng góp cho hướng đi đó!). Và khi đã có một nhóm SRE, cách tiếp cận khác truyền thống của họ đối với việc quản lý các service yêu cầu sự hỗ trợ mạnh mẽ từ bên quản lý. Ví dụ, quyết định dừng release trong phần còn lại của quý nếu không còn error-budget sẽ không được chào đón bởi nhóm developement trừ khi nó được yêu cầu bởi quản lý của họ.
Mức thời gian ngừng hoạt động được gọi là ngân sách lỗi (error-budget), là số lỗi tối đa cho phép trong hệ thống.
DevOps or SRE?
Thuật ngữ "DevOps" đã xuất hiện trong ngành công nghiệp vào cuối năm 2008 và đến thời điểm viết bài này (đầu năm 2016), nó vẫn đang trong quá trình thay đổi. Những nguyên tắc cốt lõi của nó - sự tham gia của chức năng CNTT trong mỗi giai đoạn của thiết kế và phát triển hệ thống, sự phụ thuộc mạnh mẽ vào tự động hóa thay vì công sức của con người, áp dụng các giải pháp thực tiễn và công cụ kỹ thuật vào nhiệm vụ vận hành - tương đồng với nhiều nguyên tắc và thực tiễn của SRE. Có thể coi DevOps như một sự tổng quát hóa một số nguyên tắc cốt lõi của SRE ở quy mô rộng hơn của các tổ chức, cấu trúc quản lý và nhân viên.
So sánh theo cách tương đương, SRE có thể được coi là một implementation cụ thể của DevOps với một số mở rộng độc đáo.