Ich bin Iliyan

Mein erstes Projekt war bei einem Softwareunternehmen, das globale Vertriebsdienste für Fluggesellschaften anbietet. Der Vertrieb dieser Datenprodukte ist in der Reisebranche angesiedelt.

Ich war Teil des Teams für Ticketreservierungen. In meiner Rolle als Platform Engineer bestand meine Aufgabe darin, die Datenverarbeitungs-Pipeline zu warten,

zu betreiben und weiterzuentwickeln. Diese Pipeline ist verantwortlich für die Aufnahme der vom globalen Vertriebssystem (GDS) gesendeten Rohdaten,

deren Verarbeitung über mehrere Ebenen hinweg sowie die abschließende Übermittlung an den Kunden mittels verschiedener Übertragungsprotokolle (FTP oder S3).

Zu meinen dortigen Erfolgen zählen:

• Migration von Legacy-Groovy-Skripten in ein internes Framework namens „Workflow“, das den gesamten Lebenszyklus – von der Erstellung über das Testen bis hin zur Veröffentlichung einer Anwendung –
• Umstellung eines Frameworks zur Datenübermittlung (Feed Delivery) von einer einzelnen Bash-Datei auf eine saubere, modulare Sammlung von Python-Skripten, wodurch Zuverlässigkeit und Wartbarkeit des Systems erheblich verbessert
• Refactoring eines Python-Skripts, das für die Komprimierung und Übertragung von Kundendaten vom „Raw“- in den „Source“-S3-Bucket zuständig ist; dies ermöglichte sowohl eine Erweiterung der Funktionen entsprechend den Anforderungen des Managements als auch bessere Testmöglichkeiten vor neuen
• Signifikante Verbesserung der internen Dokumentation durch Modernisierung entsprechend dem aktuellen Wissensbedarf sowie Entfernung veralteter
• Leitung der Migration unserer internen Repositories sowie der Repositories der Entwickler von Bitbucket zu
• Erstellung eines übergeordneten Konzepts für eine „saubere“ Release-Durchführung, wodurch der Rollback-Prozess optimiert und das Vertrauen des Change Advisory Board (CAB) gestärkt wurde

Mein erstes Projekt konzentrierte sich auf die Entwicklung von Fahrerassistenzsystemen (ADAS) für ein multinationales Automobilunternehmen.

In diesem Projekt war ich als DevOps-Ingenieur im Bereich des AWS-Cloud-Infrastrukturmanagements tätig.

Wir waren für die Wartung der gesamten Cloud-Plattform verantwortlich, einschließlich der Bereitstellung von

Kundenprodukten mithilfe des AWS ADF-Frameworks, der AWS Account-Vending-Machine und der benutzerdefinierten REST-API von AWS Control Tower.

Wir waren außerdem für die Verwaltung der Cloud-Plattform mithilfe von AWS CloudFormation-Richtlinienvorlagen und allen wesentlichen Ressourcen verantwortlich.

Die Automatisierung dieser Prozesse wurde durch die Verwendung von AWS CDK Infrastructure as Code (IaaC) erreicht.

Im Rahmen meiner Beiträge zu den Kundenservices habe ich folgende Lösungen implementiert:

• Budgetkostenwarnungen für die gesamte Plattform mit einem vordefinierten Prozentsatz der Budgetüberschreitung, um E-Mail-Benachrichtigungen an die Geschäftsinhaber zu
• Erstellung zusätzlicher REST-API-Endpunkte für den Control Tower, um festzulegen, welche neu erstellten AWS-Konten zu welcher VPC gehören.

  Dabei habe ich auch die Logik entwickelt, mit der eine Lambda-Funktion den Kontotyp überprüft und basierend auf der zugehörigen VPC-Vorlage den AWS CloudFormation StackSet im entsprechenden Konto

• Erstellung eines übergeordneten Designs des Datenflusses und der Datenreplikation für die gesamte Datenplattform

Mein zweites Projekt drehte sich um die Bereitstellung wertvoller Erkenntnisse zur Verbesserung

des Einkaufserlebnisses für Kunden und die Einrichtung von Kundenbindungsprogrammen für ein renommiertes Unternehmen der Lebensmittelbranche (Whole Foods).

Ich war als Dateningenieur auf der Azure-Plattform tätig, um die Datenintegrität und Datenvalidierung auf der

Ebene von Rohdaten über Quelldaten bis hin zu aufbereiteten Daten sicherzustellen. Für die Datenvalidierungsprozesse entwickelten wir ein Testautomatisierungs-Framework, das auf dem pytest-Framework basiert. Der Datenfluss beginnt wie folgt:

1. Eine einzelne Testdatendatei (.avro-Datei) und eine Konfigurationsdatei werden aus der Rohdatenebene im Blob Storage kopiert.

2. Das Kopieren der Konfigurationsdatei löst eine Azure Data Factory (ADF)-Pipeline aus, die die Testdaten an einen Azure Databricks-Cluster weiterleitet.

3. Dieser Cluster ist für kleinere Transformationen der Daten verantwortlich, wie z. B. die Konvertierung des Datentyps von Avro in Parquet, die Anpassung von Spaltennamen aus Kompatibilitätsgründen usw.

4. Nach Abschluss der Transformationen werden die transformierten Testdaten in die Quellschicht des Blob Storage kopiert.

5. Das Test-Framework validiert die Daten in der Rohdaten- und Quellschicht mithilfe des Azure SDK, beispielsweise durch Schema-, Daten-, Duplikats- und Spaltenprüfungen.

6. Nachdem alle Testergebnisse erfasst wurden, erstellt pytest eine Testausführungsdatei (junitxml_report.xml), die von den Reporting-Tools zur Visualisierung der Testergebnisse benötigt wird.

Wir stellen zwei verschiedene Reporting-Tools zur Verfügung: Zephyr Scale Rest API und Allure.

Das Praktikum umfasste die Wartung eines bestehenden Banksystems für Kunden auf dem Balkan.

Das System bestand aus einer Desktop-Anwendung, die mit Windows XP kompatibel war und in der Programmiersprache CAVO (Visual Objects) geschrieben wurde.