Продукт і вимоги

Нефункціональні вимоги: якої якості потребує система

Правильна відповідь ще не означає, що продуктом можна скористатися. Сторінка може повільно відкриватися, форма — бути недоступною з клавіатури, а…

Глава 11Заморожене українське видання

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

У цій главі розглянемо швидкодію, надійність і доступність сервісу, масштабування, безпеку, приватність, доступність інтерфейсу, сумісність і супровідність. Не кожному продукту потрібна однакова планка. Вимога має походити з реального сценарію, ризику або зобов’язання, а не зі слова «швидкий» чи «надійний».

Назва «нефункціональна» не означає «другорядна» або «поза функціональністю». Функціональна вимога описує, що продукт робить; вимога до якості — за яких умов, для кого й з яким рівнем він має це робити. Обидві потрібні: продукт може дати правильну відповідь, але надто повільно або не тим користувачам.

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

Після глави читач уміє:

  • пов’язати якість із конкретною потребою або ризиком;
  • відрізнити затримку, пропускну здатність, доступність і довговічність даних;
  • назвати умову, реакцію, межу вимірювання й метод перевірки;
  • позначити припущення та компроміси, не подаючи їх як виміряні факти;
  • вимагати доказу, не дозволяючи непомітно послабити критерій заради зеленого статусу.

Якість відповідає на питання «для кого, у яких умовах і з яким наслідком?»

«Швидкий», «надійний», «захищений» і «зручний» не мають самодостатнього числового значення. Скільки запитів надходить одночасно? Хто має право бачити дані? Чи можна виконати основну дію без миші? Що означає успіх, коли стороння служба недоступна? Відповіді змінюють рішення, тому їх не слід ховати за прикметником.

Практична форма якісної вимоги:

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

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

Не визначайте потребу технічним рішенням. «Поставити Redis» не пояснює, навіщо потрібен кеш; «додати ще три сервери» не задає навантаження; «підтримати всі браузери» не визначає «всі». Почніть зі сценарію, обмеження чи ризику, а тоді оберіть спосіб реалізації.

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

Швидкість: вимірюйте те, що відчуває користувач

Затримка, пропускна здатність і навантаження

Затримка відповіді (latency) — час від зафіксованої початкової події до визначеного завершення. Далі час подаю в мілісекундах (мс); 1000 мс становлять одну секунду. Для користувача це може бути час від натискання «Пошук» до появи корисного результату; для сервера — від отримання запиту до надсилання відповіді. Це різні межі: між ними є браузер, мережа, черга, шлюз, база даних або стороння служба. Google SRE радить обирати показник з огляду на досвід користувача й називати серверний час наближенням, якщо він не вимірює цей досвід безпосередньо (Service Level Objectives).

Пропускна здатність (throughput) — кількість роботи, яку система завершує за одиницю часу, наприклад запитів за секунду або записів за хвилину. Це не те саме, що затримка: система може завершувати багато незалежних запитів паралельно, але повільно відповідати на кожен із них; або швидко відповісти на один запит, але не впоратися з потоком. Навантаження — конкретна робота, що надходить до системи. Зростання одночасних запитів часто збільшує затримку, а після певної межі вона може різко погіршитися; тому затримку слід вимірювати разом з описом профілю роботи, а окреме швидке запитання не доводить, що сервіс витримає потік.

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

Спершу визначте межу вимірювання. Людина може чекати від натискання кнопки до появи готового результату, тоді як сервер вимірює лише час обробки запиту. Завантаження сторінки, запит до бази й відповідь зовнішнього сервісу — різні відрізки. Назвіть, де починається та закінчується таймер, і для якого сценарію це має значення.

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

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

Середнє приховує повільний хвіст

Уявімо 1000 умовних запитів на перевірку вільного часу для бронювання — це арифметичний приклад, а не вимірювання реального продукту: 940 тривали по 100 мс, 50 — по 250 мс і 10 — по 2000 мс. Середнє дорівнює 126,5 мс, а медіана — 100 мс. Обидва числа виглядають прийнятними, хоча десять людей чекали дві секунди. За методом найближчого рангу медіана відповідає 500-му спостереженню, а p95 — 950-му: 940-й запит тривав 100 мс, а наступні десять уже по 250 мс. Отже, p95 становить 250 мс, але один відсоток людей чекав дві секунди. Є кілька способів обчислювати перцентилі, і для малих вибірок вони можуть дати різні результати (NIST: Percentiles).

Кількість запитів Час одного запиту Сумарний час
940 100 мс 94 000 мс
50 250 мс 12 500 мс
10 2000 мс 20 000 мс
Разом 1000 спостережень 126 500 мс

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

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

Окремо визначте затримку успішних відповідей і частку успішних спроб. Якщо p95 рахується лише серед коректних відповідей, помилки й тайм-аути не потраплять до його вибірки, а повільні тайм-аути можуть сховатися за хорошим p95. Поряд із затримкою запишіть частку всіх допустимих запитів, що завершилася правильно до дедлайну: помилки й тайм-аути рахуються як невдалі спроби, їх не вилучають і не рахують як нуль, а час до дедлайну фіксують у звіті про помилки. Два показники відповідають на різні запитання — як швидко відповідає успішний запит і як часто людина отримує правильний результат. Якщо метрика затримки включає невдалі спроби, наперед визначте, який час їм призначається. Двадцять запитів мало говорять про хвіст; водночас велика вибірка, зібрана не в той час або не тим шляхом, може відповідати не на те питання.

У браузері Navigation Timing і Resource Timing допомагають вимірювати окремі частини завантаження сторінки й ресурсів (MDN: Navigation Timing, Resource Timing). Ці часові мітки допомагають знайти повільний відрізок, але не показують самі по собі, коли результат став корисним для людини.

Для генеративної системи час до першого видимого фрагмента відповіді відрізняється від часу до повного завершення. Потокова передача може раніше показати початок, але не обов’язково скорочує повне очікування або підвищує правильність. Час також залежить від довжини входу й відповіді, вибраної моделі, потокового режиму та інших частин запиту; OpenAI й Anthropic радять вимірювати потрібний аспект, а не припускати універсальний поріг (OpenAI, Anthropic). Скорочення згенерованого тексту може зменшити очікування, але обрізана відповідь не є успіхом, якщо людині потрібно повне пояснення. Перш ніж погоджувати поріг, визначте, що саме вважається завершенням: список може бути придатним до роботи до завантаження декоративного зображення, тоді як анімація швидкого підтвердження платежу не є завершенням, якщо результат операції ще невідомий. Поріг має походити з потреби, договору або рішення власника, а не з числа, яке зручно виміряти.

Надійність: що система робить під час відмови

Доступність, надійність і довговічність даних

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

Художня ілюстрація відмови обладнання та стійкості системи

Доступність сервісу — частка визначеного часу або запитів, коли ключову дію можна виконати успішно. Умова має сказати, чи вважається помилкою відповідь із хибними даними, неприйнятною затримкою або відмовою лише частини функцій. Довговічність — імовірність того, що підтверджені дані збережуться за визначений період. Сховище може тимчасово не відповідати, але не втратити запис; або відповідати зараз і втратити підтверджені зміни після відмови. Google SRE розглядає доступність і довговічність як окремі показники для сховищ (Service Level Objectives).

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

Збої бувають частковими: база може працювати, а служба повідомлень — ні; один платіжний провайдер може відмовити, поки решта продукту доступна. Для читання іноді безпечніше показати останні підтверджені дані й позначити, що вони можуть бути застарілими. Наприклад, кешована ціна прискорює каталог і зменшує кількість звернень до постачальника, але може вже не відповідати актуальній. Перед оплатою треба звірити ціну й наявність із джерелом; якщо перевірка недоступна або значення змінилося, не підтверджуйте стару суму (IETF RFC 9111, §4.2). Для запису може знадобитися відмовити, щоб не підтвердити операцію двічі. Автоматичний повтор іноді допомагає після тимчасової помилки, але може збільшити навантаження або знову виконати незворотну дію. Визначте, які операції безпечні для повтору і як виявити, що вони вже відбулися.

Під час мережевого розділення система може не мати змоги одночасно забезпечити доступність кожного вузла й однаковий актуальний стан даних. Якщо два вузли бачать один останній вільний слот, незалежне підтвердження може створити подвійне бронювання. Для цього запису система може тимчасово відмовити в підтвердженні, доки не зв’яжеться з джерелом істини; для каталожного перегляду вона може дозволити читання позначеної застарілої копії, бо наслідок інший. Це рішення залежить від операції, а не є правилом «узгодженість завжди важливіша» (Google SRE: Managing Critical State).

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

У практиці Google SRE розрізняють три поняття (Service Level Objectives):

  • SLI (service level indicator) — вимірюваний показник, наприклад частка успішних запитів;
  • SLO (service level objective) — ціль для цього показника за визначений період;
  • SLA (service level agreement) — договірне зобов’язання, яке може встановлювати наслідки невиконання.

Число «99,9%» саме по собі не є обіцянкою: потрібні період, визначення успіху, джерело вимірювання та правила для помилок. SLO допомагає команді обирати між роботою над новими функціями й надійністю; SLA потребує погодження сторін і може мати фінансові наслідки.

Масштабування: визначте, що саме зростає

Масштабованість — здатність обслуговувати зростання роботи за прийнятних витрат і складності. Можуть збільшитися кількість запитів, користувачів, обсяг даних, частота імпорту чи розмір команди. За вертикального масштабування додають ресурси одній машині; за горизонтального — більше машин або робочих вузлів. Другий варіант ставить додаткові питання про спільний стан, розподіл запитів, повтори, узгодженість і діагностику.

Перш ніж додавати вузли, виміряйте профіль навантаження й знайдіть вузьке місце. Розділіть читання і запис: каталог може мати багато переглядів і мало змін, а платежі — небагато операцій із високою ціною помилки. Середнє за добу приховає короткий пік. Ще один сервер не прискорить повільний запит до бази чи зовнішнього провайдера. Перевіряйте гіпотезу на відтворюваному сценарії: змініть один розмір набору або кількість паралельних читань і порівняйте p95, помилки, час запиту до сховища та вартість. Записуйте точну конфігурацію кожного прогону, інакше порівнюватимете різні умови.

Не проєктуйте на мільйони одночасних користувачів без підтвердженої потреби. Вертикальне масштабування може бути простим першим кроком, але його обмежують фізична місткість однієї машини та ціна ресурсів. Для внутрішнього кабінету з кількома десятками бронювань на день одна база може бути простішою й дешевшою; відмова цієї машини, однак, може зупинити роботу до відновлення з копії. Окремий вузол у незалежній зоні може скоротити перерву після певних типів відмов, але додає витрати, реплікацію й перемикання, яке треба перевіряти. Резервування не захищає автоматично від помилкового видалення чи невдалої міграції, тому копії та відновлення потребують окремої вимоги. Власник зіставляє ціну доступності з наслідками простою й погоджує допустимий час відновлення та обсяг можливої втрати даних; див. також розділ про надійність і AWS Well-Architected: Availability. Книжки про системи з великим обсягом даних і архітектурні компроміси корисні як мапа питань про навантаження, затримку, відмови й складність, а не як рецепт обов’язкової бази чи кількості сервісів (Kleppmann і Riccomini, Designing Data-Intensive Applications, 2nd ed., Ford та ін., Software Architecture: The Hard Parts).

Кількість сервісів сама по собі нічого не говорить про масштабованість. Окремі компоненти можуть допомогти, коли їх треба незалежно випускати чи навантажувати, але мережа додає затримки й часткові відмови. Детальний розбір меж і такої ціни — у главі 12.

Безпека й приватність: визначте, що захищати

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

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

Щоб зробити вимогу повною, перевірте:

  1. які дані й дії мають бути захищені;
  2. які ролі можуть виконувати які операції;
  3. де перевіряється доступ і що має бути безпечним при відмові;
  4. які журнали потрібні для діагностики й аудиту;
  5. що не можна записувати в журнали чи повідомлення про помилки;
  6. який строк зберігання й процес видалення застосовуються;
  7. де й за яким правилом видаються та зберігаються секрети;
  8. як команда доводить, що контроль діє.

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

Для інтеграції із зовнішньою системою діагностичний запис може містити ідентифікатор операції, час і код відповіді, але не заголовок авторизації, тіло з токеном чи фрагмент помилки із секретом. Перевірте, що токен відсутній у коді й артефактах збірки, а процес має лише потрібні права. Якщо середовище ще не має затвердженого сховища, зафіксуйте це як безпековий блокер і погодьте тимчасовий процес; не маскуйте секрет у коді чи нотатках. Для локального прототипу без справжніх облікових даних можна використовувати тестове значення, але не переносити виробничий токен у приклад. OWASP радить обмежувати доступ і контролювати життєвий цикл секретів (Secrets Management Cheat Sheet); реалізація залежить від платформи й моделі загроз.

Наприклад, служба передає підтверджені записи зовнішній системі за допомогою токена. Токен має бути доступний лише процесу інтеграції, але не потрапляти в запит до агента, журнал чи текст помилки. Для діагностики достатньо записати ідентифікатор операції, час, тип результату й код відповіді; тіло запиту та заголовок авторизації журналювати не потрібно. Під час витоку команда має знати, хто відкликає токен і як створити новий без втрати вже підтверджених записів.

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

OWASP Application Security Verification Standard (ASVS) пропонує каталог вимог і способів перевірки технічних контролів, а не автоматичний доказ безпеки чи юридичної відповідності (ASVS 5.0.0). Команда обирає вимоги відповідно до даних, загроз і продуктового контексту.

Доступність інтерфейсу — частина якості

Доступність інтерфейсу під час роботи з клавіатури

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

Наприклад, у формі бронювання є поля «Ім’я», «Електронна адреса» і кнопка «Підтвердити». Мишею можна активувати кожен елемент, але Tab пропускає кнопку, а після помилки адреси з’являється лише червона рамка без пояснення. Людина з клавіатурою не може завершити дію, а людина, яка не розрізняє кольори, не знає, що виправити. WCAG (Web Content Accessibility Guidelines — настанови з доступності вебвмісту) 2.2, які підтримує W3C (World Wide Web Consortium) і його ініціатива WAI (Web Accessibility Initiative), задає перевірювані критерії: клавіатурне керування (2.1.1), видимий фокус (2.4.7) та текстове визначення помилки (3.3.1) (WCAG 2.2, Keyboard, Focus Visible, Error Identification). Перевірте проходження всієї форми клавішею Tab, семантику інтерактивних елементів, видимість фокусу, текст помилки, масштаб і потрібні допоміжні технології. Автоматичний скан знаходить лише частину дефектів, тож він не доводить, що людина може завершити повний сценарій.

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

Ситуація Очікувана поведінка Перевірка
Людина проходить форму без миші Tab веде логічно через поля, посилання й кнопки; клавіша активації виконує дію сфокусованого елемента Пройти весь сценарій і записати порядок та доступність контролів
Фокус на елементі Поточне поле чи кнопка має виразну видиму межу фокусу Перевірити переміщення клавіатурою у підтримуваних темах і масштабах
Адреса має неправильний формат Текст повідомляє поле й причину; помилку можна знайти без вгадування за кольором Надіслати неправильну адресу, перевірити повідомлення, фокус і оголошення допоміжною технологією

Критерії залежать від сценарію та цільового рівня відповідності. Не обіцяйте «повну доступність» без визначеної межі й доказу. Технічна метрика також не підтверджує цінність чи зрозумілість: перевірте, чи людина знайшла підтверджений запис і змогла його перенести. Це застосування продуктової рамки Cagan і підходу Krug до спостереження за навігацією, а не правило про певний p95 (Cagan, Krug).

Сумісність: назвіть підтримуване середовище

Художня ілюстрація використання продукту в реальних умовах

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

Час і формати даних часто приховують проблеми сумісності. «До кінця дня» потребує часового поясу; дата 04/05 може означати 4 травня або 5 квітня. Для CSV (comma-separated values — текстового табличного формату з роздільниками) узгодьте кодування UTF-8, роздільник, лапки й формат дат, а також приклад коректного та некоректного вводу. Перевіряйте кирилицю й кому всередині лапок, а не лише простий файл (Unicode: UTF-8 FAQ).

Приклад: звіт росте разом із каталогом

Уявімо внутрішній каталог бронювань, який зростає з 500 до 50 000 записів. Це навчальний приклад. Працівники фільтрують каталог, а не вивантажують усю таблицю; час показується для часової зони офісу, дані можна експортувати у CSV.

Властивість Уточнений критерій Доказ і сигнал для супроводу
Зростання На наборі 50 000 записів, 20 одночасних читаннях і визначеній частці фільтрів p95 лишається в погодженій межі; запит завантажує лише потрібну сторінку Повторити однаковий сценарій на малому й великому наборі; зафіксувати затримку, помилки й час запиту до сховища
Сумісність CSV у UTF-8, із зафіксованими роздільником і заголовками; дати однозначні, для показу перетворені в часову зону офісу Імпортувати кирилицю, кому в лапках і дату біля півночі; перевірити підтримувані браузери
Спостережуваність Для кожного експорту є ідентифікатор, число рядків, тривалість і підсумок; персональні поля не журналюються Перевірити логи успіху й помилки, знайти операцію та підтвердити відсутність чутливих даних
Супровідність Команда відтворює помилку імпорту на синтетичному файлі й може повернути попереднє правило розбору Зберегти файл-приклад, кроки відтворення, власника правила й шлях відкату

У навчальному прогоні p95 може, наприклад, зрости зі 180 до 920 мс разом із часом запиту до сховища. Це гіпотеза для діагностики, а не доказ причини: окремо перевіряють план запиту, індекс і профіль навантаження. Якщо біля півночі браузер показує іншу дату, це дефект часового правила, а не затримки. Числа тут не є виміряними властивостями реального продукту.

Супровідність і спостережуваність

Виміри якості цифрового продукту

Супровідність описує, чи може команда зрозуміти систему, безпечно її змінити, виявити проблему й відновити роботу без непропорційних витрат. Перевіряйте це конкретними запитаннями: чи можна відтворити збій за описаними кроками? Чи зрозуміло, хто відповідає за компонент? Чи можна безпечно розгорнути зміну й повернути попередній стан?

Спостережуваність дає змогу робити висновки про внутрішній стан системи за її сигналами. Логи описують події, метрики показують числові зміни в часі, а траси пов’язують кроки одного запиту між компонентами. OpenTelemetry визначає їх як окремі сигнали телеметрії (Signals). Більше даних не завжди краще: журнали коштують грошей і можуть розкрити персональні дані чи секрети. Збирайте достатньо, щоб знайти збій, але не журналюйте все підряд.

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

Повний приклад: каталог оновлює ціну раз на годину

Магазин отримує ціни й наявність від постачальника раз на годину. Кеш — тимчасова копія даних, яку повторно використовують замість звернення до джерела під час кожного перегляду. Кеш може прискорити сторінку й зменшити навантаження на постачальника, але збільшує час, протягом якого покупець бачить застаріле значення. Це компроміс між швидкістю, свіжістю та доступністю залежності. У HTTP директива max-age задає, як довго відповідь вважається свіжою; далі може знадобитися повторна перевірка (MDN: HTTP caching).

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

Питання Початкове припущення Що треба підтвердити
Коли постачальник змінює ціну? Не більш ніж раз на годину Чи надсилає він подію про дострокову зміну, чи лише плановий файл?
Яка застарілість прийнятна для каталогу? До 60 хвилин Чи підходить межа для розпродажу й товару з малою кількістю?
Що є джерелом істини під час покупки? Ціну повторно перевіряють перед підтвердженням Що робити, якщо перевірка недоступна або сума змінилася?
Як показати застарілий стан? Показати час останнього успішного оновлення після межі Чи можна купити товар і хто вирішує, коли дані надто старі?
Яку затримку обіцяти для перегляду? p95 каталогу ≤ 700 мс за визначеного навантаження Чи важливо це користувачам і за який період вимірювати?

З цих відповідей випливають різні критерії:

  1. Свіжість: зберігати час останнього підтвердженого значення; після погодженої межі не називати ціну актуальною без застереження.
  2. Читання каталогу: вимірювати p95 коректних відповідей від запиту браузера до появи ціни на узгодженому наборі, навантаженні та середовищі; окремо рахувати частку всіх допустимих запитів, що завершилися правильно до дедлайну. Помилки й тайм-аути — невдалі спроби.
  3. Підтвердження замовлення: повторно перевіряти ціну й наявність; якщо сума змінилася, показати її та попросити покупця підтвердити, а не мовчки списувати іншу суму.
  4. Відмова постачальника: зберігати останнє підтверджене значення, показувати його вік відповідальній ролі й виконувати повтори з обмеженим інтервалом, визначеним операційною політикою; не позначати стару копію як свіжу.

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

Перевірка й доказ. На незмінному тестовому наборі зафіксуйте базову ціну, час її отримання й час наступного оновлення. Перевірте звичайний перегляд до та після погодженої межі свіжості, дострокову зміну ціни постачальником, невдале годинне оновлення, відсутній запас і повторний запит після тайм-ауту. Під час оформлення замовлення окремо змініть ціну між переглядом і підтвердженням: покупець має побачити нову суму й підтвердити її, а система не повинна мовчки списати іншу. Збережіть часи джерела й кешу, відповідь постачальника, журнал повторів, показаний покупцю стан і результат повторної перевірки. Якщо дані старі або постачальник недоступний, доказом є чесно показаний вік і безпечне рішення про покупку, а не лише низький p95 каталогу.

Як описати вимогу до якості

Контекст і спосіб вимірювання нефункціональної вимоги

Загальні критерії, способи перевірки й докази докладно розглянуто в главі 10. Для нефункціональної характеристики особливо важливо зафіксувати:

Поле Що зафіксувати
Якість і причина Яку потребу або ризик захищає вимога
Сценарій Хто виконує яку дію та в якому стані системи
Показник Що вимірюється і де саме починається й закінчується таймер
Межа Значення, одиниця, допустима частка винятків і період
Навантаження й середовище Дані, частота, паралельність, версії, регіон, клієнт і залежності
Метод і доказ Інструмент, конфігурація, журнали або протокол ручної перевірки
Помилки й неповнота Як враховуються тайм-аути, часткові відмови, втрачені дані та неперевірені умови
Власник і перегляд Хто може змінити межу, на чому ґрунтується зміна та коли припущення перевірити знову

Наприклад: «Для внутрішньої бази процедур із 50 000 документів і 20 одночасними пошуками p95 часу від надсилання запиту до появи коректного списку результатів не перевищує 800 мс у підтримуваному браузері. Не менше 99% допустимих спроб повертають правильну відповідь до двосекундного дедлайну; тайм-аути й помилки рахуються як невдалі спроби. Значення є навчальними припущеннями, а не загальними порогами книги; власник продукту має перевірити їх базовим вимірюванням». Поріг без умов, способу вимірювання й статусу числа не є корисною обіцянкою.

Повніший приклад показує, як критерій якості можна пов’язати з доступом. Для авторизованого працівника, який відкриває картку призначеного йому клієнта у підтримуваному браузері, p95 часу від натискання до показу повних даних серед коректних відповідей не перевищує 700 мс у тесті з 500 умовними картками й 20 одночасними читаннями. Окремо щонайменше 99% усіх допустимих спроб повертають правильну відповідь до дедлайну в дві секунди; відмови й тайм-аути рахуються як невдалі спроби, а їхній час фіксується у звіті. Прямий запит до картки іншого працівника не повертає дані. Усі три числа — 700 мс, 99% і дві секунди — навчальні припущення власника до перевірки з реальними користувачами, а не універсальні норми.

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

Агент може допомогти виміряти й подати результат, але не має самостійно змінювати поріг, вибірку або облік невдалих спроб. Якщо перевірки не було, результат — «не перевірено», а не «пройдено». Для загальних правил роботи з критеріями й доказами див. главу 10.

Критерії різних властивостей мають лишатися окремими. Тест швидкості не доводить безпеку контролю доступу, а ручне проходження форми не доводить доставку повідомлення про помилку. Розділення допомагає зрозуміти, який доказ треба зібрати й кому передати дефект.

До завдання варто включити джерело й статус числа, середовище та метод, правила обліку помилок і межу повноважень. Якщо критерій не виконаний, агент надає фактичний результат і доказ та пропонує варіанти; він не збільшує межу, не змінює вибірку і не виключає невдалі спостереження без рішення власника. Чесний стан може бути «пройдено», «не пройдено», «не перевірено» або «потрібне рішення». Якщо поріг переглянули, збережіть первісну межу, виміряний результат, нову межу, підставу й дату.

Прочитайте звіт про затримку, не вигадуючи причину

Публічний звіт про Knative Serving описує службу прогнозування, основну обробку якої автор оцінював у 1–2 мс. У початковому прогоні приблизно 10 запитів за секунду протягом трьох хвилин дали середнє 13,46 мс, медіану 5,29 мс, p95 47,48 мс, p99 50,65 мс і максимум 705,94 мс. Усі 1800 відповідей мали код 200 — але це не спростовувало скаргу на повільну меншість запитів Knative Serving, issue #8057.

В одному трасуванні між початком запиту на шлюзі й початком його обробки на сервері минуло близько 51 мс, тоді як запис httpRequest.latency у журналі queue-proxy показував приблизно 2,97 мс. Це різні часові межі, і жодна з них сама по собі не доводить, де виникла затримка журнал і трасування, часові мітки.

Пізніші коротші прогони приблизно по 300 запитів за хвилину дали кілька різних p95: 76,32 мс, 39,90 мс і 3,69 мс. На прямому маршруті, що оминав проксі черги, три значення становили 2,66–2,68 мс. Автор припустив, що вузьким місцем можуть бути ресурси queue-proxy, і уточнив, що його запит CPU та пам’яті дорівнював ліміту контейнера — 1 vCPU і 500 МіБ; клас якості обслуговування Pod змінився з Burstable на Guaranteed. Для звичайної схеми контейнерів Guaranteed вимагає однакових ненульових запитів і лімітів CPU та пам’яті для кожного контейнера; Kubernetes також має окремий режим ресурсів на рівні Pod (Pod Quality of Service Classes). У наступних чотирьох прогонах p95 становив 8,79 мс, 7,35 мс, 2,12 с і 4,90 мс; усі мали по 300 успішних відповідей. Повний опис ресурсів усіх контейнерів і версії Kubernetes відсутній, тож неможливо незалежно перевірити конфігурацію чи причинність. Великий розкид, зокрема один p95 понад дві секунди, зберігся: це не рівномірне «виправлення» й не відтворений бенчмарк попередні прогони, пізніша зміна й результати. Такий звіт дає підставу порівняти межі вимірювання й гіпотези, але не проголошувати універсальну причину чи поріг.

Із такого кейсу слід винести процедуру, а не число: виміряти кінцевий запит і кілька ділянок його шляху; записати кількість, частоту, тривалість і конфігурацію навантаження; порівняти середнє, медіану, p95, p99 і максимум; сформулювати гіпотезу про вузьке місце, не називаючи її встановленою причиною; змінити одну умову й повторити схожий прогін; зберегти невдалі відповіді, середовище й межу вимірювання. Коректно сказати: «У цьому прогоні за цих умов спостерігали такі числа; два інструменти виміряли різні часові межі». Некоректно узагальнити це як «сервіс працює за 2,7 мс» або «високий p95 завжди означає проблему мережі».

Підсумок

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

Замість вимагати «швидкий і надійний продукт», визначте сценарій, навантаження, показник, поріг, період, середовище й реакцію на відмову. Перевірте припущення з власником, зафіксуйте компроміс і скажіть «не перевірено», коли доказу ще немає. Це дає основу для архітектурного вибору в наступних главах без складності, що не спирається на підтверджену потребу.

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

Джерела та подальше читання