Năm 2016, Google đã phát hành cuốn sách về Kỹ thuật độ tin cậy của trang web (Site Reliability Engineering – SRE) – một phương pháp bắt nguồn từ công ty để giải quyết một vấn đề lớn: làm thế nào để giữ cho các dịch vụ của Google hoạt động với độ tin cậy cao. Trong những năm qua, SRE đã được áp dụng rộng rãi bởi các nhóm phát triển trên toàn cầu và là một vai trò phổ biến tại các công ty khởi nghiệp cũng như doanh nghiệp lớn.
Cũng như với bất kỳ phương pháp mới nào, chúng ta vẫn đang tìm hiểu về những gì các kỹ sư SRE thực sự nên làm. Những trách nhiệm cốt lõi nào đối với vai trò của một Site Reliability Engineer? Chúng ta có thể đọc sách và xem video để hiểu SRE nhưng thật khó vẽ ra một bức tranh rõ ràng về những gì được mong đợi về vai trò và trách nhiệm của SRE trong công việc hàng ngày.
Trong bài viết này chúng ta sẽ xem phân tích mô tả công việc cho các vai trò SRE từ các công ty lớn và tổng hợp các trách nhiệm hàng đầu của vai trò này. Đây là kết quả phân tích 30 tin tuyển dụng cho vị trí SRE từ các công ty lớn như Google, Twitter, Slack, v.v.
Trách nhiệm của SRE qua bảng mô tả công việc
Dưới đây là các trách nhiệm chính mà của các Site Reliability Engineer (SRE) được rút ra từ các mô tả công việc.
- Triển khai và duy trì cơ sở hạ tầng (được đề cập trong 84% bản mô tả công việc)
- Xác định và quản lý SLO, SLI và ngân sách lỗi (errro budgets) (34% mô tả công việc)
- Thiết lập giám sát và cảnh báo (47% mô tả công việc)
- Trực tiếp, ứng phó với các sự cố và thực viết các post-mortems tức ghi lại những gì đã xảy ra để tránh các sai lầm tương tự (47% mô tả công việc)
- Xây dựng công cụ và tự động hóa (56% mô tả công việc)
Triển khai và duy trì cơ sở hạ tầng
Một trong những trách nhiệm quan trọng đối với SRE là thiết kế, xây dựng và duy trì cơ sở hạ tầng mà công ty vận hành các sản phẩm và dịch vụ của mình. Điều này có thể liên quan đến việc làm việc với đám mây tự lưu trữ (self hosted cloud), nhưng rõ ràng việc lưu trữ với các đám mây công cộng như AWS và Google Cloud đang trở nên phổ biến hơn. Một cách phổ biến là viết cơ sở hạ tầng dưới dạng mã (infrastructure-as-code) với YAML và HCL (đối với các sản phẩm Hashicorp như Terraform).
Để giúp đưa ra quyết định đúng đắn cho cơ sở hạ tầng, SREs sẽ tham gia vào việc lập kế hoạch công suất (capacity planning) cho các sản phẩm mới và hiện có – điều này bao gồm các cuộc thảo luận với nhóm sản phẩm và kỹ thuật để ước tính tải và hiểu các latecy thresholds (ngưỡng trễ), v.v.
Một số trách nhiệm khác của các SREs là đảm bảo cơ sở hạ tầng đáp ứng được các yêu cầu tuân thủ (compliance requirement). Điều này đặc biệt quan trọng để duy trì sự tuân thủ các tiêu chuẩn hàng đầu như GDPR và SOC2. Cuối cùng, với chi phí công nghệ ngày càng tăng ở hầu hết các công ty, việc tối ưu hóa chi phí cho cơ sở hạ tầng cũng đang trở thành một yêu cầu quan trọng đối với các SRE.
Xác định và quản lý SLO, SLI và ngân sách lỗi
Duy trì độ tin cậy của hệ thống đang sử dụng là một phần quan trọng của SRE. Do đó, việc xác định những gì cấu thành một dịch vụ đang chạy chính xác và đáp ứng các tiêu chuẩn nội bộ trở nên quan trọng.
Là một SRE, bạn sẽ tham gia vào việc tạo SLO và SLI cho mục đích này. Service Level Objectives (SLO) chỉ định các mục tiêu của dịch vụ và Service Level Indicatior (SLI) giúp đo lường các dịch vụ. SLO có thể bắt nguồn từ các cuộc thảo luận nội bộ về kỳ vọng của khách hàng và bất kỳ lời hứa bên ngoài nào được đưa ra với khách hàng dưới dạng Service Level Agreement (SLA).
Sau khi các SLO được xác định, chúng có thể được sử dụng để đưa ra ngân sách lỗi (error budget) hoặc thời gian cho phép mà dịch vụ có thể ở dưới mức mục tiêu. Ngân sách lỗi mang lại cho các nhóm phát triển và SRE một chút thời gian, bởi vì một dịch vụ không bao giờ có thể chạy ở độ tin cậy 100%. Các ngân sách này cũng có thể hữu ích cho việc đo lường tác động của các sự cố, ví dụ: nếu một sự cố tiêu tốn 30% ngân sách, nó có thể được coi là một sự cố lớn.
Thiết lập giám sát và cảnh báo
Sau khi nhóm đã xác định SLO, đã đến lúc theo dõi xem bạn có đáp ứng những SLI đó hay không bằng cách xác định SLI (Chỉ số mức dịch vụ) và thiết lập giám sát cho cả hai. Việc giám sát phổ biến nhất sẽ dành cho cơ sở hạ tầng (CPU, tăng đột biến bộ nhớ), thời gian hoạt động của dịch vụ (của trang web, API), hiệu suất (tốc độ tải trang), v.v. Bạn sẽ sử dụng các công cụ tự lưu trữ như Prometheus và Grafana hoặc sử dụng các nhà cung cấp SAAS phổ biến như Datadog và Sentry.
Thiết lập giám sát và cảnh báo chỉ là bước đầu tiên. Bạn cũng sẽ cần đảm bảo rằng các ngưỡng giám sát là chính xác để nhóm của bạn không bị choáng ngợp với các cảnh báo không quan trọng. Bạn cũng sẽ cần đảm bảo rằng các cảnh báo có thể thực hiện được. Và cuối cùng, một hệ thống cảnh báo tốt cũng sẽ đảm bảo cảnh báo về các triệu chứng để có thể thực hiện các hành động và không lặp lại.
Luôn sẵng sàng, ứng phó với các sự cố và tiến hành các hoạt động sau post-mortems
Sau khi bạn thiết lập giám sát và khi có cảnh báo đến, nhóm của bạn sẽ thiết lập lịch trình để có thể phân bổ các phản hồi cảnh báo mọi lúc cho toàn bộ nhóm. Bạn sẽ phải sử dụng một nền tảng quản lý sự cố để đảm bảo rằng tất cả các sự cố và cảnh báo được quản lý ở một nơi và người chịu trách nhiệm rõ ràng với mọi sự cố. Điều này cũng sẽ giúp bạn trong việc tính toán các số liệu quan trọng như MTTA (Mean Time To Acknowledge) và MTTR (Mean Time To Resolve).
Bạn cũng sẽ tham gia vào quá trình xử lý sau khi đã có các post-mortems (tức các bản ghi lại các chi tiết về các sự cố) để bạn có thể giải thích cho các bên liên quan bên trong và bên ngoài về chuỗi sự kiện dẫn đến sự cố, các bước khắc phục được thực hiện để giải quyết và các thay đổi được thực hiện để ngăn chặn các vấn đề tương tự trong tương lai.
Xây dựng công cụ và tự động hóa
Một trong những nguyên tắc cốt lõi của SRE là eliminate toil tức “loại bỏ những vất vả”. Google SRE định nghĩa công việc vất vả là “công việc thủ công, lặp đi lặp lại, có thể tự động hóa, không mang tính chiến thuật” làm tiêu tốn thời gian của các nhóm phát triển và SRE và làm chậm các dự án quan trọng khác. Do đó, việc xây dựng tự động hóa cho các nhiệm vụ lặp đi lặp lại là một trong những phần quan trọng hơn của vai trò SRE. Quá trình tự động hóa có thể xoay quanh việc phản hồi các cảnh báo thông thường, thiết lập quy trình CI / CD để nhóm của bạn có thể di chuyển nhanh hơn hoặc tạo ra các sản phẩm để cho phép các nhóm nhà phát triển tự phục vụ các yêu cầu chung.
Các trách nhiệm khác trong mô tả công việc của SRE
Tùy thuộc vào công ty, một số trách nhiệm khác của SRE có thể bao gồm:
- Gỡ lỗi các vấn đề về production. Các SRE có thể sẽ tham gia vào việc gỡ lỗi các vấn đề liên quan đến hệ thống đang vận hành trên tất cả các cấp độ kỹ thuật.
- Phát triển chiến lược đa đám mây. Khi các công ty bắt đầu chuyển nhiều khối lượng công việc hơn sang đám mây công cộng, có một yêu cầu được đặt ra là cần có sự tương thích với các nhà cung cấp khác nhau (vendor agnostic) về cả chi phí và độ tin cậy. Đó là lý do tại sao nhiều công ty đang nỗ lực xây dựng chiến lược để làm cho sản phẩm của họ hoạt động trên các nền tảng đám mây khác nhau.
- Kỹ thuật hỗn loạn (Chaos Engineering). Kỹ thuật hỗn loạn lần đầu tiên được Netflix tiên phong sử dụng và kể từ đó đã trở thành một kỹ thuật được các công ty công nghệ áp dụng. Nó thường liên quan đến việc cố tình phá vỡ hệ thống của bạn theo những cách đáng ngạc nhiên để xem chúng có khả năng phục hồi như thế nào.
Kết luận
Như bạn có thể thấy, qua các bảng mô tả công việc của các công ty hàng đầu, vai trò của SRE không chỉ là bảo trì cơ sở hạ tầng hoặc trợ giúp với CI / CD. Mục tiêu của SRE là giữ cho các dịch vụ hoạt động ở mức cao nhất có thể, liên quan đến nhiều lĩnh vực hoạt động và kỹ thuật phần mềm khác nhau .
Theo What is expected in the SRE role
Bạn có biết?
tham gia cộng đồng ITguru trên Linkedin, Facebook và các kênh mạng xã hội khác có thể giúp bạn nhanh chóng tìm được những chủ đề phát triển nghề nghiệp và cập nhật thông tin về việc làm IT mới nhất
Linkedin Page:
Facebook Group:
cơ hội việc làm IT : ITguru.vn
