tgindex

🍀BitBitGo🍀 Системный Анализ

описание

Курс «Системный анализ» https://bitbitgo.by/ Пишем про системный анализ. Поможем стартануть в карьере IT. Присоединяйся!

← к каналу@bitbitgoby
3 838
подписчиков
Охват к подписчикам
4,9%
ERR
Реакции к просмотрам
0,49%
47 на 42 постов
Пересылки к просмотрам
1,23%
117
Постов в день
0,1
всего 42

Где отзываются чаще

доля реакций к просмотрам
  • 22 июл.🧩 CQRS: КОГДА ЧИТАТЬ И ПИСАТЬ НУЖНО ПО-РАЗНОМУ Привет, коллеги! 👋 Представьте: ваша CRM отлично справляется с созданием заказов, но отчёты по продажам грузятся по 10 секунд. Вы добавляете индексы, увеличиваете память — а толку ноль. Знакомо? Сегодня разберём реальный кейс, как CQRS (Command Query Responsibility Segregation) спас производительность и разделил потоки чтения и записи. Поехали! 🚀 📌 Кейс: «Отчёты убивают интерфейс» Ситуация: В CRM для менеджеров по продажам была одна база данных PostgreSQL. В ней хранились заказы, клиенты, товары. Интерфейс работал отлично, пока не появлялось 5–6 менеджеров с отчётами. Запросы с GROUP BY и JOIN по миллионам записей блокировали таблицы, и создание заказа зависало на 2–3 секунды. Пользователи жаловались, продажи падали. 📉 Проблема: Одна модель данных используется и для транзакций (быстрые вставки/обновления), и для аналитики (тяжёлые агрегации). Они конфликтуют. Что хорошо для записи (нормализованные таблицы) — плохо для чтения (много JOIN). Что хорошо для чтения (денормализация) — замедляет запись. 📌 Решение: CQRS Что сделал аналитик? Внедрил паттерн CQRS — разделение ответственности между командами (запись) и запросами (чтение). Архитектура стала такой: Командная модель (write) — PostgreSQL с нормализованной схемой для операций создания/обновления. Здесь всё быстро, потому что только INSERT/UPDATE. Модель запросов (read) — отдельная денормализованная таблица (витрина) в той же БД или в Redis/Elasticsearch. В ней данные уже агрегированы, с готовыми суммами, количеством заказов и т.д. Проектор — сервис, который слушает события из Kafka (например, OrderCreated, PaymentReceived) и обновляет read-модель. Пример кода проектора (Python + Kafka): python from kafka import KafkaConsumer consumer = KafkaConsumer('order_events', bootstrap_servers='localhost:9092') for msg in consumer: event = json.loads(msg.value) if event['type'] == 'ORDER_CREATED': # Обновляем агрегированную таблицу db.execute(""" UPDATE sales_summary SET total_orders = total_orders + 1, total_revenue = total_revenue + %s WHERE date = %s """, (event['amount'], event['date'])) Что изменилось после внедрения: Создание заказа — 50 мс (было 200 мс из-за блокировок). Отчёт по продажам — 200 мс (было 10 секунд). База данных перестала «падать» в часы пик. 📌 Что должен зафиксировать аналитик в требованиях Разделить потоки записи и чтения на уровне логики (и, возможно, на уровне БД). Допустимость eventual consistency — задержка между записью и обновлением read-модели не более 2 секунд. Выбрать хранилище для read-модели (Redis, Elasticsearch, реплика PostgreSQL). Определить события, на которые подписываются проекторы. Обеспечить идемпотентность проектора — повторное чтение одного события не должно портить данные. 🎯 ИТОГ CQRS — это не «усложнить ради усложнения». Это способ спасти производительность, когда чтение и запись конфликтуют. Аналитик, который предлагает CQRS, развязывает команду разработки и делает систему быстрее.3,16%
  • 13:27Новые модели и инструменты появляются быстрее, чем успеваешь разобраться в предыдущих. В итоге подписок десятки, а в работе используются две нейросети. Поэтому мы собрали сильных экспертов по ИИ в одну папку: инструменты, кейсы, промпты и практика. 💬Добавляйте каналы💬1,96%
  • 29 авг. 2024 г.🔍 Что такое Каскадная модель разработки (Waterfall)? Каскадная модель (Waterfall) — это классический подход к разработке программного обеспечения, при котором процесс разработки идет последовательно, переходя от одного этапа к другому без возврата назад. Этот метод часто сравнивают с водопадом 🌊, где вода течет только в одном направлении — сверху вниз. 🛠 Основные этапы Каскадной модели: 1. Сбор требований 📋 Все требования к системе тщательно собираются и документируются. Этот этап критичен, так как ошибки или пропуски могут повлиять на последующие стадии. 2. Проектирование системы 🖥 Создание детальной архитектуры системы и её компонентов. Проектирование охватывает как высокоуровневую архитектуру, так и детальное техническое решение. 3. Реализация (кодирование) 💻 На этом этапе происходит разработка программного обеспечения в соответствии с проектной документацией. Команда пишет код и интегрирует его в единую систему. 4. Тестирование 🔍 Проверка качества кода и его соответствия требованиям. Включает различные виды тестирования, такие как функциональное, нагрузочное и регрессионное тестирование. 5. Внедрение и поддержка 🚀 Система внедряется в рабочую среду, и начинается этап её поддержки. Исправляются ошибки, которые были упущены на предыдущих этапах. 🌟 Преимущества Каскадной модели: • Четкая структура и контроль: Каждый этап имеет четко определенные результаты и документацию, что облегчает управление проектом. • Прогнозируемость: Легко оценить время и ресурсы, необходимые для завершения каждого этапа. ⚠️ Недостатки Каскадной модели: • Трудности с изменениями: Внесение изменений на поздних этапах может быть дорогостоящим и сложным. • Долгий цикл разработки: Возможны задержки, особенно если выявляются ошибки на этапе тестирования, требующие возврата на предыдущие стадии. 💡 Когда применять Каскадную модель? • Для проектов с чётко определёнными требованиями, которые вряд ли изменятся. • В проектах, где критична полная документированность и строгий контроль на каждом этапе. 👉 Каскадная модель — идеальный выбор для проектов с фиксированными требованиями и ограниченными изменениями. #METHODOLOGY1,74%
  • 14 июл.УСПЕВАЕШЬ СЛЕДИТЬ ЗА НОВИНКАМИ ?! Технологии не ждут ... * Когда подписки устарели (outdated) - пора сделать АПГРЕЙД своего информационного поля. Это ПОДБОРКА ведущих Telegram-каналов — тех самых людей, которые не просто читают новости, а сами их создают. 📂 Добавляй ПАПКУ — и получи полный АПГРЕЙД своей ленты: * Сделай свою подписку умнее, пока другие читают вчерашние новости ⚡️ Отписаться можно в любой момент. Остаться — тоже ✔️1,56%
  • 21 июл.🔁 ИДЕМПОТЕНТНОСТЬ: КАК МЫ ПЕРЕСТАЛИ СПИСЫВАТЬ ДЕНЬГИ ДВАЖДЫ Привет, коллеги! 👋 Представьте: клиент оформляет заказ, система списывает деньги… а потом ещё раз. Повторно. Клиент в ярости, поддержка в огне, бизнес теряет репутацию. Знакомо? Сегодня разберём реальный кейс, как идемпотентность спасла платёжную систему от двойных списаний. Поехали! 🚀 📌 Кейс: «Платёж прошёл дважды» Ситуация: Мы интегрировались с платёжным шлюзом. Схема: клиент нажимает «Оплатить», наш сервис отправляет запрос в шлюз, шлюз возвращает payment_id, мы списываем деньги и обновляем статус заказа. Всё работало… пока не случился сетевой таймаут. Клиент не получил ответа и нажал «Оплатить» ещё раз. Запрос ушёл повторно, сервер обработал его как новый, деньги списались дважды. 💸 Проблема: HTTP POST по умолчанию не идемпотентен. Если клиент повторяет запрос из-за сбоя, сервер не может отличить повтор от нового запроса. Результат — дублирование операций. 📌 Решение: Идемпотентный ключ (Idempotency Key) Что сделал аналитик? Добавил в требования механизм идемпотентности на стороне сервера. Как это работает: Клиент генерирует уникальный ключ (например, UUID) и передаёт его в заголовке Idempotency-Key. Сервер: Проверяет, есть ли уже обработанный запрос с этим ключом (хранит в Redis/БД). Если есть — возвращает сохранённый ответ, не выполняя операцию повторно. Если нет — выполняет операцию (списание), сохраняет ключ и результат. Пример кода (Node.js + Redis): javascript app.post('/payment', async (req, res) => { const idempotencyKey = req.headers['idempotency-key']; const cached = await redis.get(`idempotency:${idempotencyKey}`); if (cached) { return res.json(JSON.parse(cached)); // повтор — возвращаем старый ответ } const result = await processPayment(req.body); await redis.setex( `idempotency:${idempotencyKey}`, 86400, // храним 24 часа JSON.stringify(result) ); res.json(result); }); Почему это работает: Если клиент не получил ответа и повторяет запрос — сервер возвращает тот же результат, не списывая деньги дважды. Ключ живёт 24 часа — достаточно, чтобы покрыть любые сетевые задержки. Redis обеспечивает атомарность и низкую задержку. 📌 Что должен зафиксировать аналитик в требованиях Idempotency-Key обязателен для всех небезопасных методов (POST, PUT, PATCH). Время жизни ключа — не менее 24 часов. Ответ на повторный запрос с тем же ключом должен быть идентичен первому. Хранилище ключей — Redis или БД с атомарной проверкой (например, SET NX в Redis). Тест-кейсы: проверить, что при повторном запросе с тем же ключом операция не дублируется. 🎯 ИТОГ Идемпотентность — это не просто «техническая деталь». Это страховка от финансовых потерь и потерянных клиентов. Аналитик, закладывающий идемпотентность в требования на этапе проектирования, спасает бизнес от катастроф. 💪1,41%
  • 7 февр.без подписи1,09%
  • 30 авг. 2024 г.🔍 Waterfall vs. Agile: Что выбрать для вашего проекта? В разработке ПО часто встает вопрос: какую методологию выбрать? 🤔 Сегодня мы рассмотрим две основные: Waterfall и Agile. Эти подходы имеют свои особенности и подходят для разных типов проектов. 💧 Waterfall — Каскадная модель • Линейная структура: Проект разбивается на последовательные этапы, каждый из которых должен быть завершен перед началом следующего. Ошибки на ранних этапах могут оказаться критичными. • Документированность: Все требования фиксируются заранее, что упрощает управление и контроль за проектом. • Когда применять: Waterfall подходит для проектов с четко определенными требованиями и отсутствием необходимости в частых изменениях. 🌀 Agile — Гибкая методология • Итеративный процесс: Проект делится на короткие спринты, каждая из которых заканчивается готовым результатом. Это позволяет быстро адаптироваться к изменениям и требованиям заказчика. • Гибкость: Agile позволяет вносить изменения на любом этапе, что особенно полезно для динамичных проектов. • Когда применять: Agile подходит для проектов, где важно быстро реагировать на изменения, и требования могут изменяться в процессе разработки. ⚖️ Waterfall или Agile? Выбор методологии зависит от специфики вашего проекта. Если ваш проект требует строгой последовательности действий и фиксированных требований, выбирайте Waterfall. Если же важны гибкость и быстрая адаптация к изменениям, ваш выбор — Agile. 💡 Вывод: Оцените цели и ресурсы вашего проекта, чтобы выбрать наиболее подходящий подход. В конечном итоге, правильный выбор методологии может значительно повлиять на успех вашего проекта! 📌 Следите за нашими постами, чтобы узнать больше о методологиях разработки ПО! #METHODOLOGY1,02%
  • 28 нояб.🔍 СИСТЕМНОЕ ТЕСТИРОВАНИЕ: ПОЛНЫЙ РАЗБОР ДЛЯ АНАЛИТИКОВ Привет, коллеги! 👋 Знаете ли вы, что качественное системное тестирование может сэкономить компании до 50% затрат на исправление ошибок? Сегодня разбираем, почему системный аналитик должен разбираться в тестировании не хуже QA-инженера! 🎯 ЧТО ТАКОЕ СИСТЕМНОЕ ТЕСТИРОВАНИЕ ПРОСТЫМИ СЛОВАМИ? Это проверка ВСЕЙ системы целиком — как она будет работать у конечного пользователя. Не просто отдельные функции, а полные сценарии использования! Аналитику на заметку: Именно здесь ваши требования проходят полевые испытания! 💥 🎪 3 ГЛАВНЫХ МЕТОДА ТЕСТИРОВАНИЯ: ⬛️ Чёрный ящик Что проверяем: Только вход и выход Для аналитика: Идеально для проверки, что система делает ТО, что вы описали в требованиях ⬜️ Белый ящик Что проверяем: Внутреннюю структуру кода Для аналитика: Помогает понять, КАК реализована логика 🩶 Серый ящик Что проверяем: Комбинация подходов Для аналитика: Золотая середина — видим и поведение, и частично внутреннюю кухню 📊 ВИДЫ ТЕСТИРОВАНИЯ, КОТОРЫЕ ДОЛЖЕН ЗНАТЬ АНАЛИТИК: Функциональное — а точно ли работает так, как я написал в ТЗ? ✅ Совместимости — а не сломается ли на другом браузере/устройстве? 📱 Производительности — выдержит ли нагрузку из 1000 пользователей? 🚀 Удобства использования — а не запутаются ли пользователи в интерфейсе? 🤔 🚨 КОГДА АНАЛИТИКУ ТРЕБУЕТСЯ СИСТЕМНОЕ ТЕСТИРОВАНИЕ? После разработки — проверяем, что получилось именно то, что вы задумали Перед релизом — последний шанс поймать критичные баги После изменений — убеждаемся, что новая фича не сломала старое При масштабировании — проверим, выдержит ли система рост нагрузки 💡 ИНСТРУМЕНТЫ, КОТОРЫЕ ПОМОГУТ АНАЛИТИКУ: Selenium — автоматизация UI-тестов JMeter — проверка нагрузки Postman — тестирование API TestRail — управление тест-кейсами 🎁 ГЛАВНЫЕ ВЫГОДЫ ДЛЯ АНАЛИТИКА: ✔️ Ваши требования реализуются точнее ✔️ Меньше доработок после сдачи проекта ✔️ Довольные клиенты = меньше претензий к вам ✔️ Ускорение выхода продукта на рынок Помните: Системный аналитик, который понимает тестирование, — это не просто "писатель ТЗ", а полноценный архитектор качественных решений! 🏗 P.S. Хотите глубже разобраться в тестировании? Сохраните этот пост — он ваш надежный помощник! 📌 #TESTING0,99%
  • 17 июн. 2025 г.💡 JSON (JavaScript Object Notation) — это текстовый формат для обмена данными. Он: • легко читается человеком • легко обрабатывается машиной • поддерживается почти всеми языками программирования Как устроен JSON? JSON описывает данные в виде пар ключ: значение. 📦 JSON-объект — данные в фигурных скобках: { "query": "Виктор Иван", "count": 7 } • "query" и "count" — ключи • "Виктор Иван" и 7 — значения • Строки — в кавычках • Числа, true, false, null — без кавычек JSON-объект может содержать: • другие объекты • массивы • строки • числа • булевы значения • null 📚 Что такое массив в JSON? 📦 JSON-массив — упорядоченный список значений в квадратных скобках: ["MALE", "FEMALE"] Пример с массивом внутри объекта: { "parts": ["NAME", "SURNAME"] } Значения могут быть любого типа: строки, числа, объекты, массивы. ✅ Признаки валидного JSON: • Все строки — в двойных кавычках • Ключи — тоже в кавычках • Пары ключ:значение разделены запятыми • Объекты — в { }, массивы — в [ ] Пример правильного JSON: { "name": "Иван", "age": 30, "skills": ["Postman", "SQL", "Python"], "married": false } #api #postman #json #тестирование #qa0,96%
  • 24 июл.📊 BPMN: КАК МОДЕЛЬ ПРОЦЕССА СПАСЛА ПРОЕКТ ОТ ХАОСА Привет, коллеги! 👋 Знакомая ситуация: бизнес говорит «сделайте как надо», а как надо — никто не знает. Процесс согласования заявок, документов, командировок — всё это часто похоже на чёрный ящик. Сегодня разберём реальный кейс, где BPMN (Business Process Model and Notation) помогла навести порядок и сократить время согласования в 3 раза. Поехали! 📌 Кейс: «Договор висит неделю» Ситуация: В компании по продаже оборудования процесс согласования договора с клиентом занимал в среднем 7 рабочих дней. Юристы, финансисты, руководители — каждый добавлял свой этап, но никто не видел полную картину. Заявки терялись, дублировались, а иногда просто зависали на неделю. Бизнес терял клиентов. Проблема: Процесс никем не описан. Каждый участник знает только свой участок, но не весь поток. Нет чёткого понимания, кто за что отвечает, какие есть альтернативные пути (отказ, доработка) и сколько времени занимает каждый шаг. 📌 Решение: BPMN-модель Что сделал аналитик? Собрал всех участников, провёл воркшоп и нарисовал BPMN-диаграмму процесса. Она включала: Пул (Pool) – вся компания (или внешний контрагент). Дорожки (Swimlanes) – юристы, финансисты, руководитель отдела, гендиректор. События (Events) – начало (заявка создана), промежуточные (получен ответ от юриста), конечные (договор подписан, отклонён). Шлюзы (Gateways) – XOR (если сумма > 1 млн → гендиректор, иначе → руководитель отдела), параллельный (одновременная проверка юриста и финансиста). Задачи (Tasks) – проверка договора, согласование бюджета, подпись. Пример BPMN-схемы (текстовое описание): text [Начало: Заявка создана] ↓ [Проверка юристом] --(если ошибки)--> [Доработка юристом] → [Проверка юристом] ↓ (если ок) [Проверка финансистом] (параллельно с юридической) ↓ (обе проверки завершены) [Шлюз: сумма > 1 млн?] ↓ Да ↓ Нет [Гендиректор] [Руководитель отдела] ↓ ↓ [Подписание договора] ↓ [Конец: Договор подписан] Что дала BPMN-модель: Прозрачность – все участники увидели полный маршрут заявки. Выявление узких мест – обнаружилось, что юристы часто возвращают заявку на доработку, потому что менеджеры забывают прикладывать скан паспорта. Добавили проверку на этапе создания. Оптимизация – убрали лишний этап согласования у заместителя, который дублировал руководителя. Время сократилось с 7 до 2 дней. 📌 Как BPMN помогает аналитику Связь с бизнесом – BPMN понятна не только разработчикам, но и заказчикам (если не углубляться в технические детали). Основа для автоматизации – BPMN-модель можно напрямую экспортировать в workflow-движок (Camunda, Activiti) и запустить как исполняемый процесс. Выявление рисков – на диаграмме видно, где процесс может «зависнуть» (например, нет таймаута на ответ от руководителя). Документирование – процесс описан один раз и не теряется в устных договорённостях. Пример кода (Camunda BPMN + Java): java @ProcessDefinition(key = "contract-approval") public class ContractApprovalProcess { @Execute public void startProcess(@Variable String contractId) { // запуск процесса } @ServiceTask("legal-check") public void legalCheck(@Variable String contractId) { // проверка юриста } @Gateway("sum-check") public String checkSum(@Variable double amount) { return amount > 1000000 ? "to-ceo" : "to-head"; } } 📌 Что должен зафиксировать аналитик в требованиях BPMN-модель должна быть согласована со всеми участниками процесса. Каждый шаг должен иметь чёткого исполнителя (роль), срок выполнения и критерии перехода. Альтернативные потоки (отказ, доработка) должны быть явно описаны. Таймауты – если задача не выполнена за N дней, процесс должен автоматически эскалироваться. 🎯 ИТОГ BPMN — это не просто «красивая картинка». Это язык, который объединяет бизнес и IT, делает процессы прозрачными и управляемыми. Аналитик, владеющий BPMN, может превратить хаос согласований в чёткий конвейер.0,94%
  • 26 дек.🔍 Тестирование в системном анализе: Не контроль, а наша общая гарантия качества! 🛡 Привет, коллеги-аналитики! 👋 Давайте развеем главный миф 🚫: тестирование (QA) — это не островок, куда мы сбрасываем требования и забываем. Это прямое продолжение нашей работы по проектированию системы! 🏗 Мы отвечаем за то, ЧТО должно работать, а тестирование проверяет, КАК это работает в реальности. 🔄 Почему аналитик должен погружаться в тестирование? 🤔 ✅ Мы — хранители «истины» 📜: Наши требования и user stories — это эталон, с которым сверяют систему! ✅ Мы — ключевые проводники на UAT 🧭: Кто, если не мы, поможет бизнес-пользователю проверить, решает ли система его задачи? Мы разъясняем логику и фиксируем обратную связь! ✅ Мы — лучшие «переводчики» багов 🐞🔧: Когда находят дефект, мы определяем: это сбой (система не соответствует ТЗ) или уточнение (ТЗ не полностью отражало потребность)! 🔥 Давайте на реальном кейсе! Допустим, мы описали бизнес-правило для корзины: «🎯 Скидка 10% применяется, если сумма заказа больше 5000 рублей ИЛИ у клиента есть статус «VIP». 💻 Смотрим на код (упрощенная логика на Python): # Функция применения скидки, реализующая наше правило def apply_discount(order_amount, is_vip): """ Применяет скидку 10% если: - order_amount > 5000 - ИЛИ is_vip == True """ if order_amount > 5000 or is_vip: return order_amount * 0.9 # Возвращаем цену со скидкой 💰 else: return order_amount # Цена без изменений ⚖️ # Давайте мысленно "протестируем" функцию: # 1. apply_discount(6000, False) -> 5400.0 ✅ (Скидка по сумме) # 2. apply_discount(4000, True) -> 3600.0 ✅ (Скидка по VIP) # 3. apply_discount(4000, False) -> 4000 ❌ (Нет скидки) # 4. apply_discount(5000, False) -> 5000 ⚠️ (Граничное значение!) # 5. apply_discount(5001, False) -> 4500.9 ✅ (Есть скидка) 🧠 Что мы, как аналитики, можем сделать ДО передачи в разработку/тестирование? 🕒 Мы можем буквально набросать сценарии проверок в текстовом виде рядом с требованием 📝: Сценарий 1 (Сумма > 5000, не VIP): 📥 Вход: 6000₽, VIP: нет. 🎯 Ожидание: скидка 10% (5400₽). Сценарий 2 (Сумма < 5000, VIP): 📥 Вход: 4000₽, VIP: да. 🎯 Ожидание: скидка 10% (3600₽). Сценарий 3 (Сумма > 5000, VIP): 📥 Вход: 6000₽, VIP: да. 🎯 Ожидание: скидка 10% (5400₽). Сценарий 4 (Сумма < 5000, не VIP): 📥 Вход: 4000₽, VIP: нет. 🎯 Ожидание: нет скидки (4000₽). Сценарий 5 (Граничное значение): ⚠️ Вход: ровно 5000₽, VIP: нет. 🎯 Ожидание: НЕТ скидки (важный нюанс! "Больше 5000" ≠ "5000 и больше"). 🎉 Что это дает? 1️⃣ Предотвращаем недопонимание с разработчиком (особенно по граничному значению) 🤝 2️⃣ Даем тестировщику готовый чек-лист для ключевых проверок 📋✅ 3️⃣ Повышаем общее качество продукта, потому что ловим противоречия еще на этапе анализа 🚀 🏁 Итог: Участие в тестировании для аналитика — это замыкание цикла качества 🔄. Мы гарантируем, что идея, рожденная в требованиях, живет в готовом продукте! 🏆 Используйте простые примеры и продумывайте сценарии — это ваш суперскилл, который сэкономит часы работы команды и нервы заказчика! 💪✨ #TESTING0,93%
  • 17 февр.без подписи0,93%