Beheer & opschaling

Digitale oplossingen beheren en doorontwikkelen: OTOKO® ondersteunt bij onderhoud, technisch beheer en het opschalen van uw systemen.

Beveiligingsupdates, nieuwe eisen en incidenten eindigen niet bij de acceptatie.

Overname met code-analyse, afhankelijkheidsinventaris, documentatie en kennisoverdracht Monitoring met Prometheus, Grafana en OpenTelemetry, alarmering op basis van ernst Incident- en probleembeheer volgens ITIL via Jira Service Management Beveiligingsupdates en afhankelijkheidsbeheer met Renovate, controle op bekende kwetsbaarheden Periodieke rapportages over beschikbaarheid, incidenten en openstaande risico's

Servicecatalogus met reactieroutes en verantwoordelijkheden Monitoring met alarmering en dashboards Beheerrapportages met incidenten en risico's

Repository, licenties en technische toegangen Documentatie, bekende incidenten en huidige dienstverleners Verwachte servicetijden en bedrijfskriticiteit

Een intern ontwikkelde vakapplicatie moet worden overgedragen aan een extern team. Na code-analyse en een reproduceerbare build worden eerst monitoring en herstel gecontroleerd. Vervolgens start het onderhoud met afgesproken servicetijden en een lijst met geprioriteerde legacyproblemen.

Jira Service Management Grafana Prometheus OpenTelemetry Renovate

Voordat wij verantwoordelijkheid overnemen, controleren wij codetoegang, gebruiksrechten, afhankelijkheden en de mogelijkheid om een versie zelf te bouwen. Samen brengen wij bekende problemen, operationele kennis en kritieke processen in kaart. Een geslaagde start van de applicatie is niet voldoende: ook back-up, herstel en de verantwoordelijkheid voor externe diensten moeten geregeld zijn. Uit de overname ontstaat een serviceomvang met openstaande risico's en geprioriteerde maatregelen. Onbeheersbare legacyproblemen worden niet stilzwijgend opgenomen in een algemene toezegging. Als eerst stabilisatie nodig is, wordt die als apart werkpakket beschreven.

Een draaiende server zegt weinig over de vraag of gebruikers hun werk kunnen doen. Wij richten de bewaking daarom ook op belangrijke applicatieprocessen en interfaces. Meldingen worden ingedeeld naar impact; voor elk alarm zijn een ontvanger en een zinvolle eerste actie nodig. Supporttijden, reactiedoelen en escalatieroutes worden in het contract vastgelegd. Een reactietijd staat niet gelijk aan een gegarandeerde oplostijd. Bij ernstige incidenten maken wij afspraken over communicatie, beslissingsbevoegdheden en de samenwerking met uw infrastructuur- of softwareaanbieder.

Updates worden beoordeeld op risico, urgentie en compatibiliteit. Wij houden afhankelijkheden zichtbaar, testen wijzigingen in een geschikte omgeving en plannen de oplevering met een terugvaloptie. Terugkerende incidenten worden onderzocht op oorzaken, zodat het beheer niet blijvend uit dezelfde reparaties bestaat. Periodieke rapportages verbinden incidenten, technische risico's en aanstaande beslissingen. Kleine verbeteringen kunnen binnen het afgesproken kader meelopen; grotere functionele uitbreidingen worden apart geprioriteerd. Met het oog op een latere overdracht aan uw team documenteren wij kennis en toegangen doorlopend.

Een applicatie kan bereikbaar zijn en toch geen bestellingen verwerken. Wij kiezen daarom meetpunten voor relevante gebruikersprocessen en onderscheiden bereikbaarheid, succesvolle verwerking en responstijd. Een servicedoel vereist een meetperiode, een gegevensbron en regels voor de omgang met ontbrekende metingen. Pas dan kan controleerbaar worden beoordeeld of de afgesproken toestand is bereikt. De resterende afwijking van het doel kan worden gebruikt als foutbudget om stabilisatie en doorontwikkeling tegen elkaar af te wegen. Welke gevolgen een overschrijding heeft, wordt gezamenlijk vastgesteld. Dat vervangt geen contractuele serviceovereenkomsten en evenmin de beoordeling van een afzonderlijk ernstig incident. Dashboards en alarmering moeten beslissingen ondersteunen: wie reageert, welke diagnose volgt en wanneer moeten functioneel verantwoordelijken worden geïnformeerd?

Een succesvol afgeronde back-up bewijst nog geen herstelbaarheid. Wij bepalen welk gegevensverlies hoogstens acceptabel zou zijn en hoe lang een uitval mag duren. Daaruit volgen eisen voor back-upintervallen, bewaartermijn en herstart. Bij de applicatie horen naast de database vaak bestanden, configuratie, sleutels en externe diensten; ontbreekt een onderdeel, dan kan een technisch leesbare back-up toch onbruikbaar zijn. Hersteloefeningen testen de afgesproken procedure in een geschikte omgeving. Daarbij worden duur, benodigde toegangen, handmatige stappen en inhoudelijke gegevenscontroles gedocumenteerd. Een enkele tenant of een per ongeluk verwijderd record kan andere hersteltrajecten vereisen dan een volledige uitval. De resultaten leiden tot concrete verbeteringen. Geconstateerde lacunes worden benoemd, in plaats van een ongeteste streefwaarde als gegarandeerde capaciteit te presenteren.

Een melding over een kwetsbare bibliotheek wordt beoordeeld in de context van de applicatie: welke versie is opgenomen, is de betrokken functie bereikbaar en welke beschermingsmaatregelen bestaan er? Urgentie en technisch wijzigingsrisico worden samen bekeken. Voor updates die niet direct mogelijk zijn, zijn gedocumenteerde tussenmaatregelen en een datum voor herbeoordeling nodig. Nieuwe versies doorlopen de passende tests en een afgestemde uitrol. Na terugkerende of ernstige incidenten onderzoeken wij oorzaak, detectie en reactie. Daaruit ontstaan geprioriteerde maatregelen met verantwoordelijken, niet alleen een afgesloten ticket. Documentatie, runbooks en toegangsoverzichten worden doorlopend bijgehouden. Ook de latere overdracht aan uw team of een andere dienstverlener wordt voorbereid: met repository, buildinstructies, openstaande risico's en een gestructureerde toegangsoverdracht. Een service is op lange termijn houdbaar wanneer kennis inzichtelijk blijft.

Applicatielandschap, eisen, risico's Vakafdeling, IT, informatiebeveiliging, softwarearchitect van OTOKO® Beoordeelde projecten, inventarisatie, beveiligings- en beheereisen

Architectuur, technologie, beheermodel Vakafdeling, architectuur, gegevensbescherming, informatiebeveiliging Doelarchitectuur, dreigingsmodel, teststrategie, beheermodel, mijlpalen