Il direttore delle operazioni del portale Banki.ru, Andrey Nikolsky, è intervenuto alla conferenza dello scorso anno sui servizi orfani: come identificare un orfano nell'infrastruttura, perché i servizi orfani sono pessimi, cosa farne e cosa fare se nulla aiuta.
Sotto il taglio c'è una versione testuale del rapporto.
Ciao colleghi! Mi chiamo Andrey, dirigo le operazioni presso Banki.ru.
Abbiamo servizi di grandi dimensioni, sono servizi così monolitici, ci sono servizi in senso più classico e ce ne sono di molto piccoli. Nella mia terminologia operaia-contadina, dico che se un servizio è semplice e piccolo, allora è micro, e se non è molto semplice e piccolo, allora è solo un servizio.
Pro dei servizi
Esaminerò rapidamente i vantaggi dei servizi.
Il primo è il ridimensionamento. Puoi fare rapidamente qualcosa sul servizio e avviare la produzione. Hai ricevuto traffico, hai clonato il servizio. Hai più traffico, lo hai clonato e convivi con esso. Questo è un buon bonus e, in linea di principio, quando abbiamo iniziato, era considerata la cosa più importante per noi il motivo per cui stiamo facendo tutto questo.
In secondo luogo, lo sviluppo isolato, quando si hanno diversi team di sviluppo, diversi sviluppatori diversi in ciascun team e ogni team sviluppa il proprio servizio.
Con le squadre c'è una sfumatura. Gli sviluppatori sono diversi. E ci sono, ad esempio, . L'ho visto per la prima volta con Maxim Dorofeev. A volte i fiocchi di neve fanno parte di alcune squadre e non di altre. Ciò rende i diversi servizi utilizzati all’interno dell’azienda un po’ disomogenei.
Guarda la foto: questo è un buon sviluppatore, ha le mani grandi, può fare molto. Il problema principale è da dove provengono queste mani.
I servizi consentono di utilizzare diversi linguaggi di programmazione più adatti a compiti diversi. Alcuni servizi sono in Go, altri in Erlang, altri in Ruby, qualcosa in PHP, qualcosa in Python. In generale, puoi espanderti molto ampiamente. Anche qui ci sono delle sfumature.
L'architettura orientata ai servizi riguarda principalmente i devops. Cioè, se non disponi di automazione, non esiste un processo di distribuzione, se lo configuri manualmente, le tue configurazioni possono cambiare da un'istanza del servizio all'istanza e devi andare lì per fare qualcosa, quindi sei all'inferno.
Ad esempio, hai 20 servizi e devi distribuirli manualmente, hai 20 console e premi contemporaneamente "Invio" come un ninja. Non è molto buono.
Se hai un servizio dopo il test (se c'è un test, ovviamente) e devi ancora completarlo con un file in modo che funzioni in produzione, ho anche brutte notizie per te.
Se ti affidi a specifici servizi Amazon e lavori in Russia, due mesi fa hai anche avuto "Tutto intorno è in fiamme, sto bene, va tutto bene".
Utilizziamo Ansible per automatizzare la distribuzione, Puppet per la convergenza, Bamboo per automatizzare la distribuzione e Confluence per descrivere in qualche modo il tutto.
Non mi soffermerò su questo in dettaglio, perché il rapporto riguarda più le pratiche di interazione e non l'implementazione tecnica.
Ad esempio, abbiamo riscontrato problemi in cui Puppet sul server funziona con Ruby 2, ma alcune applicazioni sono scritte per Ruby 1.8 e non funzionano insieme. Qualcosa va storto lì. E quando devi eseguire più versioni di Ruby su una macchina, di solito inizi ad avere problemi.
Ad esempio, diamo a ogni sviluppatore una piattaforma su cui c'è più o meno tutto ciò che abbiamo, tutti i servizi che possono essere sviluppati, in modo che abbia un ambiente isolato, possa romperlo e costruirlo come vuole.
Succede che hai bisogno di un pacchetto appositamente compilato con il supporto per qualcosa lì. È piuttosto difficile. Ho ascoltato un rapporto in cui l'immagine Docker pesa 45 GB. In Linux, ovviamente, è più semplice, lì tutto è più piccolo, ma comunque non ci sarà abbastanza spazio.
Bene, ci sono dipendenze contrastanti, quando una parte del progetto dipende da una libreria di una versione, un'altra parte del progetto dipende da un'altra versione e le librerie non sono affatto installate insieme.
Abbiamo siti e servizi in PHP 5.6, ce ne vergogniamo, ma cosa possiamo fare? Questo è il nostro unico sito. Ci sono siti e servizi su PHP 7, ce ne sono di più, non ce ne vergogniamo. E ogni sviluppatore ha la propria base dove sega felicemente.
Se scrivi in un'azienda in una lingua, tre macchine virtuali per sviluppatore sembrano normali. Se hai linguaggi di programmazione diversi, la situazione peggiora.
Hai siti e servizi su questo, su questo, poi un altro sito per Go, un sito per Ruby e alcuni altri Redis sul lato. Di conseguenza, tutto ciò si trasforma in un ampio campo di supporto e in ogni momento una parte di esso può rompersi.
Pertanto, abbiamo sostituito i vantaggi del linguaggio di programmazione con l’uso di framework diversi, poiché i framework PHP sono abbastanza diversi, hanno capacità diverse, comunità diverse e supporto diverso. E puoi scrivere un servizio in modo da avere già qualcosa di pronto per questo.
Ogni servizio ha la propria squadra
Il nostro vantaggio principale, consolidato da diversi anni, è che ogni servizio ha il proprio team. Questo è conveniente per un progetto di grandi dimensioni, puoi risparmiare tempo sulla documentazione, i manager conoscono bene il loro progetto.
Puoi inviare facilmente le attività dal supporto. Ad esempio, il servizio assicurativo è fallito. E subito la squadra che si occupa delle assicurazioni va a sistemare la cosa.
Nuove funzionalità vengono create rapidamente, perché quando hai un servizio atomico, puoi rapidamente inserirvi qualcosa.
E quando interrompi il tuo servizio, e questo inevitabilmente accade, non hai influenzato i servizi di altre persone, e gli sviluppatori di altri team non vengono correndo da te con dei pezzi e dicono: "Sì, non farlo".
Come sempre, ci sono sfumature. Abbiamo squadre stabili, i dirigenti sono inchiodati alla squadra. Ci sono documenti chiari, i manager monitorano tutto da vicino. Ogni squadra con un manager ha diversi servizi e c'è un punto specifico di competenza.
Se le squadre fluttuano (anche noi a volte lo usiamo), esiste un buon metodo chiamato “mappa stellare”.
Hai un elenco di servizi e persone. Un asterisco significa che la persona è esperta in questo servizio, un libro significa che la persona sta studiando questo servizio. Il compito della persona è cambiare il libretto con un asterisco. E se non viene scritto nulla davanti al servizio, iniziano i problemi, di cui parlerò ulteriormente.
Come appaiono i servizi orfani?
Il primo problema, il primo modo per ottenere un servizio orfano nella propria infrastruttura è licenziare le persone. Qualcuno ha mai avuto un'azienda che rispettava le scadenze prima che le attività venissero valutate? A volte capita che le scadenze siano strette e semplicemente non c'è abbastanza tempo per la documentazione. “Dobbiamo affidare il servizio alla produzione, poi lo aggiungeremo”.
Se il team è piccolo, succede che c'è uno sviluppatore che scrive tutto, gli altri sono dietro le quinte. "Ho scritto l'architettura di base, aggiungiamo le interfacce." Poi ad un certo punto il manager, ad esempio, se ne va. E durante questo periodo, quando il manager se n'è andato e non ne è stato ancora nominato uno nuovo, gli sviluppatori stessi decidono dove sta andando il servizio e cosa sta succedendo lì. E come sappiamo (torniamo indietro di qualche diapositiva), in alcune squadre ci sono persone snowflake, a volte un capo squadra snowflake. Poi se ne va e otteniamo un servizio orfano.
Allo stesso tempo, i compiti di supporto e quelli aziendali non scompaiono, ma finiscono nell’arretrato. Se durante lo sviluppo del servizio si sono verificati errori architetturali, anche questi finiscono nel backlog. Il servizio sta lentamente peggiorando.
Come identificare un orfano?
Questo elenco descrive bene la situazione. Chi ha imparato qualcosa sulla loro infrastruttura?
A proposito di soluzioni documentate: c'è un servizio e, in generale, funziona, ha un manuale di due pagine su come lavorarci, ma nessuno sa come funziona all'interno.
Oppure, ad esempio, esiste una sorta di accorciatore di collegamenti. Ad esempio, attualmente disponiamo di tre abbreviatori di link in uso per scopi diversi in servizi diversi. Queste sono solo le conseguenze.
Ora sarò il capitano dell’ovvio. Cosa dovrebbe essere fatto? Per prima cosa dobbiamo trasferire il servizio a un altro manager, a un’altra squadra. Se il leader della tua squadra non si è ancora dimesso, allora in quest'altra squadra, quando capisci che il servizio è come un orfano, devi includere qualcuno che ne capisca almeno qualcosa.
La cosa principale: devi avere le procedure di trasferimento scritte con il sangue. Nel nostro caso, di solito lo monitoro, perché ho bisogno che tutto funzioni. I manager hanno bisogno che venga consegnato rapidamente e ciò che accadrà in seguito non è più così importante per loro.
Il prossimo modo per rendere un orfano è “Lo faremo in outsourcing, sarà più veloce e poi lo consegneremo al team”. È chiaro che tutti hanno dei piani nella squadra, una svolta. Spesso un cliente aziendale pensa che l'outsourcer farà la stessa cosa dell'ufficio tecnico dell'azienda. Sebbene le loro motivazioni siano diverse. Ci sono strane soluzioni tecnologiche e strane soluzioni algoritmiche nell’outsourcing.
Ad esempio, abbiamo realizzato un servizio in cui la Sfinge si trovava in vari luoghi inaspettati. Ti dirò più tardi cosa dovevo fare.
Gli outsourcer hanno framework autoprodotti. Questo è solo PHP semplice con copia-incolla da un progetto precedente, dove puoi trovare ogni genere di cose. Gli script di distribuzione rappresentano un grosso svantaggio quando è necessario utilizzare alcuni script Bash complessi per modificare diverse righe in alcuni file e questi script di distribuzione vengono chiamati da un terzo script. Di conseguenza, cambi il sistema di distribuzione, scegli qualcos'altro, salti, ma il tuo servizio non funziona. Perché lì era necessario inserire altri 8 collegamenti tra cartelle diverse. Oppure succede che mille dischi funzionano, ma centomila non funzionano più.
Continuerò a essere capitano. Accettare un servizio in outsourcing è una procedura obbligatoria. A qualcuno è mai capitato che un servizio in outsourcing arrivasse e non venisse accettato da nessuna parte? Questo non è così popolare, ovviamente, come un servizio orfano, ma comunque.
Il servizio deve essere controllato, il servizio deve essere rivisto, le password devono essere cambiate. Abbiamo avuto un caso in cui ci hanno fornito un servizio, c'è un pannello di amministrazione "if login == 'admin' && password == 'admin'...", è scritto direttamente nel codice. Ci sediamo e pensiamo, e la gente lo scrive nel 2018?
Anche testare la capacità di archiviazione è una cosa necessaria. Devi vedere cosa accadrà su centomila record, anche prima di mettere in produzione questo servizio da qualche parte.
Non dovrebbe esserci vergogna nell'inviare un servizio per migliorarlo. Quando dici: "Non accetteremo questo servizio, abbiamo 20 compiti, eseguili, poi accetteremo", questo è normale. La tua coscienza non dovrebbe essere ferita dal fatto che stai creando un manager o che l'azienda sta sprecando denaro. L’azienda spenderà quindi di più.
Abbiamo avuto un caso in cui abbiamo deciso di esternalizzare un progetto pilota.
È stato consegnato in tempo e questo era l'unico criterio di qualità. Ecco perché abbiamo realizzato un altro progetto pilota, che in realtà non era nemmeno più un pilota. Questi servizi sono stati accettati e, attraverso mezzi amministrativi, hanno detto: ecco il tuo codice, ecco la squadra, ecco il tuo manager. I servizi in realtà hanno già iniziato a realizzare profitti. Allo stesso tempo, infatti, sono ancora orfani, nessuno capisce come lavorano, e i manager fanno di tutto per rinnegare i loro compiti.
C'è un altro grande concetto: lo sviluppo della guerriglia. Quando qualche reparto, solitamente il reparto marketing, vuole testare un'ipotesi e ordina l'intero servizio in outsourcing. Il traffico inizia ad affluire, chiudono i documenti, firmano i documenti con l'appaltatore, entrano in funzione e dicono: "Ragazzi, abbiamo un servizio qui, ha già traffico, ci porta soldi, accettiamolo". Eravamo tipo "Oppa, come può essere?"
E un altro modo per ottenere un servizio orfano: quando una squadra si ritrova improvvisamente carica, la direzione dice: "Trasferiamo il servizio di questa squadra a un'altra squadra, ha un carico minore". E poi lo trasferiremo a una terza squadra e cambieremo allenatore. E alla fine abbiamo di nuovo un orfano.
Qual è il problema con gli orfani?
Chi non lo sa, questa è la corazzata Wasa costruita in Svezia, famosa per il fatto che affondò 5 minuti dopo il varo. E il re di Svezia, a proposito, non ha giustiziato nessuno per questo. È stato costruito da due generazioni di ingegneri che non sapevano come costruire tali navi. Effetto naturale.
La nave, tra l'altro, avrebbe potuto affondare in modo molto peggiore, ad esempio, quando il re vi stava già viaggiando da qualche parte durante una tempesta. E così è annegato subito, secondo Agile è bene fallire presto.
Se falliamo presto, di solito non ci sono problemi. Ad esempio, durante l'accettazione è stato inviato per la revisione. Ma se falliamo già nella produzione, quando vengono investiti i soldi, allora potrebbero esserci dei problemi. Conseguenze, come vengono chiamate negli affari.
Perché i servizi orfani sono pericolosi:
- Il servizio potrebbe interrompersi improvvisamente.
- Il servizio richiede molto tempo per essere riparato o non viene riparato affatto.
- Problemi di sicurezza.
- Problemi con miglioramenti e aggiornamenti.
- Se un servizio importante si interrompe, la reputazione dell'azienda ne risente.
Cosa fare con i servizi orfani?
Ripeto cosa fare di nuovo. Innanzitutto ci deve essere la documentazione. 7 anni presso Banki.ru mi hanno insegnato che i tester non dovrebbero credere alla parola degli sviluppatori e che le operazioni non dovrebbero prendere la parola di tutti. Dobbiamo controllare.
In secondo luogo, è necessario scrivere diagrammi di interazione, perché accade che i servizi che non vengono accolti molto bene contengano dipendenze di cui nessuno ha parlato. Ad esempio, gli sviluppatori hanno installato il servizio sulla loro chiave su alcuni Yandex.Maps o Dadata. Hai esaurito il limite gratuito, tutto è rotto e non sai affatto cosa sia successo. Tutti questi rastrelli devono essere descritti: il servizio utilizza Dadata, SMS, qualcos'altro.
In terzo luogo, lavorare con il debito tecnico. Quando fai una sorta di stampelle o accetti un servizio e dici che qualcosa deve essere fatto, devi assicurarti che sia fatto. Perché allora potrebbe succedere che il piccolo buco non sia così piccolo e tu ci cadrai dentro.
Per quanto riguarda i compiti architettonici, abbiamo avuto una storia sulla Sfinge. Uno dei servizi utilizzava Sphinx per inserire elenchi. Solo un elenco impaginato, ma veniva reindicizzato ogni notte. Era composto da due indici: uno grande veniva indicizzato ogni notte, e c'era anche un piccolo indice che veniva avvitato ad esso. Ogni giorno, con una probabilità del 50% di bombardamento o meno, l'indice crollava durante il calcolo e le nostre notizie smettevano di aggiornarsi sulla pagina principale. All'inizio ci sono voluti 5 minuti per reindicizzare l'indice, poi l'indice è cresciuto e ad un certo punto ci sono voluti 40 minuti per reindicizzarlo. Quando l'abbiamo tagliato, abbiamo tirato un sospiro di sollievo, perché era chiaro che sarebbe passato ancora un po' di tempo e il nostro indice sarebbe stato reindicizzato a tempo pieno. Questo sarà un fallimento per il nostro portale, non ci sono notizie per otto ore: tutto qui, gli affari si sono fermati.
Pianificare la collaborazione con un servizio orfano
In realtà, questo è molto difficile da fare, perché il devops riguarda la comunicazione. Vuoi essere in buoni rapporti con i tuoi colleghi e quando colpisci in testa i tuoi colleghi e manager con le normative, potrebbero provare sentimenti contrastanti nei confronti di coloro che lo fanno.
Oltre a tutti questi punti, c'è un'altra cosa importante: persone specifiche devono essere responsabili per ogni servizio specifico, per ogni sezione specifica della procedura di implementazione. Quando non ci sono persone e devi attirarne altre per studiare l’intera questione, diventa difficile.
Se tutto ciò non ha aiutato e il tuo servizio orfano è ancora orfano, nessuno vuole assumerselo, la documentazione non è scritta, il team chiamato in questo servizio si rifiuta di fare qualsiasi cosa, c'è un modo semplice: rifare tutto.
Cioè, prendi di nuovo i requisiti per il servizio e scrivi un nuovo servizio, migliore, su una piattaforma migliore, senza strane soluzioni tecnologiche. E ti emigra in battaglia.
Abbiamo avuto una situazione in cui abbiamo preso un servizio su Yii 1 e ci siamo resi conto che non potevamo svilupparlo ulteriormente, perché eravamo a corto di sviluppatori che potessero scrivere bene su Yii 1. Tutti gli sviluppatori scrivono bene su Symfony XNUMX. Cosa fare? Abbiamo assegnato tempo, assegnato un team, assegnato un manager, riscritto il progetto e spostato senza problemi il traffico su di esso.
Successivamente è possibile eliminare il vecchio servizio. Questa è la mia procedura preferita, quando bisogna togliere e ripulire qualche servizio dal sistema di gestione della configurazione e poi verificare che tutte le auto in produzione siano state disabilitate, in modo che sugli sviluppatori non rimanga alcuna traccia. Il repository rimane in Git.
Questo è tutto ciò di cui volevo parlare, sono pronto a discutere, l'argomento è holivar, molti ci hanno nuotato.
Le diapositive dicevano che avete unificato le lingue. Un esempio è stato il ridimensionamento delle immagini. È davvero necessario limitarlo rigorosamente a una lingua? Perché il ridimensionamento delle immagini in PHP, beh, potrebbe effettivamente essere eseguito in Golang.
Di fatto è facoltativa, come tutte le pratiche. Forse, in alcuni casi, è addirittura indesiderabile. Ma devi capire che se hai un dipartimento tecnico in un'azienda di 50 persone, 45 di loro sono specialisti PHP, altri 3 sono devop che conoscono Python, Ansible, Puppet e qualcosa del genere, e solo uno di loro scrive in qualche tipo di linguaggio. Alcuni vanno al servizio di ridimensionamento delle immagini, quindi quando se ne va, l'esperienza lo accompagna. E allo stesso tempo dovrai cercare uno sviluppatore specifico per il mercato che conosca questa lingua, soprattutto se è rara. Cioè, da un punto di vista organizzativo, questo è problematico. Da un punto di vista devops, non dovrai solo clonare alcuni set di playbook già pronti che utilizzi per distribuire i servizi, ma dovrai riscriverli da capo.
Stiamo attualmente costruendo un servizio su Node.js e questa sarà semplicemente una piattaforma nelle vicinanze per ogni sviluppatore con un linguaggio separato. Ma ci siamo seduti e abbiamo pensato che il gioco valeva la candela. Cioè, questa è una domanda su cui sederti e pensare.
Come monitori i tuoi servizi? Come raccogli e monitori i log?
Raccogliamo i log in Elasticsearch e li inseriamo in Kibana e, a seconda che si tratti di ambienti di produzione o di test, lì vengono utilizzati diversi raccoglitori. Da qualche parte Lumberjack, da qualche altra parte qualcos'altro, non ricordo. E ci sono ancora alcuni posti in alcuni servizi in cui installiamo Telegraf e giriamo da qualche altra parte separatamente.
Come convivere con Puppet e Ansible nello stesso ambiente?
In effetti, ora abbiamo due ambienti, uno è Puppet, l'altro è Ansible. Stiamo lavorando per ibridarli. Ansible è un buon framework per la configurazione iniziale, Puppet è un cattivo framework per la configurazione iniziale perché richiede lavoro pratico direttamente sulla piattaforma e Puppet garantisce la convergenza della configurazione. Ciò significa che la piattaforma si mantiene in uno stato aggiornato e, affinché la macchina ansibilizzata sia mantenuta aggiornata, è necessario eseguire costantemente i playbook con una certa frequenza. Questa è la differenza.
Come mantieni la compatibilità? Hai configurazioni sia in Ansible che in Puppet?
Questo è il nostro grande dolore, manteniamo la compatibilità con le nostre mani e pensiamo a come andare avanti da tutto questo da qualche parte adesso. Si scopre che Puppet distribuisce i pacchetti e mantiene alcuni collegamenti lì, e Ansible, ad esempio, distribuisce il codice e regola lì le ultime configurazioni dell'applicazione.
La presentazione riguardava diverse versioni di Ruby. Quale soluzione?
L’abbiamo riscontrato in un posto e dobbiamo tenerlo sempre in testa. Abbiamo semplicemente disattivato la parte eseguita su Ruby che era incompatibile con le applicazioni e l'abbiamo tenuta separata.
La conferenza di quest'anno avrà luogo il 7 dicembre al Technopolis. Accettiamo richieste di report fino all'11 novembre. noi se vuoi parlare.
La registrazione per i partecipanti è aperta, unisciti a noi!
Fonte: habr.com