Site Reliability Engineering и роль Individual Contributor

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

Вторая половина работы — архитектура как функция: при 40 с лишним миллионах пользователей любой сбой заметен, а на кону чужие деньги, поэтому базовый уровень надо подтягивать там, где практики слабее. Это управление зрелостью: найти сильные практики, собрать модель зрелости и дать тулинг и контроль — без инструментов люди задолбаются и перестанут. Процессами разработки на всю компанию Александр занимается вместе с Витей Никишиным, гостем одного из прошлых выпусков, и незадолго до записи рассказывал на конференции, зачем и как мерить инженерную эффективность. Отдельный сюжет — налог на масштаб: внутренние платформы снижают когнитивную нагрузку разработчиков, но удачную практику долго не дотянуть до поздних последователей. Разную планку жёсткости подсказывает ведущий: рублёвые платежи требуют хардкора, а лендинг переживёт и кривой монолит. Александр соглашается, что уровень должен варьироваться: гипотезу можно проверять с ослабленными требованиями, но после отсечки по числу увидевших её клиентов планка возвращается.

Надёжность держится на собственной платформе observability: её написали как замену Splunk после его ухода с российского рынка, она поддерживала прежний формат неструктурированных логов, получила свой язык запросов, и только потом команды эволюционно переводили на структурированные. Поверх неё сделали инструмент, где заводят SLA и следят за соблюдением: у сервиса появляется индекс здоровья и посчитанный аптайм, инциденты заводятся автоматически, склеиваются в родительские и дочерние и уходят алертом дежурному, а рядом живёт каталог услуг. Сам Александр не дежурил ни разу, но как технический директор части продуктов стоит в кривой эскалации: звонят ему не чинить, а быть в курсе или координировать инцидент. Зато он курировал секцию найма по troubleshooting: кандидат играет SRE-лида, который уехал на конференцию без ноутбука, а интервьюер — джуна, вышедшего две недели назад и готового нажимать кнопки по телефону. Это настольная ролевая игра, где мастер строит мир и сам отыгрывает кубик: «не повезло, логи пропали».

К надёжности Александр идёт от проектирования: нефункциональные требования звучат как что-то неважное, поэтому их лучше называть атрибутами качества или архитектурными характеристиками. Мнение, что надёжную систему собирают только из надёжных компонентов, опроверг Google: денег на дорогие серверы не было, и поиск, MapReduce и файловую систему GFS строили на коммодити-железе, закладывая избыточность и обработку сбоев. Дальше — стена между разработкой и эксплуатацией: у одних цель катить быстро, у других ничего не менять. В своём подкасте он разбирал с Игорем Курочкиным книгу Accelerate: опросы показали, что скорость не противоречит стабильности, потому что частые релизы едут маленькими инкрементами и быстро откатываются. Отсюда две школы — build it, run it, где команда дежурит сама и опирается на self-service-платформу, и отдельная функция SRE: о подходе Google впервые рассказал на конференции в 2007 году, отправив инженеров автоматизировать эксплуатацию. Есть и то и другое, но у выделенных SRE теряется обратная связь: Александр помнит, как больше десяти лет назад получил root на серверы сайта из топ-50 рунета по нагрузке, и ответственность резко подняла желание понять, что может пойти не так.

Про безопасность Александр говорит осторожно — экспертом себя не считает, — но выделяет два направления. Первое: shift left, когда проверки образов, зависимостей и уязвимостей встроены в пайплайн, а не живут отдельным этапом, и скорость не страдает. Второе: безопасность — такая же архитектурная характеристика, подходить к ней стоит от модели угроз, а риска иногда проще избежать, отдав карточные данные платёжному провайдеру вместе с комиссией и головной болью. Надёжность и безопасность пересекаются: под нагрузкой систему спасают, отключая часть защиты, и атакующему достаточно эту нагрузку создать — в книге Google Building Secure and Reliable Systems предлагают думать о них вместе. В инциденте надёжности злоумышленника нет, как в консенсусе, который изучают на простых сбоях, пока не дойдёшь до византийских; в инциденте безопасности сначала выясняют, как далеко пробрались, и только потом придумывают противодействие. Главная проблема — не знания, а принятие практик: инженеру нужно сперва объяснить, зачем ему это.

Карьерных дорожек компания нарисовала две: для тех, кто хочет в инженерный менеджмент, и для тех, кто хочет расти дальше синьора, — раньше после синьора казалось, что путь только один, в руководители, и Александр это на себе застал. Инженерная ветка — staff, principal и выше — оценивается по матрице SDE, где, по его словам, около пяти осей: импакт, скоуп, лидерство, сложность, развитие. Лычку дают не за выслугу, а под потребность компании: человек был главным за техническую часть сложной системы или внутренней платформы, приложил к промопакету RFC, пул-реквесты и документацию, а лидеры профессии это ревьюят. Пример роста рядом: фронтендер Боря за шесть лет стал лидом, занялся надёжностью веба и личных кабинетов и дорос до роли chief reliability officer, которую выделяют в продуктах рядом с CTO. По книге про staff-инженеров Александр перечисляет четыре архетипа — техлид, солвер, архитектор и правая рука CTO — и напоминает, что давить властью плохо: лучше довести команду до решения вопросами. Финальная мораль: учиться надо всю жизнь.