Сценарий, который я вижу регулярно. Полгода назад знакомый программист за небольшие деньги связал сайт с CRM. Всё работало, все были довольны. А в «очередной понедельник» выяснилось, что заявки в CRM не падают уже несколько дней и никто этого не заметил, потому что заметить было нечем.
Того программиста уже не найти (как правило) и за решением обращаются ко мне. После анализа почти всегда причина оказывается из одного короткого списка. Разберу его, чтобы вы понимали, какие вопросы задать до того, как связку соберут.
Почему именно полгода
Цифра не мистическая. Просто примерно столько живут вещи, которые при запуске выглядели вечными.
Токены доступа выдают на срок. Сервисы обновляют форматы раз в несколько месяцев. Бизнес за полгода успевает подрасти. Всё это время связка работает идеально — ровно до дня, когда одно из этих условий меняется. Тогда она не «начинает барахлить», а останавливается целиком. И тишина.
Отдельная примета этого срока — тарифы. Вполне возможно, что в вашем случае через полгода закончились какие-то стартовые условия: пробный период закрылся, бесплатный план урезали, нужную функцию перенесли в тариф подороже. И связка, которая вчера работала, сегодня получает отказ по причине, не относящейся к её коду.
Причина первая: доступы истекли
Чтобы одна система пустила другую к себе, нужен ключ. В разных сервисах он называется по-разному, суть одна: строчка, которая подтверждает права — «мне можно».
Ключи бывают вечные, но чаще у них есть срок. Иногда полгода, иногда год, иногда до первой смены пароля сотрудника, на чьей учётной записи всё держится. Уволился менеджер, у которого «просто был доступ» — и связка встала.
Сюда же: ключ выпущен на личный кабинет подрядчика, а не на ваш. Пока подрядчик рядом — незаметно. Когда он пропал, ключ никто не продлил и перевыпустить его не на кого.
Как делается правильно. Ключи выпускаются на служебную учётную запись компании, не на живого человека. Срок действия записан там, где вы его увидите. Продление — пункт в календаре, а не сюрприз. Это часть более общего вопроса — кому принадлежат ваши доступы и данные.
Причина вторая: формат обмена изменился
Системы разговаривают друг с другом строго условленными словами — это и есть API, механику я разбирал в статье что такое API простыми словами. Сервис вправе эти слова поменять: переименовать поле, добавить обязательное, отключить старый способ обмена в пользу нового.
Аккуратные вендоры предупреждают заранее — письмом и за несколько месяцев. Письмо приходит на почту, указанную при регистрации — а её обычно указывал тот самый знакомый программист. Вы о переменах узнаёте, когда всё уже упало.
Дальше поведение бывает двух видов. Хорошее: связка честно ругается и пишет в журнал, что не поняла ответ. Плохое: она молча пропускает то, что не разобрала, и продолжает работать «наполовину». Второй вариант хуже — он не выглядит как поломка.
Как делается правильно. Контакт для писем от сервиса — ваш, а не подрядчика. Связка проверяет, что ответ похож на ожидаемый и при расхождении сообщает, а не отмалчивается.
Причина третья: выросли объёмы и упёрлись в лимиты
Почти каждый сервис ограничивает количество обращений, которое к нему можно сделать за минуту или за сутки. На старте у вас двадцать заявок в день, потолок — тысяча. Проблемы нет.
Через полгода заявок двести, к ним добавили выгрузку остатков каждые пять минут, а по средам ещё и рассылку. В какой-то день сумма запросов упирается в потолок. Сервис начинает отвечать «слишком часто, подождите» — и если связку писали без оглядки на этот ответ, она воспримет его как обычный отказ и данные потеряет.
Особенно обидно, что ломается это в момент роста. Бизнес идёт вверх, а инструменты валятся.
Как делается правильно. Связка знает про лимиты, умеет притормозить и повторить попытку позже, а не выбросить данные. Тяжёлые операции разносятся во времени — ночная выгрузка не конкурирует с дневными заявками.
Причина четвёртая: изменилось у вас
Три причины выше — про внешний мир. А ломает работающую связку нередко своё — и это самый неочевидный пункт списка.
Кто-то переименовал поле в CRM, чтобы менеджерам было понятнее. Кто-то сделал поле обязательным. Кто-то перекроил воронку и убрал этап, на который связка складывала заявки. Всё это делается за пять минут и из лучших побуждений — это ваша система, её для того и настраивают.
Беда в том, что «мы там чуть-чуть поправили» никто не связывает с обменом, который упал той же ночью. Связка ищет поле, которого больше нет, — и либо останавливается, либо, что хуже, кладёт данные мимо и продолжает работать как ни в чём не бывало.
Как делается правильно. Связка не молчит, когда не находит ожидаемого, а зовёт человека. А в самих системах поля и этапы, которые участвуют в обмене, помечены в комментарии — чтобы тот, кто их правит, видел, что меняет не только свою настройку.
Причина пятая, главная: некому заметить
Четыре причины выше — техника, и каждая чинится за часы, если о ней узнать. По-настоящему дорого обходится другое: между поломкой и обнаружением зачастую проходят недели.
Заявки не приходят — но менеджеры видят пустую воронку и думают, что просто затишье. Остатки не обновляются — но их и раньше обновляли редко. Единственный, кто знает правду — сама связка, а её никто не спрашивал, потому что спрашивать негде и нечем.
Это то, что отличает работу за небольшие деньги от работы, за которую отвечают. Журнал событий, уведомление о сбое, сверка раз в сутки — вещи скучные, в демонстрации не блещут и стоят денег на этапе, когда всё и так работает. Именно на них экономят, и именно их отсутствие превращает получасовую починку в месяц потерянных заявок. Подробнее про подстраховку я писал в статье про вебхуки.
Что спрашивать у подрядчика
Пять вопросов. Задать их можно до начала работ, ответы отличают связку на годы от связки на полгода.
- На чьи учётные записи выпускаются доступы и когда они истекают? Правильный ответ — на служебные, компании, с записанным сроком.
- Что произойдёт, если принимающая сторона недоступна? Правильный ответ — повторные попытки, данные не теряются, а если попытки исчерпаны — уведомление на служебный адрес и/или ответственному.
- Где я увижу журнал: что и когда передавалось? Правильный ответ — конкретное место, куда можно зайти и посмотреть.
- Как я узнаю, что связка сломалась? Правильный ответ — придёт уведомление. Не «вы заметите».
- Что будет, когда объём вырастет в десять раз? Правильный ответ — упрёмся вот в такие лимиты, вот что тогда делаем.
Внятные ответы обычно означают, что человек уже проходил этот путь. Ответ общими фразами или «навскидку не скажу, надо посмотреть» означает ровно то, что вы подумали.
Если связка уже встала
Первый порыв — звать кого-нибудь переписывать всё заново. Обычно это лишнее: связка редко портится целиком, у неё отказывает одно место из перечисленных выше.
Смотреть стоит по порядку. Жив ли доступ — самый частый случай и самый быстрый в починке. Не менял ли кто-то настройки в системах за последние дни — спросить прямо у сотрудников. Не появились ли отказы «слишком часто» — их видно, если есть куда посмотреть. И только потом код.
Разбор занимает обычно час-два-три. Дорого обходится не починка, а те недели, которые связка простояла незамеченной.
Если ваш случай — обмен между 1С и сайтом, там действуют те же законы плюс свои собственные: разобрал их отдельно в статье про интеграцию 1С и сайта без «костылей».
Если у вас уже есть связка, собранная неизвестно кем и неизвестно как, её можно просто проверить — без переделки. Напишите мне, посмотрим, где она порвётся первой. Обращайтесь, решим вашу задачу!