Аз съм Илиян

Първият ми проект е в софтуерна компания, предоставяща услуги за глобална дистрибуция на авиокомпании. Дейността е свързана с разпространението на информационни продукти в сферата на туризма.

Екипът, в който работех, е част от отдела за резервация на билети. Заеманата от мен длъжност е „платформен инженер“ (platform engineer), а основната ми задача е поддръжката,

експлоатацията и развитието на конвейера за обработка на данни (data processing pipeline). Той отговаря

за приемането на суровите данни, изпращани от глобалната дистрибуционна система,

обработването им на няколко етапа и финалното им изпращане към клиента чрез различни протоколи за трансфер – FTP или S3.

Постиженията ми по време на работата по този проект включват:

• миграция на наследени (legacy) Groovy скриптове към вътрешна рамка (framework), наречена „workflow“, която управлява целия жизнен цикъл на изграждане, тестване и публикуване на
• пренаписване на системата за доставка на данни (feed delivery framework) от един-единствен Bash скрипт към набор от чисти и модулни Python скриптове, което значително подобри надеждността и възможностите за поддръжка на
• рефакториране на Python скрипт, отговарящ за компресирането и прехвърлянето на клиентски данни от „raw“ към „source“ S3 bucket; това позволи разширяване на функционалността според нуждите на ръководството и осигури възможност за по-добро тестване преди пускането на нова версия
• значително подобряване на вътрешната документация чрез модернизирането ѝ спрямо актуалните ни нужди от споделяне на знания и премахване на остарели
• ръководене на процеса по миграция на вътрешните хранилища (repositories) и тези на разработчиците от Bitbucket към
• изготвяне на концептуален дизайн за правилно извършване на софтуерни релийзи, което подобри процеса на връщане към предишна версия (rollback) и повиши доверието от страна на CAB (Change Advisory Board)

Първоначалният ми проект се фокусира върху разработването на системи за подпомагане на водача (ADAS) за мултинационална автомобилна компания.

В рамките на този проект, моята роля беше като DevOps инженер по управление на облачната инфраструктура на AWS,

където отговаряхме за поддръжката на цялата облачна платформа, включително внедряването на клиентски продукти с помощта на рамката AWS ADF, AWS Account-Vending-Machine и персонализирания REST API на AWS Control Tower.

Отговаряхме и за управлението на облачната платформа, използвайки шаблони за политики на AWS Cloudformation и всички основни ресурси.

Автоматизацията на тези процеси беше постигната чрез използването на AWS CDK Infrastructure as Code (IaaC).

Като част от моя принос към клиентските услуги, внедрих следните решения:

• известяване за бюджетни разходи на цялата платформа с предварително определен процент на превишен бюджет за изпращане на имейл съобщения до собствениците на
• създаване на допълнителни REST API крайни точки за Control Tower за уточняване кои новосъздадени AWS акаунти принадлежат към кой VPC.

  Там също написах логиката, при която Lambda функция проверява типа на акаунта и въз основа на това към кой VPC шаблон

• внедрява AWS CloudFormation StackSet към съответния
• създаване на дизайн на високо ниво на потока от данни и репликация за цялата платформа за данни

Вторият ми проект се фокусира върху предоставянето на ценна информация за подобряване на пазаруването за клиентите и създаване на програми за лоялност за известна компания от магазини Whole Foods.

Бях позициониран като Data Engineer на платформата Azure за осигуряване на целостта на данните и валидиране на данни на нивото „от суровина до източник до подготвен продукт“. За процесите на валидиране на данни разработихме рамка за автоматизация на тестове, изградена върху рамката pytest.

Потокът от данни започва, както следва:

1. Един запис от тестови данни (.avro файл) и конфигурационен файл се копират от суровия слой в Blob Storage.

2. От това събитие на копирания конфигурационен файл се извиква ADF (Azure Data Factory) конвейер, който от своя страна анализира тези тестови данни към клъстера Azure Databricks.

3. Този клъстер е отговорен за извършването на малки трансформации на данните, като например конвертиране на типа данни от avro -> parquet, промяна на имената на колоните за целите на съвместимостта и др.

4. След като трансформациите са извършени, трансформираните тестови данни се копират в изходния слой на Blob Storage.

5. Тестовата рамка чрез Azure SDK валидира данните на суровия и изходния слой, например: проверки на схемата, проверки на данните, проверки за дублиране, проверки на колоните.

6. След като всички тестове са събрани, pytest създава файл с резултати от изпълнението на теста junitxml_report.xml, който е необходим за инструментите за отчитане, за да визуализират резултатите от теста.

Предоставихме 2 различни инструмента за отчитане: Zephyr Scale Rest API и Allure.

Стажът се състоеше в поддръжка на наследена банкова система за клиенти от Балканите.

Системата се състоеше от настолно приложение, съвместимо с Windows XP, написано на езика за програмиране CAVO (Visual Objects).