Frontend Reliability: From Alerts to CRO

Boris grew up in Belgorod, where his gymnasium unexpectedly became a lyceum with maths classes; he disliked travelling to olympiads and, in his words, studied for himself. Having won the university's own olympiad, he enrolled at the Shukhov Belgorod Technological University right next to his home, on a computer security course, but spent his energy on programming: while his whole year wrote Delphi, he alone worked through C++ and could sit for days over segmentation faults and memory leaks. His first job came from a puzzle about splitting gold without scales: one divides, the other chooses; Alexander adds that a patented American scheme for dividing property in a divorce rests on the same algorithm. Boris does not name the company — it has since collapsed as a pyramid scheme — and in roughly three months of writing trading robots there, as he recalls, he never produced a profitable one.

Then came JavaScript freelancing, a CRM for a spectacles trader in an office plastered with barcodes and with nobody to learn from, and parking payment systems on Node.js with home-made frameworks. He left for better money to a contractor company and on his very first day, 17 November 2016, landed on the bank's project; he remembers the date exactly, and his honest answer to why there is luck: his criteria were money and remote work, his goal enterprise experience. His first task was changing a line of copy on the last step of the Platinum form, and it came as a culture shock: on parking systems he had built a feature end to end, from the database to the front, while here the text was computed in a tricky way and reordered the steps of the form. Alexander recalls that teams were being split by domain then, and Platinum led on changes: the most traffic, tests and hypotheses.

Then came the fog of war: showing a grey hint inside an input field meant rewriting every dropdown, including selects you cannot type into at all, and a separate adventure was working out why the rouble sign would not render — there was no design system yet. Boris counts that experience useful: instead of one correct model he saw how not to do things, which spared him many mistakes. When the teams were split, his team lead left the company and Boris took over the cards team. He recalls that Alexander, it seems, warned him that he would be further from the code and his technical knowledge would sag, as everyone's does, so he kept reviewing and joining tasks himself, admitting he was too young then to let the code go. He also read books on kanban and scrum and fought for a long time to drop sprints from a pseudo-scrum and refill the backlog by limits instead — there was a lot of inertia, and people did not see why anything should change.

His team piloted Platinum on the new micro-frontend architecture and wrote its own test cases: automated coverage was markedly higher than in practically any team left in the monolith. He moved with that practice into forms development, and then the monitoring project came his way: production problems surfaced through the service desk, and alerts over logs were set up by a team outside their org structure that never went into the code. Boris took that responsibility over, reworked the alerts, wrote code for the gaps nobody covered, and when logs in Splunk stopped keeping up on speed he moved the front-enders onto metrics. Then came on-call rotations in the development teams, with instructions for whoever was on duty, and an error budget for release windows: a failure is caught fast and rolled back without paging everyone. He read Google's first SRE book as soon as it appeared — ready answers on how to monitor something were constantly missing. A separate question was what to do about a spike when some users simply have bad internet: that is how he arrived at monitoring the business.

A project conceived as sorting out the dashboards and changing the alerts led him into questions of organizational structure, and at the next reshuffle the SRE teams became his reports: responsibility turned de jure, not only de facto. By Alexander's account, the centralized SRE team of a unit of almost a thousand people was split across four domains, and the web went to Boris. Boris confirms that their reliability engineers write platform code and join projects as developers — shift left, where you assemble the box whose requirements you will later enforce. A story of its own is the old account web: a microservice monolith somehow cut into three dozen applications, each pulling the monolithic codebase in through an adapter. There was no observability, and the Kubernetes specs had been written by developers between features: in roughly 70% of the applications the very first request ate the whole CPU quota, so the second user waited a second. Server-side rendering on Node needs at least a core, so Boris recalculated resources in a spreadsheet, and a project team managed, barely, to generate static stubs — the account web did not need rendering at all.

The new architecture was designed in advance: the need for micro-frontends was challenged with stakeholders for a long time, and then three architects, as he recalls, designed a single application with a router and PWA specifics, into which teams plug via ready instructions and pipelines. The operational burden moved to the platform — product front-enders no longer need to know Kubernetes — and the limited set of bricks is, in Boris's view, convenient for generating simple micro-frontends from Figma with AI. The CRO role added the mobile part and the API to the web, and the difficulty proved managerial: the position exists nowhere outside the company, there is nobody to ask, and technically the hardest part was a common language with mobile development, where the same terms mean different things. Boris calls his own position a floating one: he went through the rebranding as an engineer, then swapped the mask for a manager's one, and a CRO who fixes an outage by hand does not scale. His advice to engineers is to work out first why they want to grow, and he notes that every surge in his own growth followed a good book.