Визначте, що повинна довести репетиція
Випуск API звітності може вимагати перевірки конфігурації, сумісності схеми, автентифікованого запиту та завершеного експорту. Не кожен огляд потребує даних виробничого розміру. Спочатку напишіть перевірки, потім визначте властивості середовища, які суттєво впливають на їхній результат.
Використовуйте авторизоване невиробниче призначення, незалежні облікові дані, відомий артефакт та синтетичні або належним чином знеособлені записи. Якщо вимоги до обробки даних незрозумілі, використовуйте синтетичні дані. Вибір Швейцарії або Панами для сервера PrivacyNodes не встановлює угоду про обробку даних і не визначає, де зберігається кожна копія даних або резервна копія.
Виберіть, що повинно бути окремим
| Компонент | Вибір staging | Перевірка |
|---|---|---|
| База даних | Окрема база даних і роль | Роль не може читати виробництво |
| Черга | Окремий брокер або примусова межа доступу | Жодних виробничих завдань не спожито |
| Об'єктне сховище | Окремі облікові дані та призначення | Експорт потрапляє лише до тестового сховища |
| Електронна пошта/вебхуки | Захоплення в пастку або схвалена пісочниця | Жодного реального одержувача не повідомлено |
| Заплановані завдання | Вимкнено, якщо не задіяно | Жодного дубльованого живого розкладу |
| Хост | Спільний або окремий за рішенням | Задокументовано зв'язок ресурсів і відмов |
Окремі бази даних на одному хості все одно спільно використовують ресурси та межу відмови. Окремі хости зменшують деякий зв'язок, але не можуть виправити облікові дані, що вказують на виробництво. Перевіряйте призначення та дозволи, а також розміщення процесів. Доступ адміністратора хоста та доступ до демона Docker можуть підірвати інакше ретельну ізоляцію застосунків.
Перевіряйте вплив, а не довіряйте назві
Публікація Docker-порту без адреси хоста зазвичай відкриває його на всіх адресах хоста. Явне прив'язування до loopback звужує доступ у задокументованій конфігурації bridge/NAT, але не є повноцінним дизайном контролю доступу. Docker документує застереження щодо однієї мережі для версій, старіших за 28.0.0, та відмінності в поведінці між режимами мережі. Перевірте встановлену версію та топологію.
Трафік контейнерів може обходити шлях UFW, який очікує оператор. Не робіть висновок, що база даних приватна, лише за статусом брандмауера, і не вимикайте правила фільтрації пакетів Docker як обхідний шлях. Перевірте передбачуваний доступ із окремого клієнта на адресних сімействах, що використовуються, не експериментуючи на робочому брандмауері.
Технічна довідка: Публікація Docker-портів · Фільтрація пакетів Docker і брандмауери.
Зробіть тестові дані корисними та обмеженими
Створіть синтетичні облікові записи з реалістичними зв'язками та граничними випадками: порожній експорт, великий звіт і відкликаний обліковий запис. Збережіть форми, які перевіряють міграцію, без збереження зайвих ідентифікуючих деталей. Задокументуйте джерело, процес анонімізації та дату видалення для будь-якої схваленої копії даних.
Не надавайте робочі поштові або платіжні облікові дані для проходження перевірки конфігурації. Використовуйте пісочницю або контрольоване призначення. Також перевірте поведінку при збої: вимкнена інтеграція повинна давати відому відповідь, а не повторні спроби проти живого сервісу. Перевірте тестовий експорт і приймач захоплення, щоб підтвердити, що передбачуваний шлях справді відбувся.
Запишіть відмінності, які обмежують результат
Тримайте основні версії середовища виконання, схему конфігурації та порядок міграцій узгодженими там, де вони визначають поведінку. Фіксуйте відмінності в розмірі бази даних, стані кешу, паралелізмі воркерів і залежностях. Успішна функціональна перевірка не доводить продуктивність або затримку в продакшені.
Staging на спільному малому хості може конкурувати з продакшеном, що робить репетицію та бюджет живих ресурсів недійсними. Окремий скромний хост може бути простішим для розуміння під час функціональної валідації релізу. Навантажувальні тести або великі міграції потребують потужності, відповідної цьому завданню; найменший профіль не є універсальною потужністю для staging.
Включіть демонтаж до визначення завершеності
Зафіксуйте артефакт, результат міграції, димові перевірки та відмінності від цільового середовища. Відкличте тимчасовий доступ, дозвольте експортам закінчитися та видаліть одноразові дані згідно з політикою. Підтвердьте, що заплановані завдання залишаються вимкненими, і жоден воркер не вказує на живе призначення.
The Сценарій проміжного середовища порівнює зосереджений бюджет Dev 1 із більшою репетицією. Поєднайте це з запису релізу. Результатом є задокументований набір корисних перевірок і меж, а не твердження, що staging точно відтворює продакшен.
Офіційні посилання
Документацію переглянуто для цієї статті. Приклади — це планувальні вправи, а не команди, перевірені на сервері PrivacyNodes. Перевірте документацію для вашої встановленої версії.