Il vostro provider dovrebbe aprire il ticket per primo.
Sul nostro desk, molti ticket li apriamo noi, dal nostro stesso monitoraggio, prima che il cliente segnali qualcosa. Ecco il modello operativo dietro a questo: ingegneri con nome e cognome che stanno dentro l'infrastruttura, non una coda che aspetta al suo margine.
In questo articolo 3 sezioni
- Sul nostro desk, molti ticket li apriamo noi, dal nostro stesso monitoraggio e rilevamento di sicurezza, prima che il cliente segnali qualcosa.
- Il modello ha quattro mosse: apriamo noi il ticket, un ingegnere con nome e cognome lo segue da un capo all'altro, integriamo i nostri strumenti nella vostra operatività, e il lavoro più grande corre come progetto, fuori dal ticket.
- Il confine è netto: voi gestite la vostra azienda e la vostra applicazione. Noi gestiamo, e costruiamo, tutto ciò che sta sotto.
- Niente di tutto questo è un livello o un extra. È così che funziona il desk.
Partite dalla notifica che non avete inviato. Un ticket già aperto, già preso in carico, e il primo messaggio sopra è nostro. Se avete conosciuto solo un supporto hosting che aspetta all'altro capo di una coda, quell'esperienza non torna la prima volta che succede.
Molti dei nostri ticket partono così, perché il modello operativo è costruito per muoversi per primo.
Le quattro mosse di un team in prima linea
Apriamo noi il ticket per primi
Il monitoraggio e il rilevamento di sicurezza sono collegati all'azione, quindi il primo messaggio su un ticket è spesso il nostro.
Una persona con nome e cognome lo segue, da un capo all'altro, senza livelli
Gli stessi ingegneri che montano i server nei rack rispondono sul canale. Nessun muro L1, nessun passaggio tra livelli. La relazione è con una persona, non con una coda.
Integriamo i nostri strumenti nella vostra operatività
Il segno più chiaro del modello: abbiamo costruito superfici di controllo self-service per i clienti sopra l'infrastruttura che gestiamo, così il loro personale guida giorno per giorno mentre noi abbiamo in carico l'infrastruttura sottostante. La storia completa di quella costruzione è in abbiamo costruito un VPN Control Center per il team di un'agenzia.
Il lavoro più grande corre come progetto, fuori dal ticket
Quando una collaborazione supera la coda (una migrazione di piattaforma, una riprogettazione) diventa un rilievo, un via libera e un playbook di cutover. È una migrazione è un progetto, non un ticket.
“Giorno per giorno, è come avere un team infrastrutturale in organico a cui capita di possedere anche l'hardware e la rete su cui gira.”
Chi fa cosa
Il confine merita di essere dichiarato con precisione. Nostro è il metallo e tutto ciò che sta sotto l'applicazione: provisioning, migrazioni e i loro cutover, architettura di accesso sicuro, staging e pre-produzione, la pipeline di observability, il SAN e il fabric di rete, la postura di backup e DR, ingegneria delle prestazioni e della sicurezza. Ci prendiamo in carico il livello, non solo il ticket. Loro è l'applicazione e la logica di business: cosa rilasciare e quando, il loro codice, il loro modello dati, la loro decisione di release. Noi assistiamo al deploy. Resta il loro deploy.
| VOI GESTITE | NOI GESTIAMO, E COSTRUIAMO |
|---|---|
| La vostra applicazione e il suo codice | Tutto ciò che sta sotto: compute, SAN, fabric di rete |
| Il vostro modello dati e la logica di business | La piattaforma database, i suoi backup, la sua postura DR |
| La decisione di release: cosa esce, e quando | Il livello di staging, il deploy, il playbook di cutover |
| DOVE SFUMA, DI PROPOSITOL'operatività quotidiana del vostro team | Le superfici di controllo con cui il vostro team opera |
Il confine sfuma in un punto deliberato: costruiamo sempre di più gli strumenti che permettono al vostro team di fare self-service al margine del nostro livello, così le vostre persone operano con sicurezza sopra un'infrastruttura che non devono capire. Non consegniamo un runbook e ce ne andiamo. Consegniamo una superficie di controllo e restiamo.
Chi lo compra così
Dominano le piattaforme di media ed editoria, perché la velocità di rilascio e i picchi di traffico sono esistenziali per loro. Le agenzie digitali che servono i propri clienti finali seguono da vicino, perché non possono permettersi di sembrare piccole davanti a un cliente. Nel mix ci sono anche imprese con più datacenter. L'emozione dell'acquirente cambia, ma la richiesta è la stessa, ogni volta: siate il nostro team di ingegneri, non il nostro help desk.
I tempi di risposta sono pubblicati sulla nostra pagina di supporto. Questo articolo riguarda chi si muove per primo e chi ha in carico il lavoro.
Risposte dirette
Cosa significa davvero monitoraggio proattivo dei server?+
Che il rilevamento è collegato all'azione dal lato del provider. Sul nostro desk, molti ticket li apriamo noi dal monitoraggio e dal rilevamento di sicurezza, prima che il cliente segnali qualcosa.
Ho un ingegnere dedicato con il managed hosting?+
Qui un ingegnere con nome e cognome segue il problema da un capo all'altro, e lo stesso team che monta l'hardware nei rack risponde sul canale. Non c'è un sistema a livelli. Il modello è una persona, non una coda.
Cosa succede quando qualcosa si rompe alle 3 di notte?+
Il monitoraggio è collegato in modo da aprire il ticket, quindi alle 3 di notte il primo messaggio è di solito il nostro. I tempi di risposta sono sulla pagina di supporto; se il vostro carico ha bisogno di un impegno specifico, lo definiamo insieme a voi.
Il mio team può ancora gestire le cose da solo?+
Sì, deliberatamente. Costruiamo superfici di controllo per i clienti sopra l'infrastruttura che gestiamo (gestione utenti, accessi, operatività quotidiana) così il vostro team guida e noi abbiamo in carico l'infrastruttura sottostante.
Qual è la differenza tra managed hosting e avere un team ops?+
Il confine. Voi gestite l'applicazione e il business, noi gestiamo e costruiamo il livello sottostante, e il lavoro più grande corre come progetti di ingegneria invece che come ticket.
Il primo messaggio dovrebbe essere il nostro.
Ingegneri con nome e cognome, senza livelli, che stanno dentro l'infrastruttura su cui gira la vostra azienda.
Parla con un ingegnereSiete arrivati alla fine.
Mettete la lettura al lavoro
Cosa fate girare?
Raccontateci il carico di lavoro, il traffico e i requisiti di ripristino. Partite dal configuratore di server, oppure discutete i dettagli con un ingegnere.
Scritto dagli ingegneri che costruiscono e gestiscono l'infrastruttura che descrive.Parla con un ingegnere