Журнал

Разборы технологий, обзоры инструментов и практические заметки инженерной лаборатории.

Опыт миграции инфраструктуры TSKLab в облако: Yandex Cloud и альтернативы

Миграция в облако — это не просто переезд на виртуальные машины. Это пересборка всей инфраструктуры с нуля: под новые требования к надёжности, стоимости, безопасности и скорости развития. Когда мы в TSKLab затеяли этот процесс, задача стояла сугубо практическая: снять с команды лишнюю операционку, ускорить развёртывание сервисов и получить прозрачный контроль над ресурсами, не завязанный на единственный […]

Читать разбор

Выбор IDE в TSKLab: почему часть команды на IntelliJ, а часть на VS Code

В TSKLab выбор редактора кода — не вопрос личных предпочтений, а инженерное решение, привязанное к конкретным сценариям. Часть команды работает в IntelliJ IDEA, часть — в VS Code, и это не раскол, а осознанное разделение труда. За годы тестирования на реальных проектах мы убедились: универсального инструмента не существует, зато есть чёткие критерии, когда какая среда даёт максимальную […]

Читать разбор

Как мы внедряли CI/CD: GitLab CI и GitHub Actions на проектах TSKLab

# Как мы внедряли CI/CD: GitLab CI и GitHub Actions на проектах TSKLab

В проектах TSKLab мы сознательно использовали два разных подхода к CI/CD: GitLab CI — там, где важны единая платформа и жесткий контроль пайплайнов, и GitHub Actions — там, где удобнее жить рядом с кодом и быстро масштабировать автоматизацию. Такой гибридный подход оказался практичнее, чем попытка […]

Читать разбор

Как изолировать изменение в программном эксперименте: переменные, зависимости и конфаундеры

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

Читать разбор

Canary deployment: как проверять новую версию на части трафика

После тестов новая версия приложения всё равно впервые сталкивается с реальным production-трафиком, реальными данными и рабочими зависимостями. Canary deployment уменьшает масштаб этого первого контакта: старая стабильная версия продолжает обслуживать основную нагрузку, а release candidate получает только ограниченную часть трафика.

Читать разбор

SEO как инженерный эксперимент: как отделять гипотезу, наблюдение и причинность

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

Читать разбор

Логи, метрики и трассировки: что нужно видеть в системе до эксперимента

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

Читать разбор

TSKLab и базы данных: PostgreSQL против MongoDB в реальных проектах

Когда ко мне приходят с вопросом «что круче — PostgreSQL или MongoDB», я всегда прошу показать модель данных. Потому что выбор базы — это не голосование за бренд, а инженерное решение, которое определяется тем, как устроены ваши сущности, какие запросы будут ходить и насколько критична целостность. В реальных системах PostgreSQL чаще выигрывает там, где важны согласованность, сложные […]

Читать разбор

Feature flags: как отделить деплой кода от включения функции

Новая функция может уже находиться в production-коде и при этом оставаться недоступной пользователям. Для этого поведение приложения помещают за feature flag — условием, которое вычисляется во время выполнения и определяет, какую ветку логики использовать.

Читать разбор

Git-история, changelog и журнал эксперимента: что именно фиксировать при изменениях

Когда после обновления поведение системы меняется, команде обычно нужно ответить сразу на несколько разных вопросов. Что было изменено в коде. Что вошло в релиз. Что именно происходило во время проверки и какие наблюдения были получены. Проблема в том, что эти три вопроса часто пытаются закрыть одним объектом, чаще всего списком commit.

Читать разбор