4881. В процессе согласования командировки возможны три исхода: «Утверждена», «Отклонена», «Отправлена на доработку». После каждого из них процесс завершается. Сколько конечных событий (end events) должно быть на диаграмме BPMN?
Anonymous Quiz
27%
Одно конечное событие с тремя исходящими потоками
52%
Три конечных события (по одному на каждый исход)
17%
Два конечных события (успех и ошибка)
4%
Ни одного, конечные события не нужны
👍2
В нотации BPMN процесс может иметь несколько конечных событий (end events). Каждое конечное событие обозначает отдельный, завершённый путь выполнения. Разные исходы процесса (успех, отказ, требование доработки, отмена) должны вести к разным конечным событиям, чтобы диаграмма отражала семантику бизнеса.
Почему не одно конечное событие (A)?
Если свести все три исхода в одно конечное событие, то на диаграмме будет непонятно, какой результат достигнут. Более того, для «Отправлена на доработку» может потребоваться дополнительная информация (например, комментарий проверяющего), что невозможно выразить единой точкой выхода.
Почему не два конечных события (успех/ошибка)?
В бизнес-процессе «Отправлена на доработку» – это не ошибка, а нормальное, ожидаемое состояние (например, заявка требует правок). Моделировать его как ошибку было бы некорректно и сбивало бы с толку аналитика и исполнителя.
Как изобразить на диаграмме:
После шлюза (XOR или OR) расходятся три потока.
Каждый поток ведёт к своему конечному событию.
У конечных событий можно задать имена (например, «Утверждено», «Отклонено», «На доработку»).
Реальный пример:
В процессе найма сотрудника возможны исходы: «Принят», «Отклонён», «Резерв». Каждый исход завершает процесс по-разному (в HR-системе разные статусы заявки). Три конечных события – стандартная практика.
Что должен зафиксировать аналитик:
В спецификации перечислить все возможные исходы процесса и соответствующие им конечные события.
Для каждого исхода описать, какие данные передаются (например, комментарий причины отказа).
Вывод: Количество конечных событий в BPMN должно соответствовать количеству бизнес-исходов процесса. Неверное количество приводит к потере информации и неверной реализации.
Please open Telegram to view this post
VIEW IN TELEGRAM
4882. В распределённой системе нужно обеспечить атомарность операции списания денег и резервирования товара. Требования: низкая задержка и высокая доступность. Какой протокол распределённых транзакций выбрать?
Anonymous Quiz
24%
Двухфазная фиксация (2PC) с блокировками
63%
Сага (Saga) с компенсациями
6%
Трёхфазная фиксация (3PC)
6%
Оптимистическая блокировка
Протокол, обеспечивающий строгую атомарность в распределённой среде. Имеет две фазы:
Подготовка (prepare) – координатор опрашивает все узлы, могут ли они зафиксировать транзакцию; узлы блокируют ресурсы и отвечают «готов».
Фиксация (commit) – если все готовы, координатор даёт команду commit, иначе – rollback.
Недостатки 2PC, критичные для требований:
Блокировки – ресурсы заблокированы на всё время транзакции (включая ожидание ответов). Это увеличивает задержку.
Координатор – единая точка отказа – если координатор упал после отправки commit, система может зависнуть.
Плохая масштабируемость – при большом числе участников растёт время и вероятность сбоев.
Не подходит для высокодоступных систем – требование «высокая доступность» несовместимо с 2PC, так как при сетевом разделении 2PC блокируется.
Saga (Сага):
Разбивает распределённую транзакцию на последовательность локальных транзакций. Каждая локальная транзакция обновляет свой сервис и публикует событие. Если транзакция не удалась, запускаются компенсирующие транзакции (откат выполненных шагов).
Варианты реализации Saga:
Хореография – сервисы обмениваются событиями без центрального координатора.
Оркестрация – центральный оркестратор управляет шагами и компенсациями.
Преимущества Saga:
Нет длительных блокировок – каждая локальная транзакция быстро фиксирует изменения.
Высокая доступность – нет единой точки отказа (в хореографии). Даже при оркестрации можно перезапустить оркестратор.
Масштабируемость – каждый сервис может обрабатывать свои транзакции независимо.
Недостаток Saga:
Конечная согласованность (eventual consistency) – в момент между шагами данные могут быть несогласованы (например, деньги списаны, товар ещё не зарезервирован). Но для многих бизнес-сценариев это допустимо.
Почему Saga подходит под требования «низкая задержка, высокая доступность»:
Нет блокировок → низкая задержка.
Нет единой точки отказа → высокая доступность.
Компенсации позволяют откатить изменения без глобальных блокировок.
Реальный пример:
В Uber для заказа поездки используется Saga: создание заказа → поиск водителя → списание средств → уведомление. Если поиск водителя не удался, запускается компенсация: отмена заказа и возврат средств.
Что должен зафиксировать аналитик:
«Для критичных по доступности и латентности распределённых операций использовать паттерн Saga».
«Для каждого шага определить компенсирующее действие (что делать при отказе)».
«Допустима конечная согласованность с максимальным окном 5 секунд».
Вывод: 2PC подходит для систем, где строгая атомарность важнее доступности и задержки (например, банковский перевод внутри одного кластера). Для микросервисов с высокими требованиями к доступности и скорости Saga – стандарт.
Please open Telegram to view this post
VIEW IN TELEGRAM
4883. В системе есть сервис резервного копирования, которому нужно читать все файлы. Разработчик выдал ему права администратора на сервере. В случае взлома этого сервиса злоумышленник получил полный. Какой принцип безопасности был нарушен?
Anonymous Quiz
9%
Разделение обязанностей
89%
Принцип наименьших привилегий (Least Privilege)
1%
Эшелонированная защита
1%
Безопасность по умолчанию
🤔1
Это фундаментальный принцип информационной безопасности, согласно которому любой субъект (пользователь, процесс, сервис) должен иметь только те права доступа, которые минимально необходимы для выполнения его функций, и не более. Даже если сервису нужно много файлов, ему можно дать доступ только к определённой директории и права на чтение, но не на запись или выполнение.
Почему в примере нарушен PoLP:
Сервису резервного копирования достаточно прав на чтение файлов из определённых каталогов и записи в каталог бэкапов. Ему не нужны права на установку программ, изменение конфигурации системы, доступ к другим сервисам. Выдача прав администратора даёт всё это, что резко увеличивает риски.
Реальные последствия нарушения:
При взломе сервиса атакующий получает полный контроль над хостом (root/Administrator).
Он может установить вредоносное ПО, получить доступ к данным других приложений, использовать сервер для атак на другие системы.
Как правильно:
Создать отдельную учётную запись для сервиса.
Выдать ей права на чтение только необходимых директорий (например,
C:\data\/var/www/Запретить интерактивный вход (только сервисный).
Использовать групповые политики или мандатный контроль доступа (SELinux/AppArmor).
Пример из практики:
В Amazon Web Services пользователям рекомендуют создавать IAM-роли с минимальными правами для каждого сервиса (например, EC2 может читать только свой S3-бакет, а не все бакеты компании).
Что должен зафиксировать аналитик:
В требованиях к безопасности указать: «Каждый компонент системы должен функционировать с минимальными привилегиями, необходимыми для выполнения его задач».
Провести анализ необходимых прав для каждого сервиса.
Вывод: Принцип наименьших привилегий — краеугольный камень защищённой системы. Нарушение этого принципа многократно увеличивает ущерб от успешной атаки.
Please open Telegram to view this post
VIEW IN TELEGRAM
4884. Запрос в микросервисной системе проходит через 5 сервисов. При возникновении ошибки сложно понять,в каком именно сервисе и на каком этапе произошёл сбой. Какой инструмент позволяет отслеживать путь через все сервисы и измерять время в каждом?
Anonymous Quiz
17%
Метрики (Prometheus, Graphite)
51%
Распределённая трассировка (Jaeger, Zipkin)
29%
Логирование в централизованное хранилище (ELK)
3%
Зондирование (health checks)
В микросервисной архитектуре один запрос пользователя (например, «оформить заказ») может пройти через сервис заказов, сервис платежей, сервис доставки, сервис уведомлений, сервис аналитики. При ошибке стандартные логи каждого сервиса не позволяют восстановить полную картину, так как разные сервисы пишут в разные файлы, а временные метки могут быть рассинхронизированы. Невозможно узнать общее время выполнения и в каком узле возникла задержка.
Что такое распределённая трассировка:
Это метод мониторинга, который назначает каждому внешнему запросу уникальный trace ID. Этот ID передаётся через все сервисы в заголовках HTTP/gRPC. Каждый сервис при обработке запроса записывает span (отрезок работы: начало, конец, метаданные, возможная ошибка). Все спаны отправляются в центральный коллектор (Jaeger, Zipkin). Затем можно визуализировать полную временную диаграмму выполнения запроса, увидеть, сколько времени занял каждый вызов, и найти узкое место.
Как это помогает:
Локализация ошибки – видно, в каком сервисе возникла ошибка и на какой стадии.
Анализ производительности – можно найти медленные вызовы.
Зависимости сервисов – визуализация графа вызовов.
Пример работы (Jaeger):
Клиент отправляет запрос с заголовком
X-B3-TraceId: abc123Сервис А создаёт спаны для своих действий и вызывает сервис Б, передавая тот же trace ID.
Сервис Б делает то же самое.
В веб-интерфейсе Jaeger можно выбрать trace
abc123Почему не подходят другие варианты:
A (метрики, Prometheus) – показывают агрегированные данные (среднее время ответа сервиса, количество ошибок), но не индивидуальный путь запроса.
C (централизованное логирование, ELK) – можно связать логи по trace ID, но без временных отрезков и визуализации цепочки это менее удобно, требует ручного анализа.
D (health checks) – проверяют доступность сервиса, а не отслеживают запросы.
Реальный пример:
В Uber используется распределённая трассировка Jaeger для отладки сценариев поездок. Инженеры могут взять конкретный failed-запрос, посмотреть, что поиск водителя занял 10 секунд из-за задержки в сервисе геопозиционирования, и оптимизировать именно его.
Что должен зафиксировать аналитик:
Требование: «В архитектуре должна быть реализована распределённая трассировка с использованием стандартов OpenTelemetry».
Каждый сервис должен пробрасывать заголовки trace ID при вызовах.
Временные метки должны быть синхронизированы по всем узлам (NTP).
Вывод: Распределённая трассировка — обязательный компонент отказоустойчивых микросервисных систем, позволяющий видеть «путь» запроса и быстро находить проблемные зоны.
Please open Telegram to view this post
VIEW IN TELEGRAM
4885. Архитектору нужно показать заказчику, как система взаимодействует с внешними системами (платёжный шлюз, CRM, служба доставки). Какой уровень диаграммы из модели C4 для этого подходит?
Anonymous Quiz
37%
Диаграмма компонентов (Components)
46%
Диаграмма контекста (Context)
15%
Диаграмма контейнеров (Containers)
2%
Диаграмма классов (Code)
Модель C4 (Context, Containers, Components, Code) – это стандарт визуализации архитектуры программного обеспечения, предложенный Саймоном Брауном. Она состоит из четырёх уровней детализации:
Диаграмма контекста (System Context) – самый высокий уровень. Показывает систему как «чёрный ящик», её пользователей (акторов) и внешние системы, с которыми она взаимодействует. Этот уровень понятен даже не техническим стейкхолдерам (заказчикам, менеджерам).
Диаграмма контейнеров (Containers) – показывает основные технологические блоки: веб-приложения, базы данных, очереди сообщений, кэши. Внутренности контейнеров не детализируются.
Диаграмма компонентов (Components) – раскрывает внутреннее устройство контейнера, показывает компоненты (модули, сервисы) и их взаимодействие. Уровень для архитекторов и ведущих разработчиков.
Диаграмма классов (Code) – уровень кода (UML-диаграммы классов, ERD и т.д.) для разработчиков.
Решение для задачи:
Заказчику не нужны детали контейнеров, компонентов или классов. Ему важно понять, с какими внешними системами общается его будущая система и откуда приходят данные. Диаграмма контекста (уровень 1) идеально подходит: она проста, не содержит технических деталей и акцентирует внимание на границах системы и интеграциях.
Пример диаграммы контекста:
Прямоугольник «Система» (например, «Online Store»).
Люди (акторы) – «Покупатель», «Менеджер».
Внешние системы – «Платёжный шлюз», «Складская система», «Служба доставки».
Стрелки между ними – взаимодействие.
Почему не другие варианты:
A (компоненты) – слишком детально для заказчика, показывает внутренние модули.
C (контейнеры) – показывает, что система состоит из веб-сервера, БД и очереди, что заказчику не нужно.
D (классы) – уровень кода, не для бизнеса.
Реальный пример:
В проекте интеграции интернет-магазина с платёжной системой заказчик хотел понять, какие данные и куда передаются. Диаграмма контекста помогла ему быстро согласовать интеграционные потоки и утвердить архитектуру.
Что должен зафиксировать аналитик:
Для обсуждения с бизнесом использовать диаграмму контекста C4.
Для архитекторов и разработчиков – диаграммы контейнеров и компонентов.
Вывод: C4 позволяет подобрать правильный уровень детализации для каждой аудитории. Аналитик, владеющий C4, эффективно коммуницирует архитектуру разным стейкхолдерам.
Please open Telegram to view this post
VIEW IN TELEGRAM
4886. Разработчики не обращают внимания на выделенные CPU/RAM, ставят большие инстансы «на всякий случай». Какая практика управления затратами помогает оптимизировать использование ресурсов без изменения кода?
Anonymous Quiz
31%
Вертикальное масштабирование
57%
FinOps
9%
Ручной аудит счетов раз в месяц
3%
Миграция обратно в on-premise
В облачных средах (AWS, GCP, Azure) стоимость складывается из потреблённых ресурсов (CPU, RAM, хранилище, сеть). Разработчики часто выделяют ресурсы с запасом («возьму под 4 CPU, может пригодится»), забывая о деньгах. Без контроля счёт растёт экспоненциально. Финансовые и DevOps отделы не успевают за изменениями.
Что такое FinOps?
FinOps (Cloud Financial Operations) – это практика управления облачными затратами, объединяющая технические, финансовые и бизнес-процессы. Ключевые принципы:
Accountability – разработчики несут ответственность за стоимость своих ресурсов (каждый знает, сколько стоят его поды).
Visibility – прозрачность затрат в реальном времени (дашборды, алерты).
Optimization – использование правильных типов инстансов (spot, reserved, right-sizing), автоматическое выключение неиспользуемых сред по расписанию.
Конкретные действия для Kubernetes:
Установить
requestslimitsИспользовать Vertical Pod Autoscaler (рекомендует оптимальные запросы).
Включить Cluster Autoscaler, чтобы не держать лишние ноды.
Мониторинг неиспользуемых томов, балансировщиков, зарезервированных IP.
Алерты при превышении бюджета (например, если затраты на проект превысили 1000$ в день).
Пример настройки limits:
yaml
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
Без
limitsПочему не подходят другие варианты:
A (вертикальное масштабирование) – увеличит затраты.
C (ручной аудит раз в месяц) – слишком медленно, к тому моменту деньги уже потрачены.
D (миграция обратно в on-premise) – не решает проблему культуры использования ресурсов.
Реальный пример:
В компании одного стартапа счёт за облачные ресурсы вырос с $500 до $5000 в месяц после перехода на микросервисы. Внедрили FinOps: настроили алерты, стандартизировали
requests/limitsЧто должен зафиксировать аналитик:
В требования к архитектуре: «Каждый микросервис должен иметь явные requests и limits на CPU/RAM».
«Для нерабочих сред (dev, staging) настроить автоматическое выключение в нерабочее время».
«Дашборды затрат с детализацией до уровня пода и сервиса».
Вывод: FinOps – это не техническая опция, а требование к культуре разработки. Аналитик, включающий облачную экономику в нефункциональные требования, помогает бизнесу не переплачивать за неэффективное использование ресурсов.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
4887. В прод среде обнаружен баг: вместо имени пользователя отображается «NULL». Это происходит редко, только у 0.1% пользователей, но они не могут оформить заказ. Как правильно классифицировать дефект по Severity (серьёзность) и Priority (приоритет)?
Anonymous Quiz
8%
Severity = Low, Priority = Low
52%
Severity = High, Priority = Low
22%
Severity = High, Priority = High
18%
Severity = Medium, Priority = Medium
❤2
High – критическая функция не работает (например, оформление заказа).
Medium – функция работает с ограничениями.
Low – косметический дефект, не мешающий основной работе.
Priority (приоритет) – бизнес-характеристика, показывающая, как срочно нужно исправить дефект. Зависит от количества затронутых пользователей, потери выручки, репутационных рисков.
High – нужно исправить как можно быстрее (влияет на ключевой бизнес-процесс).
Medium – исправить в ближайший спринт.
Low – исправить при следующей возможности.
Применение к задаче:
Severity = High, потому что критическая функция (оформление заказа) недоступна для затронутых пользователей. Даже если процент мал, сам сценарий критичен.
Priority = High, потому что любой сбой в оформлении заказа ведёт к потере выручки и негативному опыту. Бизнес не станет ждать следующего релиза, чтобы исправить такое.
Ошибка, которую часто допускают:
Путают «малое количество пользователей» с низким приоритетом. Например, если баг затрагивает только VIP-клиентов (но их мало), приоритет всё равно высок, потому что бизнес теряет самых ценных клиентов.
Реальный кейс:
В интернет-магазине баг с отображением корзины возникал у 2% пользователей. Команда хотела отложить исправление на следующий релиз из-за низкого процента. Аналитик аргументировал, что для затронутых пользователей оформление заказа невозможно (Severity High), и эти пользователи могут уйти к конкурентам (Priority High). Баг исправили в течение дня.
Что должен зафиксировать аналитик:
В регламенте тестирования и приёмки: «Severity определяется по степени нарушения функциональности, Priority – по влиянию на бизнес».
Примеры классификации для разных типов дефектов.
Вывод: Severity и Priority – это разные измерения. Severity определяется техническим влиянием, Priority – бизнес-ценностью. Аналитик обязан уметь аргументировать оба параметра при согласовании исправлений с заказчиком.
Please open Telegram to view this post
VIEW IN TELEGRAM
Подборка Telegram-каналов по схеме ALL IN ONE 👁🗨
Тебе больше не нужно мониторить сотни источников в надежде найти адекватных авторов. Мы сделали это за тебя ✔️
Что внутри?
ПАПКА 👈 здесь, забирай - там реально круто
👉 Делимся знаниями и аудиторией — растём вместе ⚡️
Отписаться можно в любой момент. Остаться — тоже ✔️
* Ссылка ➡️ https://t.me/addlist/FYyQj91I8jJiMzg0
Тебе больше не нужно мониторить сотни источников в надежде найти адекватных авторов. Мы сделали это за тебя ✔️
Что внутри?
* ИИ — не хайп, а реальные инструменты и внедрения
* IT Технологии — тренды, обзоры, инсайты от первых лиц
* Карьера — как найти работу, вырасти и не выгореть
* HR Tech — кто и как нанимает сейчас профессионалов
* AI Life hacks — как выжить и зарабатывать за границей с помощью новых возможностей ИИ
ПАПКА 👈 здесь, забирай - там реально круто
👉 Делимся знаниями и аудиторией — растём вместе ⚡️
Отписаться можно в любой момент. Остаться — тоже ✔️
* Ссылка ➡️ https://t.me/addlist/FYyQj91I8jJiMzg0
🔥1