You hear about outages last
The site is down for forty minutes until somebody writes to support. Or nobody writes — they just leave.
I set up continuous checks and alerts so the failure is reported by your systems.
I set up monitoring, close off unnecessary access to your server and put deployment in order. The goal: a failure should reach you from your systems, not from your users.
I review the task before any work starts. If there is no problem, I will say so.
Sound familiar?
The site is down for forty minutes until somebody writes to support. Or nobody writes — they just leave.
I set up continuous checks and alerts so the failure is reported by your systems.
When a system sends twenty messages an hour, people stop looking — and miss the one that mattered.
I configure grouping and inhibition: one failure, one message.
A contractor set it up two years ago, and things have been bolted on ever since. Now everyone is afraid to touch it.
A written review of what you actually have, and a plan for what to fix first.
Services
Described by outcome, not by tooling: you are buying “I find out about failures first”, not a product name.
You discover failures before your customers do.
Weaknesses found before they cause an incident.
The cause of the failure, not another restart.
The application runs the same on every server.
Releases without manual file copying, with a rollback.
A backup you have proven can actually be restored.
Kafka from scratch, or an existing setup stabilised.
Repetitive manual work leaves your day.
Evidence
All of it was done on my own infrastructure, which I run as production. The numbers are the measured ones; details that would identify the servers are deliberately left out.
System journals had grown to 4 GB and kept going.
4.0 GB → 31 MB, growth stopped
Read
No metrics, logs scattered, health judged by whether the site opened.
Not a single new port exposed
Read
The observation host lost connectivity and declared five healthy sites down.
A write-up of my own mistake
Read
What you get in hand
Work ends with a document: what was found, what was done, how it was verified and what is left. You can read it six months later and still understand why things were done that way.
Who does this
Dmitry Savichev
SRE/DevOps engineer
Three years supporting infrastructure and microservices in fintech. Alongside that I run my own environment of nine services on two servers — metrics, logs, alerts and automated deployment.
A couple of sentences about your infrastructure and what worries you is enough for me to tell whether I can help.