Rất may, vì Kỹ thuật Độ tin cậy Trang web được phát triển nội bộ tại Google và chỉ gần đây mới bắt đầu tham gia vào cộng đồng rộng lớn hơn, nên nó được xác định khá rõ. Tuy nhiên, điều không phải là các hoạt động web (hoặc "quản trị hệ thống" - như một ví dụ về sự thiếu rõ ràng, bạn sử dụng cả hai trong câu hỏi của mình). Thật khó để thảo luận về sự khác biệt giữa hai điều khi bạn không hoàn toàn chắc chắn một trong số chúng là gì.
Nhưng tôi là một người thích phiêu lưu, vì vậy tôi sẽ thử.
Trong các cửa hàng rất truyền thống, các nhà phát triển và sysadins rất im lặng với nhau. Các nhà phát triển xây dựng một ứng dụng, sau đó xem xét công việc của họ hoàn thành ngay khi mã của họ được cam kết. Các sysadins lấy các tạo phẩm xây dựng (có thể chỉ là mã, nếu đó là ngôn ngữ được giải thích) và triển khai nó đến các máy chủ sản xuất. Đó là công việc của các sysadins để giữ cho ứng dụng hoạt động trơn tru và nói chung quản lý môi trường sản xuất. Tuy nhiên, thường các vấn đề về hiệu suất đến từ các vấn đề kiến trúc trong ứng dụng; các hệ thống không có kiến thức lập trình để biết ứng dụng đang làm gì và các nhà phát triển không biết ứng dụng này hoạt động như thế nào trong cấu trúc liên kết sản xuất với lưu lượng sản xuất, vì vậy không ai được trang bị để giải quyết vấn đề.
Ngoài ra, các nhà phát triển thường được đánh giá về việc họ có thể tạo ra các tính năng mới nhanh như thế nào, trong khi các hệ thống được đánh giá dựa trên mức độ không thường xuyên của ứng dụng trong sản xuất. Vì sự thay đổi là một trong những nguyên nhân hàng đầu của sự đổ vỡ, điều này khiến hai bộ phận bất hòa với nhau - một sự ganh đua cũ làm tổn thương doanh nghiệp và những người liên quan.
Tại một số thời điểm, một số công ty tập trung vào nhà phát triển đã rất bực mình vì điều này đến nỗi họ bắt đầu thực hành "NoOps" - họ đã loại bỏ các bộ phận hoạt động của họ và các rào cản nhận thức đi kèm với họ. Trong thực tế, điều này có nghĩa là các nhà phát triển đảm nhận vai trò hoạt động, nhưng vẫn duy trì các tiêu đề cũ của họ.
Trong một cuộc thảo luận xung quanh NoOps , John Allspaw, sau đó là Phó Giám đốc Điều hành Kỹ thuật tại Etsy và một biên tập viên của cuốn sách Hoạt động Web được kính trọng , đã xác định vai trò tại Etsy theo cách này:
Hoạt động của Etsy chịu trách nhiệm:
- Ứng phó với cúp điện, nhận cuộc gọi
- Hệ thống cảnh báo ngưỡng, thiết kế
- Thiết kế và xem xét kiến trúc
- Xây dựng bộ sưu tập số liệu
- Cấu hình ứng dụng
- Xây dựng / quản lý cơ sở hạ tầng
Etsy Development chịu trách nhiệm:
- Ứng phó với cúp điện, nhận cuộc gọi
- Hệ thống cảnh báo ngưỡng, thiết kế
- Thiết kế và xem xét kiến trúc
- Xây dựng bộ sưu tập số liệu
- Cấu hình ứng dụng
- Vận chuyển mã công khai
Cả hai danh sách này đều không đầy đủ, tôi chắc chắn tôi đang thiếu thứ gì đó ở đó. Mặc dù Etsy Ops đã thực hiện các thay đổi ứng dụng đối với sản xuất, nhưng chúng rất ít nhưng thực tế (và đôi khi khá sâu sắc). Trong khi Etsy Dev làm Chef thay đổi, chúng rất ít nhưng có thật. Nếu có quá nhiều trách nhiệm chồng chéo, tại sao sự khác biệt, bạn có thể hỏi? Chuyên môn tên miền và nền tảng. Không có nhiều Dev có kiến thức sâu về cách TCP hoạt động chậm, nhưng Ops thì có. Không có nhiều Ops có kiến thức toàn diện về các thuật toán sắp xếp hoặc liên quan, nhưng Dev thì có. Ops có nhiều năm kinh nghiệm trong việc dự báo sử dụng tài nguyên một cách nhanh chóng với độ chính xác chấp nhận được, Dev thì không. Nhà phát triển có thể không nhận thức được những ưu và nhược điểm của việc phân phối các tùy chọn khối lượng công việc trên tất cả các lớp1-7, có thể chỉ ở mức 7, Ops không. Mô hình hóa mối quan hệ thực thể có thể trở nên tự nhiên đối với một nhà phát triển, nó có thể không hoạt động. Cuối cùng, cả hai đều khám phá ra các giải pháp cho các dạng khác nhau của kịch bản thất bại Byzantine và các mẫu khả năng phục hồi, ở tất cả các tầng và lớp.
Trong thế giới của anh ấy, các nhà phát triển và kỹ sư op có bộ kỹ năng và trách nhiệm cấp cao rất giống nhau; nơi họ khác nhau là trong chuyên môn của họ. Các chuyên ngành khác nhau của họ khuyến khích họ làm việc cùng nhau để giải quyết các vấn đề và các kỹ năng cơ bản chung của họ đã cho họ một ngôn ngữ để thực hiện điều đó.
Đây thường là định nghĩa của các hoạt động web mà tôi sử dụng cho hầu hết các trường hợp. Vì vậy, đó là người chúng ta sẽ tiếp tục cùng.
Vậy thì, Kỹ thuật Độ tin cậy Trang web là gì?
Cuốn sách Google SRE mở ra với định nghĩa về SRE ... và sau đó là một cuốn khác ... và sau đó dành một chương tiếp tục xác định vai trò và toàn bộ cuốn sách bao gồm các chi tiết cụ thể. Ngay cả khi được phát triển trong một tổ chức, có vẻ như rất khó để cô đọng công việc theo một định nghĩa đã được thống nhất.
Để bắt đầu, chúng ta cần quay trở lại năm 2003, khi Ben Khaynor gia nhập Google và thành lập nhóm trở thành nhóm Kỹ thuật Độ tin cậy Trang web đầu tiên. Hãy nhớ lại rằng một vài đoạn trước chúng ta đã ở đầu những năm 2010; nhưng vào năm 2003, ngành công nghiệp này vẫn được thiết lập dựa trên sự phân chia sysadmin / nhà phát triển như là cách tự nhiên của mọi thứ. Vì vậy, khi Ben nói rằng SRE là điều sẽ xảy ra nếu một kỹ sư phần mềm tạo ra một nhóm vận hành, đây là một sự pha trộn triệt để hơn nhiều của hai thế giới so với hiện tại.
Định nghĩa được đưa ra trong lời nói đầu nhấn mạnh từng từ trong ba từ riêng lẻ:
- Kỹ thuật - việc sử dụng các khái niệm khoa học và kỹ thuật máy tính để giải quyết các vấn đề
- Độ tin cậy - tập trung vào việc làm cho các hệ thống có khả năng mở rộng hơn, đáng tin cậy hơn và hiệu quả hơn
- Dịch vụ - sự phát triển sau này của "trang web", nhấn mạnh rằng các SRE chịu trách nhiệm về các dịch vụ được kết nối mạng
Chương giới thiệu liệt kê các nguyên lý của Kỹ thuật Độ tin cậy Trang web là:
- Đảm bảo sự tập trung lâu dài vào kỹ thuật - thực hiện hành động phủ đầu để tránh các trang thường xuyên và "công việc" khác
- Duy trì vận tốc thay đổi tối đa mà không vi phạm SLO của dịch vụ - một chủ đề có thể dễ dàng có câu trả lời hàng trăm từ của riêng mình, nhưng tóm tắt là giúp các nhà phát triển thực hiện thay đổi, miễn là họ không gây ra quá nhiều vấn đề
- Giám sát - cảnh báo tự động khi có sự cố
- Ứng phó khẩn cấp - sửa chữa mọi thứ khi chúng bị hỏng
- Thay đổi cách quản lý
- Kế hoạch năng lực
- Dự phòng
- Hiệu quả và hiệu suất - đảm bảo rằng một dịch vụ hoạt động ở mức mong đợi - tắc nghẽn gây tổn thương cho người dùng, nhưng vượt quá khả năng chi phí
Tôi đã phân loại Kỹ thuật Độ tin cậy Trang web như một tập hợp con chuyên biệt của Hoạt động Web hiện đại. Một tổ chức SRE tập trung rất nhiều vào việc tự động hóa mọi thứ , đến một mức độ chỉ hiệu quả về chi phí trong các công ty khá lớn. Các ý tưởng như ngân sách lỗi chỉ có thể hoạt động khi dịch vụ của bạn có nhiều, nhiều yêu cầu, vì nếu không, bạn sẽ mất độ chi tiết (đối với dịch vụ nhỏ hơn, một lỗi cụ thể có thể ảnh hưởng đến 0-20% yêu cầu của bạn, tùy thuộc vào phút). Các lĩnh vực liên quan như bảo mật không có trong định nghĩa SRE vì các công ty đủ lớn để có các đội SRE thực sự có các nhóm chuyên trách về bảo mật.
Chương trình SRE, theo định nghĩa của Google, là các web op được phát triển cho các nhu cầu cụ thể của Google và không nhất thiết phải áp dụng ở nơi khác.
Tuy nhiên, Kỹ thuật Độ tin cậy Trang web đã được mở rộng trong việc sử dụng công nghiệp rộng rãi hơn gần đây. Chức danh công việc hiện tại của tôi là SRE, mặc dù tôi làm việc tại một công ty nhỏ hơn nhiều và mô tả công việc của tôi khá phù hợp với định nghĩa ops web Etsy 2012 của John Allspaw. Lý thuyết của tôi là chúng tôi đã tiến bộ thông qua các tiêu đề như một cách viết tắt để thúc đẩy sự phát triển của một lĩnh vực duy nhất:
- Chúng tôi bắt đầu như sysadmin .
- Sau đó, khi các trang web trở thành một "thứ", các bài đăng công việc bắt đầu đề cập đến các kỹ sư vận hành web để phân biệt các sysadins chuyên về web với những người cũng xử lý CNTT văn phòng nói chung.
- Sau đó, DevOps có nhiệm vụ tách những người thoải mái sử dụng lập trình để giảm khối lượng công việc của họ.
- Nhưng khi DevOps bị rối loạn vì thiếu một định nghĩa rõ ràng , chúng tôi đã thông qua Kỹ thuật Độ tin cậy Trang web để xác định rằng chúng tôi đang tìm kiếm những người đang hỗ trợ các dịch vụ sản xuất theo yêu cầu.
Vì vậy, sự khác biệt giữa một sysadmin và SRE là gì? Năm mà họ nhận được danh hiệu của họ. Sự khác biệt giữa các hoạt động truyền thống và kỹ thuật độ tin cậy trang web là gì? SRE chỉ đơn thuần là sự hiện thân của các ops, sử dụng các công cụ mới (xin chào, container!) Và, khi các chương trình nối mạng tiếp tục trở nên lớn hơn và quan trọng hơn, tập trung vào các thực hành cho phép một kỹ sư làm được nhiều hơn .