Kurgan-Telecom Ru | Информационные технологии

В одном из прошлых проектов случился «кошмар техлида»: в суматохе хотфикса было забыто добавление фильтра WHERE tenant_id = ? в одну из ручек API. В итоге один клиент увидел отчеты другого. Все быстро откатили, но я навсегда запомнил то холодное чувство в животе.

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

Искал способ гарантировать изоляцию данных так, чтобы ее физически нельзя было забыть.

Почему стандартные решения не подошли?

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

1. Логическая изоляция (WHERE в коде)?

Как это работает: Тысячи строк кода, и в каждом запросе ты обязан помнить про tenant_id.

Проблема: Человеческий фактор. Это бомба замедленного действия.

2. Схема на клиента (Schema-per-tenant)

Как это работает: У каждого клиента своя схема (schema_01, schema_02...).

Проблема: Это работает, пока клиентов 100. Когда их становится 10 000, база начинает задыхаться.

Детали: Проблема даже не в миграциях, а в файловой системе. 10 000 клиентов × 50 таблиц = 500 000 файлов. Postgres (и Linux) сходят с ума от такого количества открытых дескрипторов, а VACUUM превращается в ад.

3. Отдельная БД на клиента

Как это работает: Полная физическая изоляция.

Проблема: Ценник на инфраструктуру. Держать тысячи коннектов или инстансов RDS - экономическое самоубийство для стартапа.

Тогда посмотрел в сторону PostgreSQL Row Level Security (RLS). Честно говоря, поначалу было страшно. Отдавать логику безопасности "черному ящику" внутри БД казалось рискованным. Плюс, все вокруг пугали: "RLS убьет производительность".

«План ничто, планирование всё...» — Дуайт Эйзенхауэр, 34-й президент США

В этой статье поговорим о методах планирования работ и их особенностях. Статья не претендует на полноту или управленческую новизну, это просто мнение «пессимиста» на основании собственного опыта в консалтинговых проектах.

В статье представлены сведения о классах пакета java.lang.ref - SoftReference, WeakReference, PhantomReference и др. Описываются приёмы их применения.

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

Я — Максим Гришутин, Product Platform Lead в Okko. Более семи лет работаю лидом и развиваю команды, которые хотят не только делать хорошие проекты, но и быть услышанными.

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

У каждого системного администратора должен быть набор программных решений для практически любой ситуации — некая серверная аптечка первой помощи. В статье собрал базовый минимум ПО для «лечения» основных болезней серверов на Linux и Windows.

В этой статье речь пойдет о добавлении в С++ приложение функционала сохранения данных в формате YAML с использованием библиотеки yaml-cpp. Мы подробно рассмотрим какие возможности для этого предоставляет библиотека и на какие подводные камни можно наткнуться в процессе ее использования.

Особое внимание будет уделено вопросам форматирования(и представления) выходного YAML-текста, поскольку это влияет как на восприятие конечного YAML-документа человеком, так и на совместимость с другими программами, парсеры которых могут хуже поддерживать спецификации YAML.

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

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

Установив, что мы подразумеваем под объектом исследования: Организация производства ИС, продолжим разбирать формализованные варианты построения ЖЦ и экосистемы, поддерживающей его.

Начнем с определений.

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

Управление ИТ-производством – это организация и координация всех процессов, связанных с выпуском ИТ-продукта или оказанием услуг.  Это не управление проектами в классическом смысле. Это управление потоком создания ценности в высокодинамичной, сложной системе, где Сырьем являются идеи, а Продукцией — измеримая ценность для бизнеса.

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

Реклама - это лишь симптом более серьёзной проблемы

На этой неделе OpenAI объявила, что начнёт тестировать рекламу в бесплатной версии ChatGPT. Это означает, что если я плачу - я в безопасности. Это также означает, что меня заставляют платить, чтобы быть в безопасности. Это также означает, что если я не могу или не хочу платить, инструмент, который я использовал в качестве помощника три года, будет заботиться о чужих интересах прежде моих.

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

Мне надоело, что автоматические переключатели в Punto срабатывают не там, где нужно, а «умные» исправления ломают пароли. Поэтому я давно использовал только функцию переключения раскладки выделенного текста, остальное выключал в настройках. Перегруженность и тормознутость, в целом, долго и успешно терпел. Но после попытки скачать Punto, в очередной раз, с официального сайта, антивирус не дал этого сделать и сказал, что там вирус. Это было последней каплей, пробежавшись по аналогам, я взгрустнул и решил написать свою утилиту на AutoHotkey v2, которая делает только одну вещь: исправляет выделенный текст по горячей клавише, циклически переключая его между установленными в системе раскладками.

Математические гении из канала Numberphile возродили древний алгоритм умножения, известный как «уполовинить и удвоить», «крестьянская математика», «египетская математика» или, как его описывает ведущий математического блога Джонни Болл, «русское умножение».

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

Вы запустили рекламную кампанию. Потратили 100 000 рублей, получили 500 кликов и 20 заявок. Хорошо это или плохо? Не знаете? Я тоже не знаю. Потому что непонятно — совпадает ли это количество с ожидаемым и удовлетворяет ли нас стоимость одного лида.
Запуск РК без планирования это черный ящик. Результат вы получите, но понять хороший он или плохой не сможете.
Добрый день! Меня зовут Игорь. Я практикующий продуктовый маркетолог в Product Unit.
В этом гайде таблица и методология – как спланировать и запустить РК как эксперт

Разбираем, что такое PNETLab, как он работает и чем отличается от других сетевых эмуляторов. Простое объяснение для инженеров, администраторов и студентов.

В данной статье хочется поделиться личным опытом решения ряда проблем в подготовке специалистов технических специальностей, начиная с 1999 года когда сам был студентом, 2007 годом когда был преподавателем и сейчас, когда оснащаю учебные центры крупных компаний.

В далеком 2007 году, после защиты кандидатской диссертации два года преподавал дисциплину «Гидравлические машины и компрессоры» для студентов направления подготовки 21.03.01 «Нефтегазовое дело» (в т.ч. вел и лабораторные работы). Также работал в те годы в НИИ Электронных образовательных ресурсов (НИИ ЭОР ТюмГНГУ) Тюменского нефтегазового университета.

«Гидромашины и компрессоры» в качестве конкретного примера я выбрал именно по причине наличия личного опыта как обучения этой дисциплине так и ее преподавания.

Встреча с одним моим старым другом, имеющим собственный логистический бизнес, напомнила мне о том, что руководители привыкли размышлять масштабными величинами, например — «склад» и «транспорт». То, что между ними есть еще целый ряд других систем, подчас оказывается сюрпризом. 

Именно в разговоре с ним я в очередной раз убедился, как недооцененное управление двором (YMS) становится «слепой зоной» даже для опытных руководителей. Давайте разберемся, почему эта система — не просто удобный инструмент, а фундамент эффективной логистики.

По результатам проведенного LogistiX в 2025 году опроса, из 380 компаний (Российская Федерация), которые запланировали автоматизацию склада, только 32 компании имели систему управления двором, и 80 компаний предполагали ее установить в будущем. Это приводит нас к тому, что более 70% компаний из этой выборки теряют десятки миллионов рублей в год, даже не имея плана, как исправить эту ситуацию.

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

Это явление давно известно в архитектуре вычислительных систем как разрыв между процессором и памятью (или Memory Wall). Сегодня он определяет производительность серверов, баз данных, платформ данных и AI/ML-платформ сильнее, чем выбор конкретной модели процессора или видеокарты. А в будущем определит то, какие продукты и решения индустрия будет использовать для решения задачи хранения данных.

Привет! Я Александр Гришин, руководитель по развитию продуктов хранения данных в Selectel. В этой статье я попробую подробно разобрать, что такое этот ваш разрыв между процессором и памятью, как он сформировался, как устроена иерархия памяти в сервере и почему эти ограничения подталкивают индустрию к новым архитектурам и решениям. Погнали!

К середине 80х рынок 8-битных ПК типа Commodore 64 и ZX Spectrum достиг насыщения. Новые задачи (современная графика, плавная анимация в играх, софт для бизнеса, «взрослая» компьютерная музыка) уже не укладывались в их возможности.

Ответом на вызов стали две «машинки», ставшие символами новой эпохи — Commodore Amiga и Atari ST. Это прямо quantum leap (но не от Синклера), который похоронил собственных 8-битных предков. 

В этой истории главный парадокс в том, что технологическую революцию сделали именно Commodore и Atari, но оба бренда упустили массовый сегмент, и уступили место «серому ящику» от IBM.

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

Загадка: во сколько раз увеличится RPS на ручку поллинга, если уменьшить интервал поллинга с 5 минут до 2? 

Ответ: в 2,5 раза!

Привет! Меня зовут Стёпа, и я разработчик в Яндекс Go. Я хочу поделиться тем, как математика может встречаться в самых неожиданных местах — даже в такой рутинной задаче, как настройка интервала поллинга. В статье я рассмотрю модельный пример, который встречался каждому разработчику, и просчитаю его с математической точки зрения, использовав базовые факты из теории вероятностей и статистики.

Современные комплексы бизнес-приложений отличаются высокой сложностью, из-за чего могут происходить сбои - сообщения теряются, consumer’ы падают, очереди переполняются. Поделимся реальным кейсом, в котором Eventual Consistency удалось обеспечить без серьезной переработки существующих систем.

Обеспечение Eventual Consistency в сложных системах

Уже давно стандартом де-факто стали микросервисы, поэтому практически любая система представляет собой набор компонентов, взаимодействующих между собой как синхронно (например, по REST), так и асинхронно — через шины сообщений (RabbitMQ, Kafka).

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

Где именно все может сломаться

Предположим, у нас две системы: