Portaali Banki.ru operatsioonide direktor Andrei Nikolsky esines möödunud aasta konverentsil orbteenuste kohta: kuidas tuvastada taristu orb, miks orbteenused on halvad, mida nendega teha ja mida teha, kui miski ei aita.
Lõike all on aruande tekstiversioon.
Tere kolleegid! Minu nimi on Andrey, ma juhin operatsioone saidil Banki.ru.
Meil on suured teenused, need on sellised monoliitsed teenused, on teenuseid klassikalisemas mõttes ja on väga väikseid. Oma töölise-talupoja terminoloogias ütlen, et kui teenus on lihtne ja väike, siis on see mikro, ja kui see pole väga lihtne ja väike, siis on see lihtsalt teenus.
Teenuste plussid
Tutvustan kiiresti teenuste eeliseid.
Esimene on skaleerimine. Teenuses saate kiiresti midagi ette võtta ja tootmist alustada. Olete saanud liiklust, olete teenuse klooninud. Teil on rohkem liiklust, olete selle klooninud ja elate sellega kaasa. See on hea boonus ja põhimõtteliselt peeti alustades meie jaoks kõige olulisemaks, miks me seda kõike teeme.
Teiseks isoleeritud arendus, kui sul on mitu arendusmeeskonda, igas meeskonnas mitu erinevat arendajat ja iga meeskond arendab oma teenust.
Meeskondadega on nüanss. Arendajad on erinevad. Ja seal on näiteks . Esimest korda nägin seda Maxim Dorofejeviga. Mõnikord on lumehelbeinimesed mõnes meeskonnas, teistes mitte. See muudab ettevõttes kasutatavad erinevad teenused pisut ebaühtlaseks.
Vaata pilti: see on hea arendaja, tal on suured käed, ta suudab palju. Peamine probleem on selles, kust need käed tulevad.
Teenused võimaldavad kasutada erinevaid programmeerimiskeeli, mis on erinevate ülesannete jaoks sobivamad. Mõni teenus on Go-s, mõni Erlangis, mõni Ruby-s, midagi PHP-s, midagi Pythonis. Üldiselt saab väga laialt laieneda. Siin on ka nüansse.
Teenusele orienteeritud arhitektuur on peamiselt seotud devopidega. See tähendab, et kui teil pole automatiseerimist, pole juurutusprotsessi, kui konfigureerite selle käsitsi, võivad teie konfiguratsioonid teenuse eksemplariti muutuda ja peate sinna minema, et midagi teha, siis olete põrgus.
Näiteks on teil 20 teenust ja peate juurutama käsitsi, teil on 20 konsooli ja vajutate samaaegselt sisestusklahvi nagu ninja. See ei ole väga hea.
Kui teil on pärast testimist teenus (kui testimine on muidugi olemas) ja peate selle siiski failiga lõpetama, et see tootmises töötaks, on mul teile ka halbu uudiseid.
Kui loodate konkreetsetele Amazoni teenustele ja töötate Venemaal, siis kaks kuud tagasi oli teil ka "Kõik ümberringi põleb, mul läheb hästi, kõik on lahe."
Kasutame juurutamise automatiseerimiseks Ansiblet, lähenemiseks Puppetit, juurutamise automatiseerimiseks Bamboot ja selle kõige kirjeldamiseks Confluence'i.
Ma ei peatu sellel üksikasjalikult, sest aruanne käsitleb rohkem suhtlemispraktikaid, mitte tehnilist rakendamist.
Näiteks on meil probleeme olnud sellega, et Puppet serveris töötab Ruby 2-ga, kuid mõni rakendus on kirjutatud Ruby 1.8 jaoks ja need ei tööta koos. Midagi läheb seal valesti. Ja kui teil on vaja ühes masinas käivitada mitu Ruby versiooni, tekivad tavaliselt probleemid.
Näiteks anname igale arendajale platvormi, millel on ligikaudu kõik, mis meil on, kõik teenused, mida saab arendada, et tal oleks isoleeritud keskkond, ta saaks selle lõhkuda ja ehitada nii, nagu tahab.
Juhtub, et seal on vaja mõnda spetsiaalselt koostatud paketti koos toega. See on üsna karm. Kuulasin aruannet, kus Dockeri pilt kaalub 45 GB. Linuxis on see muidugi lihtsam, seal on kõik väiksem, kuid siiski jääb ruumi väheks.
Noh, on vastuolulisi sõltuvusi, kui projekti üks osa sõltub ühe versiooni teegist, teine projekti osa sõltub teisest versioonist ja teeke ei installita üldse koos.
Meil on PHP 5.6 saidid ja teenused, meil on nende pärast häbi, aga mida teha? See on meie üks sait. PHP 7-s on saite ja teenuseid, neid on rohkem, me ei häbene neid. Ja igal arendajal on oma baas, kus ta rõõmsalt saagib.
Kui kirjutada ettevõttes ühes keeles, siis kolm virtuaalmasinat arendaja kohta kõlab normaalselt. Kui teil on erinevad programmeerimiskeeled, läheb olukord hullemaks.
Teil on saidid ja teenused selle kohta, sellel, siis veel üks sait Go jaoks, üks sait Ruby jaoks ja mõned teised Redis. Selle tulemusena muutub see kõik suureks tugiväljaks ja kogu aeg võib osa sellest puruneda.
Seetõttu asendasime programmeerimiskeele eelised erinevate raamistike kasutamisega, kuna PHP raamistikud on üsna erinevad, neil on erinevad võimalused, erinevad kogukonnad ja erinev tugi. Ja saate kirjutada teenuse nii, et teil on selle jaoks juba midagi valmis.
Igal teenusel on oma meeskond
Meie peamine eelis, mis on mitme aasta jooksul kristalliseerunud, on see, et igal teenusel on oma meeskond. See on mugav suure projekti jaoks, saate säästa aega dokumenteerimisel, juhid tunnevad oma projekti hästi.
Saate hõlpsalt tugiteenusest ülesandeid esitada. Näiteks kindlustusteenus läks katki. Ja kohe läheb kindlustusega tegelev meeskond seda parandama.
Uusi funktsioone luuakse kiiresti, sest kui sul on üks aatomiteenus, saad sinna kiiresti midagi sisse keerata.
Ja kui rikute oma teenust ja see paratamatult juhtub, ei mõjuta te teiste inimeste teenuseid ja teiste meeskondade arendajad ei jookse teie juurde ja ei ütle: "Ai-ei, ärge seda tehke."
Nagu alati, on nüansse. Meil on stabiilsed meeskonnad, juhid on meeskonna külge naelutatud. Seal on selged dokumendid, juhid jälgivad kõike hoolikalt. Igal juhiga meeskonnal on mitu teenust ja olemas on konkreetne pädevuspunkt.
Kui meeskonnad ujuvad (seda kasutame ka mõnikord), on olemas hea meetod, mida nimetatakse "tähekaardiks".
Teil on teenuste ja inimeste loend. Tärn tähendab, et inimene on selle teenuse ekspert, raamat tähendab, et inimene õpib seda teenust. Inimese ülesanne on muuta brošüür tärni vastu. Ja kui teenuse ees pole midagi kirjutatud, siis algavad probleemid, millest räägin edasi.
Kuidas orbteenused ilmuvad?
Esimene probleem, esimene viis orbteenuse saamiseks oma infrastruktuuris on inimeste vallandamine. Kas keegi on kunagi pidanud ettevõttel tähtaegu enne ülesannete hindamist kinni? Vahel juhtub, et tähtajad on kitsad ja dokumenteerimiseks lihtsalt ei jätku aega. "Peame teenuse tootmisele üle andma, siis lisame selle."
Kui tiim on väike, siis juhtub, et on üks arendaja, kes kõik kirjutab, ülejäänud on tiibadesse. "Ma kirjutasin põhiarhitektuuri, lisame liidesed." Siis mingil hetkel lahkub näiteks juht. Ja sel perioodil, kui juht on lahkunud ja uut pole veel määratud, otsustavad arendajad ise, kuhu teenus läheb ja mis seal toimub. Ja nagu me teame (läheme paar slaidi tagasi), on mõnes meeskonnas lumehelbekesi, vahel lumehelbemeeskonna juht. Siis ta loobub ja me saame orbteenuse.
Samas ei kao tugi- ja äriülesanded kuhugi, need jäävad mahajäämusse. Kui teenuse arendamisel esines arhitektuurseid vigu, jäävad need samuti mahajäämusse. Teenus halveneb aeglaselt.
Kuidas orvu tuvastada?
See nimekiri kirjeldab olukorda hästi. Kes õppis midagi oma infrastruktuuri kohta?
Dokumenteeritud lahenduste kohta: teenus on olemas ja üldiselt see töötab, kaheleheküljeline käsiraamat, kuidas sellega töötada, aga keegi ei tea, kuidas see sees töötab.
Või on näiteks mingi linkide lühendamine. Näiteks on meil praegu erinevates teenustes erinevatel eesmärkidel kasutusel kolm lingi lühendajat. Need on vaid tagajärjed.
Nüüd olen ma ilmselgete asjade kapten. Mida tuleks teha? Esiteks peame teenuse üle andma teisele juhile, teisele meeskonnale. Kui teie meeskonna juht pole veel lahkunud, peate sellesse teise meeskonda, kui saate aru, et teenus on nagu orb, kaasama kellegi, kes sellest vähemalt midagi aru saab.
Peaasi: üleviimise protseduurid peavad olema verega kirjutatud. Meie puhul ma tavaliselt jälgin seda, sest mul on seda kõike vaja, et see toimiks. Juhtidel on vaja, et see saaks kiiresti kätte ja see, mis sellest hiljem saab, pole nende jaoks enam nii oluline.
Järgmine võimalus orvuks teha on "Teeme seda sisseostetuna, see on kiirem ja siis anname selle meeskonnale üle." Selge see, et kõigil on meeskonnas mingid plaanid, pööre. Tihti arvab äriklient, et allhanke tellija teeb sama, mis ettevõtte tehniline osakond. Kuigi nende motivaatorid on erinevad. Allhankes on kummalised tehnoloogilised lahendused ja kummalised algoritmilised lahendused.
Näiteks oli meil teenus, kus oli Sfinksi erinevates ootamatutes kohtades. Ma räägin teile hiljem, mida ma tegema pidin.
Allhankijatel on ise kirjutatud raamistikud. See on lihtsalt paljas PHP koos copy-paste-ga eelmisest projektist, kust võib leida igasuguseid asju. Juurutusskriptid on suur puudus, kui peate mõne faili mitme rea muutmiseks kasutama keerulisi Bashi skripte ja neid juurutusskripte kutsub välja mõni kolmas skript. Selle tulemusena muudate juurutussüsteemi, valite midagi muud, hüppate, kuid teie teenus ei tööta. Sest seal oli vaja veel 8 linki erinevate kaustade vahele panna. Või juhtub nii, et tuhat plaati töötab, aga sada tuhat enam ei tööta.
Jätkan kaptenina. Allhanketeenuse vastuvõtmine on kohustuslik protseduur. Kas kellelgi on kunagi tulnud välisteenust ja teda pole kuskil vastu võetud? See pole muidugi nii populaarne kui orbteenus, kuid siiski.
Teenust tuleb kontrollida, teenus üle vaadata, paroolid vahetada. Meil oli juhtum, kui nad pakkusid meile teenust, seal on administraatori paneel "if login == 'admin' && password == 'admin'...", see on otse koodis kirjas. Istume ja mõtleme ning inimesed kirjutavad seda 2018. aastal?
Ka mälumahu testimine on vajalik asi. Peate vaatama, mis saja tuhande plaadi pealt juhtuma hakkab, isegi enne, kui selle teenuse kuskile tootmisse panete.
Ei tohiks olla häbi saata teenus täiustamiseks. Kui ütlete: "Me ei võta seda teenust vastu, meil on 20 ülesannet, tehke need ära, siis me aktsepteerime," on see normaalne. Teie südametunnistus ei tohiks haiget teha sellest, et asute juhtima või et äri raiskab raha. Ettevõte kulutab siis rohkem.
Meil oli juhtum, kui otsustasime pilootprojekti väljast tellida.
See tarniti õigel ajal ja see oli ainus kvaliteedikriteerium. Seetõttu tegime teise pilootprojekti, mis polnud enam isegi piloot. Need teenused võeti vastu ja nad ütlesid administratiivselt: siin on teie kood, siin on meeskond, siin on teie juht. Teenused on tegelikult juba hakanud kasumit tootma. Samas on nad tegelikult ikkagi orvud, keegi ei saa aru, kuidas nad töötavad, ja juhid annavad endast parima, et oma ülesannetest lahti öelda.
On veel üks suurepärane kontseptsioon – geriljaarendus. Kui mõni osakond, tavaliselt turundusosakond, soovib hüpoteesi testida ja tellib kogu teenuse allhanke korras. Liiklus hakkab sinna sisse voolama, pannakse dokumendid kinni, sõlmitakse töövõtjaga dokumente, asutakse tööle ja öeldakse: "Kutsid, meil on siin teenus, sellel juba on liiklus, see toob meile raha, võtame vastu." Me ütlesime: "Oppa, kuidas see saab olla."
Ja veel üks võimalus orbteenuse saamiseks: kui mõni meeskond on ootamatult koormatud, ütleb juht: "Viime selle meeskonna teenuse üle teisele meeskonnale, sellel on väiksem koormus." Ja siis anname selle üle kolmandale meeskonnale ja vahetame juhti. Ja lõpuks on meil jälle orb.
Mis on orbude probleem?
Kes veel ei tea, siis see on Rootsis üles ehitatud lahingulaev Wasa, mis on kuulus selle poolest, et uppus 5 minutit pärast vettelaskmist. Ja muide, Rootsi kuningas ei hukkanud selle eest kedagi. Selle ehitasid kaks põlvkonda insenere, kes ei teadnud, kuidas selliseid laevu ehitada. Loomulik efekt.
Laev oleks võinud uppuda, muide, palju hullemalgi moel, näiteks siis, kui kuningas sellel juba kuskil tormis sõitis. Ja nii ta uppus kohe, Agile’i sõnul on hea varakult läbi kukkuda.
Kui ebaõnnestume varakult, pole tavaliselt probleeme. Näiteks saadeti see vastuvõtmise ajal ülevaatamiseks. Aga kui me ebaõnnestume juba tootmises, kui raha investeeritakse, siis võib probleeme tekkida. Tagajärjed, nagu neid äris nimetatakse.
Miks orbteenused on ohtlikud:
- Teenus võib ootamatult katkeda.
- Teeninduse parandamine võtab kaua aega või seda ei remondita üldse.
- Ohutusprobleemid.
- Probleemid täiustuste ja värskendustega.
- Kui mõni oluline teenus katki läheb, kannatab ettevõtte maine.
Mida teha orbteenustega?
Kordan veel kord, mida teha. Esiteks peab olema dokumentatsioon. 7 aastat Banki.ru-s õpetas mulle, et testijad ei tohiks võtta arendajate sõna ja toimingud ei tohiks võtta kõigi sõna. Peame kontrollima.
Teiseks on vaja koostada interaktsiooniskeemid, sest juhtub, et vähe vastuvõetud teenused sisaldavad sõltuvusi, mille kohta keegi ei öelnud. Näiteks installisid arendajad selle teenuse mõne Yandex.Mapsi või Dadata võtmele. Teil on vaba limiit otsa saanud, kõik on katki ja te ei tea üldse, mis juhtus. Kõik sellised rehad tuleb kirjeldada: teenus kasutab Dadata, SMS-i, midagi muud.
Kolmandaks tehniliste võlgadega töötamine. Kui teete karkusid või võtate teenuse vastu ja ütlete, et midagi on vaja teha, peate veenduma, et see on tehtud. Sest siis võib selguda, et see väike auk polegi nii väike ja sa kukud sealt läbi.
Arhitektuuriülesannetega oli meil lugu Sfinksist. Üks teenustest kasutas loendite sisestamiseks Sphinxi. Lihtsalt lehekülgede loetelu, kuid see indekseeriti igal õhtul uuesti. See oli kokku pandud kahest indeksist: igal õhtul indekseeriti üks suur ja sinna külge kruviti ka väike indeks. Iga päev, 50% tõenäosusega, kas pommitamine või mitte, jooksis indeks arvutamise ajal kokku ja meie uudiste uuendamine avalehel lakkas. Algul kulus indeksi uuesti indekseerimiseks 5 minutit, siis indeks kasvas ja mingil hetkel hakkas uuesti indekseerimiseks kuluma 40 minutit. Seda välja lõigates hingasime kergendatult, sest oli selge, et läheb veel veidi aega ja meie indeks indekseeritakse täiskohaga uuesti. See on meie portaali jaoks ebaõnnestumine, kaheksa tundi pole uudiseid - see on kõik, äri on peatunud.
Plaan töötada orbteenusega
Tegelikult on seda väga raske teha, sest devops on suhtlemine. Tahad olla oma kolleegidega heades suhetes ning kui lööd oma kolleegidele ja juhtidele määrustega üle pea, võivad neil tekkida vastakad tunded nende inimeste vastu, kes seda teevad.
Lisaks kõikidele nendele punktidele on veel üks oluline asi: iga konkreetse teenuse, iga konkreetse juurutusprotseduuri lõigu eest peavad vastutama konkreetsed inimesed. Kui inimesi pole ja sa pead tõmbama ligi teisi inimesi, siis kogu selle asja uurimine muutub keeruliseks.
Kui see kõik ei aidanud ja teie orbteenus on endiselt orb, ei taha keegi seda endale võtta, dokumente pole kirjutatud, sellesse teenusesse kutsutud meeskond keeldub midagi tegemast, on lihtne viis - uuesti teha kõike .
See tähendab, et võtad uuesti teenuse nõuded ja kirjutad uue teenuse, paremini, paremal platvormil, ilma kummaliste tehnoloogiliste lahendusteta. Ja te rändate selle juurde lahingus.
Meil oli olukord, kui võtsime Yii 1-l teenuse ja mõistsime, et me ei saa seda edasi arendada, sest meil said otsa arendajad, kes oskaksid Yii 1-l hästi kirjutada. Kõik arendajad kirjutavad Symfony XNUMX-s hästi. Mida teha? Jagasime aega, määrasime meeskonna, määrasime juhi, kirjutasime projekti ümber ja lülitasime sujuvalt liikluse sellele.
Pärast seda saab vana teenuse kustutada. See on minu lemmikprotseduur, kui on vaja konfiguratsioonihaldussüsteemist võtta ja puhastada mõni teenus ning siis läbi käia ja vaadata, et kõik tootmises olevad autod on blokeeritud, et arendajatele ei jääks jälgi. Hoidla jääb Giti.
See on kõik, millest ma rääkida tahtsin, olen valmis arutama, teemaks on holivar, paljud on sellega ujunud.
Slaididel oli kirjas, et ühendate keeled. Näiteks oli piltide suuruse muutmine. Kas tõesti on vaja seda rangelt ühe keelega piirata? Sest pildi suurust PHP-s saab tegelikult teha ka Golangis.
Tegelikult on see valikuline, nagu kõik tavad. Võib-olla on see mõnel juhul isegi ebasoovitav. Kuid peate mõistma, et kui teil on 50-liikmelises ettevõttes tehniline osakond, neist 45 on PHP spetsialistid, veel 3 on devopid, kes tunnevad Pythonit, Ansiblet, Puppetit ja midagi sellist ning ainult üks neist kirjutab mõnes Mingi Go-kujutise suuruse muutmise teenus, siis kui see lahkub, läheb asjatundlikkus sellega kaasa. Ja samal ajal peate otsima turuspetsiifilist arendajat, kes seda keelt oskab, eriti kui see on haruldane. See tähendab, et organisatsioonilisest vaatenurgast on see problemaatiline. Devopsi vaatenurgast ei pea te lihtsalt kloonima mõnda valmis mänguraamatute komplekti, mida kasutate teenuste juurutamiseks, vaid peate need uuesti kirjutama.
Ehitame praegu Node.js-i teenust ja see on iga arendaja jaoks eraldi keelega lähedal asuv platvorm. Meie aga istusime ja mõtlesime, et mäng on küünalt väärt. See tähendab, et see on küsimus, mille üle peate istuma ja mõtlema.
Kuidas te oma teenuseid jälgite? Kuidas te logisid kogute ja jälgite?
Palke kogume Elasticsearchis ja paneme Kibanasse ning olenevalt sellest, kas tegemist on tootmis- või testkeskkondadega, kasutatakse seal erinevaid kogujaid. Kuskil Lumberjack, kuskil mujal midagi muud, ma ei mäleta. Ja teatud teenustes on ikka mõned kohad, kuhu paigaldame Telegrafi ja pildistame kuskil mujal eraldi.
Kuidas Puppeti ja Ansiblega ühes keskkonnas elada?
Tegelikult on meil nüüd kaks keskkonda, üks on Puppet, teine on Ansible. Töötame nende hübridiseerimise nimel. Ansible on hea raamistik algseadistuse jaoks, Puppet on algseadistuse jaoks halb raamistik, kuna see nõuab praktilist tööd otse platvormil ja Puppet tagab konfiguratsiooni ühtlustamise. See tähendab, et platvorm hoiab end ajakohases olekus ja selleks, et ansibiliseeritud masin oleks kursis, tuleb sellel kogu aeg teatud sagedusega mänguraamatuid käivitada. See on erinevus.
Kuidas säilitate ühilduvuse? Kas teil on konfiguratsioonid nii Ansibles kui ka Puppetis?
See on meie suur valu, hoiame kätega kokkusobivust ja mõtleme, kuidas sellest kõigest nüüd kuskile edasi minna. Selgub, et Puppet rullub välja paketid ja hooldab seal mingeid linke ning näiteks Ansible veeretab koodi välja ja kohandab seal uusimaid rakenduste konfiguratsioone.
Ettekanne rääkis Ruby erinevatest versioonidest. Mis lahendus?
Kohtasime seda ühes kohas ja peame seda kogu aeg oma peas hoidma. Lülitasime lihtsalt välja Ruby peal töötava osa, mis rakendustega kokku ei sobinud, ja hoidsime selle eraldi.
Selle aasta konverents toimub 7. detsembril Technopolises. Aruannete avaldusi võtame vastu kuni 11. novembrini. meile, kui soovite rääkida.
Osalejate registreerimine on avatud, liitu meiega!
Allikas: www.habr.com