El director d'operacions del portal Banki.ru, Andrey Nikolsky, va parlar a la conferència de l'any passat sobre els serveis orfes: com identificar un orfe a la infraestructura, per què els serveis orfes són dolents, què fer amb ells i què fer si res no ajuda.
A sota del tall hi ha una versió de text de l'informe.
Hola companys! Em dic Andrey, dirigeixo les operacions de Banki.ru.
Tenim serveis grans, aquests són serveis tan monolítics, n'hi ha en un sentit més clàssic i n'hi ha de molt petits. En la meva terminologia obrera-camperola, dic que si un servei és simple i petit, llavors és micro, i si no és molt senzill i petit, llavors és només un servei.
Avantatges dels serveis
Ràpidament repassaré els avantatges dels serveis.
El primer és escalar. Podeu fer alguna cosa ràpidament al servei i començar la producció. Heu rebut trànsit, heu clonat el servei. Tens més trànsit, l'has clonat i viu amb ell. Aquest és un bon avantatge i, en principi, quan vam començar, es considerava el més important per a nosaltres, per què estem fent tot això.
En segon lloc, el desenvolupament aïllat, quan tens diversos equips de desenvolupament, diversos desenvolupadors diferents a cada equip i cada equip desenvolupa el seu propi servei.
Amb els equips hi ha un matís. Els desenvolupadors són diferents. I hi ha, per exemple, . Ho vaig veure per primera vegada amb Maxim Dorofeev. De vegades, els flocs de neu estan en alguns equips i no en d'altres. Això fa que els diferents serveis utilitzats a l'empresa siguin una mica desiguals.
Mireu la imatge: aquest és un bon desenvolupador, té grans mans, pot fer molt. El principal problema és d'on provenen aquestes mans.
Els serveis permeten utilitzar diferents llenguatges de programació més adequats per a diferents tasques. Alguns serveis són a Go, altres a Erlang, alguns a Ruby, alguna cosa a PHP, alguna cosa a Python. En general, es pot expandir molt àmpliament. Aquí també hi ha matisos.
L'arquitectura orientada a serveis tracta principalment de devops. És a dir, si no teniu automatització, no hi ha cap procés de desplegament, si el configureu manualment, les vostres configuracions poden canviar d'instància de servei a instància i heu d'anar-hi per fer alguna cosa, aleshores esteu a l'infern.
Per exemple, tens 20 serveis i has de desplegar-los a mà, tens 20 consoles i premeu "Enter" simultàniament com un ninja. No és gaire bo.
Si tens un servei després de la prova (si n'hi ha prova, és clar), i encara has d'acabar-lo amb un fitxer perquè funcioni en producció, també tinc una mala notícia per a tu.
Si confieu en serveis específics d'Amazon i treballeu a Rússia, fa dos mesos també teníeu "Tot al voltant està en flames, estic bé, tot està bé".
Utilitzem Ansible per automatitzar el desplegament, Puppet per a la convergència, Bamboo per automatitzar el desplegament i Confluence per descriure-ho tot d'alguna manera.
No m'atendré en això en detall, perquè l'informe tracta més sobre pràctiques d'interacció, i no sobre implementació tècnica.
Per exemple, hem tingut problemes on Puppet al servidor funciona amb Ruby 2, però alguna aplicació està escrita per a Ruby 1.8 i no funcionen junts. Alguna cosa va malament allà. I quan necessiteu executar diverses versions de Ruby en una màquina, normalment comenceu a tenir problemes.
Per exemple, donem a cada desenvolupador una plataforma sobre la qual hi ha aproximadament tot el que tenim, tots els serveis que es poden desenvolupar, perquè tingui un entorn aïllat, el pugui trencar i construir-lo com vulgui.
Succeeix que necessiteu algun paquet compilat especialment amb suport per a alguna cosa allà. És bastant dur. Vaig escoltar un informe on la imatge de Docker pesa 45 GB. A Linux, és clar, és més senzill, tot és més petit allà, però tot i així, no hi haurà prou espai.
Bé, hi ha dependències conflictives, quan una part del projecte depèn d'una biblioteca d'una versió, una altra part del projecte depèn d'una altra versió i les biblioteques no s'instal·len en absolut.
Tenim llocs i serveis en PHP 5.6, ens fan vergonya, però què podem fer? Aquest és el nostre únic lloc. Hi ha llocs i serveis a PHP 7, n'hi ha més, no ens avergonyim. I cada desenvolupador té la seva pròpia base on veu feliçment.
Si escrius en una empresa en un idioma, tres màquines virtuals per desenvolupador sona normal. Si teniu diferents llenguatges de programació, la situació empitjora.
Teniu llocs i serveis sobre això, en aquest, després un altre lloc per a Go, un lloc per a Ruby i algun altre Redis al costat. Com a resultat, tot això es converteix en un gran camp de suport, i tot el temps una part pot trencar-se.
Per tant, vam substituir els avantatges del llenguatge de programació per l'ús de diferents frameworks, ja que els frameworks PHP són força diferents, tenen diferents capacitats, diferents comunitats i diferents suports. I pots escriure un servei perquè ja tinguis alguna cosa a punt.
Cada servei té el seu propi equip
El nostre principal avantatge, que s'ha cristal·litzat al llarg de diversos anys, és que cada servei té el seu propi equip. Això és convenient per a un projecte gran, podeu estalviar temps en la documentació, els gestors coneixen bé el seu projecte.
Podeu enviar tasques fàcilment des del suport. Per exemple, el servei d'assegurances es va trencar. I de seguida l'equip que s'ocupa d'assegurances va a arreglar-ho.
S'estan creant noves funcions ràpidament, perquè quan tens un servei atòmic, pots posar-hi alguna cosa ràpidament.
I quan trenqueu el vostre servei, i això passa inevitablement, no heu afectat els serveis d'altres persones, i els desenvolupadors d'altres equips no us venen corrents i us diuen: "Ai, sí, no ho facis".
Com sempre, hi ha matisos. Tenim equips estables, els directius estan clavats a l'equip. Hi ha documents clars, els directius ho controlen tot de prop. Cada equip amb un responsable té diversos serveis, i hi ha un punt de competència específic.
Si els equips estan flotant (a vegades també ho fem servir), hi ha un bon mètode anomenat "mapa d'estrelles".
Tens una llista de serveis i persones. Un asterisc significa que la persona és experta en aquest servei, un llibre significa que la persona està estudiant aquest servei. La tasca de la persona és canviar el fullet per un asterisc. I si no s'escriu res davant del servei, comencen els problemes, dels quals parlaré més endavant.
Com apareixen els serveis orfes?
El primer problema, la primera manera d'aconseguir un servei orfe a la vostra infraestructura és acomiadar gent. Algú ha tingut mai que una empresa compleixi els terminis abans d'avaluar les tasques? De vegades passa que els terminis són ajustats i simplement no hi ha prou temps per a la documentació. "Hem de lliurar el servei a la producció, després l'afegirem".
Si l'equip és petit, passa que hi ha un desenvolupador que ho escriu tot, la resta està a les ales. "Vaig escriure l'arquitectura bàsica, afegim les interfícies". Aleshores, en algun moment, el gerent, per exemple, marxa. I durant aquest període, quan el gerent ha marxat i encara no se n'ha nomenat un de nou, els mateixos desenvolupadors decideixen cap a on va el servei i què hi passa. I com sabem (retornem unes quantes diapositives), en alguns equips hi ha gent de flocs de neu, de vegades cap d'equip de flocs de neu. Llavors ell abandona i tenim un servei orfe.
Al mateix temps, les tasques de suport i de negoci no desapareixen, acaben en l'endarreriment. Si hi ha hagut errors arquitectònics durant el desenvolupament del servei, també acaben en l'endarreriment. El servei es va deteriorant lentament.
Com identificar un orfe?
Aquesta llista descriu bé la situació. Qui ha après alguna cosa sobre la seva infraestructura?
Sobre les alternatives documentades: hi ha un servei i, en general, funciona, té un manual de dues pàgines sobre com treballar-hi, però ningú sap com funciona dins.
O, per exemple, hi ha algun tipus d'escurçador d'enllaços. Per exemple, actualment tenim tres escurçadors d'enllaços en ús per a diferents finalitats en diferents serveis. Aquestes són només les conseqüències.
Ara seré el capità de l'obvi. Què s'ha de fer? En primer lloc, hem de transferir el servei a un altre gestor, un altre equip. Si el líder del vostre equip encara no ha abandonat, aleshores en aquest altre equip, quan entengueu que el servei és com un orfe, heu d'incloure algú que entén almenys alguna cosa al respecte.
El més important: heu de tenir els procediments de transferència escrits amb sang. En el nostre cas, acostumo a controlar-ho, perquè necessito que tot funcioni. Els directius necessiten que s'entregui ràpidament, i el que li passa després ja no els és tan important.
La següent manera de fer un orfe és "Ho farem subcontractats, serà més ràpid i després el lliurarem a l'equip". Està clar que tothom té uns plans a l'equip, un torn. Sovint, un client empresarial pensa que l'externalitzador farà el mateix que el departament tècnic que té l'empresa. Encara que els seus motivadors són diferents. Hi ha solucions tecnològiques estranyes i solucions algorítmiques estranyes en l'externalització.
Per exemple, teníem un servei que tenia Sphinx en diversos llocs inesperats. Més tard us explicaré què havia de fer.
Els subcontractistes tenen marcs escrits per ells mateixos. Això és només PHP nu amb copiar i enganxar d'un projecte anterior, on podeu trobar tot tipus de coses. Els scripts de desplegament són un gran inconvenient quan necessiteu utilitzar alguns scripts de Bash complexos per canviar diverses línies en algun fitxer, i aquests scripts de desplegament els crida algun tercer script. Com a resultat, canvieu el sistema de desplegament, trieu una altra cosa, salteu, però el vostre servei no funciona. Perquè allà calia posar 8 enllaços més entre diferents carpetes. O passa que mil discos funcionen, però cent mil ja no funcionen.
Continuaré com a capità. Acceptar un servei subcontractat és un tràmit obligatori. Algú ha arribat mai un servei subcontractat i no ha estat acceptat enlloc? Això no és tan popular, per descomptat, com un servei orfe, però tot i així.
Cal comprovar el servei, revisar el servei i canviar les contrasenyes. Vam tenir un cas quan ens van donar un servei, hi ha un tauler d'administració "si login == 'admin' && password == 'admin'...", està escrit just al codi. Ens asseiem i pensem, i la gent escriu això el 2018?
També és necessari provar la capacitat d'emmagatzematge. Heu de mirar què passarà en cent mil registres, fins i tot abans de posar aquest servei en producció en algun lloc.
No hi hauria d'haver cap vergonya a enviar un servei per millorar. Quan dius: "No acceptarem aquest servei, tenim 20 tasques, fes-les, després ho acceptarem", això és normal. La teva consciència no s'ha de fer mal pel fet que estàs creant un gerent o que el negoci està malgastant diners. Llavors el negoci gastarà més.
Vam tenir un cas quan vam decidir externalitzar un projecte pilot.
Es va lliurar a temps, i aquest era l'únic criteri de qualitat. Per això vam fer un altre projecte pilot, que ja no era ni tan sols un pilot. Aquests serveis van ser acceptats, i per mitjans administratius van dir, aquí teniu el vostre codi, aquí teniu l'equip, aquí teniu el vostre gestor. De fet, els serveis ja han començat a obtenir beneficis. Al mateix temps, de fet, encara són orfes, ningú entén com treballen i els directius fan tot el possible per renegar de les seves tasques.
Hi ha un altre gran concepte: el desenvolupament de la guerrilla. Quan algun departament, generalment el departament de màrqueting, vol provar una hipòtesi i encarrega tot el servei subcontractat. El trànsit comença a abocar-s'hi, tanquen els documents, signen documents amb el contractista, entren en funcionament i diuen: "Amics, aquí tenim un servei, ja té trànsit, ens porta diners, acceptem-ho". Vam dir: "Oppa, com pot ser això".
I una altra manera d'aconseguir un servei orfe: quan algun equip es veu carregat de sobte, la direcció diu: "Transferim el servei d'aquest equip a un altre equip, té una càrrega menor". I després el transferirem a un tercer equip i canviarem de gerent. I al final tornem a tenir un orfe.
Quin és el problema dels orfes?
Qui no ho sap, aquest és el cuirassat Wasa aixecat a Suècia, famós pel fet que s'enfonsà 5 minuts després del llançament. I el rei de Suècia, per cert, no va executar ningú per això. Va ser construït per dues generacions d'enginyers que no sabien com construir aquest tipus de vaixells. Efecte natural.
El vaixell podria haver-se enfonsat, per cert, d'una manera molt pitjor, per exemple, quan el rei ja hi anava en algun lloc d'una tempesta. I així, es va ofegar de seguida, segons Agile, és bo fallar aviat.
Si fallem aviat, normalment no hi ha problemes. Per exemple, durant l'acceptació es va enviar per revisió. Però si ja fallem en la producció, quan s'inverteixen diners, pot haver-hi problemes. Conseqüències, com s'anomenen als negocis.
Per què els serveis orfes són perillosos:
- El servei pot trencar-se sobtadament.
- El servei triga molt a reparar-se o no es repara en absolut.
- Problemes de seguretat.
- Problemes amb millores i actualitzacions.
- Si un servei important es trenca, la reputació de l'empresa es ressent.
Què fer amb els serveis orfes?
Tornaré a repetir què he de fer. En primer lloc, hi ha d'haver documentació. 7 anys a Banki.ru em van ensenyar que els provadors no haurien de prendre la paraula dels desenvolupadors i que les operacions no haurien de prendre la paraula de tothom. Hem de comprovar.
En segon lloc, cal escriure diagrames d'interacció, perquè passa que serveis poc rebuts contenen dependències que ningú en va dir. Per exemple, els desenvolupadors van instal·lar el servei a la seva clau d'alguns Yandex.Maps o Dadata. T'has quedat sense límit de llibertat, està tot trencat i no saps què va passar. Cal descriure tots aquests rastres: el servei utilitza Dadata, SMS, una altra cosa.
En tercer lloc, treballar amb deute tècnic. Quan fas algun tipus de crosses o acceptes un servei i dius que cal fer alguna cosa, has d'assegurar-te que es fa. Perquè llavors pot resultar que el petit forat no és tan petit i caureu per ell.
Amb tasques arquitectòniques, teníem una història sobre Esfinx. Un dels serveis va utilitzar Sphinx per introduir llistes. Només una llista paginada, però es tornava a indexar cada nit. Es va muntar a partir de dos índexs: un de gran se n'indexava cada nit, i també hi havia un petit índex que s'hi enganxava. Cada dia, amb una probabilitat del 50% de bombardeig o no, l'índex es va estavellar durant el càlcul i les nostres notícies van deixar d'actualitzar-se a la pàgina principal. Al principi, l'índex va trigar 5 minuts a tornar-se a indexar, després l'índex va créixer i en algun moment va començar a trigar 40 minuts a tornar-lo a indexar. Quan vam retallar això, vam respirar alleujats, perquè estava clar que passaria una mica més de temps i el nostre índex es tornaria a indexar a temps complet. Això serà un fracàs per al nostre portal, no hi ha notícies durant vuit hores; això és tot, el negoci s'ha aturat.
Planifica per treballar amb un servei orfe
De fet, això és molt difícil de fer, perquè devops tracta de comunicació. Voleu estar en bons termes amb els vostres col·legues i, quan pegueu els vostres col·legues i directius amb regulacions, poden tenir sentiments contradictoris cap a les persones que ho fan.
A tots aquests punts, hi ha una altra cosa important: persones concretes han de ser responsables de cada servei concret, de cada apartat concret del procediment de desplegament. Quan no hi ha gent i has d'atreure altres persones per estudiar tot aquest tema, es fa difícil.
Si tot això no va ajudar i el vostre servei orfe encara és orfe, ningú vol assumir-lo, la documentació no està escrita, l'equip que va ser cridat a aquest servei es nega a fer res, hi ha una manera senzilla: tornar a fer tot.
És a dir, prens de nou els requisits del servei i redactes un nou servei, millor, en una plataforma millor, sense solucions tecnològiques estranyes. I hi migreu a la batalla.
Vam tenir una situació en què vam agafar un servei a Yii 1 i ens vam adonar que no podíem desenvolupar-lo més, perquè ens vam quedar sense desenvolupadors que poguessin escriure bé a Yii 1. Tots els desenvolupadors escriuen bé a Symfony XNUMX. Què fer? Hem assignat temps, hem assignat un equip, hem assignat un gerent, hem reescrit el projecte i hem canviat el trànsit sense problemes.
Després d'això, el servei antic es pot suprimir. Aquest és el meu procediment preferit, quan necessiteu treure i netejar algun servei del sistema de gestió de la configuració i després passar-ho i veure que tots els cotxes en producció s'han desactivat, de manera que els desenvolupadors no en quedin cap rastre. El repositori roman a Git.
Això és tot el que volia parlar, estic disposat a discutir, el tema és holivar, molts s'hi han nedat.
Les diapositives deien que heu unificat els idiomes. Un exemple va ser el canvi de mida de les imatges. És realment necessari limitar-lo estrictament a una llengua? Com que el canvi de mida de la imatge en PHP, bé, es podria fer a Golang.
De fet, és opcional, com totes les pràctiques. Potser, en alguns casos, fins i tot és indesitjable. Però cal entendre que si tens un departament tècnic en una empresa de 50 persones, 45 d'elles són especialistes en PHP, altres 3 són devops que coneixen Python, Ansible, Puppet i alguna cosa així, i només un d'ells escriu en alguna tipus de llenguatge. algun servei de redimensionament d'imatges de Go, i quan surt, l'experiència va amb ell. I al mateix temps, haureu de buscar un desenvolupador específic del mercat que conegui aquest llenguatge, sobretot si és rar. És a dir, des del punt de vista organitzatiu, això és problemàtic. Des del punt de vista dels devops, no només haureu de clonar un conjunt de llibres de jocs preparats que feu servir per implementar serveis, sinó que els haureu d'escriure de nou.
Actualment estem creant un servei a Node.js, i aquesta serà només una plataforma propera per a cada desenvolupador amb un idioma diferent. Però ens vam asseure i vam pensar que el joc valia la pena l'espelma. És a dir, aquesta és una pregunta sobre la qual us heu de seure i pensar.
Com controles els teus serveis? Com recopilar i controlar els registres?
Recollim registres a Elasticsearch i els posem a Kibana i, segons si es tracta d'entorns de producció o de prova, s'hi fan servir diferents col·lectors. En algun lloc de Lumberjack, en un altre lloc una altra cosa, no ho recordo. I encara hi ha alguns llocs en determinats serveis on instal·lem Telegraf i filmem en un altre lloc per separat.
Com viure amb Puppet i Ansible en el mateix entorn?
De fet, ara tenim dos entorns, un és Puppet, l'altre és Ansible. Estem treballant per hibridar-los. Ansible és un bon marc per a la configuració inicial, Puppet és un marc dolent per a la configuració inicial perquè requereix un treball pràctic directament a la plataforma i Puppet garanteix la convergència de la configuració. Això vol dir que la plataforma es manté en un estat actualitzat i, per tal que la màquina ansibilitzada es mantingui actualitzada, heu d'executar-hi llibres de jugades tot el temps amb certa freqüència. Aquesta és la diferència.
Com manteniu la compatibilitat? Teniu configuracions tant a Ansible com a Puppet?
Aquest és el nostre gran dolor, mantenim la compatibilitat amb les nostres mans i pensem com passar de tot això en algun lloc ara. Resulta que Puppet desplega paquets i hi manté alguns enllaços, i Ansible, per exemple, desplega el codi i hi ajusta les darreres configuracions de l'aplicació.
La presentació va tractar sobre diferents versions de Ruby. Quina solució?
Ens hem trobat amb això en un sol lloc, i hem de tenir-ho al cap tot el temps. Simplement vam desactivar la part que funcionava al Ruby que era incompatible amb les aplicacions i la vam mantenir separada.
La conferència d'enguany tindrà lloc el 7 de desembre a Technopolis. Acceptem sol·licituds d'informes fins l'11 de novembre. nosaltres si vols parlar.
Les inscripcions per a participants estan obertes, acompanya'ns!
Font: www.habr.com