Gestione e scalabilità

Gestire e far evolvere le soluzioni digitali: OTOKO® vi supporta nella manutenzione, nella gestione tecnica e nella scalabilità dei vostri sistemi.

Gli aggiornamenti di sicurezza, i nuovi requisiti e i malfunzionamenti non finiscono con il collaudo.

Presa in carico con analisi del codice, inventario delle dipendenze, documentazione e trasferimento di conoscenze Monitoraggio con Prometheus, Grafana e OpenTelemetry, allarmi in base alla gravità Gestione degli incidenti e dei problemi secondo ITIL con Jira Service Management Aggiornamenti di sicurezza e gestione delle dipendenze con Renovate, verifica rispetto alle vulnerabilità note Rapporti periodici su disponibilità, incidenti e rischi aperti

Catalogo dei servizi con procedure di risposta e responsabilità Monitoraggio con allarmi e dashboard Rapporti operativi con incidenti e rischi

Repository, licenze e accessi tecnici Documentazione, incidenti noti e fornitori di servizi attuali Orari di servizio previsti e criticità per il business

Un'applicazione specialistica sviluppata internamente deve essere trasferita a un team esterno. Dopo l'analisi del codice e un build riproducibile, vengono verificati innanzitutto il monitoraggio e il ripristino. In seguito inizia la manutenzione con orari di servizio concordati e un elenco di criticità pregresse in ordine di priorità.

Jira Service Management Grafana Prometheus OpenTelemetry Renovate

Prima di assumere la responsabilità, verifichiamo l'accesso al codice, i diritti di utilizzo, le dipendenze e la possibilità di compilare autonomamente una versione. Insieme raccogliamo i problemi noti, le conoscenze operative e i processi critici. Un avvio riuscito dell'applicazione non basta: devono essere chiariti anche il backup, il ripristino e la responsabilità per i servizi esterni. Dalla presa in carico risulta un ambito di servizio, con i rischi aperti e le misure in ordine di priorità. Le criticità pregresse non gestibili non vengono incluse tacitamente in un impegno generico. Se prima è necessaria una stabilizzazione, questa viene descritta come un pacchetto di lavoro separato.

Un server in funzione dice poco sulla possibilità per gli utenti di svolgere il proprio lavoro. Per questo orientiamo il monitoraggio anche sui processi applicativi e sulle interfacce importanti. Le segnalazioni vengono classificate in base all'impatto; ogni allarme richiede un destinatario e una prima azione sensata. Gli orari di supporto, gli obiettivi sui tempi di risposta e i percorsi di escalation vengono definiti nel contratto. Un tempo di risposta non equivale a un tempo di risoluzione garantito. Per gli incidenti gravi chiariamo comunicazione, poteri decisionali e collaborazione con il vostro fornitore di infrastruttura o di software.

Gli aggiornamenti vengono valutati in base a rischio, urgenza e compatibilità. Manteniamo visibili le dipendenze, verifichiamo le modifiche in un ambiente adeguato e pianifichiamo la distribuzione con un percorso di rollback. I malfunzionamenti ricorrenti vengono analizzati per individuarne le cause, affinché la gestione operativa non si riduca in modo permanente alle stesse riparazioni. I rapporti periodici collegano incidenti, rischi tecnici e decisioni in sospeso. I piccoli miglioramenti possono essere realizzati in parallelo nell'ambito concordato; le estensioni funzionali più ampie vengono messe in ordine di priorità separatamente. In vista di un'eventuale riconsegna al vostro team, documentiamo in modo continuativo conoscenze e accessi.

Un'applicazione può essere raggiungibile e tuttavia non elaborare ordini. Scegliamo quindi punti di misurazione per i processi utente rilevanti e distinguiamo raggiungibilità, elaborazione riuscita e tempo di risposta. Un obiettivo di servizio richiede un periodo di misurazione, una fonte dei dati e regole per la gestione delle misurazioni mancanti. Solo così è possibile valutare in modo verificabile se lo stato concordato è stato raggiunto. Lo scostamento residuo dall'obiettivo può essere utilizzato come budget di errore per bilanciare stabilizzazione ed evoluzione. Le conseguenze di un superamento vengono definite insieme. Questo non sostituisce né gli accordi di servizio contrattuali né la valutazione di un singolo incidente grave. Dashboard e allarmi devono supportare le decisioni: chi reagisce, quale diagnosi segue e quando devono essere informati i responsabili di business?

Un backup completato con successo non dimostra ancora che i dati siano ripristinabili. Chiariamo quale perdita di dati sarebbe al massimo accettabile e quanto può durare un'interruzione. Ne derivano requisiti per la frequenza dei backup, la conservazione e il ripristino. Oltre al database, dell'applicazione fanno spesso parte anche file, configurazione, chiavi e servizi esterni; se manca una parte, anche un backup tecnicamente leggibile può risultare inutilizzabile. Le esercitazioni di ripristino verificano la procedura concordata in un ambiente adeguato. Vengono documentati durata, accessi necessari, passaggi manuali e controlli funzionali sui dati. Un singolo tenant o un record cancellato per errore possono richiedere percorsi di ripristino diversi da quelli di un'interruzione completa. I risultati confluiscono in miglioramenti concreti. Le lacune rilevate vengono dichiarate, invece di presentare come capacità garantita un valore obiettivo non verificato.

Una segnalazione relativa a una libreria vulnerabile viene valutata nel contesto dell'applicazione: quale versione è integrata, se la funzione interessata è raggiungibile e quali misure di protezione sono presenti? Urgenza e rischio tecnico della modifica vengono considerati insieme. Per gli aggiornamenti non immediatamente possibili servono misure intermedie documentate e una data per una nuova valutazione. Le nuove versioni vengono sottoposte ai test adeguati e a un rollout concordato. Dopo malfunzionamenti ricorrenti o gravi analizziamo causa, rilevamento e reazione. Ne derivano misure in ordine di priorità con responsabili definiti, non soltanto un ticket chiuso. Documentazione, runbook e panoramiche degli accessi vengono aggiornati in modo continuativo. Prepariamo anche il successivo passaggio di consegne al vostro team o a un altro fornitore di servizi: con repository, istruzioni di build, rischi aperti e trasferimento ordinato degli accessi. Un servizio è sostenibile nel lungo periodo se le conoscenze restano comprensibili.

Panorama applicativo, requisiti, rischi Area di business, IT, sicurezza delle informazioni, architetto software OTOKO® Iniziative valutate, analisi dello stato attuale, requisiti di sicurezza e di esercizio

Architettura, tecnologia, modello operativo Area di business, architettura, protezione dei dati, sicurezza delle informazioni Architettura target, modello delle minacce, strategia di test, modello operativo, milestone