Please open Telegram to view this post
VIEW IN TELEGRAM
В этой папке собраны каналы про медицину, которые помогают быстрее разобраться в сфере, находить идеи и экономить время на поиске информации.
Please open Telegram to view this post
VIEW IN TELEGRAM
4860. На проекте требования меняются каждую неделю. Команда тратит время на переделки. Какой инструмент аналитик должен применить для контроля изменений?
Anonymous Quiz
6%
Фиксировать все изменения в протоколе встреч
85%
Внедрить процесс управления изменениями (Change Request)
1%
Еженедельно пересматривать приоритеты задач
9%
Использовать матрицу трассируемости требований
Что такое процесс управления изменениями (Change Request)?
Это формальная процедура, которая состоит из шагов:
Запрос на изменение (Change Request, CR) – любой стейкхолдер заполняет форму: описывает изменение, обоснование (почему это важно), ожидаемую бизнес-ценность.
Оценка – аналитик вместе с разработчиками оценивает трудозатраты, влияние на другие модули, риски, необходимость изменений в документации и тестах.
Рассмотрение на Change Control Board (CCB) – встреча с участием заказчика, продукт-оунера, технического лида. Принимается решение: принять, отклонить, отложить. Если принимается, то определяется, за счёт каких задач это будет сделано (вытеснение других задач, сдвиг сроков).
Коммуникация – решение доводится до всей команды, обновляются требования и бэклог.
Реализация – изменение попадает в разработку уже с понятным приоритетом.
Почему остальные варианты не решают проблему?
A (фиксировать в протоколе) – полезно, но не даёт оценки трудозатрат и приоритизации. Команда всё равно вынуждена реагировать на каждое изменение «по факту».
C (еженедельный пересмотр приоритетов) – хорошая практика, но без формального CR изменения могут быть неполными, неоценёнными или незадокументированными.
D (матрица трассируемости) – помогает понять, какие артефакты связаны с требованием, но не управляет потоком изменений.
Реальный кейс из практики:
В одном проекте по разработке CRM для сети салонов связи изменения поступали ежедневно. Аналитик просто передавал их в бэклог, команда хваталась за то, что «горело». В результате через месяц половина фич была недоделана, а релиз сдвинулся на три недели. Ввели Change Request Board из трёх человек (заказчик, аналитик, тимлид). Заказчик заполнял CR-форму (описание, ценность). На ежедневной 15-минутной встрече оценивали влияние. Если оценка превышала 8 часов, вопрос выносили на еженедельное заседание. Через месяц количество несогласованных правок сократилось на 80%, а команда стала прогнозировать сроки.
Что должен зафиксировать аналитик:
В регламенте проекта: «Любое изменение требований после утверждения бэклога оформляется через Change Request и проходит оценку».
Форма CR должна содержать поля: автор, описание, обоснование (ожидаемый эффект), приоритет для бизнеса.
Порог принятия: например, изменения до 4 часов может утвердить PO, более 4 часов – CCB.
Вывод: Управление изменениями – это не бюрократия, а способ сохранить предсказуемость разработки и снизить хаос. Аналитик выступает не врагом изменений, а их фильтром и координатором.
Please open Telegram to view this post
VIEW IN TELEGRAM
НЕБОЛЬШОЙ АПГРЕЙД ТВОЕЙ ЛЕНТЫ, КОТОРЫЙ ДАСТ ХОРОШИЙ БУСТ ТВОЕЙ КАРЬЕРЕ
Друзья, наш канал попал в подборку тг-каналов про AI & IT, технологии и карьеру — получилась тусовка «для своих» 😎
Мы собрали каналы для себя, которые реально полезны:
➕ следить за ИИ — от свежих инструментов до реальных кейсов
➕ разбираться в технологиях — тренды, обзоры и объяснения
➕ расти в IT — советы по карьере, поиску работы и развитию
➕ быть в теме HR Tech — как технологии меняют найм и управление, ИИ для удаленки и работы за рубежом
🆒 Осталось только добавить папку себе ✔️https://t.me/addlist/iy6id2ElW_hiNTg0
Друзья, наш канал попал в подборку тг-каналов про AI & IT, технологии и карьеру — получилась тусовка «для своих» 😎
Мы собрали каналы для себя, которые реально полезны:
➕ следить за ИИ — от свежих инструментов до реальных кейсов
➕ разбираться в технологиях — тренды, обзоры и объяснения
➕ расти в IT — советы по карьере, поиску работы и развитию
➕ быть в теме HR Tech — как технологии меняют найм и управление, ИИ для удаленки и работы за рубежом
🆒 Осталось только добавить папку себе ✔️https://t.me/addlist/iy6id2ElW_hiNTg0
👍1🔥1
4861. В таблице «Клиенты» нет первичного ключа, но есть дубли по полям (ФИО, email, телефон). Как найти все дублирующиеся записи?
Anonymous Quiz
15%
Использовать оконную функцию ROW_NUMBER() с PARTITION BY
22%
Создать временную таблицу с уникальными записями
62%
Применить GROUP BY и HAVING COUNT(*) > 1
2%
Добавить автогенерируемый первичный ключ
ididЧто делает ROW_NUMBER()?
Оконная функция
ROW_NUMBER()PARTITION BYORDER BYidПример запроса:
sql
WITH ranked AS (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY fio, email, phone ORDER BY id) AS rn
FROM clients
)
SELECT * FROM ranked WHERE rn > 1;
Если таблица не имеет поля
idORDER BY (SELECT NULL)Почему другие варианты не подходят:
C (GROUP BY + HAVING) – покажет, какие комбинации полей встречаются более одного раза, но не выдаст сами записи. Например, вы узнаете, что (Иванов,
B (временная таблица) – технически можно: вставить уникальные записи во временную таблицу, потом сравнить. Но это громоздкий и медленный способ, особенно для больших объёмов.
D (добавить PK) – автогенерируемый ключ не найдёт существующие дубли. Он только предотвратит новые дубли, если добавить уникальное ограничение.
Реальный кейс:
В одной компании при миграции из старой CRM в новую выяснилось, что в таблице
customersROW_NUMBER()Что должен зафиксировать аналитик в требованиях к качеству данных:
«Периодически проводить проверку на дубли по критическим полям с использованием оконных функций».
«Результаты проверки должны включать все дублирующиеся строки, а не только комбинации полей».
Вывод: Для выявления полных дубликатов записей (а не просто факта дублирования) оконная функция
ROW_NUMBER()Please open Telegram to view this post
VIEW IN TELEGRAM
4862. Два сервиса должны обмениваться данными. Если сервис-получатель временно недоступен, данные теряются. Какой тип взаимодействия выбрать?
Anonymous Quiz
5%
Синхронный REST-вызов с повторными попытками
89%
Асинхронная очередь с гарантированной доставкой
2%
Периодическая синхронизация по расписанию
4%
Общая база данных для обмена
IT-сфера снова переживает бурные времена. AI-технологии влияют на классические подходы, а компании, которые не успевают адаптироваться - теряют позиции. В этой ситуации решает не количество информации, а её качество.
Мы собрали папку каналов для тех, кто не просто «следит за трендами», а реально работает с цифрами, тестирует AI инструменты и адаптирует свои процессы под новые реалии.
Только практические советы и реальные кейсы👇🏻
Сохранить папку 📨
Доступно 48 часов❗️
Мы собрали папку каналов для тех, кто не просто «следит за трендами», а реально работает с цифрами, тестирует AI инструменты и адаптирует свои процессы под новые реалии.
Только практические советы и реальные кейсы👇🏻
Сохранить папку 📨
Доступно 48 часов❗️
Как асинхронная очередь решает проблему
Брокер сообщений (RabbitMQ, Kafka, Amazon SQS) действует как надёжный буфер:
Сервис A отправляет сообщение в очередь и не ждёт ответа (асинхронно).
Если сервис B недоступен, сообщение остаётся в очереди.
Очередь хранит сообщения на диске (персистентность), поэтому даже перезапуск брокера не удалит их.
Когда B восстанавливается, он забирает все накопившиеся сообщения и обрабатывает их.
Гарантируется доставка «хотя бы один раз» (at‑least‑once), а при правильной настройке – идемпотентная обработка.
Почему другие варианты не подходят:
A (синхронный REST + ретраи) – ретраи помогают при кратковременных сбоях (секунды), но при длительной недоступности (часы) данные теряются. Кроме того, ретраи могут создать дополнительную нагрузку на восстанавливающийся сервис (эффект «retry storm»).
C (периодическая синхронизация) – например, раз в час. За это время данные могут устареть, а при сбое в момент передачи всё равно возможна потеря. Не подходит для интерактивных сценариев.
D (общая БД) – антипаттерн в микросервисной архитектуре: сервисы начинают зависеть от схемы данных друг друга, теряется независимость, сложно эволюционировать
Реальный кейс из практики:
Сервис заказов интернет-магазина должен был отправлять данные в CRM. Изначально использовали синхронный REST. При падении CRM на 10 минут 200 заказов не попали в CRM, и менеджеры не видели их. После перехода на RabbitMQ заказы публиковались в очередь. При сбое CRM сообщения накапливались в очереди (до 10 000 за час). После восстановления CRM обработала все заказы за несколько минут. Потери данных были исключены.
Что должен зафиксировать аналитик в требованиях:
«Взаимодействие между сервисами при не критическом ко времени отклика сценарии должно быть асинхронным через брокер сообщений».
«Очередь должна быть персистентной (сохранение на диск) и реплицированной для отказоустойчивости».
«Потребитель должен быть идемпотентным, чтобы при повторах не создавать дубли».
Вывод: Выбор между синхронным и асинхронным взаимодействием – это компромисс между простотой и надёжностью. Для критичных данных, которые нельзя терять, и при допустимой задержке асинхронная очередь – единственно правильное архитектурное решение.
Please open Telegram to view this post
VIEW IN TELEGRAM
4863. Распределённая система должна гарантировать, что все узлы видят одни и те же данные в любой момент времени и оставаться доступной даже при сбоях. При сетевом разделении система перестаёт принимать запись. Какую теорему иллюстрирует этот пример?
Anonymous Quiz
13%
Теорема Геделя о неполноте
63%
CAP-теорема Брюера
10%
Закон Амдала о распараллеливании
15%
Теорема Коуза о трансакционных издержках
В 2000 году профессор Эрик Брюер сформулировал, что в распределённой системе (данные хранятся на нескольких узлах) невозможно одновременно гарантировать все три свойства:
Consistency (C) – строгая согласованность: после успешной записи все последующие чтения видят эту запись (нет устаревших данных).
Availability (A) – доступность: каждый запрос получает ответ (даже если часть узлов недоступна).
Partition tolerance (P) – устойчивость к сетевым разделениям: система продолжает работать, когда связь между узлами нарушена.
При сетевом разделении (например, кабель между дата-центрами оборван) система вынуждена выбирать между C и A.
Если выбираем CP (согласованность + устойчивость к разделениям), то при разделении блокируем запись, чтобы не нарушить согласованность. Доступность падает: некоторые запросы не получают ответа.
Если выбираем AP (доступность + устойчивость к разделениям), то разрешаем запись в каждый раздел независимо, но потом данные могут расходиться (согласованность нарушена).
Почему пример иллюстрирует CAP?
В задаче сказано: система должна быть строго согласованной и доступной. При сетевом разделении она перестаёт принимать запись. Это значит, что система жертвует доступностью для сохранения согласованности. То есть система выбрала CP. CAP-теорема объясняет, почему невозможно иметь и то, и другое одновременно.
Разбор других вариантов:
A (теорема Геделя) – о неполноте формальных систем, к распределённым БД не относится.
C (закон Амдала) – о максимальном ускорении при распараллеливании, не про согласованность.
D (теорема Коуза) – экономическая, о трансакционных издержках.
Реальный пример из практики:
Банковская система (CP) – при разделении между офисами временно запрещает списания, чтобы не возникло отрицательного баланса. Доступность снижена, но деньги в безопасности.
Социальная сеть (AP) – при разделении дата-центров вы всё равно можете поставить лайк (доступность), но счётчик лайков может временно расходиться (eventual consistency).
Что должен зафиксировать аналитик:
В требованиях к распределённой системе явно указать, что важнее: строгая согласованность или доступность.
Например: «В системе управления запасами товара допустима задержка репликации не более 5 секунд, но запись товара должна быть всегда доступна (AP)» или «Платёжная система должна быть строго согласованной (CP)».
Вывод: CAP-теорема – фундаментальное ограничение, которое аналитик обязан понимать при проектировании распределённых систем. Нельзя попросить «идеальную систему», нужно выбирать компромисс.
Please open Telegram to view this post
VIEW IN TELEGRAM
4864. В очереди RabbitMQ сообщения поступают быстрее, чем потребитель успевает их обрабатывать. Со временем очередь растёт, задержка обработки увеличивается. Как называется эта проблема и как её решить?
Anonymous Quiz
8%
Retry storm – увеличить количество реплик
80%
Consumer lag – добавить параллельных потребителей или увеличить их количество
5%
Deadlock – переключиться на синхронные вызовы
7%
Split brain – использовать экспоненциальный бэккофф
Это разница между смещением последнего сообщения в очереди и смещением, которое уже обработал потребитель. Если сообщения приходят быстрее, чем обрабатываются, очередь растёт, и задержка доставки (латентность) увеличивается. Например, очередь растёт на 100 сообщений в секунду, через час в ней будет 360 000 необработанных сообщений, а новое сообщение будет ждать обработки часы.
Причины consumer lag:
Медленная бизнес-логика (тяжёлые запросы в БД, вызовы внешних API).
Недостаточное количество потребителей (один consumer на много партиций).
Сетевые задержки или блокировки.
Как решить:
Увеличить количество параллельных потребителей (в RabbitMQ – добавить экземпляры приложения, слушающие ту же очередь; в Kafka – увеличить число consumer’ов в группе, но не больше числа партиций).
Оптимизировать обработку – асинхронные вызовы, пакетная обработка (batch), распараллеливание внутри потребителя.
Использовать flow control – если потребитель не успевает, можно временно приостановить чтение.
Почему не другие варианты:
A (retry storm) – это проблема синхронных ретраев, а не медленного потребителя.
C (deadlock) – взаимоблокировка, не связано с очередью.
D (split brain) – проблема распределённых систем, когда два узла думают, что они лидеры.
Реальный кейс:
В системе логистики потребитель Kafka обрабатывал каждое сообщение (заказ) синхронно, вызывая внешний API доставки (среднее время 200 мс). При пике 5000 сообщений/сек очередь начала расти на 2000 сообщений/сек. Увеличили количество партиций с 1 до 10 и запустили 10 потребителей. Потребление выросло в 10 раз, и отставание прекратилось.
Что должен зафиксировать аналитик:
В требованиях к интеграции указать допустимый consumer lag (например, не более 10 000 сообщений).
Предусмотреть автоматическое масштабирование потребителей (Kubernetes HPA по длине очереди).
Мониторинг: алерт, если lag превышает порог.
Вывод: Consumer lag – главная метрика здоровья систем на основе очередей. Аналитик должен закладывать требования к пропускной способности и мониторингу отставания.
Please open Telegram to view this post
VIEW IN TELEGRAM
4865. Заказчик утвердил пороги скоринга (отказ < 50, проверка 50–70). Через месяц бизнес просит изменить пороги на 40 и 65. Изменение требует перевыпуска релиза. Что упустил аналитик?
Anonymous Quiz
10%
Не провёл нагрузочное тестирование правил
73%
Не предусмотрел внешнюю конфигурацию порогов
4%
Не согласовал правила с юристами
14%
Не зафиксировал логику в формальной спецификации