Site Reliability Engineering and the Individual Contributor Role

Alexander opens with his biography: born on the shore of the White Sea, a long education, admission to Phystech and a near expulsion, after which he dropped computer games to level up a different character in real life. He worked as a developer and an analyst, tried team leading, and just under eight years ago joined the bank as an engineering manager over three teams and ten people; his first boss came from the business and owned customer acquisition. The role widened every eighteen months to two years, and in early 2023 he took over a block called client interfaces, marketing and engagement — the first challenge, he admits, was naming it. By mid-year it was clear he could not carry a block of nearly a thousand people: it had to be split into domains, each with a goal, a main stakeholder, a plan and a need for its own technical director. By the end of the year there were four.

The other half of the job is architecture as a function: with more than 40 million users any outage is visible and other people's money is at stake, so the baseline must be raised where practices are weaker. This is maturity management: find the strong practices, build a maturity model and supply tooling and control — without instruments people get worn down and stop. Development processes company-wide he runs with Vitya Nikishin, a guest of an earlier episode; shortly before the recording he spoke at a conference on why and how to measure engineering effectiveness. Another theme is the tax on scale: internal platforms cut developers' cognitive load, but a good practice takes ages to reach the late adopters. The varying bar of rigour comes from the host: rouble payments demand hardcore, a landing page survives as a crooked monolith. Alexander agrees it has to vary; a hypothesis can be tested with relaxed requirements, but past a cut-off in customers who see it, the bar returns.

Reliability rests on an in-house observability platform: written to replace Splunk after it left Russia, it supported the old unstructured log format, gained its own query language, and only then were teams moved to structured logs. On top sits a tool for registering and tracking SLAs: a service gets a health index and a computed uptime, incidents are raised automatically, merged into parent and child ones and paged to whoever is on call; beside it lives a service catalogue. Alexander has never been on call himself, but as technical director for part of the products he sits on the escalation curve: he is called not to fix but to be aware, and sometimes to coordinate. He did curate the troubleshooting hiring section: the candidate plays an SRE lead who left for a conference without a laptop, the interviewer a junior who joined two weeks ago and will press whatever buttons he is told by phone. It is a tabletop role-playing game: the game master builds the world and rolls the dice himself — bad luck, the logs are gone.

He comes at reliability from design: non-functional requirements sound unimportant, so they are better called quality attributes, or architectural characteristics. Google refuted the belief that a reliable system needs reliable components: with no money for expensive servers, search, MapReduce and the GFS file system were built on commodity hardware with redundancy and failure handling designed in. Then comes the wall between development and operations: one side is measured on shipping fast, the other on changing nothing. On his own podcast he went through Accelerate with Igor Kurochkin: the surveys showed speed does not contradict stability, because frequent releases ship in small increments and roll back quickly. Hence two schools — build it, run it, where the team is on call itself and leans on a self-service platform, and a separate SRE function, first described in a Google conference talk in 2007, so engineers would automate operations. Both exist here, but dedicated SREs cost the feedback loop: Alexander was handed root on the servers of one of Russia's fifty most loaded sites more than ten years ago, and that responsibility sharply raised his appetite for knowing what could go wrong.

On security Alexander speaks carefully — no expert, he says — but singles out two directions. First, shift left: checks of images, dependencies and vulnerabilities built into the pipeline rather than a separate stage, so speed does not suffer. Second, security is an architectural characteristic like any other, best approached from a threat model, and a risk is sometimes easier to avoid altogether: hand card data to a payment provider with the commission and the headache. Reliability and security intersect: under load a system is sometimes saved by switching off part of its protection, and an attacker only has to create that load; Google's book Building Secure and Reliable Systems argues for treating them together. A reliability incident has no adversary, much as consensus is taught on simple crash faults until the Byzantine ones; in a security incident you first work out how far the intruders got, and only then design the counter-measures. The hard part is not knowledge but adoption: an engineer has to be told why he needs this at all.

The company drew two career paths: one into engineering management, one for engineers who want to grow beyond senior — management once looked like the only road past senior, as Alexander knows first-hand. The engineering branch — staff, principal and above — is assessed against an SDE matrix with, by his reckoning, about five axes: impact, scope, leadership, complexity and improvement. The badge is granted not for years served but against a real company need: someone owned the technical side of a complex system or internal platform, and the promotion packet carries RFCs, pull requests and documentation for profession leaders to review. A growth example sits nearby: Borya, a front-end engineer, became a team lead over six years, took on reliability for the web and personal accounts, and grew into the chief reliability officer role products keep alongside a CTO. From a book on staff engineers Alexander lists four archetypes — tech lead, solver, architect and right hand to the CTO — and warns that pushing decisions through by authority is poor form: better to lead a team to the answer with questions. The closing moral: keep learning for life.