Системный аналитик

Как пройти маршрут

Начинайте без опыта в профессии. Результат маршрута — спецификация системы с API, моделью данных и проверяемыми сценариями. Переходите дальше, когда можете выполнить задание и объяснить результат.

Здесь 16 основных шагов и 3 шага углубления. Это самостоятельная часть единой программы аналитических профессий: другие карты проходить заранее не нужно. Разделы с одинаковой базой можно пропустить только после решения их задания без подсказки. Фиксированного срока и гарантии трудоустройства нет.

Работайте в цикле: прочитайте объяснение → попробуйте пример → выполните задание → откройте разбор → исправьте ошибку → сохраните результат. Одна отметка может потребовать нескольких занятий. Записывайте время и трудности первых трёх шагов, затем планируйте посильный темп. Обязательные задания основной части выполняются бесплатно. Для локальных программ нужен компьютер; ограничения ОС и доступа указаны в шагах.

Кейс «Круг» и данные вымышлены. На маленькой таблице удобно проверить вычисления руками; она не доказывает спрос, причинность или качество ML-модели. В самостоятельном проекте предстоит изменить данные и требования. Не загружайте реальные персональные или рабочие данные в публичные тренажёры.

Основной текст русский. Для английской документации ведите словарь: термин, смысл своими словами, пример. Перевод браузера допустим, но названия полей и код не переводите. Начните с одного абзаца документации за занятие и постепенно переходите к самостоятельному чтению.

Шаг 1. Подготовить рабочее место и словарь

Разберём на примере

Сервис «Круг» сдаёт учебные комнаты по времени. Это вымышленный кейс: все числа и записи созданы для обучения. Начните с файлов, чтобы уметь повторить работу на другом компьютере. CSV — текстовая таблица: первая строка содержит имена столбцов, последующие строки — записи. Расширение файла обозначает его формат; переименование картинки в CSV таблицу не создаёт. В наших данных одна строка — одно бронирование, суммы хранятся целым числом евроцентов, даты — как год-месяц-день.

Скачать вымышленные бронирования (CSV). Для SQL позже понадобится готовая схема и те же строки.

Что прочитать и посмотреть

1. LibreOffice: CSV — Импорт CSV: разделитель, кодировка и типы столбцов. Бесплатная справка, английский; приложение LibreOffice бесплатно.

Что сделать

1. Создайте папку krug и внутри raw, work, results. Скачайте bookings.csv по ссылке в этом разделе и сохраните в raw; исходник больше не редактируйте.
2. Откройте CSV в LibreOffice Calc: кодировка UTF-8, разделитель — запятая. Проверьте восемь столбцов и шесть строк данных. Сохраните рабочую копию в work в формате ODS.
3. Создайте словарь с полями: столбец, смысл, тип, допустимые значения, единица измерения. Запишите вопросы о неизвестных правилах; не подставляйте догадки.

Что сохранить

Таблица, словарь восьми полей и журнал вопросов в results.

Как проверить себя

Снова откройте сохранённую таблицу. Идентификаторы u1 и A сохранились как текст, суммы 2000 не превратились в 20. Дата читается однозначно.

Шаг 2. Определить границы системы и роли участников

Разберём на примере

Пользователь «Круга» выбирает комнату, сайт передаёт запрос серверу, сервер проверяет доступность и сохраняет бронь. Системный аналитик описывает, как части решения должны взаимодействовать. Бизнес-цель «меньше двойных бронирований» ещё не объясняет разработчику, что делать при двух одновременных запросах. Сначала определите границу: наш сервис управляет бронями, внешний платёжный сервис подтверждает оплату. Интерфейс — согласованный способ общения двух участников; это может быть экран человека или API для программы.

Что прочитать и посмотреть

1. C4 model — System context и Container diagram: границы системы и крупные приложения. Бесплатно, английский; рисунок можно сделать на бумаге.
2. MDN: клиент и сервер — Запрос, ответ, сервер и база данных. Бесплатно, английский.

Что сделать

1. Нарисуйте контекст: клиент, администратор, сервис бронирований и внешний платёжный сервис. Подпишите цель каждого обмена.
2. Раскройте сервис на браузер, серверное приложение и базу. Для каждой части напишите одну ответственность и данные, которыми она владеет.
3. Составьте словарь: бронь, временное удержание слота, оплата, отмена. Запишите пять вопросов, ответы на которые меняют устройство системы.

Что сохранить

Две схемы и словарь с открытыми вопросами.

Как проверить себя

База не посылает пользователю экран сама; браузер не считается единственным местом проверки занятости.

Шаг 3. Записать проверяемые требования

Разберём на примере

Требование описывает нужное поведение или ограничение. Функциональное требование говорит, что делает система; нефункциональное задаёт проверяемое качество, например задержку при определённой нагрузке. «Работает быстро» нельзя однозначно принять. У требования должны быть источник, идентификатор, причина, приоритет и способ проверки. Интервью в упражнении вымышленное: администратор говорит «когда оплата зависла, люди звонят мне». Это наблюдение, а не готовое техническое решение.

Что прочитать и посмотреть

1. IREB CPRE: материалы — Foundation Level syllabus: принципы требований, рабочие продукты и управление требованиями. Английский; каталог открыт, скачивание отдельных материалов может потребовать бесплатный аккаунт Cockpit.

Что сделать

1. Напишите пять уточняющих вопросов администратору. Разделите подтверждённое условие, допущение и неизвестный ответ.
2. Опишите сценарий бронирования: участник, предусловия, шаги, результат, отказ при занятом слоте и отсутствие ответа платёжного сервиса.
3. Создайте требования R-01…R-05 с источником и тестом. Для R-01 задайте: два клиента пытаются занять один слот, подтверждена максимум одна бронь.

Что сохранить

Сценарий, таблица требований и журнал вопросов.

Как проверить себя

Тест можно выполнить и получить наблюдаемый ответ. Внутреннее устройство не навязано там, где достаточно описать поведение.

Шаг 4. Описать процесс и состояния брони

Разберём на примере

Процесс показывает действия участников во времени; состояние показывает, что сейчас разрешено делать с конкретной бронью. Не смешивайте эти вопросы на одной схеме. В BPMN задача обозначает работу, событие — наступивший факт, развилка — выбор пути. Пулы разделяют участников, сообщения пересекают их границы. Для брони зададим состояния pending, confirmed, cancelled, expired. Таблица переходов часто понятнее большого рисунка: исходное состояние, событие, условие, новое состояние и побочный эффект.

Что прочитать и посмотреть

1. Camunda: BPMN primer — События, задачи, exclusive gateway, pools и message flow. Бесплатно, английский; Camunda устанавливать не нужно.

Что сделать

1. На бумаге нарисуйте процесс: запрос слота, удержание, запрос оплаты, подтверждение либо истечение 10 минут. Обозначьте внешнего платёжного участника отдельным пулом.
2. Создайте таблицу переходов. Для pending + payment_succeeded опишите проверку срока и переход в confirmed.
3. Разберите оплату после expired и повтор payment_succeeded после confirmed. Сформулируйте, какой вопрос нужно согласовать с бизнесом.

Что сохранить

Схема процесса и таблица допустимых и запрещённых переходов.

Как проверить себя

Для повторного события нет второй брони; для поздней оплаты явно задана дальнейшая обработка.

Шаг 5. Получать строки и итоги с помощью SQL

Разберём на примере

SQL — язык запросов к таблицам. SELECT выбирает столбцы, WHERE оставляет строки по условию, GROUP BY объединяет строки для расчёта итогов. COUNT(*) считает строки; COUNT(column) пропускает NULL — неизвестные значения. Начинайте с маленького набора, в котором можете проверить каждый результат руками. Учебные запросы выполняются в SQLite Fiddle; PostgreSQL появится отдельно там, где нужны его особенности.

SELECT room_id, SUM(charged_cents-refund_cents) AS net_cents
FROM bookings WHERE status='completed'
GROUP BY room_id ORDER BY room_id;

Что прочитать и посмотреть

1. SQLBolt — Уроки 1–12: SELECT, условия, JOIN, NULL и группировка. Выполните встроенные задания. Бесплатно, английский, без установки.
2. SQLite Fiddle — Официальная SQL-песочница: вставьте учебный SQL и нажмите Run. Бесплатно, английский интерфейс; работаем только с вымышленными данными.

Что сделать

1. Пройдите SQLBolt 1–5 и 10–12. Затем откройте SQLite Fiddle, вставьте содержимое bookings.sql из первого шага и выполните его один раз в пустой базе.
2. Напишите SELECT для completed, затем итог net_cents по комнате. Используйте SUM(charged_cents-refund_cents).
3. Добавьте условие day >= '2026-09-02'. Объясните, почему фильтр по строкам ставится до группировки. Сохраните запросы в results/queries.sql.

Что сохранить

Три SQL-запроса и таблица ожидаемых результатов.

Как проверить себя

Без фильтра итог A равен 6000, B — 7000 евроцентов. После фильтра даты A=2000, B=7000. Укажите, какие строки сформировали результат.

Шаг 6. Соединять таблицы без потери и удвоения строк

Разберём на примере

Справочник хранит описание объекта один раз: код A соответствует комнате «Тихая». Первичный ключ уникально называет запись; внешний ключ связывает запись с другим объектом. JOIN сопоставляет строки по условию. Если одному бронированию соответствуют два платежа, после соединения оно появится дважды. Поэтому перед соединением назовите зерно обеих таблиц — что означает одна строка. LEFT JOIN сохраняет строки слева даже без пары; INNER JOIN оставляет только совпадения.

Что прочитать и посмотреть

1. SQLBolt — Уроки 1–12: SELECT, условия, JOIN, NULL и группировка. Выполните встроенные задания. Бесплатно, английский, без установки.
2. PostgreSQL: учебник — Разделы The SQL Language и Advanced Features: таблицы, соединения, внешние ключи, транзакции. Бесплатно, английский; команды PostgreSQL не переносите в SQLite без проверки.

Что сделать

1. Пройдите SQLBolt 6–9. Создайте rooms(room_id TEXT PRIMARY KEY, name TEXT) и добавьте A/Тихая, B/Большая.
2. Соедините bookings и rooms. Сверьте COUNT(*) и сумму net_cents до и после соединения.
3. В отдельной CTE создайте платежи (1,1000),(1,1000),(2,2000). Соедините с bookings и объясните, почему сумма charged_cents теперь не является суммой всех бронирований. Сначала сгруппируйте платежи по booking_id.

Что сохранить

Запрос с соединением, проверками количества строк и пояснением отношения «один ко многим».

Как проверить себя

Со справочником остаются 6 строк и 13000 евроцентов net. В варианте с платежами бронирование 1 повторяется; проверка это обнаруживает.

Шаг 7. Спроектировать сущности и ограничения данных

Разберём на примере

В исходном CSV пользователь и комната повторяются. Для системы записи выделите users, rooms, slots и bookings. Первичный ключ отличает запись; внешний ключ связывает её с существующей записью другой таблицы. Нормализация помогает не хранить одно изменяемое значение в нескольких местах: название комнаты достаточно держать в rooms. Упрощённый кейс использует заранее созданные непересекающиеся слоты. Проверка произвольных временных интервалов сложнее, чем уникальность slot_id.

Что прочитать и посмотреть

1. PostgreSQL: учебник — Разделы The SQL Language и Advanced Features: таблицы, соединения, внешние ключи, транзакции. Бесплатно, английский; команды PostgreSQL не переносите в SQLite без проверки.

Что сделать

1. Нарисуйте ER-схему — сущности и связи. Укажите ключи, типы, обязательность полей и связи один-ко-многим.
2. Создайте в SQLite таблицы rooms и slots с внешним ключом; включите PRAGMA foreign_keys=ON. Попробуйте добавить слот несуществующей комнаты.
3. Отдельно создайте active_reservations(slot_id PRIMARY KEY, booking_id UNIQUE). Объясните, как это ограничивает занятость готового слота и почему историю отмен хранить нужно отдельно.

Что сохранить

ER-схема, DDL-файл создания таблиц и два отрицательных примера.

Как проверить себя

Ссылка на отсутствующую комнату отклоняется; два активных удержания одного slot_id не помещаются в таблицу.

Шаг 8. Разобраться в HTTP и JSON

Разберём на примере

API — договор, по которому одна программа обращается к другой. В HTTP запрос имеет метод, адрес, заголовки и иногда тело. Ответ содержит код состояния и данные. GET читает ресурс; POST часто создаёт новый. JSON представляет объекты, массивы, строки, числа, true, false и null. Строка "120" отличается от числа 120, а отсутствующее поле отличается от явного null. Транспортное шифрование HTTPS не решает, имеет ли конкретный пользователь право отменять чужую бронь.

Что прочитать и посмотреть

1. MDN: клиент и сервер — Запрос, ответ, сервер и база данных. Бесплатно, английский.
2. MDN: коды HTTP — Прочитайте 200, 201, 400, 401, 403, 404, 409 и 500. Бесплатно, английский.
3. OpenAPI 3.0: структура — OpenAPI, paths, requestBody, responses и components. Бесплатная документация, английский; в упражнениях используем версию 3.0.3.

Что сделать

1. Откройте инструменты разработчика браузера, вкладку Network, и обновите эту страницу. Найдите метод, путь и код ответа одного документа. Не копируйте cookie или токены.
2. Напишите пример тела создания брони: slot_id, user_id и количество участников. Определите тип и обязательность каждого поля.
3. Подготовьте ответы: создано, неверное тело, нет аутентификации, запрещён доступ, слот занят, временная ошибка сервиса. Объясните разницу 401, 403 и 409.

Что сохранить

Примеры запросов и ответов с пояснением полей.

Как проверить себя

JSON использует двойные кавычки и не содержит комментариев. В каждом ошибочном ответе есть стабильный code и понятное message.

Шаг 9. Составить контракт OpenAPI

Разберём на примере

OpenAPI описывает операции HTTP API в машиночитаемом документе. Документ не запускает сервер, но помогает согласовать поля и проверить примеры. Зафиксируйте версию спецификации: в упражнении 3.0.3. В этой версии описание nullable отличается от JSON Schema в новых версиях, поэтому не смешивайте примеры из разных руководств. Для минимального контракта нужны info, paths, методы, ответы и схемы данных. Сначала согласуйте один полный сценарий, затем расширяйте.

Что прочитать и посмотреть

1. OpenAPI 3.0: структура — OpenAPI, paths, requestBody, responses и components. Бесплатная документация, английский; в упражнениях используем версию 3.0.3.

Начальная операция чтения показана ниже. Сохраните её как api.json и дополните созданием брони. Ключ paths содержит адреса, get — описание метода, responses — возможные ответы.

{
  "openapi": "3.0.3",
  "info": {
    "title": "Krug learning API",
    "version": "1.0.0"
  },
  "paths": {
    "/bookings/{booking_id}": {
      "get": {
        "parameters": [
          {
            "name": "booking_id",
            "in": "path",
            "required": true,
            "schema": {
              "type": "integer",
              "minimum": 1
            }
          }
        ],
        "responses": {
          "200": {
            "description": "Бронь найдена",
            "content": {
              "application/json": {
                "schema": {
                  "type": "object",
                  "required": [
                    "booking_id"
                  ],
                  "properties": {
                    "booking_id": {
                      "type": "integer"
                    }
                  }
                }
              }
            }
          },
          "404": {
            "description": "Бронь не найдена"
          }
        }
      }
    }
  }
}

Что сделать

1. Создайте api.json по примеру Basic Structure из справки: openapi="3.0.3", info с title и version, paths. Начните с GET /bookings/{booking_id}.
2. Добавьте POST /bookings: requestBody, required-поля, ответы 201, 400 и 409. Для параметра пути обязательно укажите in="path" и required=true.
3. Добавьте примеры корректного тела, пропущенного slot_id и отрицательного participants. Проверьте документ в локальном редакторе JSON либо вручную по структуре справки; внешний редактор допустим только с учебными данными.

Что сохранить

api.json и таблица примеров «должен пройти / должен быть отклонён».

Как проверить себя

Операция содержит успешный и ошибочный результат; поля обязательны одинаково в тексте и схеме. Описание не называется работающим API.

Шаг 10. Показать последовательность взаимодействий

Разберём на примере

Диаграмма последовательности UML показывает участников и порядок сообщений сверху вниз. Линия жизни соответствует участнику, стрелка — сообщению. Ветвь alt разделяет альтернативные исходы, loop обозначает повтор. Начните с текстовой последовательности и только затем оформляйте схему. Важно увидеть, в какой момент система сохранила состояние и что произойдёт, если ответ потеряется после сохранения.

Что прочитать и посмотреть

1. OMG UML 2.5.1 — первичная спецификация нотации, раздел Interactions: Lifelines, Messages, CombinedFragments. Бесплатно, английский; используйте как справочник обозначений после примера в этом уроке.
2. C4 model — System context и Container diagram: границы системы и крупные приложения. Бесплатно, английский; рисунок можно сделать на бумаге.
3. MDN: клиент и сервер — Запрос, ответ, сервер и база данных. Бесплатно, английский.

Клиент            API                 База            Оплата
  | -- запрос ---> |                    |                |
  |                | -- pending ------->|                |
  |                | <-- сохранено -----|                |
  |                | -- запрос оплаты ------------------>|
  |                | <-- подтверждение ------------------|
  |                | -- confirmed ----> |                |
  |                | <-- сохранено -----|                |
  | <-- результат -|                    |                |

В этой упрощённой последовательности к платёжному сервису обращается API. База только сохраняет состояние. Добавьте к схеме ошибочные ветви из задания.

Что сделать

1. Запишите цепочку: клиент → API; API → база → API; API → платёжный сервис → API; API → клиент. Для каждого сообщения укажите данные и ожидаемый ответ.
2. Нарисуйте участников вертикальными линиями на бумаге. Добавьте альтернативы «слот занят» и «внешняя оплата не ответила».
3. Отметьте место сохранения pending, затем смоделируйте потерю ответа клиенту. Запишите, почему повтор POST опасен без правила распознавания повтора.

Что сохранить

Схема успешного и двух ошибочных сценариев.

Как проверить себя

Внешняя оплата не изображена как мгновенная операция внутри локальной базы. У неизвестного результата оплаты отдельное состояние обработки.

Шаг 11. Описать асинхронные сообщения и повторы

Разберём на примере

При асинхронном обмене отправитель не ждёт немедленного завершения всей работы. Сообщение PaymentSucceeded может прийти позже или повторно. Идемпотентная обработка означает, что повтор одной операции не меняет результат повторно. Для распознавания используйте event_id, для связи процесса — booking_id, для версии структуры — schema_version. Порядок событий не всегда совпадает с порядком доставки; время события отличается от времени получения.

Что прочитать и посмотреть

1. Apache Kafka: документация — Introduction и Quickstart: topic, partition, producer, consumer. Выберите документацию своей версии. Бесплатно, английский.
2. MDN: клиент и сервер — Запрос, ответ, сервер и база данных. Бесплатно, английский.

Что сделать

1. Составьте контракт сообщения с event_id, booking_id, occurred_at, schema_version и суммой в евроцентах.
2. В таблице проиграйте доставку e1, e1 ещё раз, затем более раннего e0. Для каждого укажите проверку, изменение состояния и ответ обработчика.
3. Опишите ограниченные повторы временной ошибки, паузу между попытками и отдельную очередь или журнал проблемных сообщений с ответственным за разбор.

Что сохранить

Контракт события и таблица обработки дублей, задержек и неверной версии.

Как проверить себя

Повтор e1 не даёт вторую оплату; постоянная ошибка не повторяется бесконечно. Потеря подтверждения не объявляется потерей самой операции.

Шаг 12. Разобрать транзакции и одновременные запросы

Разберём на примере

Транзакция объединяет изменения: они фиксируются вместе или откатываются. Но два отдельных запроса «прочитать свободно» и «занять» могут столкнуться с конкурентным запросом. Нарисуйте два клиента: оба увидели свободный слот до записи другого. Надёжность должна обеспечиваться на стороне данных согласованным ограничением или блокировкой и корректной обработкой отказа. Уровни изоляции определяют, какие изменения других транзакций видны; поведение зависит от конкретной СУБД.

Что прочитать и посмотреть

1. PostgreSQL: учебник — Разделы The SQL Language и Advanced Features: таблицы, соединения, внешние ключи, транзакции. Бесплатно, английский; команды PostgreSQL не переносите в SQLite без проверки.
2. PostgreSQL: изоляция транзакций — Read Committed, Repeatable Read и Serializable: прочитайте пример конкурирующих операций. Бесплатно, английский; это поведение PostgreSQL, не всех баз сразу.

Что сделать

1. Составьте таблицу времени для клиентов A и B: чтение, проверка, запись. Найдите окно гонки.
2. В SQLite-песочнице вставьте две записи одного slot_id в active_reservations. Зафиксируйте ошибку уникальности и сопоставьте её с ответом 409 вашего API.
3. Опишите атомарное создание брони и удержания, затем случай сбоя перед commit. Для PostgreSQL прочитайте пример Serializable и запишите необходимость повторить целую транзакцию при соответствующем конфликте.

Что сохранить

Разбор гонки, правило целостности и сценарий отката.

Как проверить себя

Предварительное чтение не названо гарантией уникальности. Повтор выполняется ограниченно и только для предусмотренных ошибок.

Шаг 13. Задать безопасность и наблюдаемость

Разберём на примере

Аутентификация проверяет, кто обращается; авторизация — что ему разрешено. Владелец брони и администратор имеют разные права. Лог — запись технического события; метрика — числовое наблюдение во времени; идентификатор запроса помогает связать записи. Наблюдаемость нужна, чтобы понять, где задержалась бронь. В журнале полезны request_id, операция, время, статус и длительность; секреты доступа и полные платёжные данные там не нужны.

Что прочитать и посмотреть

1. MDN: клиент и сервер — Запрос, ответ, сервер и база данных. Бесплатно, английский.
2. MDN: коды HTTP — Прочитайте 200, 201, 400, 401, 403, 404, 409 и 500. Бесплатно, английский.

Что сделать

1. Создайте матрицу прав для гостя, владельца и администратора: читать, создавать, отменять бронь, менять расписание.
2. Для GET чужой брони и повторного использования старого токена опишите ожидаемую проверку на сервере. Решение 403 или сокрытие существования через 404 согласуйте явно.
3. Запишите три измеримых критерия: задержка чтения, доля технических ошибок и время обнаружения сбоя. Для каждого задайте способ измерения и пример записи лога без секретов.

Что сохранить

Матрица доступа, критерии качества и формат безопасного лога.

Как проверить себя

Запрет действует по данным и роли на сервере; скрытая кнопка не является проверкой права.

Шаг 14. Связать требования, тесты и изменения

Разберём на примере

Матрица трассировки показывает путь от требования до реализации и проверки. Например, R-01 об одной активной брони связан с ограничением slot_id, ответом 409 и тестом двух клиентов. При изменении правила можно найти затронутые элементы. Критерий приёмки описывает наблюдаемое поведение; тест добавляет вход, шаги и ожидаемый выход. Аналитик должен проверить и удачный путь, и ограничения, и пограничные случаи.

Что прочитать и посмотреть

1. IREB CPRE: материалы — Foundation Level syllabus: принципы требований, рабочие продукты и управление требованиями. Английский; каталог открыт, скачивание отдельных материалов может потребовать бесплатный аккаунт Cockpit.

Что сделать

1. Для R-01…R-05 составьте таблицу: требование, схема или операция, данные, тест и статус согласования.
2. Напишите восемь тестов: обычная бронь, занятый слот, пустое поле, неверный тип, чужой пользователь, повтор, поздняя оплата и сбой до фиксации.
3. Измените время удержания с 10 до 15 минут. Найдите тексты, таймеры, сообщения и тесты, которые затронуты. Отделите изменение значения от изменения самого правила.

Что сохранить

Матрица трассировки, тест-кейсы и записка влияния изменения.

Как проверить себя

Нет требования без проверки и проверки без объяснимой цели. Граница ровно 15 минут определена однозначно.

Шаг 15. Передать самостоятельную спецификацию команде

Разберём на примере

Итоговый кейс — вымышленная выдача настольных игр: одна выдача может содержать несколько экземпляров, часть возвращают раньше. Это меняет зерно данных и состояния отдельных предметов. Соберите документ, по которому другой человек может объяснить реализацию и написать тест. Рабочая спецификация связывает части через идентификаторы и примеры; объём текста сам по себе не делает её полной.

Что прочитать и посмотреть

1. OpenAPI 3.0: структура — OpenAPI, paths, requestBody, responses и components. Бесплатная документация, английский; в упражнениях используем версию 3.0.3.
2. Camunda: BPMN primer — События, задачи, exclusive gateway, pools и message flow. Бесплатно, английский; Camunda устанавливать не нужно.
3. IREB CPRE: материалы — Foundation Level syllabus: принципы требований, рабочие продукты и управление требованиями. Английский; каталог открыт, скачивание отдельных материалов может потребовать бесплатный аккаунт Cockpit.

Что сделать

1. Составьте контекст, словарь, два сценария, ER-схему и таблицу состояний выдачи и её предмета.
2. Опишите API создания выдачи и частичного возврата, ошибки, права и повтор одного запроса. Согласуйте поведение для двух клиентов на последний экземпляр.
3. Попросите проверяющего добавить условие продления срока одного предмета. Оцените влияние, обновите контракт и тесты. Проведите 20-минутный разбор: проверяющий пытается найти неуказанный исход.

Что сохранить

Связанный пакет спецификации, журнал решений и тесты после изменения.

Как проверить себя

Документ объясняет частичный возврат без потери остальных предметов. При отсутствии внешнего разбора этот пункт остаётся открытым.

Шаг 16. Проверить готовность и выбрать вакансии

Разберём на примере

Название «Systems / Functional Analyst» не задаёт одинаковые обязанности во всех компаниях. Сравнивайте задачи, уровень самостоятельности, язык команды и условия работы. Европа — основной ориентир этой программы; вакансии РФ помогают увидеть совпадения и отличия. Старшие вакансии показывают дальнейшее развитие, но не превращают весь их список в обязательный входной порог. Диплом, местный язык и опыт могут быть отдельными условиями работодателя. Учебный проект не заменяет коммерческий опыт.

Что прочитать и посмотреть

1. Pro Git — Главы «Основы Git»: создание репозитория, запись изменений, история, отмена изменений. Бесплатный текст на русском.

Что сделать

1. Соберите пять свежих европейских и три российских вакансии. Запишите дату, страну, реальный уровень по обязанностям, обязательные требования и пожелания в разные столбцы. Обновляйте ссылки перед откликом.
2. Для каждого требования приложите своё доказательство: сценарии, модель данных, контракт API, разбор гонки и матрица тестов. Отметьте «делал самостоятельно», «с подсказкой» или «пока не делал». Выберите три пробела и задания для их закрытия.
3. Попросите знакомого провести 20-минутное собеседование по вашему проекту. Объясните задачу на русском и кратко на английском: problem, method, result, limitation. Выполните новое небольшое задание без готового решения и запишите, где потребовалась помощь.

Что сохранить

Матрица вакансий, портфолио из собственных файлов и план закрытия трёх пробелов.

Как проверить себя

Другой человек может открыть проект, повторить ключевой результат и задать вопрос о неудачном варианте. В резюме учебные проекты обозначены как учебные.

Шаг 17. Спроектировать совместимое изменение интеграции

Разберём на примере

Две команды выпускают версии в разные дни. Переименование обязательного поля ломает старого клиента. Совместимость нужно оценивать по направлению: новый сервер со старым клиентом и новый клиент со старым сервером. Даже добавление значения перечисления может сломать клиента с исчерпывающим выбором. Миграцию удобно разделить на расширение, переход и удаление после подтверждения использования.

Что прочитать и посмотреть

1. OpenAPI 3.0: структура — OpenAPI, paths, requestBody, responses и components. Бесплатная документация, английский; в упражнениях используем версию 3.0.3.
2. IREB CPRE: материалы — Foundation Level syllabus: принципы требований, рабочие продукты и управление требованиями. Английский; каталог открыт, скачивание отдельных материалов может потребовать бесплатный аккаунт Cockpit.

Что сделать

1. Измените participants на список attendees в контракте. Составьте матрицу старых и новых версий клиента и сервера.
2. Опишите переходный период и способ определить, кто ещё использует старое поле. Подготовьте примеры обоих форматов.
3. Добавьте план отката и тест, доказывающий, что данные после нового формата не теряются при возврате сервера.

Что сохранить

План миграции и контрактные примеры.

Как проверить себя

Удаление старого поля имеет условие и ответственного. Откат учитывает уже записанные данные.

Шаг 18. Разобрать согласованность нескольких систем

Разберём на примере

Сохранение брони и отправка события в отдельный брокер не становятся одной транзакцией автоматически. Outbox — таблица исходящих сообщений, записываемая вместе с бизнес-изменением в той же базе; отдельный процесс доставляет их дальше. Сбой после отправки, но до отметки доставки, оставляет повтор. Компенсация — новое действие, исправляющее бизнес-последствие, например возврат оплаты; она не стирает историю.

Что прочитать и посмотреть

1. Apache Kafka: документация — Introduction и Quickstart: topic, partition, producer, consumer. Выберите документацию своей версии. Бесплатно, английский.
2. PostgreSQL: учебник — Разделы The SQL Language и Advanced Features: таблицы, соединения, внешние ключи, транзакции. Бесплатно, английский; команды PostgreSQL не переносите в SQLite без проверки.

Что сделать

1. Нарисуйте запись брони и outbox в одной транзакции. Добавьте отдельного отправителя и получателя с проверкой event_id.
2. Проверьте сбой до commit, после commit, после отправки и до отметки доставки. Для каждого укажите, что сохранено и что повторится.
3. Опишите компенсацию оплаты при невозможности подтвердить бронь и ручной разбор неудачной компенсации.

Что сохранить

Таблица отказов и план восстановления.

Как проверить себя

Повторы допустимы и безопасно обработаны; обещание «ровно один раз во всей системе» не сделано без доказательства.

Шаг 19. Выбрать техническую специализацию

Разберём на примере

Следующий уровень требует работы с реальными ограничениями команды. Возможные направления — интеграции, банковские системы, платформы данных или архитектурный анализ. Сравнивайте решения по требованиям, стоимости изменения и рискам, а не по числу технологий. Запись архитектурного решения содержит контекст, варианты, выбранное решение, последствия и условие пересмотра.

Что прочитать и посмотреть

1. C4 model — System context и Container diagram: границы системы и крупные приложения. Бесплатно, английский; рисунок можно сделать на бумаге.
2. IREB CPRE: материалы — Foundation Level syllabus: принципы требований, рабочие продукты и управление требованиями. Английский; каталог открыт, скачивание отдельных материалов может потребовать бесплатный аккаунт Cockpit.

Что сделать

1. Для нового проекта сравните синхронную и асинхронную интеграцию по сроку ответа, отказам и сложности сопровождения.
2. Запишите решение на одной странице и сценарий, при котором его придётся пересмотреть.
3. Выберите две компетенции по пяти вакансиям и составьте по одному проекту. Проверьте предложенную AI спецификацию на противоречивые статусы, потерянные ошибки и недоказанную безопасность.

Что сохранить

Запись решения и план двух проектов.

Как проверить себя

Вы можете объяснить отказ от одного варианта и цену принятого компромисса.