Rekstrarstjóri Banki.ru vefgáttarinnar Andrey Nikolsky talaði á ráðstefnunni í fyrra um munaðarlaus þjónustu: hvernig á að bera kennsl á munaðarlaus barn í innviðum, hvers vegna munaðarlaus þjónusta er slæm, hvað á að gera við hana og hvað á að gera ef ekkert hjálpar.
Fyrir neðan klippuna er textaútgáfa af skýrslunni.
Halló félagar! Ég heiti Andrey, ég er yfir rekstri hjá Banki.ru.
Við erum með stóra þjónustu, þetta er svo einhæf þjónusta, það er þjónusta í klassískari merkingu og það eru mjög litlar. Í mínum verkamanna- og bændahugtökum segi ég að ef þjónusta er einföld og lítil þá er hún ör og ef hún er ekki mjög einföld og lítil þá er hún bara þjónusta.
Kostir þjónustu
Ég mun fljótt fara yfir kosti þjónustunnar.
Hið fyrsta er skala. Þú getur fljótt gert eitthvað í þjónustunni og byrjað framleiðslu. Þú hefur fengið umferð, þú hefur klónað þjónustuna. Þú hefur meiri umferð, þú hefur klónað hana og lifir með henni. Þetta er góður bónus og í grundvallaratriðum, þegar við byrjuðum, var það talið mikilvægast fyrir okkur, hvers vegna við erum að gera þetta allt.
Í öðru lagi, einangruð þróun, þegar þú ert með nokkur þróunarteymi, nokkra mismunandi þróunaraðila í hverju teymi og hvert lið þróar sína eigin þjónustu.
Með liðum er blæbrigði. Hönnuðir eru öðruvísi. Og það eru td. . Ég sá þetta fyrst með Maxim Dorofeev. Stundum er snjókornafólk í sumum liðum en ekki í öðrum. Þetta gerir mismunandi þjónustu sem notuð er í fyrirtækinu svolítið misjöfn.
Sjáðu myndina: þetta er góður verktaki, hann hefur stórar hendur, hann getur gert mikið. Helsta vandamálið er hvaðan þessar hendur koma.
Þjónusta gerir það mögulegt að nota mismunandi forritunarmál sem henta betur fyrir mismunandi verkefni. Sum þjónusta er í Go, önnur er í Erlang, önnur er í Ruby, eitthvað er í PHP, eitthvað er í Python. Almennt er hægt að stækka mjög mikið. Það eru blæbrigði hér líka.
Þjónustumiðaður arkitektúr snýst fyrst og fremst um devops. Það er, ef þú ert ekki með sjálfvirkni, þá er ekkert dreifingarferli, ef þú stillir það handvirkt, stillingarnar þínar geta breyst frá þjónustutilviki til tilviks og þú verður að fara þangað til að gera eitthvað, þá ertu í helvíti.
Til dæmis, þú ert með 20 þjónustur og þú þarft að dreifa með höndunum, þú ert með 20 leikjatölvur og ýtir samtímis á „enter“ eins og ninja. Það er ekki mjög gott.
Ef þú ert með þjónustu eftir prófun (ef það er prófun, auðvitað), og þú þarft samt að klára hana með skrá svo hún virki í framleiðslu, þá hef ég líka slæmar fréttir fyrir þig.
Ef þú treystir á sérstaka Amazon þjónustu og vinnur í Rússlandi, þá hafðirðu fyrir tveimur mánuðum líka „Allt í kring logar, ég er í lagi, allt er flott.
Við notum Ansible til að gera sjálfvirkan dreifingu, Puppet fyrir samleitni, Bamboo til að gera sjálfvirkan dreifingu og Confluence til að lýsa þessu öllu á einhvern hátt.
Ég ætla ekki að fjölyrða um þetta í smáatriðum, vegna þess að skýrslan snýst meira um samspilsaðferðir en ekki tæknilega útfærslu.
Til dæmis höfum við átt í vandræðum þar sem Puppet á þjóninum vinnur með Ruby 2, en sumt forrit er skrifað fyrir Ruby 1.8 og þau virka ekki saman. Þar fer eitthvað úrskeiðis. Og þegar þú þarft að keyra margar útgáfur af Ruby á einni vél, byrjarðu venjulega að lenda í vandræðum.
Til dæmis gefum við hverjum forritara vettvang þar sem það er um það bil allt sem við höfum, alla þá þjónustu sem hægt er að þróa, þannig að hann hafi einangrað umhverfi, hann getur brotið það og byggt það eins og hann vill.
Það kemur fyrir að þú þarft einhvern sérútbúinn pakka með stuðningi fyrir eitthvað þar. Það er frekar erfitt. Ég hlustaði á skýrslu þar sem Docker myndin vegur 45 GB. Í Linux er það auðvitað einfaldara, allt er minna þar, en samt verður ekki nóg pláss.
Jæja, það eru misvísandi ósjálfstæði, þegar eitt stykki af verkefninu er háð bókasafni af einni útgáfu, þá er annað stykki af verkefninu háð annarri útgáfu og bókasöfnin eru alls ekki sett upp saman.
Við erum með síður og þjónustu í PHP 5.6, við skömmumst okkar fyrir þær, en hvað getum við gert? Þetta er eina síða okkar. Það eru síður og þjónusta á PHP 7, það eru fleiri af þeim, við erum ekki að skammast okkar fyrir þær. Og hver verktaki hefur sína eigin bækistöð þar sem hann sagar með ánægju.
Ef þú skrifar í fyrirtæki á einu tungumáli, þá hljómar þrjár sýndarvélar á hvern forritara eðlilegt. Ef þú ert með mismunandi forritunarmál, þá versnar ástandið.
Þú ert með síður og þjónustu á þessu, á þessu, svo aðra síðu fyrir Go, eina síðu fyrir Ruby og einhver önnur Redis til hliðar. Þess vegna breytist þetta allt í stóran vettvang til stuðnings og allan tímann getur eitthvað af því brotnað.
Þess vegna skiptum við ávinningi forritunarmálsins út fyrir notkun mismunandi ramma, þar sem PHP rammar eru nokkuð mismunandi, þeir hafa mismunandi getu, mismunandi samfélög og mismunandi stuðning. Og þú getur skrifað þjónustu þannig að þú hafir nú þegar eitthvað tilbúið fyrir hana.
Hver þjónusta hefur sitt eigið lið
Helsti kostur okkar, sem hefur kristallast í nokkur ár, er að hver þjónusta hefur sitt lið. Þetta er þægilegt fyrir stórt verkefni, þú getur sparað tíma í skjölum, stjórnendur þekkja verkefnið sitt vel.
Þú getur auðveldlega sent inn verkefni frá þjónustudeild. Til dæmis bilaði tryggingaþjónustan. Og strax fer liðið sem sér um tryggingar til að laga það.
Nýir eiginleikar eru fljótir að búa til, því þegar þú ert með eina atómþjónustu geturðu fljótt skrúfað eitthvað inn í hana.
Og þegar þú brýtur þjónustu þína, og þetta gerist óumflýjanlega, hafðirðu ekki áhrif á þjónustu annarra og verktaki frá öðrum teymum koma ekki hlaupandi til þín með bita og segja: "Jæja, ekki gera það."
Eins og alltaf eru blæbrigði. Við erum með stöðug lið, stjórar eru negldir við liðið. Það eru skýr skjöl, stjórnendur fylgjast vel með öllu. Hvert lið með yfirmanni hefur nokkra þjónustu og það er ákveðinn hæfnipunktur.
Ef liðin eru fljótandi (við notum þetta líka stundum) er til góð aðferð sem kallast „stjörnukortið“.
Þú ert með lista yfir þjónustu og fólk. Stjarna þýðir að viðkomandi er sérfræðingur í þessari þjónustu, bók þýðir að viðkomandi er að læra þessa þjónustu. Verkefni viðkomandi er að breyta bæklingnum fyrir stjörnu. Og ef ekkert er skrifað fyrir framan þjónustuna, þá byrja vandamál, sem ég mun tala um frekar.
Hvernig birtist munaðarlaus þjónusta?
Fyrsta vandamálið, fyrsta leiðin til að fá munaðarlausa þjónustu í innviðum þínum er að reka fólk. Hefur einhver einhvern tíma látið fyrirtæki standast fresti áður en verkefni voru metin? Stundum gerist það að frestir eru þröngir og einfaldlega ekki nægur tími til að skrásetja. „Við þurfum að afhenda þjónustuna til framleiðslu, svo bætum við henni við.
Ef liðið er lítið gerist það að það er einn verktaki sem skrifar allt, restin er í vængi. „Ég skrifaði grunnarkitektúrinn, við skulum bæta viðmótunum við. Svo á einhverjum tímapunkti fer framkvæmdastjórinn til dæmis. Og á þessu tímabili, þegar framkvæmdastjórinn er farinn og nýr hefur ekki enn verið ráðinn, ákveða verktaki sjálfir hvert þjónustan er að fara og hvað er að gerast þar. Og eins og við vitum (við skulum fara aftur nokkrar glærur), í sumum liðum er snjókornafólk, stundum leiðtogi snjókornateymisins. Svo hættir hann og við fáum munaðarleysingjaþjónustu.
Á sama tíma hverfa verkefni frá stuðningi og frá viðskiptum ekki, þau lenda í baklás. Ef einhverjar byggingarvillur urðu við þróun þjónustunnar lenda þær líka í baklásnum. Þjónustan versnar hægt og rólega.
Hvernig á að bera kennsl á munaðarlaus?
Þessi listi lýsir ástandinu vel. Hver lærði eitthvað um innviði þeirra?
Um skjalfestar lausnir: það er þjónusta og almennt virkar hún, hún hefur tveggja blaðsíðna handbók um hvernig á að vinna með hana, en enginn veit hvernig hún virkar inni.
Eða, til dæmis, það er einhvers konar hlekkur styttri. Sem stendur erum við til dæmis með þrjá hlekkjastyttara í notkun í mismunandi tilgangi í mismunandi þjónustu. Þetta eru bara afleiðingarnar.
Nú verð ég fyrirliði hins augljósa. Hvað ætti að gera? Fyrst þurfum við að flytja þjónustuna yfir á annan stjórnanda, annað lið. Ef liðsstjórinn þinn hefur ekki enn hætt, þá í þessu öðru teymi, þegar þú skilur að þjónustan er eins og munaðarlaus, þarftu að hafa einhvern sem skilur að minnsta kosti eitthvað um það.
Aðalatriðið: þú verður að hafa flutningsaðferðirnar skrifaðar í blóði. Í okkar tilfelli fylgist ég yfirleitt með þessu, því ég þarf að hafa þetta allt til að virka. Stjórnendur þurfa að afhenda það fljótt og það sem gerist síðar er ekki lengur svo mikilvægt fyrir þá.
Næsta leið til að gera munaðarlaus er "Við munum gera það útvistað, það verður hraðari, og þá munum við afhenda teyminu það." Það er greinilegt að allir hafa einhver plön í liðinu, snúning. Oft heldur viðskiptavinur að útvistaraðilinn muni gera það sama og tæknideildin sem fyrirtækið hefur. Þótt hvatir þeirra séu mismunandi. Það eru undarlegar tæknilausnir og undarlegar reikniritlausnir í útvistun.
Við vorum til dæmis með þjónustu sem var með Sphinx á ýmsum óvæntum stöðum. Ég segi þér seinna hvað ég þurfti að gera.
Útvistaraðilar hafa sjálfskrifaða ramma. Þetta er bara laust PHP með copy-paste frá fyrra verkefni, þar sem þú getur fundið alls konar hluti. Dreifingarforskriftir eru stór galli þegar þú þarft að nota flókin Bash forskrift til að breyta nokkrum línum í einhverri skrá, og þessi dreifingarforskrift kallast af einhverju þriðja handriti. Fyrir vikið breytir þú dreifingarkerfinu, velur eitthvað annað, hoppar, en þjónustan þín virkar ekki. Vegna þess að þarna þurfti að setja 8 tengla í viðbót á milli mismunandi möppu. Eða það kemur fyrir að þúsund plötur virka, en hundrað þúsund virka ekki lengur.
Ég mun halda áfram að vera skipstjóri. Að samþykkja útvistaða þjónustu er lögboðin aðferð. Hefur einhver einhvern tíma fengið útvistaða þjónustu sem hefur ekki verið samþykkt neins staðar? Þetta er auðvitað ekki eins vinsælt og munaðarlaus þjónusta, en samt.
Athuga þarf þjónustuna, endurskoða þjónustuna, breyta lykilorðum. Við höfðum mál þegar þeir gáfu okkur þjónustu, það er admin pallborð "ef innskráning == 'admin' && lykilorð == 'admin'...", það er skrifað beint í kóðann. Við sitjum og hugsum og fólk skrifar þetta árið 2018?
Að prófa geymslurými er líka nauðsynlegur hlutur. Þú þarft að skoða hvað mun gerast á hundrað þúsund plötum, jafnvel áður en þú setur þessa þjónustu í framleiðslu einhvers staðar.
Það ætti ekki að vera skömm að því að senda þjónustu til umbóta. Þegar þú segir: „Við munum ekki þiggja þessa þjónustu, við höfum 20 verkefni, gerum þau, þá samþykkjum við,“ er þetta eðlilegt. Samvisku þín ætti ekki að skaðast af því að þú ert að setja á fót stjórnanda eða að fyrirtækið sé að sóa peningum. Fyrirtækið mun þá eyða meira.
Við vorum með mál þegar við ákváðum að útvista tilraunaverkefni.
Það var afhent á réttum tíma og þetta var eina gæðaviðmiðið. Þess vegna gerðum við annað tilraunaverkefni, sem var ekki einu sinni í raun tilraunaverkefni lengur. Þessi þjónusta var samþykkt og með stjórnunaraðferðum sögðu þeir, hér er kóðinn þinn, hér er liðið, hér er framkvæmdastjórinn þinn. Þjónustan er reyndar þegar farin að skila hagnaði. Á sama tíma eru þau í raun enn munaðarlaus, enginn skilur hvernig þau vinna og stjórnendur gera sitt besta til að afneita verkefnum sínum.
Það er annað frábært hugtak - skæruliðaþróun. Þegar einhver deild, oftast markaðsdeild, vill prófa tilgátu og pantar alla þjónustuna útvistaða. Umferð byrjar að streyma inn í það, þeir loka skjölunum, skrifa undir skjöl við verktaka, koma í notkun og segja: „Krabbar, við erum með þjónustu hérna, það er nú þegar umferð, hún færir okkur peninga, við skulum samþykkja það. Við vorum eins og, "Oppa, hvernig getur það verið."
Og önnur leið til að fá munaðarlausa þjónustu: þegar eitthvað teymi finnur sig skyndilega hlaðið segja stjórnendur: „Við skulum flytja þjónustu þessa liðs yfir á annað teymi, það hefur minna álag. Og svo flytjum við það yfir í þriðja lið og skiptum um stjóra. Og á endanum eigum við aftur munaðarleysingja.
Hvað er vandamálið með munaðarlaus börn?
Hver veit ekki, þetta er orrustuskipið Wasa reist í Svíþjóð, frægt fyrir þá staðreynd að það sökk 5 mínútum eftir sjósetningu. Og Svíakonungur, sem sagt, tók engan af lífi fyrir þetta. Það var smíðað af tveimur kynslóðum vélstjóra sem kunnu ekki að smíða slík skip. Náttúruleg áhrif.
Skipið hefði að vísu getað sokkið á mun verri hátt, til dæmis þegar konungur var þegar farinn á því einhvers staðar í stormi. Og svo drukknaði hann strax, samkvæmt Agile er gott að mistakast snemma.
Ef okkur mistekst snemma eru yfirleitt engin vandamál. Til dæmis, við staðfestingu var það sent til endurskoðunar. En ef okkur mistekst þegar í framleiðslu, þegar peningar eru fjárfestir, þá gætu komið upp vandamál. Afleiðingar, eins og þær eru kallaðar í viðskiptum.
Af hverju munaðarlaus þjónusta er hættuleg:
- Þjónustan gæti bilað skyndilega.
- Það tekur langan tíma að gera við þjónustuna eða er alls ekki viðgerð.
- Öryggisvandamál.
- Vandamál með endurbætur og uppfærslur.
- Ef mikilvæg þjónusta bilar er orðspor fyrirtækisins fyrir þrifum.
Hvað á að gera við munaðarlaus þjónustu?
Ég mun endurtaka það sem á að gera aftur. Í fyrsta lagi verða að vera til skjöl. 7 ár hjá Banki.ru kenndu mér að prófunaraðilar ættu ekki að taka orðum þróunaraðila og rekstur ætti ekki að taka orði allra. Við þurfum að athuga.
Í öðru lagi er nauðsynlegt að skrifa víxlverkunarmyndir, því það kemur fyrir að þjónusta sem er ekki mjög vel tekið innihalda ósjálfstæði sem enginn sagði um. Til dæmis settu verktaki upp þjónustuna á lyklinum sínum að sumum Yandex.Maps eða Dadata. Þú hefur klárað ókeypis mörkin, allt er bilað og þú veist alls ekki hvað gerðist. Öllum slíkum hrífum verður að lýsa: þjónustan notar Dadata, SMS, eitthvað annað.
Í þriðja lagi að vinna með tækniskuldir. Þegar þú gerir einhvers konar hækjur eða þiggur þjónustu og segir að eitthvað þurfi að gera þarf að passa upp á að það sé gert. Því þá getur komið í ljós að litla gatið er ekki svo lítið og þú munt detta í gegnum það.
Með arkitektaverkefnum fengum við sögu um Sphinx. Ein af þjónustunum notaði Sphinx til að slá inn lista. Bara blaðsíðuskráður listi, en hann var skráður aftur á hverju kvöldi. Það var sett saman úr tveimur vísitölum: ein stór var verðtryggð á hverju kvöldi, og það var líka lítil vísitala sem var skrúfuð á hana. Á hverjum degi, með 50% líkum á annað hvort sprengjuárás eða ekki, hrundi vísitalan við útreikninginn og fréttir okkar hættu að uppfærast á aðalsíðunni. Fyrst tók það 5 mínútur að endurtryggja vísitöluna, síðan stækkaði vísitalan og á einhverjum tímapunkti fór að taka 40 mínútur að endurverðtryggja. Þegar við klipptum þetta út önduðum við léttar, því ljóst var að aðeins meiri tími myndi líða og vísitalan okkar yrði endurverðtryggð í fullu starfi. Þetta verður bilun fyrir vefsíðuna okkar, það eru engar fréttir í átta klukkustundir - það er það, viðskipti hafa stöðvast.
Áætlun um að vinna með munaðarlaus þjónustu
Reyndar er þetta mjög erfitt, því devops snýst um samskipti. Þú vilt vera í góðu sambandi við samstarfsmenn þína og þegar þú berð kollega þína og stjórnendur í hausinn með reglugerðum geta þeir haft misvísandi tilfinningar í garð þess fólks sem gerir þetta.
Auk allra þessara atriða er annar mikilvægur hlutur: tilteknir einstaklingar verða að bera ábyrgð á hverri tiltekinni þjónustu, fyrir hvern sérstakan hluta útsetningarferlisins. Þegar það er ekkert fólk og þú þarft að laða að annað fólk til að kynna sér allt þetta mál, þá verður það erfitt.
Ef allt þetta hjálpaði ekki, og munaðarlaus þjónustan þín er enn munaðarlaus, vill enginn taka það að sér, skjöl eru ekki skrifuð, teymið sem var kallað inn í þessa þjónustu neitar að gera neitt, það er einföld leið - að endurtaka allt.
Það er að segja að þú tekur kröfurnar til þjónustunnar upp á nýtt og skrifar nýja þjónustu, betri, á betri vettvang, án undarlegra tæknilausna. Og þú flytur til þess í bardaga.
Við lentum í aðstæðum þegar við tókum þjónustu á Yii 1 og áttuðum okkur á því að við gætum ekki þróað hana frekar, vegna þess að við urðum uppiskroppa með forritara sem gætu skrifað vel á Yii 1. Allir forritarar skrifa vel á Symfony XNUMX. Hvað skal gera? Við úthlutuðum tíma, úthlutuðum teymi, úthlutuðum stjórnanda, endurskrifuðum verkefnið og skiptum umferð yfir á það.
Eftir þetta er hægt að eyða gömlu þjónustunni. Þetta er uppáhalds aðferðin mín, þegar þú þarft að taka og hreinsa út einhverja þjónustu úr stillingastjórnunarkerfinu og fara svo í gegnum og sjá að allir bílar í framleiðslu hafa verið óvirkir, þannig að þróunaraðilar eiga engin ummerki eftir. Geymslan er áfram í Git.
Þetta er allt sem ég vildi tala um, ég er tilbúinn að ræða, umræðuefnið er holivar, margir hafa synt í því.
Á glærunum stóð að þú sameinaðir tungumál. Sem dæmi má nefna stærðarbreytingu mynda. Er virkilega nauðsynlegt að takmarka það við eitt tungumál? Vegna þess að myndstærð í PHP væri í raun hægt að gera í Golang.
Reyndar er það valfrjálst, eins og allar venjur. Kannski, í sumum tilfellum, er það jafnvel óæskilegt. En þú þarft að skilja að ef þú ert með tæknideild í 50 manna fyrirtæki, þá eru 45 af þeim PHP sérfræðingar, aðrir 3 eru devops sem þekkja Python, Ansible, Puppet og eitthvað svoleiðis, og aðeins einn þeirra skrifar í sumum tegund tungumáls, einhver Go myndastærðarþjónusta, svo þegar hún fer, þá fylgir sérþekkingin með henni. Og á sama tíma þarftu að leita að markaðssértækum verktaki sem kann þetta tungumál, sérstaklega ef það er sjaldgæft. Það er, frá skipulagslegu sjónarmiði, þetta er vandamál. Frá sjónarhóli devops þarftu ekki bara að klóna eitthvað tilbúið sett af leikbókum sem þú notar til að dreifa þjónustu, heldur verður þú að skrifa þær upp á nýtt.
Við erum núna að byggja upp þjónustu á Node.js og þetta verður bara vettvangur í nágrenninu fyrir hvern forritara með sérstakt tungumál. En við sátum og héldum að leikurinn væri kertsins virði. Það er að segja, þetta er spurning fyrir þig að sitja og hugsa um.
Hvernig fylgist þú með þjónustu þinni? Hvernig safnar þú og fylgist með annálum?
Við söfnum logum í Elasticsearch og setjum í Kibana og eftir því hvort um er að ræða framleiðslu- eða prófunarumhverfi eru mismunandi safnarar notaðir þar. Einhvers staðar skógarhöggsmaður, annars staðar eitthvað annað, ég man það ekki. Og það eru enn nokkrir staðir í ákveðnum þjónustum þar sem við setjum Telegraf upp og tökum annars staðar sérstaklega.
Hvernig á að lifa með Puppet og Ansible í sama umhverfi?
Reyndar höfum við núna tvö umhverfi, annað er Puppet, hitt er Ansible. Við erum að vinna að því að blanda þeim saman. Ansible er góður rammi fyrir upphaflega uppsetningu, Puppet er slæmur rammi fyrir upphaflega uppsetningu vegna þess að það krefst praktískrar vinnu beint á pallinum og Puppet tryggir samruna stillinga. Þetta þýðir að pallurinn heldur sjálfum sér í uppfærðu ástandi og til þess að hægt sé að halda uppfærðri vélinni uppfærðri þarftu að keyra leikbækur á honum allan tímann með einhverri tíðni. Það er munurinn.
Hvernig heldurðu eindrægni? Ertu með configs í bæði Ansible og Puppet?
Þetta er okkar mikli sársauki, við höldum eindrægni með höndum okkar og hugsum um hvernig við getum haldið áfram frá öllu þessu einhvers staðar núna. Það kemur í ljós að Puppet rúllar út pakka og heldur nokkrum tenglum þar og Ansible rúllar til dæmis kóðanum út og stillir nýjustu forritastillingarnar þar.
Kynningin fjallaði um mismunandi útgáfur af Ruby. Hvaða lausn?
Við lentum í þessu á einum stað og verðum að hafa það í hausnum á okkur allan tímann. Við slökkvum einfaldlega á hlutanum sem keyrði á Ruby sem var ósamrýmanlegur forritunum og héldum honum aðskildum.
Ráðstefnan í ár fer fram 7. desember í Technopolis. Tekið er við umsóknum um skýrslur til 11. nóvember. okkur ef þú vilt tala.
Skráning á þátttakendur er hafin, vertu með!
Heimild: www.habr.com