У вас є продукт, який працює. Довкола нього лежать системи, які команда відкриває щодня: CRM, телефонія, бухгалтерський облік, платіжний шлюз, API звітів. Вам пропонують їх з’єднати, і перша оцінка рахує кінцеві точки та поля. У цій оцінці майже немає роботи.

Інтеграція ламається за місяці, і тоді рідко винен сам виклик API: винне рішення, якого ніхто не прийняв. П’ять таких рішень варто закрити до першого запиту, бо після нього вони коштують дорого. Кому належить запис, що робити з чотирма хвилинами недоступності, чи створює повтор другий рядок, чи бачить збій той, хто зобов’язаний його бачити, і якій стороні вірити за розбіжності.

Я під’єднував телефонію, обмін повідомленнями й бухгалтерську систему до одного продукту, збирав платформні інтеграції для інтернет-магазину, переносив API звітів і фонові завдання між сервісами, а результат роботи моделі записував у CRM карткою. Схема щоразу та сама: з’єднання виявляється маленькою частиною, а рішення стають роботою.

1. Кому належить запис, коли його мають обидві сторони

Коли запис живе у двох системах, змінювати його можуть двоє: менеджер уранці править телефон у CRM, а ваша нічна задача записує туди значення, прочитане в березні. Жодна зі сторін не зламана. Обидві дотримуються правила, якого ніхто не записав.

Напрямок кожного поля варто зафіксувати до того, як ви напишете клієнт. Яка сторона створює запис. Яка сторона має право оновлювати які поля. Що станеться, коли поле записують обидві сторони. Правило «останній записав, той і правий» теж правило, і його обирають, а не отримують за замовчуванням.

Те саме вправо з іншого кінця описане в статті про те, що насправді переносить копіювання з форми в CRM: рядок на значення, відповідальний на поле й рішення, які людина додає дорогою. Там цей список пишуть руками. Тут його пишуть до коду.

Видалення обходять стороною найчастіше. Якщо менеджер архивує картку в CRM, ваш продукт продовжує в неї писати. Якщо ваш продукт видаляє рядок, CRM йде за ним. Обидва питання варто проговорити окремо. Дайте відповідь по одному рядку на кожне, до першого запиту.

Корисна перевірка: візьміть десять полів, які повезе інтеграція, і назвіть сторону, якій належить кожне. Якщо на одному рядку стоять два імені, саме там станеться перша сварка. Такий список читають за дві хвилини. І одразу видно порожні місця.

2. Чотири хвилини недоступності: не випадковість, а частина проєкту

Інша сторона буде недоступна. Зазвичай не тиждень, а чотири хвилини, посеред замовлення, у вівторок: це не граничний випадок, який ви виявите у продакшені, а властивість будь-якої системи, якою ви не керуєте.

Вирішіть, що робить ваш продукт у ці чотири хвилини: повертає помилку і пояснює людині, що робити, ставить роботу в чергу і надсилає, коли інша сторона повернеться, або тримає запит до таймауту. Кожен варіант коштує чогось. Жоден не є відсутністю рішення.

Потім вирішіть, хто читає чергу: непрочитана черга це той самий збій, тільки повільніший, тому назвіть людину, інтервал і глибину, після якої він перестає чекати й телефонує. Якщо такої людини немає, черга вам не потрібна.

Перевірте це там, де це нічого не коштує: вимкніть іншу сторону на чотири хвилини й проведіть через неї одне справжнє замовлення. Запишіть, що побачила людина за клавіатурою. Подивіться, що лишилося в черзі, коли все повернеться. Якщо черга порожня і ніхто нічого не помітив, ви ще нічого не перевірили.

3. Повтор має бути безпечним, перш ніж швидким

Таймаут не каже, що інша сторона нічого не зробила. Він каже, що ви не знаєте, що сталося, бо мережа повторює запити, фонове завдання після випуску виконується двічі, а людина тисне оновити, бо сторінка зависла. У всіх трьох випадках запит іде вдруге.

Тому перше питання про запит не про швидкість відповіді. Питання про те, що буде, якщо його надіслати двічі. Якщо відповіддю стане другий рядок, ви витратите другий рахунок на чистку дублікатів. Список, якому команда вже перестала довіряти, чистять вручну. І ця ручна чистка і є ціною пропущеного рішення.

Дайте кожній бізнес-події один ідентифікатор, який інша сторона вже знає: номер замовлення, ідентифікатор дзвінка, телефон із уже нормалізованим кодом країни. Потім зробіть запис умовним за цим ідентифікатором. Одна подія, один рядок. Це працює навіть тоді, коли доставка сталася двічі.

Саме це правило тримає нотатку на картці однією нотаткою, коли той самий дзвінок приходить двічі: так влаштована схема, у якій результат роботи моделі стає карткою в CRM. Повтор там безпечний за побудовою, а не за щастям, і таке саме правило варто поставити до власної інтеграції.

Перевірте це навмисно. Надішліть те саме тіло запиту двічі, з паузою між надсиланнями, і порахуйте рядки. Якщо їх два, дорогу частину знайдено рано. Поки це ще одна функція, а не чистка списку.

4. Збій, який ніхто не бачить, ніхто не виправляє

Десь на шляху запит відхилять, токен мине або завдання впаде посередині. Сайт усе одно покаже успіх, бо сайт закінчив свій крок, а збій лишається в журналі, який ніхто не відкриває, і так він і лишається непоміченим тижнями.

Вирішіть, хто зобов’язаний його побачити, де саме і що з ним можна зробити. Сповіщення в каналі, який команда й так дивиться, краще за файл на диску. Рядок «не надіслано» поруч із записом краще за стек-трейс. Добре, якщо в повідомленні є номер запису, а не лише текст помилки.

Вирішіть, що людина робить, коли побачила збій: перезапускає один запис, не перегравши всю ніч, чи править одне поле і надсилає знову. Якщо єдиний спосіб це розробник і консоль, збій чекатиме, поки про нього не скаже клієнт.

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

Тест: зламайте навмисно одну річ там, де це нічого не коштує, і подивіться, хто дізнається про це без підказки. Якщо ніхто не дізнався, ви знайшли справжню роботу. Саме вона і є предметом наступного рахунку, і її дешевше побачити зараз, ніж за квартал.

5. Коли сторони розходяться, права одна з них

Обидві системи зберігають значення одного поля, і значення відрізняються. Ціна змінилася в обліковій системі. Менеджер поправив телефон у CRM. У вашого продукту лежить ранкове значення. Розбіжність не збій, а звичайний день.

Джерело істини відповідає за кожне поле, а не за систему цілком: облікова система володіє сумою, CRM стадією та відповідальним, ваш продукт тим, що зібрав на джерелі. Запишіть цю таблицю, бо правило «хто записав останній, той і правий» теж таблиця, тільки нечитабельна. Без першої таблиці друга працює сама.

Розбіжність першим показує звіт. Звіт, який читає обидві сторони, не знаючи, яка з них перемагає, покаже два числа за один день. Команда перестане його відкривати. І це вже не питання звіту, а питання правила.

Перевірка: змініть значення з одного боку навмисно, проганіть синхронізацію і подивіться, яке значення виживе, а якщо це когось у кімнаті здивувало, правила ще немає, тож домовтеся про нього до того, як це помітить звіт.

6. Що записати до першого запиту

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

Віддайте цю сторінку тому, хто напише перший запит, і тому, кого розбудять, коли він зламається. Якщо якийсь рядок поки не можна відповісти, це і є знахідка. Відкрите питання і є оцінкою. Закрити його зараз дешевше, ніж у другому рахунку.

Послуги охоплюють таке з’єднання на системах, які ви вже ведете. Обрані роботи показують ті самі рішення поруч із результатом на продукті, який працює. Якщо хочете пройти цей шлях уважно, почніть з інтеграції продукту або напишіть мені. Надішліть сторінку, яку ви щойно заповнили. Паролі та дані клієнтів до повідомлення не додавайте.