Якось я ніколи і не розказував особливо чим я займаюся в GoDaddy у своїй поточній команді. Не розказував тому ще це не так цікаво як bing чи Windows Phone з точки зору розпізнавання та гучності імені проекту. Але тим не менше є певні складні задачі (хоча і зовсім іншого плану) які доводиться розв’язувати майже щодня.
Також варто зауважити що я не знаю визначення електронної комерції як її дають словники та енциклопедії тому те що я далі розказую скоріше за все не співпадає з якимось академічними визначеннями та тлумаченнями.
Отже коли я прийшов в GoDaddy одна з речей яка дуже привабила мене це була обіцянка того що писати коду я зможу стільки скільки в мене буде бажання це робити. Історично компанія працювала над усіма своїми проектами в такій манері щоб зробити продукти доступними для покупки якомога скоріше і софт який розробляли програмісти не вважався головною цінністю компанії як це є в софтверних фірмах – головною цінністю були саме продукти які можна продавати. Після того як компанія почала приносити більше одного мільярда прибутків на рік нею зацікавилися великі інвестори, викупили частку у власника (до того компанія була у приватній власності) і найняли менеджмент який мав би вивести компанію на новий рівень – до десятків мільярдів прибутку на рік. Нові власники подивилися на стан речей і жахнулися – усі можливі ОС, фреймворки, мови програмування, СУБД і так далі. І звісно дуже мало процесів і контроль якості лише умовний. Все це треба було довести до якогось ладу. І головна причина того що з’явився офіс GoDaddy у нас в тому що тут можна наймати досвідчених людей які розуміють і знають як розроблюється та супроводжується програмне забезпечення (а не просто пишеться код) і їх можна переманити з гігантських Microsoft та Amazon.
Команда в яку я потрапив як ви вже мабуть зрозуміли називається eCommerce. Вірніше це кілька команд зараз. Коли я лише прийшов уся компанія переходила на agile, двотижневі ітерації і усі супутні процедури. Чим же займається eCommerce? Для того щоб щось продавати треба мати як мінімум список речей доступних для продажу з їх цінами. Це так званий каталог. Але не думайте що тут достатньо буде таблички в базі даних з переліком продуктів та цінами. Нюансів багато, назву лише декілька. По-перше, не усі продукти доступні у всіх країнах. А якщо і доступні то їх ціна та конфігурація скоріше за все є різною для різних країн. Потім, якщо ви подивитеся на наш сайт то побачити що багато продуктів доступні у різних варіаціях (наприклад базова, стандартна, професійна і так далі). Деякі продукти мають розширення або доповнення що можна придбати разом з цими продуктами і які не можна придбати самі по собі. До того ж набір характеристик у продуктів різний. Одне діло мати електрону пошту на кілька тисяч адрес, а інше – віртуальний хостінг де рахунки в кінці періоду складаються з того як було використано процесор, пам’ять, диск і так далі. Також придбані продукти можна за часом апгрейдити чи даунгрейдити – тобто переходити на потужнішу чи простішу версію. І те які способи апгрейду та даунгрейду доступні теж треба зберігати у якійсь формі. Тобто каталог це продукти, ціни для різних ринків, модифікації, доповнення до них та дерева апгрейду. Це як мінімум.
Далі у нас є користувачі. Крім відносно простих даних типу адреси та продуктів якими користувач володіє у користувача є перелік методів оплати (банківські рахунки, кредитні та дебітні картки, PayPal і таке інше). Також деякі користувачі мають права доступу до облікових записів інших користувачів. Це можна зробити або через делегування якихось прав, або надавши доступ веб-розробнику який міг би виконувати для користувача роботи зі створення та підтримки сайту. Власне якщо ви хоч колись були задіяні у проекті де треба підтримувати велику кількість користувачів (у нас їх більше 15 мільйонів) то приблизно уявляєте собі що це таке і які задачі типу злиття, блокування і подібних треба автоматизувати.
Ну добре – у нас є каталог продуктів і користувачі з методами оплати, тепер все це треба скласти до купи. Перше це те що називається “корзина” – покупець вибирає все що хоче придбати, ми вираховуємо ціну враховуючи те що деякі продукти йдуть як безкоштовні доповнення, на деякі діють знижки, може було введено код на скидку і так далі. Та ще і податки треба нарахувати в залежності від місця проживання покупця. Це я до того що ціна корзини теж не складається так просто. Але уникнемо усі інші деталі і подивимося що відбувається далі. У деяких випадках ми можемо просто спробувати зняти гроші. І в залежності від методу робимо ми все це дуже по різному. Ось тут я трошки схематично показав як усе це працює для кредитних карток. А це лише один з кількох десятків методів оплати. Навіть якщо не згадувати що для кожного методу способів здійснити оплату теж як правило більше одного в залежності від багатьох факторів. Додам що деякі методі роблять так звану відкладену оплату. Це коли ви комусь типу PayPal кажете “зняти ось скількись грошей”, а він відповідає “думаю що все буде добре, але точно знатиму через пару днів”. Ми це сприймає як сигнал до того щоб надати клієнту продукт навіть якщо остаточний результат нам повідомлять лише пізніше. Ось власне різними методами оплати я і займаюся – працюю в команді яка забезпечує оплату абстрагуючи код від різних методів, країн, валют і типів оплати.
Опустимо ще трохи деталей і уявимо що клієнт придбав якісь продукти і успішно ними користується якийсь час. І ось треба їх оновити. Це теж одна з наших задач – знайти продукти термін дії яких закінчується і повідомити клієнта якщо автоматичне оновлення не дозволено. Якщо ж дозволено то ми самі кладемо відповідні оновлення в корзину. А ці оновлення це не те саме що було куплено спочатку – нам же потрібне саме продовження терміну дії вже купленого продукту, а не такий самий продукт ще раз. Тобто привіт каталог, в тобі ми ще будемо зберігати усі можливі варіанти оновлення для усіх наших продуктів. І ось ми склали цю корзину і пробуємо її оплатити. А тут з’ясовується що нам потрібен PIN-код кредитки чи податковий номер (в залежності від правил які діють на ринку клієнта). І для того щоб усе це працювало без того щоб клієнт мав купувати все вручну ми у методах оплати коли створюємо їх для користувача робимо це таким чином щоб далі можна було виконувати транзакції без залучення покупця. А для кожної з кількох десятків організації з якими ми працюємо для цього є свій протокол та способи досягнення цього. А отже у кожного користувача для кожного методу оплати зберігається якась інформації яка потрібна лише для цього методу.
Ну і ще багато речей я не буду розписувати, але серед них такі як:
- виявлення користувачів які роблять щось підозріле – послідовно пробують картки вводячи неправильний PIN, роблять багато покупок і відмін і таке інше. Усі подібні випадки мають призводити до блокування такого користувача або методу оплати.
- повідомляти іншим система про зміни які сталися у користувача, його продуктах (наприклад апгрейд) та методах оплати.
- відміняти покупки та повертати гроші – це окрема і дуже велика область діяльності.
- надавати API як внутрішнім так і зовнішнім командам – іншим провайдерам та фірмам які перепродають наші продукти та ми продаємо їхні. Як, наприклад, Microsoft (Office 365), WordPress і так далі.
- і ще багато-багато усього…
Що стосується технічної частини, і це мабуть один з великих викликів. Оскільки система дуже стара (їй більше 10 років) то технології які в ній використовуються вже неймовірно застаріли на сьогодні: COM+ (тобто це Windows), С++, SOAP, MSMQ, IIS, MS SQL. Роки 4 тому була спроба осучаснити все це і не міняючи суттєво платформи – усе що ми маємо обслуговує як я вже сказав вище мільйони клієнтів і проводить транзакції на сотні тисяч доларів на день. Тому не можна все просто взяти та переписати. А через дуже складні схеми в базі даних та потоки даних між компонентами написати нову систему яка працювала б паралельно теж не вийде – в ній доведеться дублювати усе, тобто роботи там на кілька років. Тому зрозуміло що була спроба перейти на C# з C++ та на REST з SOAP, але з часом цю ініціативу було відмінено – дуже багато зусиль для того щоб фактично отримати копію. Зараз ми працюємо над тим як деякі нові компоненти та потоки даних перевести на Java, Linux, Node.js, Hadoop, Docker і подібне. Це дуже цікава і складна інженерна задача – вдосконалити, або навіть переробити систему як працює при цьому не зупиняючи її. Майже як вдосконалювати автомобіль на ходу :)
Щодо складності автоматизації електронної комерції то якщо відкинути складність самих технології типу COM то у написанні коду нічого складного нема в принципі (звісно завжди є нюанси). Але складна сама область яку ми автоматизуємо – занадто вже багато в ній кроків, даних і зв’язків. Наскільки багато що розуміти що відбувається у кожному сценарії і як дані куди йдуть та через які компоненти майже неможливо не підглядаючи весь час в діаграми та код тих компонентів. А тому і у разі проблем та помилок дослідження причин теж є не аби яким викликом.