Як ми робили проект з digital transformation, або Про розуміння клієнта
Мабуть, я не відкрию великої таємниці, якщо скажу: коли вам обіцяють, що проект простий і ви тихенько зробите його за три місяці, не вірте. Краще множте терміни у
Отже, я працюю System Architect у EPAM Ukraine. Нещодавно ми успішно завершили проект з digital transformation однієї голландської компанії. Як ви вже, певно, здогадалися з попереднього абзацу, «успішно» не означає «просто». Розкажу, як ми допомогали трансформувати бізнес і міксували DevOps best practices з мистецтвом комунікацій.
Передісторія
Наш замовник — B2B-постачальник повнофункціональних метеорологічних рішень. Простіше кажучи, вони продають опрацьовані метеорологічні дані, в тому числі у вигляді гарних картинок, які ми потім дивимося у прогнозах на ТБ.
Спочатку було три різні компанії у трьох різних країнах. Потім голландці забрали дві інші під своє крило. І вже тоді встигли створити собі задачку на майбутнє. Головна компанія не стала перебудовувати інфраструктуру своїх надбань і залишила її, як є. Так само, як і людей. Новоутворений холдинг став схожий на клаптикову ковдру, де кожен шматок займався чимось своїм, а з іншими скріплявся грубими стібками. Через це, звичайно, виникало багато проблем із міграцією даних. Зокрема, з тією швейцарською компанією, яка згодом потрапила до нас у вигляді проекту.
Система підрозділу, який відповідав за збір метеорологічних даних, дуже складна. У їхню інфраструктуру потрапляють необроблені дані відразу з п’яти потоків. А три різні бази даних інфраструктури, до прикладу, були підключені до одного програмного забезпечення, яке в свою чергу підключене до іншого.
Дата-центр підрозділу обробляє сирі дані та розподіляє їх на два окремих продукти: дані з малюнками та анімацією, що продаються клієнтам, та відео із прогнозом погоди. А ще ж є показники, які отримують із супутників та метеорологічних станцій.
Справа в тому, що навіть після юридичного об’єднання ця підкомпанія продовжувала жити своїм життям. Вони розміщували інфраструктуру в дата-центрі буквально навпроти офісу, причому за шалені гроші. Тільки ISP коштував компанії сотні тисяч євро. А щомісячна плата складала десятки тисяч євро плюс додаткові витрати на його підтримку.
Життя новоутворених холдингів бентежне, але бізнес є бізнес. І наш майбутній замовник вирішив, що хоче не просто продавати метеорологічні дані, а створювати круті продукти на їхній основі. Наприклад, уточнювати та гіперлокалізувати прогнози до масштабу майже 2 на 2 км. Але перш ніж братися за інновації, необхідно було укріпити тили і навести лад у back-end. Для цього CTO замовника запустив програму Cost Saving. Її мета — через вихід у хмару відмовитися від інфраструктури, розкиданої по різних дата-центрах і зекономити кількасот тисяч доларів на рік. Причому то мав бути не лише перенос, а і грамотна оптимізація. Із цією задачкою вони прийшли в EPAM.
Неприємні сюрпризи
Проект потрапив до мене як терміновий. З клієнтом уже були попередні домовленості, залишалося розставити крапки над «і» та починати працювати.
Спочатку на проект виділили три місяці. Я поїхав до замовника, і його CTO відразу мене заспокоїв: «Не переживай, у нас кейс простий. Є дорогий дата-центр у Швейцарії, і нам треба швиденько перенести все, що там є, у клауд і таким чином зрізати кости». Він називав це «shift & lift». Я зрадів, але сказав: «Давайте подивимось». І почав дивитися.
Тут почалися сюрпризи.
З невідомих нам причин стейкхолдери почали залишати швейцарський дата-центр, у якому вони працювали і в якому утримувався шматок компанії. Пішов і CTO, замість нього взяли нову людину, яка тільки переймала справи. Переносити інфраструктуру без тестування було неможливо. Обіцяний «shift & lift» залишився у моїх мріях — людей, які могли щось розповісти, ставало все менше. До того ж нас чекав цілий букет із старого заліза, legacy-систем та рішень.
Оцінивши ситуацію, я зрозумів, що в три місяці ми не вкладемося. Зібрав команду із 7 людей. Ми по маленьких шматочках почали збирати інформацію щодо організації інфраструктури і вибудували часткову структуру. Але зіштовхнулися з однією великою проблемою — монолітністю: варто відключити один сервіс, помирають усі інші.
Щоб зрозуміти, що коїться із сервісами, необхідно було зрозуміти, звідки почати. Ми довго крутилися, зняли снепшоти з усіх існуючих машин, намагалися збагнути, що і як працює всередині, але даремно. Люди, які могли щось пояснити, то звільнялися, то йшли у відпустку або мало відповідали.
Ми зрозуміли, що чекати допомоги немає звідки. Треба було робити повний реверс інжиніринг.
Пробиваючи стіни
Через людський фактор ми мали найбільше веселощів. Так як у компанії офіційно оголосили digital transformation, у якому наш проект брав участь, люди думали, что їх просто звільнять після закінчення. І хоча насправді це було не так, ми скрізь натрапляли на «лежачих поліцейських».
У клієнта дуже багато всілякого legacy staff, який вони так і не мігрували у хмару та не автоматизували. Команда, яка займається data flow і сидить на всіх цих legacy, прекрасно розуміла, що ми можемо автоматизувати все, що вони нині роблять руками. І вони стануть просто не потрібні. Хоча в нас і в планах такого не було.
З командою operations виникали інші нюанси. Там є люди, які працюють багато років. І вони не дуже хотіли переїжджати на новий стек технологій Amazon, бо не особливо з ним знайомі. У них у дата-центрі кілька машин працювало на старому Oracle, і перемігрувати його на Amazon повністю вони не захотіли. Мовляв, хай буде, як є. Причина — «тому що ні».
Такий супротив ми зустрічали практично в кожному департаменті, поки не показували, як після міграції все автоматично працює. Врешті-решт, з усіма структурами це допомогло.
Інша причина — був окремий вендор, який займався виключно підтримкою Oracle. Замовник передав їм інструкцію, що необхідно зробити, щоб перенести Oracle. А фактично все зробили ми: підготували машину, засетапили, зробили в Amazon усі правила. Єдине, що зробили люди вендора — інсталювали Oracle и перенесли туди дані. На листування із вендором з поясненнями та переконаннями ми витратили в цілому близько чотирьох місяців.
Останню стінку ми пробивали лобом уже безпосередньо перед закінченням проекту, коли його треба було продовжити, щоб нормально закінчити та передати. Для цього нам дали ще одну частину інфраструктури. Це називалося broadcasting — коли картинки накладаються шарами один на інший, і завдяки даним повністю вимальовується прогноз погоди. На цьому етапі проект виглядав безхмарним, а ми були налаштовані оптимістично. Проблем ми не очікували, адже спілкувалися із knowledge keeper, який охоче ділився інформацією та обіцяв невдовзі передати всі необхідні дані.
Та скоро наш оптимізм погас. Knowledge keeper став невловим Джо, а обіцяні дані ми так і не отримали. Наша команда намагалася заходити з різних сторін, щоб отримати необхідну інформацію, якої не вистачало, та наші спроби розбила перевантаженість замовника. Як результат, фейлили дедлайни. Врешті, ми передали цю частину проекту фактично та практично готовою, але не переключеною до кінця в продакшин.
Смішно, але тут ми знову зустрілися з вендором по Oracle. Незважаючи на те, що один раз ми їх уже «перемогли», історія повторилася. Уявіть собі e-mail thread на
3 -> 6 -> 15
Ми поділили команду на шари: хтось займається скриптами, хтось — даними, хтось — потоками. Щоб покрити ризики всередині хоча б нашої команди, ми робили свої внутрішні сесії, де ділилися один з одним, хто що знає, як що працює. І все документували. Це допомогло підстраховувати один одного, коли хтось ішов у відпустку або був відсутній за сімейними обставинами.
Урешті-решт, ми знайшли, куди йдуть дані, і з цієї ниточки почали «розслідування». Оскільки компанія заробляє на постачанні консолідованих і оброблених даних, наша команда розбиралася саме з data flow. На цьому етапі було дуже важливо показати клієнту, що в нас є експертиза, що ми можемо з цим розібратися (до речі, за рахунок досвіду команда наша була в два рази менше, ніж та, яку зазвичай будують на таких проектах).
Коли ми повністю розібрали топологію мережі і те, що коїться в їхньому швейцарському дата-центрі, клієнт нам повірив.
Я одразу говорив, що це не буде просто і забере мінімум рік. Завжди давав апдейти, ходив на transformation-мітинги до клієнта. Розповідав усе, як є. Тому нам подовжували проект. Початковий контракт збільшили до півроку, а потім одразу ще на півроку.
Технології
Для Infrastructure-as-a-Code ми використовували SparkIFormation, для automated provisioning (CM) — Puppet, тому що він уже був присутній, але працював лише для створення юзерів і не був допрацьований у тому масштабі, щоб його можна було використовувати повноцінно.
Для моніторингу ми використовували Icinga. Для трекання карток беклогів — Trello плюс Confluence для зберігання даних та knowledge transfer. Для деплойментів — Jenkins та Bamboo. Бази даних у них були MySQL, ми перенесли їх в Amazon RDS. Також був Oracle, який ми теж перенесли та автоматизували (не без пригод, як я згадував трохи вище).
Результати
Проект закінчено у серпні. Ми переключили все на структуру Amazon. Повністю автоматизували все в DevOps best practices. Зробили повний reverse engineering до рівня бібліотек. Перемістили та перейшли на AWS, впровадили сучасний технологічний потік, зменшили ризики інфраструктури. Зробили так, як початково і хотів замовник: однією кнопкою все (або частина інфраструктури) піднімається та опускається. Ми залишили Disaster recovery plan, все задокументували і зробили knowledge transfer сесії.
Як я казав вище, за старий дата-центр компанія платила десятки тисяч євро на місяць плюс додаткові ресурси на підтримку. Після виходу в продакшн через півроку клієнт почне окупати інвестиції. Нам вдалося скоротити витрати в чотири рази. Також клієнт забув про головний біль мануальної роботи.
У цьому проекті величезну роль відіграла вся наша команда. І те, що ми всі разом працювали як один злагоджений механізм, дало нам можливість досягнути результатів, про які я зараз розповідаю. Не відкрию велику таємницю, коли скажу, що над командою теж треба працювати — створювати комфортні умови, ділитися знаннями, давати повне розуміння ситуації та підтримувати і мотивувати. Те ж саме треба вибудовувати і в стосунках із клієнтом. У нашій ситуації дуже важливо було знайти взаєморозуміння з клієнтом, а з самого початку це було достатньо складно. До нас приглядались, мовчали, говорили: «Ну, може бути». Треба було показувати результат, причому дуже хороший.
Один головний висновок
Треба зрозуміти клієнта.
Поділюся своїми трьома порадами у роботі з клієнтами, які я виніс з цього проекту:
1. Ставте себе на місце клієнта
Причому треба зрозуміти саме того клієнтського представника, з яким працюєш безпосередньо — власну точку контакту. Щоб побудувати з ним комунікаційний місток, треба зазирнути в його професійні бажання та страхи. А для повної картини — спілкуватися з людьми, які працюють у цій компанії. Це може звучати банально, але іноді банальностей треба просто дотримуватися — така собі дисципліна комунікацій, яка, як на мене, ні одній команді ще не зашкодила.
2. Дослідіть бізнес клієнта та слідкуйте за змінами
Треба розуміти всі процеси компанії, щоб зрозуміти, чому сталося саме так, хто винний і що робити. Іноді необхідно охопити значно ширші області. Наприклад, оцінити глобальне місце компанії на ринку, стан акцій, нещодавні угоди, загальне інформаційне поле. Можливо, це дасть підказки, які важелі саме зараз дадуть результат.
3. Інтегруйтесь у команду клієнта по максимуму
Щоб зрозуміти, що коїться з компанією-клієнтом, я спілкувався з різними менеджерами, які мали відношення до акаунту. Розпитував, знаходив кінці, вибудовував ланцюжки. Спілкувався з делівері-менеджером — він давав багато підказок, з ким як говорити, з ким можна, з ким не варто. Спілкувався із сусідньою командою сапорту і підтягнув її, щоб мотивувати її і їм було веселіше. Якщо зовсім чесно, ми з початку намагалися врахувати ризики, коли ми завершимо проект. Так і вийшло: ми пішли, а knowledge keepers залишилися, бо були залучені в цей процес.
Наостанок наголошу — communication skill дуже допомагає. Треба думати, розвиватися і дивитися ширше. Це бажано, якщо ви плануєте рости професійно. І абсолютно необхідно, якщо вже займаєте якусь координаційну роль у команді чи проекті. У такому випадку всі ниточки мають бути у вас у кулаці.
