Chết tiệt! Lúc đó là 3 giờ sáng, bạn đang có một giấc mơ tuyệt vời thì đột nhiên có một cuộc gọi đến. Bạn đang trực tuần này và hình như đã có chuyện gì đó xảy ra. Hệ thống tự động gọi để tìm hiểu xem có vấn đề gì. Đây là một khía cạnh quan trọng trong việc quản lý hệ thống máy tính hiện đại, nhưng hãy xem cách tạo thông báo tốt hơn cho mọi người.
Làm quen với triết lý giám sát, được hình thành qua nhiều thập kỷ thực hiện nhiệm vụ của tôi trong các nhóm giám sát khác nhau. Cô ấy bị ảnh hưởng phần lớn bởi cuốn kinh thánh thực sự của Rob Evashchuk (Triết lý thông báo của tôi) có trong cuốn sách về , và cuốn sách của John Alspaugh (Những lưu ý khi thiết lập cảnh báo).
, и - cảm ơn sự giúp đỡ của bạn trong việc chỉnh sửa bài viết.
TRƯỜNG HỢP là gì?
Tôi quyết định nghĩ ra một từ viết tắt đẹp như hoặc . Tôi gọi nó là phương pháp TRƯỜNG HỢP. Ông mô tả bốn điểm cần chú ý khi làm việc với giám sát tự động:
- (ràng buộc ngữ cảnh)
- (giá trị thực tiễn)
- (nhấn mạnh vào triệu chứng)
- (cấp)
Nếu sử dụng CASE, bạn sẽ xử lý thông báo một cách thờ ơ lành mạnh và không đánh thức mọi người vào ban đêm. Việc giám sát cần được đánh giá thường xuyên về tính hữu ích và hiệu quả. Khi một người nhận được thông báo, họ sẽ có mô hình tinh thần tốt hơn và tự tin hơn.
Để dễ nhớ hơn, hãy tưởng tượng bạn cần một CASE [tức là một trường hợp, một lý do - ghi chú của người dịch] để biện minh cho mỗi cảnh báo. :kính râm:
Và tại sao lại thế này?
. Vì nhiều lý do. Và CASE sẽ không loại bỏ được tất cả. Nhưng với nó, bạn sẽ thức dậy vào ban đêm để nhận được thông báo tốt hơn. Phương pháp này bao gồm các quy trình tổ chức khác nhau cũng sẽ giúp ích trong vấn đề này.
Cái hay của phương pháp RED và USE là với sự trợ giúp của chúng, chúng ta không chỉ biết cách làm việc mà còn có thể nói cùng một ngôn ngữ với nhau. Tôi hy vọng rằng phương pháp CASE sẽ giúp thảo luận về các thông báo bảo vệ hệ thống của chúng ta dễ dàng hơn nhưng lại khiến đồng nghiệp của chúng ta bận rộn.
Vấn đề là bạn cần tạo ra một nền văn hóa trong tổ chức của mình, nơi các thông báo được xử lý một cách thờ ơ lành mạnh. Thông báo có thể được tạo cho một mục đích cụ thể, nhưng thực tế không phải là chúng sẽ không mất giá trị sau này. Tại sao chúng tôi thiết lập thông báo này? Tiêu chí của nó đã được sửa đổi cách đây bao lâu? Với CASE, những câu hỏi này có thể được giải đáp.
Bối cảnh nặng - ràng buộc bối cảnh
3 giờ sáng không phải là thời điểm tốt nhất để đọc những tin nhắn chứa nhiều từ ngữ thông minh. Để phản hồi hiệu quả, bạn cần thông tin. Lý tưởng nhất, đây phải là thông tin về một vấn đề cụ thể, trong đó bối cảnh rõ ràng ngay lập tức và các thông báo phải được định cấu hình để có thể thực hiện được điều này. Đây là sự “quan sát” và “định hướng” từ . Không có gì xấu hổ khi dành thời gian cho việc thiết lập này, bởi vì việc liên tục làm một người mất tập trung thậm chí còn tốn kém hơn. Hãy tôn trọng lẫn nhau.
Vấn đề có nhiều nguồn. Đặc biệt là ma.
Tôi có thể giúp gì cho viên chức trực ban? Điều đầu tiên mà nhân viên trực nhìn thấy là một thông báo, vì vậy anh ta xây dựng mọi giả thuyết trên cơ sở đó. Sau đó, anh ấy xem hướng dẫn và trang tổng quan, nhưng có phải luôn có dữ liệu về một thông báo cụ thể chứ không chỉ thông tin chung không? Alspaugh khuyên “hãy suy nghĩ về cách bạn có thể diễn giải hoặc phản hồi thông báo” (slide 29). Một thông báo tốt sẽ tập trung vào người đang làm nhiệm vụ chứ không chỉ được cấu hình theo ngưỡng.
Vì vậy, đây là một số ý tưởng về cách cải thiện bối cảnh thông báo:
- Hiển thị cho người dùng nội dung nào đó hữu ích và được tạo đặc biệt chứ không chỉ là các hướng dẫn thông thường hoặc trang tổng quan. Trước đây, tôi và mọi người đã sử dụng bảng điều khiển được định cấu hình cho các thông báo cụ thể. Điều này sẽ hữu ích nếu vấn đề đã được biết nhưng sẽ chỉ khiến người khác bối rối. Chúng ta cần tìm sự cân bằng ở đây.
- Hãy cho chúng tôi biết về lịch sử của thông báo: nó có mới không? Nó có hoạt động thường xuyên không? Có phải theo mùa không?
- Hiển thị những thay đổi gần đây về trạng thái hệ thống. Gần đây có gì thay đổi không? (Ví dụ: triển khai hoặc bật/tắt chức năng.)
- Hiển thị các mối quan hệ và cung cấp thông tin cho mô hình tinh thần: các phần phụ thuộc của hệ thống phải được nhìn thấy rõ ràng, tốt nhất là kèm theo dấu hiệu về chức năng.
- Kết nối nhanh chóng người dùng với nhóm: họ có thể xem các sự cố đang diễn ra hay họ có thể tìm ra ai khác trong công ty đã nhận được thông báo không? Chương trình kích hoạt?
Lý tưởng nhất là chương trình quản lý sự cố sẽ đưa ra lời khuyên về cách cải thiện bối cảnh thông báo điều tra sự cố. Luôn luôn có một cái gì đó để làm việc!
Có thể hành động - giá trị thực tế
Nhân viên trực có nên làm gì đó để đáp lại thông báo không? Nếu bạn không cần làm gì hoặc không biết phải làm gì thì tại sao bạn lại đánh thức anh ấy? Bạn cần tránh những thông báo gây khó chịu cho những người đang làm nhiệm vụ và không yêu cầu hành động.
Tôi nên làm gì? Bạn muốn gì?
Trước đây, khi các hệ thống còn đơn giản và các nhóm còn nhỏ, chúng tôi thiết lập giám sát chỉ để cập nhật mọi thứ. Thông báo rằng tải trên heap đã tăng lên sẽ cung cấp cho chúng tôi bối cảnh nếu dịch vụ sau đó gặp trục trặc. Ở quy mô lớn, những thông báo như vậy sẽ chỉ tạo ra sự nhầm lẫn vì hệ thống của chúng tôi luôn hoạt động trong tình trạng xuống cấp với mức độ nghiêm trọng khác nhau. Điều này nhanh chóng dẫn đến và tất nhiên là mất đi sự nhạy cảm. Do đó, nhân viên trực ban bỏ qua hoặc thậm chí lọc những thông báo như vậy và không phải lúc nào cũng phản hồi chúng khi cần thiết. Đừng rơi vào cái bẫy này! Đừng thiết lập tất cả các thông báo liên tiếp và sau đó gửi chúng qua email đến một thư mục bị bỏ rơi nào đó.
Đây là thông báo có giá trị thực tế trông như thế nào:
- Thông báo yêu cầu hành động thay vì chỉ báo cáo tin tức.
- Hành động này khó thực hiện hoặc có rủi ro khi tự động hóa. Nếu một hành động có thể được tự động hóa thì hãy tự động hóa nó, đừng làm phiền mọi người nữa!
- Thông báo chứa các khuyến nghị khẩn cấp dưới dạng (SLA) hoặc (RTO). Sau đó, nhân viên trực có thể kích hoạt chương trình quản lý sự cố của tổ chức.
Tôi muốn làm rõ: Tôi không nói rằng thông báo chỉ nên đến đối với các SLO (mục tiêu cấp độ dịch vụ) quan trọng nhất đối với API. Giám sát SLO liên tục bị phân mảnh và phân chia và yêu cầu cách tiếp cận giống nhau đối với tất cả các dịch vụ. Rõ ràng là bạn sẽ theo dõi các SLO quan trọng nhất đối với những khách hàng trả tiền cho bạn. Nhưng các SLO cơ sở hạ tầng, chẳng hạn như cơ sở dữ liệu, cũng cần được giám sát. Chẳng bao lâu nữa bạn sẽ phải giao dịch với khách hàng nội bộ và hỗ trợ họ. Và cứ thế đến vô cùng.
Dựa trên triệu chứng - nhấn mạnh vào các triệu chứng
Dù muốn hay không thì bạn cũng đang làm việc trong một hệ thống phân tán (Kavaj). Kết quả là bạn sử dụng các chiến thuật khác nhau để cô lập các dịch vụ và bảo vệ chúng khỏi sự cố (Trainor và cộng sự)3. Và mặc dù việc thu thập rác bị trì hoãn hoặc truy vấn cơ sở dữ liệu bị đình trệ cho thấy có vấn đề, nhưng không cần phải vội vàng khắc phục chúng nếu người dùng không gặp sự cố trong tương lai gần.
Đây là những tín hiệu quan trọng và có thể có giá trị thực tế, nhưng nếu chúng không làm phiền người dùng thì cũng chưa đến mức khiến người phục vụ mất tập trung. Thông báo dựa trên nguyên nhân là ảnh chụp nhanh mô hình tinh thần của chúng ta về lỗi hệ thống. Tốt hơn là bạn nên theo dõi các triệu chứng quan trọng hơn là cố gắng liệt kê tất cả các nguyên nhân có thể gây ra lỗi.
Để làm cho thông báo có ý nghĩa, hãy tập trung vào , quan trọng đối với người dùng. Evashchuk gọi đây là “giám sát người dùng”. Hãy nhớ rằng triết lý này phải được áp dụng trong toàn tổ chức. Nếu một dịch vụ gặp vấn đề khẩn cấp ở đâu đó sâu trong cơ sở hạ tầng, nhóm thích hợp sẽ giải quyết chúng. Bảo vệ hệ thống khỏi những lỗi như vậy là một vấn đề hoàn toàn riêng biệt (Huấn luyện viên và cộng sự, phần về chiến lược giảm thiểu sự phụ thuộc quan trọng).
Các triệu chứng không thay đổi
Richard Cook nhắc nhở chúng ta rằng các hệ thống phức tạp đầy rẫy những sai sót, thiếu sót và vấn đề. Cố gắng liệt kê tất cả các lý do có thể là một nhiệm vụ của Sisyphean. Bạn cố gắng mô tả các vấn đề, nhưng chúng luôn thay đổi. Cindy Sridharan tin rằng “các hệ thống không cần phải ở tình trạng hoàn hảo từng giây” và tốt hơn là nên sử dụng cách tiếp cận nhân văn hơn ( (“Giám sát hệ thống phân tán”), 7).
Tránh thông báo sau sự cố
Thông thường, thông báo về nguyên nhân được cấu hình để khắc phục sự cố. Và những thông báo hạn chế này về thực tế của những gì đã xảy ra tạo ra cảm giác an toàn sai lầm, bởi vì hệ thống luôn tìm ra những cách mới để phá vỡ.
Đừng để bị lừa bởi những thông báo nguyên nhân. Tốt hơn hãy suy nghĩ:
- Tại sao thông báo dựa trên triệu chứng không phát hiện ra vấn đề?
- Việc cải thiện ngữ cảnh cho người dùng có hữu ích không?
- Làm cách nào để cải thiện các công cụ giám sát nhằm chẩn đoán nhanh hơn thay vì tích lũy thông báo về những gì đã xảy ra?
Các công cụ giám sát để chẩn đoán sẽ chỉ hữu ích nếu bạn coi chúng như một cách để chuyển từ triệu chứng sang giải pháp. Nếu không có phản hồi này, bạn sẽ bị tấn công dồn dập bởi các thông báo và biểu đồ muộn về những thất bại trong quá khứ—chứ không một lời nào về những thất bại trong tương lai. Đây là cơ hội tuyệt vời để một tổ chức chuyển từ phòng thủ sang tấn công. Và các nhà phát triển cũng như người quản lý sản phẩm sẽ có cùng kỳ vọng và mục tiêu rõ ràng. Trường hợp - CASE(:wink:) - rõ ràng cho từng thông báo.
Thông báo dựa trên lý do có thể được chấp nhận ở mức độ vừa phải
Đôi khi hệ thống của chúng tôi không cho chúng tôi nhiều lựa chọn về thông báo dựa trên nguyên nhân. Và đôi khi những người làm nhiệm vụ hiểu rất rõ rằng một triệu chứng chắc chắn sẽ dẫn đến thất bại, và do đó có giá trị thực tế. Có thể bạn không chắc chuyện gì đang xảy ra và đang thiết lập thông báo để đảm bảo an toàn. Hy vọng rằng hành động này chỉ là tạm thời cho đến khi chúng tôi có thể thay đổi hệ thống để giải quyết vấn đề về hiệu suất.
Hãy ghi nhớ các thành phần khác của CASE khi xử lý những tình huống này. Chỉ vì nó tạm thời không có nghĩa là bạn có thể ngừng suy nghĩ bằng đầu.
Đánh giá - đánh giá
Bất kỳ thay đổi nào đối với hệ thống (mã mới, cơ sở hạ tầng mới, bất kỳ điều gì mới) đều làm tăng phạm vi lỗi (Cook, 3). Thông báo này có còn hoạt động như mong đợi không? Mô hình hệ thống và trải nghiệm tinh thần rõ ràng và hiện tại khi phản hồi một số thông báo hỗ trợ - đây là những tính năng chính . Các khiếm khuyết trong hệ thống không ngừng phát triển và chúng ta phải theo kịp chúng.
Bạn cần liên tục đánh giá chất lượng của từng thông báo để đảm bảo chúng hoạt động như mong đợi. Kính thưa các nhà lãnh đạo! Sẽ dễ dàng hơn nhiều cho nhóm của bạn nếu bạn giúp họ thiết lập quy trình này! Dưới đây là một số ý tưởng đánh giá:
- Sử dụng , hoặc các phương pháp kiểm tra thông báo khác. Nhóm có thể tự làm việc đó mà không cần phải phụ thuộc vào hệ thống quản lý sự cố nặng nề!
- Kết hợp việc thu thập tất cả các thông báo liên quan đến sự cố vào chương trình quản lý sự cố của bạn. Đánh dấu hữu ích, có hại, không phù hợp, không rõ ràng, v.v. Hãy sử dụng chúng làm phản hồi.
- Các thông báo phù hợp được kích hoạt không thường xuyên và được kiểm tra cẩn thận. Đảm bảo tất cả các liên kết đều hoạt động, trỏ đến đúng ngữ cảnh, v.v.
- Nếu một thông báo không bao giờ kích hoạt hoặc kích hoạt quá thường xuyên thì có điều gì đó không ổn với thông báo đó. Sửa nó hoặc loại bỏ nó. Hãy coi chừng sự thụ động hoặc hoạt động quá mức!
- Đặt dấu thời gian thông báo kèm theo ngày hết hạn. Nếu ngày hết hạn, hãy đánh giá thông báo bằng phương pháp CASE và cập nhật dấu thời gian. Cũng giống như thực phẩm, hãy kiểm tra hạn sử dụng thường xuyên.
- Đơn giản hóa quá trình cải thiện thông báo. Sử dụng tính năng giám sát dưới dạng mã và lưu trữ thông báo trong kho Git. Yêu cầu kéo giúp thu hút nhóm và cung cấp cho bạn lịch sử các thông báo trước đây. Và bạn sẽ không còn ngại thay đổi thông báo hoặc xin phép những người chịu trách nhiệm về chúng nữa.
- Thiết lập phản hồi cho thông báo, ngay cả khi việc đó đơn giản , để nhân viên trực ban đánh dấu thông báo là vô ích hoặc xâm phạm. Nhúng liên kết hoặc lời kêu gọi hành động vào chính thông báo và thường xuyên xem lại phản hồi của bạn.
- Thiết lập nội quy trong nhóm - để những người trực làm việc để đơn giản hóa nhiệm vụ khi có ít việc. Có thể mọi thứ sau bạn sẽ tốt hơn một chút so với trước đây.
Kết luận
Tôi tin rằng phương pháp CASE giúp các nhà phát triển và tổ chức thảo luận về việc thiết lập và gửi thông báo tự động. Một nhà phát triển có thể bắt đầu đánh giá thông báo bằng phương pháp CASE, sau đó toàn bộ tổ chức sẽ tham gia cùng với các nhà phát triển, chương trình quản lý và quản lý sự cố khác để duy trì thông báo ở trạng thái tốt. Điều này không yêu cầu bất kỳ công cụ đặc biệt hoặc quy trình phức tạp nào.
Toàn bộ ngành cần nghĩ đến yếu tố con người khi làm nhiệm vụ mà không phải hy sinh dịch vụ khách hàng hàng đầu. Tất cả những công cụ và phương pháp thực hành này có thể và cần được cải thiện. Tôi hy vọng phương pháp CASE sẽ giúp ích được điều này.
Tận hưởng thông báo được cải thiện!
Nguồn: www.habr.com