Amministratori di sistema di tutto il mondo, congratulazioni per la vostra vacanza professionale!
Non ci sono più amministratori di sistema (beh, quasi). Tuttavia, la leggenda su di loro è ancora fresca. In onore della vacanza, abbiamo preparato questa epopea. Mettetevi comodi, cari lettori.
C'era una volta il mondo di Dodo IS in fiamme. Durante quel periodo oscuro, il compito principale dei nostri amministratori di sistema era sopravvivere un giorno in più e non piangere.
Molto tempo fa, i programmatori scrivevano il codice poco e lentamente e lo pubblicavano su prod solo una volta alla settimana. Quindi i problemi si presentavano solo una volta ogni sette giorni. Ma poi hanno iniziato a scrivere più codice e a pubblicarlo più spesso, i problemi hanno cominciato ad aumentare, a volte tutto ha cominciato a cadere a pezzi ed è diventato peggio tornare indietro. Gli amministratori di sistema hanno sofferto, ma hanno tollerato questa farsa.
La sera sedevano a casa con l'ansia nell'anima. E ogni volta che è successo “non è mai successo, e anche qui il monitoraggio manda un segnale di aiuto: amico, il mondo è in fiamme!”. Quindi i nostri amministratori di sistema hanno indossato i loro impermeabili rossi, i pantaloncini sopra i leggings, si sono arricciati la fronte e sono volati per salvare il mondo di Dodo.
Attenzione, una piccola spiegazione. Non ci sono mai stati amministratori di sistema classici che mantenessero l'hardware in Dodo IS. Siamo subito avanzati sui cloud Azure.
Cosa hanno fatto:
- se qualcosa si rompeva, facevano in modo che fosse riparato;
- server destreggiati a livello esperto;
- erano responsabili della rete virtuale in Azure;
- responsabile di cose di basso livello, ad esempio, le interazioni dei componenti (*sussurro* in cui a volte non armeggiano);
- il server si riconnette;
- e molti altri selvaggi.
La vita di un team di ingegneri delle infrastrutture (come chiamavamo i nostri amministratori di sistema) consisteva allora nello spegnere gli incendi e nel rompere costantemente i banchi di prova. Hanno vissuto e sofferto, e poi hanno deciso di pensare: perché è così brutto, o forse possiamo fare di meglio? Ad esempio, non divideremo le persone in programmatori e amministratori di sistema?
problema
data: c'è un amministratore di sistema che ha dei server nella sua area di responsabilità, una rete che lo collega ad altri server, programmi a livello di infrastruttura (un server web che ospita un'applicazione, un sistema di gestione di database, ecc.). E c'è un programmatore la cui area di responsabilità è il codice funzionante.
E ci sono cose che sono al bivio. Di chi è questa responsabilità?
Di solito, i nostri amministratori di sistema e programmatori si incontravano proprio a questo incrocio e iniziava:
“Amici, non funziona niente, probabilmente a causa dell'infrastruttura.
- Amico, no, è nel codice.
Un giorno in questo momento, tra loro cominciò a crescere una recinzione, attraverso la quale lanciarono con gioia la cacca. Il compito, come una cacca, è stato lanciato da un lato all'altro del recinto. Allo stesso tempo, nessuno si è avvicinato alla risoluzione della situazione. Faccina triste.
Un raggio di sole squarciava il cielo coperto quando qualche anno fa in Google venne l'idea di non scambiarsi i compiti, ma di fare invece una cosa comune.
E se descrivessimo tutto come un codice?
Nel 2016, Google ha pubblicato un libro intitolato "Site Reliability Engineering" sulla trasformazione del ruolo di un amministratore di sistema: da un maestro della magia a un approccio ingegneristico formalizzato nell'uso del software e dell'automazione. Loro stessi hanno attraversato tutte le spine e gli ostacoli, ne hanno preso la mano e hanno deciso di condividerlo con il mondo. Il libro è di pubblico dominio .
Il libro contiene semplici verità:
- fare tutto come codice è buono;
- utilizzare un approccio ingegneristico - buono;
- fare un buon monitoraggio è positivo;
- Anche impedire il rilascio di un servizio se non dispone di una registrazione e di un monitoraggio chiari è positivo.
Queste pratiche sono state lette dal nostro Gleb () e si parte. Implementazione! Adesso siamo in una fase transitoria. Il team SRE è formato (ci sono 6 specialisti già pronti, altri 6 sono in fase di onboarding) ed è pronto a cambiare in meglio il mondo, costituito interamente da codice.
Creiamo la nostra infrastruttura in modo tale da consentire agli sviluppatori di gestire i propri ambienti e collaborare con SRE in modo completamente indipendente.
Wang invece di conclusioni
L'amministratore di sistema è una professione degna. Ma la conoscenza della parte di sistema richiede anche ottime capacità di ingegneria del software.
I sistemi stanno diventando sempre più semplici e la conoscenza super unica dell'amministrazione dei server Iron sta diventando sempre meno richiesta ogni anno. Le tecnologie cloud stanno sostituendo la necessità di questa conoscenza.
Un buon amministratore di sistema nel prossimo futuro dovrà possedere buone competenze di ingegneria del software. Ancora meglio, dovrebbe avere buone capacità in questo settore.
Nessuno sa come prevedere il futuro prima che accada, ma crediamo che col tempo ci saranno sempre meno aziende che vorranno aggiungersi allo staff infinitamente gonfio di amministratori di sistema. Anche se, ovviamente, i fan rimarranno. Pochi oggi vanno a cavallo, per lo più usano l'auto, anche se ci sono degli amanti...
Buona giornata dell'amministratore di sistema a tutti, codice a tutti!
Fonte: habr.com