Vadim Alekseev

Infrastructure Reliability Consultant

20+ years in IT operations and network monitoring. I built and ran a Network Operations Center (NOC — the team that watches infrastructure health around the clock), led Problem Management (the practice of finding root causes, not just closing tickets) at a bank, and audited infrastructure reliability for ITSM clients. I read incident data for a living — OpsLab is the statistical engine I built to do it faster and prove the pattern with numbers.

NOC / Monitoring Problem Management ITIL SLA design Incident statistics

Built reliability practices, not slide decks

2005–2019
Rostelecom

Built the North-West Russia NOC from scratch

Cut mean time to repair (MTTR — how long it takes to fix an incident) by 20%. Built a failure-forecast model on historical data, preventing 4+ major network incidents a year.

2021–2023
Bank Saint-Petersburg

Led Problem Management and monitoring for digital transformation

Ran Problem Management (root-cause practice) plus 12 ITIL practices. Built a monitoring service from zero. Held SLA at 99.9% ± 0.2%.

2019–2021
ITSM consulting

Independent infrastructure audits

Cut failure rate by roughly 50% across engagements. Raised availability from 95% to 99.8%.

1999–2004
Lensvyaz

Chief engineer — telecom, networks, power

Radio communications engineer by training. "Master of Communications" award, 2013.

The engine finds the pattern. I read what it means.

A statistical report tells you what happened in your data — a repeat cycle, a cluster of related incidents, a shift after a release. It does not tell you whether that matters, or what to do about it. That judgment call comes from having run a NOC, owned an SLA, and sat in the room when a bank's systems went down. OpsLab computes the numbers; I read them the way 20 years of on-call experience taught me to.

What the statistical engine looks for

Six core methods out of 20+ in the OpsLab engine — the full catalog also covers correlations, trend diagnostics, anomaly detection, and per-service breakdown. Click a method name for the one-paragraph detail and a real example.

Pareto rankingwhich 20% of incidents cause 80% of the downtime
Clusteringare 47 errors actually 3 distinct root causes?
Periodicitydoes the failure repeat on a hidden schedule?
Before / afterdid the last change help or hurt — proven, not felt
Tail riskhow bad can the worst-case outage realistically get?
Event associationswhich warning signal fires before the outage?

Pareto ranking (Gini + Lorenz curve)

Ranks incidents by how much downtime each one causes, so you fix the few that matter instead of the many that don't. The Gini coefficient (an inequality measure — 0 means all incidents are equally bad, 1 means one incident caused everything) tells you how concentrated the problem is.

Example: 3 out of 90 incidents = 41% of total downtime. Gini = 0.67.

Clustering (K-Means)

Groups incidents by behavior pattern (time of day, duration, frequency) instead of by ticket category. Reveals when a long list of "different" errors is really a small number of root causes.

Example: 90 incidents → 2 clusters — "night-short" (peaks 02:00, ~2h) and "morning-long" (peaks 10:30, ~8h). Two root causes, two teams.

Periodicity (Lomb-Scargle)

Finds hidden repeat cycles in uneven time series — a method from astrophysics, applied to incident logs. Reports FAP (False Alarm Probability — the chance the detected cycle is random noise).

Example: period = 23.1h, FAP = 4×10⁻⁸ → almost certainly a cron job or scheduler, not chance.

Before / after comparison (Mann-Whitney + Cliff's δ)

Tests whether a change (a deploy, a config update) actually shifted incident frequency, and by how much. Cliff's δ (effect size — how big the shift is, from 0 to 1) turns "it feels worse" into a number.

Example: Cliff's δ = +0.445, p < 0.001 → incident rate increased with over 99.9% confidence.

Tail risk (Generalized Pareto Distribution)

Estimates the probability of a rare but very long outage — the one that breaks an SLA. Built for planning, not for the average case.

Example: 1% probability the next major incident lasts 72+ hours — the number to bring to an SLA negotiation.

Event associations (Apriori-style lift analysis)

Finds which events tend to appear together and in what order, so an early-warning alert can be set on the leading signal instead of the crash itself. Lift measures how many times more often a pair occurs than by chance.

Example: database_timeout → app_crash in 89% of cases, lift = 4.2 — set the alert on the timeout.

How the analysis is built

Statistical enginenumpy, scipy, statsmodels — deterministic, no AI guessing
Narrative + cross-checkindependent AI models, writing only, never computing
DeliveryTelegram bot + web upload, PDF report
ITSM backgroundZabbix, Nagios, Jira SM, ServiceNow exports

Have an incident log you'd like a second opinion on?

Send it through OpsLab for the statistical read, or message me directly to talk through what it means for your infrastructure.