Nhóm của chúng tôi yêu thích các thí nghiệm. Mỗi Slurm không phải là sự lặp lại tĩnh của những cái trước mà là sự phản ánh về trải nghiệm và quá trình chuyển đổi từ tốt sang tốt hơn. Nhưng vơi chúng tôi quyết định áp dụng một thể thức hoàn toàn mới - để cung cấp cho những người tham gia những điều kiện gần nhất có thể với việc “chiến đấu”.
Nếu chúng ta phác thảo ngắn gọn những gì chúng ta đã làm trong khóa học chuyên sâu: “Chúng ta xây dựng, chúng ta phá vỡ, chúng ta sửa chữa,
chúng tôi đang học." SRE ít có giá trị về mặt lý thuyết - chỉ có thực hành, giải pháp thực tế, vấn đề thực tế.
Những người tham gia được chia thành các đội sao cho tinh thần cạnh tranh gay gắt không cho phép ai ngủ quên hoặc khởi động “Angry Birds” trên iPhone, theo gương của Dmitry Anatolyevich.
Các vấn đề, trục trặc, lỗi và nhiệm vụ đã được bốn cố vấn cung cấp cho người tham gia. Ivan Kruglov, Nhà phát triển chính tại Booking.com (Hà Lan). Ben Tyler, Nhà phát triển chính tại Booking.com (Mỹ). Eduard Medvedev, CTO tại Phòng thí nghiệm Vonfram (Đức). Evgeniy Varavva, nhà phát triển chung tại Google (San Francisco).
Hơn nữa, những người tham gia được chia thành các đội và cạnh tranh với nhau. Hấp dẫn?
Ivan, Ben, Eduard và Evgeniy nhìn những người tham gia Slurm SRE tội nghiệp với ánh mắt tử tế theo chủ nghĩa Lênin trước khi cuộc thi bắt đầu.
Vì vậy, nhiệm vụ:
Chúng ta là của chúng ta, chúng ta sẽ xây dựng một thế giới mới ...
Có một trang web tổng hợp vé xem phim. Các sự cố được phát minh bởi những người cố vấn trong một kịch bản được làm sẵn (mặc dù không ai loại trừ khả năng ứng biến đặc biệt phức tạp và quỷ quyệt), hiệu suất của trang web được mô tả bằng nhiều số liệu khác nhau. Các vấn đề có thể rất khác nhau: vé vào rạp Moulin Rouge không được tải vào cơ sở dữ liệu; áp phích phim và buổi biểu diễn được tải vào cơ sở dữ liệu trong hơn 10 giây; mô tả của một bộ phim riêng lẻ bị đóng băng; 0,1% đơn hàng đã được đặt trước; Đôi khi hệ thống xử lý thanh toán gặp sự cố trong một hoặc hai phút. Và rất nhiều, rất nhiều điều khó chịu có thể xảy ra với người tham gia Slurm SRE trong công việc thực sự của anh ta.
Chúng tôi sẵn sàng xử lý mọi việc...và tất cả mọi người.
Trang web lâu dài của chúng tôi bao gồm một số dịch vụ vi mô. Nhiệm vụ của nó là tổng hợp dữ liệu về các buổi chiếu, giá cả và số ghế còn trống từ tất cả các rạp chiếu phim; nó hiển thị các thông báo về phim, cho phép bạn chọn rạp chiếu phim, buổi biểu diễn, hội trường và địa điểm, đặt chỗ và thanh toán vé. Nói chung là mọi thứ mà người xem chỉ có thể mơ ước. Nhưng người dùng thậm chí không nghi ngờ rằng bên trong đang diễn ra một cuộc đấu tranh khốc liệt để giành lấy sự ổn định và khả năng truy cập của trang web.
Đối với trang web chuyên sâu, chúng tôi đã tạo các chỉ số SLO, SLI, SLA, phát triển kiến trúc và cơ sở hạ tầng, triển khai trang web, thiết lập giám sát và cảnh báo. Và chúng tôi đi.
SLO, SLI, SLA
SLI - chỉ báo mức độ dịch vụ. SLO là mục tiêu cấp độ dịch vụ. SLA - thỏa thuận cấp độ dịch vụ.
SLA là một thuật ngữ phương pháp ITIL biểu thị một thỏa thuận chính thức giữa khách hàng của dịch vụ và nhà cung cấp dịch vụ đó, bao gồm mô tả về dịch vụ, quyền và nghĩa vụ của các bên và quan trọng nhất là mức chất lượng đã thỏa thuận để cung cấp dịch vụ này. dịch vụ.
SLO là mục tiêu cấp độ dịch vụ: giá trị mục tiêu hoặc phạm vi giá trị cho cấp độ dịch vụ được đo bằng SLI. Giá trị bình thường cho SLO là “SLI ≤ Mục tiêu” hoặc “Giới hạn dưới ≤ SLI ≤ Giới hạn trên”.
SLI là một chỉ báo mức độ dịch vụ—một thước đo định lượng được xác định cẩn thận về một khía cạnh của mức độ dịch vụ được cung cấp. Đối với hầu hết các dịch vụ, SLI chính được coi là độ trễ yêu cầu - mất bao lâu để trả lời phản hồi cho một yêu cầu. Các SLI phổ biến khác bao gồm tỷ lệ lỗi, thường được biểu thị dưới dạng một phần của tất cả các yêu cầu nhận được và thông lượng hệ thống, thường được đo bằng yêu cầu mỗi giây.
Trước hết, chúng ta sẽ phá vỡ những chiếc máy bay, sau đó là các cô gái, và sau đó là các cô gái...
Các yếu tố bên trong và bên ngoài bắt đầu “làm hỏng” SLO ngay từ những phút đầu tiên. Mọi thứ đổ dồn lên đầu các quản trị viên—lỗi của nhà phát triển, lỗi cơ sở hạ tầng, lượng khách truy cập tràn vào và các cuộc tấn công DDoS. Mọi thứ làm SLO trở nên tồi tệ hơn.
“- Thưa những người tham gia, tôi vội làm hài lòng các bạn, điều đầu tiên bạn thất bại là… tất cả mọi thứ!”
Trong suốt quá trình, các diễn giả đã thảo luận về tính ổn định, mức độ lỗi, thực hành kiểm tra, quản lý sự gián đoạn và tải trọng vận hành.
Chúng tôi không phải là thợ đốt lò, không phải thợ mộc...
Sau đó, những người tham gia bắt đầu sửa chữa mọi thứ - điều chính là hiểu những gì cần lấy trước.
“- Lạy Chúa, con chưa bao giờ thấy nó gãy như thế này, ở hình thức này và ở vị trí như thế này!”
Vì vậy, một tai nạn đã xảy ra. Dịch vụ xử lý thanh toán không hoạt động. Làm thế nào để hành động để khôi phục chức năng trong thời gian ngắn nhất?
Các chuyên gia trìu mến nhìn những người tham gia đang chuẩn bị một thủ thuật khác.
Mỗi đội tổ chức công việc của nhóm để loại bỏ tai nạn - có sự tham gia của đồng nghiệp, thông báo cho các bên quan tâm (các bên liên quan). Đồng thời, các ưu tiên được thiết lập. Bằng cách này, những người tham gia được đào tạo để làm việc dưới áp lực trong điều kiện thời gian cực kỳ hạn chế.
“Loại kinh dị nào đã xuất hiện?!”
Thở ra... và kết thúc bài tập
Cùng với các diễn giả, sau khi từng vấn đề được giải quyết và địa điểm tạm thời ổn định, nhóm đã nghiên cứu các sự cố từ góc nhìn của SRE. Chúng tôi đã phân tích chi tiết các vấn đề - nguyên nhân xuất hiện, tiến độ loại bỏ. Sau đó, theo từng nhóm và tập thể, chúng tôi đã đưa ra quyết định về cách ngăn chặn chúng hơn nữa: cách cải thiện hoạt động giám sát, cách thay đổi kiến trúc một cách khôn ngoan, cách điều chỉnh cách tiếp cận phát triển và vận hành, cách sửa các quy định. Các diễn giả trình diễn cách thực hành khám nghiệm tử thi.
“Còn ai muốn bị hành hạ nữa! - TÔI!"
Thành công của các đội được ghi chép chặt chẽ và rõ ràng trên bảng điểm điện tử.
Đối với vị trí đầu tiên - tiền thưởng từ các bên liên quan.
Nguồn: www.habr.com