К основному содержимому
к выпуску
Конспект выпуска2025CTO

Надёжность фронтенда: от алертов до CRO

Тридцать седьмой выпуск Code of Leadership: Александр расспрашивает Бориса Черныша — руководителя направления развития веб-платформы и CRO управления клиентских интерфейсов, — с которым работает вместе больше шести лет. Разговор идёт от школьной математики в Белгороде через мониторинг и SRE к платформе микрофронтендов и роли, отвечающей за надёжность.

Code of Leadership · выпуск №377 минут

Конспект сокращён относительно полного выпуска; примеры и оценки передают опыт и позиции участников.

Основная линия материала
01

От Белгорода до первой текстовки

Борис вырос в Белгороде, где гимназия неожиданно стала лицеем с математическими классами; на олимпиады он ездить не любил и, по его словам, учился для себя. Выиграв университетскую олимпиаду, он поступил в Белгородский технологический университет имени Шухова прямо рядом с домом — на компьютерную безопасность, но силы тратил на программирование: когда весь поток писал на Delphi, он один разбирался с C++ и сутками сидел над segmentation fault и утечками памяти. Первую работу он получил за задачу о том, как поделить золото без весов: один делит, второй выбирает; Александр добавляет, что на этом же алгоритме построена запатентованная в США схема раздела имущества при разводе. Компанию Борис называть не стал — недавно она закрылась как пирамида, — а торговых роботов писал там, по его воспоминаниям, месяца три и ни одного прибыльного не сделал.

Дальше был фриланс на JavaScript, CRM для торговца очками в офисе, обклеенном штрих-кодами, где учиться было не у кого, и системы оплаты парковок на Node.js с самописными фреймворками. Оттуда он ушёл туда, где больше платят, — в компанию-подрядчика, и с первого же дня, 17 ноября 2016 года, оказался на банковском проекте; дату он помнит точно, а на вопрос «почему именно туда» отвечает честно: повезло, критериями были деньги и удалёнка, а целью — энтерпрайзный опыт. Первой задачей была замена текстовки на последнем шаге формы Platinum, и это стало культурным шоком: на парковках он делал фичу целиком, от базы до фронта, а здесь текст хитро вычислялся и переставлял шаги формы. Александр напоминает, что команды тогда как раз пилили по доменам, а Platinum лидировала по изменениям: больше всего трафика, тестов и гипотез.

02

Туман войны, карты и мониторинг

Дальше начался «туман войны»: чтобы показать серую подсказку внутри поля ввода, пришлось переписать все выпадашки, включая селекты, в которых печатать вообще нельзя; отдельным приключением было выяснить, почему не отображается знак рубля, — дизайн-системы тогда не существовало. Борис считает этот опыт полезным: вместо одного правильного образца он увидел, как делать не надо, и это уберегло его от многих ошибок. Когда команды разделили, его тимлид ушёл из компании, и Борис возглавил команду карт. Он вспоминает, что Александр тогда, кажется, предупредил его: будешь дальше от кода, технические знания просядут, все через это проходят, — и потому сам делал ревью и подключался к задачам: признаётся, что был тогда слишком молод, чтобы отпустить код. Ещё он читал книжки по канбану и скраму и долго воевал за то, чтобы убрать спринты из «псевдоскрама» и наполнять бэклог по лимитам — инерции было много, люди не понимали, зачем что-то менять.

Его команда пилотировала Platinum на новой архитектуре с микрофронтендами и сама писала тест-кейсы: покрытие автотестами было заметно выше, чем практически у всех команд монолита. Вместе с этой практикой он перешёл в развитие форм, а потом ему достался проект по мониторингу: о проблемах на проде узнавали из сервис-деска, а алерты по логам настраивала команда вне их оргструктуры, которая в код не лезла. Борис забрал эту ответственность, переделал алерты, дописал код для незакрытых зон, а когда логи в Splunk перестали успевать по скорости — перевёл фронтендеров на метрики. Дальше появились дежурства в командах разработки с инструкциями для дежурного и бюджет ошибок на время релизов: сбой замечают быстро и откатываются, не поднимая на уши всех. Первую книгу Google по SRE он прочитал сразу после выхода — готовых решений, как что-то замониторить, постоянно не хватало. Отдельным вопросом было, что делать со спайком, если у части пользователей просто плохой интернет: так он пришёл к выводу, что мониторить надо бизнес.

03

SRE, личный кабинет и роль CRO

Проект, задуманный как «разберёмся с бордами и поменяем алерты», довёл его до вопросов организационной структуры, и при очередной перестройке SRE-команды перешли ему в подчинение: ответственность стала не только де-факто, но и де-юре. По словам Александра, централизованную SRE-команду юнита почти на тысячу человек раздали по четырём доменам, и веб достался Борису. Борис подтверждает: инженеры надёжности пишут у них код платформы и заходят в проекты разработчиками — это shift left, когда сам собираешь коробку, к которой потом будешь предъявлять требования. Отдельная история — старый веб личного кабинета: микросервисный монолит, чудом разрезанный на три десятка приложений, каждое из которых через адаптер тянуло монолитную кодовую базу. Наблюдаемости не было, а кубовые спеки писали разработчики между фичами: примерно в 70% приложений первый же запрос выедал квоту процессора, и второй пользователь ждал секунду. Серверный рендеринг на Node требует не меньше ядра, поэтому Борис пересчитывал ресурсы в табличке, а собранная проектная команда буквально чудом нагенерила статические заглушки — рендеринг личному кабинету был не нужен вовсе.

Новую архитектуру проектировали заранее: нужность микрофронтендов долго челленджили со стейкхолдерами, а потом, по его памяти, втроём спроектировали единое приложение с роутером и PWA-спецификой, куда команды встраиваются по готовым инструкциям и пайплайнам. Бремя эксплуатации ушло на платформу — продуктовым фронтендерам больше не нужно знать про Kubernetes, — а ограниченный набор кубиков Борис считает удобным для генерации простых микрофронтендов из Figma с помощью AI. Роль CRO добавила к вебу мобильную часть и API, и сложность оказалась менеджерской: такой позиции нет за пределами компании, спросить не у кого, а технически труднее всего было найти общий язык с мобильной разработкой, где под одними терминами понимают разное. Свою позицию Борис называет плавающей: ребрендинг он прошёл инженером, потом сменил маску на менеджерскую, а CRO, который чинит сбой руками, не масштабируется. Инженерам он советует сначала понять, зачем расти, и напоминает, что все всплески его собственного роста наступали после удачных книг.

Выводы

Что стоит унести с собой

  1. 01Мониторинг вырастает в организацию: от переделанных алертов и перехода с логов на метрики — к дежурствам в командах, бюджету ошибок на релизы и вопросу, кто отвечает за надёжность.
  2. 02Shift left работает буквально: инженеры надёжности пишут код платформы и заходят в проекты разработчиками, а не обслуживают чужой чёрный ящик.
  3. 03Платформенный подход разводит доменную сложность и технологическую: платформа забирает рантайм, деплой и мониторинг, а продуктовые команды получают меньше когнитивной нагрузки и фокус на своём домене.
  4. 04Техническому руководителю без ежедневного кода нужен фундамент computer science хотя бы как булшит-фильтр: вайб-кодинг не подскажет, что инженер искренне ошибается, а без базы легко стать голым королём.

Источники