Привет. Меня зовут Денис, я занимаюсь разработкой и доставкой приложений под Kubernetes с 2020 года. За это время через мои руки прошло достаточно проектов, чтобы заметить одну повторяющуюся вещь: почти в каждом из них рано или поздно заводился собственный набор скриптов, склеивающих сборку образа и выкатку релиза. Скрипты были разные, а болезнь одна – они прирастали к проекту и не переносились на следующий.

В этой статье я разберу контур доставки, который мы собрали, чтобы эту болезнь вылечить. Он ставит два совершенно разных по стеку приложения – React плюс Spring Boot и Angular плюс FastAPI – в кластеры двух окружений одной командой, при этом сам про эти приложения ничего не знает. Всё, что их связывает, – небольшой контракт из нескольких переменных.

Эта статья предназначена для технических специалистов, работающих с Oracle: администраторов баз данных, инженеров производительности, разработчиков инструментов мониторинга и исследователей внутренних механизмов СУБД. Это готовый пример низкоуровневого исследования, который можно адаптировать под собственные задачи. Мы покажем, как связать привычные SQL‑данные из v$sesstat с их реальным расположением в памяти процесса, и на конкретном примере проиллюстрируем методику, применимую и к другим внутренним структурам Oracle. Это первая статья из серии, она посвящена Oracle 11g, довольно древней версии Oracle, далее мы увидим как изменялся подход корпорации Oracle к хранению внутренних структур статистики.

При переносе большой системы разработанной под одну СУБД на другую неизбежно возникают различные нюансы, то? что эффективно работало в одной СУБД, уже не так эффективно (или совсем неэффективно) работает в другой.

В частности, SQL, разработанный под Oracle, при всей синтаксической схожести может работать совсем не так в PostgreSQL. Однако это не значит, что ничего нельзя сделать, зачастую, если переписать код, используя особенности новой СУБД вы можете получить ту же эффективность выполнения.

Сегодня я хочу рассмотреть один частный случай, связанный с обработкой аналитических (оконных) функций оптимизаторами Postgres и Oracle.

В данной статье я хотел бы поговорить немного о неявном приведении типов в Postgres, широко известно, что Postgres не позволяет неявно приводить строковые типы к числовым (как это делает Oracle) и эта добавочная строгость скорее всего правильна (избавляет от многих плавающих ошибок времени исполнения), но кое-какое неявное приведение типов всё-таки остаётся - это приведение внутри числовых типов (int2, int4, int8, numeric) и вот здесь возможны некоторые сюрпризы.

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

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

Какая главная польза от методик/техник тест-дизайна? В целом, методики обобщают опыт инженеров по тестированию, позволяют систематизировать процесс разработки тестов, снизить их число при сохранении достаточного покрытия. Но если рассматривать строгие методы, то у них есть ещё одно важное свойство: в рамках своей применимости они гарантируют полноту покрытия, благодаря самим алгоритмам этих методов.

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

Давайте разберём, почему вопрос быстрого погружения аналитика в ИТ‑проекты сегодня стал по‑настоящему острым и стратегически значимым.

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

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

Именно для этого существуют 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 все прописано и никуда не исчезает — это чисто визуальный баг рендера.