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

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

Именно для этого существуют Deployment Strategies — набор подходов, которые определяют, каким образом новая версия приложения попадает в продакшен. В этой статье разберём самые популярные стратегии деплоя: Recreate, Rolling Update, Blue-Green, Canary и Shadow, посмотрим их плюсы и минусы, а также выясним, в каких сценариях каждая из них действительно полезна.

Всем привет! Меня зовут Татьяна, я — Expert/Tech Lead команды аналитики в ГНИВЦ.

Помню тот день, когда я сидела перед монитором в 10‑й час работы над постановкой и параллельно работала над планом развития в новой должности без  ощущения прогресса, без ощущения удовлетворения. В голове крутилась мысль: «Зачем я это делаю?» Я хотела достичь должности, о которой многие мечтают, но чувствовала себя выжатой, потерянной и неуверенной в себе.

Оказалось, мной долгое время руководили ожидания высокого дохода и престижа. Я гналась за «правильной» карьерой, пока не осознала: мои реальные цели — совсем иные. Это было как пробуждение: я поняла, что нужно «переоткрыть себя».

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

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

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

Я фронтенд-разработчик, и в одном из своих пет-проектов на React-сервисе с цветовыми палитрами мне нужно было сделать функционал фильтров, токенов поиска и поиска по названию, где пользователь мог бы выбрать цвет, задать стиль палитры, отфильтровать по количеству цветов и вводить текстовый запрос.

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

Если администрировать Linux-сервера достаточно долго, рано или поздно сталкиваешься с сетевой фильтрацией. Где-то нужно закрыть лишние порты, где-то ограничить доступ между сегментами сети, а где-то настроить NAT.

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

В этой статье разберёмся, как появился nftables, чем он отличается от привычного iptables, как устроена его архитектура и как на практике использовать его для настройки firewall на Linux-сервере.

Я фронтенд-разработчик, в основном работаю с React. И в одном из своих пет-проектов я столкнулся с задачей, где нужно автоматически извлекать доминирующие цвета из изображения — для генерации палитры. Начал разбираться, какие подходы вообще существуют, как это делают другие инструменты и что из этого можно реализовать прямо в браузере без тяжёлых зависимостей и серверной обработки.

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

ORC — это колоночный формат, то есть данные хранятся не по строкам (как в CSV), а по столбцам. Именно это даёт ему способность эффективно сжимать и читать только нужные колонки. Есть ещё встроенная индексация и фильтр Блума, которые позволяют не перелопачивать лишние данные.

Давайте заглянем под капот и посмотрим, как устроен ORC-файл, зачем там индексы и как фильтр Блума ускоряет поиск.

Недавно, в одной из соцсетей, наткнулся на короткий пост, в котором автор написал:

«СКАМИНА ДЛЯ АЙТИШНИКОВ
Выглядит так —
Приглашают на интервью, в конце говорят, что вот проект, с которым нужно будет работать, и кидают ссылку на GitHub.
Говорят: склонируй, расскажу, что там по архитектуре.
Ну и если склонировать, там внутри таски для VS Code, которые качают и запускают обфусцированный код.
Берегите себя.»

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

Давайте разберемся, как это работает.

HAProxy часто появляется в инфраструктуре незаметно. Сначала это просто балансировщик: принял трафик, отправил дальше — всё понятно. Потом появляется второй сервис, третий, routing по домену, path, заголовкам, SNI, а заодно canary и временные исключения. И вот конфиг, который когда-то помещался на один экран, превращается в логическую задачу со звёздочкой.

В этот момент почти всегда всплывают ACL. Кто-то использует их осознанно, кто-то — по принципу: нашёл в примере, вроде работает. Рядом с ACL неизбежно стоит mode: tcp или http. Снаружи это выглядит как простая настройка, но на деле — фундаментальное решение, от которого зависит, какие данные HAProxy вообще видит и какие условия способен проверить.

Проблема в том, что HAProxy не делает догадок. Он последователен и выполняет конфигурацию ровно так, как она написана. Отсюда и классика жанра: ACL есть, но backend не выбирается; mode вроде http, но заголовки недоступны; routing работает почти всегда, кроме пятницы.

Общеизвестным является тезис о том, что от избыточного индексирования страдают только DML-операции, а SELECTы только получают разнообразные бенефиты.
Однако существуют определённые нюансы, которые могут разрушить данную стройную картину мира.

Я попробую продемонстрировать возможную проблему на тестовом примере (кстати, почти аналогичная проблема наблюдалась в реальной ПРОМ-системе).

В какой-то момент почти в каждом Kubernetes-кластере наступает день, когда kubeconfig с правами cluster-admin перестаёт быть временным решением и внезапно становится: так исторически сложилось. Пользователей становится больше, доступы плодятся, а вопрос: кто и зачем может удалить namespace в проде? повисает в воздухе без логичного ответа.

До определённого масштаба это ещё можно терпеть: сертификаты, статические токены, ручная раздача доступов. Но как только в кластере появляются: несколько команд, требования по аудитам, SSO или просто здравый смысл, становится ясно — Kubernetes нужно подключать к нормальной системе аутентификации.

Kubernetes из коробки умеет работать с OIDC (OpenID Connect), и это, пожалуй, самый адекватный способ интегрировать его с внешним Identity Provider. В роли такого провайдера часто выступает Keycloak: open-source, self-hosted, с поддержкой групп, ролей и интеграцией с LDAP/AD. В общем, всё, что обычно уже есть в инфраструктуре, либо планируется к появлению.

Эта история началась с исследования проблем производительности на высоконагруженной базе данных Postgres. Табличка, которая была предметом исследования, довольно небольшая (~100,000 записей), но очень активно используемая.

В процессе исследования я увидел, что Postgres использует индексный доступ по абсолютно неселективному критерию, фактически это был "INDEX FULL SCAN" в терминологии Oracle. Интуиция, наработанная на другой промышленной базе, вопила: "что-то здесь не так!"

Но что?

Когда проект Kubernetes только начинал свой путь, вопрос как пустить трафик в кластер решался просто: как-нибудь. Сервисы торчали наружу через NodePort, потом появился LoadBalancer, а чуть позже — объект Ingress, который на долгие годы стал стандартной точкой входа в HTTP-мир Kubernetes.

Ingress был своевременным решением. Он дал декларативный способ описывать маршрутизацию, TLS и виртуальные хосты, не заставляя инженеров напрямую настраивать nginx-конфиги или HAProxy руками. Для своего времени — шаг вперёд, и весьма заметный. Проблема в том, что Kubernetes рос быстрее, чем сам Ingress.

Со временем выяснилось, что спецификация Ingress намеренно минималистична. В ней нет ни чёткого разделения ответственности, ни расширяемой модели, ни нормального способа описывать сложные сценарии маршрутизации. Всё, что выходило за рамки базового use case, уезжало в аннотации ingress-контроллеров. В результате у нас появился единый стандарт, который на практике вёл себя по-разному в зависимости от того, какой контроллер стоял в кластере. Формально — Ingress, фактически — vendor-specific конфигурация с YAML-обвязкой.

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

Проблема заключается в том, что в таблице на React с колонками, у которых есть свойство position: sticky, иногда пропадала граница между соседними ячейками по вертикали. Причём проявлялась она не всегда и носит случайный характер. Забавно, что изменение масштаба страницы (Ctrl + колесико мыши) мгновенно возвращает исчезнувший бордер. При этом в CSS все прописано и никуда не исчезает — это чисто визуальный баг рендера.

eBPF давно перестал быть узкоспециализированной игрушкой для kernel-энтузиастов и исследователей внутренностей Linux. Сегодня с ним, так или иначе, сталкиваются не только SRE, но вообще все, кто разрабатывает системы, близкие к сети, производительности или безопасности: от авторов сетевых плагинов (CNI) и прокси, до разработчиков кастомных агентских решений, observability-инструментов и low-level инфраструктурных компонентов. Даже если вы никогда не писали eBPF-код руками, есть хороший шанс, что он уже работает в вашей системе — тихо, незаметно и с довольно широкими полномочиями.

Чаще всего eBPF проявляется через удобные CLI, библиотеки и дашборды: установили агент, включили, и внезапно система знает о происходящем больше, чем strace, tcpdump и половина метрик вместе взятых. Но за этим комфортом скрывается нетривиальный механизм исполнения пользовательского кода прямо внутри ядра Linux — с жёсткими правилами валидации, ограниченной моделью исполнения и целым набором архитектурных компромиссов, о которых обычно не принято говорить в маркетинговых описаниях.

Здравствуйте, снова я — Дмитрий, React-разработчик. Все мы видели с вами такие карты, именуемые картойдами, в данном случае — карта России, я взял первую попавшуюся из интернета, для примера.

Если верить вакансиям, DevOps — это человек-оркестр: он пишет пайплайны, чинит Kubernetes, настраивает облака, знает Linux на уровне ядра, умеет в безопасность, автоматизацию, мониторинг и, на всякий случай, может заменить бэкендера, когда тот ушёл в отпуск. Желательно за зарплату джуна и с готовностью выходить на алерты в три часа ночи. Реальность, к счастью, чуть менее драматична. Но и чуть более сложна, чем рассказывают на вводных курсах (привет тем, кто решился вкатится по быстрому). В этой статье разберёмся, кто такой DevOps на самом деле, почему от него действительно ждут «всего и сразу» и где заканчивается адекватное ожидание, и начинается фантазия работодателя.

Всем привет, на связи снова я — Дмитрий, React-разработчик. И сегодня хочу поднять тему, которая на первый взгляд кажется простой, но на практике может доставить немало сюрпризов - округление и форматирование чисел в интерфейсе.

Изначально может показаться, что здесь сложного практически ничего нет: есть toFixed() и toLocaleString(), но практика показывает, что реальные интерфейсы почти никогда в это не укладываются.

Почему? Потому что в разных диапазонах чисел пользователи ждут разного поведения.

Именно с этим сталкиваются разработчики при работе с таблицами, отчётами, финансовыми данными и аналитикой.

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

Ниже опишу требования к форматированию, которые легли в основу функции, и покажу, как они отражаются в коде и в интерфейсе.

Сетевую часть Linux обычно «настраивают», но редко понимают. Добавляют iptables-правило, включают NAT, правят sysctl — и если трафик пошёл, считается, что задача решена. Проблемы начинаются ровно в тот момент, когда он не идёт, а поведение системы перестаёт быть очевидным. В Linux нет магии. Есть IP-пакет, его заголовки и строго определённый путь внутри ядра: маршрутизация, netfilter, conntrack, NAT, TCP/UDP стек. Если не понимать этот путь целиком, firewall выглядит как чёрный ящик: NAT — как случайный набор правил, а Kubernetes CNI — как нечто «особенное», существующее отдельно от обычной сети.

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

Я решил провернуть небольшой трюк для получения приблизительного разделения. Давайте посмотрим, что у меня получилось на модельном примере.