Supporto e manutenzione applicativa gestita
Far funzionare il software già in produzione, nel rispetto del Suo SLA e della Sua coda di ticket: triage, correzioni alla radice, rilasci di patch, aggiornamenti di dipendenze e piattaforme, risposta alla sicurezza e gestione degli incidenti. Secondo e terzo livello, a cura di ingegneri che sviluppano anch’essi, così che un guasto ricorrente venga risolto e non semplicemente riavviato.
Perché è un problema da partner
Il supporto è la parte di un servizio gestito facile da vendere e difficile da coprire con il personale. Arriva in modo irregolare, richiede persone in grado di leggere codice sconosciuto sotto pressione e, nel momento in cui vi assegna i Suoi ingegneri migliori, questi non sono più disponibili per il lavoro che rende di più. La risposta abituale è un livello separato e più economico che chiude ticket senza mai correggere nulla, e il cliente se ne accorge nel giro di un trimestre.
La nostra risposta è che le persone dedicate al supporto sono ingegneri. Possono modificare il sistema, non solo descriverlo, ed è l’unico modo in cui un incidente ricorrente smette davvero di ripetersi.
Di che cosa ci facciamo carico
Triage e diagnosi
Prendere in carico ciò a cui il primo livello non sa rispondere, riprodurlo e dire che cosa non va davvero anziché chiuderlo come non riproducibile.
Correzioni che reggono
Difetti corretti alla radice, con un test di regressione scritto per l’intera classe di bug e non per il singolo ticket, così che lo stesso incidente non torni il trimestre successivo.
Rilasci e patching
Rilasci di patch consegnati attraverso la Sua pipeline secondo il Suo processo di gestione delle modifiche, con dipendenze, versioni dei framework e runtime delle piattaforme tenuti aggiornati anziché lasciarli scivolare in una crisi da aggiornamento.
Risposta alla sicurezza
Un avviso pubblicato su qualcosa da cui dipende è un motivo incondizionato per aggiornare, non una voce del backlog. Lo monitoriamo, applichiamo la patch e Le diciamo quale fosse l’esposizione.
Monitoraggio e incidenti
Controllo degli avvisi già esistenti, aggiunta di quelli che dovrebbero esserci e gestione degli incidenti con una relazione scritta successiva su ciò che è accaduto e su che cosa ne impedisce il ripetersi.
Piccole modifiche
Il flusso costante di piccoli miglioramenti che mantiene soddisfatto un cliente e non giustifica mai un progetto: gestito nella stessa capacità, alle stesse condizioni.
Il Suo SLA, valutato con onestà
Non pubblichiamo obiettivi di tempi di risposta e di risoluzione, perché un numero inventato prima che qualcuno abbia visto il Suo sistema non vale nulla né per Lei né per il Suo cliente. Leggiamo invece lo SLA che Lei già deve rispettare, Le diciamo quali parti possiamo davvero sostenere e quale copertura richiede, e poi ci impegniamo per iscritto.
Lo stesso vale per la copertura fuori orario. Dove un incarico lo richiede e lo abbiamo concordato in anticipo, è coperta da persone selezionate o assegnate per quegli orari, e non svegliando qualcuno nella speranza che risponda. Lavoriamo già con orari europei, australiani e del Pacifico statunitense in altri incarichi, quindi la questione è quale fascia Le serva, non se sia possibile.
Prendere in carico un sistema che non abbiamo costruito
Che è il caso normale. Finora nove prese in carico, la più vecchia scritta nel 2008.
Prima una revisione in sola lettura
Otteniamo l’accesso al codice, all’infrastruttura e allo storico dei ticket prima di essere responsabili di qualunque parte, e osserviamo anziché modificare.
Un elenco scritto dei rischi
Che cosa è fragile, che cosa non è aggiornato con le patch, che cosa non è documentato e che cosa sveglierà qualcuno di notte, in ordine di impatto sulla produzione. Resta Suo, che proseguiamo o no.
Il confronto sulla copertura
Leggiamo lo SLA che Lei deve al Suo cliente e Le diciamo con onestà quali parti possiamo sostenere, quali orari richiede e quanto costa, prima che una delle parti firmi qualsiasi cosa.
Passaggio di consegne, poi operatività
Un periodo definito di affiancamento a chi oggi possiede la conoscenza, poi prendiamo in carico la coda. Se nessuno la possiede più, si parte invece dalla revisione dei rischi.
Con il Suo nome, se questo è l’accordo
Il supporto è di solito la parte più visibile di un servizio gestito, quindi è anche il punto in cui il white-label conta di più. I nostri ingegneri possono lavorare da caselle di posta e account che Lei rilascia, rispondere nel Suo sistema di ticketing e scrivere report sugli incidenti che Lei inoltra senza modifiche; il Suo cliente tratta con Lei dall’inizio alla fine. Lo sviluppo white-label spiega come viene organizzato, e si applica al supporto esattamente allo stesso modo.
Come viene stabilito il prezzo del supporto
Per persona, a mese, così che il Suo costo sia prevedibile e Lei possa fissare il prezzo di un contratto di supporto al cliente in base ad esso. Tutti registrano le ore nel nostro portale, Lei vede le ore durante tutto il mese e gli stessi dati generano la fattura, quindi esiste un’unica registrazione con cui entrambe le parti si riconciliano.
Dove il supporto affianca nuovo sviluppo, i due sono di solito un unico delivery pod anziché due contratti, così che le settimane tranquille di una parte compensino quelle intense dell’altra.
Domande sugli accordi di supporto
Che cosa comprende il supporto applicativo gestito?
Mantenere in funzione il software già in produzione: smistare ciò che arriva in coda, riprodurre e correggere i difetti, rispondere alle domande tecniche a cui il primo livello non sa rispondere, rilasciare patch, tenere aggiornate dipendenze e versioni delle piattaforme, sorvegliare gli alert e gestire gli incidenti quando qualcosa si rompe. È un lavoro di secondo e terzo livello: il Suo primo livello resta dov’è.
Lavorate secondo il nostro SLA?
Sì. Non pubblichiamo obiettivi di risposta e risoluzione, perché un numero inventato prima di conoscere il Suo sistema non vale nulla. Leggiamo lo SLA che Lei già deve al Suo cliente, Le diciamo con onestà quali parti possiamo sostenere e quale copertura servirebbe, e poi ci impegniamo per iscritto su quello.
Potete fornire una copertura fuori orario o in reperibilità?
Sì. La copertura fuori orario e in reperibilità viene concordata in anticipo, scritta nei termini del supporto e assicurata da persone il cui orario di lavoro le corrisponde: un incidente notturno raggiunge così qualcuno in turno, non qualcuno svegliato di soprassalto.
Potete supportare un sistema che non avete sviluppato voi?
È il caso normale. Finora abbiamo preso in carico nove sistemi, il più vecchio scritto nel 2008. Il supporto di un sistema ereditato parte da una revisione in sola lettura e da un elenco scritto dei rischi ordinati per impatto sulla produzione, così le prime settimane servono a capire di che cosa Lei è effettivamente responsabile, anziché tirare a indovinare sotto pressione.
Le persone che supportano il sistema lo modificheranno anche?
Sì, ed è proprio questo il punto. Gli ingegneri del supporto sono ingegneri, non un livello separato che chiude ticket, quindi un incidente ricorrente può essere risolto alla causa anziché riavviato ogni lunedì. Se con noi ha sia un flusso di sviluppo sia uno di supporto, i due condividono code review e decisioni architetturali.
Come viene prezzato il supporto?
Per persona, su base mensile, così il Suo costo è prevedibile e può prezzare un contratto di supporto al Suo cliente di conseguenza. Le ore sono registrate nel nostro portale e visibili a Lei per tutto il mese, e le stesse cifre generano la fattura: c’è quindi un’unica fonte per entrambe le parti.
Ha sistemi da mantenere in funzione?
Ci indichi quali sono i sistemi, che cosa promette il Suo SLA e dove oggi il supporto fa più male. Lo leggeremo e Le diremo quali parti possiamo sostenere, comprese quelle che non possiamo.