Xin chào, Habr! Tôi đã hỗ trợ các hệ thống CNTT Highload được mười năm. Tôi sẽ không viết trong bài viết này về các vấn đề khi thiết lập nginx để hoạt động ở chế độ 1000+ RPS hoặc những thứ kỹ thuật khác. Tôi sẽ chia sẻ những quan sát của mình về các vấn đề trong quá trình phát sinh trong quá trình hỗ trợ và vận hành các hệ thống đó.
Giám sát
Hỗ trợ kỹ thuật không đợi cho đến khi có yêu cầu với nội dung “Tại sao... trang web không hoạt động trở lại?” Trong vòng một phút sau khi trang web gặp sự cố, bộ phận hỗ trợ sẽ nhìn thấy vấn đề và bắt đầu giải quyết nó. Nhưng trang web này chỉ là phần nổi của tảng băng chìm. Tính khả dụng của nó là một trong những tính năng đầu tiên được theo dõi.
Phải làm gì trong tình huống hàng hóa còn lại của cửa hàng trực tuyến không còn về từ hệ thống ERP? Hoặc hệ thống CRM tính chiết khấu cho khách hàng đã ngừng phản hồi? Trang web dường như đang hoạt động. Zabbix có điều kiện nhận được phản hồi 200. Ca trực chưa nhận được bất kỳ thông báo nào từ phía giám sát và đang vui vẻ xem tập đầu tiên của Game of Thrones mùa mới.
Việc giám sát thường chỉ giới hạn ở việc đo trạng thái của bộ nhớ, RAM và tải bộ xử lý máy chủ. Nhưng đối với doanh nghiệp, điều quan trọng hơn nhiều là có được sản phẩm có sẵn trên trang web. Lỗi có điều kiện của một máy ảo trong cụm sẽ dẫn đến thực tế là lưu lượng truy cập vào nó sẽ ngừng truy cập và tải trên các máy chủ khác sẽ tăng lên. Công ty sẽ không bị mất tiền.
Do đó, ngoài việc theo dõi các thông số kỹ thuật của hệ điều hành trên máy chủ, bạn cần cấu hình các số liệu nghiệp vụ. Các số liệu ảnh hưởng trực tiếp đến tiền. Tương tác khác nhau với các hệ thống bên ngoài (CRM, ERP và các hệ thống khác). Số lượng đơn đặt hàng trong một khoảng thời gian nhất định. Ủy quyền khách hàng thành công hoặc không thành công và các số liệu khác.
Tương tác với các hệ thống bên ngoài
Bất kỳ trang web hoặc ứng dụng di động nào có doanh thu hàng năm trên một tỷ rúp đều tương tác với các hệ thống bên ngoài. Bắt đầu từ CRM và ERP nêu trên và kết thúc bằng việc chuyển dữ liệu bán hàng sang hệ thống Dữ liệu lớn bên ngoài để phân tích các giao dịch mua hàng và cung cấp cho khách hàng một sản phẩm mà họ chắc chắn sẽ mua (trên thực tế là không). Mỗi hệ thống như vậy có sự hỗ trợ riêng. Và thường việc giao tiếp với các hệ thống này gây ra đau đớn. Đặc biệt khi vấn đề mang tính toàn cầu và bạn cần phân tích nó trong các hệ thống khác nhau.
Một số hệ thống cung cấp số điện thoại hoặc điện tín cho quản trị viên của họ. Ở đâu đó bạn cần viết thư cho người quản lý hoặc truy cập trình theo dõi lỗi của các hệ thống bên ngoài này. Ngay cả trong bối cảnh của một công ty lớn, các hệ thống khác nhau thường hoạt động trong các hệ thống kế toán ứng dụng khác nhau. Đôi khi không thể theo dõi trạng thái của ứng dụng. Bạn nhận được một yêu cầu trong một Jira có điều kiện. Sau đó, trong phần bình luận của Jira đầu tiên này, bạn đặt một liên kết đến vấn đề này trong một Jira khác. Trong Jira thứ hai trong ứng dụng, ai đó đã viết bình luận rằng bạn cần gọi cho quản trị viên có điều kiện Andrey để giải quyết vấn đề. Và như vậy.
Giải pháp tốt nhất cho vấn đề này là tạo một không gian duy nhất để liên lạc, chẳng hạn như trong Slack. Mời tất cả những người tham gia trong quá trình vận hành hệ thống bên ngoài cùng tham gia. Và cũng là một trình theo dõi duy nhất để không trùng lặp các ứng dụng. Các ứng dụng phải được theo dõi ở một nơi, từ giám sát thông báo đến kết quả giải pháp lỗi trong tương lai. Bạn sẽ nói rằng điều này là phi thực tế và trong lịch sử đã từng xảy ra việc chúng tôi làm việc trong một công cụ theo dõi còn họ làm việc trong một công cụ theo dõi khác. Các hệ thống khác nhau xuất hiện, họ có đội ngũ CNTT tự trị của riêng mình. Tôi đồng ý và do đó vấn đề cần được giải quyết từ cấp trên ở cấp độ CIO hoặc chủ sở hữu sản phẩm.
Mọi hệ thống mà bạn tương tác phải cung cấp hỗ trợ dưới dạng dịch vụ với SLA rõ ràng để giải quyết các vấn đề theo mức độ ưu tiên. Và không phải khi quản trị viên có điều kiện Andrey dành một phút cho bạn.
Người đàn ông thắt cổ chai
Có phải tất cả mọi người trong một dự án (hoặc sản phẩm) đều có một người đi nghỉ khiến cấp trên chấn động? Đây có thể là một kỹ sư, nhà phân tích hoặc nhà phát triển devops. Rốt cuộc, chỉ có kỹ sư devops mới biết máy chủ nào đã cài đặt bộ chứa nào, cách khởi động lại bộ chứa trong trường hợp có sự cố và nói chung, mọi vấn đề phức tạp đều không thể giải quyết được nếu không có anh ta. Nhà phân tích là người duy nhất biết cơ chế phức tạp của bạn hoạt động như thế nào. Luồng dữ liệu nào đi đâu. Chúng tôi sẽ nhận được phản hồi theo thông số nào của yêu cầu đối với dịch vụ nào, dịch vụ nào.
Ai sẽ nhanh chóng hiểu được tại sao có lỗi trong nhật ký và khắc phục kịp thời một lỗi nghiêm trọng trong sản phẩm? Tất nhiên là cùng một nhà phát triển. Có những cái khác, nhưng vì lý do nào đó chỉ có anh ấy mới hiểu cách hoạt động của các mô-đun khác nhau của hệ thống.
Gốc rễ của vấn đề này là thiếu tài liệu. Rốt cuộc, nếu tất cả các dịch vụ trong hệ thống của bạn đã được mô tả, thì bạn có thể giải quyết vấn đề mà không cần đến nhà phân tích. Nếu các nhà phát triển dành vài ngày trong lịch trình bận rộn của anh ấy và mô tả tất cả các máy chủ, dịch vụ và hướng dẫn giải quyết các vấn đề điển hình, thì vấn đề khi anh ấy vắng mặt có thể được giải quyết mà không cần anh ấy. Bạn không cần phải nhanh chóng uống hết cốc bia trên bãi biển khi đi nghỉ và tìm kiếm Wi-Fi để giải quyết vấn đề.
Năng lực và trách nhiệm của nhân viên hỗ trợ
Trong các dự án lớn, các công ty không tiết kiệm tiền lương của nhà phát triển. Họ đang tìm kiếm những người trung niên hoặc cao cấp đắt tiền từ các dự án tương tự. Với sự hỗ trợ, tình hình hơi khác một chút. Họ đang cố gắng giảm những chi phí này bằng mọi cách có thể. Các công ty thuê những công nhân Enikey rẻ tiền của ngày hôm qua và mạnh dạn tham gia trận chiến. Chiến lược này có thể thực hiện được nếu chúng ta đang nói về trang web danh thiếp của một nhà máy ở Zelenograd.
Nếu chúng ta đang nói về một cửa hàng trực tuyến lớn, thì mỗi giờ ngừng hoạt động sẽ tốn kém hơn cả mức lương hàng tháng của một quản trị viên Enikey. Hãy lấy 1 tỷ rúp doanh thu hàng năm làm điểm khởi đầu. Đây là doanh thu tối thiểu của bất kỳ cửa hàng trực tuyến nào từ xếp hạng . Chia số tiền này cho số giờ mỗi năm và nhận được khoản lỗ ròng hơn 100 rúp. Và nếu bạn không tính số giờ ban đêm, bạn có thể nhân đôi số tiền một cách an toàn.
Nhưng tiền không phải là điều chính, phải không? (không, tất nhiên là điều chính yếu) Ngoài ra còn có những tổn thất về danh tiếng. Sự sụp đổ của một cửa hàng trực tuyến nổi tiếng có thể gây ra cả làn sóng đánh giá trên mạng xã hội và các ấn phẩm trên các phương tiện truyền thông chuyên đề. Và những cuộc trò chuyện của bạn bè trong bếp theo kiểu “Đừng mua gì ở đó, trang web của họ sập luôn” không thể đo lường được chút nào.
Bây giờ đến trách nhiệm. Trong thực tế của tôi, đã có trường hợp quản trị viên trực không phản hồi kịp thời với thông báo từ hệ thống giám sát về việc trang web không có sẵn. Vào một buổi tối thứ Sáu mùa hè dễ chịu, trang web của một cửa hàng trực tuyến nổi tiếng ở Moscow nằm im lìm. Vào sáng thứ bảy, người quản lý sản phẩm của trang này không hiểu tại sao trang này không mở và có sự im lặng trong các cuộc trò chuyện hỗ trợ và thông báo khẩn cấp trong Slack. Một sai lầm như vậy đã khiến chúng tôi phải trả giá sáu con số và viên chức trực ban này đã mất việc.
Trách nhiệm là một kỹ năng khó phát triển. Hoặc một người có nó hoặc không. Vì vậy, trong các cuộc phỏng vấn, tôi cố gắng xác định sự hiện diện của nó bằng nhiều câu hỏi khác nhau gián tiếp cho thấy liệu một người có quen với việc chịu trách nhiệm hay không. Nếu một người trả lời rằng anh ta chọn trường đại học vì bố mẹ nói vậy hoặc thay đổi công việc vì vợ anh ta nói rằng anh ta kiếm không đủ tiền, thì tốt hơn hết là đừng dính líu đến những người như vậy.
Tương tác với nhóm phát triển
Khi người dùng gặp phải sự cố đơn giản với sản phẩm trong quá trình vận hành, bộ phận hỗ trợ sẽ tự giải quyết. Cố gắng tái tạo vấn đề, phân tích nhật ký, v.v. Nhưng phải làm gì khi sản phẩm xuất hiện lỗi? Trong trường hợp này, bộ phận hỗ trợ sẽ giao nhiệm vụ cho các nhà phát triển và đây là lúc cuộc vui bắt đầu.
Các nhà phát triển liên tục bị quá tải. Họ đang tạo ra các tính năng mới. Sửa lỗi bán hàng không phải là hoạt động thú vị nhất. Thời hạn đang đến gần để hoàn thành lần chạy nước rút tiếp theo. Và sau đó những người khó chịu từ bộ phận hỗ trợ đến và nói: "Hãy bỏ mọi thứ ngay lập tức, chúng tôi gặp vấn đề." Mức độ ưu tiên của các nhiệm vụ như vậy là tối thiểu. Đặc biệt là khi sự cố không phải là vấn đề nghiêm trọng nhất và chức năng chính của trang web vẫn hoạt động, đồng thời khi người quản lý phát hành không trợn mắt chạy quanh và viết: “Khẩn trương thêm nhiệm vụ này vào bản phát hành hoặc hotfix tiếp theo”.
Các vấn đề có mức độ ưu tiên bình thường hoặc thấp sẽ được chuyển từ bản phát hành này sang bản phát hành khác. Đối với câu hỏi “Khi nào nhiệm vụ sẽ được hoàn thành?” bạn sẽ nhận được câu trả lời theo kiểu: “Xin lỗi, hiện tại có rất nhiều nhiệm vụ, hãy hỏi trưởng nhóm hoặc người quản lý phát hành của bạn.”
Vấn đề năng suất được ưu tiên cao hơn việc tạo ra các tính năng mới. Những đánh giá tiêu cực sẽ không còn lâu nữa nếu người dùng liên tục vấp phải lỗi. Danh tiếng bị tổn hại rất khó khôi phục.
Các vấn đề tương tác giữa phát triển và hỗ trợ đều được DevOps giải quyết. Chữ viết tắt này thường được sử dụng dưới hình thức một người cụ thể giúp tạo môi trường thử nghiệm để phát triển, xây dựng quy trình CICD và nhanh chóng đưa mã đã thử nghiệm vào sản xuất. DevOps là một cách tiếp cận phát triển phần mềm khi tất cả những người tham gia vào quá trình này tương tác chặt chẽ với nhau và giúp tạo và cập nhật nhanh chóng các sản phẩm và dịch vụ phần mềm. Ý tôi là các nhà phân tích, nhà phát triển, người thử nghiệm và hỗ trợ.
Trong cách tiếp cận này, hỗ trợ và phát triển không phải là những bộ phận khác nhau với mục tiêu và mục tiêu riêng. Phát triển gắn liền với vận hành và ngược lại. Cụm từ nổi tiếng của các nhóm phân phối: “Vấn đề không nằm ở phía tôi” không còn xuất hiện thường xuyên trong các cuộc trò chuyện nữa và người dùng cuối trở nên vui vẻ hơn một chút.
Nguồn: www.habr.com