Because it can’t be used to put out a fire now
Professional deformation: when work forms bad habits
I’ve already written that in the IT sphere, with hundreds of context switches per day, it’s not home habits that define our work approach — rather, work itself molds in us the habit of immediately solving problems, often without proper analysis of consequences.
I’ve found a few examples for you of how people succumb to the temptation of instant gratification, using impulsive buying as an example. Poor souls, at the moment of ordering, thought that clicking “buy” was the only step toward solving their problem.
Who did this?Imagine this: CTOs and PMs of large companies behave exactly the same way. They order “quick-fix solutions” from DevOps teams. Upon receiving the long-awaited “box” with cutting-edge technologies (Apache Kafka, object storage S3, sharded databases, semantic search), they fail to notice the unpleasant truth: the product comes without installation, configuration, or operational manuals. There are no deployment scripts, no scalability, no performance monitoring. And most importantly — no one informed the DevOps team that these technologies would even be implemented.
Three months pass since the order was placed, but instead of the long-awaited relief, the manager faces a new round of problems. His disappointment can be expressed as: “The box arrived… but after three months of delivery, I forgot why I ordered it.” The pursuit of quick wins turns into operational chaos, while the absence of strategic planning turns technology into an endless source of difficulties.## We Need Kafka for the Next Release
Someone from the tech leads read an article on Habr about “event streaming in real time,” nodded, and said we need Kafka. No request for proposals. No architecture review. No DevOps involvement. Familiar?
Yes, Kafka is open source. Yes, it scales. But ask any team that has operated it in clusters: Kafka’s maturity is not linear — it’s a step function.
- 0–6 months: “It’s all working!” — Hidden partition imbalance, uneven broker load, uncontrolled latency
- 6–12 months: “Why are latencies increasing?” — Manual rebalancing, firefighting, fragmented ownership
- 12+ months: “Who’s responsible for this? How do we even turn it off?” — “Zombie birth” with unaccounted costs for external support
Without DevOps-ready automation, observability, and lifecycle management of the entire Kafka ecosystem, you don’t get data streams — you get Telegram alert streams.## S3-Compatible Storage? Great. Now Protect It
The Ozon team spent months rebuilding Lusca on S3-compatible storage—not because S3 is complicated, but because implementing strong consistency over event-driven systems, managing database background processes, and recovering terabytes of data are tasks requiring deep expertise and time.
Worse still: if you deploy this behind containers without DevSecOps hygiene—without image scanning, without secret storage, without L7 network policies—you won’t create a storage system. You’ll create a vulnerability vector and technical \u003cdel\u003edebt\u003c/del\u003eBurning.
Database Sharding: The Point of No Return
Shard only after exhausting vertical scaling, query optimization, caching layers, and read replicas. This is the last resort.
Doing it wrong — we’ll get “hot” shards, replication lag, and query failures between shards. Especially if the sharding key is chosen incorrectly. Doing it without DevOps tools for backup, monitoring, and redistribution — we trade scalability for resilience.
The point is: we won’t be able to “un-shard.” Once we implement such a solution, there’s no easy way out without massive pain.
Now comes the real problem — not technical, but organizational
No benchmark will tell you that the biggest bottleneck in modern DevOps isn’t mental resources, memory, or operation speed. Because it’s — decision delays caused by problems with roadmaps.In some companies, there is no DevOps roadmap. In others, there isn’t even one. Because strategy is handed over to demo-driven knee-jerk solutions.
What does a reactive execution culture lead to?
- After the CTO signs off on development, engineers don’t get specifications—they get a nudge: “Automate this across 100 servers,” with no documentation, no clear architecture, no test coverage.
- Three months later: “Why is this so slow? And why did we even build this?”
This is not leadership. It’s evasion of responsibility.
DevOps teams in reactive organizations burn their goodwill, chasing ghosts in logs and dashboards, fixing what they never designed and defending what they never owned.When does something break? Blame falls on people, not on processes. This is not DevOps—it’s a team of clairvoyants, YasnoOps. A mature DevOps culture doesn’t ask who made the mistake. It asks what caused the failure and fixes the system, not looking for the culprit. In your case, the system failure stems from the absence of a roadmap and the lack of DevOps involvement at the decision-making stage.
Russian Context: Speed vs. Stability
In 2023–2024, the SaaS market in Russia grew to several trillion rubles, but this is not a stable, predictable market—it’s a pressure cooker. The race to appear modern is destroying the very foundations needed to be modern.We are supposed to move in the direction set by GOST. Toward unified logging, certified APIs, monitoring, compliance with FSTEC requirements, and supply chain integrity. But how do we embed standards into an architecture built on haste and impulsive decisions? How do we ensure security if DevOps teams weren’t involved in the design?
Such a company still treats infrastructure as a secondary concern. This is not an engineering failure. It’s a failure of managing expectations.
How to change this?
The solution lies in shifting perspectives:
- From “Let’s build this now for sales” → “Are we ready to own this in the foreseeable future?”
- From speed of feature delivery → platform resilience
- From DevOps as a fire brigade → DevOps as a co-architectLarge companies have gone this route. They publish their roadmaps. They delay launches for stability. They measure operational readiness, not just release dates.
They understand the simple truth — speed without control is not agility. It’s drift. And it’s especially unacceptable in enterprise software, where state secrets are at stake.
To emerge from a crisis, a transition is required
- From reactive management to proactive planning — developing a DevOps roadmap, involving all stakeholders early on.
- From executors to strategic partners — recognizing DevOps as an essential part of product development.
- From chaotic implementations to structured transformation — phased technology adoption with pilot programs and iterative gap identification.
- And then the “Buy” button won’t be clicked automatically
Because in today’s realities, especially under the conditions of GosTech, ignoring operational maturity is not just a risk—it is a strategic mistake.