Автоматизації, за якими не треба наглядати: п'ять звичок

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

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

1. Кожен крок має бути безпечним для повторного запуску

Мережа відвалюється, вебхуки приходять двічі, і рано чи пізно хтось натисне «повторити». Якщо повторний запуск створює другий рахунок, другий лист чи другий контакт у CRM, кожен повтор стає ризиком, і люди перестають повторювати. Крок ідемпотентний, коли його повторення дає той самий результат, що й одне виконання.

• Дайте кожній одиниці роботи стабільний ключ — номер замовлення, id повідомлення — і не обробляйте той самий ключ двічі
• Там, де дозволяє цільова система, обирайте «встановити статус «оплачено»» замість «додати платіж»
• Якщо API підтримує ключі ідемпотентності, завжди їх передавайте

2. Повторюйте тимчасове, зупиняйтеся на постійному

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

3. Збій потрапляє туди, де його побачить людина

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

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

4. Зберігайте журнал того, що зробила автоматизація

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

5. Ставте людину туди, де помилка дорога

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

• Зворотне й з низькими ставками — повністю автоматично
• Зворотне, але видиме клієнтам — автоматично, з простим скасуванням
• Незворотне або фінансове — готується автоматично, підтверджує людина

Інструмент обирають потім

Ніщо з цього не залежить від того, на чому зроблена автоматизація — no-code платформі, рушії воркфлоу чи кількох сотнях рядків коду. Кожен варіант можна зробити надійним або крихким. Різниця в тому, скільки надійності ви отримуєте безкоштовно, а скільки доведеться будувати. Цей вибір варто робити свідомо — після того, як на п'ять запитань вище є відповіді.