Перш ніж почати
- Перелік застосунків, планувальників і зовнішніх сервісів, які використовуються.
- Доступ до стану завдань застосунку та належно відредагованих журналів.
- Окреме тестове середовище та затверджене призначення для тестових сповіщень.
2. Дайте кожному завданню коротку операційну картку.
Використовуйте один рядок для кожної окремої одиниці роботи. Додайте часовий пояс, ідентичність виконання, звичайну тривалість після вимірювання, останній корисний результат і відповідального за збої. Не вносьте до картки паролі, токени чи повні тексти приватних сповіщень.
| Гіпотетичне завдання | Тригер | Корисний результат | У разі збою |
|---|---|---|---|
| Тижневий дайджест вікі | Узгоджений тижневий розклад | Одне зведення для призначених одержувачів | Редактор перевіряє список одержувачів і шлях доставки |
| Очищення файлів | Розклад обслуговування застосунку | Видалено придатні тимчасові роботи | Супровідник перевіряє помилки завдань і зростання дискового простору |
| Нагадування календаря | Налаштоване нагадування події | Очікуване нагадування для тестової події | Власник перевіряє налаштування події та відправника |
| Незалежна резервна копія | Узгоджений розклад резервного копіювання | Нова точка відновлення із зафіксованим результатом | Власник резервної копії досліджує, перш ніж припускати покриття |
Наведені вище розклади — це приклади для ухвалення рішення, а не типові значення, які слід копіювати в застосунок. Зафіксуйте, як поводиться пропущена робота після простою: пропускається, надолужується чи ставиться в чергу на потім.
3. Простежте сповіщення далі за «надіслати».
Опишіть шлях від події застосунку до черги або процесу надсилання, далі до поштового сервісу та призначеного одержувача. Зафіксуйте, хто контролює обліковий запис для надсилання, де уповноважені супровідники отримують облікові дані та які обмеження чи звіти про збої надає цей сервіс. Вибір ресурсів VPS сам по собі не забезпечує робочого налаштування вихідної пошти.
Документація Nextcloud явно описує підключення до робочого поштового сервера, а не містить власного повноцінного поштового сервера. Його функція тестового листа допомагає перевірити налаштований шлях надсилання. Налаштування електронної пошти Nextcloud 33.
BookStack також використовує електронну пошту для процесів керування обліковими записами та пропонує вихідні вебхуки для інтеграцій, керованих подіями. Додайте обидва до карти залежностей, коли їх увімкнено; зламаний відправник може вплинути як на відновлення, так і на зручність. Електронна пошта та вебхуки BookStack.
4. Визначте, що означає повторення.
Для кожного завдання поставте два запитання: чи може інший запуск початися до завершення цього, і що станеться, якщо воно повториться після виконання частини своєї роботи? Оновлення індексу файлів і повідомлення, надіслане кожному учаснику, мають різні наслідки. Зафіксуйте поведінку застосунку щодо паралельності та повторних спроб, а не припускайте, що всі завдання можна безпечно запускати двічі.
У гіпотетичному тижневому дайджесті власник веде запис про призначений звітний період і перевіряє, чи для цього періоду вже було завершене надсилання, перш ніж повторювати вручну. Це операційна перевірка, а не твердження, що обраний застосунок реалізує придушення дублікатів. Якщо він не надає належних засобів контролю, виберіть безпечнішу процедуру ручного відновлення, перш ніж покладатися на це завдання.
5. Обмежте побічні ефекти під час відновлення.
Відновлена база даних може містити незавершену роботу або старіший стан подій. Перш ніж запускати тестову копію, не дайте їй зв’язатися з реальними одержувачами чи зовнішніми системами. Ізолюйте тестове середовище, вимкніть його планувальники та обробники, як належить, і спрямуйте явно дозволений тестовий вивід до контрольованого призначення. Не припускайте, що інше ім’я хоста змінює збережених одержувачів або URL-адреси вебхуків.
Для прикладу з майстерні тестова копія має дозволити супровіднику перевірити сторінку та вкладення, не надсилаючи повторно торішній дайджест. Зафіксуйте, які завдання залишаються зупиненими, як ви перевірятимете незавершену роботу та хто може дозволити обмежений тестовий запуск. Перед реальним переходом визначте, який екземпляр володіє запланованою роботою, щоб стара й нова копії не виконували її обидві.
6. Перевірте невеликий, спостережуваний результат.
Використайте нешкідливу тестову подію з упізнаваною міткою та одним затвердженим тестовим одержувачем. Зафіксуйте час тригера, початок завдання, результат завершення та фактичне отримання, де це застосовно. Перевірте вміст і посилання, а також факт надходження. Успішна дія в застосунку не доводить, що кожен призначений одержувач отримав повідомлення.
Якщо нічого не надходить, перевіряйте тригер, планувальник, помилку завдання та шлях відправника по черзі. Якщо надходять дублікати, припиніть повторні ручні спроби та з’ясуйте, який екземпляр або завдання створив кожну спробу. Якщо робота затримується, порівняйте вік черги чи незавершеного завдання з часом виконання та використанням ресурсів. Зберігайте стислі докази, не копіюючи токени, тексти приватних повідомлень чи зайві адреси до загальних нотаток.
7. Призначте наступну перевірку.
Виберіть інтервал перегляду, що відповідає наслідкам збою. Зламаний відправник відновлення облікового запису потребує іншої реакції, ніж запізнілий тижневий дайджест. Визначте, хто перевіряє останній успішний результат, коли сповіщення відсутнє, і подбайте, щоб сам канал сповіщень не був єдиним способом виявити зламаного відправника.
Тримайте картки завдань разом із вашим реєстр сервісів. Додайте їх до навчання з відновлення та рутини обслуговування. Цей посібник описує спосіб організувати й перевірити вибране програмне забезпечення; він не надає керованого планувальника, гарантії доставки повідомлень чи виконаного результату тесту.
Документація до цієї нотатки
Використовуйте документацію для тієї версії, яку ви насправді запускаєте. Ці приклади є матеріалом для планування, а не записом про тестування на VPS Hoszen.