statusOrderCreatedPaymentReceivedOrderShippedOrderCancelledКлючевые преимущества:
Полный аудит – есть журнал всех изменений, можно ответить на вопрос «кто и когда изменил это поле».
Восстановление на любой момент времени – можно «перемотать» состояние к любой временной точке, повторно применив события до нужного момента.
Отладка и анализ – можно воспроизвести сценарий на тестовом окружении, чтобы найти причину ошибки.
Гибкость – можно строить разные read-модели (CQRS) на основе одного и того же потока событий без изменения источника.
Почему не подходят другие варианты:
A (CQRS) – разделяет команды и запросы, но может работать без Event Sourcing (например, на основе обычной БД).
B (Saga) – паттерн для распределённых транзакций, не про хранение истории.
D (Strangler Fig) – стратегия замены монолита на микросервисы, не имеет отношения к хранению изменений.
Реальный пример:
В банковских системах Event Sourcing используется для хранения всех транзакций по счёту. Это позволяет восстановить баланс на любую дату и обеспечить детальный аудит для регулятора.
Что должен зафиксировать аналитик:
«Для сущностей, требующих полного аудита и восстановления состояния на любой момент времени, использовать Event Sourcing».
«Хранить события в неизменяемом хранилище (например, Kafka, Event Store)».
«Реализовать проекции для построения текущего состояния».
Вывод: Event Sourcing — это стандарт для систем, где важна история изменений и возможность отката/аудита. Аналитик, закладывающий этот паттерн в требования, даёт команде мощный инструмент для обеспечения прозрачности и надёжности.
Please open Telegram to view this post
VIEW IN TELEGRAM
Добрый день!
Папка, собранная исключительно из учебных каналов — точно будет для вас полезной!
Присоединиться к папке можно по ссылке –
https://t.me/addlist/DcOLlyrhYWFmNzYy
Папка, собранная исключительно из учебных каналов — точно будет для вас полезной!
В папке собраны каналы, которые:
- рассказывают про ЕГЭ и ОГЭ для обучающихся в школе;
-каналы репетиторов
- каналы про олимпиады;
- каналы для обучения языку;
- каналы посвященные тематическим предметам ВУЗов;
- каналы для учителей, предназначенные для повышения их квалификации.
Присоединиться к папке можно по ссылке –
https://t.me/addlist/DcOLlyrhYWFmNzYy
4905. Какой сетевой слой управляет безопасностью и маршрутизацией между микросервисами без изменения кода?
Anonymous Quiz
50%
API Gateway
20%
Балансировщик нагрузки
19%
Service Mesh
11%
Шина данных
Service Mesh — это выделенный инфраструктурный слой, который управляет коммуникацией между микросервисами. Обычно он реализован как набор прокси (sidecar-контейнеров), запускаемых вместе с каждым сервисом. Все сетевые вызовы между сервисами проходят через эти прокси, которые обеспечивают:
Безопасность: автоматическое шифрование mTLS между сервисами.
Наблюдаемость: сбор метрик (latency, error rate, traffic) и распределённая трассировка без изменения кода.
Управление трафиком: канареечные релизы, A/B‑тестирование, процентное распределение трафика между версиями.
Отказоустойчивость: таймауты, повторные попытки, circuit breaker на уровне сетевых вызовов.
Чем Service Mesh отличается от API Gateway?
API Gateway (A) — это точка входа для внешних клиентов (мобильные приложения, браузеры). Он работает на периметре системы.
Service Mesh работает внутри кластера, управляя взаимодействием между внутренними сервисами.
Они не заменяют, а дополняют друг друга.
Реальный пример:
В крупных компаниях (Google, Lyft, PayPal) используют Istio или Linkerd для управления микросервисами. Это позволяет им безопасно выкатывать новые версии и быстро откатывать при проблемах без передеплоя кода.
Что должен зафиксировать аналитик:
«При большом количестве микросервисов и требованиях к безопасности, наблюдаемости и гибкому управлению трафиком, использовать Service Mesh».
«Service Mesh должен обеспечивать mTLS, сбор метрик, трассировку и поддержку канареечных релизов».
Вывод: Service Mesh — это стандарт для микросервисных систем, который решает проблемы сетевого взаимодействия без изменения кода. Аналитик, знающий этот паттерн, может рекомендовать его как инфраструктурный слой для сложных распределённых систем.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Тссс! Не спугни 🤫
Дорогие зрители, на вашем экране удивительное интернет-явление — лучшие IT и AI каналы собрались в группу и готовы поделиться своей полезностью
Все это, и не только, вы можете увидеть по ссылке! Забирайте пользу, пока каналы не разбежались https://t.me/addlist/qI7aaJx4U5s5MjQy
Дорогие зрители, на вашем экране удивительное интернет-явление — лучшие IT и AI каналы собрались в группу и готовы поделиться своей полезностью
Новости из мира IT
Нейросети
Реальные кейсы из практики
Вакансии
Все это, и не только, вы можете увидеть по ссылке! Забирайте пользу, пока каналы не разбежались https://t.me/addlist/qI7aaJx4U5s5MjQy
❤1
ХОЧЕШЬ ИДТИ В НОГУ С ТЕХНОЛОГИЯМИ ?! … или наблюдать, как другие зарабатывают на ИИ? - РЕШАТЬ ТЕБЕ !
ИИ станет твоим главным инструментом, а не загадкой 🗝
Больше не нужно мониторить сотни источников в надежде найти адекватных авторов. Мы сделали это за тебя и заодно попали в эту ПОДБОРКУ сами ✔️
Что внутри? Только лучшее из Мира IT & AI :
* ИИ — не хайп, а реальные инструменты и внедрения
* Технологии — тренды, обзоры, инсайты от первых лиц
* Карьера — как найти работу, вырасти и не выгореть
* HR Tech — кто и как нанимает профессионалов прямо сейчас
* AI Life hacks — как выжить и зарабатывать за границей с помощью возможностей ИИ
👉 Делимся знаниями и аудиторией - растём вместе ⚡️ 📂 Забирай ПАПКУ с ТОП ИИ Каналами бесплатно
Отписаться можно в любой момент. Остаться — тоже ✔️
ИИ станет твоим главным инструментом, а не загадкой 🗝
Больше не нужно мониторить сотни источников в надежде найти адекватных авторов. Мы сделали это за тебя и заодно попали в эту ПОДБОРКУ сами ✔️
Что внутри? Только лучшее из Мира IT & AI :
* ИИ — не хайп, а реальные инструменты и внедрения
* Технологии — тренды, обзоры, инсайты от первых лиц
* Карьера — как найти работу, вырасти и не выгореть
* HR Tech — кто и как нанимает профессионалов прямо сейчас
* AI Life hacks — как выжить и зарабатывать за границей с помощью возможностей ИИ
👉 Делимся знаниями и аудиторией - растём вместе ⚡️ 📂 Забирай ПАПКУ с ТОП ИИ Каналами бесплатно
Отписаться можно в любой момент. Остаться — тоже ✔️
🔥1
ИИ ПРЯМО СЕЙЧАС ПЕРЕПИСЫВАЕТ ВСЕ СТАРЫЕ ПРАВИЛА 🖋
На твоих глазах меняются алгоритмы генерации текстов, аналитики, продаж и дизайна. Вопрос не в том, заменит ли он людей, а в том, кто использует его раньше остальных.
Мы подготовили для тебя подборку экспертных каналов по теме: AI, IT & HR Tech, а также последние - AI Life hacks
🔗 [Добавить подборку]
На твоих глазах меняются алгоритмы генерации текстов, аналитики, продаж и дизайна. Вопрос не в том, заменит ли он людей, а в том, кто использует его раньше остальных.
Мы подготовили для тебя подборку экспертных каналов по теме: AI, IT & HR Tech, а также последние - AI Life hacks
– Нейросети и практика внедрения;
– IT и технологии;
– HR Tech и найм;
– AI Life hacks для работы и заработка.
🔗 [Добавить подборку]
🔥1
4906. В проекте выявлен риск: внешний API, может стать недоступным в часы пик. Команда решает добавить кэширование ответов и fallback‑логику, чтобы функция продолжала работать даже при сбое API. Какая стратегия реагирования на риск применяется?
Anonymous Quiz
8%
Избегание риска
10%
Передача риска
55%
Смягчение риска
27%
Принятие риска
В системном анализе риски — это события, которые могут негативно повлиять на проект (сроки, бюджет, функциональность, качество). Управление рисками включает их идентификацию, оценку (вероятность и влияние) и планирование реагирования.
Основные стратегии реагирования на риски:
Избегание (Avoid) – устранение причины риска. Например, отказаться от использования внешнего API вообще и написать своё решение.
Передача (Transfer) – переложить ответственность на третью сторону. Например, застраховать проект или заключить SLA с поставщиком API.
Смягчение (Mitigate) – снижение вероятности или последствий риска до приемлемого уровня. В примере: кэширование ответов, fallback‑логика, ретраи с экспоненциальной задержкой.
Принятие (Accept) – ничего не делать, принять риск. Применяется, когда стоимость устранения риска выше, чем ущерб от него.
Почему Mitigate — правильный ответ:
Добавление кэширования и fallback‑логики не устраняет сам риск (API всё ещё может упасть), но существенно снижает последствия: пользователи не увидят ошибку, получат хотя бы кэшированные данные. Это классическое смягчение.
Реальный пример:
В сервисе прогноза погоды внешний API погоды иногда недоступен. Команда внедрила кэширование последнего успешного ответа на 30 минут и fallback‑сообщение о примерной погоде. Риск не исчез, но его влияние на пользователей стало минимальным.
Что должен зафиксировать аналитик:
«Для каждого критического риска должна быть определена стратегия реагирования».
«В требованиях к системе должны быть указаны меры смягчения (кэширование, ретраи, fallback) для высокорисковых интеграций».
Вывод: Смягчение рисков — самая распространённая стратегия в системном анализе, когда нельзя полностью избежать риска или передать его. Аналитик, умеющий предлагать конкретные технические меры смягчения, повышает надёжность системы.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Поймали себя на мысли, что мы вообще перестали обсуждать, какая нейросеть «умнее». Теперь обсуждают другое.
Кажется, это лучший фильтр для digital сегодня.
Здесь можно почитать подборки, обзоры, впечатления глазами менеджера с аналитическим умом.
Без бесконечных списков из сотни сервисов. Собрали папку интересных инструментов, наблюдений, кейсов из IT, AI и маркетинга, которые помогают работать быстрее и смотреть на индустрию чуть шире.
Если тоже любите не просто читать новости, а понимать, что из них действительно заслуживает внимания
📂 Сохраняйте папку себе
На фестивале Cannes Lions руководители крупнейших мировых брендов пришли к неожиданному выводу: когда ИИ научился делать почти всё, главным конкурентным преимуществом стал... человеческий вкус. Не промпты, не количество сервисов, а способность понять, что действительно стоит показать аудитории, а что — просто очередной AI-мусор.
Кажется, это лучший фильтр для digital сегодня.
Здесь можно почитать подборки, обзоры, впечатления глазами менеджера с аналитическим умом.
Без бесконечных списков из сотни сервисов. Собрали папку интересных инструментов, наблюдений, кейсов из IT, AI и маркетинга, которые помогают работать быстрее и смотреть на индустрию чуть шире.
Если тоже любите не просто читать новости, а понимать, что из них действительно заслуживает внимания
📂 Сохраняйте папку себе
4907. Для защиты взаимодействия между микросервисами требуется взаимная аутентификация без участия человека, гарантирующая, что обе стороны являются теми, за кого себя выдают, на уровне транспортного уровня. Какой протокол обеспечивает это?
Anonymous Quiz
34%
OAuth2
22%
JWT
39%
mTLS
5%
Basic Auth
В микросервисной архитектуре сервисы общаются друг с другом по сети. Злоумышленник может попытаться подделать запрос или перехватить данные. Требуется не только шифрование трафика, но и проверка подлинности обоих участников (сервис-клиент и сервис-сервер). Традиционные методы (Basic Auth, API‑ключи) работают на уровне приложения и могут быть скомпрометированы.
Что такое mTLS (Mutual TLS)?
Это расширение протокола TLS, при котором не только сервер предоставляет сертификат клиенту, но и клиент обязан предъявить свой сертификат серверу. Обе стороны проверяют сертификаты друг друга, удостоверяясь, что они принадлежат доверенным сущностям. Это обеспечивает:
Взаимную аутентификацию – сервер знает, кто клиент, клиент знает, что сервер настоящий.
Шифрование трафика – все данные передаются в зашифрованном виде.
Защиту от подделки – сертификаты подписаны доверенным центром (CA) или внутренним PKI.
Сравнение с другими вариантами:
A (OAuth2) – протокол авторизации, обычно с участием пользователя и получением токена доступа. Не является транспортным протоколом и не обеспечивает взаимную аутентификацию на уровне соединения.
B (JWT) – формат токена для передачи утверждений (claims) между сторонами. JWT не гарантирует, что клиент – это тот, за кого себя выдаёт, без дополнительных механизмов.
D (Basic Auth) – передача логина/пароля в открытом виде (или Base64). Устаревший и небезопасный метод для межсервисного взаимодействия.
Реальный пример:
В Kubernetes с Istio (Service Mesh) mTLS включён по умолчанию для всех сервисов внутри кластера. Это позволяет автоматически шифровать и аутентифицировать весь трафик без изменения кода приложений.
Что должен зафиксировать аналитик:
«Для межсервисного взаимодействия использовать mTLS для взаимной аутентификации и шифрования».
«Сертификаты должны управляться централизованным PKI с автоматической ротацией».
Вывод: mTLS — это стандарт для безопасной коммуникации в микросервисных системах, особенно когда критичны защита от подделки и шифрование на транспортном уровне. Аналитик, закладывающий этот протокол в требования, повышает общую безопасность системы.
Please open Telegram to view this post
VIEW IN TELEGRAM
Сэкономила вам время ⌚️
Я собрал каналы по Искусственому интеллекту.
Все в одном месте:
⚪️ лучшие нейросети и сервисы;
⚪️готовые промпты;
⚪️реальные кейсы ;
⚪️способы зарабатывать с помощью ИИ
Добавляйте каналы, все полезное уже здесь⚡️
Самый ценный ресурс
Я собрал каналы по Искусственому интеллекту.
Все в одном месте:
⚪️ лучшие нейросети и сервисы;
⚪️готовые промпты;
⚪️реальные кейсы ;
⚪️способы зарабатывать с помощью ИИ
Добавляйте каналы, все полезное уже здесь
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Доя масштабного и перспективного проекта в FinTech, Локация: Минск, РБ
ищем амбициозных и ориентированных на развитие специалистов:
1. Руководитель отдела карточных продуктов
Требования:
Опыт в карточном бизнесе от 3 лет, опыт управления P&L карточного портфеля, опыт управления продуктовой командой (от 3 человек), аналитические навыки
Задачи:
1. Управление портфелем карточных продуктов (дебетовые, кредитные, премиальные)
2. Разработка и запуск новых продуктов: от гипотезы до релиза (анализ рынка, требования к IT, юнит-экономика, маркетинг, обучение продавцов).
3. Формирование тарифной политики и ценообразование
4. Увеличение транзакционной активности и снижение оттока по картам.
5. Управление P&L карточного портфеля
2. Руководитель отдела кредитных продуктов
Требования:
Опыт в розничном кредитовании от 3 лет, запуск кредитных продуктов от идеи до релиза, понимание скоринга и кредитного риска, управление продуктовой командой от 3 человек, аналитические навыки, опыт в POS-кредитовании/рассрочке/кредитных картах, знакомство с альтернативным скорингом
Задачи:
1.Управление портфелем кредитных продуктов (кредитные карты, потребительские кредиты, автокредиты, рассрочка, POS-кредиты).
2. Разработка и запуск новых кредитных продуктов: от гипотезы до релиза
3. Формирование процентной политики (ставки, комиссии, льготные периоды,условия досрочного погашения).
4.Организация процесса кредитования (от заявки до сделки
5. Увеличение проникновения кредитных продуктов в действующую клиентскую базу (cross-sell, up-sell).
6. Управление P&L кредитного портфеля
3. Delivery Manager
Требования:
Опыт работы delivery-менеджером / project-менеджером в банке от 3 лет, понимание жизненного цикла разработки ПО, опыт управления кросс-функциональными проектами, знание Agile-практик, навык работы с JIRA / Confluence
Задачи:
1. Управление портфелем проектов розничного блока: от идеи до релиза и пост-релизного сопровождения.
2. Координация запуска новых продуктов
3. Контроль качества изменений
4. Организация сбора и фиксации бизнес-требований, контроль полноты документации перед передачей в разработку.
5. Сбор метрик delivery-процессов (lead time, cycle time, объём незавершёнки), проведение ретроспектив и непрерывное улучшение.
Контакт для связи: @Alena_Gvozdz
ищем амбициозных и ориентированных на развитие специалистов:
1. Руководитель отдела карточных продуктов
Требования:
Опыт в карточном бизнесе от 3 лет, опыт управления P&L карточного портфеля, опыт управления продуктовой командой (от 3 человек), аналитические навыки
Задачи:
1. Управление портфелем карточных продуктов (дебетовые, кредитные, премиальные)
2. Разработка и запуск новых продуктов: от гипотезы до релиза (анализ рынка, требования к IT, юнит-экономика, маркетинг, обучение продавцов).
3. Формирование тарифной политики и ценообразование
4. Увеличение транзакционной активности и снижение оттока по картам.
5. Управление P&L карточного портфеля
2. Руководитель отдела кредитных продуктов
Требования:
Опыт в розничном кредитовании от 3 лет, запуск кредитных продуктов от идеи до релиза, понимание скоринга и кредитного риска, управление продуктовой командой от 3 человек, аналитические навыки, опыт в POS-кредитовании/рассрочке/кредитных картах, знакомство с альтернативным скорингом
Задачи:
1.Управление портфелем кредитных продуктов (кредитные карты, потребительские кредиты, автокредиты, рассрочка, POS-кредиты).
2. Разработка и запуск новых кредитных продуктов: от гипотезы до релиза
3. Формирование процентной политики (ставки, комиссии, льготные периоды,условия досрочного погашения).
4.Организация процесса кредитования (от заявки до сделки
5. Увеличение проникновения кредитных продуктов в действующую клиентскую базу (cross-sell, up-sell).
6. Управление P&L кредитного портфеля
3. Delivery Manager
Требования:
Опыт работы delivery-менеджером / project-менеджером в банке от 3 лет, понимание жизненного цикла разработки ПО, опыт управления кросс-функциональными проектами, знание Agile-практик, навык работы с JIRA / Confluence
Задачи:
1. Управление портфелем проектов розничного блока: от идеи до релиза и пост-релизного сопровождения.
2. Координация запуска новых продуктов
3. Контроль качества изменений
4. Организация сбора и фиксации бизнес-требований, контроль полноты документации перед передачей в разработку.
5. Сбор метрик delivery-процессов (lead time, cycle time, объём незавершёнки), проведение ретроспектив и непрерывное улучшение.
Контакт для связи: @Alena_Gvozdz
4908. Для проверки отказоустойчивости системы команда намеренно отключает случайные микросервисы или задерживает их ответы, чтобы убедиться, что система корректно обрабатывает сбои. Как называется эта практика?
Anonymous Quiz
9%
Нагрузочное тестирование
71%
Тестирование на отказоустойчивость
18%
Chaos Engineering
2%
Пентест безопасности
Как это работает:
Инструмент (например, Chaos Monkey от Netflix) случайным образом отключает сервисы, задерживает сетевые пакеты, вызывает ошибки.
Команда наблюдает за поведением системы: восстанавливается ли она, не теряет ли данные, не ухудшается ли пользовательский опыт.
На основе результатов усиливают отказоустойчивость: добавляют ретраи, таймауты, circuit breaker, redundant узлы.
Сравнение с другими вариантами:
A (Нагрузочное тестирование) — проверяет производительность под большой нагрузкой, а не устойчивость к сбоям.
B (Тестирование на отказоустойчивость) — похоже, но это более общий термин, а Chaos Engineering — конкретная практика, которая фокусируется на экспериментировании в продуктивной среде и автоматизации.
D (Пентест) — проверяет безопасность, а не отказоустойчивость.
Реальный пример:
Netflix создала Chaos Monkey, который случайно выключает инстансы в AWS. Это помогло инженерам убедиться, что система самовосстанавливается, и инциденты стали редкостью, а не катастрофой.
Что должен зафиксировать аналитик:
«В архитектуре должна быть предусмотрена возможность проведения экспериментов по Chaos Engineering».
«Ключевые метрики (ошибки, задержки, успешность запросов) должны отслеживаться во время таких экспериментов».
Вывод: Chaos Engineering — это не просто «проверим, упадёт ли», а систематический подход к повышению надёжности сложных распределённых систем.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔1