SA: Между бизнесом и реальностью

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

Простая аналогия - навигатор
Идеальный сценарий:
- Навигатор получает данные о пробках в реальном времени
- Показывает оптимальный маршрут с учётом аварий, ремонтов дорог и плотности трафика
- Перестраивает маршрут динамически, если ситуация меняется
Fallback (Когда что-то пошло не так):
- Потеряно соединение с интернетом →
- Навигатор показывает сохранённую карту и базовый маршрут без учёта пробок
- Да, вы можете попасть в затор, но вы хотя бы доедете до точки назначения.

Как это работает?
Обычно работает в связке с Circuit Breaker и Timeout:
1. Делаем запрос к основному сервису (например, к сервису рекомендаций).
2. Если ответ не пришел за 500мс (Timeout) или пришла ошибка...
3. ...включаем Fallback:
- Берем данные из локального кэша.
- Показываем статический список ("Популярное").
- Возвращаем значение по умолчанию.

Когда ПРИМЕНИМО?
✅ Нужна высокая доступность (High Availability)
→ Сайт должен работать всегда, даже если часть функций отвалилась.
✅ Допустима неактуальность данных
→ Лучше показать цену товара часовой давности, чем ошибку "503".
✅ Грейсфул деградация (Graceful Degradation)
→ Мы не "рушим" весь сайт из-за падения виджета с погодой.
✅ Пиковые нагрузки
→ Если основной сервис не справляется, включаем упрощенный режим.
Когда НЕ ПРИМЕНИМО?
❌ Критичные финансовые операции
→ Нельзя возвращать "фейковый" баланс или "успешную оплату", если она не прошла.
❌ Данные должны быть строго актуальными
→ В медицинских системах или системах бронирования "старые данные" могут стоить здоровья или денег.
❌ Пользователь должен знать о проблеме
→ Иногда лучше честно сказать "Сервис недоступен", чем врать, что всё ок.

Мораль:
Идеальный сервис — это мечта.
Работающий сервис — это реальность.
Fallback Pattern учит нас тому, что иногда лучше дать "кое-что", чем не дать ничего.
Главное — чтобы "кое-что" не было ошибкой. 😎

Оптимистичная блокировка - подход, при котором мы не блокируем данные, а просто проверяем, не изменил ли их кто-то другой перед сохранением.

Простая аналогия, представьте, что работаете с Git:
1. Вы создаёте ветку → делаете коммиты → нажимаете git push
2. А кто-то другой уже запушил изменения в main
3. Git говорит: «Конфликт! Сделайте pull и смержите»
4. Вы подтягиваете изменения, разрешаете конфликт → пушите снова ✅

Как это работает в БД:

-- 1. Читаем данные + версию
SELECT balance, version FROM accounts WHERE id = 123;
-- Получаем: balance=100, version=5

-- 2. Меняем у себя в коде
new_balance = 150
new_version = 6

-- 3. Пытаемся сохранить с проверкой версии
UPDATE accounts
SET balance = 150, version = 6
WHERE id = 123 AND version = 5;

-- Если обновлено 0 строк → КОНФЛИКТ! Начинаем с начала
-- Кто-то уже сохранил version=6

Когда применимо:
- Ожидаются редкие конфликты
- Пользователь думает минуты между чтением и сохранением
- Можно откатить транзакцию и начать заново
- Изменяется ограниченный набор строк

Мораль:
Блокировка данных — это дорого.
Конфликт версий — это дёшево.
Оптимистичная блокировка выбирает дешёвый путь, пока он работает.

Блокировки в БД

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

Простая аналогия:
Представьте общественный туалет:
Когда кто-то внутри — дверь закрыта на замок (exclusive lock)
Остальные ждут в очереди
Никто не может зайти, пока первый не выйдет
Зачем нужны?
Без блокировок:
→ Два человека одновременно меняют баланс счёта
→ Первый: баланс = 100
→ Второй: баланс = 200
→ Результат: кто последний — тот и прав
→ Деньги потерялись 💸
С блокировками:
→ Первый заблокировал запись → поменял → отпустил
→ Второй получил доступ → поменял → отпустил
→ Всё честно ✅

Типы блокировок:
Shared: Многие могут читать, но никто не пишет
Exclusive:
Только один пишет, остальные ждут
Intent: «Я планирую заблокировать часть таблицы»

Проблемы:
1. Блокировки (Locks)
→ Один процесс держит данные
→ Остальные ждут
→ Решение: делать транзакции короткими
2. Взаимная блокировка (Deadlock)
→ Процесс A держит X, хочет Y
→ Процесс B держит Y, хочет X
→ Оба ждут вечно
→ Решение: БД убивает одну из транзакций (rollback)

Как избежать проблем?
✅ Делать транзакции короткими
✅ Блокировать минимум данных
✅ Обращаться к таблицам в одинаковом порядке
✅ Использовать оптимистичные блокировки (версионирование)
✅ Настраивать таймауты на ожидание

Мораль:
Блокировки — это как очередь в туалет.
Неприятно ждать, но без очереди будет хуже 😅

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

Что в программе? Разбираем детально:
🔹 Максим Смирнов — «Навыки архитектурных решений»
Поговорим о фундаменте: как системно подходить к принятию решений, которые не придется переделывать через полгода.
🔹 Прохоров Николай — «Быстрый старт для создания ИИ-ассистента»
Практический гайд по внедрению LLM в кодовую базу организации. Узнайте, как заставить ИИ помогать в исследовании ваших приложений.
🔹 Ирина Орлова — «Надёжная шина данных на Apache Kafka»
Разберем нюансы асинхронного обмена сообщениями и построение отказоустойчивых систем на базе Kafka.
🔹 Дмитрий Курило — «От таблиц к графам»
Новый взгляд на анализ отраслевого рынка. Почему графовые модели эффективнее привычных таблиц для выявления скрытых связей.
🔹 Шутова Елена — «От монолога к модели»
Как с помощью правильных вопросов и методологии Event Storming избежать бесконечных правок и сразу строить то, что нужно бизнесу.
🔹 Хайдаров Ильназ — «Стандартизация API: от хаоса к качеству»
Методика для тех, кто устал от зоопарка интерфейсов. Как внедрить единые стандарты и измерить их эффективность.
🔹 Калинина Софья — «От промпта к прототипу»
Валидация требований на ранних этапах. Как современные инструменты помогают проверить гипотезы еще до написания первой строчки кода.
🔹 Бурмистров Владимир — «Privacy by Design для аналитика»
Проектирование систем с учетом конфиденциальности данных. Как аналитику учитывать требования безопасности с самого начала проектирования.

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

Регистрация здесь

Специально для участников нашей группы организаторы дали промокод на скидку 20% на полный доступ - ZA20_AM17

Прочитал книгу "Искусство системного мышления". Есть мнение, что системное мышление обязательно для аналитика, и я с этим полностью согласен. Однако, книгу по такой теме я прочитал впервые.

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

Что касается содержания: книга предлагает множество практических концепций, которые напрямую применимы как в работе аналитика, так и в повседневных решениях. Однако, для меня она не стала откровением — все описанные принципы я уже встречал в статьях, учебных материалах, на практике и в других изданиях (например, в «Цели» Голдратта или «Думай медленно, решай быстро» Канемана). Пожалуй, это первое издание по теме, которое не расширило мой кругозор (но и плохой книгой назвать его не могу).

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

Rate limiting (ограничение частоты запросов) - Механизм, который контролирует, как часто клиент может обращаться к сервису.

Как работает?
Задаём лимит:
→ 100 запросов в минуту с одного IP
→ 10 запросов в секунду на пользователя
→ 1000 в час на весь API-ключ
Считаем запросы:
→ Каждое обращение увеличивает счётчик
→ Счётчик сбрасывается по таймеру (окно времени)
Принимаем решение:
✅ В лимите → обрабатываем запрос
❌ Превысил → возвращаем 429 Too Many Requests + заголовок Retry-After: 30
Зачем нужен?
✅ Защищает от перегрузки
Не даёт одному клиенту «положить» сервис для всех
✅ Предотвращает атаки
Brute-force, DDoS, скрейпинг — получают вежливый отпор
✅ Честное распределение ресурсов
Все пользователи получают равный доступ
✅ Экономит деньги
Меньше лишних запросов → меньше нагрузка → меньше счёт за облако
✅ Даёт обратную связь
Заголовок Retry-After подсказывает, когда можно попробовать снова
Пример из жизни:
Без Rate Limiting:
Бот отправляет 10 000 запросов в секунду →
База данных захлёбывается →
Реальные пользователи видят «503 Service Unavailable»
С Rate Limiting:
Бот получает 429 после 100-го запроса →
Остальные пользователи работают нормально →
Бот учится делать паузы (или уходит к конкурентам)

Мораль:
429 — это не «иди прочь».
Это «приходи чуть позже — и всё получится» 🤝

Паттерн Circuit Breaker — Когда сервис упал, а ты просто перестал его вызывать.

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

Как работает?
Три состояния:
CLOSED (Закрыт) — нормальная работа
→ Вызовы идут к сервису
→ Считаем ошибки
OPEN (Открыт) — сервис упал
→ Блокируем все вызовы (не мучаем упавший сервис)
→ Возвращаем ошибку или fallback
→ Ждём 30-60 секунд
HALF-OPEN (Полуоткрыт) — проверка
→ Пробуем один вызов
→ Успех → CLOSED
→ Ошибка → OPEN (снова ждём)

Зачем нужен?
✅ Защищает от каскадных сбое
Один сервис упал → не тянет за собой всю систему
✅ Экономит ресурсы
Не тратим время на таймауты и повторные вызовы
✅ Даёт время на восстановление
Сервис может перезагрузиться без нагрузки
✅ Graceful degradation
Показываем кэш или заглушку вместо ошибки

Пример из жизни:
Без Circuit Breaker:
Платёжный сервис упал → 1000 запросов в секунду получают timeout →
База данных перегружена → Весь сайт лёг
С Circuit Breaker:
Платёжный сервис упал → После 5 ошибок сработал выключатель →
Показываем «Оплата временно недоступна» →
Через 30 секунд пробуем снова → Всё работает

CQRS — это паттерн разделения операций записи и чтения данных.
Команды (Commands): Только меняют данные (создать, обновить, удалить).
Запросы (Queries): Только читают данные (получить информацию).
Суть: Вместо одной модели для всего используются две разные. Это позволяет независимо оптимизировать производительность для записи и для чтения, так как нагрузка на них обычно неравномерна (например, читают чаще, чем пишут).

Есть такой паттерн реализации распределённой транзакции (когда нужно выполнить какие-то действия транзакционно в нескольких разных сервисах) - Saga. В случае если один из сервисов не смог завершить у себя транзакцию - он отправляет другим сервисам компенсирующие действия (либо можно завести оркестратор).

Сценарий:
Вы решили жениться.
Шаг 1: Забронировали ресторан ✅
Шаг 2: Разослали приглашения ✅
Шаг 3: Заказали кольца → отправили в Kafka-топик «wedding.rings»…
…но сообщение потерялось (consumer упал, offset сбился, продюсер не дождался ack).

Что делать?
В мире транзакций — откат всего. Но в распределённой системе отката нет.
Зато есть компенсирующие действия:
Отменить бронь ресторана;
Отправить гостям «свадьба отменяется»;
Вернуть депозит за торт;
Это и есть Saga Pattern: цепочка локальных транзакций + набор «отмен», если что-то пошло не так.

Мораль:
В микросервисах нельзя просто «нажать Ctrl+Z».
Но можно аккуратно развестись до свадьбы — автоматически.

Рубрика "Простыми словами о сложном":

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

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

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

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

Ещё немного про книги.

Когда я учился в магистратуре, у меня был предмет Data Management, а учебником по этому предмету была книга DAMA DMBOK (Data Management Body of Knowledge) - свод знаний по управлению данными.

Важная ремарка: существует множество других сводов знаний, например, PMBOK (проекты), BABOK (бизнес-аналитика), SWEBOK (программная инженерия). Если интересуетесь какой-то из этих сфер, то рекомендую ознакомиться с соответствующим сводом.

DMBOK описывает 11 ключевых областей управления данными, которые перечислены на колесе выше, включая центр.

Будет полезна для понимания стандартов работы с данными, выравнивания с бизнесом. Как основа для архитектуры решений и для ознакомления с лучшими практиками по управлению данными. С точки зрения системного аналитика, я бы рекомендовал её синьорам либо аналитикам, которые работают на проектах, связанных с мастер-данными в компании (MDM, справочники, etc).

Более практичны примеры, с которыми может помочь книга: как повысить качество данных и при этом снизить их объём, как получать больше бизнес-пользы из данных...

Важно понимать, что эта книга - лишь набор лучших практик, которые нужно адаптировать под контекст своей компании. На моём позапрошлом месте работы решили внедрить описанные практики бездумно. Нововведения в компании отлично читались, из каких глав книги они взяты. Однако, это не дало никакого результата. Пример причины провала: ввели роль дата-офицера и наняли новых людей на эту роль, закрепили их за разными командами (примерно 1 на 10 команд), но нанятые люди не смогли настроить коммуникации между собой и сформировать единое видение своей роли, при этом явно было видно, что многие из них ни про какой Data Management ранее не слышали и могли не глядя ставить согласование на артефактах решений...

В магистратуре мы изучили только пару глав из этой книги. А она большая - страниц 800. Позднее я прочитал ещё примерно чуть больше половины книги. Далее я переключился на более интересные в моменте книги, но и DMBOK обязательно когда-нибудь дочитаю до конца.

Мем про eventual consistency (согласованность в конечном счёте) - модель согласованности данных в распределённых системах для обеспечения высокой доступности. Подразумевается, что через какой-то промежуток времени (в конечном счёте), все изменения в данных будут гарантированно применены, но возможно с некоторой задержкой (асинхронно).

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

Как объяснить eventual consistency нетехническому заказчику. (Ниже конечно шутка и такое говорить не надо)
Представьте, вы отправили СМС другу: "Иду к тебе!".
Он не видит это сообщение сразу - телефон разряжен.
Через час он заряжает телефон - видит СМС - но вас уже нет у него дома. Это eventual consistency: сообщение дошло... но слишком поздно

Прочитал ещё одну книгу - "Думай медленно, решай быстро" в русскоязычном переводе.

Главная идея книги в том, что человеческое мышление состоит из двух систем:
первой - быстрой, которая фактически принимает большинство решений в жизни, но эти решения не всегда обдуманны;
и второй - которая способна мыслить логически, но её трудно активировать и иногда на неё может влиять первая система.

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

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

Пример из книги. В какую игру вы скорее сыграете:
1. 10% шанс выиграть 95$ и с вероятностью 90% проиграть 5$;
2. заплатить 5$ за участие в лотерее, в которой есть 10%-ная вероятность выиграть 100$ и 90%-ная вероятность не выиграть ничего.
Математически это одна и та же игра, но подавляющее большинство людей выбирает вторую, потому что такая формулировка кажется более безопасной.

Может ли эта книга быть полезной в работе системного аналитика или другого технаря - вряд ли. Но может быть полезной для менеджера или просто для развития личной осознанности.

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

Аналитик:
- Пользователь ожидает телепатическую интеграцию с MVP, построенную на воздухе и надежде

Разработчик:
import magic.core;