Як зробити проєкт на Operational Intelligence

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

Оскільки в час локдауну будь-які відрядження призупинені, нашій команді (як і багатьом іншим нині) довелося адаптуватися до роботи у дистанційному форматі. Проєкт мав бути коротким — лише чотири тижні, з фокусом на EngX (Engineering Excellence — найкращі інженерні практики та підходи до написання коду, тестування тощо). Проте скоро завдання, яке стояло перед нашою командою, кілька разів змінилося. І в результаті фокус змістився з EngX на Operational Intelligence.

Перед тим як розповісти більше деталей про те, що ж це за напрям, напишу кілька слів про себе. Останні 6 років я співпрацюю з ЕРАМ як бізнес-аналітик. Не так давно долучився до Operational Intelligence практики і торік у грудні успішно пройшов сертифікацію Splunk Core Certified Consultant. До цього займався розробкою та впровадженням бізнес-процесів на виробництвах, втіленням ERP-систем (Oracle та 1С).

Operational Intelligence — новий напрям в ЕРАМ, який займається вирішенням проблем контролю та моніторингу бізнес- та операційних процесів у компанії, аналізом і візуалізацією моніторингових метрик для ухвалення оптимальних рішень з боку керівництва компанії та багато іншого.

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

Знайомство та перше завдання

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

Оскільки це велика компанія, вона, звичайно ж, дорожить своїм іміджем. Один з пріоритетів для неї — вчасна доставка замовлення клієнту. Тому найнапруженіші періоди в роботі клієнта — це сезони розпродажів, а всесвітньо відомий Black Friday лише один з них. Тоді кількість замовлень іноді зростає у 10 разів, і будь-які збої систем можуть дорого коштувати. Це стосується як фінансової частини — зменшення продажів, простій людей, обладнання та транспорту, так і репутаційної — невчасно або не у повному обсязі доставлені замовлення, а відтак незадоволені клієнти. Тож за кілька місяців до наступної такої події клієнт вирішив зробити аудит технічної екосистеми, оцінити її стан і готовність до масштабування в разі потреби.

Заглиблення в інфраструктуру і бізнес-процеси. Зміна фокусу

Межі процесу, який досліджувала наша команда, були від моменту, коли клієнт розмістив своє замовлення до виїзду товару зі складу. Тут виділимо такі кроки:

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

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

Monitoring DNA

Перша складність, з якою ми стикнулися у клієнта, — це відсутність уніфікованого підходу до логування та моніторингу. Три команди були зовсім не схожі одна на одну. Одна команда використовувала Splunk для логування та вже мала декілька добрих дашбордів, друга мала гірші дашборди з меншим покриттям. Третя команда використовувала тільки Elasticsearch з кількома дашбордами. Через відсутність центрального репозиторію логів не було бачення, як всі системи живуть разом та працюють інтегровано. Підхід у моніторингу здебільшого був реактивний: якщо з’являлися помилки при друку етикетки, то про це дізнавалися вже з телефонного дзвінка зі складу: «В нас не друкуються етикетки». Інколи були потрібні години, щоб тільки з’ясувати, в якій саме системі чи компоненті виникає помилка. Наявні дашборди не завжди могли дати відповідь через відсутність більш широкої картини. Інколи через такі інциденти склад повністю зупинявся і не міг опрацьовувати відправлення.

Ми вивчали наявні дані у різних системах та збирали інформацію про всі інструменти, якими користувалися команди. Щоб систематизувати всю інформацію, ми створили таблицю, яку назвали Monitoring DNA:

1. Data Gathering.
2. Application Monitoring:
   
   • Distributed Tracing;
   • Data Flow Monitoring;
   • App Health Monitoring;
   • Log analysis.
3. Platform Monitoring:
   
   • System Health.
4. Reporting:
   
   • KPI/SLA Reporting;
   • Ticketing;
   • Visualization;
   • Alerting & Escalations.
5. Robotization / Automation.

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

Були дві основні проблеми, що заважали впровадженню Е2Е моніторингу.

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

Наша команда підготувала звіти та артефакти, які ілюстрували ідентифіковані проблеми. Одним з таких звітів була матриця, яка відображала стан моніторингу за командами та загалом:

Пізніше ми використали цю матрицю для підготовки кроків для уніфікації логування і моніторингу. Мета — стандартизація та документування формату логів з різних систем та скерування їх у єдиний ресурс.

E2E Dashboard PoC

Аналізуючи наявні проблеми, ми не могли не думати про те, якими можуть бути швидкі (Quick wins) та стратегічні (Long term) рішення.

Для верифікації одного із них ми вирішили створити PoC (Proof of Concept) дашборду, що показував дані з більшого переліку систем та аналізував дані на основі повних транзакцій (що на той час ще були розірвані).

«Розкидані» дані в одну дата-модель. Через «розкиданість» даних по різних системах перше, що нам потрібно було, — це зрозуміти, яким чином ми змогли б консолідувати дані з усіх систем в одну дата-модель. Зважаючи на певні обмеження, ми запропонували кілька варіантів для подальшої роботи. Оптимальним було лімітування проміжку часу, за який ми маємо консолідувати дані та «ручний» імпорт підготовленої статистики по компонентах з інших систем. Клієнт обрав саме цей сценарій, і ми почали активну роботу над PoC. Ми затребували вибірку від команди підтримки за статистикою інцидентів. З її допомогою разом з клієнтом обрали 4 тижні, де були зосереджені кілька вагомих аномалій (маю на увазі розпродажі чи подібні івенти, коли збільшується кількість замовлень).

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

Поєднання окремих івентів в одну транзакцію. Наступною задачею, яку нам пізніше довелось допомагати глобально вирішувати для клієнта, було поєднання окремих івентів у транзакцію. Річ у тому, що один запит, проходячи через різні внутрішні системи, не мав унікального ключа у логах, що дозволив би зв’язати всі івенти в одну транзакцію і в разі неуспішного опрацювання замовлення швидко зрозуміти, на якому кроці виникає помилка. Ми почали збирати всі ідентифікатори і ключі для аналізу можливості об’єднання усіх івентів з їх допомогою. Щоб правильно зробити калькуляції тривалості обробки запитів у різних компонентах, запитали мапінг лог-івентів до їхніх значень з точки зору бізнес-процесів. Це дозволило виділити ключові івенти та відкинути зайві. Проте у поточних умовах без змін у логуванні нам вдалося зв’язати у транзакції тільки 80–90% івентів. Але через використання проміжних ключів пошук та поєднання частин транзакцій забирав багато часу — замовлення за 4 години оброблялися близько 2 хвилин. Тож робота у реальному часі з довільним проміжком часу без попередніх змін у логуванні бачилася неможливою.

Через відсутність затверджених метрик ми запропонували ключові за методологією Golden Signals, і ними стали:

• Кількість успішних транзакцій (Successful count).
• Кількість невдалих транзакцій (Failed count).
• Тривалість опрацювання у секундах (Duration).

Щоб зробити аналіз більш ефективним та поглибленим, на дані ефективності роботи компонентів ми наклали таку інформацію:

• Інциденти різного ступеня важливості.
• Релізи.
• Заплановані маркетингових компанії та розпродажі.
• Інфраструктурні метрики з NewRelic.

І наш PoC дашборд дав перші результати:

• Ми ідентифікували проблему з інфраструктурою, яка до того не аналізувалась на потрібному рівні та під час підвищення навантажень у певних сервісах негативно впливала на роботу системи в цілому.
• Були виявлені проблеми, пов’язані з якістю даних, що були адресовані командам для виправлення.
• Були ідентифіковані сервіси, де обривався або зовсім не існував унікальний ключ транзакції, для подальшого виправлення помилок.
• Проаналізована тривалість обробки запитів у різних системах і компонентах, впроваджені базові KPI/SLA та підготовлені їх цільові значення.
• Проведена оцінка якості релізів та ідентифіковані певні залежності.

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

Бізнес-проблеми та шляхи вирішення

Паралельно з роботою над PoC ми проводили інтерв’ю з різними командами та групами та намагалися зрозуміти, які інструменти та системи вони використовують у роботі. Що їм допомагає працювати і чого не вистачає, які основні «болі», з якими вони стикаються систематично. В кінці цього аналізу ми отримали пріоритизований перелік проблем:

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

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

Через тиждень після презентації остаточних результатів до нас повернувся з клієнт з пропозицією продовження співпраці :)

Продовження співпраці та допомога клієнту з покращенням моніторингу

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

• Стандартизували, задокументували та впровадили підхід до логування за ключовими командами та системами.
• Запровадили єдиний ключ транзакції у всіх івентах.
• Визначили та запровадили бізнес-івенти — це ключові події, що дають можливість швидко ідентифікувати успішність того чи іншого запиту.
• Ідентифікували та запровадили унікальні ідентифікатори для бізнес-транзакцій. Поява таких атрибутів значно полегшила та пришвидшила пошуки та вирішення проблем.
• Запровадили дата-моделі, що значно спростили пошук та прискорили створення звітів.
• Розробили інтерактивні дашборди для візуалізації Е2Е здоров’я системи та її компонентів, інструмент пошуку транзакцій за всіма доступними бізнес-ключами.
• Впровадили спеціалізований дашборд для вирішення проблем із замовленнями. Розпочали працювати над автоматизованою базою знань з корегувальних дій, а також над інтеграціями з автоматизованою системою керування запитами і оперативного сповіщення.

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

Підсумовуючи

Operational Inteligence проєкти мають свою специфіку, яку потрібно враховувати:

• Розмитість вимог. Замовник, як правило, не має або має дуже розмите уявлення, що саме йому потрібно, що потрібно зробити, аби проактивно моніторити критичні для бізнесу процеси та сервіси. Для цього потрібно мати чіткий та структурований підхід, який допоможе навіть на початкових етапах зібрати необхідну інформацію в короткий термін і видати клієнту бачення.
• Data gap. Замовник не може вам гарантувати, що всі необхідні метрики будуть забезпечені даними. Окрім цього, потрібно розуміти, що не всі дані можна чи потрібно використовувати. Після формування вимог і деталізації бізнесових та операційних метрик потрібно зробити Data Gap Analysis, який може допомогти виявити пробіли в даних, допоможе сформувати і узгодити способи доступу до даних чи їхньої перезаливки на доступний ресурс (база даних, файл, індекс тощо).
• Дата-моделі та аналітика. Побудова аналітики без дата-моделей практично неможлива. Вичленити логічні entity з маси даних, знехтувати несуттєвими атрибутами, провести агрегацію атрибутів з різних data-source — це своєрідне мистецтво. Але результат вартий цього.
• ·Візуалізація та дашборди. Характерною особливістю є побудова holistic view — дашборду, на якому клієнт може бачити всі свої критичні сервіси, аплікації. Бачити їхній стан з можливістю ухвалювати рішення з усунення проблем (швидкодія, безпека тощо.) Ми мали готові анонімізовані інтерактивні борди (invisionapp), які допомогли клієнту швидко зорієнтуватись зі своїми бажаннями та задокументувати їх.
• Troubleshooting та взаємодія із командами підтримки. Одним з business value такого проєкту є зменшення часу для виявлення, дослідження та виправлень проблем. Тут не обійтися без розуміння того, як на стороні клієнта працює команда підтримки і на що саме йде 80% часу команди підтримки. Часто, крім розробки механізмів швидкої діагностики (troubleshooting) та виводу всієї необхідної для цього інформації на борду, потрібно рекомендувати клієнту міняти самі операційні процеси.

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