Стройте для сегодняшнего дня. Планируйте на завтра. Планируйте на случай сбоя.

🌐 Также доступно на 28 языках

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 5 из 7 главы Думать как архитектор данных, глава 1 курса Data Architect. Каждый модуль самостоятелен. Назад: Архитектура — искусство компромиссов · Далее: Знайте свои инструменты: девять вопросов

Вопрос, на который отвечает этот модуль: Как проектировать под сегодняшние требования, планируя при этом рост и сбои?

Одна из самых легких ошибок в архитектуре — проектировать только под требования, которые лежат перед вами. У нас есть проект, бэклог и требования. Мы строим то, что им отвечает. Оно работает, и мы объявляем победу. Через полгода меняется бизнес, или вырастают данные, или другое подразделение хочет этим пользоваться, или мы покупаем компанию, или нужно интегрировать новую систему, или ломается то, к чему никто не готовился.

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

Стройте для сегодняшнего дня. Планируйте на завтра. Планируйте на случай сбоя.

Нужны все три.

Click to enlarge

Стройте для сегодняшнего дня

Архитектура начинается с проблемы, которая у нас действительно есть. Звучит очевидно, но архитекторы могут совершить ошибку, противоположную краткосрочному мышлению: мы можем переусложнить архитектуру. А что, если мы купим двенадцать компаний, у нас будет миллиард клиентов, мы выйдем в 40 стран и каждой системе понадобится интеграция в реальном времени? Может быть. Но это реальные возможности или мы выдумываем проблемы? Архитектура — это не построение самой изощренной системы, какую можно вообразить. Это построение уместной.

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

Ищите подразумеваемые требования

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

Бизнес говорит: «Нам нужны данные клиентов в Salesforce». Хорошо. Значит, кто-то должен владеть этими данными и решить, насколько свежими они должны быть. Нам нужно знать, что будет, когда система-источник недоступна, как мы заметим, что синхронизация сломалась, и какая сторона побеждает, когда Salesforce и источник расходятся. Нам нужен срок хранения, модель доступа, решение о чувствительных полях и способ исправлять плохие данные.

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

Знайте свои цифры

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

Когда лучшей цифры у меня нет, моя базовая оценка — 30 % роста в год. Это не прогноз; это способ заставить подумать. Если мне говорят, что сегодня у нас 10 млн записей, я не хочу, чтобы обсуждение остановилось на 10 млн. При 30 % в год у нас будет примерно 13 млн в следующем году, 17 млн через год и около 22 млн еще через год. Вот теперь давайте поговорим о проекте. Если бизнес говорит мне, что 30 % — это смешно, отлично: назовите реальную цифру. Смысл в том, чтобы сделать рост частью обсуждения архитектуры.

Я называю это «числом нулей» Steve (Steve’s Number of Zeros). Один лишний ноль может полностью изменить вашу архитектуру. Десять тысяч, сто тысяч, миллион, десять миллионов, сто миллионов: функция не изменилась, и требование, может быть, тоже, а архитектура — может.

Помните записи на прием из модуля 1? Давайте подставим реальные цифры. Более 1 200 точек, 100 записей на точку в день, шесть дней в неделю, около 305 дней в году. Это более 36 млн записей на прием за первый год. Каждый визит создает две записи, значит, более 73 млн записей. Теперь храните историю за пять лет при росте 30 % в год — и получится более 650 млн записей. Та же функция, то же требование. Пара лишних нулей — и совсем другая архитектура.

Планируйте на завтра

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

Вот почему мне так важно, может ли архитектура расти за счет добавления, а не постоянных изменений. Если бизнес добавит продукт, вместит ли его модель? Если данные понадобятся другой системе, сможем ли мы аккуратно их предоставить? Если объем резко вырастет, есть ли нам куда двигаться? Если изменится структура бизнеса, придется ли нам разносить модель данных на части? Мы не пытаемся идеально предсказать будущее. Мы пытаемся не загнать себя в угол.

Не стройте завтрашний день сегодня

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

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

Планируйте на случай сбоя

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

Спросите, что может сломаться, а затем — что будет, когда это случится. Интеграция падает по тайм-ауту. API отклоняет запрос. Ночная загрузка обрабатывает 800 000 записей и падает на 200 000. Система-источник отключается. Пользователь вводит недопустимые данные. Внешний идентификатор встречается дважды. Вышестоящая система меняет формат значения, не меняя имя поля. Процесс успешно проходит в одной системе и падает в другой. Это не редкие пограничные случаи. Так выглядит продакшн.

Частичный успех — это все равно сбой, который нужно понять

Частичные сбои особенно опасны в архитектуре данных. Представьте, что вы перемещаете миллион записей, и процесс сообщает, что завершился. Отлично. Но пришел ли миллион или 999 997, и каких трех не хватает? Может быть, 200 000 не прошли, какие-то были созданы дважды, или все пришло, но часть полей не прошла преобразование.

«Задание завершено» — не то же самое, что данные верны. Архитектор данных думает о сверке: как узнать, что должно было произойти, что произошло на самом деле, и в чем разница? И что мы с этим делаем?

Вот что я делаю, когда системы становятся сложными. Записи идут из A в B, слева направо. Затем B отправляет кое-что обратно: подтверждение для каждой записи, которую она получила и сохранила. Теперь A может сравнить то, что отправила, с тем, что подтверждено. Если у каждой записи есть подтверждение, прогон прошел успешно. Если каких-то подтверждений нет, значит, не прошел, что бы ни говорил статус задания, и мы точно знаем, за какими записями идти: повторить их, передать человеку или поднять тревогу.

Click to enlarge

Ломайтесь аккуратно

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

И самое главное: можем ли мы восстановиться, не сделав проблему хуже? Стратегия повторов, которая создает дубликаты данных, — так себе стратегия восстановления. Хорошая архитектура предполагает сбои и дает нам путь назад.

Отслеживайте то, что важно

Планировать на случай сбоя без мониторинга — это не совсем планирование. Если интеграция падает в 02:00 и никто не замечает этого, пока через три дня не позвонит клиент, у нас не было эксплуатационной архитектуры. У нас была надежда.

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

Думайте во всех трех направлениях

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

Технологии меняются от главы к главе. Вопросы — нет.

Архитектура живет во времени

Разработчик иногда может посмотреть на требование и спросить: «Это работает?» Архитектор должен спросить больше: работает ли это сегодня, будет ли работать завтра и что будет, когда это вообще не работает? Эти три вопроса выводят нас за пределы реализации, в жизнь системы.

Вы не предскажете каждое будущее требование и не предотвратите каждый сбой. Цель не в этом. Цель — построить то, что уместно для того, что мы знаем сегодня, оставить себе куда двигаться завтра и иметь план на случай, когда реальность не хочет сотрудничать.

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

Что здесь решает архитектор

• Каковы реальные объемы и рост и какие цифры изменили бы проект.
• Какие подразумеваемые требования бизнес еще не высказал.
• Как сегодняшний проект может развиться в завтрашний, не строя завтрашнюю систему сегодня.
• Что будет, когда что-то сломается: восстановление, сверка и мониторинг.