Constraints та assumptions

Обмеження задають межі, у яких потрібно знайти рішення. Вони можуть походити з різних джерел.

Бізнесові обмеження

Визначаються продуктом, бюджетом або правилами компанії:

• максимальна вартість інфраструктури;

• дата запуску;

• підтримка лише певних країн;

• вимога використовувати вже наявну систему авторизації;

• заборона залежати від конкретного постачальника.

Технічні обмеження

Пов’язані з наявною інфраструктурою або технологіями:

• використання конкретної бази даних;

• обмежений обсяг пам’яті;

• підтримка лише певної версії середовища;

• максимальна пропускна здатність мережі;

• робота в одному регіоні або дата-центрі.

Операційні обмеження

Стосуються експлуатації системи:

• допустимий час простою;

• час відновлення після збою;

• необхідність резервного копіювання;

• доступність команди підтримки;

• вимоги до моніторингу та журналювання.

Обмеження вимог

Це межі самої поведінки системи:

• максимальний розмір файлу;

• максимальна кількість елементів у запиті;

• обмеження частоти запитів;

• час відповіді;

• обсяг даних, який потрібно зберігати.

Обмеження не завжди є негативними. Вони зменшують кількість можливих рішень і допомагають ухвалювати конкретні архітектурні рішення.

Припущення

Припущення виникають там, де інформації ще недостатньо. Наприклад:

• «Користувачі зазвичай виконуватимуть не більше 10 запитів на хвилину».

• «Розмір одного документа не перевищуватиме 5 МБ».

• «Для читання даних потрібна нижча затримка, ніж для запису».

• «Дані можна видаляти через 30 днів».

• «Зовнішній сервіс буде доступний більшу частину часу».

Припущення допомагають рухатися вперед, але вони створюють ризик. Якщо припущення помилкове, архітектура може перестати відповідати вимогам.

Властивості хорошого припущення

Хороше припущення:

• сформульоване конкретно;

• має числове значення або чітку межу;

• має джерело або пояснення;

• може бути перевірене;

• має вказаний рівень упевненості.

Погано:

Система матиме багато користувачів.

Краще:

У перші шість місяців очікується до 100 000 активних користувачів на місяць, із рівнем упевненості 60%.

Ще краще — додати спосіб перевірки:

Значення перевіримо за статистикою поточного продукту або результатами навантажувального тестування.

Як відрізнити обмеження від припущення

Поставте запитання: це вже відоме правило чи наша оцінка невідомого?

Якщо відповідь підтверджена договором, вимогою або технічною можливістю, це, ймовірно, обмеження.

Якщо відповідь ґрунтується на прогнозі, досвіді або неповній інформації, це припущення.

Приклад класифікації

• «API має підтримувати HTTPS» — обмеження.

• «Усі клієнти підтримують HTTPS» — припущення, якщо це ще не перевірено.

• «База даних має залишатися PostgreSQL» — обмеження.

• «PostgreSQL витримає 10 000 записів за секунду» — припущення до проведення тестів.

• «Відновлення після аварії має тривати не більше години» — обмеження.

• «Резервна копія відновиться за 20 хвилин» — припущення до перевірки.

Одне й те саме твердження може змінити категорію. Наприклад, очікуване навантаження спочатку є припущенням. Після затвердження продуктом воно може стати офіційною вимогою або обмеженням для проєктування.

Як фіксувати обмеження та припущення

Не покладайтеся на пам’ять або лише на усні обговорення. Для кожного пункту корисно записати:

• формулювання;

• тип: обмеження або припущення;

• джерело;

• значення або межу;

• рівень упевненості;

• спосіб перевірки;

• вплив на архітектуру;

• відповідального;

• дату повторного перегляду.

Наприклад:

Тип: припущення
Формулювання: до 1 мільйона нових посилань на день
Упевненість: середня
Перевірка: аналіз статистики аналогічного сервісу
Вплив: потрібен запас для запису та генерації унікальних ідентифікаторів
Відповідальний: продуктова команда
Перегляд: після першого місяця роботи

Для невеликого проєкту достатньо звичайного документа або розділу в технічному описі. Головне — щоб записи були доступними всім учасникам.

Перевірка припущень

Не всі припущення потрібно перевіряти однаково. Спочатку перевіряють ті, які:

• мають високий вплив на архітектуру;

• мають низький рівень упевненості;

• можуть призвести до значних витрат;

• складно змінити після запуску;

• стосуються безпеки, надійності або втрати даних.

Способи перевірки

Залежно від припущення можна використати:

• аналіз існуючої статистики;

• уточнення вимог у зацікавлених сторін;

• прототип;

• навантажувальний тест;

• тест із реальною базою даних;

• вимірювання затримки;

• перевірку документації постачальника;

• пілотний запуск для обмеженої кількості користувачів.

Приклад

Припущення:

Система зможе обробляти 500 запитів на секунду на одному сервері.

Можливий план перевірки:

1. Визначити типовий запит.

2. Підготувати тестові дані.

3. Запустити навантаження в 500 запитів на секунду.

4. Виміряти затримку, використання CPU, пам’яті та бази даних.

5. Повторити тест із запасом, наприклад на 750 запитів на секунду.

6. Зафіксувати результати та оновити архітектурне рішення.

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

Вплив на архітектурні рішення

Обмеження та припущення не повинні залишатися окремим списком. Їх потрібно пов’язувати з рішеннями.

Приклад зв’язку

Припущення:

Запити на читання траплятимуться у 20 разів частіше, ніж запити на запис.

Можливі наслідки:

• оптимізація індексів для читання;

• кешування часто запитуваних даних;

• окремий аналіз навантаження на читання та запис;

• готовність до масштабування компонентів, які обслуговують читання.

Якщо припущення зміниться, наприклад співвідношення стане 1:1, ці рішення потрібно переглянути.

Оцінка запасу

Не варто проєктувати систему рівно під очікуване значення. Потрібно враховувати запас.

Якщо очікується 1 мільйон запитів на день, корисно оцінити:

• середню кількість запитів за секунду;

• пікове навантаження;

• необхідний запас;

• поведінку системи при перевищенні межі.

Орієнтовну середню кількість запитів можна обчислити так:

Але середнє значення не описує піки. Навантаження може бути набагато вищим у робочі години або під час рекламної кампанії.

Невеликий розрахунок на JavaScript

Цей приклад оцінює середнє навантаження, обсяг нових даних і рекомендований запас.

У цьому прикладі всі числа є припущеннями. Якщо змінити newLinksPerDay або peakMultiplier, зміняться й оцінки. Це показує, чому важливо зберігати не лише рішення, а й значення, на яких воно ґрунтується.

Робота з невизначеністю

Не всі припущення можна перевірити одразу. У такому разі потрібно зменшити ризик.

Варіанти роботи з неперевіреним припущенням

• додати запас продуктивності;

• обмежити обсяг першого запуску;

• використати конфігурацію, яку легко змінити;

• додати моніторинг потрібного показника;

• підготувати альтернативний план;

• зробити припущення явною частиною ризиків.

Наприклад, якщо невідомо, чи буде пікове навантаження в 5 чи 20 разів більшим за середнє, можна:

1. запустити систему з обмеженням частоти запитів;

2. додати метрики пікового навантаження;

3. зробити масштабування конфігурованим;

4. переглянути оцінку після появи реальної статистики.

Це краще, ніж одразу створювати складну архітектуру для найгіршого сценарію без доказів, що він настане.

Практичний алгоритм

Під час підготовки архітектури використовуйте такий порядок:

1. Зберіть факти.
   Запишіть вимоги, доступні ресурси, правила, дедлайни та відомі обмеження.

2. Відокремте припущення.
   Позначте твердження, які ще не підтверджені.

3. Додайте числа.
   Замість «велике навантаження» запишіть кількість користувачів, запитів або даних.

4. Оцініть вплив.
   Визначте, які рішення залежать від кожного припущення.

5. Перевірте найризикованіші пункти.
   Використайте статистику, прототип або тест.

6. Зафіксуйте рішення.
   Запишіть, чому обрано конкретний компонент або підхід.

7. Визначте умови перегляду.
   Наприклад: «переглянути після досягнення 10 000 активних користувачів».

8. Оновлюйте записи.
   Після появи нових даних припущення може стати підтвердженим фактом або виявитися неправильним.

Типові помилки

Припущення видають за факти

Фраза «система витримає навантаження» не є доказом. Потрібно вказати конкретне навантаження та спосіб перевірки.

Використовують нечіткі слова

Слова «швидко», «багато», «рідко» та «великий» не дають змоги ухвалити технічне рішення. Замініть їх вимірюваними значеннями.

Не враховують пікове навантаження

Середнє значення може приховувати короткочасні піки. Завжди уточнюйте, коли саме виникає навантаження і наскільки воно може зрости.

Не вказують вплив

Список припущень без зв’язку з архітектурою швидко застаріває. Для кожного важливого пункту пояснюйте, яке рішення від нього залежить.

Не переглядають старі припущення

Після запуску з’являються реальні дані. Якщо не оновлювати припущення, система продовжить розвиватися на основі неточної інформації.

Створюють надто складну систему «про всяк випадок»

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

Summary

• Обмеження — це відомі правила та межі, яких система має дотримуватися.

• Припущення — це непідтверджені твердження, необхідні для руху вперед.

• Припущення потрібно формулювати конкретно, бажано з числами.

• Найважливіші припущення слід перевіряти за допомогою статистики, прототипів або тестів.

• Архітектурні рішення мають бути пов’язані з обмеженнями та припущеннями, на яких вони ґрунтуються.

• Непідтверджені припущення потрібно супроводжувати запасом, моніторингом і умовами перегляду.

• Документування цих пунктів допомагає команді бачити ризики та своєчасно змінювати архітектуру.