Vaste releaseplanning
Standaard aanPlatformreleases gaan live op de eerste dinsdag van elke maand, 's avonds (CET). Extra releases kondigen we minstens drie werkdagen vooraf aan, en spoedhotfixes brengen we zo snel mogelijk uit.
Blits.ai garandeert een beschikbaarheid van 99,5% per maand voor implementaties in de cloud. Die beschikbaarheid meten we op een openbare statuspagina, en we koppelen er reactie en oplostijden per prioriteit aan. Hieronder vindt u een samenvatting van onze standaard Service Level Agreement.
Bij elke functie staat of die standaard aan staat of configureerbaar is per assistent, workflow of tenant. Standaardinstellingen die klantgegevens raken, kunt u uitzetten waar regelgeving of uw eigen beleid dat vraagt.
Doelstelling voor de maandelijkse beschikbaarheid van implementaties in de cloud. Beschikbaarheid is de geplande uptime min ongeplande downtime en spoedonderhoud, gedeeld door de geplande uptime. Voor implementaties on-premises worden de beschikbaarheidsdoelen per contract afgesproken.
Actuele status op status.blits.aiVoor 95% van de meldingen geldt dat we binnen deze tijden reageren en ze oplossen.
| Prioriteit | Enterprise | Pro en Pro+ | ||
|---|---|---|---|---|
| Reactie | Oplossing | Reactie | Oplossing | |
| P1 Kritiek | 1 uur | 4 uur | 1 uur | 20 uur |
| P2 Hoog | 4 uur | 8 uur | 4 uur | 48 uur |
| P3 Gemiddeld | 1 werkdag | 5 werkdagen | 1 werkdag | 5 werkdagen |
| P4 Laag | 2 werkdagen | 2 weken | 2 werkdagen | 4 weken |
P1 betekent dat productie plat ligt of zo zwaar verstoord is dat er niet verder gewerkt kan worden. P2 betekent dat kritieke functies niet beschikbaar zijn en er geen workaround is. Aan P1 en P2 wordt onafgebroken gewerkt tot ze zijn opgelost, met elk uur een statusupdate bij P1 en elke vier uur bij P2.
Een vast releaseritme, tests voor elke release en een snelle weg terug.
Platformreleases gaan live op de eerste dinsdag van elke maand, 's avonds (CET). Extra releases kondigen we minstens drie werkdagen vooraf aan, en spoedhotfixes brengen we zo snel mogelijk uit.
Goedgekeurde contentwijzigingen gaan live in de contentrelease op donderdagavond, binnen vijf werkdagen na goedkeuring.
Voor een release beantwoordt de assistent elke vraag die door de wijziging wordt geraakt, en elk antwoord wordt vergeleken met het verwachte antwoord. De klant ontvangt het testrapport.
Elke guardrail heeft een eigen testcase en ze draaien allemaal voor elke release. Zo blijft een guardrail werken als de content eromheen verandert.
Elke publicatie maakt een genummerde, onveranderlijke versie van de hele assistent, met auteur, datum, releasenotitie en een diff ten opzichte van de vorige versie.
U kunt instellen dat een assistent pas in productie komt als een gekozen testsuite, inclusief latencycontroles, slaagt op de nieuwe versie. Alleen een beheerder kan de gate omzeilen, met opgave van een reden, en dat wordt gelogd.
Productie kan met één klik worden teruggezet naar een eerdere versie, zonder dat lopende gesprekken worden onderbroken. Elke release wordt opgeslagen als volledige snapshot, zodat de vorige situatie binnen enkele minuten is hersteld terwijl de oorzaak wordt onderzocht.
Hoe we weten dat het platform gezond is voordat een klant ons iets meldt.
Beschikbaarheid wordt gemeten en gepubliceerd op status.blits.ai, en maandelijks samen met statistieken over meldingen aan klanten gerapporteerd.
Elke service heeft liveness en readiness checks, inclusief de verbinding met de database. Instances die falen, worden automatisch vervangen.
Na elke deployment vergelijkt een automatische controle de actuele reactietijden met een baseline. Lopen die terug, dan wordt de deployment gemarkeerd.
Elke regio draait als eigen productieomgeving. Een incident in de ene regio raakt dus geen klanten in een andere.
Taalmodellen variëren van nature. Met deze instellingen blijven antwoorden voorspelbaar waar dat nodig is.
De temperature stelt u per assistent in: standaard 0,7 en aan te passen, bijvoorbeeld lager voor feitelijke antwoorden. Guardrailcontroles draaien op 0,1.
Klantroutes die altijd op dezelfde manier moeten verlopen, draaien als BPMN-flows met vaste stappen en exacte formuleringen. Intentherkenning gebeurt met Microsoft CLU, IBM, Google of Wit.
Testsets met gesprekken over meerdere beurten, beoordeeld door een model of door deterministische regels. Ze draaien op aanvraag of volgens een planning, van elke 5 minuten tot eens per dag, met meldingen per e-mail of webhook.
We organiseren een werksessie over uw use case, met uw data en de modellen die u kiest.
Plan een gesprek