SRE: отдать дежурства разработчикам

Салих представляется так: около восемнадцати лет в IT, четвёртый год в компании, сейчас — главный инженер управления, которое отвечает за открытие новых продуктов. Компьютер у него, по его словам, появился примерно в 1996 году, что для Казани было рано; в четырнадцать лет знакомый системный администратор увлёк его не программированием, а администрированием, и первой системой помимо Windows стала FreeBSD, которую он постоянно ломал. Когда в город пришёл скоростной интернет, компьютерные клубы строили общую игровую сеть, и он напросился туда работать: доступ к серверам выдали сразу, продакшн был боевым, а после одной неосторожной команды пришлось ехать в дата-центр по срочно оформленному пропуску. Учился он на авиаконструктора, многих предметов из computer science в программе не было, зато код считал за него интегралы, а некоторые преподаватели вместо оформленного отчёта охотно брали исходники.

Первую оплачиваемую работу он нашёл на втором курсе по статье пятилетней давности, в конце которой искали PHP-программиста в Казани; на месте сказали, что нужны верстальщики, и он согласился. В той компании он провёл больше восьми лет: верстальщик, PHP-разработчик, мобильный разработчик — в 2012-м поднимал macOS в VMware, потому что ни одного Mac в компании не было, — потом инфраструктура, руководитель группы и, наконец, руководитель разработки с командой до шестнадцати человек, то есть фактически CTO небольшой компании. На уровне группы он отвечал за тактику на три-четыре месяца вперёд, на уровне отдела — за стратегию, найм и метрики доставки ценности. В 2020-м ковид ударил по рекламному бизнесу компании, Салих вышел на рынок через знакомых и полтора года проработал в стартапе — соцсети про медицину, где быстро выстроил доставку ценности и заскучал.

Ещё работая в стартапе, он прошёл курс по SRE, который вёл Дима Масленников, — курс шёл в компании, куда его после выпуска и позвали, — и понял, что роль ему близка: есть инфраструктура, есть код, а влияние команды держится не на прямой власти, а на коммуникации и умении убедить чужих разработчиков сделать приложение надёжнее. Найм занял около шести месяцев и, по его счёту, пять секций: четыре технические — базовое программирование, алгоритмы, системный дизайн и траблшутинг — и фит-интервью; Александр вспоминает, что системный дизайн проходили плохо и позже секцию убрали, а у Салиха был один из лучших результатов, который тот объясняет опытом стартапа. В большую компанию он сознательно пошёл старшим инженером: про финтех он не знал ничего и хотел разобраться снизу вверх. До ведущего инженера он вырос быстро, разбирая отложенные проблемы — перекосы трафика и производительность баз, которые страдали не от того, что базы плохие, а от того, как их использовали.

Команда, частью которой он стал, — семь инженеров плюс руководитель, который сам вырос из инженеров и до сих пор разбирает инциденты; дежурят они круглосуточно и отвечают за доступность всего управления. Управление origination — это больше шестисот человек и шесть отделов: первые формы подачи заявок на любой продукт и вся дальнейшая работа с заявкой, включая создание и проверку клиентов и расчёт рисков. Салих специально подбил цифры: около 280 услуг, то есть примерно по сорок на инженера, больше двухсот деплоев в Kubernetes против трёхсот пятидесяти полгода назад, 210 баз PostgreSQL, около трёхсот топиков, а сверх того парк виртуальных машин и bare metal, который он в слайд не вписал. Часть систем в Kubernetes не переедет никогда — например серверы с четырьмя терабайтами оперативной памяти, про которые Александр угадывает антифрод. Разработчиков в управлении 232, то есть примерно 33 на одного SRE, или 3% при рекомендации меньше 10% из книги Google.

Когда сервисов стало больше трёхсот, команда перестала успевать: она превратилась в сервисную, которая только отвечает на вопросы и чинит прод, инженеры выгорали, а на собственные продукты и автоматизацию времени не оставалось. Два года назад решение договорились и «продали»: дневные дежурства ушли в команды разработки. Эффект Салих описывает двумя частями. Во-первых, SRE вернулись к тому, чем должны заниматься, — надёжности и доступности, DR-планам и учениям, где придумать, как сломать сервис и не оставить следов, оказывается отдельной наукой, и наблюдаемости за двумя-тремя сотнями сервисов. Во-вторых, у разработчиков появилась осознанность: они видят, как их изменения ломают прод, умеют мониторить свои приложения и не боятся туда лезть, сами выключают ненужные алерты и чинят метрики, которые раньше приходилось продавать их менеджерам как задачи техдолга. Выигрывают и Time to Market, и время восстановления: теперь при пробитии SLO команда сама пишет, что уже откатывает релиз. Александр называет это замкнутым циклом обратной связи, а Салих добавляет: без него люди просто перестают чувствовать боль.

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