Fester Release-Plan
Standardmäßig aktivPlattform-Releases erscheinen am ersten Dienstag jedes Monats am Abend (MEZ). Zusätzliche Releases kündigen wir mindestens drei Werktage vorher an, dringende Hotfixes spielen wir so schnell wie möglich ein.
Blits.ai sagt für Cloud-Deployments eine monatliche Verfügbarkeit von 99,5 % zu, misst sie auf einer öffentlichen Statusseite und hinterlegt sie mit Reaktions- und Lösungszeiten je Priorität. Hier finden Sie eine Zusammenfassung unseres Standard-Service-Level-Agreements.
Bei jeder Funktion ist angegeben, ob sie standardmäßig aktiv ist oder sich pro Assistent, Workflow oder Mandant konfigurieren lässt. Standards, die Kundendaten betreffen, lassen sich abschalten, wo Regulierung oder Ihre eigene Richtlinie es verlangt.
Monatliches Verfügbarkeitsziel für Cloud-Deployments. Verfügbarkeit ist die geplante Betriebszeit abzüglich ungeplanter Ausfallzeiten und Notfallwartungen, geteilt durch die geplante Betriebszeit. Für On-Premises-Deployments werden die Verfügbarkeitsziele im jeweiligen Vertrag vereinbart.
Aktueller Status auf status.blits.ai95 % der Fälle werden innerhalb dieser Zeiten beantwortet und gelöst.
| Priorität | Enterprise | Pro und Pro+ | ||
|---|---|---|---|---|
| Reaktion | Lösung | Reaktion | Lösung | |
| P1 Kritisch | 1 Stunde | 4 Stunden | 1 Stunde | 20 Stunden |
| P2 Hoch | 4 Stunden | 8 Stunden | 4 Stunden | 48 Stunden |
| P3 Mittel | 1 Werktag | 5 Werktage | 1 Werktag | 5 Werktage |
| P4 Niedrig | 2 Werktage | 2 Wochen | 2 Werktage | 4 Wochen |
P1 bedeutet: Die Produktivumgebung ist ausgefallen oder so stark beeinträchtigt, dass nicht weitergearbeitet werden kann. P2 bedeutet: Kritische Funktionen sind nicht verfügbar, und es gibt keinen Workaround. An P1- und P2-Fällen wird ohne Unterbrechung gearbeitet, bis sie gelöst sind, mit Statusmeldungen jede Stunde bei P1 und alle vier Stunden bei P2.
Ein fester Release-Rhythmus, Tests vor jedem Release und ein schneller Weg zurück.
Plattform-Releases erscheinen am ersten Dienstag jedes Monats am Abend (MEZ). Zusätzliche Releases kündigen wir mindestens drei Werktage vorher an, dringende Hotfixes spielen wir so schnell wie möglich ein.
Freigegebene inhaltliche Änderungen gehen mit dem Content-Release am Donnerstagabend live, spätestens fünf Werktage nach der Freigabe.
Vor einem Release wird der Assistent mit jeder betroffenen Frage getestet, und jede Antwort wird mit der erwarteten Antwort abgeglichen. Der Kunde erhält den Testbericht.
Jede Guardrail hat einen eigenen Testfall, und alle laufen vor jedem Release. So greift eine Guardrail weiterhin, auch wenn sich die Inhalte um sie herum ändern.
Jede Veröffentlichung erzeugt eine nummerierte, unveränderliche Version des gesamten Assistenten, mit Autor, Datum, Release Note und einem Diff zur vorherigen Version.
Ein Assistent lässt sich so einstellen, dass er erst in Produktion geht, wenn eine ausgewählte Testsuite einschließlich Latenzprüfungen mit der neuen Version besteht. Wer das Gate übergehen will, braucht Admin-Rechte und eine Begründung, und der Vorgang wird protokolliert.
Die Produktion lässt sich mit einem Klick auf eine frühere Version zurückstellen, ohne laufende Gespräche zu unterbrechen. Jedes Release wird als vollständiger Snapshot gespeichert, sodass der vorherige Stand innerhalb weniger Minuten wiederhergestellt ist, während die Ursache untersucht wird.
Woran wir erkennen, dass die Plattform gesund ist, bevor ein Kunde uns etwas meldet.
Die Verfügbarkeit wird gemessen und auf status.blits.ai veröffentlicht. Kunden erhalten sie monatlich zusammen mit der Fallstatistik.
Jeder Service stellt Liveness- und Readiness-Checks bereit, einschließlich der Datenbankverbindung. Fehlerhafte Instanzen werden automatisch ersetzt.
Nach jedem Deployment vergleicht eine automatische Prüfung die aktuellen Antwortzeiten mit einer Baseline. Werden sie schlechter, wird das Deployment markiert.
Jede Region läuft als eigene Produktivumgebung. Ein Vorfall in einer Region betrifft deshalb keine Kunden in einer anderen.
Sprachmodelle schwanken von Natur aus. Diese Mechanismen halten die Antworten dort vorhersehbar, wo es darauf ankommt.
Die Temperature wird pro Assistent eingestellt: standardmäßig 0,7 und anpassbar, etwa niedriger für faktenbasierte Antworten. Guardrail-Prüfungen laufen mit 0,1.
Abläufe, die immer gleich verlaufen müssen, laufen als BPMN-Flows mit festen Schritten und exaktem Wortlaut. Die Intent-Erkennung übernimmt Microsoft CLU, IBM, Google oder Wit.
Testsets mit mehreren Gesprächsrunden, bewertet von einem Modell oder nach deterministischen Regeln. Sie laufen auf Abruf oder nach Zeitplan, von alle 5 Minuten bis einmal täglich, mit Alarmen per E-Mail oder Webhook.
Wir arbeiten gemeinsam an Ihrem Anwendungsfall, mit Ihren Daten und den Modellen Ihrer Wahl.
Gespräch vereinbaren