Безперервність аналітики під час віддаленої роботи

Business Continuity / Data Management / Remote Work / Enterprise Architecture

Нові умови роботи підприємств вимагають перегляду інформаційної стратегії

Березень 2020 року поставив перед підприємствами завдання, які ще кілька місяців тому розглядалися переважно як сценарії кризового планування.

11 березня Всесвітня організація охорони здоров’я охарактеризувала поширення COVID-19 як пандемію. Водночас у різних країнах почали запроваджуватися обмежувальні заходи, які впливають на пересування людей, роботу офісів, транспорт, логістику та організацію виробничих процесів.

Для багатьох підприємств це означає необхідність швидко змінювати звичні способи роботи.

Частина співробітників переходить на дистанційну взаємодію.

Окремі підрозділи працюють за зміненими графіками.

Постачальники й партнери можуть тимчасово змінювати порядок виконання своїх зобов’язань.

У таких умовах особливого значення набуває доступність достовірної корпоративної інформації.

Наприклад, торговельний холдинг має декілька ERP, централізовану CRM та корпоративний Data Warehouse.

Звичайна модель передбачає, що керівники щоденно працюють в офісі, користуються внутрішньою мережею й отримують звіти через локальну BI-платформу.

Проте частина співробітників змушена працювати дистанційно.

Відразу виникають питання.

Чи доступні критичні аналітичні ресурси поза офісом?

Чи може фінансовий підрозділ завершувати звітність без фізичної присутності всіх співробітників?

Чи працюватимуть ETL-процеси, якщо адміністратори не матимуть можливості оперативно приїхати до дата-центру?

Чи здатне підприємство виявити й усунути інформаційну помилку, якщо Data Steward, DBA та бізнесові власники перебувають у різних місцях?

Ці питання стосуються не лише віддаленої роботи.

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

Тому підприємствам необхідно переглянути Business Continuity Planning (BCP) — комплекс організаційних і технічних заходів, спрямованих на продовження критичних бізнесових функцій під час несприятливих подій.

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

Business Continuity та Disaster Recovery — різні поняття

Однією з поширених помилок є ототожнення Business Continuity Planning із резервним копіюванням серверів.

Disaster Recovery справді є важливою складовою стійкості.

Проте він не охоплює всі організаційні питання.

Disaster Recovery

Орієнтований на відновлення відповідних інформаційних систем після технічної аварії.

Наприклад, вихід із ладу серверного обладнання або недоступність основного дата-центру.

Business Continuity

Має ширше призначення.

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

Або через тимчасову недоступність зовнішнього постачальника даних.

Таким чином, для корпоративної аналітики необхідно планувати не лише технічне відновлення, а й підтримання необхідної інформаційної послуги.

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

Визначення критичних інформаційних послуг

Першим практичним кроком є інвентаризація інформаційних процесів.

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

Не всі вони мають однакову критичність.

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

А щоденний контроль дебіторської заборгованості може залишатися необхідним.

Тому доцільно визначити пріоритети.

Це умовний приклад.

Для конкретного підприємства пріоритети повинні визначатися відповідними бізнесовими власниками.

Business Impact Analysis

Необхідно оцінити наслідки недоступності кожного процесу.

Dependencies

Встановити, від яких систем і співробітників він залежить.

Recovery Requirements

Визначити допустиму затримку й час відновлення.

Alternative Procedures

Передбачити відповідні тимчасові способи роботи.

Особливо важливо не створювати однаково складні резервні архітектури для всіх інформаційних наборів.

Ресурси потрібно спрямовувати відповідно до реального бізнесового ризику.

Віддалена робота й захищений доступ до аналітики

У звичайному режимі багато корпоративних систем доступні лише з внутрішньої мережі.

Для дистанційної роботи необхідно забезпечити відповідний контрольований доступ.

Наприклад, фінансовий аналітик повинен працювати з BI-платформою та необхідними звітами.

А Data Engineer — перевіряти ETL і виконувати відповідні операції супроводу.

Проте відкриття внутрішніх баз даних безпосередньо в Інтернеті не є належним вирішенням проблеми.

Для цього потрібна відповідна архітектура.

• Віддалений співробітник
• Керований пристрій · належна автентифікація
• Захищений канал доступу
• VPN / корпоративний шлюз / відповідні політики
• Розмежування повноважень
• Ідентифікація · авторизація · аудит
• BI / Reports
• ETL Monitoring
• BPM / СЕД

Концептуальна модель дистанційного доступу. Прямий доступ користувачів до продуктивних СУБД не є обов’язковою умовою віддаленої аналітики.

Автентифікація

Важливо правильно перевіряти особу користувача.

Для критичних ресурсів можна використовувати багатофакторну автентифікацію.

Authorization

Співробітник повинен отримувати лише необхідні права.

Endpoint Security

Необхідно враховувати стан пристрою, з якого здійснюється доступ.

Logging

Потрібно контролювати відповідні критичні події.

Privileged Access

Адміністративні повноваження повинні мати окремі правила.

Network Capacity

Необхідно оцінити, чи зможе інфраструктура обслуговувати значно більшу кількість віддалених користувачів.

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

Тому технічне рішення повинно включати відповідне навантажувальне тестування.

Доступність BI не означає доступність правильних даних

Для корпоративної аналітики важливо розділяти доступність інтерфейсу та актуальність інформації.

Наприклад, співробітник може успішно відкрити фінансовий звіт через захищений канал.

Але якщо ETL не працював із попереднього дня, результат буде застарілим.

Тому потрібно контролювати декілька незалежних характеристик.

BI Availability

Чи доступна відповідна аналітична система?

Data Freshness

Коли інформацію востаннє оновлено?

Data Completeness

Чи отримано всі обов’язкові джерела?

Data Quality

Чи пройдено необхідні перевірки?

Certified Status

Чи придатний набір для конкретного використання?

Наприклад, для ранкової фінансової панелі можна визначити:

Такі вимоги повинні бути відомими користувачам.

Наприклад, якщо звіт містить попередні дані, це необхідно чітко позначати.

Не слід представляти неповний результат як остаточний.

DataOps: зменшення залежності від ручної роботи

Одним із головних ризиків для Business Continuity є залежність інформаційних процесів від окремих співробітників.

Наприклад, підприємство має критичний ETL, який запускається вручну лише одним спеціалістом.

Якщо ця людина тимчасово недоступна, процес може зупинитися.

Інший випадок — лише один DBA знає порядок відновлення відповідної таблиці.

Для зменшення таких ризиків необхідно використовувати DataOps.

Version Control

SQL, Python, конфігурації та DAG повинні мати контрольовану історію.

Orchestration

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

Automated Testing

Потрібно перевіряти структури, дані й бізнесові результати.

Documentation

Критичні процеси повинні мати зрозумілий опис.

Release Management

Оновлення виконуються відповідно до визначених процедур.

Monitoring

Помилки мають виявлятися без постійної ручної перевірки інтерфейсів.

Recovery

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

Саме тому документація та автоматизація є складовими Business Continuity.

Apache Airflow 1.10.9: керована оркестрація

У березні 2020 року доступна Apache Airflow 1.10.9. Вона вийшла в лютому як коригувальний реліз гілки 1.10.

Наступна Airflow 1.10.10 буде випущена лише у квітні 2020 року.

Для корпоративного BCP Airflow може використовуватися для автоматичного виконання залежних інформаційних завдань.

Наприклад:

ERP Extract
    ↓
Schema Validation
    ↓
MDM Matching
    ↓
DWH Load
    ↓
Reconciliation
    ↓
Certified Publication

Така послідовність допомагає зменшувати ризик випадкового порушення регламенту.

Retries

Можуть використовуватися для тимчасових технічних збоїв.

SLA Monitoring

Дозволяє виявляти певні порушення строків виконання.

DAG Logs

Допомагають аналізувати відповідні помилки.

Backfill

Може використовуватися для повторного виконання визначених історичних періодів. Проте важливо не переоцінювати інструмент.

Airflow не визначає автоматично правильність фінансових показників. Так само повторний запуск не завжди є безпечним.

Якщо ETL не підтримує ідемпотентність, повторне виконання може створити дублікати.

Тому Business Continuity має враховувати і якість даних, і відповідну транзакційну модель.

Apache NiFi 1.11.3: керування інтеграційними потоками

Для корпоративних інформаційних потоків може використовуватися Apache NiFi.

На дату цієї статті доступна NiFi 1.11.3, випущена 26 лютого 2020 року.

Реліз містить виправлення витоків ресурсів і вдосконалення відповідних інтеграційних компонентів.

Для Business Continuity особливого значення мають можливості контролю черг, Data Provenance та параметризації.

Queues

Дозволяють відокремлювати відповідні етапи передавання.

Backpressure

Допомагає обмежувати надмірне накопичення інформації.

Provenance

Дозволяє аналізувати історію відповідних FlowFiles у межах доступного періоду.

Parameter Contexts

Доступні з NiFi 1.10 і можуть спрощувати керування конфігураціями.

Monitoring

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

Для цього необхідно враховувати стан відповідних repositories та інші експлуатаційні характеристики.

Також потрібні відповідні резервні копії й перевірені процедури.

Залежність від зовнішніх джерел

Business Continuity для Data Management повинно враховувати не лише власну інфраструктуру.

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

Тому необхідно визначати поведінку аналітичної системи.

Останній підтверджений стан

За відповідних умов можна використовувати останній перевірений набір.

Freshness Warning

Користувачі повинні бачити, що інформація застаріла.

Часткова готовність

Можна окремо відображати дані доступних джерел за умови правильного позначення обмежень.

Відкладене завантаження

Після відновлення джерела виконується необхідний Backfill.

Reconciliation

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

Необхідно перевірити повноту всього пропущеного періоду.

Тому для критичних інтеграцій потрібні відповідні інформаційні контракти.

RPO та RTO для аналітичних послуг

Для Business Continuity необхідно визначати цільові показники відновлення.

Recovery Point Objective

Описує допустиму точку втрати інформації в разі аварії.

Recovery Time Objective

Визначає цільовий час відновлення послуги. Проте для Data Management потрібні додаткові характеристики.

Наприклад, після відновлення DWH повинно бути не лише доступним, а й правильно заповненим.

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

Особливо важливо перевіряти їх виконання практично. Наприклад, наявність резервної копії не гарантує, що СУБД можна відновити в потрібний час.

Тому необхідні відповідні Recovery Tests.

Business Continuity для Data Stewardship

Одна з менш очевидних проблем — залежність контролю якості від відповідальних фахівців. Наприклад, MDM щоденно виявляє кілька неоднозначних клієнтських відповідностей.

Зазвичай їх перевіряє один Data Steward. Проте під час тимчасової відсутності співробітника відповідні винятки можуть накопичуватися.

Тому необхідно організовувати заміщення.

Розподіл повноважень

Потрібно визначити, хто може приймати відповідні рішення.

Документовані правила

Matching і Survivorship повинні мати зрозумілу методику.

BPM / Workflow

Для складних випадків можна використовувати відповідні процеси погодження.

Audit Trail

Необхідно документувати критичні рішення.

Escalation

За визначених умов виняток передається іншому уповноваженому спеціалісту.

Remote Access

Співробітники повинні мати безпечну можливість працювати з відповідними інструментами дистанційно.

Таким чином, Data Stewardship повинно бути корпоративним процесом, а не неформальною функцією однієї людини.

Інформаційна безпека під час дистанційної роботи

Швидкий перехід на дистанційні способи взаємодії створює додаткові ризики. Наприклад, працівники можуть почати передавати корпоративні Excel-файли через особисті поштові скриньки або зовнішні сервіси, не передбачені інформаційною політикою підприємства.

Для критичних наборів це може бути неприйнятним.

Корпоративні канали

Потрібно використовувати належним чином визначені засоби передавання.

Access Control

Повноваження повинні відповідати ролі користувача.

Data Minimisation

Не слід експортувати повні таблиці, якщо потрібен лише агрегований звіт.

Endpoint Protection

Необхідно враховувати стан пристроїв.

Audit

Важливо контролювати відповідні критичні дії.

Backup

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

Проте дистанційна робота сама по собі не означає порушення GDPR.

Важливими є фактичні цілі, способи обробки та відповідні заходи захисту.

Практичний сценарій: BCP для корпоративного Data Warehouse

Розглянемо умовний холдинг із кількома ERP, централізованою CRM та DWH.

Компанія змушена перевести значну частину співробітників на дистанційну роботу.

Етап 1. Бізнесова критичність

Визначаються необхідні інформаційні послуги.

Етап 2. Data Ownership

Для кожного критичного набору призначаються відповідальні.

Етап 3. Remote Access

Налаштовується захищений доступ.

Етап 4. Network Capacity

Перевіряється пропускна здатність відповідних каналів.

Етап 5. ETL Inventory

Документуються критичні інформаційні процеси.

Етап 6. Airflow / Orchestration

Автоматизується регламентне виконання.

Етап 7. Data Quality

Встановлюються відповідні контрольні перевірки.

Етап 8. Data Steward Backup

Визначаються уповноважені замінники.

Етап 9. Monitoring

Налаштовується дистанційний контроль.

Етап 10. Incident Management

Документується порядок реагування.

Етап 11. Recovery Testing

Перевіряється відновлення необхідних інформаційних послуг.

Етап 12. External Dependencies

Оцінюються ризики недоступності постачальників даних.

Етап 13. Business Communication

Користувачі отримують інформацію про стан відповідних наборів.

Етап 14. Review

План оновлюється за результатами практичної роботи.

Така модель допомагає зменшувати залежність корпоративної аналітики від звичайного офісного середовища.

KPI Business Continuity для Data Management

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

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

Компетенції Intecracy Group у Business Continuity

Забезпечення безперервності корпоративних інформаційних процесів потребує кількох технологічних спеціалізацій. Data Management IG (dmig.com.ua) спеціалізується на ETL, MDM, Data Quality, DWH та корпоративній аналітиці. Ці напрями важливі для підтримки інформаційних конвеєрів, контролю якості, історичності та правильності аналітичних результатів під час нестандартних умов роботи.

IQusion IT (iqusion.com) працює у сферах системної інтеграції, електронного документообігу та BPM. Відповідні компетенції можуть використовуватися для автоматизації віддалених бізнесових процесів, погоджень, документообігу й роботи з інформаційними винятками. Softline IT (softline.kiev.ua) має компетенції в серверній, мережевій інфраструктурі та системах зберігання. Вони забезпечують основу для віддаленого доступу, продуктивності СУБД, резервування й відповідних механізмів Disaster Recovery.

SL Global Service (sgs4business.com) спеціалізується на хмарній інтеграції, віртуалізації та гібридній інфраструктурі. Такі напрями можуть використовуватися для створення резервних середовищ і контрольованої дистанційної доступності відповідних сервісів.

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

Практичні орієнтири для впровадження

Події березня 2020 року підкреслюють значення Business Continuity для корпоративних інформаційних систем.

Пандемія COVID-19 та пов’язані з нею зміни організації роботи змушують підприємства переглядати залежність критичних процесів від фізичної присутності співробітників. Для Data Management це означає необхідність забезпечувати доступність аналітики, автоматизоване виконання ETL, контроль Data Quality та належні процедури відновлення.

Apache Airflow 1.10.9 і NiFi 1.11.3 можуть використовуватися як компоненти відповідної технічної архітектури.

Проте програмні інструменти не замінюють організаційної відповідальності.

Для успішного BCP необхідні Data Ownership, документовані Runbooks, підготовлені замінники та відповідні процедури Incident Management.

Особливе значення має контроль Data Freshness і правильності інформації.

Головний принцип Business Continuity для Data Management полягає в тому, що підприємство повинно зберігати можливість отримувати своєчасні й достовірні корпоративні дані незалежно від того, де перебувають співробітники та які тимчасові обмеження впливають на звичайну організацію роботи.