Đây là cách Google đảm bảo rằng dịch vụ của mình không bao giờ sập

Lần gần nhất bạn cần tra Google nhưng truy cập được vào website là khi nào?

Bạn chẳng thể nhớ nổi đâu. Đúng là có lúc bạn không thể vào Google vì mạng nhà mình bị đứt. Nhưng các dịch vụ trực tuyến của Google, từ cỗ máy tìm kiếm trứ danh đến Gmail và Google Docs, gần như luôn truy cập được. Theo số liệu của công ty, các ứng dụng của Google truy cập được 99,97% thời gian trong năm 2015. Thế giới nghĩ điều này là chuyện đương nhiên, nhưng đằng sau đó là một kỳ công. Có bao giờ hàng tỷ người dùng của Google chịu dừng lại để nghĩ xem làm thế nào Google đã biến một điều quá đỗi ấn tượng như vậy trở nên thật bình thường.

Google giải thích kỳ công này bằng ba từ: Site Reliability Engineering – SRE (Kỹ thuật ổn định website). Đằng sau ba từ nghe có vẻ bình thường này là một triết lý có ảnh hưởng sâu rộng, ra đời hơn 10 năm về trước. Đó là một triết lý tinh tế và nhiều ảnh hưởng, được dựa trên một ý tưởng đặc biệt: Đừng để nhân viên chuyên về vận hành dịch vụ Internet vận hành dịch vụ Internet. Hãy để các lập trình viên phần mềm vận hành chúng. Nếu bạn làm như vậy, mọi thứ sẽ thành thế này: các lập trình viên phần mềm sẽ tạo ra một công cụ để vận hành website mà không cần tác động trực tiếp của con người.

“Cách nghĩ này đã đưa chúng tôi thành lập một đội mà nhanh chóng trở nên chán nản với việc làm nhiệm vụ của họ một cách thủ công. Vì thế, họ viết phần mềm tự vận hành để thay thế công việc thủ công của họ”, Ben Treynor Sloss, phó chủ tịch phụ trách kỹ thuật của Google cho biết.

Đối với nhiều công ty ở Thung lũng Silicon, đây dường là một trào lưu phổ biến. Phương pháp này đang được thực hiện ở khắp nơi trong giới công nghệ, từ Amazon cho đến Box.com. Người ta gọi nó là DevOps – “development” (phát triển) cộng với “operations” (vận hành). Đây là nỗ lực kết hợp khả năng của lập trình viên phần mềm với mục đích của nhân viên quản trị hệ thống. Nhưng trào lưu DevOps, đại diện bởi các công cụ như Chef và Puppet, đã phát triển một cách độc lập với triết lý SRE của Google. Đó là vì Google đã giữ im lặng về triết lý này trong 10 năm qua. Họ thường làm vậy khi được hỏi về hoạt động của nhóm vận hành website tài ba của mình.

Nhưng Google đã bước vào một giai đoạn mới. Trong đó, Google sẵn sàng công khai quan điểm của mình nhiều hơn. Chủ yếu là vì Google muốn thúc đẩy dịch vụ đám mây, mà cho phép các doanh nghiệp bên ngoài vận hành phần mềm của mình dựa trên mạng lưới trung tâm dữ liệu và máy móc khổng lồ của công ty. Google thậm chí đã đi xa đến mức viết một cuốn sách về SRE.

Tất nhiên tiêu đề của cuốn sách này cũng là Site Reliability Engineering. Nó được xuất bản bởi O’Reilly, và bài luận của Sloss được dùng làm chương đầu tiên. Nếu bạn muốn tìm hiểu về DevOps, đây là một cuốn sách phải đọc. Cuốn sách sẽ đem lại cho bạn cái nhìn thú vị về những động lực đã giúp phát triển đế chế online lớn nhất thế giới như ngày hôm nay.

Với nhiều người trong giới công nghệ, quản trị hệ thống là thứ chẳng đáng quan tâm, một trong những khía cạnh tẻ nhạt nhất của công nghệ máy tính. Nhưng Sloss đã bác bỏ quan điểm này. Ông lập luận rằng độ ổn định của một website là “đặc điểm cơ bản nhất của mọi sản phẩm”. Suy cho cùng, “một hệ thống sẽ chẳng có ý nghĩa gì nếu không ai có thể sử dụng nó”.

Thay đổi nhận thức

Sloss bắt đầu xây dựng SRE từ con số không. Mọi chuyện bắt đầu khi Google thuê ông để vận hành website cho công ty, và cũng chính ông là người nghĩ ra thuật ngữ SRE. “SRE ra đời khi bạn bảo một kỹ sư phần mềm thiết kế một đội vận hành website”, ông nói. “Tôi đã thiết kế và quản lý nhóm trên cơ sở tự đặt mình vào vị trí của họ”.

Đối với Todd Underwood, giám đốc SRE hiện tại của Google, là lẽ tự nhiên khi công ty thuê một lập trình viên như Sloss cho công việc này. “Khi Google còn đang trong thời kỳ sơ khai, có nhiều kỹ sư phần mềm của công ty hiểu được tại sao website lại gặp trục trặc và biết cách khắc phục chúng. Nhưng không có ai muốn làm điều đó một cách thủ công”, ông nhớ lại.

Điều đó giống như một phần văn hóa của công ty. Nhưng Adam Jacob, giám đốc công nghệ của Chef lại đồng tình với suy nghĩ của các lập trình viên trên. Ông giải thích rằng điều này thường xảy ra khi website phát triển đến một quy mô lớn như vậy. “Dễ hiểu tại sao người ta muốn kết hợp phần mềm với việc vận hành website. Khi bạn nhìn nhận vấn đề một cách bao quát, bạn sẽ có kết quả tốt hơn”.

Sự thay đổi trong nhận thức này là điều đặc biệt thú vị vì phát triển và vận hành phần mềm thường là những lĩnh vực đối lập nhau. Phía phát triển muốn tạo ra phần mềm mới hoặc những thay đổi mới và muốn chúng được triển khai càng sớm càng tốt. Nhưng phía vận hành lại muốn đảm bảo rằng mọi thứ hoạt động suôn sẻ và cách tốt nhất để làm điều đó là giữ những thay đổi ở mức tối thiểu. “Đây là những mục tiêu đối lập nhau”, Underwood nói. “Giải pháp là nếu kết hợp phát triển và vận hành, bạn có thể loại bỏ sự mâu thuẫn giữa hai bên”.

Chấp nhận sai sót

Nhằm giảm thiểu xung đột giữa bên phát triển và bên vận hành, công ty không cố vận hành website 100% thời gian. Sloss cho biết thực tế là một dịch vụ Internet không cần phải truy cập được 100% thời gian. Người dùng không thể phân biệt được sự khác nhau giữa thời gian hoạt động 100% và 99,999% (laptop, WiFi, điện, hay ISP không hoạt động trong 0,0001% thời gian). Nếu công ty đặt ra mục tiêu hoạt động dưới 100% - một “ngân sách sai sót”, công ty sẽ có nhiều không gian để thực hiện những thay đổi và thử nghiệm.

“Việc chấp nhận sai sót sẽ giúp khắc phục được sự mâu thuẫn về mục đích giữa bên phát triển và vận hành”, Sloss nói. ““Sập” không phải là một điều xấu. Đó là một phần của quy trình cải tiến và là một dịp để nhóm phát triển và vận hành thử nghiệm các phương án mới thay vì sợ hãi”.

Google đã đặt ra những quy định đảm bảo rằng các kỹ sư vận hành sẽ không trở thành những nhân viên quản trị hệ thống kiểu cũ. Về cơ bản, công ty yêu cầu kỹ sư vận hành không được dành hơn 50% thời gian cho hoạt động vận hành truyền thống. Nếu các kỹ sư vận hành bắt đầu làm nhiều việc hơn các kỹ sư phát triển phần mềm trong một đội SRE, Google sẽ chuyển bớt việc của kỹ sư vận hành cho kỹ sư phát triển phần mềm. “Việc duy trì sự cân bằng giữa công việc vận hành và phát triển phần mềm giúp đảm bảo rằng các đội SRE có đủ thời gian để phát huy khả năng sáng tạo và cải tiến của mình”, Sloss nói.

Jacob cho biết tỷ lệ 50% ở đây không phải là điều quan trọng. Cái ông thích là triết lý của Google. “Các công ty vẫn hay yêu cầu nhân viên phải làm công việc vận hành hệ thống tẻ nhạt. Họ thường yêu cầu nhân viên làm quá nhiều công việc này. Vì thế phải có cơ chế giới hạn công việc của họ”, ông nói.

Google thậm chí đã lập ra các quy định tuyển dụng riêng các nhóm SRE. Công ty tuyển từ 50 đến 60% thành viên trong nhóm theo như quy trình với các kỹ sư phần mềm bình thường khác của Google. Số còn lại sẽ phải có khoảng “85-90% kiến thức giống với những người được tuyển trước đó – cộng thêm những kỹ năng hiếm đối với kỹ sư phần mềm, như kiến thức về hệ điều hành UNIX hay giao thức mạng phần cứng. Điều này nhằm đảm bảo sự cân bằng giữa các kỹ sư phần mềm và kỹ sư vận hành.

Cảm hứng đến từ mặt trăng

Trên nhiều phương diện, đây là một triết lý mới. Nhưng trong cuốn sách của mình, Google tiết lộ họ đã lấy cảm hứng từ một hình mẫu ở thế kỷ trước. Người đã truyền cảm hứng cho triết lý SRE của Google là Margaret Hamilton, một lập trình viên của đại học MIT. Bà là người đã phát triển phần mềm cho tàu vũ trụ Apollo mà sau này đã hạ cánh xuống mặt trăng. Hamilton nói văn hóa của nhóm phát triển Apollo là “học hỏi từ tất cả mọi người và tất cả mọi thứ, gồm cả những điều mà người ta cho là chẳng liên qua”.

Hamilton là một lập trình viên. Nhưng bà cũng đóng vai trò trong việc vận hành phần mềm. Để chứng mình điều này, cuốn sách của Google đã nhắc lại sự việc về con gái của Hamilton. Cô bé thường đến phòng thí nghiệm của mẹ và vô tình nhấn một nút cài chương trình trước hạ cánh của tàu Apollo vào một máy tính chạy chương trình sau hạ cánh.

Việc này đã làm chương trình gặp trục trặc, và Hamilton nhận ra là phải bổ sung một lệnh kiểm tra lỗi cho hệ thống nhằm tự động ngăn chặn lỗi khi tàu được phóng trên thực tế. Cấp trên của bà đã bác bỏ ý tưởng trên và cho rằng các phi hành gia sẽ chẳng bao giờ vô tình phạm sai lầm như con gái bà. Nhưng trên tàu Apollo 8, các phi hành gia đã làm điều đó. May là Hamilton đã cài thêm phần mềm sửa lỗi vào trong hệ thống. Và trong các chương trình phóng tàu sau này, bà đã bổ sung thêm lệnh kiểm tra lỗi.

Đó chính là tinh thần của DevOps, mà theo cách nói của Google là Site Reliability Engineering. Ba từ này nghe thì có vè tầm thường nhưng thực ra là một ý tưởng đầy quyền năng. Ý tưởng này đã giúp tạo ra Google như ngày hôm nay. Nhưng những người thấm nhuần triết lý SRE như Underwood còn có một tham vọng lớn hơn. Ông nghĩ về một thế giới mà việc vận hành sẽ được giao cho những dòng lệnh lập trình. “Chúng tôi luôn mong về ngày đó, khi mọi thứ được vận hành mà không cần ai nhúng tay vào”, Underwood nói.

Tham khảo: wired.com