Acronis

Acronis: From performance tests to a diagnostics platform

Senior Software Developer / DevOpsFebruary 2022 – August 2026

Built an internal performance-testing application from scratch and evolved it into a reusable platform for execution, browser evidence, diagnosis and operational workflows.

Context & constraints

A browser performance test is useful only when its result helps someone understand what happened and what to change. At Acronis, I built an application to run UI performance tests programmatically, catch regressions and investigate failures. Over time, the work expanded from a runner into a platform connecting web/API services, scheduling, workers, reporting and operational controls. The engineering challenge crossed the browser, backend, infrastructure and the teams investigating the results.

  • Test execution and reporting had different responsibilities. Browser work needed a controlled execution environment; completed runs needed processing, storage and useful presentation.
  • The platform had to support API-driven workflows as well as a user interface, and workers needed to communicate with a central application across regional worker groups.
  • Useful diagnostics required more than a score: screenshots, video, network evidence and the ability to relate a run to the behavior under investigation.
  • Reliability experiments needed explicit safety, recovery and rollback controls across Kubernetes and virtual-machine environments.

My contribution

  • Built the central application and developed its web/API capabilities. Later work included a Vue interface, schedulers, worker orchestration, composable flows, managed credentials and operational controls.
  • Worked across the execution and report-processing path. The historical system separated a central Web/API application, test workers and a report runner, with RabbitMQ, MariaDB, report storage and diagnostic tooling around them.
  • Developed browser evidence collection and investigation workflows using Playwright, Lighthouse, screenshots, video and HAR data, with earlier versions using Puppeteer.
  • Used the platform to investigate frontend and backend performance issues and help the relevant teams address them. This made the work a feedback loop between test evidence and application changes.
  • Designed safety-gated chaos and incident-reproduction workflows using Chaos Mesh, k6, Ansible and Jenkins, with diagnostics, recovery and rollback. Earlier reliability automation included Chaos Toolkit.
  • Built containerized UEFI/iPXE provisioning and Linux Kickstart/Windows WinPE workflows. Investigated operational issues such as excessive VM IOPS, DHCP failures and recovering lost leases from ARP tables.
  • Contributed technical direction, architecture reviews, root-cause analysis, hands-on troubleshooting and mentoring.

Technology context Node.js · Express.js · Vue.js · RabbitMQ · MariaDB/MySQL · Playwright · Lighthouse · ELK · Grafana · Docker · Kubernetes · Chaos Mesh · k6 · Ansible · Jenkins · iPXE · Kickstart · WinPE

Historical architecture, reconstructed from my work

A central Web/API application coordinated browser execution and made completed-run evidence available for reporting and investigation. This historical reconstruction brings together responsibilities from successive stages of the platform.

Components & responsibilities

Central Web/API application
User/API workflows, scheduling, run coordination and later Vue/operational controls.
RabbitMQ
Queueing within the execution platform.
Test workers
Browser execution, internal API communication and regional worker groups.
Report runner
Processes completed runs, generates reports and populates diagnostic views.
MariaDB & report storage
Application state and retained run/report material.
Diagnostic views
Internal viewer, ELK and Grafana context for investigation.

Connections & flow

  1. Central Web/API application to RabbitMQExecution coordination
  2. RabbitMQ to Test workersQueued work
  3. Test workers to Central Web/API applicationInternal API communication
  4. Central Web/API application to MariaDB & report storageRun state & reports
  5. MariaDB & report storage to Report runnerCompleted-run material
  6. Report runner to Diagnostic viewsProcessed evidence

The earlier report runner and each test worker processed one test at a time on dedicated VMs; orchestration and UI capabilities evolved later. Queue arrows show responsibilities at a high level.

Action-centric frontend observability remained a separate exploration and proof of concept.

Decisions & trade-offs

Separate coordination, execution and reporting

Browser workers, application workflows and post-run processing have distinct responsibilities and operational behavior.

Trade-off: This makes the system easier to reason about in parts, while adding coordination, state transitions and failure paths that need diagnosis.

Collect evidence alongside test results

Screenshots, video and HAR data help connect a failing or slow interaction to a concrete investigation.

Trade-off: Richer evidence adds storage and processing work, so capture and reporting become platform concerns of their own.

Keep execution controls visible

Composable flows, worker controls and managed credentials make a runner useful across more workflows.

Trade-off: Flexibility increases the number of states an operator needs to understand and recover from.

Build recovery into reliability experiments

Incident reproduction and chaos workflows need diagnosis, rollback and recovery as part of the workflow design.

Trade-off: Safety gates add preparation and orchestration, but keep an experiment connected to an operational recovery path.

Outcome & operation

The application became a reusable execution and diagnostics platform and supported performance investigations that led to frontend and backend improvements. The work also produced provisioning automation and reliability workflows with explicit recovery controls. Its value was in connecting a test result to evidence, investigation and a practical engineering response.

Notes & references

Professional experience
Work performed at Acronis between February 2022 and August 2026.

Related career context

Explore all cases or read the complete career.