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

​💸 А вот и пост про деньги и московскую недвижимость

​На днях знакомый из крупной компании рассказал историю. Им пришла корпоративная рассылка с «уникальным спецпредложением» для сотрудников — купить квартиры в ЖК рядом с московским офисом.

​Смотрим на «скидки» для самого дешёвого варианта:
• 27 кв. м с черновой отделкой (даже стены не выровнены) — 27 млн рублей 😱
• Те же 27 кв. м, но с предчистовой — 33 млн рублей
​Несложная математика показывает, что выравнивание стен на 27 квадратах обошлось застройщику в 6 млн рублей.
Отсюда логичный вопрос: в какую бригаду записаться, чтобы выравнивать стены по 222 тысячи за метр? 😂
​Чем больше метраж, тем веселее — в среднем выходит по 1 млн рублей за квадрат.

​И вот кому в компании адресована эта рассылка? Точно не мидлам, не синьорам и даже не архитекторам. СТО (Chief technical officer)? Ну, может, на однушку и наскребет.

​Как по мне, присылать такие «эксклюзивные предложения» рядовым сотрудникам — это форменное издевательство.
​Как вам «спецусловия»? Встречали подобные рассылки у себя в компаниях? 👇

Младшие аналитики, принесли вам классный пост, как в компании оценивают скиллы действующие специалисты RWB

С аналитиков по лайку 🌹

Дошли руки до «Руководства по DevOps» 📖
​Честно говоря, по названию ждал сугубо техническую методичку. На деле же львиная доля книги посвящена организационным практикам. Очень четко прослеживается связь с идеями из книги «Цель».
​Что касается технической части — там разобраны базовые практики для повышения скорости и надежности релизов, причём с разбором реальных кейсов гигантов индустрии.

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

​Главный плюс — книга написана просто. Чтобы вникнуть, не нужно быть senior-инженером. Рекомендую!

Всем привет!
Автор вернулся и привёз с собой вагон новостей!
Летом отдыхал от ведения канала. Надеюсь, вы успели соскучиться.
Рассказываю про прошедшие события:

↔️ Сменил проект на работе на более важный. Важность проекта определил менеджмент.

🔃 Поменялись процессы и составы команд, так что теперь я не только аналитик, но ещё и лидирую команду разработки на шесть человек.

🌴 Целых два раза съездили с женой в отпуск, всем рекомендую.

🎊 Был на корпоративе в Красной Поляне без малого неделю. Всё прекрасно, но без проблем не обошлось: аэропорт закрыли, поэтому добираться домой было достаточно проблематично.

🏍 Открыл для себя новую нишу - мотоцикл! Обучение прошёл успешно, а вот экзамен... в другой раз.

⛽️ Научился проверять качество бензина на заправке на цвет, запах и вкус. Если что, обращайтесь.

🏴󠁧󠁢󠁥󠁮󠁧󠁿 I was actively studying English, you know.

📚 Прочитал много профильных книг, о которых расскажу вам в следующих постах.

Надеюсь, ваше лето тоже было богатым на события!

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

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

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

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

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

User story по учебнику:
Как [роль],
Я хочу [действие],
Чтобы [ценность].

С чем надо уметь работать:
Как [все],
Я хочу [всё],
Чтобы [было круто].

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

Простая аналогия, представьте, что работаете с 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 — это не «иди прочь».
Это «приходи чуть позже — и всё получится» 🤝