Когда интеграция меняется под тобой

Поломка, которая о себе не сообщает

Остановившаяся автоматизация - маленькая беда. Она встала, в течение часа кто-то заметил, причина очевидна, потому что сломалось то, что меняли последним.

Дорогая поломка - та, что продолжает работать. Наверху переименовали поле, читающий его код получает пустоту, а пустота в большинстве процессов легальна: незаполненный комментарий, невыставленный флаг, отсутствующая вторая строка адреса. Ошибки не возникает. Процесс выдаёт записи, неотличимые от прошлонедельных, и делает это ровно столько, сколько нужно человеку, чтобы сверить руками два числа.

Что меняется на самом деле

Почти всё сводится к четырём формам.

Поле переименовали или перенесли - обычно при уборке, которую никто не считал внешней. В ответе появился лишний уровень вложенности, когда поставщик добавил обёртку для постраничности или метаданных. В перечислении завелось новое значение, новый статус заказа или новый тип документа, и ветка, разбирающая известные значения, молча роняет неизвестное. Версия API ушла на покой, а запасным вариантом оказалась старая форма вместо ошибки.

Ни одно из этого не авария. Каждое - вторник во второй половине дня в чужих примечаниях к релизу.

Три защиты, все дешёвые

Одна запись, весь маршрут, каждое утро. Искусственный объект, проходящий путь целиком и проверяемый на выходе против известного ответа. Он нагружает стыки между системами, а дрейф живёт на стыках. Четыре по отдельности здоровых сервиса вполне могут передавать друг другу то, что изменилось.

Проверять форму, а не статус. Двести с разбираемым телом не доказывает, что тело означает то же, что месяц назад. Проверяйте, что читаемые поля на месте и нужного типа, и падайте громко, когда это не так. Это десять строк, и они превращают тихий неверный ответ в видимую остановку.

Предупреждать по распределению, а не по исключениям. Если в прошлом месяце в ручной маршрут уходил один объект из двадцати, а сегодня уходит один из шести, - вот сигнал, и ни одно исключение при этом не поднялось. Работает это только тогда, когда обычные числа записали заранее, а довод в пользу этого приведён в тексте про измеренную базу.

Почему это вопрос границ, а не сопровождения

Любая интеграция - это зависимость от чужого расписания релизов. Плохой идеей её это не делает: доставка в аренде из текста куда уходят четыре часа читает наличие из системы, которой мы не управляем, и всё равно окупается. Это делает зависимость тем, что надо оценить.

Практическая версия: когда границы процесса согласуются, перечислите, что он читает извне себя, и для каждого пункта скажите, что произойдёт при смене формы. Про большинство ответ будет «встанет, и пусть встанет». Те, где ответ звучит как «поедет дальше, и мы не узнаем», требуют проверочной записи до запуска, а не после первого плохого месяца.

То, что называть не хочется

Процесс, за который не отвечает ни один человек, проверяет тот, кто случайно посмотрел, а на практике - клиент своей жалобой. Имя попадает в документ передачи вместе со всем остальным, и принадлежит оно тому, у кого есть мнение о конструкции, а не тому, кто был свободен на той неделе. Довод в пользу того, чтобы считать это этапом, а не последним днём, лежит в тексте что обязан произвести аудит процессов, а дописать это потом нельзя: человек, забывший, что было непонятно, уже не может это записать.