Bằng cách kết hợp những điều tưởng như mâu thuẫn, Google đã làm được điều kỳ diệu trên.
ảnh minh họa
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.
