Chúng tôi theo dõi Sportmaster - bằng cách nào và với cái gì

Chúng tôi đã nghĩ đến việc tạo ra một hệ thống giám sát ở giai đoạn thành lập nhóm sản phẩm. Rõ ràng là hoạt động kinh doanh của chúng tôi - khai thác - không thuộc về những đội này. Tại sao vậy?

Thực tế là tất cả các nhóm của chúng tôi đều được xây dựng xung quanh các hệ thống thông tin riêng lẻ, dịch vụ vi mô và mặt trận, vì vậy các nhóm không nhìn thấy được tình trạng tổng thể của toàn bộ hệ thống. Ví dụ: họ có thể không biết một phần nhỏ nào đó trong phần phụ trợ sâu ảnh hưởng đến giao diện người dùng như thế nào. Phạm vi quan tâm của họ được giới hạn ở các hệ thống mà hệ thống của họ được tích hợp. Nếu một đội và dịch vụ A của họ hầu như không có kết nối với dịch vụ B, thì dịch vụ đó gần như vô hình đối với nhóm.

Chúng tôi theo dõi Sportmaster - bằng cách nào và với cái gì

Ngược lại, nhóm của chúng tôi làm việc với các hệ thống được tích hợp rất chặt chẽ với nhau: có nhiều kết nối giữa chúng, đây là một cơ sở hạ tầng rất lớn. Và hoạt động của cửa hàng trực tuyến phụ thuộc vào tất cả các hệ thống này (nhân tiện, chúng tôi có một số lượng lớn).

Vì vậy, hóa ra bộ phận của chúng tôi không thuộc đội nào mà nằm hơi lệch một bên. Trong toàn bộ câu chuyện này, nhiệm vụ của chúng ta là hiểu một cách toàn diện cách thức hoạt động của hệ thống thông tin, chức năng, sự tích hợp, phần mềm, mạng, phần cứng và cách tất cả những thứ này được kết nối với nhau.

Nền tảng mà các cửa hàng trực tuyến của chúng tôi hoạt động trông như thế này:

  • trước mặt
  • văn phòng trung gian
  • văn phòng trở lại

Cho dù chúng ta có muốn đến mức nào đi chăng nữa thì không phải tất cả các hệ thống đều hoạt động trơn tru và hoàn hảo. Một lần nữa, vấn đề là số lượng hệ thống và sự tích hợp - với những thứ như của chúng tôi, một số sự cố là không thể tránh khỏi, bất chấp chất lượng thử nghiệm. Hơn nữa, cả trong một hệ thống riêng biệt và về mặt tích hợp của chúng. Và bạn cần theo dõi trạng thái của toàn bộ nền tảng một cách toàn diện chứ không chỉ bất kỳ phần riêng lẻ nào của nó.

Lý tưởng nhất là việc theo dõi sức khỏe trên toàn nền tảng nên được tự động hóa. Và chúng tôi coi việc giám sát là một phần tất yếu của quá trình này. Ban đầu, nó chỉ được xây dựng cho phần tuyến đầu, trong khi các chuyên gia mạng, quản trị viên phần mềm và phần cứng đã và vẫn có hệ thống giám sát từng lớp của riêng họ. Tất cả những người này đều chỉ theo dõi ở cấp độ của mình, cũng không có ai hiểu biết toàn diện.

Ví dụ: nếu một máy ảo gặp sự cố, trong hầu hết các trường hợp, chỉ có quản trị viên chịu trách nhiệm về phần cứng và máy ảo biết về nó. Trong những trường hợp như vậy, nhóm tiền tuyến đã nhìn thấy thực tế sự cố ứng dụng, nhưng họ không có dữ liệu về sự cố của máy ảo. Và quản trị viên có thể biết khách hàng là ai và có ý tưởng sơ bộ về những gì hiện đang chạy trên máy ảo này, miễn là đó là một loại dự án lớn. Rất có thể anh ấy không biết về những đứa trẻ. Trong mọi trường hợp, quản trị viên cần đến gặp chủ sở hữu và hỏi xem máy này có những gì, cần khôi phục những gì và cần thay đổi những gì. Và nếu có điều gì đó thực sự nghiêm trọng bị hỏng, họ bắt đầu chạy vòng quanh - bởi vì không ai nhìn thấy toàn bộ hệ thống.

Cuối cùng, những câu chuyện khác nhau như vậy ảnh hưởng đến toàn bộ giao diện người dùng, người dùng và chức năng kinh doanh cốt lõi của chúng tôi - bán hàng trực tuyến. Vì chúng tôi không phải là thành viên của một nhóm nhưng tham gia vận hành tất cả các ứng dụng thương mại điện tử như một phần của cửa hàng trực tuyến nên chúng tôi đã nhận nhiệm vụ tạo ra một hệ thống giám sát toàn diện cho nền tảng thương mại điện tử.

Cấu trúc hệ thống và ngăn xếp

Chúng tôi bắt đầu bằng cách xác định một số lớp giám sát cho hệ thống của mình, trong đó chúng tôi cần thu thập số liệu. Và tất cả những điều này cần phải được kết hợp lại, đó là những gì chúng tôi đã làm ở giai đoạn đầu tiên. Bây giờ ở giai đoạn này, chúng tôi đang hoàn thiện bộ sưu tập số liệu chất lượng cao nhất trên tất cả các lớp của mình để xây dựng mối tương quan và hiểu cách các hệ thống ảnh hưởng lẫn nhau.

Việc thiếu giám sát toàn diện ở giai đoạn đầu khởi chạy ứng dụng (vì chúng tôi bắt đầu xây dựng nó khi hầu hết các hệ thống đang được sản xuất) dẫn đến việc chúng tôi phải gánh khoản nợ kỹ thuật đáng kể để thiết lập giám sát toàn bộ nền tảng. Chúng tôi không thể tập trung vào việc thiết lập giám sát cho một IS và tiến hành giám sát nó một cách chi tiết, vì phần còn lại của hệ thống sẽ không được giám sát trong một thời gian. Để giải quyết vấn đề này, chúng tôi đã xác định danh sách các số liệu cần thiết nhất để đánh giá trạng thái của hệ thống thông tin theo từng lớp và bắt đầu triển khai nó.

Vì vậy, họ quyết định ăn thịt con voi làm nhiều phần.

Hệ thống của chúng tôi bao gồm:

  • phần cứng;
  • hệ điều hành;
  • phần mềm;
  • Các phần UI trong ứng dụng giám sát;
  • số liệu kinh doanh;
  • ứng dụng tích hợp;
  • bảo mật thông tin;
  • mạng lưới;
  • cân bằng lưu lượng.

Chúng tôi theo dõi Sportmaster - bằng cách nào và với cái gì

Trung tâm của hệ thống này là việc giám sát chính nó. Để hiểu tổng thể trạng thái của toàn bộ hệ thống, bạn cần biết điều gì đang xảy ra với các ứng dụng trên tất cả các lớp này và trên toàn bộ bộ ứng dụng.

Vì vậy, về ngăn xếp.

Chúng tôi theo dõi Sportmaster - bằng cách nào và với cái gì

Chúng tôi sử dụng phần mềm nguồn mở. Ở trung tâm, chúng tôi có Zabbix, ứng dụng được chúng tôi sử dụng chủ yếu làm hệ thống cảnh báo. Mọi người đều biết rằng đó là giải pháp lý tưởng cho việc giám sát cơ sở hạ tầng. Điều đó có nghĩa là gì? Chính xác là những số liệu cấp thấp mà mọi công ty duy trì trung tâm dữ liệu của riêng mình đều có (và Sportmaster có trung tâm dữ liệu riêng) - nhiệt độ máy chủ, trạng thái bộ nhớ, đột kích, số liệu thiết bị mạng.

Chúng tôi đã tích hợp Zabbix với ứng dụng nhắn tin Telegram và Microsoft Teams, những ứng dụng này được sử dụng tích cực trong các nhóm. Zabbix bao gồm lớp mạng thực tế, phần cứng và một số phần mềm, nhưng nó không phải là thuốc chữa bách bệnh. Chúng tôi làm phong phú dữ liệu này từ một số dịch vụ khác. Ví dụ: ở cấp độ phần cứng, chúng tôi kết nối trực tiếp qua API với hệ thống ảo hóa của mình và thu thập dữ liệu.

Còn gì nữa. Ngoài Zabbix, chúng tôi sử dụng Prometheus, cho phép chúng tôi giám sát các số liệu trong ứng dụng môi trường động. Nghĩa là, chúng tôi có thể nhận số liệu ứng dụng thông qua điểm cuối HTTP và không cần lo lắng về việc nên tải số liệu nào vào đó và số liệu nào không. Dựa trên dữ liệu này, các truy vấn phân tích có thể được phát triển.

Nguồn dữ liệu cho các lớp khác, ví dụ: số liệu kinh doanh, được chia thành ba thành phần.

Thứ nhất, đây là các hệ thống kinh doanh bên ngoài, Google Analytics, chúng tôi thu thập số liệu từ nhật ký. Từ họ, chúng tôi nhận được dữ liệu về người dùng đang hoạt động, chuyển đổi và mọi thứ khác liên quan đến doanh nghiệp. Thứ hai, đây là hệ thống giám sát giao diện người dùng. Nó nên được mô tả chi tiết hơn.

Ngày xửa ngày xưa, chúng tôi bắt đầu với thử nghiệm thủ công và nó phát triển thành thử nghiệm tự động về chức năng và tích hợp. Từ đó, chúng tôi thực hiện giám sát, chỉ để lại chức năng chính và dựa vào các điểm đánh dấu ổn định nhất có thể và không thay đổi thường xuyên theo thời gian.

Cấu trúc nhóm mới có nghĩa là tất cả các hoạt động ứng dụng được giới hạn trong các nhóm sản phẩm, vì vậy chúng tôi đã ngừng thực hiện thử nghiệm thuần túy. Thay vào đó, chúng tôi đã thực hiện giám sát giao diện người dùng từ các thử nghiệm được viết bằng Java, Selenium và Jenkins (được sử dụng làm hệ thống để khởi chạy và tạo báo cáo).

Chúng tôi đã thử nghiệm rất nhiều, nhưng cuối cùng chúng tôi quyết định đi theo con đường chính, thước đo cấp cao nhất. Và nếu chúng ta có nhiều bài kiểm tra cụ thể thì sẽ khó có thể cập nhật dữ liệu. Mỗi bản phát hành tiếp theo sẽ phá vỡ đáng kể toàn bộ hệ thống và tất cả những gì chúng tôi sẽ làm là sửa nó. Vì vậy, chúng tôi tập trung vào những điều rất cơ bản hiếm khi thay đổi và chúng tôi chỉ theo dõi chúng.

Cuối cùng, thứ ba, nguồn dữ liệu là một hệ thống ghi nhật ký tập trung. Chúng tôi sử dụng Elastic Stack cho nhật ký và sau đó chúng tôi có thể lấy dữ liệu này vào hệ thống giám sát của mình để biết số liệu kinh doanh. Ngoài tất cả những điều này, chúng tôi còn có dịch vụ API giám sát của riêng mình, được viết bằng Python, dịch vụ này truy vấn bất kỳ dịch vụ nào thông qua API và thu thập dữ liệu từ chúng vào Zabbix.

Một thuộc tính không thể thiếu khác của giám sát là trực quan hóa. Của chúng tôi dựa trên Grafana. Nó nổi bật so với các hệ thống trực quan hóa khác ở chỗ nó cho phép bạn trực quan hóa các số liệu từ các nguồn dữ liệu khác nhau trên trang tổng quan. Chúng tôi có thể thu thập các số liệu cấp cao nhất cho một cửa hàng trực tuyến, ví dụ: số lượng đơn đặt hàng được đặt trong giờ qua từ DBMS, số liệu hiệu suất cho hệ điều hành mà cửa hàng trực tuyến này đang chạy từ Zabbix và số liệu cho các phiên bản của ứng dụng này từ Prometheus. Và tất cả điều này sẽ có trên một bảng điều khiển. Rõ ràng và dễ tiếp cận.

Hãy để tôi lưu ý về vấn đề bảo mật - chúng tôi hiện đang hoàn thiện hệ thống mà sau này chúng tôi sẽ tích hợp với hệ thống giám sát toàn cầu. Theo tôi, những vấn đề chính mà thương mại điện tử gặp phải trong lĩnh vực bảo mật thông tin có liên quan đến bot, trình phân tích cú pháp và bạo lực. Chúng tôi cần phải chú ý đến điều này vì tất cả những điều này có thể ảnh hưởng nghiêm trọng đến cả hoạt động của ứng dụng và danh tiếng của chúng tôi từ quan điểm kinh doanh. Và với ngăn xếp đã chọn, chúng tôi đã thực hiện thành công các nhiệm vụ này.

Một điểm quan trọng nữa là lớp ứng dụng được Prometheus lắp ráp. Bản thân anh ấy cũng được tích hợp với Zabbix. Và chúng tôi cũng có sitespeed, một dịch vụ cho phép chúng tôi xem các thông số như tốc độ tải trang, tắc nghẽn, hiển thị trang, tải tập lệnh, v.v., nó cũng được tích hợp API. Vì vậy, số liệu của chúng tôi được thu thập trong Zabbix và theo đó, chúng tôi cũng cảnh báo từ đó. Tất cả các cảnh báo hiện được gửi đến các phương thức gửi chính (hiện tại là email và điện tín, MS Teams gần đây cũng đã được kết nối). Có kế hoạch nâng cấp cảnh báo lên trạng thái mà các bot thông minh hoạt động như một dịch vụ và cung cấp thông tin giám sát cho tất cả các nhóm sản phẩm quan tâm.

Đối với chúng tôi, số liệu không chỉ quan trọng đối với các hệ thống thông tin riêng lẻ mà còn là số liệu chung cho toàn bộ cơ sở hạ tầng mà ứng dụng sử dụng: cụm máy chủ vật lý nơi máy ảo chạy, bộ cân bằng lưu lượng, Bộ cân bằng tải mạng, bản thân mạng, việc sử dụng các kênh liên lạc . Cộng thêm các số liệu cho các trung tâm dữ liệu của chúng tôi (chúng tôi có một vài trong số đó và cơ sở hạ tầng khá lớn).

Chúng tôi theo dõi Sportmaster - bằng cách nào và với cái gì

Ưu điểm của hệ thống giám sát của chúng tôi là với sự trợ giúp của nó, chúng tôi có thể thấy được tình trạng hoạt động của tất cả các hệ thống và có thể đánh giá tác động của chúng đối với nhau và đối với các tài nguyên được chia sẻ. Và cuối cùng, nó cho phép chúng tôi tham gia vào việc lập kế hoạch tài nguyên, đây cũng là trách nhiệm của chúng tôi. Chúng tôi quản lý tài nguyên máy chủ - một nhóm trong thương mại điện tử, vận hành và ngừng hoạt động thiết bị mới, mua thêm thiết bị mới, tiến hành kiểm tra việc sử dụng tài nguyên, v.v. Hàng năm, các nhóm lên kế hoạch cho các dự án mới, phát triển hệ thống của họ và điều quan trọng là chúng tôi phải cung cấp tài nguyên cho họ.

Và với sự trợ giúp của các số liệu, chúng tôi thấy được xu hướng tiêu thụ tài nguyên của hệ thống thông tin của mình. Và dựa trên chúng, chúng ta có thể lập kế hoạch gì đó. Ở cấp độ ảo hóa, chúng tôi thu thập dữ liệu và xem thông tin về lượng tài nguyên có sẵn của trung tâm dữ liệu. Và bên trong trung tâm dữ liệu, bạn có thể thấy quá trình tái chế, phân phối thực tế và tiêu thụ tài nguyên. Hơn nữa, cả với máy chủ độc lập và máy ảo cũng như cụm máy chủ vật lý mà trên đó tất cả các máy ảo này đang hoạt động mạnh mẽ.

Triển vọng

Bây giờ chúng tôi đã có sẵn phần cốt lõi của toàn bộ hệ thống, nhưng vẫn còn rất nhiều thứ cần phải xử lý. Ở mức tối thiểu, đây là lớp bảo mật thông tin, nhưng nó cũng quan trọng để tiếp cận mạng, phát triển cảnh báo và giải quyết vấn đề tương quan. Chúng tôi có nhiều lớp và hệ thống, và trên mỗi lớp có nhiều số liệu hơn. Hóa ra đó là một matryoshka ở mức độ matryoshka.

Nhiệm vụ của chúng tôi cuối cùng là đưa ra những cảnh báo phù hợp. Ví dụ: nếu lại xảy ra sự cố với phần cứng, với máy ảo và có một ứng dụng quan trọng và dịch vụ không được sao lưu theo bất kỳ cách nào. Chúng tôi phát hiện ra rằng máy ảo đã chết. Khi đó các số liệu kinh doanh sẽ cảnh báo bạn: người dùng đã biến mất ở đâu đó, không có chuyển đổi, giao diện người dùng trong giao diện không khả dụng, phần mềm và dịch vụ cũng đã chết.

Trong tình huống này, chúng tôi sẽ nhận được thư rác từ các cảnh báo và điều này không còn phù hợp với định dạng của hệ thống giám sát phù hợp nữa. Câu hỏi về mối tương quan nảy sinh. Do đó, lý tưởng nhất là hệ thống giám sát của chúng tôi nên nói: “Các bạn, máy vật lý của bạn đã chết, cùng với đó là ứng dụng này và các số liệu này,” với sự trợ giúp của một cảnh báo, thay vì dồn dập tấn công chúng tôi bằng hàng trăm cảnh báo. Nó sẽ báo cáo điều chính - nguyên nhân, giúp loại bỏ nhanh chóng sự cố do bản địa hóa của nó.

Hệ thống thông báo và xử lý cảnh báo của chúng tôi được xây dựng dựa trên dịch vụ đường dây nóng 24 giờ. Tất cả các cảnh báo được coi là bắt buộc phải có và có trong danh sách kiểm tra đều được gửi đến đó. Mỗi cảnh báo phải có phần mô tả: điều gì đã xảy ra, ý nghĩa thực sự của nó, tác động của nó. Và cũng là một liên kết đến bảng điều khiển và hướng dẫn về những việc cần làm trong trường hợp này.

Đây là tất cả về các yêu cầu để xây dựng một cảnh báo. Khi đó, tình hình có thể phát triển theo hai hướng - hoặc có vấn đề và cần được giải quyết, hoặc có lỗi trong hệ thống giám sát. Nhưng trong mọi trường hợp, bạn cần phải đi và tìm ra nó.

Trung bình hiện nay chúng tôi nhận được khoảng một trăm cảnh báo mỗi ngày, có tính đến thực tế là mối tương quan giữa các cảnh báo vẫn chưa được định cấu hình đúng cách. Và nếu chúng ta cần thực hiện công việc kỹ thuật và buộc phải tắt thứ gì đó, số lượng của chúng sẽ tăng lên đáng kể.

Ngoài việc giám sát các hệ thống mà chúng tôi vận hành và thu thập các số liệu được chúng tôi coi là quan trọng, hệ thống giám sát cho phép chúng tôi thu thập dữ liệu cho các nhóm sản phẩm. Chúng có thể ảnh hưởng đến thành phần của các số liệu trong hệ thống thông tin mà chúng tôi giám sát.

Đồng nghiệp của chúng tôi có thể đến và yêu cầu thêm một số số liệu hữu ích cho cả chúng tôi và nhóm. Hoặc, ví dụ: nhóm có thể không có đủ số liệu cơ bản mà chúng tôi có; họ cần theo dõi một số số liệu cụ thể. Trong Grafana, chúng tôi tạo không gian cho mỗi nhóm và cấp quyền quản trị viên. Ngoài ra, nếu một nhóm cần bảng thông tin nhưng bản thân họ không thể/không biết cách thực hiện, chúng tôi sẽ giúp họ.

Vì chúng tôi nằm ngoài quá trình tạo ra giá trị, phát hành và lập kế hoạch của nhóm, nên chúng tôi dần dần đi đến kết luận rằng các bản phát hành của tất cả hệ thống đều liền mạch và có thể được triển khai hàng ngày mà không cần phối hợp với chúng tôi. Và điều quan trọng là chúng tôi phải giám sát các bản phát hành này vì chúng có khả năng ảnh hưởng đến hoạt động của ứng dụng và làm hỏng thứ gì đó, và điều này rất quan trọng. Để quản lý các bản phát hành, chúng tôi sử dụng Bamboo, từ đó chúng tôi nhận dữ liệu qua API và có thể xem bản phát hành nào đã được phát hành trong hệ thống thông tin nào và trạng thái của chúng. Và điều quan trọng nhất là vào thời điểm nào. Chúng tôi áp dụng các điểm đánh dấu phát hành trên các số liệu quan trọng chính, điều này mang tính biểu thị trực quan rất cao trong trường hợp có vấn đề.

Bằng cách này, chúng ta có thể thấy mối tương quan giữa các bản phát hành mới và các vấn đề mới nổi. Ý tưởng chính là hiểu cách hệ thống hoạt động ở tất cả các lớp, nhanh chóng xác định vấn đề và khắc phục nó một cách nhanh chóng. Suy cho cùng, điều tốn nhiều thời gian nhất không phải là giải quyết vấn đề mà là tìm ra nguyên nhân.

Và trong lĩnh vực này trong tương lai, chúng tôi muốn tập trung vào tính chủ động. Lý tưởng nhất là tôi muốn biết trước về một vấn đề đang tiếp cận chứ không phải sau sự việc đó, để tôi có thể ngăn chặn nó hơn là giải quyết nó. Đôi khi xảy ra cảnh báo sai của hệ thống giám sát, cả do lỗi của con người và do những thay đổi trong ứng dụng. Và chúng tôi xử lý vấn đề này, gỡ lỗi và cố gắng cảnh báo những người dùng sử dụng nó với chúng tôi về điều này trước khi có bất kỳ thao tác nào đối với hệ thống giám sát hoặc thực hiện các hoạt động này trong cửa sổ kỹ thuật.

Như vậy, hệ thống đã được ra mắt và hoạt động thành công kể từ đầu mùa xuân... và đang cho thấy lợi nhuận rất thực tế. Tất nhiên, đây không phải là phiên bản cuối cùng; chúng tôi sẽ giới thiệu nhiều tính năng hữu ích hơn. Nhưng hiện nay, với rất nhiều tích hợp và ứng dụng, việc tự động hóa việc giám sát là điều khó tránh khỏi.

Nếu bạn cũng giám sát các dự án lớn với số lượng tích hợp đáng kể, hãy viết vào phần nhận xét bạn đã tìm thấy viên đạn bạc nào cho việc này.

Nguồn: www.habr.com

Thêm một lời nhận xét