About

My name is Peter Stukalov. With 20 years in infrastructure, I've learned one simple thing: an engineer's value isn't defined by a list of technologies on a resume, but by their efficiency.

​

So, what is my efficiency?

​

Simply put, it's the result divided by the resources spent. My primary resources are my time and my employer's money. The result is a bit more complex; it consists of two key parts:

1. Service Stability (availability, uptime) — this is the domain of SRE.

2. Quality of Services for Developers — this is the territory of DevOps.

​

Stability is easy to measure—that's what SLI/SLO is for. But the quality of developer services is a real challenge. Often, developers themselves don't know what they need from the infrastructure, beyond the obvious CI/CD and monitoring, which are just the tip of the iceberg. (This topic is covered in detail in the article about IDPs, so we won't dive deep here).

​

Now, let's get back to resources. The amount of company money spent per "unit of result" is almost constant. It changes slowly with general technological progress, and only if you're already using optimal technologies. Sure, there are optimization projects, but that's not what I think about every day. The exceptions are giant corporations and high-load projects where cost-saving is critical. But for 99% of companies, a 1% reduction in the AWS bill means absolutely nothing; there are far more powerful levers for boosting efficiency.

​

So, I'm faced with a task. And there are two ways to approach it.

The first way: complete the task without thinking about its meaning and go home in the evening with a clear conscience.

The second way: try to understand the reason the task appeared and solve it in a way that prevents similar tasks from ever arising again by eliminating the root cause.

​

With enough experience, I have a good idea of what tasks I'll face in the future. This means the current problem needs to be solved in a way that makes future tasks easier to complete. It's like I'm building a foundation, forming my own "best practices."

​

There's a catch to this method. It isn't for people who aren't interested in their work and do it just for a paycheck. It requires investing time beyond what's mandatory, especially early in your career—learning new things, experimenting, and constantly working on your efficiency.

​

This approach, where completing future tasks is made easier by the ones already done, is what I call the systemic approach.

​

As a result, my experience and my "best practices" evolve into a platform. It's not just a collection of tools, but a system that transforms infrastructure from a cost center into your competitive advantage. This is what I build.