Як ми віддали рутинні процеси команді ботів

Привіт! Мене звати Роман, і я Solution Architect у компанії Valtech. Пропоную разом пірнути у світ автоматизації процесів і продуктів. На реальному прикладі я покажу, як ми придумали та розробили додаткову команду з віртуальними працівниками-ботами, які допомагають основній команді з рутинними процесами.

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

Але час плине, і насправді речі, які були ефективними та працювали три-п’ять років тому, можуть бути вже дуже застарілими в наші дні. Бо світ змінюється, технології розвиваються, і ми отримуємо можливості робити щось якісніше, вкладаючи в це менше зусиль. І в цьому швидкоплинному світі завжди гарно вміти зупинитися на пару хвилин і поставити собі запитання: «А що я роблю? А чи ефективно я це роблю?». Декілька хвилин роздумів можуть привести вас у шоковий стан, коли зрозумієте, що кожного дня ходите на роботу, робите щось рутинне знову і знову. І все це замість того, щоб вивільнити час на пізнання чогось нового, що зробить вас набагато ціннішим спеціалістом і додасть щось новеньке у ваше життя чи роботу.

«Який же він лінивий...»

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

Кожного ранку, приходячи на роботу, він випивав маленьку чашечку кави, яку йому готувала кавова автоматизована машина, що стояла у нього в кабінеті. Вона мала два горщики, один для води, інший для кавових зернят. Щоб отримати каву, співробітнику необхідно було підставити паперовий стаканчик і натиснути ту чи іншу кнопку залежно від виду кави, який він полюбляв. Нічого незвичайного, вірно?

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

Таким чином, мікроконтролер автоматично запускав процес виготовлення кави, і о 9:02 мій колега вже міг насолоджуватися смачним ранковим напоєм. Єдиним нюансом було те, що йому необхідно було не забути підставити стаканчик перед тим, як він завершував роботу ввечері.

З часом він стикнувся з тим, що інколи кава не була готова о 9:02, і це його дуже засмучувало... Це траплялося, коли в машині закінчувалися вода або кавові зернята. Щоб розв’язати цю проблему, він додав до горщиків датчики, які почали йому висилати SMS про те, що щось закінчується. Отримуючи ці повідомлення, він відповідно заправляв той чи інший горщик, і таким чином продовжив насолоджуватися кавою о 9:02.

Зрештою мій колега дійшов до того, що система вміла автоматично брати та підставляти паперовий стаканчик перед натисканням кнопок на машині. Додатково, він міг відправити SMS на мікроконтролер, щоб запустити процес виготовлення кави у будь-який момент часу «не втрачаючи заряд дзену від слухання надокучливого торохкотіння кавової машини».

Споглядаючи це, в ті часи у мене в голові постала думка: «Який же він лінивий, що навіть клацнути декілька кнопок на кавовій машині, яка вже за нього автоматично все робить, йому і то лінь...». Але насправді, побачене назавжди закарбувалось у мене в пам’яті та відіграло величезну роль у майбутньому.

Все починалось з малого

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

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

Через місяць, рутинно перебілджуючи проєкт з дня в день і з ненавистю ставлячись до цього процесу, особливо коли щось не зібралося або не туди було задеплоєно, реліз-менеджер поставив собі запитання: «А що я роблю? А чи правильно я це роблю?»

Це був кінець далекого 2016 року, де про автоматизацію ще майже ніхто не думав і всі займалися простим написанням коду. В тому числі і наша команда. Почути історію на якомусь саміті з програмування про те, що хтось прикрутив до проєкту CI-процес, — викликало суцільні ВАУ! і прирівнювалось до того, неначе хтось злітав на Марс і повернувся звідти з інноваційними відкриттями.

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

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

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

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

Рисунок 1. Як все виглядало на початку

Наш перший віртуальний член команди

На початку 2017 року, паралельно з тим, як наш реліз-менеджер автоматизовував свою роботу в системі Jenkins, я захопився ШІ та можливостями побудови ботів на основі месенджерів типу MS Teams чи Telegram.

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

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

Бувало, що бувши відповідальним за реліз, коли я вже був на шляху додому, як на зло, хтось та й писав: «Ром, зроби, будь ласка, білд. Це дуже терміново, пів команди чекає». І тільки уявіть, в цей момент ти стоїш у переповненій маршрутці чи вагоні метро і маєш під рукою тільки телефон, з якого пустити білд було майже неможливо, бо існує купа речей, як-от фаєрвол компанії, які треба було обійти, щоб дістатися до кнопочки в Jenkins.

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

Трішки подумавши над запитанням «Як можна покращити процес, щоб команда не страждала через те, що я в дорозі?», я прийшов до цікавої думки: «А що, якщо використати мій досвід з ботами та зробити віртуального реліз-менеджера, який би міг запускати білд, а все що мені треба було б зробити — це дати йому вказівку через месенджер, до якого я маю швидкий доступ?».

Через два тижні у нас на проєкті з’явився наш перший бот в MS Teams, якому можна було написати повідомлення start build {instance}. Він запускав білд, а в кінці ще й звітував, чи успішно він пройшов і чи все готово до тестування.

Ось так і з’явився бот, якого ми прозвали Ramzes. З часом Ramzes став невіддільним членом нашої команди та виручав нас у скрутних ситуаціях.

Рисунок 2. Наш перший віртуальний помічник

Автоматизація відкриває нові можливості для подальшої автоматизації

Згадуючи що і як ми будували нашою командою, інколи приходжу до думки, що 2017-2019 роки були напевно одними з найяскравіших років, коли, не встигши відійти від одного «ВАУ!» після автоматизації того чи іншого шматка роботи, команда отримувала ще більший «ВАУ!» від наступного.

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

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

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

Використавши бота, ми з легкістю змогли автоматизувати частину процесу, пов’язану з білдами. Після цього команда задумалась: «А як би нам автоматизувати злиття гілок?». Відповідь насправді лежала на поверхні, бо все, що треба було зробити, — це інтегрувати бота з BitBucket API (на нашому проєкті ми використовуємо цю систему замість GitHub).

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

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

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

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

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

Забагато рев’юерів

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

Після розмови з командою стало зрозуміло, що документація проєкту складно описувала цей процес, ніхто з нових розробників не розумів, кого додавати в рев’ювери. Тобто всі просто почали додавати всіх.

Команда реліз-менеджерів одразу використала вже відомий нам підхід і поставила собі запитання «А як саме ми додаємо рев’юверів в пул-реквести? А чи можемо ми якось це покращити автоматизацією?». Відповідь була «Так, і дуже просто! Ми можемо визначити список людей, хто має робити код рев’ю і зробити так, щоб вони автоматично додавалися в пул-реквести ботом».

Але тепер треба було продумати, як це реалізувати, бо поточних механізмів бота не вистачало. Після недовгого пошуку відповіді на це питання, ми знайшли, що BitBucket підтримує технологію Web Hooks. Вона дозволяє відправляти події на специфічну URL-адресу, коли відбуваються якісь зміни на стороні BitBucket, наприклад, був створений пул-реквест чи оновлений.

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

Хаос в гілках пул-реквестів

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

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

Наша команда реліз-менеджменту сіла за аналіз проблеми і пошук рішення. Ми виявили, що все, що ми мали на той момент, це мітка релізу, яка проставлялася в тікеті в системі Jira. Ця мітка використовувалась командою проджект-менеджменту і визначала, в який реліз має потрапити той чи інший тікет. Контролювати кожен пул-реквест згідно з цією міткою вручну — не варіант, бо це знову треба саджати окрему людину, яка б те й робила що весь день перевіряла це. Але у нас же є бот, інтегрований з BitBucket, який вміє реагувати на створення або зміни в пул-реквесті!

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

А щоб розробник був зацікавлений у виправленні цієї проблеми і випадково реліз-менеджер не змерджив його пул-реквест в некоректну гілку, бот отримав вказівку не додавати ревьюверів, поки пул-реквест не стане валідним і розробник не виправить помилку. І вуаля! За тиждень реалізація була готова і проблема з гілками пропала назавжди.

Підтримка загальних правил написання коду

Коли ми мали команду з десяти розробників, всі старалися писати код, дотримуючись однакових правил, але з приходом великої кількості нових розробників кожен став писати код так, як йому здавалося правильним, не звертаючи уваги на загальні правила проєкту. Це призвело до жахливих наслідків, які впливали на якість коду і призводили до нескінченних баталій в пул-реквестах, де інколи можна було побачити до 50-100 коментарів.

Команда реліз-менеджменту взялася за цю проблему. Першим, що спало на думку, було додати лінтер до проєкту і прив’язати його до прекоміт-хуків (git hooks), які б запускали лінтер і не давали розробникам зробити коміт в репозиторій, поки зміни в коді не відповідали загальним правилам проєкту. За пару днів команда визначила, які правила повинен мати лінтер і реалізувала інтеграцію з прекоміт-хуком.

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

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

Зрештою команда придумала розширити можливості бота — це дозволило би йому, використовуючи вже наявну інтеграцію з BitBucket, аналізувати зміни, зроблені розробником в пул-реквесті, і перевіряти, чи вони відповідають правилам, встановленим лінтером. У разі порушення правил, бот мав відписувати коментар з описом того, що зроблено неправильно, і, так само як у випадку з неправильною гілкою, поки всі помилки лінтера не були виправлені, бот не додавав рев’юверів до пул-реквесту.

Мердж реквестів

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

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

Рішення було перед нами, треба було тільки об’єднати в одне все, що вже вмів бот, і трошки це розширити. Автоматизацію було визначено так: коли бот отримує повідомлення через BitBucket Web Hook про оновлення пул-реквесту, що трапляється, коли хтось апрувить пул-реквест, він робить перевірку, чи валідний пул-реквест і чи достатньо у нього апрувів від рев’юерів, щоб бути змерженим.

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

Рисунок 3. Як все виглядало після того, як ми вийшли з хаосу

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

Створення віртуальної команди

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

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

Із двох файликів, розмірами до 300 рядків коду, з яких ми починали автоматизацію білдів, за декілька років, додаючи все більше і більше автоматизацій, бот виріс до декількох десятків дуже пов’язаних між собою файлів, кожен з яких мав 500-1000 рядків коду. Коли щось відпадало і автоматизований процес зупинявся, реліз-менеджеру вже доводилось передивлятися ледь не чверть усього коду бота, щоб зрозуміти що не так. Тільки уявіть собі, як складно і скільки багато часу це могло забирати.

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

Таким чином, наш маленький помічник перетворився у великого, геніального помічника який вмів багато, але з яким стало складно взаємодіяти. Такий собі буркотливий бот-дідусь, який вже віджив своє і просто сам вже хоче насолоджуватися своїм життям. Знову, наша реліз-команда зібралася і почала думати: «А що б можна було зробити, щоб покращити код бота і зробити його більш гнучким?».

Це був початок 2020 року. На той час великі платформи та компанії-гіганти активно перебудовували свої багатомільярдні рішення та оновлювали їх, щоб йти в ногу з популярними технологіями. Через це, у всіх на слуху були такі слова як Headless, Microservices тощо.

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

За місяць рефакторингу ми отримали п’ять ботів, які чітко розподілили обовʼязки роботи з різними системами. На додачу до них, ми розробили шостого бота, такого собі менеджера, який вмів керувати всіма ботами та знав, в якій послідовності до якого бота звернутися, щоб отримати той чи інший результат. Сумно було прощатися з Ramzes, адже з ним ми пройшли і вогонь і воду, але його душа живе тепер у багатьох наших ботах :)

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

Маючи мікросервісну архітектуру, ми з легкістю змогли розширити нашого бота в MS Teams рольовою моделлю і тепер, залежно від ролі чи посади на проєкті, бот надавав відповідний список команд, якими міг скористатися той чи інший співробітник. Прекрасно! Чи не так?

Рисунок 4. Наша віртуальна команда

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

Підсумок

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

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

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

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

А якщо вам цікаво, до чого ми дійшли зараз, то ось так виглядає наша віртуальна команда:

Рисунок 5. Як виглядає віртуальна команда сьогодні