Sergey Gamov
System administrator | DevOps | Python backend developer
System administrator | DevOps | Python backend developer
I’ve always considered myself a system administrator - in the broad, original sense of the word.
For me, it’s a profession that naturally includes DevOps, networking, infrastructure, security, and sometimes software development.
I work at the intersection of infrastructure, automation, and backend development. On projects, I usually help developers, participate in application architecture planning, and stay involved in hardware-level things as well - networks, hypervisors, servers, and system maintenance. If something is unclear or broken, I try to understand how it works under the hood, not just how to "fix it quickly".
Over the years, I’ve been responsible for taking systems from idea to production: designing architecture, automating infrastructure, setting up CI/CD pipelines, deploying applications, and keeping everything running reliably.
I’m not someone who believes that titles like "senior", "expert", or "rockstar" give the right to stop learning.
At this stage, I clearly see areas where I’m not strong enough yet - and that’s fine. I have a long list of things I want to learn and understand better, and I genuinely hope I’ll have enough time to explore all of them.
I haven’t encountered a problem in development or infrastructure - whether it’s networking, hardware, servers, or production systems - that I couldn’t eventually figure out. When I hit a wall, I try to break it down piece by piece. Even if the solution isn’t perfect at first or comes from an unexpected angle, I always get to the root of the problem.
That process inspires me and makes me stronger as an engineer.
I prefer to automate everything possible and usually aim for 80% of the result with 20% of the effort, knowing when perfection actually matters - and when it doesn’t.
Participated in a multi-year project to transition a product from symmetric encryption to an end-to-end encryption architecture. During the design phase, I identified a performance bottleneck in the original approach and proposed an alternative based on competitive research - which was accepted as a compromise and became the foundation for the final implementation. The cryptographic components were developed by a dedicated specialist; my role focused on infrastructure planning and the production rollout. The deployment covered 100+ servers and included OS and runtime upgrades, coordinated as a single release. The vast majority of servers were deployed automatically with minimal manual intervention.
I consistently focus on making CI/CD pipelines clean, predictable, and easy to understand. My goal is that any engineer can look at a pipeline configuration and quickly grasp how it works, how it deploys, and where to start if something goes wrong.
I try to avoid tight coupling to a single vendor or technology stack. When designing infrastructure, I prefer tools and services that have clear alternatives, so individual components can be replaced without rewriting or rebuilding the entire system.
I prefer building small, simple services that do one thing and do it well. I’m strongly inspired by the UNIX philosophy, where each tool has a single, clear responsibility and behaves predictably in production.
I actively eliminate routine and manual work through automation. Complex tasks are broken down into smaller steps and automated gradually, making systems easier to operate, debug, and extend over time.
Over the next few years, I’d like to grow more in software development and eventually build a product that people actually use - something simple, clear, and useful.
I also want to:
If my knowledge and experience can make systems more reliable, products simpler, and the world just a bit better - that’s already a great result for me.