SLA (Service Level Agreement)

Ця Угода про рівень сервісу (“SLA”) описує, як FinDay OS вимірює доступність, як ми працюємо з інцидентами та як комунікуємо планові роботи. SLA є доповненням до “Умов обслуговування (Terms of Service)” та “Умов продажу (Terms of Sale)”. У разі розбіжностей пріоритет має індивідуальний договір/специфікація клієнта, якщо вона підписана сторонами.

SLA створено для B2B-логіки: FinDay OS — Operating System фінансового дня, тому важлива не “обіцянка”, а чітка рамка — що вважається недоступністю, як швидко ми реагуємо, як відновлюємо, і що клієнт може очікувати прозоро.

Дата набрання чинності: 1 лютого 2026 року.

Канал інцидентів/підтримки: security@finday-os.com

1. Показник доступності

1.1. Цільова доступність (Uptime)

Базовий SLA (за замовчуванням для тарифів): 99.5% uptime на місяць.
Розширений SLA (за окремою домовленістю / Enterprise): 99.9% uptime на місяць.

Цільова доступність застосовується до виробничого середовища FinDay OS (“Production”) і означає частку часу, коли сервіс є доступним для більшості користувачів і ключові сценарії працюють у штатному режимі.

1.2. Як розраховується uptime

Uptime за календарний місяць розраховується за формулою:

Uptime % = (Загальний час місяця – Час недоступності) / Загальний час місяця × 100%

де час вимірюється в хвилинах.

1.3. Що вважається “недоступністю” (Downtime)

Недоступністю вважається ситуація, коли:

1. веб-інтерфейс FinDay OS або API (якщо використовується) не відповідає або повертає системні помилки, і

2. проблема відтворюється не менш ніж 5 хвилин поспіль, і

3. вона впливає на більшість користувачів або на критичні сценарії.

Недоступність може бути повною (сервіс “лежить”) або функціональною (критична функція не працює у продуктивному середовищі). Детальніше — у класифікації Severity (10.3).

1.4. Як фіксується факт недоступності

Час недоступності фіксується на основі:

• технічного моніторингу провайдера (health-checks, метрики, логи), та/або
• звернень клієнтів, які підтверджені як інцидент, та/або
• даних Status Page (якщо вона використовується як джерело істини щодо інцидентів).

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

2. Вікна планових робіт

2.1. Планові роботи (Scheduled Maintenance)

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

Стандартне вікно планових робіт: [наприклад, щонеділі 02:00–04:00 за Europe/Zaporozhye].
Якщо ви не хочете фіксованого вікна — можна використовувати формулювання: “переважно позаробочий час, з попередженням”.

2.2. Повідомлення про планові роботи

Ми повідомляємо про планові роботи:

• не пізніше ніж за 72 години — для значущих змін, які можуть вплинути на доступність або UX;
• не пізніше ніж за 24 години — для стандартних планових робіт;
• якнайшвидше — для термінових безпекових оновлень (Emergency Maintenance), коли чекати небезпечно.

Канали повідомлення: сервісне повідомлення в кабінеті, email адміністратора, Status Page (якщо є) або узгоджений канал підтримки.

2.3. Чи враховуються планові роботи в uptime

Планові роботи, про які було повідомлено завчасно, не враховуються як downtime, якщо інше прямо не зазначено у вашому індивідуальному SLA.
Аварійні безпекові роботи також можуть не враховуватися як downtime, якщо вони необхідні для захисту даних і мінімізовані за часом.

3. Рівні інцидентів (Severity)

Щоб реагувати не “однаково на все”, ми класифікуємо інциденти за рівнем впливу.

S1 — Critical Outage (повний даун):

• Сервіс недоступний або більшість користувачів не можуть увійти/працювати. Ключові сценарії зупинені.

S2 — Major (критична функція не працює):

• Сервіс частково доступний, але критичний контур або ключова операція не працює для значної частини користувачів (наприклад, неможливо створювати/проводити документи, не працює збереження, масові помилки у важливому модулі).

S3 — Minor Degradation (часткова деградація):

• Є збої або деградація, але існує обхідний шлях або вплив обмежений: повільна робота, локальні помилки, окремі екрани/функції працюють нестабільно, але бізнес-процес загалом не зупинений.

S4 — Request / Question (питання, консультація, запит):

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

4. Час реакції та час відновлення (RTO)

Нижче наведені цільові показники. Вони означають: коли ми починаємо роботу над інцидентом (реакція) і коли прагнемо відновити працездатність (RTO). Для частини випадків RTO може бути довшим через складність, але тоді клієнт отримує комунікацію з ETA та проміжними оновленнями.

4.1. Базовий SLA (стандартні тарифи)

Години підтримки: [наприклад, Пн–Пт 09:00–18:00 Europe/Zaporozhye], окрім свят/вихідних.
Для S1 ми реагуємо поза графіком best effort, якщо інше не визначено вашим тарифом.

• S1: реакція до 30 хв, RTO до 4 год

• S2: реакція до 2 год, RTO до 1 робочого дня

• S3: реакція до 1 робочого дня, RTO до 3 робочих днів

• S4: реакція до 2 робочих днів, рішення/відповідь — у “розумний строк” залежно від запиту

4.2. Розширений SLA (Enterprise / за договором)

Години підтримки: 24/7 для S1–S2, Пн–Пт для S3–S4 (або як погоджено).

• S1: реакція до 15 хв, RTO до 2 год

• S2: реакція до 1 год, RTO до 8 год

• S3: реакція до 4 год, RTO до 2 робочих днів

• S4: реакція до 1 робочого дня

4.3. Комунікація під час інциденту

Для S1–S2 ми надаємо оновлення статусу:

• не рідше ніж кожні 60 хвилин (або частіше, якщо є суттєві зміни),

• через Status Page / кабінет / погоджений канал.

Мета — щоб клієнт мав не “мовчання”, а керований контекст: що відомо, що робимо, які ризики, який орієнтир відновлення.

5. Винятки

Наступні випадки не враховуються як downtime або не підпадають під SLA по доступності, якщо інше не погоджено:

1. Форс-мажор (військові дії, масштабні відключення, аварії дата-центрів, катастрофи, рішення органів влади, масштабні кібератаки на інфраструктуру поза контролем провайдера).
2. Проблеми на стороні клієнта: інтернет, локальна мережа, VPN, пристрої, браузер, некоректні налаштування, блокування корпоративними політиками.
3. Проблеми сторонніх інтеграцій або сервісів клієнта (якщо вони впливають на сценарій, але не є частиною FinDay OS).
4. Планові роботи, про які повідомлено відповідно до 10.2.
5. Збої, спричинені діями клієнта або його користувачів: неправильні права доступу, помилкові масові операції, завантаження шкідливого контенту, порушення Terms of Service.

Якщо випадок на межі, ми розбираємо його по факту й даємо клієнту обґрунтований висновок на основі логів і технічних даних.

6. Компенсації / Service Credits (якщо застосовується)

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

6.1. Коли надаються Credits

Service Credits можуть надаватися, якщо фактичний uptime за місяць нижчий за цільовий показник вашого рівня SLA (10.1), за винятком випадків із 10.5.

6.2. Розмір Credits (приклад стандартної шкали)

Для 99.5% SLA (базового) можна використати таку шкалу:

• Uptime < 99.5% та ≥ 99.0% → 5% кредиту від місячної вартості підписки

• Uptime < 99.0% та ≥ 98.0% → 10% кредиту

• Uptime < 98.0% → 25% кредиту

Для 99.9% SLA (Enterprise) шкала зазвичай жорсткіша (за договором).

Ліміт: Service Credits не перевищують 100% вартості підписки за відповідний місяць і не є поверненням коштів. Це кредит, який застосовується до наступного рахунку/періоду.

6.3. Як оформляється Credits

Клієнт подає запит на credits протягом 30 календарних днів після завершення місяця, в якому сталася недоступність, через підтримку або billing-контакт, вказуючи:

1. акаунт/організацію;
2. місяць;
3. опис впливу (за потреби);
4. контакт адміністратора.

Провайдер підтверджує розрахунок uptime та, якщо умови виконані, застосовує credits до наступного платежу або рахунку.

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