Operationsdirektören för Banki.ru-portalen Andrey Nikolsky talade vid förra årets konferens om föräldralösa tjänster: hur man identifierar ett föräldralöst barn i infrastrukturen, varför föräldralösa tjänster är dåliga, vad man ska göra med dem och vad man ska göra om inget hjälper.
Under klippet finns en textversion av rapporten.
Hallå kollegor! Jag heter Andrey, jag leder verksamheten på Banki.ru.
Vi har stora tjänster, det är sådana monolitiska tjänster, det finns tjänster i mer klassisk mening och det finns väldigt små. I min arbetar-bonde-terminologi säger jag att om en tjänst är enkel och liten, så är den mikro, och om den inte är väldigt enkel och liten, så är den bara en tjänst.
Fördelar med tjänster
Jag ska snabbt gå igenom fördelarna med tjänsterna.
Den första är skalning. Du kan snabbt göra något på tjänsten och starta produktionen. Du har fått trafik, du har klonat tjänsten. Du har mer trafik, du har klonat den och lever med den. Detta är en bra bonus, och i princip, när vi började, ansågs det vara det viktigaste för oss, varför vi gör allt detta.
För det andra, isolerad utveckling, när man har flera utvecklingsteam, flera olika utvecklare i varje team, och varje team utvecklar sin egen tjänst.
Med team finns det en nyans. Utvecklare är olika. Och det finns t.ex. . Jag såg det här första gången med Maxim Dorofeev. Ibland finns snöflingor i vissa lag och inte i andra. Detta gör att de olika tjänsterna som används över hela företaget blir lite ojämna.
Titta på bilden: det här är en bra utvecklare, han har stora händer, han kan göra mycket. Det största problemet är var dessa händer kommer ifrån.
Tjänster gör det möjligt att använda olika programmeringsspråk som är mer lämpade för olika uppgifter. Vissa tjänster finns i Go, vissa är i Erlang, vissa är i Ruby, något är i PHP, något är i Python. Generellt sett kan du expandera väldigt brett. Det finns nyanser även här.
Tjänsteorienterad arkitektur handlar i första hand om devops. Det vill säga, om du inte har automatisering finns det ingen distributionsprocess, om du konfigurerar den manuellt, dina konfigurationer kan ändras från tjänsteinstans till instans, och du måste gå dit för att göra något, då är du i helvetet.
Till exempel har du 20 tjänster och du behöver distribuera för hand, du har 20 konsoler och du trycker samtidigt på "enter" som en ninja. Det är inte särskilt bra.
Om du har en tjänst efter testning (om det finns testning förstås), och du fortfarande behöver avsluta den med en fil så att den fungerar i produktionen, har jag också dåliga nyheter till dig.
Om du förlitar dig på specifika Amazon-tjänster och arbetar i Ryssland, hade du för två månader sedan också "Allt runt omkring brinner, jag mår bra, allt är coolt."
Vi använder Ansible för att automatisera distributionen, Puppet för konvergens, Bamboo för att automatisera distributionen och Confluence för att på något sätt beskriva det hela.
Jag kommer inte att uppehålla mig i detalj, eftersom rapporten handlar mer om interaktionspraxis och inte om teknisk implementering.
Vi har till exempel haft problem där Puppet på servern fungerar med Ruby 2, men någon applikation är skriven för Ruby 1.8, och de fungerar inte tillsammans. Något går fel där. Och när du behöver köra flera versioner av Ruby på en maskin börjar du oftast få problem.
Till exempel ger vi varje utvecklare en plattform där det finns ungefär allt som vi har, alla tjänster som kan utvecklas, så att han har en isolerad miljö, han kan bryta den och bygga den som han vill.
Det händer att man behöver något speciellt sammanställt paket med stöd för något där. Det är ganska tufft. Jag lyssnade på en rapport där Docker-bilden väger 45 GB. I Linux är det naturligtvis enklare, allt är mindre där, men ändå kommer det inte att finnas tillräckligt med utrymme.
Tja, det finns motstridiga beroenden, när en del av projektet beror på ett bibliotek av en version, beror en annan del av projektet på en annan version, och biblioteken är inte alls installerade tillsammans.
Vi har sajter och tjänster i PHP 5.6, vi skäms över dem, men vad kan vi göra? Det här är vår enda sida. Det finns sajter och tjänster på PHP 7, det finns fler av dem, vi skäms inte för dem. Och varje utvecklare har sin egen bas där han gärna sågar.
Om du skriver i ett företag på ett språk så låter tre virtuella maskiner per utvecklare normalt. Om du har olika programmeringsspråk blir situationen värre.
Du har webbplatser och tjänster på detta, på denna, sedan en annan sida för Go, en sida för Ruby och några andra Redis vid sidan av. Som ett resultat förvandlas allt detta till ett stort fält för stöd, och hela tiden kan en del av det gå sönder.
Därför ersatte vi fördelarna med programmeringsspråket med användning av olika ramverk, eftersom PHP-ramverk är ganska olika, de har olika möjligheter, olika gemenskaper och olika stöd. Och du kan skriva en tjänst så att du redan har något redo för den.
Varje tjänst har sitt eget team
Vår främsta fördel, som har utkristalliserats under flera år, är att varje tjänst har sitt eget team. Detta är bekvämt för ett stort projekt, du kan spara tid på dokumentation, chefer kan sitt projekt väl.
Du kan enkelt skicka in uppgifter från supporten. Till exempel gick försäkringstjänsten sönder. Och omedelbart går teamet som sysslar med försäkringar för att fixa det.
Nya funktioner skapas snabbt, för när du har en atomtjänst kan du snabbt skruva in något i den.
Och när du bryter din tjänst, och detta oundvikligen händer, påverkade du inte andras tjänster, och utvecklare med bitar från andra team kommer inte springande till dig och säger: "Åh, gör inte det."
Som alltid finns det nyanser. Vi har stabila lag, chefer är spikade i laget. Det finns tydliga dokument, chefer övervakar allt noga. Varje team med en chef har flera tjänster, och det finns en specifik kompetenspunkt.
Om lagen flyter (vi använder också detta ibland) finns det en bra metod som kallas "stjärnkartan".
Du har en lista över tjänster och personer. En asterisk betyder att personen är expert på denna tjänst, en bok betyder att personen studerar denna tjänst. Personens uppgift är att ändra häftet mot en asterisk. Och om inget skrivs framför tjänsten, börjar problemen, som jag kommer att prata om ytterligare.
Hur ser föräldralösa tjänster ut?
Det första problemet, det första sättet att få en föräldralös tjänst i din infrastruktur är att avskeda människor. Har någon någonsin haft ett företag att uppfylla deadlines innan uppgifterna bedömdes? Ibland händer det att deadlines är snäva och det finns helt enkelt inte tillräckligt med tid för dokumentation. "Vi måste lämna över tjänsten till produktionen, sedan lägger vi till den."
Om teamet är litet händer det att det finns en utvecklare som skriver allt, resten är i kulisserna. "Jag skrev den grundläggande arkitekturen, låt oss lägga till gränssnitten." Sen någon gång går till exempel chefen. Och under denna period, när chefen har slutat och en ny ännu inte har utsetts, bestämmer utvecklarna själva vart tjänsten ska och vad som händer där. Och som vi vet (låt oss gå tillbaka några bilder), i vissa lag finns det snöflingamänniskor, ibland en lagledare för snöflinga. Sedan slutar han, och vi får en föräldralös gudstjänst.
Samtidigt försvinner inte uppgifter från support och från näringslivet, de hamnar i eftersläpningen. Om det blev några arkitektoniska fel under utvecklingen av tjänsten hamnar de också i eftersläpningen. Tjänsten försämras sakta.
Hur identifierar man ett föräldralöst barn?
Denna lista beskriver situationen väl. Vem lärde sig något om deras infrastruktur?
Om dokumenterade lösningar: det finns en tjänst och i allmänhet fungerar den, den har en tvåsidig manual om hur man arbetar med den, men ingen vet hur den fungerar inuti.
Eller så finns det till exempel någon form av länkförkortare. Till exempel har vi för närvarande tre länkförkortare som används för olika ändamål i olika tjänster. Det här är bara konsekvenserna.
Nu ska jag vara kapten för det uppenbara. Vad borde göras? Först måste vi överföra tjänsten till en annan chef, ett annat team. Om din teamledare ännu inte har slutat, då i detta andra team, när du förstår att tjänsten är som en föräldralös, måste du inkludera någon som förstår åtminstone något om det.
Det viktigaste: du måste ha överföringsprocedurerna skrivna i blod. I vårt fall brukar jag övervaka detta, eftersom jag behöver allt för att fungera. Chefer behöver det levereras snabbt, och vad som händer med det senare är inte längre så viktigt för dem.
Nästa sätt att göra en föräldralös är "Vi kommer att göra det på entreprenad, det kommer att gå snabbare, och sedan lämnar vi över det till teamet." Det är klart att alla har några planer i laget, en sväng. Ofta tror en företagskund att uppdragsgivaren kommer att göra samma sak som den tekniska avdelning som företaget har. Även om deras drivkrafter är olika. Det finns konstiga tekniska lösningar och konstiga algoritmiska lösningar inom outsourcing.
Vi hade till exempel en tjänst som hade Sphinx på olika oväntade ställen. Jag ska berätta senare vad jag var tvungen att göra.
Entreprenörer har självskrivna ramar. Det här är bara PHP med copy-paste från ett tidigare projekt, där du kan hitta alla möjliga saker. Implementeringsskript är en stor nackdel när du behöver använda några komplexa Bash-skript för att ändra flera rader i någon fil, och dessa distributionsskript anropas av något tredje skript. Som ett resultat ändrar du distributionssystemet, väljer något annat, hoppar, men din tjänst fungerar inte. För där var det nödvändigt att lägga ytterligare 8 länkar mellan olika mappar. Eller så händer det att tusen skivor fungerar, men hundra tusen inte längre fungerar.
Jag kommer att fortsätta som kapten. Att acceptera en utlagd tjänst är ett obligatoriskt förfarande. Har någon någonsin haft en utlagd tjänst som anländer och inte blivit accepterad någonstans? Detta är naturligtvis inte lika populärt som en föräldralös tjänst, men ändå.
Tjänsten måste kontrolleras, tjänsten måste ses över, lösenord måste ändras. Vi hade ett fall när de gav oss en tjänst, det finns en adminpanel "om login == 'admin' && lösenord == 'admin'...", det är skrivet direkt i koden. Vi sitter och funderar, och folk skriver det här 2018?
Att testa lagringskapacitet är också en nödvändig sak. Du måste titta på vad som kommer att hända på hundra tusen skivor, även innan du sätter den här tjänsten i produktion någonstans.
Det borde inte vara någon skam att skicka en tjänst för förbättring. När du säger: "Vi kommer inte att acceptera den här tjänsten, vi har 20 uppgifter, gör dem, då accepterar vi", är det normalt. Ditt samvete ska inte ta skada av att du sätter upp en chef eller att verksamheten slösar pengar. Verksamheten kommer då att spendera mer.
Vi hade ett fall när vi bestämde oss för att lägga ut ett pilotprojekt på entreprenad.
Den levererades i tid och detta var det enda kvalitetskriteriet. Det var därför vi gjorde ytterligare ett pilotprojekt, som inte ens egentligen var ett pilotprojekt längre. Dessa tjänster accepterades, och på administrativ väg sa de, här är din kod, här är teamet, här är din chef. Tjänsterna har faktiskt redan börjat gå med vinst. Samtidigt är de faktiskt fortfarande föräldralösa, ingen förstår hur de fungerar och chefer gör sitt bästa för att förneka sina uppgifter.
Det finns ett annat bra koncept - gerillautveckling. När någon avdelning, oftast marknadsavdelningen, vill testa en hypotes och beställer hela tjänsten utlagd. Trafiken börjar strömma in, de stänger dokumenten, undertecknar dokument med entreprenören, kommer i drift och säger: "Gubbar, vi har en tjänst här, den har redan trafik, den ger oss pengar, låt oss acceptera det." Vi var som, "Oppa, hur kan det vara."
Och ett annat sätt att få en föräldralös tjänst: när något team plötsligt finner sig laddat säger ledningen: "Låt oss överföra det här lagets service till ett annat team, det har en mindre belastning." Och sedan överför vi det till ett tredje lag och byter manager. Och till slut har vi ett föräldralöst barn igen.
Vad är problemet med föräldralösa barn?
Vem vet inte, det här är slagskeppet Wasa som restes upp i Sverige, känt för att det sjönk 5 minuter efter sjösättning. Och Sveriges kung avrättade för övrigt ingen för detta. Den byggdes av två generationer ingenjörer som inte visste hur man bygger sådana fartyg. Naturlig effekt.
Skeppet kunde för övrigt ha sjunkit på ett mycket värre sätt, till exempel när kungen redan åkte på det någonstans i en storm. Och så drunknade han direkt, enligt Agile är det bra att misslyckas tidigt.
Misslyckas vi tidigt är det oftast inga problem. Till exempel, under godkännandet skickades den för revision. Men om vi misslyckas redan i produktionen, när pengar investeras, då kan det bli problem. Konsekvenser, som de kallas i näringslivet.
Varför föräldralösa tjänster är farliga:
- Tjänsten kan plötsligt gå sönder.
- Tjänsten tar lång tid att reparera eller repareras inte alls.
- Säkerhetsproblem.
- Problem med förbättringar och uppdateringar.
- Om en viktig tjänst går sönder blir företagets rykte lidande.
Vad ska man göra med föräldralösa tjänster?
Jag ska upprepa vad jag ska göra igen. Först måste det finnas dokumentation. 7 år på Banki.ru lärde mig att testare inte borde ta utvecklarnas ord, och verksamheten borde inte ta allas ord. Vi måste kolla.
För det andra är det nödvändigt att skriva interaktionsdiagram, eftersom det händer att tjänster som inte är särskilt väl mottagna innehåller beroenden som ingen sa om. Till exempel installerade utvecklarna tjänsten på sin nyckel till vissa Yandex.Maps eller Dadata. Du har tagit slut på gratisgränsen, allt är trasigt och du vet inte alls vad som hände. Alla sådana rakes måste beskrivas: tjänsten använder Dadata, SMS, något annat.
För det tredje, att arbeta med tekniska skulder. När du gör någon form av kryckor eller accepterar en tjänst och säger att något måste göras måste du se till att det blir gjort. För då kan det visa sig att det lilla hålet inte är så litet, och du kommer att ramla genom det.
Med arkitektuppgifter hade vi en berättelse om Sfinx. En av tjänsterna använde Sphinx för att skriva in listor. Bara en paginerad lista, men den indexerades om varje kväll. Det var sammansatt av två index: ett stort indexerades varje kväll, och det fanns också ett litet index som skruvades fast på det. Varje dag, med 50 % sannolikhet att antingen bomba eller inte, kraschade indexet under beräkningen, och våra nyheter slutade uppdateras på huvudsidan. Först tog det 5 minuter för indexet att återindexeras, sedan växte indexet och någon gång började det ta 40 minuter att återindexera. När vi klippte bort det här andades vi ut, för det var klart att det skulle gå lite mer tid och vårt index skulle återindexeras på heltid. Detta kommer att bli ett misslyckande för vår portal, det finns inga nyheter på åtta timmar - det är allt, affärerna har stannat.
Planera för att arbeta med en föräldralös tjänst
Faktum är att detta är väldigt svårt att göra, eftersom devops handlar om kommunikation. Du vill vara på god fot med dina kollegor, och när du slår dina kollegor och chefer i huvudet med regelverk kan de ha motstridiga känslor gentemot de människor som gör detta.
Utöver alla dessa punkter finns det en annan viktig sak: specifika personer måste vara ansvariga för varje specifik tjänst, för varje specifik del av utplaceringsförfarandet. När det inte finns några människor och man måste locka till sig några andra för att studera hela den här saken blir det svårt.
Om allt detta inte hjälpte, och din föräldralösa tjänst fortfarande är en föräldralös, ingen vill ta på sig det, dokumentation är inte skriven, teamet som kallades till denna tjänst vägrar att göra något, det finns ett enkelt sätt - att göra om allt .
Det vill säga att du tar kraven på tjänsten på nytt och skriver en ny tjänst, bättre, på en bättre plattform, utan konstiga tekniska lösningar. Och du migrerar till det i strid.
Vi hade en situation när vi tog en tjänst på Yii 1 och insåg att vi inte kunde utveckla den vidare, eftersom vi fick slut på utvecklare som kunde skriva bra på Yii 1. Alla utvecklare skriver bra på Symfony XNUMX. Vad ska man göra? Vi tilldelade tid, tilldelade ett team, tilldelade en chef, skrev om projektet och bytte smidigt trafik till det.
Efter detta kan den gamla tjänsten raderas. Det här är min favoritprocedur, när du behöver ta och rensa ut någon tjänst från konfigurationshanteringssystemet och sedan gå igenom och se att alla bilar i produktion har stängts av, så att utvecklarna inte har några spår kvar. Lagret finns kvar i Git.
Det här är allt jag ville prata om, jag är redo att diskutera, ämnet är holivar, många har simmat i det.
Bilderna sa att ni enade språk. Ett exempel var storleksändring av bilder. Är det verkligen nödvändigt att strikt begränsa det till ett språk? Eftersom storleksändring av bilder i PHP, ja, faktiskt kan göras i Golang.
I själva verket är det valfritt, som alla metoder. Kanske, i vissa fall, är det till och med oönskat. Men du måste förstå att om du har en teknisk avdelning i ett företag på 50 personer, 45 av dem är PHP-specialister, ytterligare 3 är devops som kan Python, Ansible, Puppet och något liknande, och bara en av dem skriver i vissa typ av språk, någon Go-tjänst för storleksändring av bilder, och när den lämnar, följer expertisen med den. Och samtidigt måste du leta efter en marknadsspecifik utvecklare som kan detta språk, särskilt om det är sällsynt. Det vill säga ur organisatorisk synvinkel är detta problematiskt. Ur en devops-synpunkt behöver du inte bara klona några färdiga spelböcker som du använder för att distribuera tjänster, utan du måste skriva om dem igen.
Vi bygger för närvarande en tjänst på Node.js, och detta kommer bara att vara en plattform i närheten för varje utvecklare med ett separat språk. Men vi satt och tyckte att spelet var värt ljuset. Det vill säga, det här är en fråga för dig att sitta och fundera över.
Hur övervakar du dina tjänster? Hur samlar och övervakar du loggar?
Vi samlar in stockar i Elasticsearch och lägger dem i Kibana och beroende på om det är produktions- eller testmiljöer används olika samlare där. Någonstans Lumberjack, någon annanstans något annat minns jag inte. Och det finns fortfarande några ställen i vissa tjänster där vi installerar Telegraf och fotograferar någon annanstans separat.
Hur lever man med Puppet och Ansible i samma miljö?
Faktum är att vi nu har två miljöer, den ena är Puppet, den andra är Ansible. Vi arbetar med att hybridisera dem. Ansible är ett bra ramverk för initial installation, Puppet är ett dåligt ramverk för initial installation eftersom det kräver praktiskt arbete direkt på plattformen, och Puppet säkerställer konfigurationskonvergens. Detta innebär att plattformen håller sig i ett uppdaterat tillstånd, och för att den ansibiliserade maskinen ska hållas uppdaterad måste du köra spelböcker på den hela tiden med viss frekvens. Det är skillnaden.
Hur upprätthåller du kompatibiliteten? Har du inställningar i både Ansible och Puppet?
Det här är vår stora smärta, vi upprätthåller kompatibilitet med våra händer och funderar på hur vi ska gå vidare från allt detta någonstans nu. Det visar sig att Puppet rullar ut paket och underhåller några länkar där, och Ansible rullar till exempel ut koden och justerar de senaste applikationskonfigurationerna där.
Presentationen handlade om olika versioner av Ruby. Vilken lösning?
Vi stötte på det här på ett ställe, och vi måste hålla det i huvudet hela tiden. Vi stängde helt enkelt av den del som kördes på Ruby som var inkompatibel med applikationerna och höll den åtskild.
Årets konferens kommer att äga rum den 7 december på Technopolis. Vi tar emot ansökningar om rapporter fram till den 11 november. oss om du vill prata.
Anmälan för deltagare är öppen, följ med!
Källa: will.com