Zelf een voice-stack hosten: wie draagt de pieper?

Wat je werkelijk vervangt

Het helpt precies te zijn over de omvang, want "de voice-agent zelf hosten" betekent meestal zes dingen zelf hosten die toevallig naast elkaar liggen. Elk daarvan heeft volwassen open-source opties, en elk daarvan is een component die je vanaf nu onderhoudt.

Die laatste rij is waar de meeste schattingen misgaan. Het interessante engineeringwerk zit in de eerste vijf; het blijvende werk zit in de zesde. Een voice-platform is vooral het oppervlak rond het gesprek: de registratie van wat er gebeurde, de koppelingen naar je eigen systemen, het bewaarbeleid, en het ding dat je een klant laat zien als hij vraagt wat de agent zei.

De rekening die niet in de spreadsheet staat

De besparing per minuut is echt en makkelijk te berekenen. Deze kosten zijn even echt en blijven eruit, vooral omdat het mensen zijn en geen factuurregels.

1. 01

   Iemand neemt 's nachts de telefoon op

   Een telefoonlijn is een synchrone dienst die tijdens kantooruren kritisch is en geen herhaalpogingen kent. Een wachtrij kan een storing van twintig minuten opvangen, een beller niet. Dat betekent een rooster, en een rooster heeft minstens twee mensen nodig die de stack beide kennen, en dat is een wezenlijk ander wervingsprobleem dan één persoon die het opzette.
2. 02

   De upgrade-tredmolen stopt niet

   De agent-frameworks in deze hoek bewegen snel, en voice-plugins breken op manieren die unit tests niet zien: een modelwissel die stil de beurtwisseling verandert, een transcriptieplugin die een parameter nodig heeft die de vorige versie niet nodig had. Elke upgrade vraagt echte testgesprekken, niet een groen CI-vinkje.
3. 03

   Je hebt nu een carrier-relatie

   Nummers, porteringen, trunkcapaciteit, fraudecontroles, en iemand om naar te escaleren als het probleem bóven jou zit. Dat is een inkoop- en operatieverantwoordelijkheid, geen technische, en het is niemands favoriete werk.
4. 04

   Observability moet je bouwen, niet kopen

   Je hebt sporen per gesprek nodig die SIP, media en modelbeurten overspannen, want dat is de enige manier om "waarom was dít gesprek slecht" te beantwoorden. Generieke APM geeft je dat niet. Het gesprekniveau-gereedschap in deze markt ook niet, want dat stopt grotendeels boven de transportlaag.
5. 05

   Herstel telt pas als het getest is

   Een back-up die je nooit hebt teruggezet is alleen een aanname. Een failover die je nooit bewust hebt aangezet bestaat alleen op papier. Beide vragen doelbewust, ingepland en licht angstaanjagend werk dat altijd verliest van featurewerk, tenzij iemand het beschermt.

Hoe een voice-storing om 3 uur 's nachts eruitziet

Abstracte kosten voor bereikbaarheidsdienst zijn makkelijk weg te wuiven, dus hier de concrete versie. Dit type incident is gewoon in plaats van exotisch, en dat is precies het punt.

03:12  alert     inkomende gesprekken falen · 14 in 4 min
03:12  jij       wordt wakker
03:19  triage    SIP registreert prima · 200 OK op INVITE
03:24  triage    geen uitgaande RTP · media staat vast
03:31  gevonden  STT-worker OOM-killed, herstart, poort
                 opnieuw gebonden achter oude NAT-mapping
03:38  fix       mediapad herstarten, workers leegtrekken
03:44  check     testgesprek · tweerichtingsaudio ✓
03:51  notitie   oorzaak onduidelijk · morgen verder
─────────────────────────────────────────────────
39 minuten · ~90 gesprekken kwijt · niemand anders
had het kunnen doen, want niemand anders kent de stack

Drie dingen aan dat logboek zijn het even laten bezinken waard. Het kostte negenendertig minuten, en dat is een goede uitkomst, geen slechte. De oorzaak stond aan het eind nog open, wat betekent dat dezelfde nacht volgende week opnieuw kan gebeuren. En de reden dat het negenendertig minuten kostte en geen vier uur, is dat de gepiepte persoon de hele stack in zijn hoofd had, wat óók de reden is dat dit systeem nu één menselijk faalpunt heeft dat graag op vakantie zou gaan.

Dat is de werkelijke ruil bij zelf hosten. Niet geld voor controle, maar geld voor concentratie van kennis. Het werkt prachtig zolang je beste engineer betrokken en beschikbaar is, en het verslechtert precies wanneer dat niet zo is.

Capaciteit is geen server, het zijn drie plafonds

De meest voorkomende verrassing bij zelf hosten is de ontdekking dat voice opschalen betekent dat je drie ongerelateerde dingen opschaalt, en dat degene die je het eerst raakt zelden degene is waarop je had gerekend.

De derde verdient de waarschuwing. De publieke richtlijnen voor de gangbare agent-frameworks zetten één worker op ergens tussen een handvol en een paar dozijn gelijktijdige sessies, afhankelijk van wat er in-process draait, en lokale spraakactiviteitsdetectie is vaak het onderdeel dat het plafond zet. Dat is een brede marge, wat betekent dat jouw echte getal een empirische vraag is die je met een belastingtest moet beantwoorden, op jouw hardware, met jouw pluginset. Niemand kan het je aanreiken.

Het ongemakkelijke is dat het rekenplafond verslechtert in plaats van omslaat. Je krijgt geen alarm dat de capaciteit is overschreden. Je krijgt gesprekken die iets slechter voelen, een agent die door mensen heen begint te praten, en een supportwachtrij die vol loopt voordat je monitoring iets merkt.

Modelverloop is wat het na een jaar breekt

Een zelf gehoste stack die in maand één werkt, faalt meestal in maand twaalf om een reden die niets met infrastructuur te maken heeft. De modellen bewegen. Er komt een nieuw realtime-model met betere latency en andere semantiek. Een transcriptieprovider zet de versie die je vastpinde uit. Een stem waar je je merk op bouwde krijgt een opvolger en de oude gaat in onderhoud.

Op een beheerd platform is dat verloop iemands werk. Zelf gehost is het een doorlopende last op je roadmap: elk kwartaal moet iemand nagaan wat er veranderde, vergelijkingsgesprekken draaien, en besluiten of je meegaat. Sla het een jaar over en je draait een stack die een generatie oud klinkt, wat bellers merken ook als ze niet kunnen benoemen waarom.

Het moeilijke aan zelf hosten is niet het neerzetten. Het is over achttien maanden nog actueel zijn, met dezelfde twee mensen, terwijl je je eigenlijke product bouwt.

Wanneer zelf hosten het juiste antwoord is

Wij bouwen en draaien een platform, dus weeg onze mening dienovereenkomstig, maar dit is een oprecht antwoord en geen retorisch. Zelf hosten is duidelijk juist als minstens twee van deze drie opgaan.

De eerste is volume dat het rekenwerk overweldigend maakt in plaats van marginaal. Zijn de kosten per minuut een afrondingsverschil tegenover twee engineers, dan is dat niet het probleem dat je moet oplossen. Overtreffen ze de volledig belaste kosten van een klein team met een ruime marge, dan is de zaak duidelijk.

De tweede is een harde eis die geen gehoste constructie kan vervullen: een air-gapped netwerk, een toezichthouder die de werklast binnen je eigen perimeter eist, of een dataclassificatie die verwerking door derden verbiedt, ongeacht contract. Dat is een randvoorwaarde en geen voorkeur, en daarmee is de vraag beslecht.

De derde is dat voice jóuw product is en niet een functie daarvan. Zit je onderscheid in het gesprek zelf, dan is het bezitten van de runtime strategisch en zijn de operationele kosten simpelweg de kosten van je kernactiviteit. Is voice één functie binnen een groter product, dan sta je op het punt te gaan werven voor een specialisme dat niet jouw specialisme is.