The systems behind the work

Responsibility inside ATLAS

From 2016 to 2021, I worked as an ATLAS Trigger and Data Acquisition (TDAQ) system administrator at CERN, alongside research appointments connected to the University of Udine, INFN and ICTP. ATLAS depends on a computing environment that supports the operation of a major particle-physics experiment. Systems administration was a defined professional responsibility within that collaboration.

A concrete example is the 2020 paper Designing a New Infrastructure for ATLAS Online Web Services, which I co-authored with Sergio Ballestrero, Franco Brasolin, Diana Alessandra Scannicchio and Matthew Shaun Twomey. It documents our work on the infrastructure supporting ATLAS online web services. This combination of experimental science, shared engineering and operational responsibility is the foundation I bring to company infrastructure.

Compute for research

I manage cloud and on-premises computing infrastructure, including Azure environments and the resources used for machine learning and GPU workloads. I work with researchers and developers to understand what their software needs in terms of compute, memory, storage and connectivity, then provision and maintain the environment around it. Capacity is only part of the problem. A useful environment also needs clear access, a workable configuration and a cost that the company can sustain. I provide the infrastructure on which the research teams build and run their work.

Enabling AI and robotics

I support research and development in AI and robotics by providing the compute, software tools, networking and secure access the work depends on. That means coordinating GPU and machine-learning resources with development environments, as well as the IT and workplace needs around laboratory activity. I work with researchers and developers to turn requirements into usable setups, resolve dependencies between teams and keep the supporting systems operational. Experiments and software development can then progress in a working environment, with someone responsible for addressing infrastructure issues as the work evolves.

Infrastructure as code

I use Terraform, Bicep and Puppet to automate provisioning and configuration. Writing infrastructure as code makes its setup inspectable and gives changes a history that other people can follow. My work includes defining resources, managing their configuration and reducing the manual steps needed to reproduce an environment. I also handle the operating work around the automation: investigating failures, keeping deployments understandable and making sure that a configuration remains useful after its first successful run.

Tools for developers

I administer GitHub Enterprise and GitHub Actions, including access, repositories, runners and the workflows used to build and deliver software. I help development teams put CI/CD into practice and resolve problems where code, credentials and infrastructure meet. I also support technical integrations between services and organisations, including API connections. I bring the platforms, automation, access and technical coordination together so colleagues can develop, test and deliver their work in an environment they can use and understand.

Networks, identity and systems

I administer Linux and Windows systems and the networks that connect people to them. My responsibilities include FortiGate VPN and network perimeter administration, Microsoft Entra ID, identity and access management, and access reviews. I apply least privilege by matching permissions to the work a person or service needs to do. These responsibilities are closely connected: a failed sign-in, an unreachable service or an unreliable connection can involve the endpoint, identity configuration or network, and I work across those boundaries to resolve it.

The IT people use every day

I handle the practical IT work that allows colleagues to start, continue and finish their work: onboarding and offboarding, accounts, hardware, software provisioning and technical support. I prepare equipment, arrange the necessary access and investigate problems with the person affected. That often means moving between a specialist research environment and an ordinary workstation problem during the same day. I treat both as part of the same responsibility, because a missing account or a broken laptop can stop work just as effectively as unavailable compute.

Making responsibility clear

I also work on the governance of infrastructure and IT: making responsibility explicit, documenting how work is carried out and helping the company make coherent decisions about access, tools and services. I connect the technical requirements with budgets, operational needs and the people responsible for the decision. I document the agreed approach and follow through on its implementation. This gives colleagues a clearer path from a request to a decision and a working service. It also makes the reasons for a choice available to the next person who has to operate, review or change it.

Budgets, suppliers and contracts

I manage infrastructure and IT budgets, review spending, compare offers and negotiate with vendors on services and software licences. I handle procurement, reconcile invoices with the services purchased and coordinate the technical and commercial details of contracts with the relevant colleagues. This requires understanding both the requested capability and its continuing cost. I bring those questions into the technical discussion early, so a choice accounts for implementation, support, renewals and the work required to operate it.

An office that works

My remit also includes office infrastructure and operational logistics. I coordinate repairs, technicians, equipment and the practical interventions needed to keep the workplace functioning. This work involves identifying what is needed, finding the right provider, arranging access and timing, and checking that the problem has been resolved. It uses the same habit of follow-through as an infrastructure change: understand the dependency, organise the intervention and make sure the people affected can get back to work.

Making the work transferable

I write runbooks, document decisions and help colleagues learn the systems they use. My scientific background helps when a conversation moves between researchers, programmers and mathematicians: I can discuss the purpose of a workflow as well as its computing requirements. I want another person to be able to understand what has been built, operate it and know where to look when something fails. That is the thread through my work: engineering the system, coordinating what surrounds it and leaving enough knowledge for other people to continue.

From one computer to a shared environment

In a 2021 paper with Giovanni Guerrieri, I explored ways to deploy ATLAS educational resources for multiple users. The proposal brought together infrastructure as code, virtual machines, containers and Jupyter environments.

The user’s experience provided the organising question: how can a university offer a usable analysis environment without making every student solve the installation problem independently? Reproducible deployment instructions can carry knowledge from the original developers to local instructors and administrators.