Door Anoniem: Door Anoniem:
Dat is gewoon '<1% gaan we niet optimaliseren' .
Wie zegt dat ze dit niet gedaan hebben?
Niet in de training van de helpdesk
Wie zegt dat de helpdesk geen training heeft gehad?
en niet in de automatisering.
Zie zegt dat er niet geautomatiseerd is?
Je werkt zeker bij een ISP die 't misschien wel voor elkaar heeft en bent nu een beetje op de pik getrapt ?
Informed speculation op basis van de ervaringen van anoniem 30 sep 17:06
Helpdesk 3x uitleggen wat ie uberhaupt wilde want helpdesker had er nooit van gehoord, website om het eigen mac in te geven was toevallig down , en 24 uur vertraging om het eigen mac te activeren.
Die ervaringen kun je echt niet "goed uit-geautomatiseerd" noemen. Als het zo werkte voor de "normale" cases van klant activatie was het gierende paniek .
Past allemaal precies bij een heel weinig gebruikt traject in het bestel/support proces .
Het is wel ongeveer "mogelijk/supported" maar past typisch bij een prio 0 project - website 'net down' doet ook denken aan development VM'tje dat even buiten de operationele monitoring valt (nog) .
dus is er "omdat het moet" een servertje bij elkaar geklutst met een paar scrippies, een cronjob, en waarschijnlijk nog een engineer ertussen die controleert of dat mac echt gezien is achter de aansluiting die opgegeven is voordat dat mac adres echt authorized wordt .
Ik zie weer heel veel aannames. Meestal gaat dit volledig automatisch, en zit er een stukje middelware tussen dat dit allemaal regelt. Teminste, zo zou ik dit bouwen, maar ik zou ook niet een continue reload laten uitvoeren maar dit gestructureerd doen.
Natuurlijk - zonder volledige inside kennis van die specifieke ISP kun je alleen maar speculeren welke oorzaak past bij de gerapporteerde symptomen.
Je hebt wel goed opgepakt dat dit gaat om een installatie waarin je door de eindgebruiker opgegeven data moet gaan configureren in je aansluiting-authenticatie platform (en/of toevoegen in die middleware ) ?
Dat zijn dingen die ik extreem grondig zou checken , gezien het risico op storing voor andere klanten .
Misschien graag automatisch, maar als dat onevenredig veel ontwikkeltijd kost vgl de frequentie van voorkomen (of een live deadline) kom je wel eens uit op een handmatige stap .
Als het zeldzaam genoeg is kan ik de 24 uur vertraging verklaren met een batch en handmatige controle ergens tussen.
Meestal gaat dit volledig automatisch, en zit er een Er zijn altijd dingen die urgenter zijn en waar ontzettend veel meer klanten baat van hebben dan dit soort randgevallen perfect maken.
Ik zie weer dat je eigenlijk niet weet hoe het werkt, en maar weer aannames doet?
Dat zouden mensen die in de IT werken (of dat willen) toch moeten snappen - en dus herkennen als ze aan de klantenkant zitten.
Ik zou denken dat mensen met enige IT kennis nooit aannames doen, en dit soort post doen, als ze enige inhoudelijke kennis hebben.
Als je dit soort werk gedaan hebt kun je vrij goed speculeren over achterliggende redenen op basis van dit soort symptomen.
Zonder precies bij de betreffende provider in de juiste keuken gewerkt te hebben blijft het speculatie . (en weet je het wel precies, valt het meestal onder NDAs , dit soort ietwat vuile was ).