Клиенты ценят надежных партнеров по разработке и развитию сайтов и сервисов. Руководителям компаний важно знать, что цифровой продукт работает как часы. Тогда люди могут сконцентрироваться на главном — развивать бизнес и стремиться к своей мечте.
Мало сделать хороший сайт или сервис — важно гарантировать его стабильную работу и быстро реагировать на аномалии.
Приведу реальный пример.
У нас есть постоянный клиент, связанный с одним из крупнейших предприятий страны. Однажды ночью наша система сообщила, что сайт заказчика упал. Мы узнали о проблеме раньше клиента. Попытались связаться с ним — не получилось. Взяли на себя ответственность и провели анализ проблемы.
Мы нашли причину и восстановили работу ресурса совместно с техподдержкой хостинга сайта. К утру, когда клиент вышел на связь, сайт работал в полном режиме. Если бы мы не отреагировали ночью, то к началу периода основной посещаемости ресурс был бы недоступен.
Хорошо, что мы всегда держим всё под контролем.
Но как?
Если время от времени проверять, работает ли сервис, можно слишком поздно обнаружить проблему. Важно узнать о проблеме ДО того, как сервис упадет.
Что нужно отслеживать?
Есть несколько зон, которые нужно мониторить, чтобы контролировать работоспособность сервиса.
1. Инфраструктура сайта или сервиса
Сервис работает не сам по себе, а на конкретном «железе». Чаще всего работу сервиса обеспечивает не один сервер, а сразу несколько: например, база данных и ее реплики вынесены на отдельные машины.
На каждом из этих серверов крутится большое количество программного обеспечения (веб-серверы, СУБД и т.д.). При нарушении работы любого ПО начнутся проблемы с доступностью сервиса.
Хорошо, что существует огромное число инструментов, позволяющих мониторить серверы. Одно из популярных решений — Zabbix, которым пользуемся и мы.
Zabbix — свободная система мониторинга и отслеживания статусов разнообразных сервисов компьютерной сети, серверов и сетевого оборудования. Для хранения данных используется MySQL, PostgreSQL, SQLite или Oracle Database, веб-интерфейс написан на PHP.
Система Zabbix свободна и бесплатна. А самое главное, она позволяет мониторить все, что угодно!
Работает это так:
- На отдельном сервере устанавливается Zabbix-сервер. Это непосредственный сервер мониторинга, который будет собирать всю статистику и уведомлять, если какие-то значения выходят из допустимого диапазона.
- Параллельно на серверы («узлы») сервиса устанавливается Zabbix-агент, который будет отдавать Zabbix-серверу необходимые метрики.
Что конкретно делает Zabbix?
Zabbix даёт возможность добавить шаблоны к каждому узлу (серверу).
Шаблоны указывают системе:
- какие метрики нужно собрать,
- какие триггеры и при каких значениях запускать,
- какие графики показывать.
После установки Zabbix становятся доступны многочисленные шаблоны для распространенного ПО: Nginx, Mysql, PostgreSQL, а также общие метрики системы.
Разработчик может подключать шаблоны, разработанные сообществом Zabbix Share.
Или написать свой шаблон под конкретный проект. Например, мы создали такой для мониторинга асинхронного приложения в нашем проекте Festa (онлайн-игры для вечеринок в формате видеоконференции).
На каждый узел или группу узлов можно настроить оповещения по событиям. Для оперативности мы настроили отправку всех уведомлений (алертов) в специальную группу в Telegram.
Иногда клиенты просят дублировать сообщения им на почту — все это легко настраивается.
И что тогда получается?
Подключая шаблоны к узлу, мы не просто мониторим доступность серверов, мы держим руку на пульсе.
Например, при мониторинге СУБД мы видим количество подключений. Если оно начнет подбираться к максимальному — в нашу группу сразу прилетит алёрт, и мы сможем исправить ситуацию еще до того, как сервис «упадет». А с помощью сохраненных данных удобно разбираться с уже прошедшими инцидентами.
Здесь мы советуем не лениться.
Настроить мониторинг всего ПО, которое требуется сервису, и все триггеры настроить адекватно. Иначе может сложится ситуация, когда тревожных сообщений прилетает так много, что их просто начинают игнорировать, считая незначительными. Здесь есть большой риск пропустить критическое сообщение.
Поэтому абсолютно каждый алерт должен быть изучен.
2. Приложение сайта или сервиса
Даже на самом лучшем «железе» приложение, написанное с ошибками, будет работать плохо. Заказы не будут оформляться, а на экранах пользователи будут видеть ошибку 500 или 502 («сервис недоступен»).
Ошибки будут появляться всегда. Главное — как можно быстрее о них узнать и устранить.
У нас в вебе ошибки приложения можно разделить на две категории:
- Ошибки бэкенда (приложения на сервере),
- Ошибки фронтенда (ошибки JS в браузере пользователя).
Ошибки бэкенда
Ошибки бэкенда легко получать через стандартные инструменты вашего фреймворка. Наверняка, у него «из коробки» есть такая возможность, как отправка уведомлений об ошибках на почту.
Мы используем для отслеживания бэкенд-ошибок сервис Sentry.io. Он умеет интегрироваться со всеми популярными решениями и удобно группирует события, не забрасывая разработчиков однотипными сообщениями.
Ошибки фронтенда
Sentry.io очень помогает нам и с ошибками фронтенда, которые обычно хитрее бэкенда.
Серверная часть приложения всегда работает на одном окружении. Ошибки там чаще всего понятные и воспроизводимые. В то время как фронтенд выполняется на бесчисленном множестве устройств с разными браузерами, разными расширениями, настройками, качеством интернета и так далее.
Все эти ошибки мы видим и чиним, игнорируя только ошибки с совсем старых устройств (которые мы не поддерживаем) и стороннего ПО (например, расширений браузера — их код мы не можем исправить).
В воспроизведении ошибок, связанных с окружением, нам помогает сервис BrowserStack, на котором мы можем запустить любой браузер на любом устройстве.
3. Бизнес-метрики сайта или сервиса
Даже настроив все вышеперечисленное, нельзя исключить возможность упущенного фактора. Любой сервис работает не сам по себе, а обычно в интеграции с парой-тройкой сторонних систем.
Поэтому желательно ко всем метрикам «железа» и приложения добавить бизнес-метрики. Это метрики, которые показывают выполнение бизнес-задачи сайта или сервиса.
Например, это может быть процент оплаченных заказов за последний час.
Если процент ниже порогового значения, нужно бить тревогу и отправлять алерт через сервер Zabbix.
В корне ошибки могут лежать проблемы с платежной системой. По какой-то причине она не дает пользователям ввести карту и не отдает ошибку в api. Или же в интерфейсе сайта сломали кнопку оплаты, и она не всегда нажимается :)
Такие моменты важно вовремя ловить и чинить.
Что еще нужно предусмотреть?
К сожалению, проблемы бывают не только из-за ошибок разработчиков, но и при инцидентах у хостера.
Конечно, настроив мониторинг, вы сразу увидите, что серверы недоступны. Но ничего сделать с этим не сможете (кроме создания тикета в техподдержке хостера).
Создание и обслуживание копии сайта или сервиса
Тут нужно оценить потери от возможного простоя сервиса из-за проблем в дата-центре хостера. Если они будут дороже, чем держать копию инфраструктуры и ее обслуживание, нужно поднять копию сервиса в другом дата-центре другого хостера. Убедившись, что это действительно разные дата-центры.
Переключение на резервные мощности
Кроме обслуживания копии, нужно подготовить план переключения на резервные мощности с учетом полной недоступности основного дата-центра и регулярно проводить «учения» по переключению.
Пользуйтесь инструментами мониторинга и защищайте бизнес клиентов от неприятных неожиданностей.
P.S. Не забывайте, что систему мониторинга тоже нужно мониторить ;)
.png)
