Production IT systems should be
operable - not
mysterious.
Many systems work day-to-day but become fragile when something needs to change. I help turn fragile infrastructure into systems that teams can safely operate, trust, and own independently.
Signs your systems are more fragile than they appear
These patterns usually don’t fail immediately - but they increase risk over time.
Single-Admin Dependency
Only one person truly knows what is safe to change. If they are unavailable, the team hesitates - or stops touching production entirely.
Fear of Change
Routine tasks such as updates, configuration changes, or scaling feel riskier than they should. Even small adjustments trigger uncertainty.
Infrastructure Opacity
Systems are running, but how they actually work has become unclear. Documentation is outdated, partial, or missing.
From mysterious to manageable
Whether the trigger is an acute problem or a planned project from the backlog, I start by making current behavior visible. From there, urgent risks, missing knowledge, and long-term cleanup can be separated into practical next steps.Inventory
Map services, dependencies, and ownership, and identify who actually carries the risk if something breaks.
Baseline
Establish a measurable current state from logs, metrics, dashboards, and alerts, before making any changes.
Stabilization
One step at a time: Rollback-capable updates, migrations, or platform moves.
Documentation
Hand over runbooks, diagrams, and operating notes, so your team can take it from here.
Typical starting points
Concrete moments where a short, structured engagement can reduce operational uncertainty and make the next change less risky.Monitoring and Alerting Baseline
For Grafana, Prometheus, Loki, or similar setups where health, noise, and coverage gaps are hard to assess.
Complex Service Operations Review
For grown service stacks such as self-hosted GitLab, where configuration, usage, or changed demands have outpaced the team's current capacity.
Virtualization Operations Improvement
For Proxmox-like VM and container environments where storage, backups, resource limits, or service dependencies need a clearer operating model.
Gradual Migration from Grown Infrastructure
For services that need clearer ownership, safer deployment, or stepwise replacement without a disruptive rewrite.
Start with a structured conversation
Many fragile production environments look stable on the surface. A short call is often enough to clarify whether your situation fits and what a reasonable next step could be.
Non binding
Confidential
Pragmatic assessment
About Me
I join when your IT service systems need a sharp pair of hands for a defined push.
I'm an independent software engineer with an infrastructure bias. I like the messy middle: logs, dashboards, shell sessions, service configs, CI runners, VMs, and the notes that explain why a system became the way it is.
My PhD work in scientific computing had me building and operating bioinformatics pipelines at the fast-paced Max Planck Institute for Molecular Genetics in Berlin. Later, I broadened that perspective at the German Climate Computing Center in Hamburg, working on monitoring and energy efficiency in an HPC datacenter. Different scale, same problem: not always enough hands for the work the system needs.
I am at my best when a team needs extra depth for a focused project: Understand the real dependencies, make the next change safer, clean up what blocks progress, and leave behind knowledge the team can actually use.
Strongest in focused projects
Give me a clear goal, access to the system, and room to move: I build momentum quickly, keep findings concrete, and turn unclear service setups into decisions the team can act on.
Fast orientation in grown systems
I can enter systems with partial documentation and find the real dependencies before changing them.
Operator-level technical depth
Monitoring stacks, Linux services, VMs, Containers, Proxmox/Ceph, Storage, and Pipelines are familiar terrain.
Work that transfers back
I do not aim to become the permanent owner. When my engagement ends, your team can run, change, and explain the system without me.