La difino de DevOps estas tre kompleksa, do ni devas komenci la diskuton pri ĝi denove ĉiufoje. Estas mil eldonaĵoj pri tiu ĉi temo nur pri Habré. Sed se vi legas ĉi tion, vi verŝajne scias, kio estas DevOps. Ĉar mi ne estas. Saluton mia nomo estas Aleksandro Titov (@), kaj ni nur parolos pri DevOps kaj mi dividos mian sperton.
Mi delonge pensas pri kiel utiligi mian rakonton, do estos multaj demandoj ĉi tie - tiuj, kiujn mi demandas al mi mem kaj tiujn, kiujn mi demandas al la klientoj de nia kompanio. Respondante ĉi tiujn demandojn, kompreno fariĝas pli bona. Mi diros al vi kial DevOps estas bezonata el mia vidpunkto, kio ĝi estas, denove, el mia vidpunkto, kaj kiel kompreni, ke vi denove moviĝas al DevOps el mia vidpunkto. La lasta punkto estos per demandoj. Respondante ilin mem, vi povas kompreni ĉu via kompanio moviĝas al DevOps aŭ ĉu iel estas problemoj.
Iam mi rajdis la ondojn de fuzioj kaj akiroj. Unue, mi laboris por malgranda ekentrepreno nomata Qik, poste ĝi estis aĉetita de iom pli granda kompanio nomata Skajpo, kiu tiam estis aĉetita de iomete pli granda kompanio nomata Microsoft. En tiu momento, mi komencis vidi kiel la ideo de DevOps transformiĝas en malsamaj grandecoj kompanioj. Post tio, mi interesiĝis pri rigardi DevOps el merkata vidpunkto, kaj miaj kolegoj kaj mi fondis la kompanion Express 42. De 6 jaroj ni moviĝas laŭ la ondoj de la merkato.
Interalie, mi estas unu el la organizantoj de la DevOps Moskva komunumo kaj la organizanto de DevOps-Tagoj 2017, sed mi ne organizis 2018. Express 42 funkcias kun multaj kompanioj. Ni kreskigas DevOps tie, rigardas kiel ĝi okazas, eltiras konkludojn, analizas, rakontas al ĉiuj niajn konkludojn kaj trejnas homojn pri DevOps-praktikoj. Ĝenerale, ni faras nian eblon por pliigi nian sperton kaj kompetentecon ĉi-rilate.
Kial DevOps
La unua demando, kiu plagas ĉiujn kaj ĉiam estas - kial? Multaj homoj pensas, ke DevOps estas nur aŭtomatigo aŭ simila afero, kiun ĉiu kompanio jam havis.
— Ni havis Daŭran Integriĝon - tio signifas, ke ni jam havis DevOps, kaj kial ĉio ĉi estas necesa? Ili amuziĝas eksterlande, sed ili malhelpas nin labori!
Dum 9 jaroj da evoluo de la komunumo kaj metodaro, jam evidentiĝis, ke tio ankoraŭ ne estas merkatado de briletoj, sed ankoraŭ ne estas tute klare kial ĝi estas bezonata. Kiel ajna ilo kaj procezo, DevOps havas specifajn celojn, kiujn ĝi finfine atingas.
Ĉio ĉi estas pro la fakto, ke la mondo ŝanĝiĝas. Li malproksimiĝas de la entreprena aliro, kiam kompanioj moviĝas rekte al revo, kiel kantis nia Peterburga klasikaĵo, de punkto A al punkto B laŭ certa strategio, kun certa strukturo konstruita por tio.
Principe ĉio en IT devus esti konstruita laŭ ĉi tiu aliro. Ĉi tie IT estas uzata ekskluzive por aŭtomatigi procezojn.
Aŭtomatigo ne ofte ŝanĝiĝas, ĉar kiam kompanio iras laŭ tre tretita vojo, kion ŝanĝi? Ĝi funkcias - ne tuŝu ĝin. Nun aliroj en la mondo ŝanĝiĝas, kaj tiu nomata Agile sugestas, ke finpunkto B ne tuj videblas.
Kiam firmao trairas la merkaton, laboras kun kliento, ĝi konstante esploras la merkaton kaj ŝanĝas la finpunkton B. Cetere, ju pli ofte la firmao ŝanĝas sian direkton, des pli sukcesas finfine, ĉar ĝi elektas pli da merkato. niĉoj.
La strategio estas pruvita de interesa kompanio, pri kiu mi ĵus eksciis. One Box Shave estas abona liverservo por raziloj kaj razakcesoraĵoj en skatolo. Ili scias kiel personecigi sian "skatolon" por malsamaj klientoj. Ĉi tio estas farita de certa programaro, kiu tiam sendas la mendon al la korea fabriko, kiu produktas la produkton.
Ĉi tiu produkto estis aĉetita de Unilever por 1 miliardo USD. Ĝi nun konkuras kun Gillette kaj forprenis gravan parton de konsumantoj en la usona merkato. One Box Shave diru:
— 4 klingoj? Ĉu vi serioze? Kial vi bezonas ĉi tion - ĝi ne plibonigas la kvaliton de la razado. Speciale elektita kremo, aromo kaj altkvalita razilo kun du klingoj solvas multe pli da problemoj ol tiuj stultaj 4 Gillette-klingoj! Ĉu ni baldaŭ atingos 10?
Jen kiel la mondo ŝanĝiĝas. Unilever asertas, ke ili havas bonegan IT-sistemon, kiu permesas vin fari tion. Fine ĝi aspektas kiel koncepto Tempo-al-merkato, pri kiu neniu jam parolis.
La punkto de Tempo-al-merkato ne estas kiom ofte ni deplojas. Vi ofte povas disfaldi, sed la eldoncikloj estos longaj. Se tri-monataj eldoncikloj estas supermetitaj unu al la alia, ŝanĝante ilin je semajno, rezultas, ke la kompanio ŝajnas deplojiĝi unufoje semajne. Kaj de la ideo ĝis la fina efektivigo necesas 3 monatoj.
Tempo-al-merkato temas pri minimumigo de la tempo de ideo ĝis fina efektivigo.
En ĉi tiu kazo, programaro interagas kun la merkato. Jen kiel la retejo de One Box Shave interagas kun la kliento. Ili ne havas vendistojn - nur retejon, kie vizitantoj klakas kaj lasas dezirojn. Sekve, io nova devas esti konstante afiŝita sur la retejo kaj ĝisdatigita laŭ deziroj. Ekzemple, en Sud-Koreio oni razas malsame ol en Rusio, kaj ili ŝatas la odoron ne de pino, sed, ekzemple, de karotoj kaj vanilo.
Ĉar necesas rapide ŝanĝi la enhavon de la retejo, la disvolviĝo de programaro multe ŝanĝiĝas. Per programaro ni devas ekscii, kion volas la kliento. Antaŭe, ni lernis ĉi tion per kelkaj ĉirkaŭvojoj, ekzemple, per komerca administrado. Tiam ni desegnis ĝin, metis la postulojn en la IT-sistemon, kaj ĉio estis bonega. Nun ĝi estas malsama - programaro estas desegnita de ĉiuj, kiuj partoprenas en la procezo, inkluzive de inĝenieroj, ĉar per teknikaj specifoj ili lernas kiel funkcias la merkato kaj ankaŭ dividas siajn komprenojn kun la komerco.
Ekzemple, ĉe Qik ni subite eksciis, ke homoj tre ŝatis alŝuti kontaktlistojn al la servilo, kaj ili provizis al ni aplikaĵon. Komence ni ne pensis pri tio. En klasika kompanio, ĉiuj estus decidintaj, ke ĉi tio estas cimo, ĉar la specifo ne diris, ke ĝi devus funkcii bonege kaj estis ĝenerale efektivigita sur la genuo, ili malŝaltus la funkcion kaj dirus: "Neniu bezonas ĉi tion, la plej grava afero estas, ke la ĉefa funkcieco funkcias.” . Kaj la teknologia kompanio vidas ĉi tion kiel ŝancon kaj komencas ŝanĝi la programaron laŭ ĉi tio.
En 1968, vizia ulo, Melvin Conway, formulis la sekvan ideon.
La organizo kiu kreas la sistemon estas limigita per dezajno kiu reproduktas la komunikadstrukturon de tiu organizo.
Pli detale, por produkti sistemojn de malsama tipo, vi ankaŭ devas havi komunikadan strukturon ene de firmao de malsama tipo. Se via komunika strukturo estas supro-hierarkia, tiam ĉi tio ne permesos al vi krei sistemojn, kiuj povas provizi tre altan Temp-al-Merkatan indikilon.
Legu povas . Ĝi estas grava por kompreni la kulturon aŭ filozofion DevOps ĉar la sola afero, kiu esence ŝanĝiĝas en DevOps, estas la strukturo de komunikado inter teamoj.
El proceza vidpunkto, antaŭ DevOps, ĉiuj etapoj: analizo, evoluo, testado, operacio, estis liniaj.
En la kazo de DevOps, ĉiuj ĉi tiuj procezoj okazas samtempe.
Tempo al merkatado estas la nura maniero kiel ĝi povas esti farita. Por homoj, kiuj laboris en la malnova procezo, tio aspektas iom kosma, kaj ĝenerale tiel tiel.
Do kial vi bezonas DevOps?
Por disvolvo de ciferecaj produktoj. Se via kompanio ne havas ciferecan produkton, DevOps ne estas bezonata - ĝi estas tre grava.
DevOps venkas la rapidlimojn de sinsekva softvarproduktado. En ĝi ĉiuj procezoj okazas samtempe.
Malfacilo pliiĝas. Kiam evangeliistoj de DevOps diras al vi, ke ĝi faciligos al vi liberigi programaron, tio estas sensencaĵo.
Kun DevOps, aferoj nur fariĝos pli komplikaj.
En la konferenco ĉe la stando de Avito, vi povis vidi kiel estis disfaldi Docker-ujon - nerealisma tasko. La komplekseco fariĝas malpermesa; vi devas ĵongli kun multaj pilkoj samtempe.
DevOps tute ŝanĝas la procezon kaj organizon en la kompanio — pli precize, ne DevOps ŝanĝiĝas, sed la cifereca produkto. Por veni al DevOps, vi ankoraŭ devas tute ŝanĝi ĉi tiun procezon.
Demandoj por specialisto
Kion vi havas? Demandoj, kiujn vi povas demandi al vi mem laborante en kompanio kaj evoluante kiel specialisto.
Ĉu vi havas strategion por krei ciferecan produkton? Se ekzistas, tio jam estas bona. Ĉi tio signifas, ke via kompanio moviĝas al DevOps.
Ĉu via kompanio jam kreas ciferecan produkton? Ĉi tio signifas, ke vi povas altiĝi alian nivelon pli alte kaj fari aferojn pli interese - denove el DevOps vidpunkto. Mi parolas nur el ĉi tiu vidpunkto.
Ĉu via kompanio estas unu el la merkataj gvidantoj en la cifereca produkta niĉo? Spotify, Yandex, Uber estas kompanioj, kiuj nun estas ĉe la pinto de teknologia progreso.
Demandu al vi ĉi tiujn demandojn, kaj se ĉiuj respondoj estas ne, tiam eble vi ne devus fari DevOps ĉe ĉi tiu kompanio. Se la temo de DevOps estas vere interesa por vi, eble... vi devus translokiĝi al alia kompanio? Se via kompanio volas eniri DevOps, sed vi respondis "Ne" al ĉiuj demandoj, tiam ĝi estas kiel tiu bela rinocero, kiu neniam ŝanĝiĝos.
organizo
Kiel mi diris, laŭ la Leĝo de Conway, la organizo de kompanio ŝanĝiĝas. Mi komencos per kio malhelpas DevOps enpenetri en la firmaon de la organiza vidpunkto.
La problemo de "putoj"
La angla vorto "Silo" estas tradukita ĉi tie en la rusan kiel "bone". La punkto de ĉi tiu problemo estas tio ne estas interŝanĝo de informoj inter teamoj. Ĉiu teamo fosas profunde en sia kompetenteco, sen konstrui komunan mapon por navigi.
Tio ĉi iel memorigas min pri homo, kiu ĵus alvenis en Moskvon kaj ankoraŭ ne scias kiel navigi la metromapon. Moskvanoj kutime tre bone konas sian regionon, kaj tra Moskvo ili povas navigi per la metromapo. Kiam vi venas al Moskvo por la unua fojo, vi ne havas ĉi tiun kapablon, kaj vi estas nur malorientita.
DevOps sugestas trapasi ĉi tiun momenton de malorientiĝo kaj ĉiuj fakoj kunlabori por konstrui komunan interagomapon.
Du faktoroj malhelpas ĉi tion.
Sekvo de la kompania administradsistemo. Ĝi estas konstruita en apartaj hierarkiaj "putoj". Ekzemple, estas certaj KPI-oj en kompanioj, kiuj subtenas ĉi tiun sistemon. Aliflanke, la cerboj de homo, kiu malfacilas preterpasi la limojn de sia kompetenteco kaj navigi la tutan sistemon, malhelpas. Estas nur malkomforta. Imagu, ke vi estas en Bangkok-flughaveno - vi ne trovos vian vojon rapide. DevOps ankaŭ estas malfacile navigebla, kaj tial homoj diras, ke vi devas trovi gvidilon por atingi tien.
Sed la plej grava afero estas, ke la problemo de "putoj" por inĝeniero, kiu estas trempita de la spirito de DevOps, legis Fowler kaj amason da aliaj libroj, estas esprimita en tio, ke "putoj" ne permesas al vi fari "evidentajn" aferojn. Ni ofte kunvenas post DevOps Moskvo, parolas unu kun la alia, kaj homoj plendas:
— Ni nur volis lanĉi CI, sed montriĝis, ke administrado ne bezonas ĝin.
Ĉi tio okazas ĝuste ĉar CI и Kontinua Livera Procezo estas ĉe la limo de multaj ekzamenoj. Simple sen venki la problemon de "putoj" je la organiza nivelo, vi ne povos antaŭeniri, negrave kion vi faras kaj kiom ajn malĝoja ĝi estas.
Ĉiu partoprenanto en la procezo en la firmao: backend kaj fasado programistoj, testado, DBA, operacio, reto, fosas en sia propra direkto, kaj neniu havas komunan mapon krom la administranto, kiu iel kontrolas ilin kaj administras ilin uzante la "divido". kaj konkeri” metodon.
Homoj batalas por iuj steloj aŭ flagoj, ĉiuj fosas sian kompetentecon.
Sekve, kiam aperas la tasko kunligi ĉion ĉi kune kaj konstrui komunan dukton, kaj ne plu necesas batali por steloj kaj flagoj, aperas la demando - kion fari ĉiuokaze? Ni devas iel interkonsenti, sed neniu instruis nin kiel fari tion en la lernejo. Ni estas instruitaj ekde la lernejo: oka klaso - uu! - kompare kun la sepa klaso! Estas same ĉi tie.
Ĉu estas same en via kompanio?
Por kontroli ĉi tion, vi povas demandi al vi la jenajn demandojn.
Ĉu teamoj uzas komunajn ilojn kaj kontribuas al ŝanĝoj al tiuj komunaj iloj?
Kiom ofte teamoj reorganizas—iuj specialistoj de unu teamo moviĝas al alia teamo? Ĝuste en DevOps-medio ĉi tio fariĝas normala, ĉar foje homo simple ne povas kompreni, kion faras alia kompetenteco. Li translokiĝas al alia fako, laboras tie du semajnojn por krei por si mapon de orientiĝo kaj interago kun ĉi tiu fako.
Ĉu eblas formi ŝanĝan komitaton kaj ŝanĝi aferojn? Aŭ ĉu ĝi postulas la fortan manon de la plej alta administrado kaj direkto? Mi ĵus skribis en Fejsbuko, kiel unu malmulte konata banko efektivigas ilojn per mendoj: ni skribas mendon, ni efektivigas ĝin dum jaro, kaj vidu kio okazas. Ĉi tio, kompreneble, estas longa kaj malĝoja.
Kiom gravas por administrantoj ricevi personajn atingojn sen konsideri la atingojn de la kompanio?
Se vi respondas ĉi tiujn demandojn por vi mem, estos pli klare ĉu vi havas tian problemon en via kompanio.
Infrastrukturo kiel kodo
Post kiam ĉi tiu problemo estas pasita, la unua grava praktiko, sen kiu estas malfacile antaŭeniri plu en DevOps, estas infrastrukturo kiel kodo.
Plej ofte, infrastrukturo kiel kodo estas perceptita jene:
— Ni aŭtomatigu ĉion en bash, kovru nin per skriptoj, por ke administrantoj havu malpli da manlaboro!
Sed tio ne estas vera.
Infrastrukturo kiel kodo signifas, ke vi priskribas la IT-sistemon kun kiu vi laboras en formo de kodo por konstante kompreni ĝian staton.
Kune kun aliaj teamoj, vi kreas mapon en formo de kodo, kiun ĉiuj povas kompreni kaj povas navigi kaj navigi. Ne gravas, pri kio ĝi estas farita - Chef, Ansible, Salt, aŭ uzante YAML-dosierojn en Kubernetes - ne estas diferenco.
En la konferenco, kolego de 2GIS rakontis kiel ili faris sian propran internan aferon por Kubernetes, kiu priskribas la strukturon de individuaj sistemoj. Por priskribi 500 sistemojn, ili bezonis apartan ilon, kiu generas ĉi tiun priskribon. Kiam ekzistas ĉi tiu priskribo, ĉiuj povas kontroli inter si, kontroli ŝanĝojn, kiel ŝanĝi ĝin kaj plibonigi ĝin, kio mankas.
Konsentu, individuaj bash-skriptoj kutime ne provizas ĉi tiun komprenon. En unu el la kompanioj, kie mi laboris, estis eĉ nomo por "skribi nur" skripto - kiam la skripto estas skribita, sed ne plu eblas legi ĝin. Mi pensas, ke ĉi tio ankaŭ estas konata al vi.
Infrastrukturo kiel kodo estas kodo kiu priskribas la nunan staton de la infrastrukturo. Multaj produktaj, infrastrukturoj kaj servaj teamoj laboras kune pri ĉi tiu kodo, kaj plej grave, ili ĉiuj bezonas kompreni kiel ĉi tiu kodo efektive funkcias.
La kodo estas konservita laŭ plej bonaj kodpraktikoj: komuna evoluo, koda revizio, XP-programado, testado, tirpetoj, CI por kodaj infrastrukturoj - ĉio ĉi taŭgas kaj uzeblas.
Kodo fariĝas komuna lingvo por ĉiuj inĝenieroj.
Ŝanĝi infrastrukturon en kodo ne prenas multan tempon. Jes, infrastruktura kodo ankaŭ povas havi teknikan ŝuldon. Kutime teamoj renkontas ĝin jaron kaj duonon post kiam ili komencis efektivigi "infrastrukturon kiel kodon" en la formo de amaso da skriptoj aŭ eĉ Ansible, kiujn ili skribas kiel spagetkodo, kaj ili ankaŭ ĵetas bash-skriptojn en la miksaĵon!
gravaj: Se vi ankoraŭ ne provis ĉi tion, memoru tion Ansible ne estas bato! Legu la dokumentaron atente, studu kion ili skribas pri ĝi.
Infrastrukturo kiel kodo estas la apartigo de infrastruktura kodo en apartajn tavolojn.
En nia kompanio, ni distingas 3 bazajn tavolojn, kiuj estas tre klaraj kaj simplaj, sed eble estas pli da ili. Vi povas rigardi vian infrastrukturan kodon kaj diri ĉu vi havas ĉi tiun kondiĉon aŭ ne. Se neniuj tavoloj estas reliefigitaj, tiam vi devas preni iom da tempo kaj refaktori iomete.
baza tavolo - jen kiel la OS, sekurkopioj kaj aliaj malaltnivelaj aferoj estas agorditaj, ekzemple, kiel Kubernetes estas deplojita ĉe la baza nivelo.
Servonivelo - ĉi tiuj estas la servoj, kiujn vi provizas al la programisto: ensalutu kiel servo, monitorado kiel servo, datumbazo kiel servo, ekvilibristo kiel servo, atendovico kiel servo, Daŭra livero kiel servo - amaso da servoj kiujn individuaj teamoj povas provizi al evoluo. Ĉi ĉio devas esti priskribita en apartaj moduloj en via agorda administra sistemo.
La tavolo kie aplikoj estas faritaj kaj priskribas kiel ili disvolviĝos super la antaŭaj du tavoloj.
Kontrolaj demandoj
Ĉu via kompanio havas komunan infrastrukturan deponejon? Ĉu vi administras teknikan ŝuldon en via infrastrukturo? Ĉu vi uzas evoluajn praktikojn en infrastruktura deponejo? Ĉu via infrastrukturo estas tranĉita en tavolojn? Vi povas kontroli la diagramon de Bazo-servo-APP. Kiom malfacile estas fari ŝanĝon?
Se vi spertis, ke necesas tago kaj duono por fari ŝanĝojn, tio signifas, ke vi havas teknikan ŝuldon kaj bezonas labori kun ĝi. Vi ĵus trafis teknikan ŝuldon en via infrastruktura kodo. Mi memoras multajn tiajn rakontojn, kiam, por ŝanĝi iun CCTL, vi bezonas reverki duonon de la infrastruktura kodo, ĉar kreivo kaj la deziro aŭtomatigi ĉion kondukis al tio, ke ĉio ĉie estas korodita, ĉiuj teniloj estas forigitaj, kaj necesas refaktorigi.
Kontinua Livero
Ni komparu debeton kun kredito. Unue venas priskribo de la infrastrukturo, kiu povas esti sufiĉe baza. Vi ne devas priskribi ĉion detale, sed iu baza priskribo necesas por ke vi povu labori kun ĝi. Alie, estas ne klare, kion fari kun daŭra livero poste. Ĉiuj ĉi tiuj praktikoj disvolviĝas samtempe kiam vi venas al DevOps, sed ĝi komenciĝas per kompreno, kion vi havas kaj kiel administri ĝin. Ĉi tio estas ĝuste la praktiko de infrastrukturo kiel kodo.
Post kiam evidentiĝas, ke vi havas ĝin kaj kiel administri ĝin, vi komencas eltrovi kiel sendi la programkodon al produktado kiel eble plej rapide. Mi volas diri kune kun la programisto - ni memoras pri la problemo de "putoj", tio estas, ne individuaj homoj kiuj elpensas ĉi tion, sed teamo.
Kiam ni estas kun Vanja Evtuĥoviĉ vidis la unuan libron Jez Humila kaj grupoj de aŭtoroj "Kontinua Livero", kiu estis publikigita en 2009, ni longe pensis pri kiel traduki ĝian titolon en la rusan. Ili volis traduki ĝin kiel "Konstante liveras", sed, bedaŭrinde, ĝi estis tradukita kiel "Daŭra livero". Ŝajnas al mi, ke estas io rusa en nia nomo, kun premo.
Senĉese liverante rimedojn
Kodo kiu estas en la produkta deponejo ĉiam povas esti elŝutita al produktado. Li eble ne estas malŝveligita, sed li ĉiam estas preta por tio. Sekve, vi ĉiam skribas kodon kun malfacile klarigebla sento de ioma angoro sub via vosto. Ĝi ofte aperas kiam vi lanĉas infrastrukturan kodon. Ĉi tiu sento de ioma angoro devus ĉeesti - ĝi ekigas cerbajn procezojn, kiuj permesas vin skribi kodon iomete alie. Ĉi tio devus esti registrita en la reguloj ene de la evoluo.
Por konstante liveri, vi bezonas artefaktan formaton, kiu funkcias tra infrastruktura platformo. Se vi ĵetas "vivan rubon" de malsamaj formatoj tra infrastruktura platformo, tiam ĝi iĝas unuigita, estas malfacile konservi, kaj la problemo de teknika ŝuldo ekestas. La formato de la artefakto devas esti vicigita - tio ankaŭ estas kolektiva tasko: ni ĉiuj devas kunveni, susuri nian cerbon kaj elpensi ĉi tiun formaton.
La artefakto estas kontinue plibonigita kaj ŝanĝiĝas por konveni al la produktadmedio dum ĝi moviĝas tra la livera dukto. Kiam artefakto moviĝas laŭ la dukto, ĝi konstante renkontas kelkajn maloportunajn aferojn por ĝi, kiuj similas al tio, kion la artefakto, kiun vi metas en produktadon, renkontas. Se en klasika evoluo tio estas farita de sistemadministranto, kiu faras la lanĉon, tiam en la DevOps-procezo tio okazas ĉiam: jen ili testis ĝin per kelkaj testoj, jen ili ĵetis ĝin en Kubernetes-areton, kiu pli-malpli similas. al produktado, tiam subite ili komencis ŝarĝtestadon.
Ĉi tio iom rememorigas la ludon Pac-Man - la artefakto trairas ian historion. Samtempe, gravas kontroli ĉu la kodo efektive trairas la rakonton kaj ĉu ĝi iel rilatas al via produktado. Rakontoj de produktado povas esti trenitaj en la Daŭran Liveran procezon: estis tiel kiam io falis, nun ni nur programu ĉi tiun scenaron ene de la sistemo. Ĉiufoje la kodo trairos ĉi tiun scenaron ankaŭ, kaj vi ne renkontos ĉi tiun problemon venontfoje. Vi lernos pri ĝi multe pli frue ol ĝi atingos vian klienton.
Malsamaj deplojstrategioj. Ekzemple, vi uzas AB-testadon aŭ kanariajn deplojojn por testi la kodon alimaniere ĉe malsamaj klientoj, akiri informojn pri kiel la kodo funkcias, kaj multe pli frue ol kiam ĝi estas lanĉita al 100 milionoj da uzantoj.
"Konstante liveru" aspektas tiel.
La livera procezo Dev, CI, Test, PreProd, Prod ne estas aparta medio, ĉi tiuj estas stadioj aŭ stacioj kun fajrorezistaj sumoj tra kiuj via artefakto pasas.
Se vi havas infrastrukturan kodon, kiu estas priskribita kiel Bazserva APP, tiam ĝi helpas ne forgesu ĉiujn skriptojn, kaj skribu ilin kiel kodon por ĉi tiu artefakto, promocii artefakton kaj ŝanĝu ĝin dum vi iras.
Memtestaj demandoj
La tempo de ĉefpriskribo ĝis liberigo en produktadon en 95% de kazoj estas malpli ol semajno? Ĉu la kvalito de la artefakto pliboniĝas en ĉiu etapo de la dukto? Ĉu estas rakonto, kiun ĝi trairas? Ĉu vi uzas malsamajn deplojajn strategiojn?
Se ĉiuj respondoj estas jes, tiam vi estas nekredeble mojosa! Skribu viajn respondojn en la komentoj - mi ĝojos).
Retrosciigo
Ĉi tio estas la plej malfacila praktiko el ĉiuj. En la konferenco DevOpsConf, kolego de Infobip, parolante pri ĝi, estis iomete konfuzita en siaj vortoj, ĉar ĉi tio vere estas tre kompleksa praktiko pri tio, ke vi bezonas ĉion kontroli!
Ekzemple, antaŭ longe, kiam mi laboris ĉe Qik kaj ni rimarkis, ke ni bezonas kontroli ĉion. Ni faris tion, kaj ni nun havas 150 erojn en Zabbix, kiuj estas konstante monitoritaj. Estis timige, la teknika direktoro tordis sian fingron ĉe sia tempio:
- Knaboj, kial vi seksperfortas la servilon per io neklara?
Sed tiam okazis okazaĵo, kiu montris, ke tio vere estas tre bonega strategio.
Unu el la servoj komencis kraŝi konstante. Komence, ĝi ne kraŝis, kio estas interese, la kodo ne estis aldonita tie, ĉar ĝi estis baza makleristo, kiu havis preskaŭ neniun komercan funkciojn - ĝi simple sendis mesaĝojn inter unuopaj servoj. La servo ne ŝanĝiĝis dum 4 monatoj, kaj subite ĝi komencis kraŝi kun la eraro "Segmenta misfaro".
Ni estis ŝokitaj, malfermis niajn leterojn en Zabbix, kaj montriĝis, ke antaŭ semajno kaj duono, la konduto de petoj en la API-servo, kiun ĉi tiu broker uzas, multe ŝanĝiĝis. Poste ni vidis, ke la ofteco de sendo de certa speco de mesaĝo ŝanĝiĝis. Poste ni eksciis, ke ĉi tiuj estas androidaj klientoj. Ni demandis:
— Knaboj, kio okazis al vi antaŭ semajno kaj duono?
Responde, ni aŭdis interesan rakonton pri kiel ili restrukturis la UI. Estas neverŝajne, ke iu tuj diros, ke ili ŝanĝis la HTTP-bibliotekon. Por Android-klientoj, ĝi estas kiel ŝanĝi sapon en la banĉambro - ili simple ne memoras. Rezulte, post 40 minutoj da konversacio, ni eksciis, ke ili ŝanĝis la HTTP-bibliotekon, kaj ĝiaj defaŭltaj tempoj ŝanĝiĝis. Ĉi tio kaŭzis ŝanĝiĝon de la trafika konduto sur la API-servilo, kio kaŭzis situacion, kiu kaŭzis vetkuron ene de la makleristo, kaj ĝi komencis kraŝi.
Sen profunda monitorado estas ĝenerale neeble malfermi ĉi tion. Se la organizo ankoraŭ havas la problemon de "putoj", kiam ĉiuj ĵetas monon unu al la alia, tio povas vivi dum jaroj. Vi simple rekomencas la servilon ĉar estas neeble solvi la problemon. Kiam vi kontrolas, spuras, spuras ĉiujn eventojn, kiujn vi havas, kaj uzas monitoradon kiel testadon - skribu kodon kaj tuj indikas kiel kontroli ĝin, ankaŭ en formo de kodo (ni jam havas la infrastrukturon kiel kodon), ĉio evidentiĝas kiel sur la manplato. Eĉ tiaj kompleksaj problemoj estas facile spuritaj.
Kolektu ĉiujn informojn pri kio okazas al la artefakto en ĉiu etapo de la livera procezo - ne en produktado.
Alŝutu la monitoradon al CI, kaj iuj bazaj aferoj jam estos videblaj tie. Poste vi vidos ilin en Testo, PredProd kaj ŝarĝo-testado. Kolektu informojn en ĉiuj stadioj, ne nur metrikojn, statistikojn, sed ankaŭ protokolojn: kiel la aplikaĵo disvolviĝis, anomalioj - kolektu ĉion.
Alie, estos malfacile eltrovi ĝin. Mi jam diris, ke DevOps estas pli kompleksa. Por trakti ĉi tiun kompleksecon, vi devas havi normalajn analizojn.
Demandoj por memregado
Ĉu via monitorado kaj registrado estas la evoluilo por vi? Kiam vi verkas kodon, ĉu viaj programistoj, inkluzive de vi, pensas pri kiel kontroli ĝin?
Ĉu vi aŭdas pri problemoj de klientoj? Ĉu vi pli bone komprenas la klienton de monitorado kaj registrado? Ĉu vi pli bone komprenas la sistemon de monitorado kaj registrado? Ĉu vi ŝanĝas la sistemon simple ĉar vi vidis, ke la tendenco en la sistemo kreskas kaj vi komprenas, ke post aliaj 3 semajnoj ĉio mortos?
Post kiam vi havas ĉi tiujn tri komponantojn, vi povas pensi pri kia infrastruktura platformo vi havas en via kompanio.
Infrastruktura platformo
La punkto ne estas, ke ĝi estas aro de malsimilaj iloj, kiujn ĉiu kompanio havas.
La punkto de infrastruktura platformo estas, ke ĉiuj teamoj uzas ĉi tiujn ilojn kaj disvolvas ilin kune.
Estas klare, ke ekzistas apartaj teamoj, kiuj respondecas pri la disvolviĝo de individuaj pecoj de la infrastruktura platformo. Sed samtempe ĉiu inĝeniero portas respondecon pri la disvolviĝo, agado kaj promocio de la infrastruktura platformo. Sur interna nivelo ĝi fariĝas komuna ilo.
Ĉiuj teamoj disvolvas la infrastrukturan platformon kaj zorge traktas ĝin kiel sian propran IDE. En via IDE vi instalas malsamajn kromaĵojn por fari ĉion bela kaj rapida, kaj agordi klavojn. Kiam vi malfermas Sublime, Atom aŭ Visual Studio Code, kodaj eraroj enfluas kaj vi rimarkas, ke tute ne eblas labori, vi tuj sentas malĝojon kaj vi kuras por ripari vian IDE.
Traktu vian infrastrukturan platformon same. Se vi komprenas, ke estas io malbona kun ĝi, lasu peton se vi ne povas ripari ĝin mem. Se estas io simpla, redaktu ĝin mem, sendu tiran peton, la infanoj konsideros ĝin kaj aldonos ĝin. Ĉi tio estas iomete malsama aliro al inĝenieraj iloj en la kapo de la programisto.
La infrastruktura platformo certigas la translokigon de la artefakto de evoluo al la kliento kun kontinua plibonigo de kvalito. La IP estas programita kun aro de rakontoj kiuj okazas al la kodo en produktado. Dum la jaroj de evoluo, ekzistas multaj ĉi tiuj rakontoj, kelkaj el ili estas unikaj kaj rilatas nur al vi - ili ne povas esti Gugloditaj.
Je ĉi tiu punkto, la infrastruktura platformo fariĝas via konkurenciva avantaĝo, ĉar ĝi havas ion konstruitan en ĝi, kio ne estas en la ilo de la konkuranto. Ju pli profunde via IP, des pli granda estas via konkurenciva avantaĝo laŭ Tempo-al-merkato. Aperas ĉi tie problemo de vendoŝlosilo: Vi povas preni la platformon de iu alia, sed uzante la sperton de iu alia, vi ne komprenos kiom grava ĝi estas por vi. Jes, ne ĉiu kompanio povas konstrui platformon kiel Amazon. Ĉi tio estas malfacila linio, kie la sperto de la kompanio rilatas al sia pozicio en la merkato, kaj vi ne povas uzi vendistan seruron tie. Ĉi tio ankaŭ gravas pripensi.
Skemo
Ĉi tio estas baza diagramo de infrastruktura platformo, kiu helpos vin agordi ĉiujn praktikojn kaj procezojn en kompanio DevOps.
Ni rigardu el kio ĝi konsistas.
Sistemo de orkestrado de rimedoj, kiu provizas CPU, memoron, diskon al aplikoj kaj aliaj servoj. Aldone al ĉi tio - servoj de malalta nivelo: monitorado, arbodehakado, CI/KD-Motoro, artefaktostokado, infrastrukturo kiel sistemkodo.
Servoj de pli alta nivelo: datumbazo kiel servo, atendovicoj kiel servo, Load Balance kiel servo, bildo regrandigo kiel servo, Big Data fabriko kiel servo. Aldone al ĉi tio - dukto kiu liveras konstante modifitan kodon al via kliento.
Vi ricevas informojn pri kiel via programaro funkcias por la kliento, ŝanĝas ĝin, liveras ĉi tiun kodon denove, ricevas informojn - kaj tiel vi konstante disvolvas kaj la infrastrukturan platformon kaj vian programaron.
En la diagramo, la livera dukto konsistas el multaj stadioj. Sed ĉi tio estas skema diagramo, kiu estas donita kiel ekzemplo - ne necesas ripeti ĝin unu post la alia. Etapoj interagas kun servoj kvazaŭ ili estus servoj - ĉiu briko de la platformo portas sian propran rakonton: kiel rimedoj estas asignitaj, kiel la aplikaĵo estas lanĉita, funkcias kun resursoj, estas monitorita kaj ŝanĝiĝas.
Gravas kompreni, ke ĉiu parto de la platformo portas rakonton, kaj demandu vin, kian rakonton portas ĉi tiu briko, eble ĝi devus esti forĵetita kaj anstataŭigita per triaparta servo. Ekzemple, ĉu eblas instali Okmeter anstataŭ brikon? Eble la uloj jam evoluigis ĉi tiun kompetentecon multe pli ol ni. Sed eble ne - eble ni havas unikan kompetentecon, ni devas instali Prometheus kaj disvolvi ĝin plu.
Kreo de la platformo
Ĉi tio estas kompleksa komunika procezo. Kiam vi havas bazajn praktikojn, vi komencas komunikadon inter malsamaj inĝenieroj kaj specialistoj, kiuj disvolvas postulojn kaj normojn, kaj konstante ŝanĝas ilin al malsamaj iloj kaj aliroj. La kulturo, kiun ni havas en DevOps, estas grava ĉi tie.
Kun kulturo ĉio estas tre simpla - temas pri kunlaboro kaj komunikado, tio estas, la deziro labori en komuna kampo unu kun la alia, la deziro uzi unu instrumenton kune. Ĉi tie ne ekzistas raketscienco - ĉio estas tre simpla, banala. Ekzemple, ni ĉiuj loĝas en la enirejo kaj tenas ĝin pura – tia nivelo de kulturo.
Kion vi havas?
Denove, demandoj vi povas demandi vin mem.
Ĉu la infrastruktura platformo estas dediĉita? Kiu respondecas pri ĝia evoluo? Ĉu vi komprenas la konkurencivajn avantaĝojn de via infrastruktura platformo?
Vi devas konstante demandi al vi ĉi tiujn demandojn. Se io povas esti transdonita al triaj servoj, ĝi devus esti transdonita; se triaparta servo komencas bloki vian movadon, tiam vi devas konstrui sistemon en vi mem.
Do, DevOps...
... ĉi tio estas kompleksa sistemo, ĝi devas havi:
- Cifereca produkto.
- Komercaj moduloj, kiuj disvolvas ĉi tiun ciferecan produkton.
- Produktteamoj kiuj skribas kodon.
- Kontinuaj Liveraj praktikoj.
- Platformoj kiel servo.
- Infrastrukturo kiel servo.
- Infrastrukturo kiel kodo.
- Apartaj praktikoj por konservi fidindecon, konstruitajn en DevOps.
- Retrosciiga praktiko, kiu priskribas ĉion.
Vi povas uzi ĉi tiun diagramon, elstarigante en ĝi tion, kion vi jam havas en via kompanio en iu formo: ĉu ĝi disvolviĝis aŭ ankoraŭ bezonas disvolviĝi.
Ĝi finiĝos post kelkaj semajnoj . kiel parto de RIT++. Venu al la konferenco, kie vi trovos multajn bonegajn raportojn pri kontinua liverado, infrastrukturo kiel kodo kaj DevOps-transformo. , lasta preza limdato estas la 20-a de majo
fonto: www.habr.com