Проекти з диджиталізації: чому тут не обійтися без DevOps-культури і як діяти DevOps-інженерам
Усім привіт! Я Макс Козиненко, Cloud Architect у SoftServe. У цій статті ми розглянемо, що дає бізнесу диджиталізація й чому вона не працює без DevOps.
Навіщо бізнесу диджиталізація
Перш ніж переходити до ролі DevOps, варто чітко розібратися в суті й цілях диджиталізації. Якщо коротко, то вона потрібна, щоб прискорити темпи зростання бізнесу завдяки автоматизації бізнес-процесів і трансформації бізнес-стратегії. Якщо ще коротше — вона допомагає продавати швидше й більше з мінімальним залученням людських ресурсів.
Безумовно, перевести весь бізнес у цифровий формат — це складно, довго й занадто глобально, тому до цього поки мало хто готовий.
Розгляньмо на прикладі офлайн-ритейлу. У повністю диджиталізованому магазині не буде співробітників: процес доставки товару на полиці, відстеження залишків на складі, замовлення та отримання товарів від постачальників відбуватимуться без участі співробітників-людей завдяки AI й роботизованим процесам. Покупець у такому магазині здобуде кардинально інший досвід: AI розумітиме, навіщо та як часто він приходить до магазину, завжди пропонуватиме те, що потрібно, і максимально задовольнятиме його потреби.
На практиці ритейлери тільки йдуть до цього. Зараз ми можемо спостерігати кейси з впровадження окремих технологічних рішень:
- IoT — допомагають зібрати дані про відвідуваність магазину.
- AI — дає предиктивну аналітику.
- AR — розширює можливості взаємодії з клієнтами, наприклад, нині з’являються рішення, які дають змогу приміряти одяг у режимі онлайн: наводиш на себе камеру й бачиш, який вигляд матиме на тобі конкретна річ.
Безумовно, тут до повної цифрової трансформації ще далеко, оскільки трансформується одна із сотні ділянок бізнесу. Але навіть це допомагає бізнесу зоптимізувати ресурси й привернути увагу споживачів.
Крім онлайн- та офлайн-ритейлу можливо диджиталізувати банківську сферу, охорону здоров’я, енергетику, транспортну систему, фінансовий сектор і низку інших.
Однак важливо розуміти, що диджиталізація — це не тільки зиск, а й великі ризики за неефективного підходу та незлагодженої роботи.
Тільки уявіть: є успішний бізнес, усі процеси переведено в електронний вигляд, зоптимізовано, клієнти працюють з вами в новому форматі з новим досвідом — і тут усе припиняє функціювати на годину. А якщо це цифровий бізнес і немає стаціонарних відділень або офісів, куди можна прийти щось дізнатися тощо? Станеться катастрофа, яка спричинить суттєві фінансові втрати на прямих продажах, а непрямі збитки навіть порахувати неможливо, тому що після такого негативного досвіду велика кількість користувачів може втратити лояльність до компанії й перейти до конкурентів.
Суть цифрової трансформації зводиться до поліпшення наявного й розробки нового ПЗ для керування процесами, переведеними в цифрову форму. Саме тут з’являється DevOps, місією якого є скоротити time to market конкретного продукту й забезпечити його безперебійне функціювання.
DevOps-культура — відповідь на технічні виклики диджиталізації
Цифрова трансформація без DevOps може зайняти занадто багато часу, а фінальний результат може бути непередбачуваним і не відповідати початковим цілям, оскільки процес розробки має такий вигляд: Devs на свій розсуд написали код та віддали його Ops, які його на свій розсуд розгорнули. У розрізі процесу цифрової трансформації така схема не працюватиме, оскільки ймовірність помилки й кількість витраченого часу дуже великі: поки цей софт доїде до продакшену, у конкурентів уже все буде новіше.
Як DevOps розв’язує цей челендж? Він виступає клеєм, який склеює дві ці фази, координує весь процес розробки й кастомізації рішень.
Можна вирізнити такі ключові напрями, які є у фокусі DevOps-інженерів на проектах, пов’язаних з диджиталізацією.
Platform-engineering
Створення, підтримка й масштабування платформ, на яких працюють комплекси програмних рішень (хмарні інфраструктури, власний дата-центр тощо).
Може здатися, що для запуску цифрового проекту достатньо купити обладнання, поставити його у своєму дата-центрі, установити потрібне програмне забезпечення — і на найближчі кілька років питання про платформу для функціювання цифрових процесів організації можна вважати розв’язаним. Це далеко від реальности, бо обладнання виходить з ладу, а якщо бізнес активно зростатиме, наявних обчислювальних потужностей не вистачатиме. Тому потрібні постійна підтримка й оптимізація. Platform-engineering розв’язує ці проблеми як на апаратному, так і на програмному рівні.
Release-engineering
Координація й автоматизація релізів ПЗ. Застосунки/сайти, які бачать користувачі, — це верхівка айсберга. Інженери працюють з багатьма іншими застосунками й мікросервіс-інструментами, які також треба підтримувати та синхронізувати. На рівні дата-центру цей софт оновлюють, змінюють під нові норми законодавства тощо. Реліз-інженери відповідають за те, що код, який пишуть розробники, під час продакшену перетворюється на працездатний застосунок — тобто те, із чим працюють люди. Що краще влаштовано Release-engineering у рамах DevOps-організації компанії, то безшовніше відбуваються оновлення.
Керування процесами тестування
Це безпосередньо стосується DevOps, оскільки ключовий принцип цієї культури — відсутність окремих фахівців, які пишуть і релізять код, керують продакшеном та тестують. Усі ці функції має бути виконано в межах одного відділу продукту, де всі фахівці рівною мірою відповідають за якість кінцевого результату. DevOps допомагає забезпечувати стабільну якість підсумкового продукту, який бачить кінцевий користувач, завдяки автоматизації всіх процесів.
Ми на своїх проектах дотримуємося парадигми Quality Gates, коли реліз має пройти кілька «воріт», перш ніж потрапити в продакшен. Кожні з них перевіряють продукт за кількома критеріями: наприклад, на одному з етапів навантажуємо рішення великою кількістю трафіку й відстежуємо дані продуктивности, порівнюємо з бейслайном і вирішуємо, пропускати далі чи повернути на доопрацювання. DevOps допомагає завтоматизувати процес тестування, щоб усе відбувалося максимально без участі людини.
Що більш цифровим стає бізнес, то складніше забезпечити його безперебійну роботу. Яскравий приклад — Google.
Це повністю цифрова компанія. Якоїсь миті вони дійшли того, що їм не вистачає парадигми DevOps, розробили власний підхід і назвали його SRE (site reliability engineering). За духом це досить близько до DevOps, але з нюансами й тонкощами Google. SRE-інженери 50% часу пишуть код програмних продуктів, а решту 50% — підтримують його. Цей підхід був би ефективним, якщо б не одне «але». Буквально недавно в Google стався збій (перестали працювати також YouTube, Gmail тощо). Скільки коштує хвилина простою всіх сервісів Google одночасно? Дуже дорого! А сталося так, що, грубо кажучи, одна неправильно натиснута кнопка зупинила їхню роботу на якийсь час.
У культурі Google заведено робити огляди й аналіз сформованих ситуацій, і їх часто викладають у відкритий доступ. У цьому кейсі було зазначено, що конфігурацію, призначену для цільових груп серверів, застосовували ще на деякі інші в різних регіонах, для яких вона не підходила. Тож усе й зламалося. Це сталося через людський чинник. І саме SRE-культура й базується на тому, що людський чинник — найпоширеніша причина збоїв, а отже, його роль треба якнайбільше знижувати. Але, на жаль, це вдається не завжди. Тому такі ситуації все-таки трапляються. Бізнес на цьому втрачає дуже багато, автоматизація ж якщо не усуває, то мінімізує ризик виникнення таких помилок.
Повернувшись до DevOps, зазначу, що між автоматизацією й рішеннями, які приймає людина, є тонка грань, на якій і балансують інженери.
Як на практиці зорганізовано роботу DevOps-інженера на проектах цифрової трансформації
Є багато причин, чому проект може бути невдалим:
- Недостатньо інформації від клієнта.
- Неправильно вибрано технологію для реалізації ідеї.
- Кардинальна зміна запита від клієнта тоді, коли внести зміни вже буде занадто складно й дорого.
DevOps-інженер має все це врахувати й усунути всі можливі проблеми.
Ми прилучаємося до проекту ще на етапі discovery, щоб із самого початку максимально передбачити можливі ризики й поставити клієнтові якнайбільше уточнювальних запитань. Але він не завжди розповідає все. Тож потрібно сідати й ґуґлити, чим клієнт займається, які ризики для його бізнесу можуть виникнути (зміни в законодавстві тощо) в найближчі хоча б пів року, і зрозуміти, яка саме проблема найімовірніше виникне в цьому розрізі часу. Водночас я намагаюся не дивитися занадто вглиб технічних компонентів рішення, оскільки мені важливіше розуміти картину загалом, тобто механіку процесу генерації прибутку, потенційні проблемні місця й додаткові можливості усунути людський чинник.
Це головна особливість роботи DevOps-інженера в контексті диджиталізації: потрібно проаналізувати всі можливі ризики й бачити дуже широко.
У нас є стандартні темплейти architecture vision, але це не чек-лист, бо його створити було б просто неможливо. Це радше відпровідні пункти, які допомагають зорієнтуватися, із чого почати, наприклад, чітко з’ясувати бізнес-цілі замовника. Ясна річ, що в усіх це — збільшення прибутку. Але в кожної компанії є особливості, які впливають на загальну картину.
Для прикладу, недавно в одного з клієнтів ми зіткнулися з тим, що в них постійно затримуються поставки товару на склад, унаслідок чого зриваються терміни відвантаження замовлень клієнтам. Тут відразу видно вузьке місце, і його потрібно описати як ризик та розробити спосіб розв’язання, який потім урахувати під час побудови загальної архітектури. Також у всіх є вже усталені бізнес-процеси, і деякі з них міняти дорого, а часто й безглуздо (їх простіше обійти, ніж намагатися трансформувати), але на результат це дуже впливає.
Кожен із цих чинників беремо до уваги, вносимо в architecture vision з обґрунтуванням, яка може виникнути проблема і яка має бути архітектура проекту, щоб цю проблему обійти. Це все досить велика мозаїка, яку потрібно тримати в голові. Це майндсет.
Такий ґрунтовний підхід здобуває прихильність клієнтів до проектної команди, а також спрощує нашу подальшу спільну роботу.
Коли загальна картина складається й запит від клієнта зрозумілий, ми з різними фахівцями, залежно від потреб конкретного проекту, брейнштормимо, разом розглядаємо проблему, вивчаємо best practices і міркуємо, як краще розв’язати поставлене перед нами завдання. Коли рішення є, моє завдання — задокументувати кінцевий результат і продумати максимальну автоматизацію, щоб вималювався хід роботи над проектом з мінімальними шансами зійти із цієї колії.
Наступний етап проекту — безпосередньо розробка. До нього прилучено кілька відділів, у кожного з яких свої інтереси: у розробників — випустити реліз якомога швидше, у тестувальників — випустити якісний продукт, а неякісний вони не пропускають, в оперейшенз усі kpi зводяться до стабільности й безперервности роботи системи, тож для них кожен новий реліз — порушення стабільности. Це як лебідь, рак і щука, і всі тягнуть у різні боки. Швидко зарелізити софт у такій ситуації не вийде. На цій стадії перед DevOps-інженером стоїть завдання налагодити горизонтальну структуру взаємодії між усіма цими відділами, де кожен з фахівців несе відповідальність за кінцевий продукт. У такому разі в загальному проектному ланцюжку керівником процесу виступає product- або project-менеджер, а DevOps — це клей, який склеює всі частини воєдино й робить так, щоб усі працювали за заздалегідь прописаним планом.
Для цього важливо все:
- Технічні знання й розуміння обмежень конкретних технологій, що дає змогу збагнути, на базі чого і як саме вибудовуватиметься проект. Якщо цього немає, можна вибрати неправильне рішення, під час реалізації якого проект розвалиться, а перебудовувати його — довго й дорого. Тому краще не помилятися, а з першого разу все розрахувати правильно й отримати хороший результат.
- Чітке розуміння процесів організації бізнесу клієнта.
- Soft skills для того, щоб зорганізувати всіх людей, прилучених до процесу.
Основне завдання архітектора з DevOps-бекграундом — комунікувати й робити це вчасно, оскільки здебільшого головна причина провалу проектів — недостатня комунікація на старті. Тому що, наприклад, за 6 місяців може з’ясуватися, що розроблена архітектура не задовольняє вимоги замовника. Або через зміни на ринку в замовника бізнес-вимоги змінюються так, що рішення, яке розробляється, уже не актуальне, а змінити архітектуру під нові вимоги вже практично неможливо.
Висновки
Шаблону дій у цій роботі бути не може, оскільки кожен проект — унікальний. Якщо б можна було придумати універсальний сценарій, у DevOps-інженерах не було б потреби. Але практика показує, що саме грамотна DevOps-культура — запорука успішної диджиталізації.
