From 412178055f9aa992f430894b6e4ac2c9db3f4d85 Mon Sep 17 00:00:00 2001 From: OfficeCom Codex Date: Thu, 30 Jul 2026 00:53:22 +0200 Subject: [PATCH] Define reversible beta rollout model --- docs/roadmap.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) diff --git a/docs/roadmap.md b/docs/roadmap.md index 2e42817..840d7c1 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -21,6 +21,73 @@ Incident-Protokollen. - Datenminimierung: zentrale Speicherung nur von verdichteten Ereignissen und Incident-Kontext, nicht von vollstaendigen Dateilisten. +## Beta- und Rollback-Modell + +Jede neue Erkennung, Datenart und UI-Aenderung durchlaeuft denselben +reversiblen Lieferweg. Eine Funktion wird nie erstmals auf dem gesamten Bestand +aktiv geschaltet. + +### Stufe 0: Spezifikation und lokale Tests + +- Zweck, Datenfelder, Bewertung und erwartete Last werden vor dem Coding + dokumentiert. +- Beispielereignisse decken Normalfall, Hinweis, Warnung, kritisch und Fehler + ab. +- Der Client muss bei fehlender neuer Konfiguration das bisherige Verhalten + unveraendert beibehalten. + +### Stufe 1: Interne Beta + +- Das Paket wird als separater Beta-Release veroeffentlicht; `stable` bleibt + unveraendert. +- Eine neue Funktion ist per Feature-Schalter standardmaessig deaktiviert. +- Die Beta wird nur auf Testgeraeten bzw. einer internen Organisation verteilt. +- Zentrale Auswertung prueft Laufzeit, Upload-Volumen, Fehler und Datenformate. + +### Stufe 2: Passiver Kunden-Pilot + +- Ausgewaehlte Geraete erhalten die Beta mit aktivierter Funktion im + Beobachtungsmodus. +- Signale erscheinen in Protokoll und Dashboard, loesen aber keine NinjaOne- + Alarmbedingung aus. +- Der Pilot laeuft mindestens eine realistische Arbeitswoche, bei Fileservern + inklusive der normalen Spitzenzeiten. + +### Stufe 3: Kontrollierte Alarmierung + +- Erst nach Auswertung werden Warnungen fuer eine kleine, benannte Pilotgruppe + an NinjaOne uebergeben. +- Hinweise bleiben weiterhin rein informativ. +- Schwellenwerte, Ausnahmen und Empfaenger werden pro Pilot dokumentiert. + +### Stufe 4: Stable-Rollout + +- Rollout zuerst je Organisation oder Richtlinie, nicht an alle Kunden zugleich. +- Der Stable-Kanal wird erst nach erfolgreichem Pilot, Review der Datenqualitaet + und Freigabe der Alarmbedingungen aktualisiert. +- Die vorherige Stable-Version bleibt als signiertes Release verfuegbar. + +### Rueckfall + +- Sofort: Feature-Schalter in der Richtlinie deaktivieren. Der Client bleibt + installiert, sammelt fuer diese Funktion aber nichts mehr. +- Kurzfristig: Pilotgeraete ueber NinjaOne auf die vorherige Stable-Version + zuruecksetzen. +- Zentral: Die Auswertung kann das neue Feld ignorieren; neue JSON-Felder sind + immer optional und muessen abwaertskompatibel bleiben. +- Datenbankaenderungen werden nur additiv eingefuehrt. Loeschende oder nicht + rueckgaengig zu machende Migrationen gehoeren nicht in eine Beta. + +### Abbruchkriterien + +Ein Pilot wird pausiert und zurueckgesetzt, wenn eines dieser Kriterien eintritt: + +- spuerbare Last oder Beeintraechtigung auf einem Kundenserver, +- unkontrolliertes Upload- oder Queue-Wachstum, +- fehlerhafte Organisationszuordnung oder unerwartete personenbezogene Daten, +- mehr als ein unbegruendeter NinjaOne-Alarm im Pilot ohne klare Korrektur, +- fehlende oder nicht nachvollziehbare Incident-Protokolle. + ## Ausgangslage: geliefert - Endpoint-Client mit signiertem Upload und lokaler NinjaOne-Feldaktualisierung. @@ -31,6 +98,18 @@ Incident-Protokollen. Einzelne Tippfehler erzeugen keinen Alarm; Anmelde-Bursts und Password Spraying werden als Warnung oder kritisch bewertet. +## Voraussetzung: 1.4.1 Beta-Auslieferung + +- Eigener Beta-Manifest-Pfad neben `release/stable/version.json`. +- Eigene NinjaOne-Aufgabe fuer Pilotgeraete, die ausschliesslich den + Beta-Manifest-Pfad verwendet. +- Stable-Aufgabe bleibt unveraendert und ist zugleich der schnelle Rollback auf + die letzte freigegebene Version. +- Beta-Releases werden in Gitea als Vorabversion markiert und erhalten dieselbe + Paket-Hash-Pruefung wie Stable-Releases. +- Jeder Pilot dokumentiert Geraete, Organisation, aktivierte Feature-Schalter, + Startzeitpunkt und verantwortliche Person. + ## Naechster Schwerpunkt: 1.5 Ransomware-Frueherkennung ### 1.5.0: Leichtgewichtiger Fileserver-Sensor @@ -73,6 +152,8 @@ Incident-Protokollen. - Nachweis, dass normale Dateiaktivitaet von vielen Benutzern keinen Alert erzeugt und ein simuliertes Mehrsignal-Szenario korrekt eskaliert. - Offline-Pufferung, Deduplizierung und Retry des Incident-Protokolls getestet. +- Start als interne Beta gemaess dem Beta- und Rollback-Modell; der Sensor wird + erst nach dem passiven Fileserver-Pilot als NinjaOne-Alarm aktiviert. ### 1.5.1: Tuning und kontrollierter Rollout