Model serwisowy i utrzymanie¶
Zasada¶
Serwis NORBI obejmuje oprogramowanie, modele, integracje, sprzęt, dane i proces. „System działa” nie znaczy wyłącznie, że port odpowiada. Usługa jest zdrowa, gdy jobs są wykonywane poprawnie, kolejki mieszczą się w SLO, backup jest świeży i odtwarzalny, a security gates nie wykazują naruszeń.
Warstwy odpowiedzialności¶
| Warstwa | Właściciel podstawowy | Zakres |
|---|---|---|
| proces i decyzje | klient / process owner | reguły, wyjątki, dane, approval, wynik biznesowy |
| aplikacja NORBI | maintainer / partner | core, UI, registries, migrations, release |
| pakiet branżowy | publisher + partner | workflow, adapters, datasets, zgodność domenowa |
| infrastruktura | klient lub managed partner | sprzęt, OS, sieć, UPS, backup, KVM |
| provider zewnętrzny | dostawca + klient | konto, SLA API, transfer danych, koszt |
| model lokalny | registry owner | provenance, benchmark, runtime compatibility |
RACI jest zapisane w umowie i runbooku. Norbi nie bierze odpowiedzialności prawnej za decyzję, którą policy wyraźnie przypisuje człowiekowi.
Pakiety serwisowe¶
Community / Self-managed¶
Kod i dokumentacja, narzędzia diagnostyczne, community updates. Bez gwarantowanego czasu reakcji. Klient odpowiada za sprzęt, backup i integracje. Dobre dla laboratorium i użytkownika technicznego.
Care¶
Stabilne kanały aktualizacji, health review, kwartalny raport, wsparcie w godzinach roboczych, kontrola backupu, compatibility advisories i określona liczba konsultacji. Bez zdalnej administracji domyślnie.
Business¶
Monitoring health za zgodą, szybsze SLA, incident coordination, test aktualizacji na stagingu, okresowe recovery drill, capacity review, partner support dla pakietów branżowych i szkolenie operatorów.
Critical / Managed¶
24/7 on-call, redundantna architektura, zapasowe części/worker, ścisłe RTO/RPO, change advisory, regularny failover, dedykowany security kontakt i możliwość kontrolowanego remote support. Nie oznacza stałego nieograniczonego dostępu dostawcy.
Zdalny serwis¶
Remote support jest sesją czasową. Klient inicjuje lub zatwierdza dostęp, zakres hostów, czas i czynności. Sesja używa osobnej tożsamości partnera, MFA, recording/audit commandless operations i expiry. Partner nie dostaje sekretów modelowych ani broad admin account na stałe. KVM access wymaga wyższego poziomu niż zwykły odczyt health.
SLO i priorytety¶
| Severity | Przykład | Cel reakcji | Domyślna akcja |
|---|---|---|---|
| SEV1 | utrata Control Plane, możliwy incydent danych, brak recovery | natychmiast według pakietu | stop effects, incident lead, recovery |
| SEV2 | ważny workflow niedostępny, jeden krytyczny worker | szybka reakcja | workaround, failover, diagnosis |
| SEV3 | degradacja jakości/latency, błąd ograniczony | następne okno robocze | triage, candidate fix |
| SEV4 | pytanie, kosmetyka, ulepszenie | backlog | plan release |
SLA jest mierzone od prawidłowego zgłoszenia/alertu, ale monitoring nie może wysyłać prywatnych danych bez umowy. RTO/RPO są per usługa. Model zewnętrzny może mieć inne SLA niż lokalny core.
Utrzymanie cykliczne¶
Codziennie: health, queue, storage, backup outcome, cert expiry, camera/worker offline. Tygodniowo: warnings, failed jobs, cost anomalies, drift. Miesięcznie: patch candidate, access deltas, capacity, model quality. Kwartalnie: recovery drill, access review, autonomy review, plugin/model lifecycle. Rocznie: threat model, pełny restore/failover, umowy, sprzęt lifecycle i certyfikacja partnera.
Proces zgłoszenia¶
Ticket zawiera projekt, czas, objaw, impact, correlation/job ID i zgodę na zakres danych. Norbi może automatycznie zebrać zredagowany support bundle: wersje, health, relevant receipts i logi bez sekretów. Wysłanie bundle na zewnątrz wymaga policy/approval. Serwis tworzy hipotezy, reprodukcję i candidate; nie edytuje aktywnego środowiska ad hoc.
Przykładowe polecenia¶
- „Przygotuj zredagowany pakiet diagnostyczny dla incydentu, ale go nie wysyłaj.”
- „Pokaż urządzenia, których certyfikaty wygasną w 30 dni.”
- „Zaplanuj kwartalny test restore bez przełączania produkcji.”
- „Otwórz czasową sesję partnera tylko do odczytu health na dwie godziny.”
Walidacja serwisu¶
Mierzy się availability właściwych funkcji, success rate workflow, MTTA/MTTR, change failure rate, restore success, backup freshness, security findings, reopen rate i satysfakcję użytkownika. Liczba zamkniętych ticketów nie jest wystarczająca. Każda zmiana serwisowa ma evidence i post-change validation.
Ryzyka i scenariusz awaryjny¶
Ryzyka to vendor lock-in, stały zdalny admin, serwis bez wiedzy domenowej, nieprzetestowany backup i „hot fix” bez candidate. Umowa wymaga eksportowalnych danych, dokumentacji, lokalnych credentials klienta, change protocol i exit plan.
W awarii SEV1 klient może odciąć partnera i przejść do lokalnego recovery. Break-glass nie unieważnia późniejszego audytu. Po incydencie odbywa się blameless review: timeline, przyczyna, czynniki systemowe, skuteczność runbooku, dane narażone, corrective actions, właściciele i terminy.