Kỹ sư SRE - thực tập sinh
Đầu tiên, hãy để tôi giới thiệu bản thân mình. TÔI - , kỹ sư front-end trong nhóm GitLab. Tuần trước tôi đã có vinh dự được thực tập với một trong những kỹ sư SRE theo yêu cầu của chúng tôi. Mục đích là để quan sát cách nhân viên trực ứng phó với các sự cố hàng ngày và tích lũy kinh nghiệm thực tế trong công việc. Chúng tôi mong muốn các kỹ sư của mình hiểu rõ hơn nhu cầu của người dùng Theo dõi::Sức khỏe.
Tôi phải theo kỹ sư SRE đi khắp nơi trong suốt một tuần. Nghĩa là, tôi có mặt tại buổi bàn giao, theo dõi các kênh cảnh báo tương tự và ứng phó với các sự cố nếu và khi chúng xảy ra.
Sự cố
Có 2 sự cố trong vòng một tuần.
1. Công cụ khai thác tiền điện tử
GitLab.com đã chứng kiến mức sử dụng tăng vọt vào thứ Tư 'a, gây ra bởi nỗ lực sử dụng số phút của người chạy để khai thác tiền điện tử. Sự cố đã được xử lý bằng cách sử dụng công cụ vô hiệu hóa vi phạm của chúng tôi, công cụ này sẽ dừng nhiệm vụ của người chạy và xóa dự án cũng như tài khoản được liên kết với nó.
Nếu sự kiện này không được chú ý thì một công cụ tự động đã có thể phát hiện ra nó, nhưng trong trường hợp này, kỹ sư SRE đã nhận thấy hành vi vi phạm trước tiên. Một nhiệm vụ sự cố đã được tạo nhưng thông tin về nó bị đóng.
2. Suy giảm hiệu suất của ứng dụng Canary và Main
Sự cố xảy ra do sự chậm lại và tần suất lỗi ngày càng tăng trong các ứng dụng web chính và canary trên Gitlab.com. Một số giá trị Apdex đã bị vi phạm.
Nhiệm vụ sự cố mở:
Những phát hiện chính
Dưới đây là một số điều tôi học được trong tuần làm nhiệm vụ.
1. Cảnh báo hữu ích nhất khi phát hiện những sai lệch so với định mức.
Cảnh báo có thể được chia thành nhiều loại:
- Cảnh báo dựa trên một giá trị ngưỡng nhất định, chẳng hạn như “xảy ra 10 lỗi 5xx mỗi giây”.
- Cảnh báo trong đó ngưỡng là giá trị phần trăm, chẳng hạn như “tần suất lỗi 5xx trên 10% tổng khối lượng yêu cầu tại một thời điểm nhất định”.
- Cảnh báo dựa trên mức trung bình lịch sử, chẳng hạn như "lỗi 5xx ở phân vị thứ 90".
Nói chung, loại 2 và 3 hữu ích hơn đối với các SRE đang làm nhiệm vụ vì chúng bộc lộ những sai lệch so với tiêu chuẩn trong quy trình.
2. Nhiều cảnh báo không bao giờ chuyển thành sự cố.
Các kỹ sư SR phải xử lý một loạt cảnh báo liên tục, nhiều cảnh báo trong số đó không thực sự quan trọng.
Vậy tại sao không giới hạn cảnh báo của bạn chỉ với những cảnh báo thực sự quan trọng? Tuy nhiên, với cách tiếp cận này, bạn có thể không nhận ra những dấu hiệu ban đầu cho thấy vấn đề thực sự sẽ trở thành một vấn đề đe dọa thiệt hại lớn.
Công việc của SRE theo yêu cầu là xác định cảnh báo nào thực sự chỉ ra điều gì đó nghiêm trọng và liệu chúng có cần được chuyển lên cấp cao hơn và xử lý hay không. Tôi nghi ngờ điều này cũng là do tính không linh hoạt của cảnh báo: sẽ tốt hơn nếu có nhiều cấp độ hoặc cách “thông minh” để định cấu hình cảnh báo phù hợp với tình huống được mô tả ở trên.
Đề xuất tính năng:
3. Các SRE đang làm nhiệm vụ của chúng tôi sử dụng rất nhiều công cụ.
Nội bộ:
- Dự án cơ sở hạ tầng GitLab: sổ ghi chép có sẵn tại đây, bài tập theo ca/tuần, nhiệm vụ ứng phó sự cố.
- Sự cố GitLab: Các cuộc điều tra, đánh giá và bảo trì cũng được theo dõi trong các sự cố.
- Nhãn GitLab: Các tác vụ tự động hóa được khởi chạy bằng cách sử dụng các nhãn cụ thể mà bot sử dụng để theo dõi hoạt động của tác vụ.
Bên ngoài:
- PagerNhiệm vụ: Cảnh báo
- Slack: Luồng thông báo PagerDuty/AlertManager xuất hiện ở đây. Tích hợp với các lệnh gạch chéo để thực hiện nhiều tác vụ khác nhau, chẳng hạn như đóng cảnh báo hoặc báo cáo sự cố.
- Grafana: trực quan hóa các số liệu tập trung vào các xu hướng dài hạn.
- Kibana: Cung cấp khả năng trực quan hóa/tìm kiếm nhật ký, khả năng tìm hiểu sâu hơn về các sự kiện cụ thể.
- Zoom: Có một “phòng đột phá” chạy liên tục trong Zoom. Điều này cho phép các kỹ sư SRE thảo luận nhanh chóng về các sự kiện mà không lãng phí thời gian quý báu khi tạo phòng và liên kết những người tham gia.
Và nhiều người khác.
4. Giám sát GitLab.com bằng GitLab là một điểm thất bại duy nhất
Nếu GitLab.com gặp phải sự cố ngừng dịch vụ nghiêm trọng, chúng tôi không muốn điều đó ảnh hưởng đến khả năng giải quyết vấn đề của chúng tôi. Có thể dừng nó bằng cách khởi chạy phiên bản GitLab thứ hai để quản lý GitLab.com. Trên thực tế, điều này đã có tác dụng với chúng tôi: .
5. Một số tính năng cần cân nhắc thêm vào GitLab
- , tương tự như Google Tài liệu. Điều này sẽ giúp thực hiện các nhiệm vụ về các sự cố trong một sự kiện cũng như các nhiệm vụ về việc phỏng vấn. Trong cả hai trường hợp, một số người tham gia có thể cần thêm nội dung nào đó theo thời gian thực.
- Thêm webhook cho nhiệm vụ. Khả năng chạy các bước quy trình công việc GitLab khác nhau từ bên trong sẽ giúp giảm sự phụ thuộc của bạn vào tích hợp Slack. Ví dụ: khả năng cho phép cảnh báo trong PagerDuty thông qua lệnh gạch chéo trong vấn đề GitLab.
Kết luận
Các kỹ sư SRE gặp khó khăn với rất nhiều điều phức tạp. Sẽ thật tuyệt khi thấy thêm nhiều sản phẩm GitLab giải quyết những vấn đề này. Chúng tôi đang nghiên cứu một số bổ sung cho sản phẩm để giúp quy trình làm việc được đề cập ở trên trở nên dễ dàng hơn. Chi tiết có tại .
Chúng tôi sẽ mở rộng nhóm vào năm 2020 để kết hợp tất cả các tính năng tuyệt vời này lại với nhau. Nếu quan tâm, vui lòng kiểm tra và vui lòng liên hệ với bất kỳ ai trong nhóm của chúng tôi nếu có bất kỳ câu hỏi nào.
Nguồn: www.habr.com