Qlik beheer: grip op reloads, gebruikers, performance en capaciteit
Een dashboard kan er prima uitzien terwijl de reload vannacht is mislukt, een gateway is uitgevallen of de capaciteit langzaam volloopt. Beheer is zorgen dat iemand dat ziet voordat een gebruiker het meldt, en dat de omgeving na iedere wijziging nog klopt.
De beheercyclus: monitoren, signaleren, oplossen en verbeteren, iedere week opnieuw.
Wat wil je onder controle houden?
Kies een onderdeel. Per onderdeel staat wat we controleren, welk risico dat beperkt en welke actie er meestal op volgt.
Wat we controleren: de dagelijkse status van alle reloadtaken: geslaagd of mislukt, duur, afhankelijkheden en de foutmelding.
Welk risico wordt beperkt: gebruikers die sturen op cijfers van gisteren of eergisteren zonder dat te weten.
Welke actie volgt meestal: oorzaak herstellen (bron, script, verbinding of gateway), de reload opnieuw starten, en terugkerende fouten structureel oplossen.
Wat we controleren: wie toegang heeft, tot welke spaces en apps, en of dat nog klopt met de organisatie.
Welk risico wordt beperkt: oud-medewerkers met toegang, of rechten die breder zijn dan bedoeld.
Welke actie volgt meestal: periodieke opschoning, groepen beheren in de identity provider en section access controleren.
Wat we controleren: het verbruik van gebruikerslicenties of capaciteit tegenover het contract, en de trend daarin.
Welk risico wordt beperkt: onverwachte kosten, of gebruikers die niet meer kunnen inloggen omdat het maximum is bereikt.
Welke actie volgt meestal: inactieve gebruikers vrijmaken, apps met onevenredig verbruik opsporen en het contract tijdig bijstellen.
Wat we controleren: laadtijden van apps, duur van reloads, geheugengebruik en trage objecten.
Welk risico wordt beperkt: dashboards die niemand meer opent omdat ze te traag zijn geworden.
Welke actie volgt meestal: datamodel en expressies optimaliseren, reloadketens ontvlechten en incrementeel laden waar het volume dat vraagt.
Wat we controleren: de status van de Data Gateway, de connectors en de credentials die op een dag verlopen.
Welk risico wordt beperkt: alle reloads op lokale bronnen mislukken tegelijk, meestal op een ongelegen moment.
Welke actie volgt meestal: gateway-updates, certificaten en wachtwoorden bijhouden, en een uitwijk afspreken als de gateway uitvalt.
Wat we controleren: welke apps in gebruik zijn, waar ze staan en of er dubbele versies rondgaan.
Welk risico wordt beperkt: wildgroei aan apps waarvan niemand weet welke leidend is.
Welke actie volgt meestal: opruimen, een eigenaar per app, en ontwikkel-, test- en productiespaces gescheiden houden.
Wat we controleren: rollen, section access, gedeelde definities en exportrechten.
Welk risico wordt beperkt: gevoelige data zichtbaar voor de verkeerde groep, of definities die per app afwijken.
Welke actie volgt meestal: het rechtenmodel vastleggen, master items centraal houden en periodiek een controle op rechten.
Wat we controleren: wijzigingen aan apps en scripts, en de releases van Qlik Cloud zelf, die frequent verschijnen.
Welk risico wordt beperkt: een wijziging die de volgende ochtend een dashboard breekt.
Welke actie volgt meestal: testen in een aparte space, een changelog bijhouden en terugdraaien mogelijk maken.
Twee routes
Beheer hoeft geen abonnement te zijn. Wat past, hangt af van hoe kritiek de omgeving is en of er intern iemand is die de opvolging doet.
We hebben incidenteel hulp nodig
Een mislukte reload, een trage app, een gateway die niet meer verbindt of een vraag over rechten. QDTA helpt op afroep, zonder vaste afspraak, en draagt de oplossing over aan wie het intern beheert.
We willen structureel beheer
Vaste monitoring, een afgesproken reactietijd, een vast aanspreekpunt en periodieke controle op licenties, performance en security. Voor organisaties zonder eigen Qlik-beheerder of met een omgeving waar dagelijks op wordt gestuurd.
Beheer begint in beide gevallen met een inventarisatie van de omgeving zoals die nu draait: apps, reloads, gateways, gebruikers en rechten. Daarna is duidelijk wat dagelijks bewaakt moet worden en wat een keer per kwartaal volstaat.
Veelgestelde vragen
Wat valt onder Qlik beheer?
De onderdelen hierboven: reloads, gebruikers en toegang, licenties en capaciteit, performance, gateways, apps en spaces, security en wijzigingen. Wat precies in een afspraak zit, bepalen we per organisatie; de SLA-pakketten geven de gangbare indeling.
Kunnen jullie alleen monitoring doen?
Ja. Monitoring en signalering zonder oplossen is mogelijk, bijvoorbeeld als er intern een beheerder is die de opvolging doet en alleen tijdig gewaarschuwd wil worden.
Werken jullie ook met bestaande omgevingen?
Ja, en dat is de gebruikelijke situatie. Beheer begint met een inventarisatie van de omgeving zoals die nu draait, inclusief wat er in het verleden omheen is gebouwd. Pas daarna worden afspraken gemaakt over wat bewaakt wordt.
Hoe werkt support bij reloadproblemen?
Een mislukte reload wordt gesignaleerd, de oorzaak wordt vastgesteld (bron, verbinding, script of gateway) en hersteld. Binnen een SLA geldt een afgesproken reactietijd; daarbuiten helpt QDTA op afroep.
Wat is het verschil tussen beheer en consultancy?
Consultancy is projectmatig: iets bouwen, migreren of verbeteren. Beheer is doorlopend: zorgen dat wat gebouwd is blijft werken, en signaleren wat aandacht nodig heeft. In de praktijk lopen ze in elkaar over; vandaar de twee routes hierboven. Lees ook: Managed services of zelf beheren?
Wie ziet het bij jullie als de reload mislukt?
In een gesprek lopen we de omgeving door en bepalen we welke onderdelen bewaking nodig hebben, en of incidentele hulp of een SLA daar het beste bij past.