Привет, Хабр!
Я двадцать лет работал в руководстве ИТ в банках и страховых компаниях. За это время через меня прошли десятки проектов заказной разработки. Некоторые из них я вспоминаю с гордостью. Некоторые — с содроганием.
Protobuf как контракт: spec‑first валидация с protoc‑gen‑validate
Первая статья из мини‑серии про валидацию на базе Protobuf. В этой части — концепция spec‑first и protoc‑gen‑validate. В следующей поговорим про protovalidate и то, почему его вообще имеет смысл рассматривать как «следующее поколение» (или же как очередная эволюция в обратную сторону?)
Также, чтобы не пропустить следующую часть, очень рекомендую подписаться на мой телеграмм канал :-)
Serverless — это не отсутствие серверов. Это состояние, когда вы перестаете о них думать. Вы не патчите ядра Linux, не настраиваете Nginx и не мониторите свободное место на дисках. Вы пишете функцию, загружаете код в облако, и платформа сама решает, где и как это запустить.
Звучит идеально. Но на практике Serverless — это сделка. Вы отдаете контроль над инфраструктурой в обмен на удобство. И часто цена этой свободы — новые, совершенно неочевидные архитектурные проблемы.
Вы проектируете масштабируемую систему на System Design интервью в BigTech. Всё идёт хорошо, пока вам не задают неожиданный вопрос. От ответа на который зависит ваше прохождение.
Разберём 10 популярных вопросов, ответы со схемами и примерами в ультимативном чеклисте. И закроем для себя этот важный аспект интервью.
Бизнес Додо активно масштабируется. Уже сейчас Dodo IS круглосуточно работает в двух облаках, более чем в 25 странах и практически во всех часовых поясах. В таких условиях важно знать, что вся система действительно работает хорошо, а не просто «не горит» прямо сейчас.
Чтобы это знание обрести, мы привезли в нашу инженерную савану SLO'на — неповоротливое, но умное существо. Он наводит порядок в хаосе метрик и алёртов, и отличает реальную проблему от мнимой. А ещё он требует внимания, точных чисел и ясных целей. Поначалу мы его боялись, но позже поняли: если его приручить, он защитит нас от ночных звонков и научит бизнес говорить на языке надёжности.
Сегодня мы расскажем, как приручили своего SLO'на и прошли путь от первых экспериментов с нагрузочным тестированием до построения культуры надёжности.
Иногда в процессе разработки внезапно выясняется, что привычные подходы к тестированию перестают работать: автотесты громоздкие, данные — одноразовые и неудобные, а тестовые фреймворки уже не спасают. В такой момент команда или буксует, или придумывает что-то новое.
Привет, Хабр! Меня зовут Владимир, я SDET-специалист в компании SimbirSoft. В этой статье хочу рассказать, как мы решали проблемы тестирования не традиционным написанием автотестов, а созданием собственных REST-сервисов: сервиса генерации данных и сервиса, ассистирующего тестам.
Мне всегда была интересна тема антихрупкости и работы Нассима Талеба — особенно в контексте их применения в IT.
Книга «Антихрупкость в IT» попала в мой список рекомендаций больше года назад, после одной конференций в Казахстане.
Книга показалась мне интересно, по этому ниже обзор основных тем, и в каком случае вам стоит ее прочесть.
А так же ответим на вопросы: как продать микросервисы бизнесу? Почему у книги такая обложка? А есть ли что-то от антихрупкости Талеба в книги с таким название?
Это схема, которая описывает типы объектов в вашей системе и возможные отношения между пользователями и этими объектами (ролями, функциями защиты и привилегиями).
Классическая ситуация:
«Я данные отправил!»
«А я не получил!»
«А они зависли где-то, потому что формат не тот!»
Пример из практики: комплексный проект по рефакторингу системы управления доступами. Интеграция приложения по управлению доступами на основе ролей и привилегий (это наша Новая система) с другими информационными системами (ИС) в контуре предприятия (например, управление учетными записями, авторизация пользователей и прочие).
В данной статье я хочу поделиться опытом и рассказать о том, как системным аналитикам улучшить Sequence-диаграммы (диаграммы последовательностей) с помощью лучших практик.
Я покажу, как некоторые подходы из мира программирования (те самые best practices и идеи из Clean Code) помогают рисовать sequence-диаграммы чище и понятнее.
Приложение тормозит. Это жалоба номер один, которую слышат разработчики и архитекторы. Но "тормозит" — это не диагноз. Это симптом. За этим простым словом может скрываться что угодно: от плохо написанного SQL-запроса до "шумного соседа" в облаке или неправильной настройки сборщика мусора.
Оптимизация производительности — это не магия и не набор случайных твиков. Это инженерная дисциплина. Это бесконечный поиск узких мест, компромиссов и баланса между скоростью, стоимостью и сложностью поддержки. Нельзя оптимизировать то, что нельзя измерить. Поэтому, прежде чем менять хоть строчку кода, нужно вооружиться инструментами профилирования и мониторинга.
История о том, как наша команда смогла ускорить релизы, снизить затраты и построить масштабируемую архитектуру без хаоса. В статье вы узнаете, подходят ли вам микрофронтенды.
Привет! Меня зовут Фёдор Засечкин. С 2023 года я руковожу группой разработки операционной платформы в Купере. Наша команда отвечает за стабильность и развитие сервисов, которые обеспечивают сборку и доставку заказов, а также найм и выход партнёров в смены.
Последние два года наша ключевая задача — микросервисная трансформация. Мы постепенно распиливаем монолит, перераспределяя нагрузку по сервисам. На сегодня более 1 000 RPS HTTP-трафика уже ушло с монолита; до полного завершения осталось около 30 RPS и часть межсервисных интеграций.
Я решил написать серию статей о том, как мы проходили этот путь: что сработало, какие ошибки допустили и какие решения реально помогли. Этот текст — первый из серии.
Микросервисы легко разрастаются до зоопарка эндпоинтов, где каждый сервис живёт по своим правилам, а клиенту приходится знать обо всех. В статье разберем, как API Gateway превращает этот хаос в единую точку входа: берёт на себя маршрутизацию, аутентификацию, агрегацию запросов и наблюдаемость. На простом примере с Spring Cloud Gateway рассмотрим, как собрать такой слой поверх Java-сервисов и упростить жизнь и разработчикам, и внешним потребителям API.
Transactional Outbox часто подаётся как простой рецепт: записали событие в отдельную таблицу, фоновый воркер разберётся. В реальности именно этот «временный костыль» неожиданно превращается во вторую очередь со своей конкуренцией за блокировки, дубликатами, нарушенным порядком и тихо растущими таблицами.
В статье разберемся, что именно начинает ломаться в outbox-паттерне под нагрузкой, как выбирать и блокировать события в разных СУБД, почему ретранслятор стоит отделить от API и какие гарантии доставки на самом деле получаются. А ещё — почему консюмеры должны быть идемпотентными, как следить за внутренней очередью в базе и не узнавать о проблемах уже после инцидента.
Привет, Хабр!
Calico, Kolla, Reconciler — это названия технологических сервисов или имена героев аниме? Проверьте свою интуицию и знания в нашем новом тесте, который мы разработали в Хабре вместе с Рунити!
Мы собрали различные популярные и двусмысленные термины, чтобы выяснить, насколько хорошо вы чувствуете границу между IT-технологиями и поп-культурой. Готовы к вызову? Вперед!
Привет! Меня зовут Гильметдинов Ильнур, ведущий эксперт Дирекции роботизации банка Уралсиб.
Сегодня хочу рассказать о вызове, с которым мы столкнулись в самом начале пути масштабирования RPA (Robotic Process Automation) внутри банка: как научить коллег, не имеющих опыта в программировании, не просто пользоваться роботами — а создавать их самостоятельно?
Это звучит амбициозно — и даже немного наивно. Но именно с этого начался наш путь к созданию внутреннего курса по RPA на платформе PIX.
Всем привет! Меня зовут Вадим, и я QA-инженер в IT-компании Intelsy. В современной разработке программного обеспечения всё чаще встречаются распределённые системы и микросервисная архитектура. Один из ключевых инструментов, обеспечивающих надёжное и масштабируемое взаимодействие между сервисами, — это Apache Kafka — распределённая платформа потоковой обработки и передачи сообщений. Для специалиста по обеспечению качества понимание принципов работы Kafka критически важно.
Почему exactly-once — это миф? Как защититься от дубликатов в распределённых системах?
Продолжаем работу с Kafka на практике и рассматриваем более интересные темы.
Простым языком и с примерами кода о непростых концепциях и паттернах.
Привет, Хабр. Я Витя Михайлов, Backend Lead в Garage Eight, и больше 6 лет у меня RabbitMQ в продакшене. За это время мы с командой узнали много интересных вещей. О них я рассказывал этим летом, выступая на Saint Highload++ с докладом про рецепт правильного приготовления RabbitMQ. Там же я поделился 8 практическими кейсами. Сегодня в статье разберу один из них — Publish without Confirmation. Расскажу, почему из коробки Publish не имеет гарантий доставки в RabbitMQ, и что с этим делать.
Большие старые проекты обычно живут по своим законам.
Ты уже не спрашиваешь, почему именно так, — просто делаешь свою часть работы и стараешься ничего не сломать.
Наш проект был именно таким: монорепозиторий, десятки микросервисов, сотни зависимостей и общие библиотеки для всего подряд. В кодовой базе было около 220 Python-пакетов и примерно 70 Docker-контейнеров, которые собирались из них. Всё хранилось в одном репозитории, а полный пайплайн для pull request’ов проходил в Azure TFS до 4-х часов.
Именно это пришлось оптимизировать...
