Orvuteenused: mikroteenuste arhitektuuri vastaspool.

Banki.ru porta juhtiv töötaja Andrei Nikolski rääkis mullu toimunud konverentsil DevOpsDays Moskvasse orvuteenustest: kuidas tuvastada orvuteenuseid infrastruktuuris, millised on orvuteenuste puudused, mida nendega teha ja kuidas käituda, kui miski ei aita.

Allpool on ettekande tekstiversioon.

Tere, kolleegid! Minu nimi on Andrei, ma juhinBanki.ru teenuseid.

Meil on suured teenused, need on monoliitteenused, on ka klassikalisemas mõttes teenuseid ja ka väga väikseid teenuseid. Oma töötava-põllumehe terminoloogias ütlen, et kui teenus on lihtne ja väike, siis on see mikro, ja kui see ei ole eriti lihtne ja mitte väike, siis on see lihtsalt teenus.

Teenuste plussid

Käin kiiresti üle teenuste plussid.

Esimene on skaleerimine. Te saate teenusel kiiresti midagi teha ja alustada tootmises. Kui teil tuleb liiklus, kloonite teenuse. Kui tuleb veel liiklust, kloonite uuesti ja elate selle kaubaga. See on hea boonus ja põhimõtteliselt, kui me alustasime, peeti seda meie jaoks kõige olulisemaks, miks me kogu seda teha üldse tahtsime.

Teiseks, isoleeritud arendamine, kui teil on mitu arendusmeeskonda, mitmed erinevad arendajad igas meeskonnas ja iga meeskond arendab oma teenust.

Meeskondadega on nüanss. Arendajad on erinevad. Näiteks on olemas lumeinimesed. Nägin esmakordselt seda maksima Dorofoevi juures. Mõnikord on lumeinimesi mõnes meeskonnas, mõnes ei ole. See muudab erinevaid teenuseid, mida ettevõttes kasutakse, veidi ebaühtlasteks.

Vaadake pilti: see on hea arendaja, tal on suured käed, ta suudab palju teha. Peamine probleem on see, kust need käed kasvavad.

Teenused võimaldavad kasutada erinevaid programmeerimiskeeli, mis sobivad paremini erinevate ülesannete täitmiseks. Üks teenus on Go-s, teine Erlangis, üks Ruby-s, mõni PHP-s, mõni Pythonis. Üldiselt, laiendaned väga laialdaselt. Siin on samuti nüansse.

Teenusele orienteeritud arhitektuur on eelkõige seotud devopsiga. See tähendab, et kui teil ei ole automatiseerimist, ei ole paigaldusprotsessi, kui te seadistate käsitsi, võivad teie konfiguratsioonid erinevate teenuse instantside vahel erineda ja peate sinna minema ja midagi tegema, siis olete põrgus.

Näiteks, kui teil on 20 teenust ja peate need käsitsi juurutama, siis teil on 20 kontrollerit ja samal ajal vajutate "enter" nagu ninja. See ei ole just kõige parem lahendus.

Kui teil on teenus, mis on pärast testimist (kui testimine on loomulikult olemas) ja seda tuleb veel lihvida, et see tootmiskeskkonnas töötaks, siis mul on teile samuti halbu uudiseid.

Kui toetute Amazoni spetsiifilistele teenustele ja töötate samal ajal Venemaal, siis kaks kuud tagasi oli teil ka "Kõik põleb ümberringi, ma olen okei, kõik on hästi".

Kasutame Ansible'it juurutamise automatiseerimiseks, Puppet'i konvergentsiks, Bamboo't juurutamise automatiseerimiseks ja Confluence'i selle kõik dokumenteerimiseks.

Ei hakka sellel pikemalt peatuma, kuna esitlus on pigem koostööpraktikate kohta, mitte tehnilise rakenduse kohta.

Meil on näiteks olnud probleeme, et Puppet serveris töötab Ruby 2, aga mõni rakendus on kirjutatud Ruby 1.8 jaoks ja nad ei tööta koos. Seal juhtub mingi probleem. Kui peate ühel masinal hoidma mitu Ruby versiooni, siis tavaliselt algavad probleemid.

Me anname näiteks igale arendajale platvormi, kus on umbes kõik, mis meil on, kõik teenused, mida saab arendada, et tal oleks isoleeritud keskkond, kus ta saaks seda lõhkuda ja ehitada, nagu tal soov on.

Mõnikord on vajalik mõni spetsiaalselt kompileeritud paket, mis toetab mingit asja. See on suhteliselt range. Kuulasin esitluse, kus Docker'i pilt kaalub 45 GB. Linuxis on muidugi lihtsam, seal on kõik väiksem, aga ikkagi, kohti ei jätku.

Noh, ja võib esineda vastuolulisi sõltuvusi, kui teie projekti üks osa sõltub ühe versiooniga raamatukogust ja teine osa teise versiooniga raamatukogust, kuid raamatukogusid ei saa omavahel paigaldada.

Meil on veebisaidid ja teenused PHP 5.6-l, meil on nende pärast häbi, aga mida teha. See on meie üks platvorm. On veebisaite ja teenuseid PHP 7-l, neid on rohkem, nende pärast meil häbi ei ole. Ja iga arendajal on oma baas, kus ta rõõmsalt töötleb.

Kui kirjutate ettevõttes ühes keeles, siis kolm virtuaalmasinat arendaja kohta on normaalne. Kui teil on erinevad programmeerimiskeeled, siis olukord halveneb.

Teie juures on veebisaidid ja teenused, see, see, siis veel üks Go platvorm, üks Ruby platvorm, veel mõni Redis kõrval. Lõpuks kõik see muutub suureks toetamise alaks ning alati võib midagi sellest katki minna.

Seetõttu oleme programmist saadud kasulikke funktsioone asendanud erinevate raamistikudega, kuna raamistikud PHP-le on piisavalt erinevad, neil on erinevad võimalused, erinevad kogukonnad, erinev tugi. Ja saab kirjutada teenuse nii, et teil on juba midagi selle jaoks olemas.

Igal teenusel on oma meeskond

Meie peamine pluss, mis on välja kristalliseerunud mitme aasta jooksul, on see, et igal teenusel on oma meeskond. See on mugav suure projekti jaoks, saab aega säästa dokumentatsiooni pealt, juhid tunnevad oma projekti hästi.

Tugitegevustest saab ülesandeid suurepäraselt edasi anda. Näiteks, kui kindlustusteenus on katki. Ja kohe läheb kindlustusega tegelev meeskond seda parandama.

Uute funktsioonide lisamine toimub kiiresti, sest kui teil on üks teatud aatomaarne teenus, siis saab sellesse operatiivselt midagi sisse panna.

Ja kui olete oma teenuse katki teinud, mis on paratamatult leiduv, siis te ei puutu teiste teenustega kokku, ja teie juurde ei tule arendajad teiste meeskondadest kiivritega ning ei ütle: "Oi-oi, ärge nii tehke."

Nagu alati, on nüansid. Meil on stabiilsed meeskonnad, juhid on meeskonnaga tugevalt seotud. On selged dokumendid, juhid jälgivad seda hoolikalt. Igal meeskonnal on juhiga mitu teenust ja on konkreetne kompetentsipunkt.

Kui meeskonnad on liikuvad (sellist praktikat kasutame vahel), on olemas hea meetod, mida nimetatakse "tähtedekaardiks".

Teie käes on teenuste ja inimeste nimekiri. Täht tähistab, et inimene on selle teenuse ekspert, raamat tähistab, et inimene õpib seda teenust. Inimese ülesanne on vahetada raamat tähtede vastu. Ja kui teenuse vastas ei ole midagi kirjutatud, siis algavad probleemid, millest ma edaspidi räägin.

Kuidas tekivad orvuteenused?

Esimene probleem, esimene viis, kuidas saada endale infrastruktuuri teenusesoht — see on inimeste vallandamine. Kas kellegil on olnud, et äri toob tähtaegu enne, kui ülesandeid hinnatakse? Mõnikord on tähtaegadega kitsas ja dokumentatsiooni jaoks ei jätku aega. "Peame teenuse tootmisse andma, pärast kirjutame juurde."

Kui meeskond on väike, võib olla, et seal on üks arendaja, kes kirjutab kõik, teised on abiks. "Ma kirjutasin põhistruktuuri, sina tee kasutajaliidese ülesanded." Siis mingil hetkel, näiteks, lahkub juht. Ja sellel perioodil, kui juht on lahkunud ja uut pole veel nimetatud, otsustavad arendajad ise, kuhu teenus liigub, mis seal toimub. Ja nagu me teame (naaseme mõne slaidi tagasi), on mõnedes meeskondades inimesi-lumehelbeid, mõnikord lumehelbeke-peakorter. Siis lahkub ta, ja me saame teenusesohtu.

Samas ei kao toe ja äriülesanded kuhugi, need jäävad tagavarasse. Kui teenuse arendamise käigus on olnud mingisuguseid arhitektuurilisi vigu, siis needki jäävad tagavarasse. Teenus aeglaselt laguneb.

Kuidas ära tunda teenusesaadet?

See nimekiri kirjeldab olukorda üsna hästi. Kes on oma infrastruktuuris midagi sarnast kogenud?

Dokumenteeritud töölahenduste kohta: on teenus ja üldiselt töötab see, tal on kaks lehekülge käsiraamatut, kuidas sellega töötada, kuid kuidas see seestpoolt töötab, ei tea keegi.

Või näiteks on olemas mõni lingikokkuvõtja. Meil on näiteks praegu käimas kolm lingikokkuvõtjat erinevate eesmärkide jaoks erinevates teenustes. See on just selliste tagajärgede tulemus.

Nüüd hakkan ma olema ilmne kapten. Mida on vaja ette võtta? Esiteks tuleb teenus edastada teisele juhile, teisele meeskonnale. Kui teie peakorter pole veel lahkunud, siis sellesse teise meeskonda, kui te mõistate, et teenus sarnaneb orvule, tuleb kaasata keegi, kes sellest vähemalt midagi teab.

Peamine asi: teil peavad olema kirja pandud verega protseduurid üleminekuks. Meie puhul jälgin ma tavaliselt seda, sest mul on oluline, et see kõik töötaks. Juhtidele on oluline, et see oleks kiiresti üle antud, mis sellega pärast juhtub, ei ole neile enam nii tähtis.

Järgmine viis teha orbudest — "Teeme ära allhanke kaudu, nii on kiiremini, ja siis anname meeskonnale edasi". On selge, et kõigil on oma plaanid meeskonnas ning järjekord. Tihti arvab äriklient, et allhanke tegijad saavad seda teha sama hästi, kui tehnikainstituudis, mis on ettevõttes olemas. Kuigi nende motivaatorid on erinevad. Allhankes võivad olla kummalised tehnoloogilised lahendused ja kummalised algoritmilised lahendused.

Meil näiteks oli teenus, kus Sphinx oli erinevates ootamatutes kohtades. Räägin hiljem, mida tuli teha.

Allhankijatel on sageli isetegemise raamistikud. See on lihtsalt puhas PHP koos varasemast projektist kopeeritud koodiga, kust võib leida igasugu asju. Suured toetused deploy-skriptides, kui peate keeruliste Bash-skriptide abil mingites failides mõnda rida muutma, samas kui need deploy-skriptid kutsuvad mingit kolmandat skripti. Lõpuks muudate deploy-süsteemi, valite midagi muud, ja äkki ei tööta teie teenus. Sest seal pidi olema veel 8 linki erinevate kaustade vahel. Või juhtub, et tuhat kirjeid töötab, aga sada tuhat enam mitte.

Jätkan kaptenina. Teenuse vastuvõtt allhankest — see on kohustuslik protseduur. Kas kellelgi on olnud nii, et teenus allhankest tuleb, aga seda ei võeta vastu? See ei ole kindlasti nii populaarne kui orbu teenus, kuid siiski.

Teenust tuleb kontrollida, teenust tuleb üle vaadata, tuleb vahetada paroole. Meil oli juhtum, kui meile anti teenus, kus administraatori leht oli "if login == 'admin' && password == 'admin'…", otse koodis kirjutatud. Istume ja mõtleme, et kas inimesed kirjutavad seda 2018. aastal?

Salvestusmahud tuleb testida — see on samuti vajalik asi. Tuleb vaadata, mis juhtub sajande tuhandes kirjes, veel enne kui te selle teenuse kuskile tootmisesse panete.

Teenuse edasilükkamine ei tohiks olla piinlik. Kui te ütlete: "Me ei võta seda teenust vastu, meil on 20 ülesannet, tehke need ära, siis võtame vastu", on see normaalne. Südametunnistus ei tohiks olla haige selle pärast, et panete juhtiva kohaliku haldaja või et äri kulutab raha. Äri kulutab hiljem rohkem.

Meil oli juhtum, kui me otsustasime teha pilootprojekti allhanke kaudu.

See oli õigeaegselt valmis, ja see oli ainus kvaliteedinäitaja. Seetõttu tehti veel üks prototüüp, juba mitte enam päris prototüüp. Need teenused võeti vastu, administratiivselt öeldi, et siin on teie kood, siin on teie meeskond, siin on teie juht. Teenused hakkasid tõeliselt tulu tooma. Samas on nad endiselt orvud, keegi ei saa aru, kuidas nad töötavad, ja juhid püüavad igati nende ülesannetest distantseeruda.

On veel üks suurepärane mõiste — partisanide arendamine. Kui mingi osakond, tavaliselt turundusosakond, soovib hüpoteesi testida ja tellib teenuse täielikult välistootjalt. Sellele hakkab liikuma liiklus, nad vormistavad dokumendid, allkirjastavad lepingud allhankijaga, tulevad tööle ja ütlevad: "Meil on siin teenus, millel on juba liiklus, see toob meile raha, võtame selle vastu." Meie oleme: "Oota, kuidas see nii on?"

Ja veel üks viis orvuteenuse saamiseks: kui mingi meeskond äkitselt koormatud, ütleb juhtkond: "Kandke selle meeskonna teenus teisele meeskonnale, kellel on vähem koormust." Ja siis kandke kolmandasse meeskonda ja vahetage managerit. Ja lõpuks on meil taas orvuteenused.

Mis on probleem orvudega?

Kes ei tea, see on Rootsis laevaks ehitatud Wasa, kuulus selle poolest, et see hävis 5 minutit pärast vette laskmist. Ja Rootsi kuningas ei karistanud kedagi. See ehitati kahe insenerigeneratsiooni poolt, kes ei osanud selliseid laevu ehitada. Ahnusest tulenev efekt.

Laev oleks võinud tegelikult palju halvemini uppuda, näiteks kui kuningas oleks juba tormi läinud. Nii et, see uppus kohe, agiilsuse seisukohalt on see hea — ebaõnnestuda varakult.

Kui me ebaõnnestusime varakult, siis tavaliselt probleeme ei ole. Näiteks, vastuvõtu ajal saadeti tootmisse viimiseks. Aga kui me ebaõnnestusime juba tootmises, kui raha on investeeritud, siis võivad probleemid tekkida. Tagajärjed, nagu äris öeldakse.

Miks on orvuteenused ohtlikud:

• Teenused võivad äkki katki minna.
• Teenuse parandamine võtab kaua aega või ei parandata üldse.
• Turvaprobleemid.
• Probleemid täienduste ja uuendustega.
• Kui oluline teenus katki läheb, kannatab ettevõtte maine.

Mida teha orvuteenustega?

Kordan ütlen, mida teha. Esiteks, peab olema dokumentatsioon. 7 aastat Banki.ru-s õpetas mind, et testijad ei tohiks arendajatesse pimesi uskuda ja kasutus ei tohiks uskuda kõiki. Tuleb kontrollida.

Teiseks, tuleb kirjutada suhtlemisskeeme, kuna on juhtumeid, kui teenused, mis pole väga hästi vastu võetud, sisaldavad sõltuvusi, millest keegi pole rääkinud. Näiteks, kui arendajad on teenuse seadnud oma võtme kaudu Yandex. Kaardile või Dadata. Kui tasuta limiit lõpeb, kõik laguneb ja sa ei tea, mis juhtus. Kõik sellised komistuskivid peavad olema kirjeldatud: teenuses kasutatakse Dadata, Sms jne.

Kolmandaks, töö tehnilise võlga. Kui teete mingisuguseid kiiruslahendusi või võtate teenuse ja ütlete, et midagi tuleb teha, tuleb jälgida, et seda ka teostataks. Sest hiljem võib selguda, et väike auk pole nii väike ja sa kukud sinna sisse.

Arhitektuuriliste ülesannetega oli meil lugu Sphinxiga. Ühes teenuses kasutati Sphinxit nimekirjade sisestamiseks. Lihtsalt nimekiri lehekülgede kaupa, kuid sellegipoolest indekseeriti see iga öö. See koosnes kahest indeksist: üks indeks oli suures mahus ja see indekseeriti igal ööl, ja oli veel väike indeks, mis sellele külge asetati. Igal päeval, 50% tõenäosusega kas plahvatab või mitte, indekseerimise ajal purunes indeks ning uudised ei värskendunud meie esilehel. Alguses oli see 5 minutit, kuni indeks uuesti indekseeriti, siis kasvas indeks ning mingi hetkel hakkas see indekseerima 40 minutit. Kui me selle välja lõikasime, hingasime kergendatult, sest oli selge, et möödub veel natuke aega ja meie indeks hakkab igapäevaselt kogu tööpäeva jooksul indekseerima. See oleks meie portaali jaoks ebaõnnestumine, kaheksa tundi ilma uudisteta - kõik, äri seiskus.

Tööplaan orvuteenusele

Tegelikult on see väga raske, kuna DevOps tähendab suhtlemist. Tahaks olla oma kolleegidega heades suhetes, kuid kui sa lööd kolleegide ja juhtide pea reglamentidega, võivad nad tunda vastuolulisi tundeid inimeste suhtes, kes nii teevad.

Lisaks nendele punktidele on veel üks oluline asi: iga konkreetse teenuse, iga konkreetse juurdepääsuprotseduuri eest peavad vastutama spetsiifilised inimesed. Kui inimesi ei ole ja tuleb kaasata teisi, kes peavad kõik seda õppima, siis muutub see keeruliseks.

Kui see kõik ei aidanud ja orvuteenuse kinnitamisest ei pääse, keegi ei soovi seda enda kätte võtta, dokumentatsiooni ei kirjutata, meeskond, keda sellele teenusele kutsuti, keelab midagi teha, on lihtne lahendus - kõik teha uuesti.

See tähendab, et võtate teenuse nõudmised uuesti ja kirjutate uue teenuse, mis on parem, paremal platvormil, ilma kummaliste tehniliste lahendusteta. Ja migreerite selle sõda käies.

Meil oli olukord, kui võtsime teenuse Yii 1 pealt ja mõistsime, et ei saa seda enam edasi arendada, kuna meil ei olnud rohkem arendajaid, kes oskasid Yii 1 süvitsi kirjutada. Kõik arendajad oskavad hästi kirjutada kolmandal Symfony-l. Mida teha? Määrasime aega, meeskonna ja manageri, ümberkirjutasime projekti ja sujuvalt suunatud liiklus sellele.

Pärast seda saab vana teenuse kustutada. See on minu lemmikprotseduur, kui süsteemi halduskonfiguratsioonide hulgast tuleb eemaldada mingi teenus ja seejärel vaadata, et kõik tootmisseadmed oleksid välja lülitatud, et arendajatele ei jääks mingeid jälgi. Repositoorium Git-is jääb alles.

See on kõik, millest soovisin rääkida, olen valmis arutama, teema on vaidluslik, paljudele on see tuttav.

Esitluste slaididel räägiti ühtsustamisest keele osas. Näiteks tuuakse välja piltide suuruse muutmine. Kas tõepoolest on vajalik minna rangelt ühte keelde? Sest pildi suuruse muutmine PHP-s, noh, seda oleks võinud tõesti teha ka Golangis.

Tegelikult ei ole see hädavajalik, nagu kõik praktikad. Mõnes olukorras võib see isegi olla soovimatu. Kuid on oluline mõista, et kui teie ettevõttes on 50 inimese suurune tehniline osakond, neist 45 PHP arendajad, veel 3 DevOps'i insenerid, kes valdavad Pythonit, Ansible'i, Puppetit ja midagi sellist, ja ainult üks neist kirjutab mõnes Go keeles pildiresiiseerimise teenuse, siis kui ta lahkub, lahkub ka ekspertteave koos temaga. Ja teil tuleb otsida turul spetsiifilist arendajat, kes teab seda keelt, eriti kui see on haruldane. See tähendab, et organisatsiooni tasandil on see probleemne. DevOps'i vaatenurgast vajate mitte lihtsalt valmis mängurežiimide komplekti kloonimist, mille abil teenuseid üles seada, vaid peate need uuesti kirjutama.

Me töötame praegu teenuse kallal Node.js-is ja see tuleb justkui platvormiks igale arendajale eraldi keeles. Kuid me istusime ja mõtlesime, et mäng on seda väärt. See on küsimus, mille üle tasub natuke mõelda.

Kuidas te jälgite oma teenuseid? Kuidas kogute ja jälgite logisid?

Kogume logisid Elasticsearchis ja salvestame need Kibanas, sõltuvalt sellest, kas tegemist on tootmis- või testkeskkondadega, kasutame erinevaid kogujad. Kusagil on Lumberjack, kusagil veel midagi, ma ei mäleta enam. Ja on veel mõnes teenuses teatud kohad, kus paigaldame Telegrafi ja saadame selle veel kuhugi eraldi.

Kuidas elada Puppet ja Ansible sama keskkonna sees?

Tegelikult on meil praegu kaks keskkonda, üks on Puppet ja teine Ansible. Töötame selle nimel, et neid hübriidida. Ansible on hea keskkond algselt seadistamiseks, Puppet on halb algse seadistamise jaoks, kuna nõuab otsest käsitööde tegemist keskkonnas, ja Puppet tagab konfiguratsiooni kooskõla. See tähendab, et keskkond toetab ennast pidevalt kursis, kuid et Ansible'iga masin püsiks kursis, tuleb seal regulaarselt mängurežiime teostada. See on selline erinevus.

Kuidas te säilitatega ühilduvust? Kas teil on konfiguratsioone nii Ansible'is kui Puppetis?

See on meie suur probleem, me toetame ühilduvust käsitsi ja mõtleme, kuidas sellest kõigest kuhugi edasi liikuda. Meie puhul võib Puppet paigaldada pakette ja toetada seal mingeid linke, samas kui Ansible näiteks paigaldab koodi ja kohandab sinna värskeid rakenduste конфигурации.

Esitluses räägiti erinevatest Ruby versioonidest. Milline lahendus?

Me kohtusime sellega ühes kohas ja peame seda pidevalt meeles pidama. Lihtsalt keerasime välja osa, mis töötas Ruby versioonil, mis ei olnud rakendustega ühilduv, ja hoidsime selle eraldi.

Sel aastal toimub konverents DevOpsDays Moskvasse 7. detsembril «Tehnopolis». Me võtame ettekandeteemade ettepanekuid vastu kuni 11. novembrini. Kirjutage meile, kui soovite esineda.

Osalejate registreerimine on avatud, liituge!

Allikas: habr.com