DevOps vs SRE vs Kỹ sư hỗ trợ sản xuất


7

DevOps chủ yếu tập trung vào Tốc độ phân phối và SRE tập trung vào Độ tin cậy trong sản xuất, nhưng Kỹ sư hỗ trợ sản xuất phù hợp với ai cũng tập trung vào giám sát sản xuất, cảnh báo, hiệu suất, trải nghiệm người dùng, quản lý sự cố, RCA và làm việc về lỗi mã và hiểu chức năng kinh doanh?

  • Trong một thế giới SRE, các kỹ sư hỗ trợ sản xuất sẽ phù hợp hơn với SRE hoặc sáp nhập với SRE?

In a SRE world, would production support engineers be more aligned to SRE or merged with SRE?- Các kỹ sư PS sẽ hợp nhất với SRE.
KatariaA

Câu trả lời:


4

Câu trả lời tốt nhất cho DevOps vs SRE là ở đây Sự khác biệt giữa DevOps và SRE là gì? Từ loạt bài trên, bạn sẽ hiểu Class SRE thực hiện DevOps và cả hai đều đang làm việc trên một nền tảng tương tự và đó là mục tiêu khá phù hợp cho cả hai.

Là một hỗ trợ sản xuất, bạn sẽ thực hiện nhiệm vụ mà bạn đã đề cập trong câu hỏi, ngoài ra, bạn cần có tầm nhìn sâu, cảnh báo và thông báo, độ trễ, số liệu, theo dõi, bảo mật, v.v ... rất nhiều điều cần quan tâm. Và, về cơ bản, nó cung cấp dịch vụ cho người dùng cuối đang sử dụng ứng dụng hoặc hệ thống của bạn. Ngoài ra, tôi thấy nhóm hỗ trợ sản xuất đã viết các kịch bản dockerfile và bash để tự động hóa nhiều tác vụ. Vì vậy, bất cứ khi nào người dùng gặp phải bất kỳ vấn đề nào đầu tiên xảy ra với nhóm Hỗ trợ sản xuất và nó có thể chuyển sang các nhóm CNTT khác nếu điều đó không dễ dàng giải quyết. Nhưng, nếu bạn nhìn vào SRE, mục đích duy nhất của họ là giữ cho hệ thống luôn ở trạng thái đáng tin cậy, duy trì khả năng phục hồi, v.v. Trong một số tổ chức, DevOps cũng thực hiện phần này.

Từ quan điểm của tôi, tất cả ba thuật ngữ đều giống như mục tiêu của chúng và chỉ khác nhau về chức năng. Các chức năng này khác nhau từ tổ chức để tổ chức. Nhưng, DevOps được dự định mang lại văn hóa và sự thay đổi trong mô hình để mọi người sẽ hợp tác làm việc. Hi vọng điêu nay co ich.


4

Tôi không muốn chọn nit, nhưng tôi không đồng ý với ý kiến ​​rằng DevOps là về tốc độ trong khi SRE là về độ tin cậy. Tôi hiểu đây là một điều dễ nghĩ - đặc biệt là vì SRE có "Độ tin cậy" trong tên của nó - nhưng nó không phải vậy. :-)

SRE là tất cả về vận tốc.

Chúng tôi nghĩ rằng trong thời gian dài, bạn sẽ đi nhanh hơn nhiều nếu bạn nhận ra khi các bánh xe bắt đầu chao đảo (SLO và Ngân sách Lỗi) và làm chậm trong những trường hợp đó để làm cho mọi thứ tốt hơn. Điều đó, theo kinh nghiệm của chúng tôi, nhanh hơn nhiều so với việc phải dừng lại trong một thời gian dài vì chúng tôi để cho một loạt các khoản nợ kỹ thuật liên quan đến độ tin cậy chồng chất.

SRE có thể được coi là một khởi tạo cụ thể của DevOps với một tập hợp các ràng buộc được thi hành đồng đều hơn. (Do đó, SRE Class thực hiện công thức DevOps ở trên.)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.