English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

khách
1 / ?
trở lại bài học

Đọc Đuôi Dài

Độ trễ Sống trên một Đường cong, Không phải một Số

Độ trễ trung bình ẩn giấu những gì người dùng trải qua. Các dịch vụ thực tế tạo ra một phân phối: một đường cong hiển thị có bao nhiêu yêu cầu mất bao lâu.

Ba điểm trên đường cong đó mang phần lớn ý nghĩa hoạt động:

- p50 (trung vị): giữa của phân phối. Nửa yêu cầu hoàn thành nhanh hơn, nửa chậm hơn. Mô tả trải nghiệm điển hình.

- p99: phân vị thứ 99. Chỉ 1% yêu cầu mất nhiều thời gian hơn thế này. Mô tả trải nghiệm tồi tệ nhất cho người dùng điển hình.

- p99.9: chỉ 0,1% yêu cầu mất nhiều thời gian hơn. Mô tả trải nghiệm tồi tệ nhất cho những người dùng quyền lực sử dụng dịch vụ thường xuyên.

Hiểu biết về hình học: phân phối độ trễ hầu như luôn có một đuôi dài bên phải. Đường cong tăng nhanh đến đỉnh cao xung quanh trung vị, sau đó giảm chậm về bên phải, thường có một sự gợn sóng nhỏ cách xa giá trị trung bình. Sự gợn sóng đó đại diện cho những người dùng chậm nhất: những người viết những vé giận dữ.

Tại sao trung bình gây hiểu lầm: một dịch vụ có trung vị 50 ms và p99 là 5.000 ms có khoảng cách 100x giữa trải nghiệm điển hình và đuôi. Trung bình số học có thể hạ cánh ở 100 ms, ẩn toàn bộ thảm họa. Trung bình số học là một phép chiếu điểm đơn của một hình dạng 2D: gần như tất cả thông tin của hình dạng biến mất.

Vấn đề nhân phân vị: một yêu cầu chạm vào 10 dịch vụ backend, mỗi dịch vụ có p99 là 100 ms, có p99 khoảng 600 ms (không phải 100 ms). Những đuôi chậm nhân lên. Đây là lý do tại sao cuốn sách SRE cảnh báo: 'hãy cẩn thận với điều chậm nhất của N'. Khi N tăng, độ trễ đuôi của bạn giảm nhanh chóng.

Phân phối độ trễ: đuôi dài bên phải với p50, p99, p99.9 được đánh dấu

Toán Độ trễ Đuôi

Dịch vụ A có luồng yêu cầu phân nhánh thành 5 dịch vụ backend song song và đợi tất cả các phản hồi. Mỗi backend có độ trễ p99 là 100 ms.

Ước tính độ trễ p99 của Dịch vụ A dựa trên cấu trúc phân nhánh. Giải thích tại sao câu trả lời khác với 100 ms. Mô hình hình học nào trong phân phối độ trễ gây ra sự nhân này, & một thay đổi kiến ​​trúc cụ thể nào giảm khuếch đại đuôi?

Tiêu thụ Ngân sách dưới dạng Độ dốc

Vẽ Biểu đồ Ngân sách Theo thời gian

Một ngân sách lỗi được vẽ trên các trục 2D (thời gian trên x, ngân sách còn lại trên y) tiết lộ sức khỏe dịch vụ trong nháy mắt. Hình dạng của đường cong tiêu thụ mang cùng thông tin mà mười bảng điều khiển riêng lẻ sẽ truyền đạt.

Ba hình dạng tham chiếu:

- Tiêu thụ tuyến tính lành mạnh: ngân sách giảm trong một đường thẳng tỷ lệ với thời gian đã trôi qua. Vào ngày 14 của cửa sổ 28 ngày, nửa ngân sách nên còn lại. Đây là mục tiêu SLO được hiển thị rõ.

- Tiêu thụ nhanh: một độ dốc陡峭 xuống dưới. Chỉ ra một vấn đề độ tin cậy hoạt động. Nếu độ dốc đủ dốc, ngân sách sẽ cạn kiệt trước khi cửa sổ đặt lại, kích hoạt chính sách ngân sách lỗi.

- Đường cong được chữa khỏi: một đoạn phẳng hoặc tăng. Dịch vụ đang hoạt động tốt hơn SLO của nó. Ngân sách còn lại tăng theo thời gian, mở ra chỗ cho những lần phát hành rủi ro.

Tốc độ tiêu thụ là độ dốc của đường tiêu thụ, chuẩn hóa: tốc độ tiêu thụ là 1 có nghĩa là tiêu thụ ngân sách chính xác với tốc độ thời gian trôi qua (hoàn toàn phù hợp với SLO). Tốc độ tiêu thụ là 10 có nghĩa là tiêu thụ nhanh hơn 10 lần so với cho phép: toàn bộ ngân sách hàng tháng sẽ cạn kiệt trong 2,8 ngày với tốc độ này.

Cảnh báo tốc độ tiêu thụ đa cửa sổ: Sổ tay SRE của Google khuyến nghị cảnh báo trên các điều kiện kết hợp như 'tốc độ tiêu thụ trên 14,4 trong giờ qua VÀ trên 14,4 trong 5 phút qua'. Hình học: một độ dốc dốc kéo dài, không chỉ là một bản spike tạm thời. Hình dạng này lọc ra những sự gián đoạn tạm thời trong khi bắt những mối đe dọa tiêu thụ thực.

Tiêu thụ ngân sách lỗi: hình dạng tuyến tính, tiêu thụ nhanh, chữa khỏi

Đọc một Tốc độ Tiêu thụ

SLO của nhóm bạn là 99,9% trong 28 ngày. Vào ngày 7, bạn đã sử dụng 60% ngân sách lỗi của mình. Tốc độ tiêu thụ hiện tại trong 24 giờ qua là 8.

Tính trạng thái dự kiến ​​cuối cửa sổ (ngân sách cạn kiệt hoặc dư thừa) nếu tốc độ tiêu thụ tiếp tục. Sau đó mô tả những gì hình dạng hình học của biểu đồ tiêu thụ cho bạn biết & những gì chính sách ngân sách lỗi có thể nói bạn nên làm tuần này.

Dịch vụ dưới dạng một Biểu đồ Có hướng

Sản xuất dưới dạng một DAG

Các dịch vụ hiện đại chạy dưới dạng một biểu đồ phụ thuộc. Mỗi dịch vụ là một nút. Mỗi cuộc gọi từ dịch vụ A đến dịch vụ B là một cạnh có hướng từ A đến B. Bức tranh đầy đủ tạo thành một biểu đồ có hướng (đôi khi là một DAG, đôi khi có chu kỳ qua thử lại không đồng bộ).

Các tính chất hình học quan trọng:

- Độ bậc ngoài: có bao nhiêu dịch vụ mà một nút phụ thuộc vào. Độ bậc ngoài cao hơn có nghĩa là nhiều chế độ lỗi ngược dòng hơn. Một dịch vụ phụ thuộc vào 12 backend sẽ thất bại nếu bất kỳ một trong số 12 cái đó thất bại.

- Độ bậc vào (fan-in): có bao nhiêu dịch vụ phụ thuộc vào nút này. Độ bậc vào cao hơn có nghĩa là một lỗi duy nhất ở đây sẽ lan rộng. Một cơ sở dữ liệu có 30 dịch vụ phụ thuộc có bán kính nổ vỡ lớn nhất.

- Trung tâm giữa (betweenness centrality): có bao nhiêu đường dẫn ngắn nhất đi qua một nút. Các nút có trung tâm cao là những chỗ nghẽn. Các dịch vụ xác thực và API cốt lõi thường có điểm số cao.

- Các thành phần được kết nối mạnh mẽ: các nhóm dịch vụ tạo thành chu kỳ. Nếu A gọi B và B gọi A, bạn có một chu kỳ. Các chu kỳ làm phức tạp việc khôi phục lỗi: bắt đầu một dịch vụ bất kỳ yêu cầu dịch vụ kia đã hoạt động.

Bán kính nổ tung là khái niệm hình học thúc đẩy đầu tư độ tin cậy. Bán kính nổ tung của một lỗi là tập hợp con phụ thuộc dịch vụ mà nó ảnh hưởng. Kỹ thuật độ tin cậy đầu tư nặng nề ở các nút có bán kính nổ tung lớn nhất. Cách rẻ nhất để cải thiện độ tin cậy hệ thống tổng thể thường là thêm tính dự phòng hoặc thoái hóa duyên cảm ở các nút có trung tâm cao nhất.

Biểu đồ phụ thuộc dịch vụ với nút có trung tâm cao được làm nổi bật

Suy luận Bán kính Nổ tung

Một dịch vụ người tiêu dùng phụ thuộc vào: AuthService, UserDB, ProductCatalog, PaymentGateway, RecommendationEngine, EmailService, AnalyticsService. AuthService có 47 dịch vụ khác phụ thuộc vào nó. EmailService có 3 dịch vụ khác phụ thuộc vào nó. RecommendationEngine có 2 dịch vụ khác phụ thuộc vào nó.

Xếp hạng ba dịch vụ này theo bán kính nổ tung từ cao nhất đến thấp nhất. Sau đó mô tả hai khoản đầu tư độ tin cậy cụ thể để thực hiện ở nút bán kính nổ tung cao nhất trước tiên, & giải thích tại sao đầu tư ở đó cung cấp nhiều cải thiện độ tin cậy tổng thể hơn cùng một khoản đầu tư ở nút bán kính nổ tung thấp hơn.

Hình học Thông tin của một Bảng điều khiển

Pixel là Bất động sản

Bảng điều khiển là một bề mặt 2D với diện tích hữu hạn. Mỗi pixel được phân bổ cho một tín hiệu là một pixel không được phân bổ cho một tín hiệu khác. Thiết kế bảng điều khiển là một vấn đề hình học: sắp xếp thông tin có liên quan quyết định nhất trong diện tích hình ảnh nhỏ nhất trong khi bảo tồn các mối quan hệ không gian giúp nhận dạng.

Mô hình đọc: người đọc phương Tây quét F-hình (trên cùng bên trái đầu tiên, sau đó trên, sau đó xuống). Tín hiệu quan trọng nhất thuộc về góc trên cùng bên trái. Góc dưới cùng bên phải nhận được ít chú ý nhất.

Nhóm Gestalt: tín hiệu từ cùng một dịch vụ thuộc về cùng một nhóm hình ảnh. Độ trễ, lưu lượng, lỗi và bão hòa cho một dịch vụ thuộc về một lưới 2x2, không phải rải rác trên màn hình.

Mã hóa màu: màu đỏ cho các lỗi, vàng cho bão hòa, màu xanh lá cây cho các phạm vi lành mạnh. Lựa chọn màu sắc là những quy ước, không phải ngẫu nhiên. Đảo ngược chúng tốn chi phí tải nhận thức trên mỗi cái nhìn trong sự cố.

Tỷ lệ trục Y: biểu đồ tỷ lệ 0-100% trông bình tĩnh ngay cả trong lúc tăng gấp đôi lưu lượng. Biểu đồ tự động tỷ lệ đến các giá trị gần đây trông alarmant trong quá trình biến động bình thường. Cả hai lựa chọn đều có các cách sử dụng thích hợp; lựa chọn là hình học, không phải mỹ phẩm.

Mật độ thông tin: quá ít tín hiệu khiến nhóm mù những gì sai. Quá nhiều chôn vùi tín hiệu trong tiếng ồn. Tỷ lệ data-ink của Edward Tufte áp dụng: tối đa hóa tỷ lệ mực conveying thông tin thành mực trang trí. Kiểu sparkline tối thiểu chiến thắng widget lộn xộn trong nháy mắt.

Bố cục bảng điều khiển: đọc F-hình, nhóm Gestalt, mã hóa màu

Thiết kế cho Cái nhìn đầu tiên

Nhóm của bạn đang thiết kế một bảng điều khiển chính duy nhất cho một dịch vụ có 8 SLI quan trọng trên 4 phụ thuộc backend. Bảng điều khiển phải trả lời câu hỏi đầu tiên của kỹ sư on-call vào lúc 3 giờ sáng trong vòng 5 giây: 'có điều gì đó đang cháy không, & nếu có, ở đâu?'

Mô tả bố cục hình học mà bạn sẽ chọn. Tín hiệu quan trọng nhất đi đâu trên màn hình? Làm cách nào bạn nhóm các SLI theo phụ thuộc? Bạn áp dụng những công ước màu sắc và tỷ lệ nào, & yếu tố cụ thể nào đảm bảo kỹ sư có thể trả lời câu hỏi 'có gì đó đang cháy không' mà không cần đọc bất kỳ văn bản nào?

Hình học của SRE: Kết thúc

Hình dạng Mà Điều hành Sản xuất

Bạn đã đi bộ qua bốn cấu trúc hình học chạy bên dưới thực hành SRE:

- Phân phối độ trễ dưới dạng đường cong đuôi dài nơi các điểm phân vị mang nhiều sự thật hơn trung bình

- Hình nón ngân sách lỗi nơi độ dốc tiêu thụ tiết lộ sức khỏe dịch vụ tốt hơn số còn lại

- Biểu đồ phụ thuộc dịch vụ nơi bán kính nổ tung và trung tâm hướng dẫn đầu tư độ tin cậy

- Bố cục bảng điều khiển dưới dạng bất động sản 2D nơi phân bổ pixel là một vấn đề hình học với hậu quả hoạt động


Tư duy hình học là những gì tách biệt SRE khỏi công việc vận hành chung chung. Một kỹ sư ops đọc số. Một SRE đọc hình dạng. Các hình dạng mã hóa thông tin mà không có một số duy nhất nào có thể nắm bắt: độ dốc của tốc độ tiêu thụ, độ mập của một đuôi, trung tâm của một nút, gestalt của một bảng điều khiển panel.


Bài học đi kèm trên chính SRE bao gồm các thực hành. Bài học này bao gồm hình học bên dưới chúng. Cùng nhau, họ tạo thành dạng lộn xộn hình ảnh và khái niệm của kỹ thuật độ tin cậy hiện đại.