Меня зовут Женя Космак, я менеджер продукта, и я написал эту статью, описывая свой опыт работы в качестве технического менеджера продукта. Вы можете связаться со мной на LinkedIn, если хотите обсудить свой проект или что-то связанное с этой статьей. И я буду рад поделиться с вами некоторыми советами 🙃
Если ваша команда разработчиков потратила несколько тысяч часов на ваш продукт, и он уже запущен в производство, то вопрос его стабильности уже достаточно значим. Все сервисы на серверах должны работать стабильно, а если где-то есть критическая проблема — команда разработчиков должна выяснить ее и начать исправлять. В этой статье мы расскажем о нашем опыте настройки системы оповещения Calibra. В данном случае нам удалось не только обеспечить техническую стабильность продукта, но и оптимизировать затраты и улучшить процессы нашего клиента.
Эта статья входит в цикл «Система оповещения: почему она нужна и разработчикам, и владельцам продукта». В статье рассказывается о том, как система оповещения может пригодиться, когда сложно держать все под рукой.
Чтобы облегчить понимание проблем, которые мы решали, нам нужно рассказать самое необходимое о продукте. Calibra — это BPMS, то есть система, которая охватывает большинство рабочих процессов нашего клиента. Компания клиента управляла многочисленными рекламными кампаниями для своих клиентов в их интересах. Компания клиента зарабатывала с каждого приведенного им лида. Calibra управляла счетами, с которых запускалась реклама; всеми настройками рекламы; автоматически меняла объявления; собирала статистику об эффективности рекламы и многое другое.
Как это работало в целом
В ДВУХ СЛОВАХ:
- Мы собирали метрики на каждом сервере системы с помощью универсальных инструментов. Каждая метрика отправлялась в централизованное хранилище.
- Любую неожиданную ситуацию мы называли «событием-оповещением». Оно имеет дату и время начала (когда произошла проблема) и окончания (когда проблема была решена).
- Мы использовали централизованные настройки для отправки уведомлений о таких событиях. Когда происходило что-то неладное, мы отправляли сообщение на канал в Slack. То же самое происходило, когда ситуация разрешалась.
В результате клиент оставался в курсе проблем продукта. И под этим мы подразумеваем не только технические проблемы, но и проблемы бизнеса клиента как такового.
«Напоминания» о необходимости платить за сторонние инструменты
Почти все продукты сейчас используют инструменты сторонних разработчиков — это выгодно, учитывая экономию на стоимости разработки. Calibra имеет дюжину таких интеграций. Некоторые из них можно оплачивать ежегодно; счета за некоторые выставляются по непредсказуемому графику. Нашему клиенту приходилось использовать несколько кредитных карт, потому что не все сторонние компании могли выставлять счета по каждой карте.
Поэтому наш клиент неизбежно забывал пополнить баланс некоторых кредитных карт или иногда ошибался с суммой платежа. В результате сторонний инструмент перестает работать до тех пор, пока не будет произведен платеж. Поскольку нам нередко приходилось менять сторонних партнеров, мы решили, что этот риск должен быть покрыт автоматизированным решением.
Поскольку такая ситуация не должна рассматриваться как реальная долгосрочная угроза, мы договорились, что управление будет осуществляться постфактум. Когда происходит ошибка в платеже — мы информируем клиента. Поэтому мы разработали такой простой процесс:
- Счет не прошел, после чего 3-я сторона перестала работать.
- API третьей стороны перестает работать, система оповещения по коду ошибки определяет, что это неплатеж.
- Клиент и мы узнаем об этом с помощью уведомления в Slack. Клиент может решить эту проблему немедленно.
- В результате интеграция возобновляет работу в кратчайшие сроки.
При таком типе оповещения вам требуется минимальное количество ложных срабатываний. Когда вашему сотруднику приходится проверять проблему сразу же после уведомления, это не должно стать рутиной. Если такие оповещения происходят часто, проблему следует решать другим способом. Например, клиент может нанять отдельного клерка, который будет этим заниматься. Но когда у вас 1-3 оповещения в месяц, как это должно быть на растущем продукте, такое решение — то, что нужно.
В нашем случае такие ситуации возникали постоянно, но они не наносили существенного вреда стабильности. Таким образом, благодаря системе мониторинга мы обезопасили стабильность продукта от человеческого фактора в этом вопросе.
За этим решением стояло несколько примечательных технических аспектов. Один из сторонних инструментов, который мы использовали, отвечал HTTP-кодом 401 (Unauthorized). Обычно это означает, что вы указали неверные учетные данные, например, неправильный пароль в запросе. Мы перепроверили свои учетные данные, и они были в порядке. Обратившись в службу поддержки, мы выяснили, что такой ответ означает истекший срок подписки. По их логике, если пользователь не оплатил подписку, то такого пользователя больше не существует, поэтому ответ с кодом 401 правомерен. Ха, такое бывает. Поэтому мы добавили этот случай в систему оповещения. Кроме того, мы задокументировали, почему это решение было построено таким странным образом.
Другой случай. Одна из сторонних компаний стала часто выдавать предупреждения. Как мы выяснили, команда третьей стороны не справлялась с растущей нагрузкой и неоднократно отвечала с ошибкой «Gateway timeout». Мы только что внесли изменения, согласно которым мы рассматриваем ответы как события-тревоги только в том случае, если в течение часа не было получено 200 ответов.
Таким образом, чтобы создать надежную систему оповещения, вы должны хорошо знать своих третьих сторон.
Итог
Это может показаться чем-то несущественным. Но когда в понедельник вы узнаете, что все выходные некоторые лендинги не работали, так как не прошел платеж Cloudflare, а маркетинговые бюджеты на два дня потрачены впустую… Вы измените свое мнение.
Того же самого решения можно добиться и другими способами. Но гораздо удобнее, когда у вас есть обобщенное решение, которое можно настроить в любой момент.
Если вам нужно что-то подобное для вашего продукта, мы с удовольствием это обсудим.