Amministratori di sistema di tutto il mondo, vi congratuliamo per la vostra festa professionale!
Non ci sono più amministratori di sistema tra di noi (beh, quasi). Tuttavia, la leggenda che parla di loro è ancora viva. In occasione della festività, abbiamo preparato questa epica. Mettetevi comodi, cari lettori.
C'era una volta un mondo Dodo IS in fiamme. In quel periodo oscuro, l'obiettivo principale dei nostri amministratori di sistema era sopravvivere un giorno in più senza piangere.
Tanto tempo fa, i programmatori scrivevano codice poco e lentamente e pubblicavano in produzione solo una volta alla settimana. Così i problemi si presentavano solo una volta ogni sette giorni. Ma poi iniziarono a scrivere più codice e a pubblicarlo più spesso, i problemi iniziarono a crescere, a volte tutto si sgretolava, e il ripristino diventava più difficile. Gli amministratori di sistema soffrivano, ma tolleravano questo caos.
La sera sedevano a casa con ansia nel cuore. E ogni volta accadeva: "non era mai successo, e ora il monitoraggio invia un segnale di aiuto: Ehi, il mondo è in fiamme!". Allora i nostri sysadmin indossavano i loro mantelli rossi, i calzoni sopra i leggings, si arricciavano il ciuffo e volavano a salvare il mondo Dodo.
Attenzione, una piccola precisazione. Non ci sono mai stati negli Dodo IS amministratori di sistema classici che si occupano dell'hardware. Noi abbiamo sempre avuto esperti nel cloud di Azure.
Ma cosa facevano:
- se qualcosa si rompeva, trovavano il modo di ripararlo;
- gestivano i server a un livello esperto;
- si occupavano della rete virtuale in Azure;
- era responsabile di aspetti di basso livello, come le interazioni tra i componenti (*sussurrando* a volte non capivano assolutamente nulla);
- riconnessi dei server;
- e molto altro ancora di incredibile.
La vita del team di ingegneri dell'infrastruttura (così chiamavamo i nostri amministratori di sistema) era fatta di spegnimento incendi e di test che si rompevano in continuazione. Vivevano nel terrore e poi decisero di riflettere: cosa c'è che non va, e se provassimo a fare meglio? Per esempio, perché non dividere le persone in programmatori e amministratori di sistema?
Il compito
Dati: c'è un amministratore di sistema, la cui responsabilità include i server, la rete che lo collega ad altri server, le applicazioni di livello infrastrutturale (il server web che ospita l'applicazione, il sistema di gestione dei database, ecc.). E c'è un programmatore, la cui responsabilità è il codice funzionante.
Ma ci sono cose che si trovano a cavallo. Di chi è la responsabilità?
Di solito, proprio a questo confine si incontravano i nostri amministratori di sistema e programmatori e cominciava:
– Ragazzi, non funziona niente, sarà colpa dell'infrastruttura.
– Ragazzi, no, è colpa del codice.
Un giorno, in quel momento fra loro, cominciò a crescere un muro, oltre il quale si lanciavano felicemente escrementi. I compiti, come escrementi, venivano passati da un lato all'altro del muro. Nessuno, però, si avvicinava alla risoluzione della situazione. Faccia triste.
Un raggio di sole attraversò il cielo nuvoloso, quando alcuni anni fa Google ideò di non scambiarsi più compiti, ma di fare invece un lavoro comune.
E se descrivessimo tutto come codice?
Nel 2016, Google pubblicò un libretto intitolato "Site Reliability Engineering" sulla trasformazione del ruolo dell'amministratore di sistema: da maestro della magia a un approccio ingegneristico formalizzato nell'uso del software e nell'automazione. Hanno attraversato tutte le spine e ostacoli, hanno affinato le loro competenze e hanno deciso di condividerle con il mondo. Il libro è disponibile gratuitamente. .
Nel libro sono contenute verità semplici:
- fare tutto come codice è buono;
- usare un approccio ingegneristico è buono;
- fare un buon monitoraggio è fondamentale;
- non permettere a un servizio di andare in produzione senza un logging e monitoraggio chiari è altrettanto importante.
Queste pratiche sono state condivise dal nostro Gleb (), e si va avanti. Stiamo implementando! Attualmente ci troviamo in una fase di transizione. Il team SRE è stato formato (ci sono 6 specialisti pronti, altri 6 sono in onboarding) e pronti a cambiare in meglio il mondo composto interamente di codice.
Stiamo costruendo la nostra infrastruttura in modo che i programmatori possano gestire autonomamente i propri ambienti e collaborare con SRE.
Fattiamo invece di concludere
L'amministratore di sistema è una professione dignitosa. Ma oltre alle conoscenze sistemiche, sono necessarie anche ottime competenze in software engineering.
I sistemi stanno diventando sempre più semplici e le conoscenze super specializzate nella gestione di server fisici stanno diventando meno richieste ogni anno. Le tecnologie cloud stanno rendendo superflue queste conoscenze.
Un buon sysadmin nel prossimo futuro dovrà possedere buone competenze in software engineering. E sarebbe ancora meglio se avesse delle buone competenze in questo campo.
Nessuno è in grado di prevedere il futuro fino a quando non si presenta, ma riteniamo che nel tempo ci saranno sempre meno aziende disposte ad aumentare indefinitamente il personale degli amministratori di sistema. Anche se, naturalmente, ci saranno sempre appassionati. Oggi in pochi utilizzano le carrozze trainate da cavalli, la maggior parte delle persone guida automobili, anche se ci sono dei fan…
Buona giornata del sysadmin a tutti, a tutto il codice!
Fonte: habr.com
