Будуйте для сьогодні. Плануйте на завтра. Плануйте на випадок збою.

🌐 Також доступно 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 розділу Мислити як архітектор даних, першого розділу курсу Data Architect. Кожен модуль самостійний. Попередній: Архітектура — це мистецтво компромісів · Наступний: Знайте свої інструменти: дев’ять запитань

Питання, на яке відповідає цей модуль: Як проєктувати під сьогоднішні вимоги, плануючи водночас на зростання і на збої?

Одна з найлегших помилок в архітектурі — проєктувати лише під ті вимоги, що лежать перед вами. У нас є проєкт, беклог і вимоги. Ми будуємо щось, що їм відповідає. Воно працює, і ми оголошуємо перемогу. Через пів року бізнес змінюється, або дані зростають, або інший підрозділ хоче цим користуватися, або ми купуємо компанію, або нову систему треба інтегрувати, або ламається щось, на що ніхто не розраховував.

Ніщо з цього не має дивувати архітектора. Ми не можемо передбачити все, що станеться, але можемо проєктувати, знаючи, що щось станеться. Тому я дивлюся на архітектуру крізь три лінзи:

Будуйте для сьогодні. Плануйте на завтра. Плануйте на випадок збою.

Потрібні всі три.

Click to enlarge

Будуйте для сьогодні

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

Тож почніть із сьогодні: що потрібно бізнесу, реальні обсяги, користувачі й транзакції, як часто змінюються дані і як швидко вони мають рухатися, кому потрібен доступ, звідки дані приходять і куди йдуть. І найважливіше: чому? Ці відповіді дають нам щось конкретне для проєктування.

Шукайте неявні вимоги

Вимоги, які вам дали, — не обов’язково всі вимоги, які у вас є. Майже завжди є неявні вимоги.

Бізнес каже: «Нам потрібні дані клієнтів у Salesforce». Добре. Тоді хтось має цими даними володіти і вирішити, наскільки свіжими вони мають бути. Нам треба знати, що станеться, коли система-джерело недоступна, як ми помітимо збій синхронізації і яка сторона виграє, коли Salesforce і джерело не збігаються. Нам потрібні строк зберігання, модель доступу, рішення щодо чутливих полів і спосіб виправляти погані дані.

Нічого з цього не було в user story. І все це — архітектура. Значна частина того, щоб стати архітектором, — навчитися розпізнавати запитання, які ще не поставили.

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

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

Коли кращого числа немає, моя базова величина — 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

Падайте коректно

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

І найважливіше: чи можемо ми відновитися, не погіршивши проблему? Стратегія повторних спроб, що створює дублікати даних, — не надто вдала стратегія відновлення. Добра архітектура припускає збої і дає нам шлях назад.

Моніторте те, що важливо

Планування на випадок збою без моніторингу — не зовсім планування. Якщо інтеграція падає о 2:00 ночі, і ніхто не помічає, доки через три дні не зателефонує клієнт, у нас не було операційної архітектури. У нас була надія.

Вирішіть, що має бути спостережуваним: чи запустився процес, скільки він тривав, скільки записів оброблено, скільки вдалося і скільки ні? Чи раптом обсяги відрізняються від звичних? Чи росте черга, чи збільшуються помилки? Архітектура не закінчується, коли розгортання вдалося. Хтось має експлуатувати цю систему завтра, і це частина дизайну.

Думайте в усіх трьох напрямках

Застосовуйте три лінзи й далі протягом курсу. Коли проєктуємо модель даних: чи працює вона сьогодні, чи зможе зростати завтра і що станеться, коли дані хибні чи неповні? Інтеграцію: чи переносить вона сьогоднішні дані, чи впорається із завтрашнім обсягом і системами і що станеться, коли одна сторона недоступна? Великі обсяги даних: що в нас сьогодні, куди рухаються цифри і як ми відновимося, коли велика операція вдасться лише частково?

Технології змінюються від розділу до розділу. Запитання — ні.

Архітектура існує в часі

Розробник іноді може подивитися на вимогу й запитати: «Це працює?» Архітектор мусить запитати більше: чи працює це сьогодні, чи працюватиме завтра і що станеться, коли воно взагалі не працюватиме? Ці три запитання виводять нас за межі реалізації — у життя системи.

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

Будуйте для сьогодні. Плануйте на завтра. Плануйте на випадок збою. Ми знову і знову користуватимемося цими трьома лінзами.

Що тут вирішує архітектор

• Які реальні обсяги й зростання і які цифри змінили б дизайн.
• Які неявні вимоги бізнес ще не сформулював.
• Як сьогоднішній дизайн може еволюціонувати в завтрашній, не будуючи завтрашню систему сьогодні.
• Що станеться, коли щось зламається: відновлення, звірка і моніторинг.