Приклад умовний. У компанії є панель залишків, яка оновлюється щогодини. Завдання оновлення щоразу завершується успішно. Але один зі складів перестав надсилати вивантаження: зламалася інтеграція або хтось змінив пароль. Панель виглядає живою, час останнього оновлення свіжий, а товари цього складу показано з учорашніми залишками або взагалі як нульові. Менеджер із закупівель дивиться на панель і замовляє те, що насправді є, або не замовляє того, чого вже немає.
Збою у звичному сенсі не було: жодне завдання не впало, жодне сповіщення не прийшло. Помилився не розрахунок, а вхідні дані, і ніхто про це не дізнався.
Зелений статус відповідає не на те запитання
Статус завдання відповідає на запитання «чи відпрацювало завдання». Людині, яка ухвалює рішення, потрібна відповідь на інше запитання: «чи можна користуватися цим результатом зараз».
Між ними великий розрив. Завдання може успішно перерахувати звіт за даними, які перестали оновлюватися. Може зібрати зведення з трьох джерел замість чотирьох. Може порахувати все правильно, а результат пролежить у черзі так довго, що на момент видачі застаріє. В усіх трьох випадках завдання «зелене».
Тому перевірки свіжості ставлять не замість моніторингу завдань, а поруч: вони дивляться на самі дані, а не на процес, який їх обробив.
Допустимий вік залежить від рішення
Почніть із запитання: наскільки старими можуть бути дані для цього конкретного рішення? Це і є допустимий вік даних. Щоденному звіту для планування й оперативній перевірці наявності товару не обов’язково потрібна одна й та сама межа. Для першого можуть підійти вчорашні дані, для другого й година може виявитися завеликим строком.
Межу встановлює власник процесу, а не розробник. Розробник може підказати, як часто джерело взагалі оновлюється, але лише той, хто ухвалює рішення, знає, яка затримка для нього ще безпечна.
Стара подія сама по собі не помилка. Для аналізу за минулий рік потрібні саме старі дані. Допустимий вік стосується конкретного використання: та сама таблиця може бути свіжою для квартального звіту й застарілою для рішення про сьогоднішнє замовлення.
Три перевірки до розрахунку
Час: коли сталося й коли отримали
Кожен запис має щонайменше два часи: коли сталася подія чи зроблено знімок даних і коли ваша система ці дані отримала. Зберігайте їх окремо.
Нещодавнє завантаження не робить стару подію нещодавньою. Якщо вчорашнє вивантаження прийшло сьогодні вранці, у ньому все одно вчорашні залишки. Якщо рахувати вік за часом завантаження, панель покаже «дані свіжі», хоча вони описують учорашній день.
З’ясуйте й те, що саме означає позначка часу в кожному джерелі. Це може бути час події, час формування вивантаження або час останньої зміни запису. Від цього залежить, як рахувати вік.
Надходження: чи приходять оновлення
Треба знати, як часто кожне джерело зазвичай надсилає дані, і помічати, коли оновлення перестали приходити. Тиша буває двох видів: подій справді не було, наприклад магазин зачинений у вихідний, або джерело замовкло. Без очікуваного графіка надходження ці випадки не розрізнити.
Повнота: чи всі джерела на місці
Перевірте, що до розрахунку потрапили всі обов’язкові джерела й усі потрібні частини бізнесу: усі склади, магазини, юрособи чи регіони, які мають бути у звіті. Часткове завантаження не повинно виглядати як повний звіт. Якщо прийшли дані по трьох складах із чотирьох, підсумок по компанії не можна показувати як підсумок по компанії.
Відсутні дані — не нуль
Найнебезпечніша підміна — перетворити недоступне джерело на нуль. Нуль виглядає як факт: «продажів не було», «залишок закінчився». Насправді це «ми не знаємо».
Якщо обов’язкові дані застаріли, відсутні або прийшли не повністю, результат має два чесні варіанти:
- затримати його й повідомити конкретного відповідального, що не так;
- видати його з явною позначкою про обмеження: якого джерела бракує і що через це в результаті неточно.
Який із варіантів підходить, власник процесу вирішує заздалегідь, для кожного звіту. Важливо одне: така ситуація повинна мати окремий стан, а не тихе продовження роботи. Схожа логіка з «невідомим» результатом потрібна під час передачі даних між системами, ми розбирали її у статті про тайм-аути під час передачі замовлення в ERP.
Ще одна перевірка перед видачею
Якщо вхідні дані пройшли перевірки, результат можна будувати. Але на цьому перевірки не закінчуються. Розрахунок може чекати в черзі, звіт може піти за розкладом через кілька годин, відповідь можуть показати користувачеві набагато пізніше, ніж почався розрахунок. Результат, який був свіжим на початку розрахунку, на момент видачі може вийти за допустимий вік.
Тому вік даних перевіряють ще раз безпосередньо перед тим, як результат побачить людина або отримає наступна система. Якщо межу перевищено, результат притримують і перераховують, а не надсилають як є.
«Дані на …» поруч із відповіддю
Показуйте поруч із результатом час, на який дані актуальні, і їхнє охоплення: «Залишки на 09:00, без складу № 3». Це короткий рядок, але він змінює те, як людина читає цифри. Вона бачить не лише відповідь, а й межі, у яких цій відповіді можна довіряти.
Коли джерело відновилося, недостатньо просто дочекатися наступного планового оновлення. Знайдіть результати, побудовані без нього або з його застарілими даними, перерахуйте їх і знову проженіть перевірки, перш ніж ними користуватися.
Якщо ви будуєте сховище даних на dbt, у ньому є вбудована перевірка свіжості: для джерела чи моделі задається, наскільки старими можуть бути найсвіжіші дані, перш ніж перевірка видасть попередження або помилку. Це добра основа, але вона перевіряє дані у сховищі. Повторну перевірку перед видачею й позначку «дані на …» однаково треба зробити там, де результат показують.
Як перевірити до запуску
Головний тест простий: навмисно зупиніть одне джерело, а завдання звіту залиште працювати. Що зробить система: повідомить, що даних бракує, чи й далі впевнено показуватиме відповідь?
До тестового набору варто включити п’ять випадків:
- свіжі дані: результат видається з позначкою «дані на …»;
- джерело із затримкою: дані прийшли, але старші за допустимий вік;
- зупинене джерело: оновлень немає зовсім;
- часткове завантаження: прийшла лише частина складів чи магазинів;
- дані, які застаріли, поки результат чекав на видачу.
І окремо перевірте відновлення: джерело повернулося, зачеплені результати перераховано, перевірки пройдено знову.
Чек-лист
- Для кожного рішення, яке спирається на звіт, власник процесу встановив допустимий вік даних.
- Час події й час отримання даних зберігаються окремо, і відомо, що означає позначка часу в кожному джерелі.
- Для кожного джерела відомий очікуваний графік оновлень, і припинення оновлень помічають.
- Перевіряється, що до розрахунку потрапили всі обов’язкові джерела й усі потрібні склади, магазини чи юрособи.
- Відсутні дані не перетворюються на нуль.
- Якщо перевірки не пройдено, результат затримують або видають з явною позначкою, і про це дізнається названий відповідальний.
- Вік даних перевіряють ще раз перед видачею.
- Поруч із результатом показано, на який час дані актуальні й які джерела до них увійшли.
- Після відновлення джерела зачеплені результати перераховують і перевіряють знову.
- У тестовому середовищі джерело навмисно зупинили, і система повідомила про нестачу даних, а не видала впевнену відповідь.
З чого почати
Візьміть один звіт чи одну панель, за якими регулярно ухвалюють рішення, і одне таке рішення. Запишіть джерела, як часто кожне оновлюється, допустимий вік даних і того, хто відповідає за результат. Насамперед додайте поруч із результатом рядок «дані на …» з переліком джерел: уже він покаже, де картина неповна. Потім додайте перевірки й проведіть тест із зупиненим джерелом.
Якщо у вас є звіт, який збирається автоматично з кількох систем, подивіться сценарій «Реклама й продажі → звіт» на сторінці автоматизації процесів. Корисне запитання до такого звіту не лише «чи зібрався він», а й «чи можна безпечно користуватися ним просто зараз».