Трохи довше, трохи дешевше · Збережіть 28% за 6 місяців або 50% за рік, сплачено один раз Дивіться плани ↗

Доступ і робота · 5 хв читання

Тримайте роботу за сторінкою передбачуваною.

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

Перш ніж почати

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

1. Перелічте, що відбувається без відвідування сторінки.

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

Деяке програмне забезпечення пропонує кілька механізмів планування з різною поведінкою. Наприклад, Nextcloud 33 документує завдання AJAX, що запускаються відвідуванням сторінки, та окремо заплановані альтернативи, рекомендуючи cron для регулярного виконання. Тихому сервісу, отже, може знадобитися ретельніше планування, а не менш ретельне. Дотримуйтеся документації для тієї версії та способу встановлення, які ви використовуєте. Фонові завдання Nextcloud 33.

2. Дайте кожному завданню коротку операційну картку.

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

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

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

3. Простежте сповіщення далі за «надіслати».

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

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

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

4. Визначте, що означає повторення.

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

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

5. Обмежте побічні ефекти під час відновлення.

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

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

6. Перевірте невеликий, спостережуваний результат.

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

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

7. Призначте наступну перевірку.

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

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

Документація до цієї нотатки

Використовуйте документацію для тієї версії, яку ви насправді запускаєте. Ці приклади є матеріалом для планування, а не записом про тестування на VPS Hoszen.