Привет, Хабр! Меня зовут Роман Стрекаловский, я корпоративный архитектор в «Столото». Мой первый рабочий день начался с экскурсии в лотерейный центр — место, где воплощаются мечты миллионов. Блестящие шары, гул вращающихся барабанов, атмосфера напряжённого ожидания — всё это производило сильное впечатление. Я сразу почувствовал: здесь живёт энергия, которая двигает бизнес.

Но когда я заглянул «под капот» — в ИТ‑ландшафт компании, — меня ждало ещё более интересное открытие. Передо мной оказалась сложная, многолетняя экосистема: более 500 систем, выросших вместе с бизнесом, монолиты, сплетённые самописными интеграциями, и процессы, в которых ключевую роль играл опыт инженеров. Запуск нового решения мог занимать до года, а создание новой игры — требовать ручного внесения данных в десяток разных систем.

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

И я хочу поделиться этой историей с вами.

Меня зовут Илья Куликов, я руковожу разработкой веб-терминалов в компании «Столото». Сегодня хочу рассказать, как мы превратили ручные релизы и вечные конфликты в почти автономный CI/CD. За почти 10 лет в компании я прошёл путь от бэкенд-разработчика до руководителя направления, в «Столото» же за это время родился и вырос целый продукт — веб-терминал для агентов розничной сети. Изначально у нас был парк дорогих аппаратных терминалов, установленных у агентов. Но как расширить сеть и снизить входной порог? Возникла идея: а что, если сделать аналогичное приложение в браузере? Тогда любой желающий мог бы стать агентом — достаточно старого ноутбука и договора с нами. Так появился полноценный веб-аналог аппаратного терминала со всеми необходимыми функциями для продажи лотерей.

Но вместе с ростом продукта росла и боль: релизы занимали часы, всё постоянно ломалось на проде, а после каждого деплоя команда судорожно грепала логи в поисках причины падения. Мы поняли: без серьёзной перестройки процессов дальше — только хуже. И тогда решили кардинально пересмотреть наш подход к CI/CD. Отказались от классического GitFlow в пользу trunk-based development, полностью перестроили пайплайны в GitLab и внедрили автоматизацию на всех этапах — от сборки и тестирования до деплоя и мониторинга.

В этой статье я делюсь реальным опытом:

- как мы ушли от ручных релизов к автоматическому деплою в прод;

- какие практики и инструменты позволили нам перестать бояться каждого коммита;

- как повысить качество кода и ускорить вывод фич на рынок без ущерба для стабильности.

Этот материал будет особенно полезен техлидам, инженерам DevOps, разработчикам и командам, которые всё ещё живут в мире ручных деплоев, боятся нажимать «мердж» в пятницу вечером. Если вы задумываетесь, как перейти от хаоса к предсказуемости в релизах — вы по адресу.

А как мы этого добились — читайте под катом!

Привет, Хабр! Меня зовут Константин Бессонов, и я — ведущий инженер-тестировщик в компании «Столото», где уже шесть лет участвую в тестировании и управлении процессами.

Эта статья — моя история о том, как я пришёл в тестирование без опыта, как готовился к собеседованиям, какие ошибки совершал, а главное — как за несколько лет вырос от новичка до руководителя группы. В процессе пути сталкивался с волнением перед первым релизом, автоматизировал процессы через Postman, осваивал SQL, Linux и понял, что в IT важны не только навыки, но и желание учиться.

Спойлер: если вы думаете, что в IT можно попасть только с идеальным резюме или опытом программирования — вы зашли не в ту статью.

В этой статье расскажу, как выбрать правильную компанию, найти наставников, развивать soft skills, почему важно записывать всё новое.

О паттернах отказоустойчивой архитектуры написано уже немало. Но когда дело доходит до реальных кейсов, особенно в специфических отраслях вроде лотерейной — информации почти нет. А ведь здесь, как и в любой высоконагруженной системе, отказоустойчивость — не просто галочка в ТЗ, а вопрос пользовательского доверия и бизнес-репутации. 

В этой статье расскажем, как мы в «Столото» подошли к проектированию Lottery Payment System. Это полностью вымышленный сервис для выплат выигрышей, построенный на опыте реальных вызовов и ограничений для того, чтобы на его примере описать, как работают ключевые паттерны отказоустойчивой архитектуры: Retry, Idempotency Key, Deadlines, Rate Limit и Circuit Breaker. Также покажем, как они применяются в контексте распределённой системы, которая должна стабильно работать, даже когда вокруг всё пошло не по плану. 

В нашем вымышленном сценарии мы представили, что компания прошла через архитектурную трансформацию и решила переосмыслить доменные области. Слишком громоздкий и хрупкий процессинг тормозил развитие. В какой-то момент он стал похож на башню из кубиков, которую боишься задеть. Поэтому мы выбрали путь здорового прагматизма — выплаты вынесли в отдельный сервис, чтобы дать этому направлению и стабильность, и простор для развития. В зоне его ответственности — всё, что связано с переводами пользователям, которые хотят получать выигрыши по лотерейным билетам и исполнять свои мечты.

Будет немного архитектуры, чуть-чуть лирики и много практики. Это не скучный туториал — это живая история гипотетического продукта, в котором отказоустойчивость стала краеугольным камнем. Если вы работаете с высоконагруженными системами, и вам важно, чтобы ваши системы не падали — добро пожаловать.

Когда ключевой вендор ушёл с рынка, а готовые решения перестали справляться, у нас было два пути: искать костыли или написать свою систему. Мы выбрали второе — и за 2 года создали ACRM, которая не просто заменяет SAS, но и даёт новые возможности. Рассказываю, как мы проектировали систему с нуля, на какие грабли наступили и почему теперь не зависим от вендоров.

Меня зовут Иван Курбатов, и я руковожу направлением систем взаимодействия с клиентами в компании «Столото». Наша команда отвечает за разработку и поддержку CRM-систем, которые помогают нам общаться с миллионами клиентов через СМС, email-рассылки и push-уведомления.

Если вы ранее не сталкивались с деятельностью бренда «Столото», отмечу коротко, что это крупнейший распространитель всероссийских государственных лотерей. Организацией таких лотерей занимаются сразу два федеральных ведомства: Минфин и Минспорт, что накладывает на нас серьёзные обязательства. Наши решения должны быть максимально надёжными и бесперебойными, ведь мы отвечаем за доверие пользователей по всей стране.

Хотите узнать, как строится CRM-система с нуля, как она работает в масштабе миллиона клиентов и почему иногда лучше писать своё, чем адаптировать чужое — добро пожаловать под кат!