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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда начать

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

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