Как создавать задачи по системному проектированию, которые обучают инженеров оценке архитектурных компромиссов.

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

Это иллюстративный сценарий, а не задокументированный инцидент. Это ситуация, которую призвана отработать систематическая задача проектирования: проект, который был хорош при одних ограничениях, сталкивается с новыми, и инженеры должны обосновать или пересмотреть его, приведя аргументы. Это руководство предназначено для руководителей отделов обеспечения инженерной поддержки и менеджеров инженерных проектов. В нем рассматривается, что такое системная задача проектирования, как ее создать, как ее проводить и оценивать, и где обучение перестает быть решением. Каждый случай и каждый критерий должны быть проверены старшим инженером, прежде чем их использовать.

Что такое ката проектирования системы?

Ката по системному проектированию — это короткое, ограниченное по времени упражнение по проектированию. Небольшая команда получает бизнес-задачу, описанную в одном абзаце, набрасывает архитектуру, представляет её коллегам и отвечает на сложные вопросы. Её также называют архитектурной ката или архитектурным ката. Этот формат был разработан Тедом Ньюардом в качестве семинара и задокументирован, вместе с правилами и ролью модератора, на [ссылка на сайт]. Страница архитектурных ката Нила ФордаВ основе вопроса, который приводит Ньюард, лежит вопрос о том, как организациям воспитывать выдающихся архитекторов, если инженеры получают возможность заниматься архитектурой менее шести раз за карьеру. Ката дает им дополнительные повторения без риска для производительности.

Интересные факты

1. Опишите проблему с производительностью.

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

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

Напишите краткое описание производительности в одном предложении и попросите руководителя инженерного отдела проверить его: «При заданной архитектуре и измененном ограничении инженер указывает, что именно ломается, предлагает изменение, описывает компромисс и говорит о том, что ему еще неизвестно».

2. Диагностика пробелов в знаниях и контексте.

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

1. Используется ли в практике реальная задача? Если обучение строится на изучении закономерностей в отрыве от контекста, а оценка представляет собой тест с несколькими вариантами ответа, то никто не тренировался в защите своего выбора.
2. Какова когнитивная нагрузка? В пересмотренной таксономии Блума сравнение вариантов с учетом ограничений находится на уровне анализа и оценки, а предложение пересмотренного проекта достигает уровня создания. Наше руководство по соответствие учебных мероприятий таксономии Блума показывает, как соотнести задание с данным уровнем.
3. Что-то ещё, помимо навыков, мешает? Проверьте, есть ли у инженеров время на проектирование, кто принимает решения по архитектуре и зафиксированы ли требования. Если решение принимает кто-то вне команды, никакие задачи не изменят того, что команда может сделать. Передайте эти вопросы тем, кто может их решить.

3. Подготовка и практика проектирования

На каждом этапе следует отвести отдельную задачу.

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

Практикуйтесь. Проведите само упражнение «ката». В формате, описанном на сайте Нила Форда, после формирования команды упражнение проходит в три этапа: этап обсуждения, где команда определяет, что она будет создавать; этап взаимной оценки, где каждая команда представляет результаты и отвечает на вопросы; и этап голосования, где участники ставят «лайк» («справились на отлично»), «так себе» («упустили несколько моментов») или «дизлайк» («упустили очень сильно»). Некоторые правила стоит позаимствовать напрямую: команды могут делать предположения о незнакомых технологиях, но должны их озвучивать и не могут предполагать, что смогут нанять команду из одних звёзд.

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

Обратная связь. Связывайте отзывы с принятыми решениями, а не с общей оценкой. Фраза "Вы перешли на два региона, но не указали, что происходит с заказом, размещенным во время переключения" более полезна, чем "3 из 5".

Ввод данных в режиме реального времени или асинхронная проверка? Живое обсуждение наиболее эффективно, когда выбор неоднозначен, и инженеры учатся у старшего коллеги, который объясняет, почему они придерживаются той или иной позиции. Асинхронного обсуждения достаточно для сравнения письменного обоснования с аннотированным примером.

4. Проработайте реалистичный пример.

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

Дело. На региональном фестивале за выходные продается 20 000 билетов, причем большинство продаж приходится на первые десять минут. В первом варианте технического задания требуется сервис бронирования, способный справиться с таким пиком. Проектирование: один веб-уровень, одна база данных, обращение к платежному провайдеру при оформлении заказа.

Измененное ограничение. В середине мероприятия организатор добавляет: продажа билетов должна продолжаться, даже если один из центров обработки данных выйдет из строя, и ни один билет не может быть продан дважды.

Первая попытка. «Добавьте второй центр обработки данных и реплицируйте базу данных». Команда использовала знакомый компонент, но не уточнила, что произойдет с правилом предотвращения двойной продажи, когда два центра обработки данных не смогут взаимодействовать друг с другом.

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

Более убедительная попытка. «Мы будем соблюдать правило запрета двойной продажи. При разделении мест билеты продаются только на основном сайте, а на другом сайте отображается страница ожидания. Мы допускаем снижение доступности мест на короткое время, чтобы избежать продажи одного и того же места дважды. Мы предполагаем, что разделение мест происходит редко и кратковременно, и хотели бы, чтобы организатор подтвердил, что страница ожидания приемлема. Если им необходимо, чтобы билеты продавались на обоих сайтах, мы заранее выделим отдельные блоки мест для каждого сайта, ценой некоторого количества непроданных мест». Обратите внимание, что в этом ответе указан конфликт интересов, выбрана сторона, указаны издержки и отмечены неясные моменты.

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

5. Оценить возможности и спланировать передачу.

Доказательством компетентности является выполнение инженером нового, ранее не встречавшегося задания. Оценивается обоснование компромисса между результатами и реакция на новое ограничение. Простая оценочная шкала использует шкалу от 0 до 2 для каждого критерия:

Критерии оценки: 0 означает отсутствие или неподтвержденность, 1 — частичное выполнение с существенными упущениями, 2 — полное выполнение и обоснование в соответствии с согласованными критериями. Критические ошибки следует определять отдельно, например, игнорирование заявленных требований безопасности или защиты данных, чтобы общая оценка не могла их скрыть. Данная рубрика является предложением, а не утвержденным стандартом готовности: адаптируйте ее совместно с руководителем инженерного отдела и проведите пилотное тестирование. Наше руководство по разработка интерактивных методов обучения с полезной обратной связью Рассматривается, как писать отзывы, которые связаны с принятыми решениями.

Планируйте передачу задач обдуманно. После обсуждения попросите каждого инженера представить на совещание одно из принятых в ходе работы проектных решений и задать те же вопросы. Беспристрастный анализ прошлых инцидентов — еще один хороший способ перейти к реальной работе; см. наше руководство по этому вопросу. проведение невиновных проверок инцидентов.

Где интерактивная доставка помогает

Интерактивные форматы помогают, когда каждый участник должен подтвердить свое согласие до начала обсуждения в группе. На сессии «ката» в режиме реального времени модератор может показать измененное ограничение, попросить каждого члена команды написать, на какой компромисс они готовы пойти и почему, а затем показать результаты перед началом обсуждения. Голосование коллег в конце исходного формата легко провести аналогичным образом. Тот же кейс можно использовать в режиме самостоятельной подготовки или для инженеров, пропустивших сессию. AhaSlides поддерживает интерактивное обучение и переключение между режимом реального времени и самостоятельным обучением. Это инструмент для презентаций и обучения, а не место для рисования или построения архитектуры, поэтому храните диаграммы на доске или в инструменте проектирования. Проверьте любые конкретные функции создания, обратной связи или отчетности, которые вы планируете использовать, на соответствие вашему рабочему процессу. Для получения рекомендаций по выбору форматов см. нашу статью о Когда использовать адаптивное, интерактивное и обучение в режиме реального времени?.

Измерьте, что изменилось.

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

Ограничения, которые могут остаться

• Авторитет в области дизайна. Если команда не примет это решение, его отработка будет иметь ограниченный эффект.
• Время. На выполнение ката уходят часы; на создание реальных конструкций уходят недели, и для этого требуются данные, которые ката не может предоставить.
• Обзор дела. В одном из случаев рассматриваются некоторые компромиссы. Оценка не отражает в целом суждения инженера.
• Сложность. Большая сложность не обязательно означает лучшую архитектуру, поэтому не стоит поощрять наибольшее количество компонентов.
• Перевод. Успешное прохождение мастер-класса — это не то же самое, что успешное прохождение напряженного разбора задания, поэтому проверяйте свои результаты после выполнения упражнения, в реальных условиях.

Назовите эти проблемы спонсорам на раннем этапе и спланируйте отдельные исправления. Ката улучшает способность инженеров объяснять и защищать свои идеи. Она не создает авторитета и не экономит время.

Часто задаваемые вопросы

Что такое ката проектирования системы?

Краткое, ограниченное по времени проектное упражнение, в котором небольшая команда делает эскиз архитектуры для решения бизнес-задачи, представляет его коллегам и отвечает на сложные вопросы. Его также называют архитектурной ката.

Сколько человек должно быть в команде?

Первоначальный формат предполагает работу в небольших группах по 3-5 человек, обычно в одной из 4-10 групп в помещении. Используйте группы достаточно малого размера, чтобы каждый мог высказаться.

Как оценить задачу по проектированию системы?

Представьте новый сценарий и обоснуйте компромисс между оценкой и результатом, а также реакцию на изменение ограничения в соответствии с согласованными критериями. Голосование коллег — полезная обратная связь, но само по себе не является оценкой.

Когда начать

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

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