Hanno smesso di chiamarci quando qualcosa si rompe.
I clienti hanno smesso di chiamarci quando qualcosa si rompe e hanno iniziato a chiamarci per costruire quello che viene dopo. Release engineering, ambienti di staging, accesso sicuro e migrazioni gestite come progetti riempiono ormai la coda di ingegneria.
In questo articolo 3 sezioni
- I clienti hanno smesso di chiamarci quando qualcosa si rompe e hanno iniziato a chiamarci per costruire quello che viene dopo.
- Cosa riempie oggi la coda di ingegneria: release engineering, ambienti di staging, accesso sicuro, migrazioni gestite come progetti. Il lavoro per cui si assume un team di ingegneri.
- La maggior parte degli incidenti sul nostro desk li apriamo noi, non il cliente: il monitoraggio arriva per primo.
- Le costruzioni riescono perché lo strato sottostante è nostro: il metal, la SAN, la rete sul nostro AS, e gli ingegneri che la gestiscono.
La forma del nostro support desk è cambiata. La coda che continua a crescere è quella del managed engineering: release engineering, ambienti di staging, accesso sicuro, migrazioni gestite come progetti. La prova di ciò che siamo diventati non è una testimonianza. È il lavoro che i nostri clienti ci portano, e ciò che ci chiedono di essere.
Il break-fix non è sparito. Ha smesso di essere il motivo principale per cui ci chiamano. Un provider che risponde alle 3 di notte si guadagna il diritto di essere interpellato su cosa succederà alle 9 del mattino del giorno del lancio, ed è di questa conversazione che è fatta la coda di ingegneria.
Cosa ci chiedono di costruire oggi
Cosa riempie oggi la coda di ingegneria, in ordine di frequenza:
- 01CI/CD e lavoro di live release: presenza durante deploy e go-live
- 02Ambienti di staging e pre-produzione
- 03Accesso sicuro: site-to-site, gateway per cliente, rollout per il personale remoto
- 04Security hardening
- 05Ingegneria delle prestazioni
- 06Migrazioni gestite come progetti, e l'architettura dietro di esse
Migrazioni, architettura e automazione sembrano piccole nei dati dei ticket per un motivo: le costruzioni più grandi escono del tutto dal sistema di ticket e corrono come progetti, con una rilevazione, un via libera e un playbook di cutover. Gli incarichi di maggior valore non sono mai stati ticket.
La prova di questo vive sotto la linea di galleggiamento, nelle costruzioni che hanno smesso di essere ticket: un centro di controllo self-service che abbiamo costruito dentro il portale di un cliente (ogni modifica VPN passa dalla nostra coda di ticket), la piattaforma di un editore riprogettata e atterrata sul nostro metal (una migrazione è un progetto, non un ticket), e tutto il personale di un'agenzia portato sull'accesso sicuro in un pomeriggio. Nessuno di questi stava in un ticket.
La maggior parte degli incidenti li apriamo noi per primi
Un'altra cosa, perché appartiene allo stesso spostamento. La maggior parte degli incidenti sul nostro desk li apriamo noi: il monitoraggio interviene prima che il cliente se ne accorga. Un desk break-fix aspetta che ve ne accorgiate voi. Leggete di più su come opera il nostro support desk.
Perché comprarlo da un provider di hosting
Rispetto all'assunzione interna: un ingegnere senior di infrastruttura, più una SAN, più una rotazione di reperibilità è un impegno serio e un ciclo di assunzioni prima che qualcuno scriva una riga. Noi siamo il team e il datacenter, disponibili adesso.
Rispetto a un freelance o a un'agenzia: costruiscono su un'infrastruttura gestita da qualcun altro. Quando si rompe alle 3 di notte, aprono un ticket a un provider che non controllano. Noi costruiamo su un'infrastruttura che gestiamo anche noi, quindi la persona che l'ha progettata è la persona che la ripara.
Rispetto al supporto di un hyperscaler: un livello di supporto e una coda, su una fattura che si muove. Qui c'è una persona con nome e cognome, da un capo all'altro, senza livelli, su hardware a costo fisso di nostra proprietà. La differenza non è una funzionalità. È chi risponde al telefono.
In affitto, e a livelli
Il metal di qualcun altro, con risposta da una coda.
Di proprietà, ma a livelli
Il metal è loro. Voi ricevete comunque un livello di supporto e una coda.
Con nome, ma in affitto
Una persona reale che costruisce su un'infrastruttura che non gestisce.
Di proprietà, e con nome
Gli ingegneri che gestiscono il metal sono quelli che rispondono.
Le costruzioni riescono perché lo strato sottostante è nostro: il metal, la SAN, la rete sul nostro AS e BGP, gli ingegneri firmware in organico. La relazione è il prodotto. La piattaforma di proprietà è il motivo per cui funziona, e il motivo per cui nessuno che affitta la propria può copiarlo. Il break-fix non è un passato che ci lasciamo alle spalle. È ciò in cui siamo diventati abbastanza bravi da far sì che i clienti iniziassero a chiederci di più.
“I clienti hanno smesso di chiamarci quando qualcosa si rompe, e hanno iniziato a chiamarci per costruire quello che viene dopo.”
Risposte dirette
Cosa include davvero il fully managed hosting?+
Lo strato sotto l'applicazione è nostro: provisioning, migrazione, accesso sicuro, staging, observability, postura di backup e DR, ingegneria delle prestazioni e della sicurezza, erogati da ingegneri con nome e cognome e sempre più come progetti di costruzione, non solo come risposta agli incidenti. È il lavoro per cui altrimenti assumereste un team di infrastruttura.
Qual è la differenza tra supporto break-fix e managed engineering?+
Il break-fix aspetta un sintomo e chiude un ticket. Il managed engineering progetta, costruisce e resta presente durante il lancio. Sul nostro desk, la coda di ingegneria si è moltiplicata dal 2021, mentre il desk nel suo insieme no.
Un provider di hosting può davvero fare lavoro DevOps e CI/CD?+
La domanda più grande nella nostra coda di ingegneria è esattamente questa: release engineering, supporto ai deploy, ambienti di staging.
Non è più economico assumere un freelance per il lavoro di infrastruttura?+
Il freelance costruisce su un'infrastruttura gestita da qualcun altro, quindi la costruzione e la responsabilità alle 3 di notte si dividono tra due parti. Qui sono lo stesso team, su un'infrastruttura che quello stesso team gestisce.
Portateci quello che viene dopo, non solo quello che si è rotto.
Un ingegnere con nome e cognome, da un capo all'altro, su infrastruttura di nostra proprietà. Se deve essere un progetto invece di un ticket, ve lo diremo.
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
