Skilgreiningin á DevOps er mjög flókin, svo við verðum að byrja umræðuna um það upp á nýtt í hvert skipti. Það eru þúsund rit um þetta efni á Habré einum. En ef þú ert að lesa þetta veistu líklega hvað DevOps er. Vegna þess að ég er það ekki. Halló ég heiti Alexander Titov (@), og við tölum aðeins um DevOps og ég mun deila reynslu minni.
Ég hef lengi velt því fyrir mér hvernig eigi að gera söguna mína gagnlega, svo það verða margar spurningar hér - þær sem ég spyr sjálfan mig og þær sem ég spyr viðskiptavinum fyrirtækisins. Með því að svara þessum spurningum verður skilningurinn betri. Ég mun segja þér hvers vegna DevOps er þörf frá mínu sjónarhorni, hvað það er, aftur, frá mínu sjónarhorni, og hvernig á að skilja að þú ert að fara í átt að DevOps aftur frá mínu sjónarhorni. Síðasti liðurinn verður í gegnum spurningar. Með því að svara þeim fyrir sjálfan þig geturðu skilið hvort fyrirtækið þitt sé að fara í átt að DevOps eða hvort það séu vandamál á einhvern hátt.
Á sínum tíma hjólaði ég á öldur samruna og yfirtaka. Fyrst vann ég hjá litlu sprotafyrirtæki sem heitir Qik, síðan var það keypt af aðeins stærra fyrirtæki sem heitir Skype, sem síðan var keypt af aðeins stærra fyrirtæki sem heitir Microsoft. Á því augnabliki fór ég að sjá hvernig hugmyndin um DevOps var að breytast í mismunandi stærðum fyrirtækjum. Eftir það kviknaði áhugi á að skoða DevOps út frá markaðssjónarmiðum og við samstarfsfólk mitt stofnuðum fyrirtækið Express 42. Núna í 6 ár höfum við verið að færast á öldur markaðarins.
Ég er meðal annars einn af skipuleggjendum DevOps Moskvu samfélagsins og skipuleggjandi DevOps-Days 2017, en ég skipulagði ekki 2018. Express 42 vinnur með mörgum fyrirtækjum. Við ræktum DevOps þar, fylgjumst með hvernig það gerist, drögum ályktanir, greinum, segjum öllum ályktanir okkar og þjálfum fólk í DevOps-aðferðum. Almennt séð gerum við okkar besta til að auka reynslu okkar og sérfræðiþekkingu í þessum efnum.
Hvers vegna DevOps
Fyrsta spurningin sem ásækir alla og er alltaf - hvers vegna? Margir halda að DevOps sé bara sjálfvirkni eða svipaður hlutur sem hvert fyrirtæki hafði þegar.
— Við vorum með stöðuga samþættingu - þetta þýðir að við vorum þegar með DevOps og hvers vegna þarf allt þetta dót? Þeir skemmta sér í útlöndum, en þeir eru að stoppa okkur í að vinna!
Yfir 9 ára þróun samfélagsins og aðferðafræði hefur þegar komið í ljós að þetta er enn ekki markaðsglími, en samt er ekki alveg ljóst hvers vegna þess er þörf. Eins og öll tæki og ferli, hefur DevOps sérstök markmið sem það nær að lokum.
Allt er þetta vegna þess að heimurinn er að breytast. Hann hverfur frá framtaksnálguninni, þegar fyrirtæki fara beint í átt að draumi, eins og Sankti Pétursborgarklassíkin okkar söng, frá punkti A til punkts B samkvæmt ákveðinni stefnu, með ákveðinni uppbyggingu byggð fyrir þetta.
Í grundvallaratriðum ætti allt í upplýsingatækni að vera byggt samkvæmt þessari nálgun. Hér er upplýsingatækni eingöngu notað til að gera sjálfvirkan ferla.
Sjálfvirkni breytist ekki oft, því hverju er þá að breyta þegar fyrirtæki lendir í troðnum hjólförum? Það virkar - ekki snerta það. Nú eru aðferðir í heiminum að breytast og sú sem heitir Agile bendir til þess að endapunktur B sé ekki strax.
Þegar fyrirtæki fer í gegnum markaðinn, vinnur með viðskiptavin, kannar það stöðugt markaðinn og breytir endapunkti B. Þar að auki, því oftar sem fyrirtækið breytir um stefnu, þeim mun farsælli er það á endanum, því það velur meiri markað. veggskot.
Stefnan er sýnd af áhugaverðu fyrirtæki sem ég lærði nýlega um. One Box Shave er áskriftarsending fyrir rakvélar og rakvélar í kassa. Þeir vita hvernig á að sérsníða „kassann“ sinn fyrir mismunandi viðskiptavini. Þetta er gert með ákveðnum hugbúnaði sem sendir síðan pöntunina til kóresku verksmiðjunnar sem framleiðir vöruna.
Þessi vara var keypt af Unilever fyrir 1 milljarð dollara. Það keppir nú við Gillette og hefur tekið umtalsverðan hlut neytenda á bandaríska markaðnum. One Box Shave segja:
— 4 blöð? Er þér alvara? Hvers vegna þarftu þetta - það bætir ekki gæði raksins. Sérvalið krem, ilmur og hágæða rakvél með tveimur blöðum leysa mun fleiri vandamál en þessi heimskulegu 4 Gillette blöð! Komumst við í 10 bráðum?
Svona breytist heimurinn. Unilever halda því fram að þeir séu með flott upplýsingatæknikerfi sem gerir þér kleift að gera þetta. Að lokum lítur það út eins og hugtak Tími til markaðssetningar, sem enginn hefur þegar talað um.
Aðalatriðið með Time-to-market er ekki hversu oft við sendum inn. Þú getur oft sent inn, en útgáfuferlið verður langt. Ef þriggja mánaða útgáfulotur eru lagðar ofan á hvor aðra og færa þær um viku, kemur í ljós að fyrirtækið virðist vera að dreifa einu sinni í viku. Og frá hugmynd til lokaútfærslu tekur það 3 mánuði.
Time-to-market snýst um að lágmarka tímann frá hugmynd til lokaútfærslu.
Í þessu tilviki hefur hugbúnaður samskipti við markaðinn. Þetta er hvernig One Box Shave vefsíðan hefur samskipti við viðskiptavininn. Þeir hafa ekki sölumenn - bara vefsíðu þar sem gestir smella og skilja eftir óskir. Samkvæmt því þarf stöðugt að setja eitthvað nýtt á síðuna og uppfæra í samræmi við óskir. Til dæmis, í Suður-Kóreu raka þeir sig öðruvísi en í Rússlandi og þeim finnst lyktin ekki af furu, heldur til dæmis af gulrótum og vanillu.
Þar sem nauðsynlegt er að breyta innihaldi síðunnar fljótt breytist hugbúnaðarþróun mjög. Með hugbúnaði verðum við að komast að því hvað viðskiptavinurinn vill. Áður lærðum við þetta með nokkrum hringtorgsleiðum, til dæmis í gegnum viðskiptastjórnun. Svo hönnuðum við það, settum kröfurnar inn í upplýsingatæknikerfið og allt var flott. Nú er þetta öðruvísi - hugbúnaður er hannaður af öllum sem taka þátt í ferlinu, þar á meðal verkfræðingum, því í gegnum tækniforskriftir læra þeir hvernig markaðurinn virkar og deila einnig innsýn sinni með fyrirtækinu.
Til dæmis, á Qik lærðum við allt í einu að fólki líkaði mjög vel að hlaða tengiliðalistum inn á netþjóninn og það útvegaði okkur forrit. Upphaflega hugsuðum við ekki um það. Í klassísku fyrirtæki hefðu allir ákveðið að þetta væri galli, þar sem forskriftin sagði ekki að það ætti að virka frábærlega og væri almennt útfært á hnénu, þeir hefðu slökkt á eiginleikanum og sagt: "Enginn þarf þetta, það mikilvægasta er að aðalvirknin virki.“ . Og tæknifyrirtækið lítur á þetta sem tækifæri og fer að breyta hugbúnaðinum í samræmi við þetta.
Árið 1968 mótaði hugsjónamaður, Melvin Conway, eftirfarandi hugmynd.
Skipulagið sem býr til kerfið er bundið af hönnun sem endurtekur samskiptaskipulag þeirrar stofnunar.
Nánar, til þess að framleiða kerfi af annarri gerð, þarf einnig að hafa samskiptauppbyggingu innan fyrirtækis af annarri gerð. Ef samskiptauppbyggingin þín er hæsta stigveldi, þá mun þetta ekki leyfa þér að búa til kerfi sem geta veitt mjög háan tíma-til-markaðsvísi.
Lestu maður getur . Það er mikilvægt til að skilja DevOps menningu eða heimspeki vegna þess það eina sem breytist í grundvallaratriðum í DevOps er uppbygging samskipta milli teyma.
Frá ferlissjónarmiði, fyrir DevOps, voru öll stig: greining, þróun, prófun, rekstur línuleg.
Þegar um DevOps er að ræða, eiga sér stað öll þessi ferli samtímis.
Tími til markaðssetningar er eina leiðin til þess. Fyrir fólk sem vann í gamla ferlinu lítur þetta nokkuð kosmískt út og almennt svo sem svo.
Svo hvers vegna er DevOps þörf?
Fyrir stafræna vöruþróun. Ef fyrirtæki þitt er ekki með stafræna vöru er DevOps ekki þörf - það er mjög mikilvægt.
DevOps sigrar hraðatakmarkanir raðbundinnar hugbúnaðarframleiðslu. Í henni eiga sér stað öll ferli samtímis.
Erfiðleikar aukast. Þegar DevOps evangelistar segja þér að það muni auðvelda þér að gefa út hugbúnað er þetta bull.
Með DevOps verða hlutirnir aðeins flóknari.
Á ráðstefnunni í Avito básnum mátti sjá hvernig það var að setja upp Docker gám - óraunhæft verkefni. Flækjustigið verður óviðjafnanlegt; þú þarft að leika með mörgum boltum á sama tíma.
DevOps gjörbreytir ferli og skipulagi í fyrirtækinu — Nánar tiltekið, það er ekki DevOps sem breytist, heldur stafræna varan. Til að koma til DevOps þarftu samt að breyta þessu ferli algjörlega.
Spurningar fyrir sérfræðing
Hvað ertu með? Spurningar sem þú getur spurt sjálfan þig á meðan þú vinnur í fyrirtæki og þróast sem sérfræðingur.
Ertu með stefnu til að búa til stafræna vöru? Ef það er, þá er það nú þegar gott. Þetta þýðir að fyrirtækið þitt er að færast í átt að DevOps.
Er fyrirtæki þitt nú þegar að búa til stafræna vöru? Þetta þýðir að þú getur fært þig upp á annað stig og gert hlutina áhugaverðari - aftur frá sjónarhóli DevOps. Ég er aðeins að tala út frá þessu sjónarhorni.
Er fyrirtæki þitt eitt af leiðtogum markaðarins á sviði stafrænna vara? Spotify, Yandex, Uber eru fyrirtæki sem eru á hátindi tækniframfara núna.
Spyrðu sjálfan þig þessara spurninga og ef öll svörin eru nei, þá ættirðu kannski ekki að gera DevOps hjá þessu fyrirtæki. Ef viðfangsefnið DevOps er virkilega áhugavert fyrir þig, ættir þú kannski að flytja til annars fyrirtækis? Ef fyrirtækið þitt vill fara í DevOps, en þú svaraðir „Nei“ við öllum spurningunum, þá er það eins og þessi fallegi nashyrningur sem mun aldrei breytast.
Samtök
Eins og ég sagði, samkvæmt Conway's Law, breytist skipulag fyrirtækis. Ég mun byrja á því sem kemur í veg fyrir að DevOps komist inn í fyrirtækið frá skipulagslegu sjónarhorni.
Vandamálið við "brunnur"
Enska orðið „Silo“ er hér þýtt á rússnesku sem „vel“. Tilgangurinn með þessu vandamáli er sá engin upplýsingaskipti eru á milli liða. Hvert lið kafar djúpt í sérfræðiþekkingu sína, án þess að byggja upp sameiginlegt kort til að sigla.
Að sumu leyti minnir þetta mig á manneskju sem er nýkomin til Moskvu og veit ekki enn hvernig á að fara um neðanjarðarlestarkortið. Moskvubúar þekkja venjulega svæðið sitt mjög vel og um alla Moskvu geta þeir farið með neðanjarðarlestarkortið. Þegar þú kemur til Moskvu í fyrsta skipti hefurðu ekki þessa hæfileika og þú ert bara ráðvilltur.
DevOps stingur upp á því að komast í gegnum þetta augnablik ráðleysis og allar deildir vinna saman að því að byggja upp sameiginlegt samskiptakort.
Tveir þættir hamla þessu.
Afleiðing stjórnunarkerfis fyrirtækja. Það er byggt í aðskildum stigveldis „brunnum“. Til dæmis eru ákveðin KPI í fyrirtækjum sem styðja þetta kerfi. Á hinn bóginn kemur heili einstaklings sem á erfitt með að fara út fyrir mörk sérfræðiþekkingar sinnar og rata um allt kerfið í veginum. Það er bara óþægilegt. Ímyndaðu þér að þú sért á flugvellinum í Bangkok - þú munt ekki rata hratt. DevOps er líka erfitt yfirferðar og þess vegna segja fólk að þú þurfir að finna leiðarvísir til að komast þangað.
En það mikilvægasta er að vandamálið við „brunn“ fyrir verkfræðing sem er gegnsýrður anda DevOps, hefur lesið Fowler og fullt af öðrum bókum, kemur fram í þeirri staðreynd að „brunnar“ leyfa þér ekki að gera „augljósa“ hluti. Við komum oft saman eftir DevOps Moskvu, tölum saman og fólk kvartar:
— Við vildum bara setja CI á markað, en það kom í ljós að stjórnendur þurftu þess ekki.
Þetta gerist einmitt vegna þess CI и Stöðugt afhendingarferli eru á mörkum margra prófa. Einfaldlega án þess að sigrast á vandamálinu „brunnur“ á skipulagsstigi muntu ekki geta haldið áfram, sama hvað þú gerir og sama hversu sorglegt það er.
Hver þátttakandi í ferlinu í fyrirtækinu: bakenda- og framendahönnuðir, prófun, DBA, rekstur, netkerfi, grafar í sína áttina og enginn hefur sameiginlegt kort nema framkvæmdastjórinn, sem á einhvern hátt fylgist með þeim og stýrir þeim með „deilunni“ og sigra“ aðferð.
Fólk er að berjast fyrir einhverjum stjörnum eða fánum, allir eru að grafa sérfræðiþekkingu sína.
Þar af leiðandi, þegar það verkefni kemur upp að tengja þetta allt saman og byggja upp sameiginlega leiðslu, og ekki þarf lengur að berjast um stjörnur og fána, vaknar spurningin - hvað á að gera? Við þurfum einhvern veginn að ná samkomulagi en það kenndi okkur enginn í skólanum. Okkur hefur verið kennt síðan í skóla: áttunda bekk - vá! - miðað við sjöunda bekk! Það er eins hér.
Er það sama í þínu fyrirtæki?
Til að athuga þetta geturðu spurt sjálfan þig eftirfarandi spurninga.
Nota teymi sameiginleg verkfæri og stuðla að breytingum á þeim sameiginlegu verkfærum?
Hversu oft endurskipuleggja teymi sig - sumir sérfræðingar úr einu teymi fara yfir í annað teymi? Það er í DevOps umhverfi sem þetta verður eðlilegt, því stundum getur einstaklingur einfaldlega ekki skilið hvað annað sérfræðisvið er að gera. Hann flytur á aðra deild, vinnur þar í tvær vikur við að búa til kort af stefnumörkun og samskiptum við þessa deild.
Er hægt að mynda breytinganefnd og breyta hlutunum? Eða krefst það sterkrar handar æðstu stjórnenda og stjórnunar? Ég skrifaði nýlega á Facebook hvernig einn lítt þekktur banki er að innleiða verkfæri í gegnum pantanir: við skrifum pöntun, við innleiðum hana í eitt ár og sjáum hvað gerist. Þetta er auðvitað langt og sorglegt.
Hversu mikilvægt er fyrir stjórnendur að fá persónuleg afrek án tillits til árangurs fyrirtækisins?
Ef þú svarar þessum spurningum fyrir sjálfan þig kemur betur í ljós hvort þú eigir við slík vandamál að etja í þínu fyrirtæki.
Innviðir sem kóða
Eftir að þetta vandamál er liðið er fyrsta mikilvæga æfingin, án hennar er erfitt að komast lengra í DevOps innviði sem kóða.
Oftast er litið á innviði sem kóða sem hér segir:
— Gerum allt sjálfvirkt í bash, hyljum okkur með skriftum svo að stjórnendur hafi minni handavinnu!
En það er ekki satt.
Innviðir sem kóða þýðir að þú lýsir upplýsingatæknikerfinu sem þú vinnur með í formi kóða til að skilja stöðugt ástand þess.
Saman með öðrum liðum býrð þú til kort í formi kóða sem allir geta skilið og geta flakkað og flakkað. Það skiptir ekki máli hvað það er gert á - Chef, Ansible, Salt eða með því að nota YAML skrár í Kubernetes - það er enginn munur.
Á ráðstefnunni sagði samstarfsmaður frá 2GIS frá því hvernig þeir gerðu sinn eigin innri hlut fyrir Kubernetes, sem lýsir uppbyggingu einstakra kerfa. Til að lýsa 500 kerfum þurftu þeir sérstakt tól sem býr til þessa lýsingu. Þegar þessi lýsing er til þá geta allir athugað hver við annan, fylgst með breytingum, hvernig á að breyta því og bæta, hvað vantar.
Sammála, einstök bash forskriftir veita venjulega ekki þennan skilning. Í einu af fyrirtækjum þar sem ég starfaði var meira að segja til nafn fyrir „skrifaðu aðeins“ handrit - þegar handritið er skrifað, en það er ekki lengur hægt að lesa það. Ég held að þú þekkir þetta líka.
Innviði eins og kóði er kóða sem lýsir núverandi ástandi innviða. Mörg vöru-, innviða- og þjónustuteymi vinna saman að þessum kóða og síðast en ekki síst þurfa þau öll að skilja hvernig þessi kóða virkar í raun og veru.
Reglunum er viðhaldið í samræmi við bestu siðareglur: sameiginleg þróun, endurskoðun kóða, XP-forritun, prófun, dragbeiðnir, CI fyrir kóðainnviði - allt þetta hentar og er hægt að nota.
Kóði verður sameiginlegt tungumál fyrir alla verkfræðinga.
Það tekur ekki mikinn tíma að breyta innviðum í kóða. Já, innviðakóði getur líka verið með tæknilegar skuldir. Venjulega lenda lið í því einu og hálfu ári eftir að þau byrjuðu að innleiða „innviði sem kóða“ í formi fullt af skriftum eða jafnvel Ansible, sem þau skrifa eins og spaghetti kóða, og þau henda líka bash skriftum í blönduna!
Það er mikilvægt: Ef þú hefur ekki prófað þetta efni ennþá, mundu það Ansible er ekki bash! Lestu skjölin vandlega, kynntu þér hvað þeir skrifa um þau.
Innviði sem kóða er aðskilnaður innviðakóða í aðskilin lög.
Í fyrirtækinu okkar aðgreinum við 3 grunnlög, sem eru mjög skýr og einföld, en þau geta verið fleiri. Þú getur skoðað innviðakóðann þinn og sagt hvort þú sért með þetta ástand eða ekki. Ef engin lög eru auðkennd, þá þarftu að taka smá tíma og endurskoða aðeins.
grunnlag - þetta er hvernig stýrikerfið, öryggisafrit og aðrir hlutir á lágu stigi eru stilltir, til dæmis hvernig Kubernetes er sett upp á grunnstigi.
Þjónustustig - þetta er þjónustan sem þú veitir þróunaraðilanum: skógarhögg sem þjónusta, eftirlit sem þjónusta, gagnagrunnur sem þjónusta, jafnvægisbúnaður sem þjónusta, biðröð sem þjónusta, Stöðug afhending sem þjónusta - fullt af þjónustu sem einstök teymi getur veitt þróun. Þessu öllu þarf að lýsa í sérstökum einingum í stillingastjórnunarkerfinu þínu.
Lagið þar sem umsóknir eru gerðar og lýsir því hvernig þau munu þróast ofan á fyrri tvö lögin.
Stjórna spurningar
Er fyrirtæki þitt með sameiginlega innviðageymslu? Ertu að stjórna tæknilegum skuldum í innviðum þínum? Notar þú þróunaraðferðir í innviðageymslu? Er innviðum þínum skipt niður í lög? Þú getur athugað Base-service-APP skýringarmyndina. Hversu erfitt er að gera breytingar?
Ef þú hefur upplifað að það tók einn og hálfan dag að gera breytingar þýðir það að þú ert með tækniskuldir og þarft að vinna með það. Þú rakst bara á tæknilega skuldasöfnun í innviðakóðanum þínum. Ég man eftir mörgum slíkum sögum þegar þú þarft að endurskrifa helminginn af innviðakóðanum til þess að breyta einhverju CCTL, því sköpunargáfan og löngunin til að gera allt sjálfvirkt leiddi til þess að allt er tært alls staðar, öll handföng hafa verið fjarlægð, og það er nauðsynlegt að endurskoða.
Stöðug afhending
Berum saman debet og kredit. Fyrst kemur lýsing á innviðum, sem getur verið frekar grunn. Þú þarft ekki að lýsa öllu í smáatriðum, en það þarf einhverja grunnlýsingu svo þú getir unnið með það. Annars er ekki ljóst hvað á að gera við samfellda afhendingu næst. Allar þessar venjur þróast samtímis þegar þú kemur til DevOps, en það byrjar með því að skilja hvað þú hefur og hvernig á að stjórna því. Þetta er einmitt iðkun innviða sem kóða.
Þegar það verður ljóst að þú hefur það og hvernig á að stjórna því, byrjarðu að finna út hvernig á að senda þróunarkóðann til framleiðslu eins fljótt og auðið er. Ég meina ásamt framkvæmdaraðilanum - við munum eftir vandamálinu við „brunn“, það er að það er ekki einstaklingur sem kemur upp með þetta, heldur teymi.
Þegar við erum með Vanya Evtukhovich sá fyrstu bókina Jez Humble og hópa höfunda "Stöðug afhending", sem kom út árið 2009, hugsuðum við lengi um hvernig ætti að þýða titilinn á rússnesku. Þeir vildu þýða það sem „Stöðugt afhenda“ en því miður var það þýtt sem „Stöðug afhending“. Mér sýnist að það sé eitthvað rússneskt í nafni okkar, með þrýstingi.
Stöðugt að skila þýðir
Kóða sem er í vörugeymslunni er alltaf hægt að hlaða niður í framleiðslu. Hann er kannski ekki látinn blása, en hann er alltaf tilbúinn í það. Í samræmi við það skrifarðu alltaf kóða með erfiðri tilfinningu fyrir einhverjum kvíða undir rófubeininu. Það birtist oft þegar þú rúllar út innviðakóða. Þessi tilfinning um einhverja kvíða ætti að vera til staðar - hún kemur af stað heilaferli sem gerir þér kleift að skrifa kóða aðeins öðruvísi. Þetta ætti að skrá í reglur innan þróunarinnar.
Til að afhenda stöðugt þarftu gripasnið sem keyrir yfir innviðavettvang. Ef þú kastar „lífsúrgangi“ af mismunandi sniðum yfir innviðavettvang, þá verður það sameinað, það er erfitt að viðhalda því og vandamálið vegna tæknilegra skulda kemur upp. Það þarf að samræma snið gripsins - þetta er líka sameiginlegt verkefni: við þurfum öll að koma saman, ryðja heilann og finna upp þetta snið.
Munurinn er stöðugt endurbættur og breytist til að henta framleiðsluumhverfinu þegar hann fer í gegnum afhendingarleiðsluna. Þegar gripur hreyfist eftir leiðslunni lendir hann stöðugt í einhverjum óþægilegum hlutum fyrir hann, sem eru svipaðir og gripurinn sem þú setur í framleiðslu lendir í. Ef í klassískri þróun er þetta gert af kerfisstjóra sem gerir útsetninguna, þá gerist þetta alltaf í DevOps ferlinu: hér prófuðu þeir það með nokkrum prófum, hér hentu þeir því í Kubernetes þyrping, sem er meira og minna svipað til framleiðslu, þá byrjuðu þeir skyndilega að prófa hleðslu.
Þetta minnir svolítið á Pac-Man leikinn - gripurinn fer í gegnum einhvers konar sögu. Á sama tíma er mikilvægt að stjórna því hvort kóðinn fari í raun í gegnum söguna og hvort hann tengist þinni framleiðslu á einhvern hátt. Hægt er að draga sögur frá framleiðslu inn í stöðuga afhendingarferlið: það var svona þegar eitthvað féll, nú skulum við bara forrita þessa atburðarás inni í kerfinu. Í hvert skipti sem kóðinn fer í gegnum þessa atburðarás líka og þú munt ekki lenda í þessu vandamáli næst. Þú munt læra um það miklu fyrr en það nær til viðskiptavinar þíns.
Mismunandi dreifingaraðferðir. Til dæmis, þú notar AB próf eða kanarídreifingar til að prófa kóðann öðruvísi á mismunandi viðskiptavinum, fá upplýsingar um hvernig kóðinn virkar og mun fyrr en þegar hann er settur út til 100 milljón notenda.
„Stöðugt skila“ lítur svona út.
Afhendingarferlið Dev, CI, Test, PreProd, Prod er ekki sérstakt umhverfi, þetta eru stig eða stöðvar með eldföstum upphæðum sem gripurinn þinn fer í gegnum.
Ef þú ert með innviðakóða sem er lýst sem Base Service APP þá hjálpar það ekki gleyma öllum handritunum, og skrifaðu þær niður sem kóða fyrir þennan grip, stuðla að gripi og breyttu því eins og þú ferð.
Sjálfsprófsspurningar
Tíminn frá lýsingu eiginleika til útgáfu í framleiðslu er í 95% tilvika innan við vika? Bætast gæði gripsins á hverju stigi leiðslunnar? Er einhver saga sem það fer í gegnum? Notar þú mismunandi dreifingaraðferðir?
Ef öll svörin eru já, þá ertu ótrúlega flottur! Skrifaðu svörin þín í athugasemdunum - ég mun vera ánægð).
Álit á síðunni
Þetta er erfiðasta æfingin af öllu. Á DevOpsConf ráðstefnunni var kollegi frá Infobip, sem talaði um það, svolítið ruglaður í orðum sínum, því þetta er í raun mjög flókið starf um þá staðreynd að þú þarft að fylgjast með öllu!
Til dæmis fyrir margt löngu þegar ég vann hjá Qik og við áttum okkur á því að við þyrftum að fylgjast með öllu. Við gerðum þetta og við erum núna með 150 hluti í Zabbix sem er stöðugt fylgst með. Það var skelfilegt, tæknistjórinn snéri fingrinum við snærið:
- Krakkar, af hverju ertu að nauðga servernum með einhverju óljósu?
En svo gerðist atvik sem sýndi að þetta er í raun mjög flott stefna.
Ein af þjónustunum byrjaði stöðugt að hrynja. Upphaflega hrundi það ekki, sem er áhugavert, kóðanum var ekki bætt við þar, vegna þess að það var grunnmiðlari, sem hafði nánast enga viðskiptavirkni - hann sendi einfaldlega skilaboð á milli einstakra þjónustu. Þjónustan breyttist ekki í 4 mánuði og skyndilega byrjaði hún að hrynja með villunni „Segmentation fault“.
Okkur brá, opnuðum töflurnar okkar í Zabbix og það kom í ljós að fyrir einni og hálfri viku breyttist hegðun beiðna í API þjónustunni sem þessi miðlari notar mikið. Næst sáum við að tíðni þess að senda ákveðin tegund skilaboða hafði breyst. Síðan komumst við að því að þetta voru Android viðskiptavinir. Við spurðum:
— Strákar, hvað kom fyrir ykkur fyrir einni og hálfri viku?
Sem svar heyrðum við áhugaverða sögu um hvernig þeir höfðu endurhannað HÍ. Það er ólíklegt að einhver muni strax segja að þeir hafi breytt HTTP bókasafninu. Fyrir Android viðskiptavini er þetta eins og að skipta um sápu á baðherberginu - þeir muna það bara ekki. Fyrir vikið, eftir 40 mínútna samtal, komumst við að því að þeir höfðu breytt HTTP bókasafninu og sjálfgefna tímasetningar þess höfðu breyst. Þetta leiddi til þess að umferðarhegðun á API netþjóninum breyttist, sem leiddi til aðstæðna sem olli kapphlaupi innan miðlarans, og það byrjaði að hrynja.
Án djúps eftirlits er almennt ómögulegt að opna þetta. Ef samtökin eiga enn í vandræðum með „brunn“, þegar allir kasta peningum hver í annan, getur þetta lifað í mörg ár. Þú einfaldlega endurræsir netþjóninn því það er ómögulegt að leysa vandamálið. Þegar þú fylgist með, rekur, fylgist með öllum atburðum sem þú hefur, og notar vöktun sem prófun - skrifar kóða og gefur strax til kynna hvernig á að fylgjast með honum, líka í formi kóða (við erum nú þegar með innviðina sem kóða), verður allt ljóst hvernig á lófanum. Jafnvel svo flókin vandamál eru auðvelt að rekja.
Safnaðu öllum upplýsingum um hvað verður um gripinn á hverju stigi afhendingarferlisins - ekki í framleiðslu.
Hladdu upp vöktuninni á CI og nokkur grunnatriði munu þegar vera sýnileg þar. Seinna muntu sjá þá í Test, PredProd og hleðsluprófun. Safnaðu upplýsingum á öllum stigum, ekki aðeins mælingum, tölfræði, heldur einnig annálum: hvernig forritið fór út, frávik - safnaðu öllu.
Annars verður erfitt að átta sig á því. Ég sagði þegar að DevOps er flóknara. Til að takast á við þetta flókið þarftu að hafa eðlilega greiningu.
Spurningar um sjálfsstjórn
Ertu að fylgjast með og skrá þig í þróunartólið fyrir þig? Þegar þú skrifar kóða, hugsa verktaki þín, þar á meðal þú, um hvernig á að fylgjast með honum?
Heyrðir þú um vandamál frá viðskiptavinum? Skilurðu viðskiptavininn betur frá eftirliti og skráningu? Skilurðu kerfið betur frá eftirliti og skráningu? Breytir þú kerfinu einfaldlega vegna þess að þú sást að þróunin í kerfinu er að aukast og þú skilur að eftir 3 vikur í viðbót mun allt deyja?
Þegar þú hefur þessa þrjá þætti geturðu hugsað um hvers konar innviðavettvang þú hefur í fyrirtækinu þínu.
Innviðavettvangur
Málið er ekki að það sé sett af ólíkum verkfærum sem hvert fyrirtæki hefur.
Tilgangurinn með innviðavettvangi er að öll teymi nota þessi verkfæri og þróa þau saman.
Það er ljóst að það eru aðskilin teymi sem bera ábyrgð á þróun einstakra hluta innviðavettvangsins. En á sama tíma ber sérhver verkfræðingur ábyrgð á þróun, frammistöðu og kynningu innviðavettvangsins. Á innra stigi verður það algengt tæki.
Öll teymi þróa innviðavettvanginn og meðhöndla hann af alúð sem eigin IDE. Í IDE þinni seturðu upp mismunandi viðbætur til að gera allt gott og hratt og stillir flýtilykla. Þegar þú opnar Sublime, Atom eða Visual Studio Code streyma kóðavillur inn og þú áttar þig á því að það er ómögulegt að vinna, þér líður strax dapur og þú hleypur til að laga IDE.
Komdu fram við innviðavettvang þinn á sama hátt. Ef þú skilur að eitthvað er athugavert við það skaltu skilja eftir beiðni ef þú getur ekki lagað það sjálfur. Ef það er eitthvað einfalt, breyttu því sjálfur, sendu pull request, strákarnir íhuga það og bæta því við. Þetta er aðeins öðruvísi nálgun á verkfræðiverkfæri í höfði þróunaraðila.
Innviðavettvangurinn tryggir flutning gripsins frá þróun til viðskiptavinarins með stöðugum framförum í gæðum. IP-talan er forrituð með safn af sögum sem gerast við kóðann í framleiðslu. Í áranna rás hafa þessar sögur verið margar, sumar þeirra eru einstakar og tengjast aðeins þér - ekki er hægt að gúgla þær.
Á þessum tímapunkti verður innviðavettvangurinn samkeppnisforskot þitt, vegna þess að það er eitthvað innbyggt í það sem er ekki í tóli keppinautarins. Því dýpri sem IP-talan þín er, því meiri samkeppnisforskot þitt hvað varðar tíma til markaðssetningar. Birtist hér vandamál með læsingu söluaðila: Þú getur tekið vettvang einhvers annars, en með því að nota reynslu einhvers annars muntu ekki skilja hversu viðeigandi það er fyrir þig. Já, ekki öll fyrirtæki geta byggt upp vettvang eins og Amazon. Þetta er erfið lína þar sem reynsla fyrirtækisins skiptir máli fyrir stöðu þess á markaðnum og ekki er hægt að nota sölulás þar. Þetta er líka mikilvægt að hugsa um.
Kerfið
Þetta er grunnskýringarmynd af innviðavettvangi sem mun hjálpa þér að setja upp allar venjur og ferla í DevOps fyrirtæki.
Við skulum skoða hvað það samanstendur af.
Auðlindaskipunarkerfi, sem veitir forritum og annarri þjónustu CPU, minni, disk. Ofan á þetta - þjónustu á lágu stigi: eftirlit, skógarhögg, CI/CD vél, geymsla gripa, innviði sem kerfiskóði.
Þjónusta á hærra stigi: gagnagrunnur sem þjónusta, biðraðir sem þjónusta, Hleðslujöfnuður sem þjónusta, stærðarbreyting mynd sem þjónusta, Big Data verksmiðja sem þjónusta. Ofan á þetta - leiðsla sem skilar stöðugt breyttum kóða til viðskiptavinarins.
Þú færð upplýsingar um hvernig hugbúnaðurinn þinn virkar fyrir viðskiptavininn, breytir honum, gefur upp þennan kóða aftur, færð upplýsingar - og þannig þróar þú stöðugt bæði innviðavettvanginn og hugbúnaðinn þinn.
Á skýringarmyndinni samanstendur afhendingarleiðslan af mörgum þrepum. En þetta er skýringarmynd sem er gefin sem dæmi - engin þörf á að endurtaka það eitt af öðru. Stig hafa samskipti við þjónustu eins og um þjónustu væri að ræða - hver múrsteinn á pallinum ber sína sögu: hvernig tilföngum er úthlutað, hvernig forritið er ræst, vinnur með tilföngum, er fylgst með og breytingar.
Það er mikilvægt að skilja að hver hluti pallsins ber sögu og spyrðu sjálfan þig hvaða sögu ber þessi múrsteinn, kannski ætti að henda honum og skipta út fyrir þjónustu frá þriðja aðila. Er til dæmis hægt að setja upp Okmeter í stað múrsteins? Kannski hafa strákarnir þegar þróað þessa sérfræðiþekkingu miklu meira en við. En kannski ekki - kannski höfum við einstaka sérfræðiþekkingu, við þurfum að setja upp Prometheus og þróa hana áfram.
Stofnun vettvangsins
Þetta er flókið samskiptaferli. Þegar þú hefur grunnaðferðir byrjarðu samskipti milli mismunandi verkfræðinga og sérfræðinga sem þróa kröfur og staðla og breytir þeim stöðugt í mismunandi verkfæri og nálgun. Menningin sem við höfum í DevOps er mikilvæg hér.
Með menningu er allt mjög einfalt - þetta snýst um samvinnu og samskipti, það er löngunin til að vinna á sameiginlegu sviði með hvort öðru, löngunin til að beita einu hljóðfæri saman. Það eru engin eldflaugavísindi hér - allt er mjög einfalt, banalt. Við búum til dæmis öll í innganginum og höldum honum hreinum - svona menningarstig.
Hvað ertu með?
Aftur, spurningar sem þú getur spurt sjálfan þig.
Er innviðavettvangurinn hollur? Hver ber ábyrgð á þróun þess? Skilur þú samkeppnisforskot innviðakerfisins þíns?
Þú þarft stöðugt að spyrja sjálfan þig þessara spurninga. Ef hægt er að flytja eitthvað yfir á þjónustu þriðja aðila ætti að flytja það; ef þjónusta þriðja aðila byrjar að loka á hreyfingu þína, þá þarftu að byggja upp kerfi innra með þér.
Svo, DevOps...
... þetta er flókið kerfi, það verður að hafa:
- Stafræn vara.
- Viðskiptaeiningar sem þróa þessa stafrænu vöru.
- Vörateymi sem skrifa kóða.
- Stöðugar sendingaraðferðir.
- Pallar sem þjónusta.
- Innviðir sem þjónusta.
- Innviðir sem kóða.
- Aðskildar aðferðir til að viðhalda áreiðanleika, innbyggðar í DevOps.
- Endurgjöf sem lýsir öllu.
Þú getur notað þessa skýringarmynd, undirstrikað í henni það sem þú hefur nú þegar í fyrirtækinu þínu í einhverri mynd: hefur það þróast eða þarf enn að þróa það.
Það lýkur eftir nokkrar vikur . sem hluti af RIT++. Komdu á ráðstefnuna þar sem þú finnur margar flottar skýrslur um stöðuga afhendingu, innviði sem kóða og DevOps umbreytingu. , síðasti verðfrestur er til 20. maí
Heimild: www.habr.com