Автоматизация всегда падает: вопрос лишь в том, узнаете ли вы об этом
Любая интеграция однажды ломается: у площадки кончился лимит, сервис ответил ошибкой, сеть моргнула. Разница между рабочей автоматизацией и красивой демкой не в том, ломается ли она, а в том, что происходит потом. Разбираю на своём хозяйстве: ретраи, очередь, журнал сбоев и уведомления, которые не хочется отключить на второй день.
Кто узнает, когда всё-таки не вышло
Дальше начинается то, что обычно делают хуже всего - уведомления. Я долго жил с сообщениями вида "ошибка в процессе, подробности в логе" и на третий день перестал их открывать. Бесполезное уведомление хуже его отсутствия: оно создаёт ощущение контроля, которого нет.
- Что именно упало.Не "процесс постинга", а "статья такая-то, площадка такая-то". Человек должен понять контекст, не открывая систему.
- На каком шаге.Отправка, подготовка текста, загрузка картинки. Шаг сужает поиск причины в разы.
- Что ответил сервис.Настоящий текст ошибки, а не пересказ. Именно он отвечает на вопрос "это чинится само или руками".
- Куда нажать.Ссылка прямо на карточку записи. Без неё сообщение превращается в задание "найди сам".
И обратное правило: ожидаемые отказы не должны звенеть вообще. У одной площадки тариф ограничивает число публикаций в сутки - система помечает такую отправку неуспешной и молчит, потому что делать с этим нечего. Уведомления имеют смысл ровно до тех пор, пока каждое из них требует действия.
Что это даёт
Главный эффект не в цифрах, а в доверии. Автоматизацией, которая молча теряет работу, пользоваться нельзя - её приходится перепроверять, и она перестаёт экономить время. Как только сбои становятся видимыми и обратимыми, систему можно оставить работать одну.
Что забрать себе
- Разделите отказы.Пройдитесь по своим сценариям и отметьте, где сбой временный, а где окончательный. Это полчаса работы и половина всей надёжности.
- Дайте задаче состояние.Взята, отправлена, подтверждена. Без него повтор опасен, а значит его не будет.
- Заведите очередь и сторожа.Пусть просроченное подбирается само, а не по вашему напоминанию.
- Перепишите уведомления.Контекст, шаг, настоящая причина, ссылка. И тишина там, где действие не требуется.
Ни один из пунктов не требует сложных технологий - всё это делается в том же инструменте, где у вас уже живёт автоматизация. Требуется другое: заранее признать, что ломаться будет, и потратить день на то, чтобы поломка стоила две минуты вместо потерянного клиента.
Похожая задача?
Если у вас есть автоматизация, которой вы не доверяете и потому перепроверяете руками - опишите задачу в оценщике. Отвечу с планом, вилкой стоимости и расчётом экономии.
Любая интеграция однажды ломается: у площадки кончился лимит, сервис ответил ошибкой, сеть моргнула на две секунды. Это не признак плохой работы - это нормальный режим жизни системы, которая ходит наружу. Разница между рабочей автоматизацией и красивой демкой не в том, ломается ли она, а в том, что происходит в следующую минуту.
Ломается не код, а стыки
Внутри своего кода всё предсказуемо: данные те, что положили, логика та, что написали. Проблемы начинаются там, где система встречается с чужой: почтовый сервер, мессенджер, платёжный шлюз, нейросеть. У каждого свои лимиты, свои редкие пятисотые и своё представление о том, сколько можно думать над ответом.
Поэтому надёжность - это не "написать без ошибок". Это заранее решить, что делать с чужими ошибками, и ответить на три вопроса по каждому стыку: отказ временный или окончательный, можно ли повторить безопасно и кто узнает, если повторы не помогли.
Временный отказ и окончательный - разные истории
Самая частая ошибка проектирования - считать любой сбой поводом остановиться. У меня был показательный случай: восемь площадок одновременно попросили у нейросети текст под свой формат, шлюз ответил "слишком много запросов", и все восемь публикаций встали намертво с красным статусом. Формально система отработала честно. По сути - потеряла материал на ровном месте, потому что через минуту тот же запрос прошёл бы спокойно.
- Временный.Превышен лимит запросов, таймаут, обрыв связи, пятисотая ошибка на стороне сервиса. Такое лечится ожиданием: повторить через минуту, потом через пять.
- Окончательный.Неверный ключ доступа, площадка отказала по правилам, текст не проходит модерацию. Повторять бессмысленно - нужен человек.
- Неизвестный.Сервис ответил чем-то нечитаемым. Пара попыток, и если не помогло - относимся как к окончательному.
Разделение выглядит очевидным ровно до того момента, когда его надо описать в коде. Именно на этом шаге выясняется, что "ошибка" в вашей системе - это одно слово на все случаи жизни, и любое решение по ней принимает человек вручную.
Повтор должен быть безопасным
Второе правило важнее первого: повторять можно только то, что не сделает работу дважды. Если запрос успел дойти, а ответ потерялся по дороге, слепой повтор превращается в два одинаковых письма клиенту или два одинаковых поста в ленте.
Поэтому у каждой операции должно быть состояние, а не только результат: взята в работу, отправлена, подтверждена. Тогда повтор - это не "выполнить ещё раз", а "досделать то, что не дошло". У меня публикация в соцсети хранит и статус, и счётчик попыток, и площадка отвечает своим идентификатором поста - по нему видно, что дубля не будет.
Проверьте себя
Возьмите любой свой автоматический сценарий и мысленно оборвите ему связь ровно в середине. Если после этого нельзя нажать "повторить" не думая - у сценария нет состояния, и однажды он сделает работу дважды.
Очередь вместо героизма
Третья опора - очередь. Не как модное слово, а как простая таблица: что нужно сделать, когда можно попробовать снова, сколько раз уже пробовали. Отдельный сторож раз в несколько минут забирает оттуда просроченное и запускает заново.
Это скучная конструкция, но именно она превращает хрупкую цепочку в систему, которая переживает ночной сбой провайдера без единого потерянного письма. И она же снимает с вас необходимость сидеть рядом: пока очередь разбирается сама, ваше внимание не нужно.
Новые разборы - на почту
Разборы задач автоматизации: что автоматизировать, сколько это стоит и что даёт в цифрах. Одно письмо на статью, без рекламы чужих продуктов.
