Endi mavjud! Telegram Tadqiqoti 2025 — yilning asosiy insaytlari 
BA & SA | 10000 Interview questions
Kanalga Telegram’da o‘tish
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
Ko'proq ko'rsatish📈 Telegram kanali BA & SA | 10000 Interview questions analitikasi
BA & SA | 10000 Interview questions (@systemanalystinterview) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 10 210 obunachidan iborat bo'lib, Karyera toifasida 3 873-o'rinni va Rossiya mintaqasida 64 191-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 10 210 obunachiga ega bo‘ldi.
15 Iyun, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 301 ga, so‘nggi 24 soatda esa -1 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 3.19% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 2.35% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 326 marta ko‘riladi; birinchi sutkada odatda 240 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 3 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent объяснение, индекс, user_id, субд, паттерн kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 16 Iyun, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Karyera toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
10 210
Obunachilar
-124 soatlar
+1267 kunlar
+30130 kunlar
Postlar arxiv
4896. Платёжный шлюз присылает вебхук на ваш сервер. Если сервер временно недоступен, шлюз не повторяет отправку и вебхук теряется. Как гарантировать доставку, не меняя код шлюза?
Сейчас в digital и IT странный момент.
Вроде всё то же самое:
те же инструменты, те же площадки, те же люди. Но результаты — как будто из разных реальностей.
У одних стагнация, у других рост.
И это уже не про «лучше настроили рекламу».
Это про то, как вообще думают и принимают решения. Кто-то продолжает делать по старым схемам и упирается в потолок, а кто-то пересобирает подход и находит деньги там, где их раньше не видел.
Собрали папку по digital и IT как раз про это состояние рынка —
без иллюзий, но с пониманием, куда всё двигается и как под это адаптироваться.
Сохранить папку себе 🗂
☀Объяснение:
Проблема с мягким удалением (A):
Добавление поля
is_deleted и индекса заставляет все запросы на чтение включать условие WHERE is_deleted = false. Даже с индексом 100 млн записей, где 95% – активные, это всё равно сканирует много данных. Кроме того, мягко удалённые записи со временем накапливаются и занимают место. Восстановление работает, но производительность падает.
Решение – отдельная архивная таблица (B):
Основная таблица orders содержит только активные заказы (без удалённых).
При удалении заказ перемещается в таблицу deleted_orders (возможно, в том же или другом физическом хранилище).
Фоновый процесс раз в день удаляет из deleted_orders записи старше 30 дней.
Восстановление – перенести строку обратно в orders.
Преимущества:
Основная таблица остаётся маленькой и быстрой.
Архивную таблицу можно хранить на более дешёвом и медленном диске, сжатой.
Простые запросы (SELECT * FROM orders) не требуют фильтрации по is_deleted.
Недостатки:
Требуется фоновый процесс перемещения данных (можно реализовать через триггер + job).
Если восстанавливать часто, то перемещения туда-обратно могут стать нагрузкой.
Почему не подходят другие варианты:
C (физическое удаление + резервные копии) – восстановление сложно, требует разворачивания бэкапа.
D (партиционирование по дате удаления) – помогает, но не решает проблему накопления «мёртвых» записей в основной таблице.
Реальный пример:
В сервисе управления заказами Ozon удалённые заказы переносятся в отдельную таблицу, и только последние 30 дней хранятся в горячем архиве. Это позволило сократить размер основной таблицы на 70%.
Что должен зафиксировать аналитик:
«Удалённые объекты должны храниться отдельно от активных с автоматической очисткой через 30 дней».
«Фоновый процесс не должен создавать блокировок в основной таблице».
Вывод: Для больших таблиц с функцией восстановления архитектура с отдельной архивной таблицей предпочтительнее мягкого удаления.4895. В CRM нужно реализовать «корзину»: удалённые заказы должны восстанавливаться в течение 30 дней, после чего удаляться навсегда. Как спроектировать хранение удалённых заказов без падения производительности основных запросов?
☀Объяснение:
Что такое Canary deployment?
Название происходит от практики «канарейки в угольной шахте» (раньше шахтёры брали с собой канарейку – если она падала, значит, есть угарный газ). В IT – это стратегия, при которой новая версия приложения сначала получает маленькую долю трафика (например, 1% пользователей или запросов). Затем команда наблюдает за метриками (ошибки, время отклика). Если всё хорошо, доля постепенно увеличивается (5%, 20%, 50%, 100%). Если возникают проблемы, можно быстро откатить, направив 100% трафика на старую версию.
Чем отличается от других стратегий:
A (Rolling update) – постепенная замена подов, но трафик распределяется между старыми и новыми подами, а не контролируется на уровне процентного соотношения.
C (Blue‑Green) – требует двух полных окружений и мгновенного переключения. Не позволяет постепенно наращивать трафик.
D (Shadow deployment) – новая версия получает «теневой» трафик (копию запросов), но не обслуживает реальных пользователей. Хорошо для тестирования под нагрузкой, но не для проверки на реальных пользователях.
Реальный пример:
Netflix, Google, Amazon используют canary deployment для критических сервисов. Например, новая версия поиска сначала обрабатывает 0.5% запросов, а затем, если метрики в норме, долю увеличивают.
Что должен зафиксировать аналитик:
Требование: «Выкатка новых версий должна происходить по стратегии канареечного релиза с возможностью контролировать процент трафика».
Определить ключевые метрики для автоматического отката (например, увеличение ошибок 500 более чем на 0.1%).
Вывод: Canary deployment – идеальный выбор, когда нужно снизить риски, выпуская новую функциональность постепенно.
4894. Команда хочет выкатить новую версию рекомендательного сервиса, но не уверена в её стабильности. Нужно сначала направить на неё 1% трафика, а если ошибок нет – постепенно увеличивать. Какая стратегия деплоя это позволяет?
⁉️ Устал искать интересные каналы с ИИ новостями?
📁 ДОБАВИТЬ ВСЕ КАНАЛЫ
В этой папке собраны каналы про ИИ, которые помогают быстрее разобраться в сфере, находить идеи и экономить время на поиске информации.
😏 ЗАБРАТЬ ПАПКУ МОЖНО ТУТ
⏰ Папка действует 72 часа.
🤩 Организаторы: Green.Papka
☀Объяснение:
Проблема – состояние гонки (race condition):
Два процесса одновременно читают
value = 5, увеличивают в памяти до 6, затем оба записывают 6. В результате значение станет 6, хотя должно было стать 7 (потерян один инкремент).
Решение – атомарный UPDATE:
В большинстве реляционных СУБД (PostgreSQL, MySQL, Oracle) оператор UPDATE SET value = value + 1 является атомарным. База данных блокирует строку на время обновления, но не блокирует чтение (за счёт MVCC в PostgreSQL или разных механизмов). При параллельных вызовах второй вызов увидит уже увеличенное значение и корректно увеличит его ещё раз.
Почему не подходят другие варианты:
A (два отдельных запроса) – не атомарно, гонка неизбежна.
C (SELECT ... FOR UPDATE) – да, решает проблему, но блокирует строку даже для чтения другими транзакциями (пессимистическая блокировка). Это может снизить производительность. Атомарный UPDATE обычно быстрее.
D (UPSERT) – работает, но тяжеловесно, если гарантированно существует запись.
Важно для аналитика:
Если нужен атомарный инкремент – используйте один UPDATE.
Если нужно прочитать старое значение перед обновлением (например, для логирования), то придётся использовать SELECT ... FOR UPDATE в транзакции.
Для высоконагруженных счётчиков (лайки, просмотры) часто используют Redis (атомарный INCR), а периодически синхронизируют с БД.
Реальный пример:
В счетчике просмотров видео на YouTube используется атомарный UPDATE в базе данных для финальной консистентности, а промежуточные инкременты накапливаются в Redis.
Что должен зафиксировать аналитик:
«При обновлении счётчика использовать атомарный UPDATE SET field = field + 1 без предварительного чтения».
Если нужно получить предыдущее значение – оформить требование на пессимистическую блокировку.
Вывод: Простой атомарный UPDATE – самое производительное и надёжное решение для счётчиков без необходимости читать старое значение.4893. В таблице counters есть поле value. Два параллельных запроса могут прочитать одно и то же значение, увеличить и записать, что приведёт к потере одного инкремента. Какая SQL-конструкция гарантирует атомарное увеличение без блокировок на чтение?
☀Объяснение:
При эволюции API часто приходится менять названия полей, типы или удалять устаревшие атрибуты. Прямое изменение сломает всех существующих клиентов. Необходимо поддерживать несколько версий одновременно, позволяя клиенту выбирать версию.
Способы версионирования:
Через URL (
/v1/customers, /v2/customers) – самый простой и наглядный. Минус: меняется endpoint, клиентам нужно обновлять код вызовов.
Через параметр запроса (?version=2) – менее явно, может кэшироваться некорректно.
Через заголовок Accept – стандартный способ для REST, основанный на медиатипах. Клиент указывает желаемую версию в заголовке, например: Accept: application/vnd.myapi.v2+json. Сервер, прочитав заголовок, сериализует ответ в соответствующем формате.
Почему B – правильный ответ:
Использование Accept соответствует принципам REST (content negotiation).
Не засоряет URL, сохраняет единый endpoint.
Позволяет гибко комбинировать версию и формат (JSON, XML).
Сравнение с другими вариантами:
A (параметр ?version) – тоже возможен, но менее чистый с точки зрения REST.
C (разные URL) – классический подход, но вопрос явно описывает заголовок как способ указать версию.
D (тело запроса) – нестандартно, требует разбора тела до того, как будет понята версия (курица-яйцо).
Реальный пример:
GitHub API версионирует через заголовок Accept: application/vnd.github.v3+json. Это позволяет им добавлять новые поля, не ломая старых клиентов.
Что должен зафиксировать аналитик:
В требованиях указать, что API поддерживает версионирование через заголовок Accept.
Документировать возможные значения (v1, v2, latest).
Определить политику депрекации старых версий.
Вывод: Версионирование через заголовок Accept – гибкий и REST-совместимый способ, особенно когда URL должен оставаться стабильным.4892. API возвращает поле customer_name. В новой версии поле переименовали в full_name. Чтобы не ломать старых клиентов, сервер должен поддерживать обе версии одновременно. Как клиент может указать, какую версию API он хочет получить?
Нейросети, IT и AI — в одной папке
💬 С коллегами собрали новые каналы про:
💠 промпты для нейросетей и готовые решения
💠 AI-фотосессии, генерация изображений и контента
💠 новости искусственного интеллекта без лишнего шума
💠 применение AI в работе, бизнесе и повседневной жизни
💠 Python, JavaScript, Data Science и системный анализ
💠 вакансии и возможности для специалистов в IT
Посмотреть и подписаться тут 👉 https://t.me/addlist/c_rbhnzprbAwMmFi
💌 Добавить свой канал в папку
☀Объяснение:
Blue‑Green deployment – это техника, при которой существуют два идентичных окружения: «синее» (blue, текущая production-версия) и «зелёное» (green, новая версия).
Новая версия разворачивается в зелёной среде, пока синяя продолжает обслуживать трафик.
Проводятся smoke-тесты зелёной среды.
В один момент (атомарно) переключается маршрутизатор (балансировщик, DNS), и весь трафик направляется на зелёную среду.
Если возникли проблемы – переключаем обратно на синюю за секунды.
Синяя среда сохраняется как резервная, позже удаляется.
Почему отсутствует простой:
Переключение трафика происходит мгновенно (обновление конфигурации балансировщика или смена DNS-записи). Старые поды не удаляются до переключения, поэтому пользователи не замечают никакого прерывания.
Сравнение с другими стратегиями:
Rolling update (A) – постепенная замена подов. Может быть почти незаметным, но требует, чтобы приложение было отказоустойчивым к разным версиям одновременно. Риск – простой при ошибке в последней партии.
Canary deployment (C) – сначала новая версия получает небольшой процент трафика (например, 1%), что позволяет оценить работу, но для бездымного переключения на 100% также нужен финальный атомарный шаг.
A/B тестирование (D) – не про деплой, а про эксперименты.
Реальный пример:
В Netflix используется Blue‑Green для критических сервисов. Перед переключением проводят полный цикл интеграционного тестирования в зелёной среде. При обнаружении проблем – просто не переключают трафик.
Что должен зафиксировать аналитик:
Требование: «Критические сервисы должны разворачиваться по стратегии Blue‑Green с нулевым временем простоя».
Наличие двух полных окружений (ресурсы могут быть уменьшены на время, но должны быть готовы к переключению).
Процедура отката – переключение обратно на blue.
Вывод: Blue‑Green deployment – золотой стандарт для систем, где недопустим простой, но требует удвоения ресурсов во время деплоя.
4891. Команда выпускает новую версию микросервиса, но при обновлении возникает простой 2 минуты, пока старые поды заменяются новыми. Какой стратегией деплоя можно полностью исключить простой и мгновенно переключать трафик между средами?
