Привет! 👋

Знакомо: делаешь новую фичу в отдельной ветке, а проджект или тестировщик просит: «А можно 👀глянуть👀 вживую?». И начинается ад:

🔹«Подними на тестовом» → нужно мержить, конфликты, ждать
🔹«Дай доступ к локальному» → настраивать окружение, порты, зависимости
🔹«Скинь скриншоты» → не показывает реальное поведение

🔥 Есть способ лучше 🔥
Review Apps в GitLab — это временные окружения, которые создаются автоматически для каждой ветки и умирают после мержа. Как облачный стенд, который живет ровно столько, сколько нужно.

Вот как это настроить. Без магии, просто копируй:

review:
  stage: deploy
  noscript:
    - echo "Деплоим ветку $CI_COMMIT_REF_SLUG на временный сервер"
    # Твои команды деплоя (kubectl, docker-compose, ansible)
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.your-app.com
    on_stop: stop_review  # что запустить при удалении
  rules:
    - if: $CI_MERGE_REQUEST_ID  # Только для MR

stop_review:
  stage: cleanup
  noscript:
    - echo "Удаляем окружение review/$CI_COMMIT_REF_SLUG"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual  # или automatic для автоудаления

💡Что происходит:

1️⃣ Создаешь Merge Request → пайплайн сам поднимает окружение
2️⃣В MR появляется кнопка с ссылкой на твое живое приложение
3️⃣ После мержа (или вручную) окружение автоматически чистится

Зачем это тебе:
• Показываешь работу клиенту/ПМ/тестировщику без лишних телодвижений
• Тестируешь в реалистичных условиях, а не «на локалке»
• Экономишь ресурсы — окружения живут только когда нужны
• Автоматизируешь рутину — не нужно руками что-то поднимать и чистить

Это не сложно.
Если уже умеешь деплоить приложение (хоть в Docker, хоть на сервер), то добавить Review Apps — дело 15 минут ⏰ конфигурации.

А если хочешь научиться не просто копировать конфиги, а понимать как проектировать такие пайплайны — приходи на курс по GitLab CI. Научим делать не только Review Apps, но и полноценные staging/prod окружения с безопасностью и мониторингом.

Если было полезно, то ставь 🔥

Хей, ребята! 🖖

Часто вижу в проектах JWT как стандарт для аутентификации. Токен есть, но мало кто смотрит, насколько он действительно защищён.

😳 А зря 😳
Потому что типовые ошибки в JWT — это прямая дорога к компрометации аккаунтов.
Не верите?

Давайте проверим ваш токен прямо сейчас.

📌 Шаг 1: Смотрим, что внутри
JWT состоит из трёх частей: header.payload.signature. Просто вставьте свой токен на сайт jwt.io или в расширение DevTools — и сразу увидите:
1️⃣ Алгоритм подписи (alg)
2️⃣ Данные пользователя (payload)
3️⃣ Срок действия (exp)

📌 Шаг 2: Ищем опасные признаки
1️⃣ Алгоритм "none" — самая грубая ошибка. Если в header видите "alg": "none", токен можно подделать, просто удалив подпись.
2️⃣ Слабый секрет — если ключ подписи простой (типа "secret123"), его можно подобрать брутфорсом. Проверить можно через hashcat или онлайн-инструменты.
3️⃣ Отсутствие проверки alg — сервер может принимать любой алгоритм. Попробуйте сменить RS256 на HS256 в header — иногда это срабатывает.

📌 Шаг 3: Практика в Burp Suite
1️⃣ Перехватите запрос с токеном в Burp
2️⃣ Отправьте токен в Decoder
3️⃣ Модифицируйте payload (например, поменяйте "user": "user" на "user": "admin")
4️⃣ Если подпись не проверяется — вы только что нашли уязвимость

Что делать, если нашли проблему?
↘ Никогда 🚫 не используйте алгоритм "none" в продакшене
↘ Генерируйте сложные секреты длиной от 32 символов
↘ Всегда проверяйте алгоритм подписи на сервере
↘ Используйте короткое время жизни токенов (exp)

⚠️P.S. Эта проверка — только верхушка айсберга⚠️
Если хотите не просто находить уязвимости, а понимать их природу и думать как атакующий — смотрите наш практический курс по безопасности веб-приложений.

На курсе разберём:
🔹 Полный цикл пентеста — от разведки до отчёта
🔹 Все уязвимости OWASP Top 10 на реальном стенде OWASP Juice Shop
🔹 Работу с Burp Suite на продвинутом уровне
🔹 Методы защиты на уровне архитектуры, а не просто "заплатки"

🗓Старт: 22 декабря
Подробная программа

Проверили свой токен? 🔍

Знакомо ощущение, когда открываешь Burp Suite и теряешься в сотне вкладок? Интерфейс выглядит как кабина пилота, а времени на полноценный пентест нет.

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

🎯 1. Intercept — видеть всё, что уходит в сеть
Зачем: понимать, что на самом деле отправляет ваше приложение.
Что делать:
1. Включите перехват (Intercept is on)
2. Выполните действие в браузере (логин, поиск)
3. Смотрите "сырой" запрос: куки, заголовки, параметры
⭐️Фишка: меняйте любые параметры на лету. Хотите проверить, что будет если передать user_id=1 вместо user_id=2? Просто отредактируйте и нажмите Forward.

🔁 2. Repeater — тестировать одну точку снова и снова
Зачем: глубоко проанализировать конкретный эндпоинт.
Что делать:
1. Перетащите перехваченный запрос из Intercept во вкладку Repeater
2. Меняйте параметры, заголовки, тело запроса
3. Нажимайте Send и сравнивайте ответы
💡Практический кейс: Проверка на SQL-инъекцию. Добавляете ' или " в параметры и смотрите — не вернулась ли ошибка базы данных в ответе?

⚡ 3. Active Scan — автоматический поиск уязвимостей
Зачем: пусть Burp поработает за вас, пока вы занимаетесь другими задачами.
Что делать:
1. Кликните правой кнопкой по запросу в Proxy → Send to Scanner
2. Выберите Active Scan
3. Через 10-15 минут проверьте вкладку Dashboard → Issue activity

🔥 Что найдёт: XSS, SQLi, уязвимые заголовки, проблемы с CORS, пути к файлам — всё, что можно обнаружить автоматически.

📌 Краткий алгоритм на 10 минут:
1️⃣ Настройте прокси в браузере на 127.0.0.1:8080
2️⃣ Включите Intercept, сделайте действие в приложении
3️⃣ Изучите запрос — нет ли в нём чувствительных данных
4️⃣ Отправьте в Repeater подозрительные эндпоинты
5️⃣ Запустите Active Scan на самый интересный запрос

Этих трёх инструментов достаточно, чтобы провести базовую проверку безопасности за чашку кофе☕️.
Burp Suite — это не только для хакеров, это практичный Swiss Army Knife для инженера, который хочет быть уверен в своём коде.

P.S. Хотите не просто пользоваться инструментами, а понимать, как искать уязвимости системно? Наш курс по безопасности веб-приложений — это не про запоминание кнопок в Burp, а про мышление пентестера.

Старт: 22 декабря

А какими функциями Burp Suite пользуетесь вы чаще всего?

👀 С этими 5 ошибками в GitLab CI сталкиваются все 👀

🔥Разбираем, почему они возникают и как их решать раз и навсегда

Если работаешь с GitLab CI, ты точно знаешь эти боли. Вместо того чтобы гуглить каждый раз, давай разберемся, почему они случаются и как исправить их системно.

1️⃣ «Runner зарегистрирован, но джобы висят в stuck»
Что происходит: Создал раннер, а пайплайн не стартует. В интерфейсе This job is stuck.
Почему так: GitLab отправляет джоб только на раннеры с подходящими тегами. Если в джобе tags:[docker], а у раннера тег linux, они не встретятся.

💡Как решить:
↘ Проверь теги раннера: gitlab-runner list
↘ В .gitlab-ci.yml укажи те же теги в джобе
↘ Убедись, что раннер в статусе active (не paused)
🧠 Системный подход: Пойми механику tags как систему маршрутизации и сможешь проектировать инфраструктуру под разные типы задач.

2️⃣ Docker-in-Diner: connection refused
Что происходит: Пытаешься собрать Docker-образ внутри CI, но получаешь Cannot connect to the Docker daemon.
Почему так: Докер внутри контейнера (DinD) требует особых прав и переменных окружения.

💡Как решить:

services:
  - name: docker:dind
    alias: docker
    command: ["--tls=false"]
variables:
  DOCKER_HOST: tcp://docker:2375
  DOCKER_TLS_CERTDIR: ""

↘ Плюс не забудь добавить privileged: true в конфиг раннера при регистрации.
🧠 Системный подход: Пойми разницу между изолированными окружениями и научишься выбирать подход (DinD, Kaniko, Socket) под задачу.

3️⃣«Кеш не работает, зависимости качаются каждый раз»
Что происходит: Вроде настроил кеширование, но npm install или go mod download выполняются каждый раз с нуля.
Почему так: Ключ кеша меняется при каждом коммите (например, $CI_COMMIT_SHA), поэтому GitLab не находит старый кеш.

💡 Как решить:

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - node_modules/

Для кеширования зависимостей лучше использовать хэш lock-файла:

cache:
  key: $CI_COMMIT_REF_SLUG-$CI_PROJECT_DIR/package-lock.json

🧠 Системный подход: Научись проектировать стратегии кеширования, понимать lifecycle кеша и экономить часы времени сборок.

4️⃣ Секрет случайно попал в логи
Что происходит: В логах пайплайна видишь свой $DEPLOY_TOKEN или другой секрет.
Почему так: GitLab не может автоматически маскировать секреты, если они попадают в stdout.

💡 Как решить:
↘ Создай переменную в Settings → CI/CD → Variables с флагами Masked и Protected
↘ Никогда не делай echo $TOKEN — вместо этого проверяй наличие: if [ -n "$TOKEN" ]; then echo "Token is set"; fi
↘Используй set -euo pipefail для отладки, но затем убирай

🧠 Системный подход: Разберись с практиками безопасной работы с секретами, поймешь, как GitLab обрабатывает переменные под капотом.

5️⃣ «У меня локально работает, а в CI падает»
Что происходит: Тесты проходят на локальной машине, но в пайплайне валятся с ошибками подключения.
Почему так: В CI сервисы доступны не по localhost, а по своим сетевым алиасам.

💡 Как решить:

services:
  - postgres:14
  
test:
  noscript:
    - PGHOST=postgres psql -U postgres -c "SELECT 1"  # не localhost!

🧠 Системный подход: Научись проектировать воспроизводимые окружения и поймешь принципы контейнерной сети в CI.

------------------------------
Эти 5 проблем — симптомы. Корень — в непонимании как GitLab CI работает изнутри.

На курсе GitLab CI мы учим не просто «как исправить», а:
🔹 Предсказывать проблемы до их появления
🔹 Строить ментальную модель работы пайплайнов
🔹 Принимать инженерные решения — какой подход выбрать под задачу
🔹 Отлаживать системно — от чтения логов до анализа архитектуры

Стартуем 22 декабря. Подойдет, если уже работаешь с веб-проектами и хочешь прокачать автоматизацию.
До 10 декабря включительно цена 22 000 рублей потом 25 000.

По ссылке можешь купить программу.

🏁 ДЕНЬ СТАРТА: ПОГНАЛИ РЕШАТЬ! БЕСПЛАТНО!

Сегодня 10 декабря! Пора закатать рукава и погрузиться в детали сломанного Systemd.

Переходите на страницу траблшутинга → регистрируйтесь, если не успели → и начинайте решать!

Ваша задача уже ждёт:
1. Нужно разобраться, почему Go-приложение отказывается работать как служба, хотя вручную — всё запускается.
2. Где та самая коварная строчка в конфиге? Где прячется проблема с правами или изоляцией?

❗️❗️❗️ Что делать прямо сейчас: ❗️❗️❗️
↘Внимательно изучите условие задачи - вот прямая ссылка на задачу, если уже зарегистрировались. Все детали и подсказки уже там.
↘Приступайте к диагностике. Проверяйте логи, анализируйте юнит, тестируйте гипотезы.
↘У вас есть 5 дней — до 15 декабря включительно — чтобы найти решение и отправить его.

🔥 А 15 декабря Василий Озеров проведёт подробный разбор задачи:
✅ Покажем правильное решение и все шаги диагностики.
✅ Объясним ключевые ошибки и как их избежать.
✅ Ответим на ваши вопросы по решению.

Не откладывайте! Самые интересные инсайты часто приходят в процессе глубокого копания.

🟡 Анонс открытых практикумов на следующую неделю

1️⃣ Networks: Использование протокола RADIUS для аутентификации пользователей на сетевых устройствах
↘ Регистрация

Время проведения:
16 декабря, вторник, 19:00 по МСК

Программа практикума:
🟢Radius: основные теоретические сведения
🟢Установка и базовая конфигурация freeradius
🟢Настройка централизованной аутентификации

Кто ведёт?
Андрей Шабалин — тренер Cisco/Huawei, кандидат наук, преподаватель сетевых технологий на онлайн-платформах, инструктор академии Eltex и Астра-Университета. Автор сообщества «Компьютерные сети и сетевая безопасность»
---------------------------------------------------------------------------------------

2️⃣ Linux: GlusterFS: распределенная файловая система
↘ Регистрация

Время проведения:
17 декабря 2025, среда, 20:00 по МСК

Программа практикума:
🟢Чем был плох DRBD?
🟢Типы томов GlusterFS
🟢Настраиваем GlusterFS
🟢Добавляем ноду в кластер

Кто ведёт?

Андрей Буранов — системный администратор в департаменте VK Play. 13+ лет опыта работы с ОС Linux. 11+ лет опыта преподавания. Входит в топ-3 лучших преподавателей образовательных порталов.
---------------------------------------------------------------------------------------

3️⃣ DevOps: Kubernetes: The Hard Way
↘ Регистрация

Время проведения:
18 декабря 2025, четверг, 19:00 по МСК

Программа практикума:
🟢Разбираемся с архитектурой Kubernetes
🟢Разворачиваем собственный кластер без автоматизации
🟢Добавляем узлы и запускаем полезную нагрузку

Кто ведёт?
Василий Озеров — co-Founder REBRAIN, IT-инженер с 2012 года, провёл 100+ вебинаров по DevOps и инфраструктуре.
---------------------------------------------------------------------------------------

✉ Также у нас есть открытое комьюнити, где мы собрали много специалистов по инфраструктуре, готовых помочь и поделиться опытом. Задать вопрос коллегам и разобраться в сложных задачах можно по ссылке!

Мы взяли 5 самых частых болей и показали, каких лечим на курсе "Postfix".

1️⃣ Проблема: Письма уходят, но не доходят или летят в спам. Ты слышал про SPF/DKIM, но настраивать их страшно — можно сломать всю рассылку.
💡 Решение: Внедришь SPF, DKIM и DMARC с нуля. Научишься генерировать ключи, править конфиги Postfix и публиковать DNS-записи так, чтобы почта гарантированно доходила до inbox.

2️⃣ Проблема: Алерты от мониторинга (Zabbix, Grafana) или уведомления от GitLab внезапно перестали приходить. Где искать проблему — в приложении, сети или почтовом сервере?
💡 Решение: Освоишь диагностику очередей Postfix. Научишься командой mailq находить «застрявшие» письма и за 5 минут определять причину сбоя.

3️⃣ Проблема: Нужно поднять почтовый сервер для тестов, нотификаций или обработки заявок с сайта. Гайды из интернета противоречивы, а в main.cf страшно что-то менять.
💡 Решение: Настроишь Postfix с нуля для локальной работы и отправки писем. Поймёшь ключевые параметры и научишься проверять работу через telnet, чтобы не гадать.

4️⃣ Проблема: Сервер нечаянно стал открытым релеем, его IP попал в чёрные списки (RBL), и теперь вся почта блокируется. Как это предотвратить?
💡 Решение: Настроишь жёсткие политики доступа. Поймёшь, как работают mynetworks и relay_domains, и подключишь RBL-фильтрацию, чтобы спамеры обходили твой сервер стороной.

5️⃣ Проблема: Нужно принимать почту для нескольких доменов или сделать переадресацию с info@ на команду. Приходится городить костыли или просить «того, кто умеет».
💡 Решение: Настроишь виртуальные домены и алиасы. Сможешь создавать групповые рассылки и перенаправлять почту на скрипты — без магии и лишних движений.

👀 И это не всё. На курсе разберём и другие задачи:
• Настройку шифрования (TLS) и интеграцию с Dovecot
• Диагностику проблем с DNS (MX, PTR записи)
• Режимы Smarthost и Null Client для отправки через внешние сервисы
• И многое другое — полная программа по ссылке.

Старт курса — 22 декабря.

Стоимость: 22 000 25000 до 20 декабря.

Это не теория, а готовые рецепты для самых частых и болезненных проблем. Пора перестать тушить пожары и начать понимать, как работает почта.

💰 Для тех, кто хочет сразу купить, оставляем ссылочку.

Для вас мелочь, а нашей команде очень приятно получать положительный фидбек от вас💓

Переходите на страницу траблшутинга → регистрируйтесь, если не успели → и начинайте решать!

Вот прямая ссылка на задачу, если уже зарегистрировались. Все детали и подсказки уже там.

Делитесь фидбеком в закрытом чате траблштинга в ТГ:
- негативный учтем в следующим задачах 🤓
- а позитивный даст нам мотивации, создавать такие задачи вновь🤩

Используете HDD в Ceph и хотите performance близкий к SSD, но бюджет не резиновый?

💡Есть решение: гибридная конфигурация.

Суть: BlueStore (движок OSD) хранит метаданные и WAL отдельно от данных. Если отдать эти компоненты на быстрый NVMe/SSD — производительность HDD взлетит.

📊 Результат на практике: Снижение задержек (latency) в 2-5 раз, особенно на операциях с малым объемом данных (metadata-intensive workloads).

🔧 Настройка через cephadm:
Создаем спецификацию OSD с разделением устройств:

service_type: osd
service_id: hybrid_osds
placement:
  host_pattern: "storage-node-*"
spec:
  data_devices:
    paths:
      - /dev/sd[b-c]  # Ваши HDD
  db_devices:
    paths:
      - /dev/nvme0n1  # Ваш быстрый SSD/NVMe
  db_size: "50GB"     # Выделяем место под метаданные

Применяем:

ceph orch apply osd -i spec.yml
⚖️ Баланс: Один SSD 1TB может "ускорить" 10-20 HDD по 10TB. Экономия против полноценного SSD-пула — в разы!

❗️ Важно:
🔹WAL и DB лучше размещать на одном быстром устройстве
🔹Для продакшена — отдельные NVMe под каждые 4-8 OSD
🔹Мониторим wearout SSD (SMART) при высокой нагрузке записи

👉 Мы произвели полный рефакторинг курса по Ceph, где разбираем:

1️⃣ Расчёт оптимального соотношения SSD:HDD
2️⃣ Разделение через DriveGroups
3️⃣ Реальные тесты производительности "до/после"
4️⃣ Подбор оборудования под разные workload

Ссылка на подробную программу тут.

🗓 22 декабря старт курса и до 22 декабря вклюбчительно стоимость практикума 25 000 30000 рублей.

Купить можно по ссылке.

🎁💥🔥 У всех пользователей, кто ранее покупал модуль по ceph, c 22 декабря его можно будет обновить бесплатно. Но важно заметить, что:
- мы не переносим прогресс, так как программы полностью отличаются
- старая версия при этом закрывается

Обновляем версию по запросу, условия расскажет поддержка, пишите на почту info@rebrainme.com c 22 декабря.

🟡 Тестовое собеседование + тестовое задание в Магнит.Tech - открытый вебинар пройдет в 19:00 24 декабря!

Вебинару быть! Один доброволец есть 💓

Продливаем поиск второго добровольца, готовых пройти тестовое интервью в открытом формате до 20 декабря!

Подробности и запись в прошлом посте🤍

Знакомо: создали пул в Ceph, потратили час на расчет pg_num, потом кластер вырос — и снова мучитесь с пересчетом и ребалансировкой.

👀 А что если Ceph мог бы сам подбирать оптимальное количество Placement Groups?

💡Он так и делает. Функция называется PG Autoscaler. Включили её — и забыли про ручные расчеты, оверпровижининг и недогрузку пулов. Ceph сам анализирует нагрузку и масштабирует PG по мере роста данных.

📊 Что это дает:
🔹 Автоматическую оптимизацию при добавлении/удалении OSD
🔹 Равномерное распределение данных
🔹 Устранение "узких мест" производительности

⚙️ Как включить за 30 секунд (глобально для кластера):

# Включаем autoscaler
ceph mgr module enable pg_autoscaler

# Ставим режим "on" для всех пулов по умолчанию
ceph config set global osd_pool_default_pg_autoscale_mode on

🔍 Проверить статус:

ceph osd pool autoscale-status

Увидите рекомендации системы по каждому пулу.

🎯 Три режима работы:
• on — Ceph сам решает (рекомендуем для большинства случаев)
• warn — только рекомендации без автоматики
• off — ручное управление (для экспертов)

⚠️ Важный нюанс: Автоскейлинг не панацея. Нужно понимать, как он работает, какие метрики анализирует и когда его лучше отключить (например, для пулов с предсказуемой стабильной нагрузкой).

👉 На модуле по Ceph мы не просто показываем команды, а учим принимать архитектурные решения:
1️⃣Когда и какой режим autoscaler выбрать
2️⃣Как анализировать рекомендации системы
3️⃣Что делать с legacy-пулами, созданными без автоскейлинга
4️⃣Как сочетать с Erasure Coding и репликацией

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

Хватит считать PG вручную — приходите систематизировать знания

Модуль обновим 22 декабря и до 22 декабря включительно стоимость практикума 25 000 30000 рублей.

Купить можно по ссылке.

P.S. А вы используете PG Autoscaler? Или до сих пор считаете pg_num калькулятором?

🟡 Анонс открытых практикумов на следующую неделю

1️⃣ Битмап-индексы без магии: как битовые структуры, roaring bitmaps и фильтры Блума ускоряют поиск, фильтрацию и аналитику
↘ Регистрация

Время проведения:
23 декабря 2025, вторник, 20:00 по МСК

Программа практикума:
🟢Разберём, что такое битмап-индексы, зачем они нужны, где они показывают наилучшую эффективность и когда от них лучше отказаться.
🟢Изучим принципы устройства и особенности применения компрессированных битмапов (Roaring).
🟢Поймём базовые идеи фильтров Блума и их роль в быстрых операциях проверки принадлежности."

Кто ведёт?
Денис Колпаков — Software Engineer, Qase Core Team, еx. Avito Senior Engineer. Занимается backend разработкой 10 лет.
---------------------------------------------------------------------------------------

2️⃣ 🔥Открытое собеседование в Магнит.Tech🔥
↘ Регистрация

Время проведения:
24 декабря 2025, среда, 19:00 по МСК

Программа практикума:
🟢Что интересует работодателя в опыте и как, исходя из этого, составить свое резюме (что привлекает внимание, что отторгает).
🟢Этапы собеседования (обычно 2, бывает 4: какие есть и зачем нужны).
🟢 Собеседование с HR (базовый «привет», на что обратить внимание и что следует спросить самому).
🟢 Техническое собеседование (формальное и неформальное — что хотят слышать технические спецы).
🟢 Обратная связь (не стесняться запрашивать).
🟢Тестовые задания (большой вопрос — а стоит ли оно того?).
🟢Практическая часть: интервью с комментариями (какие интервью бывают плохие, какие хорошие и на что соискателю обращать внимание)."

Кто ведёт?

Владимир Пашковский — 13 лет опыта в DevOps и инженерии инфраструктуры. Руководитель команды DevOps-инженеров в Магнит.Тех. Автор блога о технологиях, работе и карьерном росте @secrets_of_devops
---------------------------------------------------------------------------------------

3️⃣ Мониторинг производительности в Linux
↘ Регистрация

Время проведения:
25 декабря 2025, четверг, 19:00 по МСК

Программа практикума:
🟢Утилиты локального мониторинга системы.
🟢Контроль загрузки процессора, памяти, дисков, сети.
🟢Мониторинг системы с помощью Prometheus.
🟢Визуализация данных в Grafana.

Кто ведёт?
Николай Лавлинский — Технический директор в ООО “Метод Лаб”. Веб-разработчик более 15 лет. Спикер конференций HighLoad++, РИТ++
---------------------------------------------------------------------------------------

✉ Также у нас есть открытое комьюнити, где мы собрали много специалистов по инфраструктуре, готовых помочь и поделиться опытом. Задать вопрос коллегам и разобраться в сложных задачах можно по ссылке!