Portaali Banki.ru tegevjuht Andrei Nikolskõi rääkis eelmisel aastal toimunud konverentsil orphan teenustest: kuidas tuvastada orvuks jäänud teenuseid infrastruktuuris, millised on orvusteenuste puudused, mida nendega teha ja kuidas käituda, kui miski ei aita.
Allpool on esituse tekstiversioon.
Tere, kolleegid! Minu nimi on Andrei, juhin Banki.ru haldamist.
Meil on suured teenused, need on monoliitsed teenused, on ka teenuseid klassikalisemas mõttes ja on täiesti väikesed. Oma töökeskkonnas nimetan ma neid, et kui teenus on lihtne ja väike, siis on see mikro, ja kui see ei ole väga keeruline ega väike, siis on see lihtsalt teenus.
Teenuste eelised
Käin kiiresti üle teenuste eelistest.
Esiteks – skaleeritavus. Sa saate teenusel kiiresti midagi teha ja käivitada tootmisprotsessis. Kui teil tuleb liiklust, kopeerite teenuse. Kui tuleb veel liiklust, kopeerite veel ja elate selle juurde. See on hea boonus ja põhimõtteliselt, kui me alustasime, peeti seda meie jaoks kõige olulisemaks, miks me üldse seda kõike teeme.
Teiseks, isoleeritud arendus, kus teil on mitu arendusmeeskonda, erinevad arendajad igas meeskonnas, ja iga meeskond loob oma teenust.
Meeskondade puhul on nüansid. Arendajad on erinevad. Näiteks on olemas . Nägin seda esmakordselt Maksim Dorofeevi juures. Mõnikord on lumeinimesi mõnes meeskonnas, mõnes aga mitte. See muudab ettevõttes kasutatavaid erinevaid teenuseid veidi ebaühtlasteks.
Vaadake pilti: see on hea arendaja, kellel on suured käed, ta suudab palju teha. Peamine probleem on, kust need käed kasvavad.
Teenused võimaldavad kasutada erinevaid programmeerimiskeeli, mis sobivad paremini erinevate ülesannete jaoks. Üks teenus on Go-s, teine Erlangis, kolmas Ruby-s, midagi PHP-s, midagi Pythonis. Ühesõnaga, siin on võimalik väga laialdaselt arendada. Siin on samuti nüansse.
Teenusorienteeritud arhitektuur tähendab eelkõige devopsi. Kui teil pole automatiseerimist, pole paigaldusprotsessi ja te seadistate kõik käsitsi, võivad teie konfiguratsioonid erinevate teenuse instantside vahel varieeruda, mistõttu peate sinna minema ja midagi tegema – see on tõeline õudus.
Näiteks, kui teil on 20 teenust ja peate neid käsitsi paigaldama, on teil 20 konsooli, kus peate samaaegselt "enter"-it vajutama nagu ninja. See pole just tõhus.
Kui teie teenus on testimise läbi läinud (kui selline on olemas) ja seda tuleb veel viimase lihvi jaoks kohendada, et see tootmises töötaks, siis pean ka teile halbu uudiseid edastama.
Kui toetute Amazonile spetsiifilistele teenustele ja töötate Venemaal, siis kaks kuud tagasi oli teie jaoks sama olukord: "Kõik põletab ümberringi, mul on kõik hästi, kõik on suurepärane."
Kasutame Ansible'i automatiseerimise jaoks, Puppet'i kooskõla tagamiseks, Bamboo't paigalduse automatiseerimiseks ning Confluence'i, et kõike kuidagi dokumenteerida.
Ma ei hakka sellel süvenema, kuna ettekande keskmes on pigem koostööpraktikad kui tehniline teostus.
Meil on olnud näiteks probleeme, et Puppet serveris töötab Ruby 2, samas kui mõni rakendus on kirjutatud Ruby 1.8 jaoks ja need ei tööta koos. Seal tekib mingi konflikt. Kui peate ühel masinal hoidma mitut Ruby versiooni, siis tekivad tavaliselt probleemid.
Meil, näiteks, anname igale arendajale platvormi, kus on enam-vähem kõik, mis meil on, kõik teenused, mida saab arendada, et tal oleks isoleeritud keskkond, kus ta saaks seda rikkuda ja ehitada nii, nagu ta soovib.
Mõnikord on vaja spetsiaalselt kompileeritud paketti, mis toetab mingit asi. See on piisavalt jäik. Kuulasin ühte ettekannet, kus Docker image kaalub 45 GB. Linuxis on muidugi kergem, seal on kõik väiksem, aga ikkagi, ruumi ei jätku.
No ja on vastuolulisi sõltuvusi, kui ühe projekti osa sõltub ühe versiooni teegist, teine osa aga teisest versioonist, ning teegi koos paigaldamine ei toimi üldse.
Meil on PHP 5.6 põhinevaid saite ja teenuseid, mille üle tunne me piinlikkust, aga mis parata. See on meie üks platvorm. PHP 7 puhul on meil rohkem saite ja teenuseid, mille üle me ei tunne piinlikkust. Igal arendajal on oma väike andmebaas, kus ta rõõmuga töötab.
Kui te suhtlete ettevõttes ühes keeles, siis kolm virtuaalset masinat arendaja kohta kõlab normaalselt. Kui teil on erinevad programmeerimiskeeled, siis olukord halveneb.
Teie juurde tekivad saidid ja teenused selle peal, selle peal, siis veel üks platvorm Go jaoks, üks platvorm Ruby jaoks, ja veel üks Redis kõrvale. Lõpuks muutub see suureks tugiväljakuks, kus midagi võib pidevalt katki minna.
Seetõttu vahetasime programmeerimiskeele pluginaid erinevate raamistikude vastu, kuna PHP raamistikke on piisavalt erinevaid, neil on erinevad võimalused, erinevad kogukonnad, erinev tugi. Ja saate kirjutada teenuse nii, et teil oleks midagi eelnevalt valmis selle jaoks.
Igal teenusel on oma meeskond
Meie peamine eelis, mis on aastate jooksul välja kujunenud, on see, et igal teenusel on oma meeskond. See on mugav suurte projektide jaoks, kuna see aitab kokku hoida aega dokumentatsioonil ja juhtidel on hea ülevaade oma projektist.
Tugiteenuste ülesandeid saab suurepäraselt suunata. Näiteks, kui kindlustusteenus rikki läheb, siis läheb koheselt kindlustuse meeskond seda parandama.
Uute funktsioonide väljatöötamine on kiire, sest kui teil on üks kõikvõimalik teenus, saab sinna kiiresti midagi lisada.
Ja kui teie teenus rikub, mis on vältimatu, ei mõjuta see teisi teenuseid, ja arendajad teiste meeskondade hulgast ei tule teie juurde pahandama ja ütlevad: „Ärge nii tehke.”
Nagu alati, on nüansid. Meil on stabiilsed meeskonnad, juhid on meeskondadega tugevalt seotud. Toad on selged, juhid jälgivad kõike hoolikalt. Igal meeskonnal on manageriga mitmeid teenuseid ning kindel kompetentsipunkt.
Kui meeskonnad on muutlikud (seda juhtub meil vahel), siis on olemas hea meetod, mida nimetatakse „tähtkaart”.
Teie loendis on teenuseid ja inimesi. Täht tähistab, et inimene on selle teenuse ekspert, raamat tähistab, et inimene õpib seda teenust. Inimese ülesanne on vahetada raamat tähtsümboli vastu. Kui teenuse vastas ei ole midagi kirjas, siis tekivad probleemid, millest ma hiljem räägin.
Kuidas tekivad orvuteenused?
Esiteks probleem, esimene viis, kuidas saada oma infrastruktuuris orvuteenuseid — see on inimeste vallandamine. Kas kellelgi on olnud kogemust, kus ärioujast saadetakse tähtaeg enne, kui ülesandeid hinnatakse? Mõnikord on tähtajad range ja dokumentatsiooni jaoks lihtsalt ei jätku aega. 'Teenuse peab tootmisse andma, pärast kirjutame edasi.'
Kui meeskond on väike, võib olla, et seal on üks arendaja, kes kirjutab kogu koodi, teised toimetavad kõrval. «Mina kirjutasin põhistruktuuri, sina tee liidesed». Siis mingil hetkel näiteks juht lahkub. Ja sellel perioodil, mil juht on lahkunud, kuid uut pole veel määratud, otsustavad arendajad ise, kuhu teenus liikuda võiks, mis seal toimub. Ja nagu me teame (naaseme mõned slaidid tagasi), on mõnedes meeskondades inimesi, kes on erilised, mõnikord on see eriline inimene ka tiimijuht. Siis ta lahkub, ja me saame koduta teenuse.
Sellega on aga probleemid ja äriülesanded kuhjunud, nad jäävad tagasiotsingusse. Kui teenuse arendamisel oli mingeid arhitektuurilisi vigu, siis need jäävad samuti tagasiotsingusse. Teenus aeglaselt halveneb.
Kuidas tuvastada kodutute teenuseid?
See nimekiri kirjeldab olukorda hästi. Kes on oma infrastruktuuris midagi sellist kogenud?
Dokumenteeritud lahenduste kohta: teenus eksisteerib ja üldiselt töötab, tal on kahe lehe pikkune juhend, kuidas seda kasutada, kuid kuidas see seestpoolt töötab, ei tea keegi.
Või näiteks, on olemas mõni lingi lühendaja. Meil on näiteks praegu kasutuses kolm lingi lühendajat erinevate eesmärkide jaoks erinevates teenustes. Need on just nimelt tagajärjed.
Nüüd olen ilmselgelt kapten. Mida tuleks ette võtta? Esiteks tuleb teenus üle anda teisele juhile, teisele meeskonnale. Kui teie tiimijuht pole veel lahkunud, siis tuleb sellesse teise meeskonda, kui te mõistate, et teenus on nagu orv, lisada keegi, kes vähemalt midagi sellest mõistab.
Peamine asi: teil peavad olema veretuks kirjutatud üleminekuprotseduurid. Meie puhul jälgin seda tavaliselt mina, sest mul on vaja, et see kõik töötaks. Juhtidele on vaja, et see kiiresti üle antaks, aga mis temaga hiljem juhtub, ei ole neile enam nii oluline.
Järgmine viis orvuks muuta on: "Teeme väliseid allhankeid, nii on kiiremini, ja siis anname selle meeskonda üle." On selge, et kõigil on oma plaanid meeskonnas, järjekord. Sageli arvab äri tellija, et allhankija teeb selle sama moodi nagu ettevõtte tehniline osakond. Kuigi nende motivatsioonid on erinevad. Välises allhangetes võivad olla kummalised tehnilised lahendused ja kummalised algoritmilised lahendused.
Meil oli näiteks teenus, kus Sphinx oli erinevates üllatavates kohtades. Räägin hiljem, mida tuli ette võtta.
Outsourceritel on sageli oma kirjutatud raamistikud. See on lihtsalt puhas PHP, kus on kopeeritud-kleebitud eelmisest projektist, kust võib leida kõike. Suured ämbritõmbed deploy-skriptides, kus peate keeruliste Bash-skriptide abil muutma paar rida mingis failis, samas kui neid deploy-skripte kutsub üles mõni kolmas skript. Lõpuks muudate deploy-süsteemi, valite midagi muud, ja hop, teenus ei tööta. Sest seal pidid olema veel 8 linki erinevate kaustade vahel. Või võib olla, et tuhat kirjet töötab, aga sada tuhat enam ei tööta.
Jätkan kaptaanina. Teenuse vastuvõtt outsoursingust on kohustuslik protseduur. Kas kellegil on olnud, et outsourseeritud teenus jõuab kohale, aga seda ei võeta kuskile vastu? See ei ole muidugi nii populaarne kui orvuks jäänud teenus, aga siiski.
Teenust tuleb kontrollida, teenust tuleb üle vaadata, paroole tuleb vahetada. Meil oli juhtum, kus me saime teenuse, kus administraatoripaneelis oli kirjutatud "if login == 'admin' && password == 'admin'...". Kuidas saavad inimesed sellist asja 2018. aastal kirjutada?
Salvestusmahu testimine on samuti vajalik. Tuleb jälgida, mis juhtub sadade tuhandete kirjetega, enne kui seda teenust tootmisse lähete.
Teenuse täiendamisele saatmine ei tohiks olla häbiväärne. Kui ütlete: "Me ei võta seda teenust vastu, meil on 20 ülesannet, tehke need ära, siis võtame," on see täiesti normaalne. Südametunnistus ei tohi olla häiritud, kui panete juhatajat ohtu või kui äri kulutab raha. Äri kulutab hiljem rohkem.
Meil oli juhtum, kus otsustasime teha pilootprojekti väljavahetamisele.
See projekti lõpetamine toimus õigel ajal, mis oli ainus kvaliteedikriteerium. Seetõttu viidi ellu veel üks pilootprojekt, mis ei olnud enam päris piloot. Need teenused viidi ellu, halduslikult öeldi, et siin on teie kood, siin on teie meeskond, siin on teie juht. Teenused hakkasid reaalselt juba kasumit tootma. Sellegipoolest on nad tõeliselt jätkuvalt orvud, keegi ei saa aru, kuidas nad töötavad, ja juhid eemalduvad igal moel nende ülesannetest.
On veel üks suurepärane mõisted — partisanide arendus. Kui mõni osakond, tavaliselt turundusosakond, soovib testida hüpoteesi ja tellib teenuse täielikult välja. Sellele hakkab voolama liiklus, nad kinnitavad dokumente, allkirjastavad lepingu töövõtjaga, lastakse kasutusse ja ütlevad: „Kaaslased, meil on siin teenus, millel on juba liiklus, see toob meile raha, võtame selle kasutusele.“ Meie oleme sellised: „Oh, kuidas see võimalik on?“
Ja veel üks viis orvuteenuse saamiseks: kui mõni meeskond äkki koormuse alla jääb, ütleb juhtkond: „Kandke teenus selle meeskonna juurde üle teisele meeskonnale, kellel on vähem koormust.“ Ja siis anname kolmandale meeskonnale, ja vahetame juhi ära. Ja lõpuks on meil jälle orvuteenused.
Mis on orvuteenuste probleem?
Kes ei tea, siis see on Rootsis ehitatud lineaarlaev Wasa, tuntud selle poolest, et see uppus viie minuti pärast pärast vee peale laskmist. Ja Rootsi kuningas ei karistanud kedagi selle eest. See ehitati kahe insenerigeneratsiooni poolt, kellel ei olnud selliste laevade ehitamisest aimu. Tulemuseks on seaduspärane efekt.
Laev oleks võinud uppuda palju hullemini, näiteks siis, kui kuningas oleks olnud laeva peal tormis teel kuhugi. Nii et see uppus kohe — agiilse mõtteviisi järgi on see hea — ebaõnnestuda vara.
Kui me ebaõnnestume vara, siis tavaliselt probleeme ei ole. Näiteks, kui aktsepteerimise ajal saadetakse see täiendusele. Aga kui me oleme ebaõnnestunud juba tootmises, kui raha on sisse pandud, võivad tekkida probleemid. Tagajärjed, nagu ärimaailmas öeldakse.
Millised on orvuteenuste ohud:
- Teenuse üllatuslik lõhkemine.
- Teenuse parandamine võtab kaua aega või ei toimu üldse.
- Turvalisuse probleemid.
- Probleemid muudatuste ja uuendustega.
- Kui oluline teenus kokku variseb, kannatab ettevõtte maine.
Kuidas käituda orvuteenustega?
Kordaksin veel kord, mida teha. Esiteks, dokumentatsioon peab olema. 7 aastat Banki.ru's õpetasid mind, et testijad ei tohiks arendajate sõnā usaldada, ja hooldus ei tohiks samuti kõigile uskuda. Tuleb kontrollida.
Teiseks, tuleb kirjutada koostöö skeeme, sest juhtub, et teenused, mis on heaks kiidetud, sisaldavad sõltuvusi, millest keegi ei ole rääkinud. Näiteks arendajad on seadnud teenuse oma võtme kaudu mõne Yandexi kaardi või Dadata juurde. Kui teie tasuta piirang on läbi, kõik on katki ja te ei tea, mis üldse juhtus. Kõik sellised takistused peavad olema kirja pandud: teenuses kasutatakse Dadata, Sms, midagi muud.
Kolmandaks, töö tehnilise võlaga. Kui teete mingeid tugistruktuure või võtate teenuse vastu ja ütlete, et midagi tuleb teha, tuleb jälgida, et seda ka tehakse. Sest hiljem võib selguda, et väike süvend ei ole nii väike, ja te võite sinna sisse kukkuda.
Meie arhitektuuriülesannetega seoses oli meil lugu just Sphinxist. Ühes teenuses kasutati Sphinxit nimekirjade sisestamiseks. Lihtsalt nimekiri lehtede kaupa, kuid samal ajal indekseeris see end iga öö. See koosnes kahest indeksist: üks indeks, mis indekseeris iga öö suure andmehulgaga, ja teine, väiksem indeks, mis sellele lisandus. Igal päeval oli 50% tõenäosus, et kas see toimis või mitte; kui indekseeritav teave laaditi üles, purunes indeks ja uudised lakkasid meie avalehel uuendumast. Alguses kestsid katkestused 5 minutit, kuni indeks uuesti indekseeritud sai, seejärel kasvas indeks ja mingil hetkel hakkas indekseeritav teave võtma 40 minutit. Kui me selle eemaldame, kergendasime hinge, sest oli selge, et veel natuke aega ja meie indeks hakkaks pidevalt tööpäeva jooksul uuenduma. See tähendaks meie portaali jaoks ebaõnnestumist — kaheksa tundi ilma uuteta, kõik, äri seiskub.
Tööplaan üksikteenuse jaoks
Tegelikult on seda väga raske teha, sest DevOps on suhtlemise kohta. Tahetakse hoida häid suhteid kolleegidega, kuid kui sa lööd kolleegid ja juhid regulatsioonidega peas, võivad nad tunda segadust nende inimeste suhtes, kes nii teevad.
Lisaks kõigile neile punktidele on veel üks oluline asi: iga konkreetse teenuse ja iga konkreetse juhi vastutus peab olema määratud kindlate inimeste poolt. Kui inimesi ei ole ja tuleb kaasata teisi inimesi, kes peavad kõik uuesti õppima, läheb see keeruliseks.
Kui see kõik ei aidanud ja teenus on endiselt orvuks jäänud, ei taha keegi seda endale võtta, dokumentatsiooni ei kirjutata, ja meeskond, kes selle teenusega kokku kutsuti, keelduvad midagi tegemast, on lihtne lahendus — kogu see asi tuleb ümber teha.
See tähendab, et võtate teenuse nõudmised uuesti ja kirjutate uue teenuse, parem versioon, paremal platvormil, ilma kummaliste tehniliste lahendusteta. Ja migreerite sellele aktiivselt.
Meil oli olukord, kus kasutasime Yii 1 teenust ja mõistsime, et me ei saa seda edasi arendada, kuna meie arendajad, kes oskavad Yii 1 keeles kirjutada, said otsa. Kõik arendajad kirjutavad hästi kolmandas Symfony's. Mis teha? Eraldasime aega, moodustasime meeskonna, määrasime projektijuhiks inimese, kirjutasime projekti ümber ja sujuvalt suunatud liiklus sellele.
Pärast seda saab vana teenuse eemaldada. See on minu lemmikprotseduur, kui konfigureerimise haldussüsteemist tuleb midagi välja võtta ja puhastada, ning siis käia kontrollimas, et kõik tooteversioonid oleksid kustutatud ja arendajatel ei jääks jälgi. Git'i repositoorium jääb alles.
See on kõik, millest ma tahtsin rääkida, olen valmis arutama, teema on üsna vaieldav, paljud on selles osalenud.
Slide'idel oli juttu sellest, et te ühtlustasite keeled. Näidatud näitena oli piltide suuruse muutmine. Kas on tõesti vajalik rangelt üht keelt kasutada? Sest pildi suuruse muutmine PHP-s, noh, oleks võinud seda tõesti ka Golangis teha.
Tegelikult ei ole see vajalik, nagu paljud teised praktikad. Mõnel juhul võib see isegi olla soovimatu. Kuid on oluline mõista, et kui teie ettevõttes on 50 inimesest IT-osakonnas, kellest 45 on PHP arendajad, 3 on DevOps-i, kes oskavad Pythonit, Ansible'i, Puppet't ja midagi sellist, ning ainult üks inimene kirjutab mingis Go-s teenust piltide suuruse muutmiseks, siis kui ta lahkub, lahkub ekspertteadmus koos temaga. Ja teil on vaja otsida turul spetsiifilist arendajat, kes tunneb seda keelt, eriti kui see on haruldane. Seega on see organisatsiooniliselt probleemne. DevOps'i vaatenurgast peate mitte ainult kloonima mõnda valmis mänguraamatut, mida kasutate teenuste käivitamiseks, vaid peate need uuesti kirjutama.
Me arendame praegu teenust Node.js-il ja see on just see platvorm, kus igaühel arendajal on oma keel. Kuid me istusime ja mõtlesime, et mäng väärib vaeva. See tähendab, et siin on küsimus järele mõelda.
Kuidas te jälgite oma teenuseid? Kuidas kogute ja jälgite logisid?
Kogume logisid Elasticsearchis ja salvestame need Kibanas. Olenevalt sellest, kas tegu on tootmis- või testikeskkondadega, kasutatakse seal erinevaid kogumise tööriistu. Kusagil on Lumberjack, kusagil veel midagi, enam ei mäleta. Teatud teenustes kasutame ka Telegrafi ja saadame andmeid eraldi mujale.
Kuidas elada Puppet'i ja Ansible'iga ühe keskkonna sees?
Tegelikult on meil praegu kaks keskkonda: üks on Puppet, teine Ansible. Töötame selle nimel, et need hübriidida. Ansible on hea keskkond algse seadistuse jaoks, Puppet on algse seadistuse jaoks halb, sest see nõuab käsitsi töötamist otse keskkonnas, ja Puppet tagab konfiguratsiooni ühtsuse. See tähendab, et keskus toetab end pidevalt uuena, samas kui ansibletud masin nõuab pidevat playbook'ide käitamist, et end värskena hoida. Selline on erinevus.
Kuidas te toetate ühilduvust? Kas teil on konfigureerimist nii Ansible’is kui ka Puppet’is?
See on meie suur probleem, toetame ühilduvust käsitsi ja mõtleme, kuidas kõik sellest kuhugi edasi viia. Tundub, et Puppet installib pakette ja toetab seal teatud linke, samas kui Ansible, näiteks, installib koodi ja kohandab sellele värskeid rakenduskonfigureerimisi.
Esitluses räägiti erinevatest Ruby versioonidest. Milline lahendus?
Me oleme selle probleemiga ühes kohas kokku puutunud ja peame seda pidevalt meeles pidama. Lihtsalt lülitasime välja selle osa, mis töötas Ruby versiooniga, mis ei ühtinud rakendustega, ja hoidsime seda eraldi.
Sel aastal toimub konverents 7. detsembril 'Tehnopolis'. Jätame ettekannete esitamise taotlusi avatuks kuni 11. novembrini. meile, kui soovite esineda.
Osalejate registreerimine on avatud, liituge!
Allikas: habr.com
