Участие в нескольких проектах снижает результаты работы — так ли это?
На одной из конференций прозвучал тезис: заказчику необходимо держать аутсорс-команду full-time. Потому что, работая на нескольких проектах одновременно, разработчики меньше погружаются в контекст каждой задачи, что в итоге сказывается на качестве кода и проекта в целом.
Была высказана и противоположная точка зрения, но хочется услышать мнение именно лидов и разработчиков, основанное на опыте.
Почему спрашиваю?
Люди, не связанные с разработкой, часто видят процессы иначе. Любой штатный сотрудник, например, в маркетинге или продукте, обычно ведёт несколько проектов и в день решает десятки разноплановых задач: от подготовки рекламной кампании и согласования креативов до контроля бюджета и аналитики. И сотрудники успешно справляются с этой нагрузкой, переключаясь между задачами.
Вопрос к сообществу:
Правда ли, что разработчик, участвующий в нескольких проектах part-time, будет менее эффективен, допустит больше багов и в целом ухудшит качество релизов? Или это миф, и всё зависит от процессов, коммуникации и личной организованности?
Хочу написать о финте, который позволит вам сохранить нервы и сэкономить время. Правда некоторые (многие, почти все) впадают в ступор от него. Поэтому тут использована КДПВ с поста. Я наверно чувак слева.
А именно добавление первым условием if единицы:
if (1
&& $cond1
&& $cond2
&& $cond3
)
Использование финта дает нам возможность: 1. Быстро выключать фичу заменой 1 на 0:
if (0
&& $cond1
&& $cond2
&& $cond3
)
2. Быстро выключать любое условие в PhpStorm через горячие клавиши:
if (1
// && $cond1
&& $cond2
&& $cond3
)
Без этого финта мы не можем быстро выключить первое условие. Нам приходится делать примерно такую фигню, манипулируя с двумя строками и целясь в &&:
if (
/*$cond1
&&*/ $cond2
&& $cond3
)
Или такую:
if (
$cond2
&& $cond3
)
3. Быстро добавлять новое первое условие:
if (1
&& $cond2
&& $cond3
)
легко превращается в:
if (1
&& $cond1 // в изменениях одна строка
&& $cond2
&& $cond3
)
4. Быстро дублировать любое условие.
5. Быстро менять порядок условий.
6. Также у нас будет чистый diff git-а при удалении/добавление первого условия. Тут должен быть рисунок удаления с финтом и без, рисунок добавления с финтом и без. Также при конфликте у нас будет более простое его решение, если нужно просто добавить оба условия.
Данный финт сродни правилу хорошего тона добавлять после последнего элемента массива запятую. Это дает нам возможность при добавлении работать только с одной строкой. Добавлять горячими клавишами дублирования строк, в diff опять же будет только 1 строка, а также при конфликте слияний просто применяем обе строки и не нужно проставлять запятые, а то код упадет.
CWE-295. А Вы точно выясняете все способы отключения SSL-проверок в коде?
CWE-295 — неправильная проверка сертификата, включая игнорирование ошибок цепочки доверия. Близкие CWE: CWE-296 (Improper Certificate Validation in TLS) и CWE-297 (Improper Hostname Verification).
Делюсь с Вами очередной версией 2-х мегарегулярок для выявления всех когда-либо встретившихся мне способов отключения проверки цепочки сертификатов либо удаленного хоста.
Давайте проверим насколько хорошо Вы контролируете внешние взаимодействия Вашего кода со сторонними приложениями при помощи SAST/линтеров.
Не важно о чем код: запуск удаленной команды на Power Shell, запуск cURL, запуск Node.js и т.д. Если в Вашем коде имеется обращение к стороннему ресурсу, вполне вероятно, хотя бы какая-нибудь строка вызова составлена небезопасно, коробочные правила используемых Вами SAST не могут покрыть все кейсы, особенно, в неподдерживаемом файле.
Сами регулярные выражения для проверки Вашего кода:
Периодически натыкаюсь в YouTube на видео с названиями типа «Стоит ли идти в IT в 2025 году».
И видео / статьи с подобным содержанием меня всегда немного коробят...
По поводу «входа в IT» и в другие сложные специальности у меня есть совершенно чёткое и однозначеное мнение — если вы хотите освоить эти специальности ТОЛЬКО из конъюнктурных соображений: «это модно и там много платят» — то лучше не надо.
Пожалуйста, не идите в IT — вам там будут не рады, я во всяком случае точно буду не рад. «You are not welcome here!»
Идти в сложные профессии можно и нужно только в одном случае — если вам это ДЕЙСТВИТЕЛЬНО ИНТЕРЕСНО.
Если вы этим горите, не можете без этого жить. Если идёте «по зову сердца». Во всех остальных случаях — лучше найдите какой-то другой способ «срубить бабла».
А если же вам это действительно интересно, то вы в принципе не задаётесь и никогда не будете задаваться вопросом «стоит ли».
Вы пойдёте — независимо от текущего состояния рынка труда, от зарплат, от коньюнктуры, от того «заменит ли всех ИИ».
Вам всё это НЕ ВАЖНО, т.к. все эти факторы — преходящие и уходящие и идёте вы не за этим.
А если вам уже за 35, вы никогда не интересовались программированием и вдруг услышали рекламу «пройди наш 3-х-месячный курс и зарабатывай от 200k в месяц» — не верьте. Лучше не мучить ни себя, ни индустрию, ни будущих коллег...
Привет, это снова Егор Гаврилов. Сегодня я расскажу, что было сделано за последний месяц в рамках очередного своего пет-проекта - StingrayTV Alice.
Предыдущая статья была вынесена в черновики мной, однако если вкратце, StingrayTV Alice - это попытка интегрировать ресиверы Триколора на базе платформы StingrayTV с сервисом "Дом с Алисой". Это позволяет управлять ресивером через Алису, и интегрировать его в общий умный дом. Проект пережил несколько доработок, и сейчас там используется Keycloak, Spring Boot 4, и другие самые современные технологии. Также было сделано множество улучшений кодовой базы, что позволило избавиться от лишнего кода, и улучшить стабильность и производительность данного гейтвея.
Keycloak: теперь нормальная аутентификация - это реальность
Изначально планировалась аутентификация по физическому присутствию пользователя за консолью сервера. Однако реализовать это достаточно было нетривиально, и поэтому принято решение использовать уже готовый сервер аутентификации - а именно Keycloak. Оно даёт более гибкий контроль за процессом аутентификации, а также является проверенным и готовым решением для реализации OAuth2.
Куча рефакторинга
Проект подвергся обширному рефакторингу - как те, которые я сделал на всех своих пет-проектах (в частности, перевод проектов на Spring Boot 4, а также улучшения по части CI/CD в проектах - теперь там реализован полноценный пайплайн, который обеспечивает высокий уровень консистентности всего цикла), так и постепенная работа над чисткой кода (при помощи самых разных линтинг-инструментов - начиная от встроенных инструментов OpenIDE, и заканчивая SonarQube for IDE и Explyt Spring). Это позволило обеспечить гораздо большую чистоту и сопровождаемость кода.
В частности:
Избавились от кривого механизма аутентификации - теперь там самый что ни на есть цивильный Keycloak.
Убрали использование Preferences API для хранения нужных ключей для старого механизма аутентификации - Keycloak куда лучше во всём.
Мелкие улучшения в кодовой базе - меньше ужаса и треша, больше чистого кода.
Итоги
Проект пережил многое - но теперь оно всё ближе к тому, чтобы можно было использовать у себя дома, безопасно и спокойно.
Привет, Хабр! Тем, кому регулярно приходится заглядывать в etcd — будь то QA, поддержка или разработчики — хорошо знакома ситуация, когда нужно разобраться с неожиданным состоянием сервиса, проверить конфиги или найти застрявший лок. И каждый раз всё сводится к одному: копировать ключ, запускать etcdctl get, читать многострочный JSON в терминале, ошибаться в пути… и в какой-то момент понимаешь, что это однообразие выматывает больше, чем сама проблема.
Поэтому наш коллега из Хайстекс сделал небольшой TUI-инструмент, который заметно упрощает работу с etcd и делает её куда дружелюбнее для тех, кто каждый день копается в окружениях. Он снимает рутину etcdctl, даёт привычную “каталожную” навигацию, подсвечивает скрытые _-ключи, позволяет комфортно открывать большие конфиги и помогает разбираться с локами, которые любят появляться в самых неожиданных местах.
Если вы в QA, поддержке или просто часто работаете с etcd, этот инструмент легко сэкономит вам время и нервы.
📊 Multi‑LLM Orchestrator v0.6.0: метрики провайдеров и умный роутинг
На этой неделе на Хабре вышла статья про Multi-LLM Orchestrator — библиотеку для работы с российскими LLM через единый интерфейс. Сегодня релиз v0.6.0 добавляет метрики провайдеров и стратегию роутинга на основе health status.
Автоматический сбор метрик
Роутер отслеживает каждый запрос и собирает статистику по провайдерам. Latency, success rate, количество ошибок — всё фиксируется без дополнительной настройки.
from orchestrator import Router
from orchestrator.providers import GigaChatProvider, ProviderConfig
router = Router(strategy="best-available")
router.add_provider(GigaChatProvider(
ProviderConfig(name="gigachat", api_key="...", model="GigaChat")
))
# После нескольких запросов
metrics = router.get_metrics()
print(f"{metrics['gigachat'].avg_latency_ms:.0f}ms")
print(f"Health: {metrics['gigachat'].health_status}")
Система отслеживает среднюю задержку и rolling average по последним 100 запросам. Если провайдер начинает деградировать, это видно сразу.
Health status провайдеров
Роутер классифицирует каждого провайдера автоматически:
healthy — error rate меньше 30%, стабильная latency
degraded — error rate 30-60% или задержки растут
unhealthy — error rate выше 60%
Классификация происходит на лету, без пороговых значений в конфигах.
Стратегия best-available
Новая стратегия роутинга выбирает провайдера на основе метрик. Приоритет отдаётся healthy-провайдерам, среди них — с минимальной задержкой.
router = Router(strategy="best-available")
router.add_provider(gigachat_provider)
router.add_provider(yandexgpt_provider)
# Роутер выбирает самого здорового и быстрого
response = await router.route("Вопрос")
Если GigaChat деградирует до 3 секунд, а YandexGPT стабильно отвечает за 500ms — роутер переключится на YandexGPT.
Тестирование на боевых API
Запущена серия тестов с реальными запросами к GigaChat и YandexGPT. Результаты подтверждают стабильность системы метрик.
Метрики провайдеров: GigaChat vs YandexGPT (fallback-тест)
Первый тест показал базовую работу: GigaChat отвечает за ~1.7 секунды со 100% success rate. Второй тест проверил fallback при ошибке авторизации — роутер переключился на YandexGPT без потери запроса. Третий тест подтвердил корректность метрик при streaming-запросах.
YandexGPT показал стабильные 500-700ms на серии из шести запросов. GigaChat медленнее (~1.7s), но это ожидаемо для более тяжёлой модели. Success rate обоих провайдеров — 100%.
Structured logging
Каждый запрос логируется в структурированном формате с полями provider, model, latency_ms, streaming, success. Интеграция с Prometheus или Grafana требует только парсинг JSON
# При успехе
logger.info("llm_request_completed", extra={
"provider": "gigachat",
"latency_ms": 1723
})
# При ошибке
logger.warning("llm_request_failed", extra={
"provider": "yandexgpt",
"error_type": "RateLimitError"
})
В 2025 году мы запустили 25+ курсов и тарифов для ИТ-специалистов. В этой подборке собрали новые программы по разработке и архитектуре.
«Rust для действующих разработчиков» — 4 месяца После курса сможете использовать Rust как основной стек и создавать отказоустойчивые системы с высоким уровнем безопасности.
«SRE — обеспечение надёжности систем» — 4 месяца Освоите практики и подходы SRE, наладите мониторинг инфраструктуры и приложений, чтобы повышать стабильность и улучшать бизнес-процессы.
«DevSecOps: безопасная разработка и эксплуатация» — 3 месяца Разберём, как выявлять и устранять уязвимости на ранних этапах и снижать риски на всём жизненном цикле приложения — от планирования до эксплуатации.
«MLOps для разработки и мониторинга» — 5 месяцев Освоите принципы MLOps, чтобы ускорять и безопасно выводить ML-модели в продакшн, настраивать стабильную инфраструктуру и улучшать взаимодействие команд.
«Микросервисная архитектура» — 3 месяца Научитесь проектировать и реализовывать масштабируемые и отказоустойчивые микросервисные системы. Разберёте паттерны SAGA и Transactional Outbox, подход DDD и другие инструменты.
«Мидл разработчик C++» — 4,5 месяца Прокачаете владение современным C++: лучшие практики и идиомы языка, работа с диапазонами, библиотечными возможностями, асинхронностью и многопоточностью.
«Продвинутая разработка на C# и .NET» — 5 месяцев Научитесь писать безопасный высокопроизводительный код, разбирать сложные продакшн-задачи, внедрять observability (логи, метрики, трейсы) и использовать современные возможности .NET.
Проверяем osu! и рассказываем про фишки статических анализаторов
Про существование инструментов статического анализа известно многим, но почему их часто используют и в чём конкретно заключается практическая польза? В этот раз мы предлагаем рассмотреть несколько основных особенностей этого инструмента на примере анализа исходного кода игры osu!
Первая особенность: экономит время
Одной из особенностей статических анализаторов является возможность сэкономить время на код-ревью за счёт схожего подхода (просмотра исходников), только за вас всё делает инструмент :)
Предлагаю начать с небольшой разминки: сможете ли вы самостоятельно найти ошибку?
public partial class TopScoreStatisticsSection
: CompositeDrawable
{
public ScoreInfo Score
{
....
if (score == null && value == null)
return;
if (score?.Equals(value) == true)
return;
score = value;
accuracyColumn.Text = value.DisplayAccuracy;
maxComboColumn.Text = value.MaxCombo
.ToLocalisableString(@"0\x");
ppColumn.Alpha = value.BeatmapInfo!
.Status
.GrantsPerformancePoints() ? 1 : 0;
}
}
Если нужна подсказка или хотите убедиться в своём варианте, можно посмотреть на предупреждение PVS-Studio:
V3125 [SEC-NULL] The 'value' object was used after it was verified against null. Check lines: 128, 120. TopScoreStatisticsSection.cs 128
Нашли? Ну я в вас и не сомневался :)
Для протокола давайте всё же разберём, что произошло. Выглядит как логическая ошибка, а их не так просто заметить, потому что не все захотят высматривать все возможные сценарии. В нашем же случае один из них сразу может вызвать проблемы.
В начале есть две проверки.
Первая проверка:
if (score == null && value == null)
return;
Вторая проверка:
if (score?.Equals(value) == true)
return;
Скорее всего, они предназначались для обработки двух переменных по разным сценариям (если score = null, если value = null, если они равны и т. д.). Но вот если комбинация будет score = "NotNull" и value = null, то первая и вторая проверки отработают без выхода из метода, и мы пойдём дальше по коду, где непременно наткнёмся на разыменовывание свежеполученного null
Хотите узнать еще? Если вас заинтересовало какие еще есть особенности статических анализаторов и что еще мы смогли найти в osu! То предлагаю прочитать полную версию статьи.
Со временем у каждого разработчика появляется свой набор маленьких правил, которые работают лучше любых инструкций. Матвей из команды разработки сервисов на базе SMP поделился пятью привычками, которые помогают ему держать код аккуратным и читаемым.
1. Давать осмысленные имена сразу же
Хорошие названия переменных, функций и классов экономят время всей команде: код проще читать, легче понимать и поддерживать. А еще чем меньше вопросов «что делает эта функция?» или «что содержит переменная?», тем лучше.
2. Декомпозировать код и избегать вложенности
if внутри if или for внутри for путают: каждое разветвление создает еще одну ветку, которую приходится держать в голове. Лучше разбить логику на небольшие части — код становится прозрачнее и надежнее.
как не надо:
функция заказать_пиццу(адрес):
если адрес_валиден(адрес):
если у_ресторана_ингредиенты():
если клиент_может_платить():
печать "Пицца заказана!"
иначе:
печать "Недостаточно денег"
иначе:
печать "Нет ингредиентов"
иначе:
печать "Адрес некорректный"
как надо:
функция заказать_пиццу(адрес):
если не адрес_валиден(адрес):
печать "Адрес некорректный"
вернуть
если не у_ресторана_ингредиенты():
печать "Нет ингредиентов"
вернуть
если не клиент_может_платить():
печать "Недостаточно денег"
вернуть
печать "Пицца заказана!"
3. Регулярно делать рефакторинг
Подходы и стандарты меняются, команда учится новому и растет, а код устаревает. Регулярный рефакторинг помогает поддерживать код актуальным и облегчает жизнь новым разработчикам, которые, возможно, уже пробовали новые подходы в работе.
4. Настроить линтер и форматер
Линтер — статический анализатор кода, который следит за определенным стилем написания кода. Так как у каждого из нас свой подход, нам нужен «инструмент-судья», который беспристрастно оценит оформление кода. Форматер помогает автоматически исправить код и привести его к единому виду.
5. Комментировать только неочевидную бизнес-логику
Комментарии полезны, если они объясняют то, что нельзя понять из кода. Например, когда понимаем, что участок кода содержит особенность бизнес-логики, которая еще не ясна новому сотруднику. Но важно помнить, что избыток пояснений превращает понятный код в мешанину из кода и комментариев. Принцип простой: объясняем редкие, действительно сложные места и не трогаем остальное.
Добавлять в рефакторинг улучшения Строго отделяйте рефакторинг т.е. преобразование кода из одной формы в другую с полным сохранением поведения от любых даже самых незначительных улучшений, оптимизаций, украшательства и тд и тп
Делать один огромный коммит Делайте много коммитов, каждый на свой шаг рефакторинга. Рефакторинг это как ходьба по заминированному лабиринту, нужно обязательно записывать все ходы и иногда отступать на шаг или N шагов назад и искать другой путь.
Рефакторить без промежуточных проверок Когда вдохновение несет и хочется "прибраться" и тут и там и везде и некогда останавливаться можно "пролететь поворот" и даже не один. Лучше всего делить рефакторинг на логические этапы. "Дешевые" по времени и ресурсу проверки можно и нужно запускать как можно чаще: компиляция, тесты, запуск приложение локально. Между крупными этапами желательно проводить регрессионное тестирование. И самое отличное поэтапный релиз рефакторинга, чтобы провести не только синтетические проверки, но самую важную "проверку продакшеном"
Затягивать и долго не релизить рефакторинг Топ выбрасываний рефакторинга на моей практике происходило из за желания довести его до окончательного окончания, всё всё исправить, привести в идеальную симметрию и тд и тп. Чем дольше человек очищает код, пока параллельно идут продуктовые спринты, тем больше он несет накладных расходов(мержить то надо) и тем больше падает вероятность успешной интеграции ветки рефакторинга с основной и его успешного релиза.
Не думать о запасном варианте Не смотря на все многоступенчатые системы проверки качества вашего кода всегда есть далеко не нулевая вероятность ошибки, особенно когда "наводишь порядок" в самом ключевом месте системы (а где еще как не в таких местах наводить порядок). В таких ситуация очень полезно оставлять запасной вариант, например флаг переключения на "абсолютно старый код", лучше всего налету без рестартов.
В своем канале о разработке в стартапах делюсь опытом и рассказываю еще больше удачных примеров и факапов. Буду рад видеть каждого! Заходите!
[ВИДЕО] AmoCRM + Joomla: быстрая настройка интеграции. Библиотека WT AmoCRM.
- Как быстро настроить интеграцию AmoCRM и сайта на Joomla?
- использовать PHP библиотеку WT AmoCRM для Joomla, которая предполагает использование её разработчиками. А разработчики могут написать любое количество плагинов и решений по интеграции и автоматизации AmoCRM и Joomla.
📈 MariaDB 11.8, векторные БД и курс на миграцию с Oracle: Итоги MariaDB Meetup в Тель-Авиве
Я и Монти Видениус
Вчера мне посчастливилось побывать на MariaDB Meetup с участием самого Майкла «Монти» Видениуса в Тель-Авиве. Это событие стало не только ценной возможностью услышать о стратегических и технических планах развития MariaDB, но и позволило укрепить партнерские связи между проектом и нашей образовательной платформой.
Делюсь ключевыми тезисами и анонсами с митапа, которые будут интересны всем, кто работает с базами данных и Open Source.
1. Стратегический вектор: Open Source и миграция с Oracle
Майкл Видениус в своем докладе однозначно обозначил стратегию MariaDB: курс на безоговорочную победу открытого кода над проприетарными гигантами. Основной акцент был сделан на преимуществах миграции с Oracle на MariaDB.
Преимущества и миграция:
Экономическая эффективность: Монти открыто говорил о несопоставимой стоимости использования и владения MariaDB по сравнению с Oracle, что является критическим фактором для многих корпоративных пользователей.
Совместимость синтаксиса: MariaDB активно развивает режим совместимости с Oracle (Oracle Compatibility Mode), который значительно упрощает процесс перехода, позволяя использовать привычный синтаксис SQL. Это резко снижает затраты времени и ресурсов на переписывание существующего кода.
Производительность MariaDB 11.8: Были продемонстрированы тесты, подтверждающие рост производительности более чем в 2,5 раза по сравнению с предыдущими версиями за счет архитектурных улучшений.
2. MariaDB, AI и Векторные базы данных
Сергей Голубчик представил глубокий технический обзор поддержки векторного типа данных в последних версиях MariaDB. Это важнейший шаг, который ставит MariaDB в один ряд с современными решениями, адаптированными для задач искусственного интеллекта.
Векторный тип данных (Векторная БД): Встроенная поддержка векторов позволяет использовать MariaDB как полноценную векторную базу данных, что критически важно для работы с embeddings, семантическим поиском и RAG-системами (Retrieval-Augmented Generation).
Производительность и точность (Tradeoff): Сергей Голубчик подробно остановился на ключевом вопросе производительности векторных операций и компромиссе между скоростью поиска и точностью (performance vs. precision of search). Он продемонстрировал, как тонкая настройка конфигурации и индексов (например, использование HNSW-индексов) позволяет добиться наилучшего баланса, обеспечивая высокую скорость без существенной потери точности результатов.
3. Видение будущего и сотрудничество
Анна Видениус (CEO MariaDB Foundation) представила стратегический обзор развития проекта, подчеркнув фокус на стабильности, высокой производительности и укреплении позиции MariaDB в корпоративном сегменте.
🤝 Новые горизонты: Планы сотрудничества с sqlize.online
Самой продуктивной частью митапа стало личное общение с Майклом и Анной Видениус, которое вылилось в конкретные договоренности:
Расширение поддержки версий: Платформа sqlize.online расширит поддержку MariaDB до трех актуальных версий, включая последнюю — MariaDB 11.8 — с акцентом на тестирование ее векторных возможностей.
Новый учебный контент: На sqltest.online будет запущен новый набор практических заданий, разработанных совместно с командой MariaDB, для глубокого освоения последних функций и особенностей этой СУБД.
Это сотрудничество поможет ускорить процесс обучения и внедрения инноваций MariaDB среди разработчиков и аналитиков.
❓ Дискуссия: Готовы ли вы использовать векторы в MariaDB?
MariaDB смело интегрирует технологии будущего, делая ставку на миграцию и ИИ.
Уважаемые читатели Хабра, вопрос к вам:
Как вы относитесь к появлению нативной поддержки векторного типа данных в MariaDB? Готовы ли вы использовать эту функцию в своих новых проектах и рассматривать MariaDB как альтернативу специализированным векторным базам данных?
Привет! На Хабр Карьере мы собираем для вас сотни классных онлайн-курсов, которые помогают быстро и качественно прокачать профессиональные навыки.
Мы часто делимся подборками по специальностям, а в этот раз решили действовать прицельно — собрали подборку курсов по конкретным прикладным программам.
PostgreSQL на 4 ТБ, Patroni на две столицы и 16 000 фур в реалтайме: как мы «перевозили» CARGO.RUN
Привет, Хабр! Представьте ситуацию: один логист управляет 80 машинами одновременно. Маршруты, топливо, простои — все в реальном времени. Остановись сервер — бизнес сразу теряет деньги, а на перевозчиков сваливается хаос.
Именно таков мир, в котором работает команда CARGO.RUN — SaaS-платформа, которая автоматизирует грузоперевозки для топ-игроков рынка. Мы подготовили кейс о том, как помогли CARGO.RUN мигрировать к нам в Selectel. Внутри — настоящий технический детектив и архитектурный дзен.
Базы данных — почему для PostgreSQL с расширениями PostGIS и Timescale (а это 4 ТБ «горячих» данных!) выбрали именно выделенные серверы, а не облако.
Отказоустойчивость — как развернули кластер Patroni, физически разнесенный между дата-центрами в Москве и Санкт-Петербурге, чтобы пережить падение целого региона.
Оркестрация — переход от Docker Swarm к Managed Kubernetes для микросервисов, когда в штате всего три DevOps-инженера.
IaC — как Terraform и GitOps помогли навести порядок и сделать инфраструктуру прозрачной.
Результат миграции — рост производительности логистов в 2,5 раза и сокращение порожнего пробега фур на 53%.
Через 25 минут на вебинаре «Внутри S3». Мы создаем масштабируемые, отказоустойчивые и быстрые S3-хранилища: ледяные, холодные, горячие и стандартные. Познакомим вас с устройством сервиса под капотом и разберем, как используют S3 компании из разных сфер. Присоединяйтесь!
⚡️ITFB Group запускает KODA — платформу для объективной оценки эффективности разработки
Мы представили KODA — собственную платформу, которая показывает, как на самом деле работает команда разработки. Не по ощущениям и не по субъективным отчётам, а на основе данных из всех инструментов инженеров: репозиториев, таск-трекеров, CI/CD, баз знаний и систем тестирования.
🔥 За первые 3 квартала внутреннего использования мы увеличили производительность команд на 30%, сократили количество переделок на 35% и ускорили code review на 40%.
💻 KODA объединяет инженерные метрики, ИИ-модули и аналитику, чтобы дать руководителям полную картину разработки — прозрачную, измеримую и безопасную. Все данные остаются внутри компании.
Наталья Романова, директор по развитию ITFB Group: «Мы создавали KODA как инженеры для инженеров. Но в итоге получили инструмент, который одинаково важен и для бизнеса: он переводит работу разработки в язык цифр, прозрачности и управляемости».
📎 По оценкам Gartner, к 2027 году подобные системы станут стандартом для половины компаний мира. Российский рынок только начинает этот путь — и KODA становится одним из первых решений такого уровня.
Приглашаем на бесплатный вебинар «Микросервисы: 5 главных ошибок и как их избежать с самого начала». Обсудим, какие ошибки возникают при переходе на MSA: от не тех границ сервисов до хаоса и технического долга.Вы узнаете, как с самого начала проектировать архитектуру правильно и получите чек-лист «10 признаков здоровой микросервисной системы» чтобы не создать «распределенный монолит».
‼️ Обратите внимание, что чек-лист будет выдан только участникам эфира.
🕓 Когда: 25 ноября, 16:00–17:00 (Мск)
👨🎓 Спикер: Бурцев Николай — cпециалист по архитектуре ПО, проектированию MSA, .NET-разработке.
Разберём:
1️⃣ Неправильное выделение границ микросервисов: бизнес-декомпозиция против технической.
2️⃣ REST-зависимость: когда API превращается в паутину.
3️⃣ «Всё через брокер»: когда Kafka и RabbitMQ создают больше проблем, чем решают.
4️⃣ Архитектура без инфраструктуры: CI/CD, наблюдаемость, DevOps-влияние.
5️⃣ Архитектура без коммуникации: стандарты, код-ревью, управление качеством.
