Mis on DevOps

DevOps'i määratlemine on väga keeruline, mistõttu tuleb seda igal korral uuesti arutada. Ainult Habr'ist leiate tuhandeid selle teema avaldusi. Kuid kui te seda loete, siis teate kindlasti, mis on DevOps. Sest mina - ei tea. Tere, minu nimi on Aleksandr Titov (@osminog), ja me räägime lihtsalt DevOps'ist ja jagan oma kogemusi.

Olin pikka aega mõelnud, kuidas muuta oma jutt kasulikuks, seega on siin palju küsimusi - neid, mida ma endale esitan, ja neid, mida esitan meie ettevõtte klientidele. Neile küsimustele vastates saavad arusaamad selgemaks. Räägin, miks on DevOps vajalik minu vaatenurgast, mis see on, jälle minu positsioonist, ja kuidas mõista, kas teie ettevõte liigub taas DevOps'i suunas minu vaatenurgast. Viimane punkt tuleb küsimuste kaudu. Vastates neile endale, saate aru, kas teie ettevõte liigub DevOps'i suunas või on milleski probleeme.

Mingil ajal navigeerisin ühinemiste ja omandamiste lainetel. Esiteks töötasin väikeses idufirmas Qik, mille seejärel ostis veidi suurem ettevõte Skype, mille seejärel ostis veelgi suurem ettevõte Microsoft. Selle hetke jooksul sain aimu, kuidas DevOps'i arusaam erineva suurusega ettevõtetes muutub. Pärast seda tekkis mul huvi DevOps'i turu poole vaatamine ja koos kolleegidega korraldasime ettevõtte Ekspress 42. Oleme juba 6 aastat sellel turul lainetel liikunud.

Lisaks olen üks DevOps Moscow kogukonna korraldajatest ja 2017. aasta DevOps Days'i korraldaja, kuid 2018. aastal ei korraldanud ma. Ekspress 42 teeb koostööd paljude ettevõtetega. Arendame seal DevOps'i, vaatame, kuidas see toimub, teeme järeldusi, analüüsime, jagame oma järeldusi kõigile, koolitame inimesi DevOps'i praktikate osas. Ühesõnaga, kasvame selles osas kogemusi ja ekspertiisi.

Miks DevOps

Esimene küsimus, mis kõiki alati kummitab - miks? Paljud arvavad, et DevOps on lihtsalt automatiseerimine või sarnane asi, mis juba igas ettevõttes olemas on.

- Meil oli pidev integratsioon - see tähendab, et DevOps oli juba olemas, miks on siis kogu see jama vajalik? Seal välismaal lõbutsetakse, aga meile takistatakse tööd!

9 aasta jooksul arendatud kogukonna ja metoodika käigus on selgeks saanud, et see ei ole pelgalt turunduspettus, kuid siiani ei ole täielikult selge, miks see vajalik on. Nagu igal võtmel ja protsessil, on DevOps-il konkreetsed eesmärgid, mida ta lõpuks saavutab.

See kõik on seotud sellega, et maailm muutub. See liigub eemale ettevõtte lähenemisest, kus ettevõtted liiguvad otse unistuste suunas, nagu laulis meie peterburilik klassik, punktist A punkti B kindla strateegia kaudu, mille jaoks on loodud määratud struktuur.

Põhimõtteliselt peaks IT kõike seda lähenemist järgima. Siin kasutatakse IT-d ainult protsesside automatiseerimiseks.

Automatiseerimine ei muutu sageli, kuna kui ettevõte liigub kindlat rada pidi — mis seal siis muuta? Kui see töötab, ära puutu. Praegu maailmas lähenemised muutuvad, ja see, mida nimetatakse Agile'iks, ütleb, et lõpp-punkti B ei ole kohe nähtav.

Kui ettevõte liigub turul, suhtleb klientidega — ta uurib pidevalt turgu ja muudab lõpp-punkti B. Mida tihedamalt ettevõte oma suunda muudab, seda rohkem see lõpuks õnnestub, kuna ta valib rohkem turunišše.

Strateegiat demonstreerib huvitav ettevõte, millest ma hiljuti kuulsin. One Box Shave — tellimuste järgi raseerimisvahendite ja -tarvikute kohaldamise teenus. Nad oskavad kohandada oma "karpi" erinevatele klientidele. Sellega tegeleb kindel tarkvara, mis saadab seejärel tellimuse Korea tehasesse, kus toodet valmistatakse.

Selle toote ostis ettevõte Unilever 1 miljardi dollari eest. Nüüd konkurseerib see Gillette'iga ja on võtnud USA turul sellelt olulise osa tarbijatest. One Box Shave ütleb:

— 4 tera? Oled tõsiselt? Miks sul seda vaja on — see ei paranda kvaliteeti raseerimise. Spetsiaalselt valitud kreem, lõhnaine ja kvaliteetne raseerija kahe teraga lahendavad palju rohkem probleeme kui need rumalad 4 tera Gillette'il! Varsti jõuame 10 tera juurde?

Nii muutub maailm. Unilever teatab, et neil on lahe IT-süsteem, mis võimaldab seda teha. Lõpuks näeb see välja nagu kontseptsioon Time-to-market, millest on juba rääkinud, kes iganes.

Time-to-market mõte ei seisne selles, kui sageli me välja anname. Sageli võib välja anda, kuid sel juhul on väljaandetsüklid pikad. Kui kolme kuu väljaandetsüklid üksteise peale asetada, nihutades nädalakese, tundub nagu ettevõte väljastab kord nädalas. Ent idee ja lõpliku teostamise vahele jääb 3 kuud.

Time-to-market tähendab aega, mis kulub ideest lõpliku teostamiseni.

Selles juhul suhtleb turuga tarkvara. Nii nagu One Box Shave'i puhul suhtleb kliendiga veebisait. Neil pole müüjaid - lihtsalt veebisait, kus külastaja klõpsab ja jätab oma soovid. Seetõttu tuleb veebisaidil pidevalt midagi uut avaldada, et see vastaks soovidele. Näiteks Lõuna-Koreas habetakse teisiti kui Venemaal, ja neile meeldib ei ole männi, vaid näiteks porgandi vanilli lõhn.

Kuna tuleb kiiresti muuta veebisaidi sisu, muutub tarkvara arendus oluliselt. Tarkvara kaudu peame teada saama, mida klient soovib. Varem saime me seda teada ringteed pidi, näiteks ärijuhtimise kaudu. Siis projekteerisime, panime nõuded IT-süsteemi ja kõik oli suurepärane. Praegu on see aga teisiti - tarkvara projekteerivad kõik, kes on protsessis kaasatud, sealhulgas insenerid, sest nad saavad tehniliste omaduste kaudu teada, kuidas turg töötab, ja jagavad äriga oma teadmisi.

Näiteks ettevõttes Qik saime äkki teada, et inimestele meeldib väga kontaktloendeid serverisse üles laadida, ja nad andsid meile rakenduse. Me ei olnud algselt selle peale mõelnud. Kliendiga tegelevas ettevõttes oleks kõik arvanud, et see on viga, kuna spetsiifikas ei olnud kirjutatud, et see peab hästi töötama, ja see oli üldiselt teostatud kiirustades, oleks funktsioon välja lülitatud ja öeldud: „See pole kellelegi vajalik, peamine on, et peamine funktsionaalsus töötab“. Ahnates tehnoloogiaettevõtte näeb sellises olukorras võimalust ja hakkab tarkvara vastavalt sellele muutma.

1968. aastal sõnastas ettevaatlik mees Melvin Conway järgmise idee.

Organisatsioon, mis loob süsteemi, on piiratud selle disainiga, mis kopeerib kommunikatsioonistruktuuri selles organisatsioonis.

Kui rääkida lähemalt, et toota teist tüüpi süsteeme, peab olema ka ettevõttes teistsugune suhtlemisstruktuur. Kui teie suhtlemisstruktuur on pealiskaudne ja hierarhiline, ei võimalda see teil luua süsteeme, mis suudavad tagada väga kõrge Time-to-market.

Lugege Conway seadusest saab linkide kaudu. See on oluline DevOpsi kultuuri või filosoofia mõistmiseks, kuna ainsus, mis DevOpsis fundamentaalselt muutub, on just suhtlemise struktuur meeskondade vahel..

Protsessi vaatenurgast on kogu DevOpsi eelnevad etapid: analüüs, arendus, testimine, kasutuselevõtt, toimunud lineaarselt.
DevOpsi puhul toimuvad kõik need protsessid samal ajal.

Time-to-market saab täidetud ainult nii. Inimestele, kes on töötanud vanas protsessis, tundub see natuke ulmelisena ja üldiselt mitte just meeldivana.

Aga miks on vaja DevOpsi?

Digitaalsete toodete arendamiseks. Kui teie ettevõttes ei ole digitaalset toodet, ei ole DevOps vajalik – see on väga oluline.

DevOps ületab tarkvaratootmise järjestikuste meetodite kiiruspiiranguid. Kõik protsessid toimuvad samal ajal.

Suurenev keerukus. Kui DevOpsi evangelistid räägivad, et sellega on teil lihtsam tarkvara välja anda – see on jama.

DevOpsiga muutub kõik ainult keerulisemaks.

Konverentsil võis Avito stendil näha, mis on Docker-konteineri üles seadmine – uskumatu ülesanne. Keerukus muutub ületamatuks, tuleb samal ajal peksta mitut palli.

DevOps muudab täielikult protsessi ja korralduse ettevõttes – täpsemalt mitte DevOps, vaid digitaalne toode. Et jõuda DevOpsini, tuleb see protsess täielikult muuta.

Küsimused spetsialistile

Aga mis teil on? Küsimused, mida saate endale esitada, töötades ettevõttes ja enesearendades spetsialistina.

Kas teil on digitaalsete toodete loomise strateegia? Kui on – juba hea. See tähendab, et teie ettevõte liigub DevOpsi suunas.

Kas teie ettevõte juba loob digitaalset toodet? See tähendab, et saate tõusta veel ühele astmele kõrgemale, tegutseda huvitavamate asjade kallal – DevOpi vaatenurgast. Räägin ainult sellest vaatenurgast.

Kas teie ettevõte on üks turuliidritest digitaalsete toodete nišis? Spotify, Yandex, Uber — ettevõtted, mis on praegu tehnoloogilise edusamme tipus.

Küsi endalt neid küsimusi, ja kui kõik vastused on eitavad, siis võib-olla ei tasu sul DevOpsiga selle ettevõtte juures tegeleda. Kui aga sind DevOps tõeliselt huvitab, võib-olla… peaksid sa minema teise ettevõttesse? Kui sinu ettevõte soovib minna DevOpsi suunas, aga oled kõigile küsimustele vastanud „Ei”, siis sarnaneb see toreda ninasarvikuga, kes ei muutu kunagi.

Organisatsioon

Nagu ma juba ütlesin, muutub ettevõttes organisatsioon Conwy seaduse kohaselt. Alustan sellest, mis takistab DevOpsi tungimist ettevõtte sisemusse just organisatsiooni seisukohalt.

„Silo” probleem

Inglise sõna „Silo” on siin tõlgitud vene keelde kui „колодец”. Probleemi mõte on selles, et meeskondade vahel ei toimu teabe vahetust. Iga meeskond kaevab oma ekspertiseerimist sügavale, ehitamata samas ühist kaarti, mille järgi orienteeruda.

See meenutab inimest, kes just saabus Moskvasse ja ei oska veel metrookaardi järgi orienteeruda. Moskvast pärit inimesed tunnevad oma piirkonda tavaliselt hästi, aga kogu Moskva piires orienteeruvad nad metrookaardi järgi. Kui sa tuled Moskvasse esmakordselt, puudub see oskus ning sa oled lihtsalt segaduses.

DevOps kutsub üles minema läbi selle segaduse hetke ning koostama kõigil osakondadel koos ühise suhtlemiskaardi.

Sellele takistavad kaks tegurit.

Korporatiivse juhtimissüsteemi tagajärg. See on üles ehitatud eraldi hierarhiliste „siloide” peale. Näiteks on ettevõtetes teatud KPI-d, mis seda süsteemi toetavad. Teiselt poolt takistavad inimese mõtted, kellel on keeruline välja astuda oma ekspertiseerimisest ja orienteeruda kogu süsteemis. See on lihtsalt ebamugav. Kujutage ette, et olete sattunud Bangkokis asuvasse lennujaama — seal ei orienteeru kiiresti.

DevOpsis on samuti keeruline orienteeruda, ja seetõttu ütlevad inimesed, et on vaja leida giid, et sinna pääseda. Kuid kõige olulisem on see, et „siloide” probleem insenerile, kes on mõistnud DevOpsi vaimu, lugenud Fowlerit ja palju teisi raamatuid, väljendub selles, et„siloid” ei luba teha „ilmseid” asju. Me koguneme sageli pärast DevOps Moskvast, suhtleme omavahel ning inimesed kurdavad:

— Me lihtsalt tahtsime CI-d käivitada, aga juhtkonnale ei ole see vajalik.

See juhtub just seetõttu, et CI ja Continuous Delivery protsess asuvad paljude ekspertide piiril. Lihtsalt, kui ei suudeta probleem 'kaevudest' organisatsiooni tasandil ületada, ei õnnestu edasi liikuda, ükskõik mida teete ja kui kurb see ka pole.

Iga protsessi osaline ettevõttes: tagaplaneerijad ja esiplaneerijad, testimine, DBA, tegevus, võrk, kaevavad oma suunas, kuid ühtegi üldkaarti pole kellelgi, välja arvatud juht, kes neid kuidagi jälgib ja haldab meetodiga 'jaga ja vali'.

Inimesed võitlevad mingite tähede või lippude pärast, igaühel on oma ekspertiza.

Lõpuks, kui tekib ülesanne kõik see kokku tuua ja ehitada üldine torujuhe, ning tähete ja lippude pärast enam ei pea võitlema, tekib küsimus - mida nüüd teha? Kuidas leppida kokku, aga seda ei õpetanud meile koolis. Oleme juba koolist harjunud: kaheksas klass - ohhoo! - võrreldes seitsmenda klassiga! Siin on sama.

Kas on teie ettevõttes samuti?

Seda kontrollimiseks võite esitada endale järgmised küsimused.

Kas meeskonnad kasutavad ühiseid tööriistu, panustavad nad nende ühiste tööriistade muudatustesse?

Kui sageli meeskonnad ümber käivad - mõned spetsialistid ühest meeskonnast lähevad teise meeskonda? Just DevOps keskkonnas muutub see normaalseks, sest mõnikord ei saa inimene lihtsalt aru, millega teine ekspertiis tegeleb. Ta läheb teise osakonda, töötab seal paar nädalat, et luua endale orienteerumise ja suhtlemise kaart selle osakonnaga.

Kas on võimalik luua muudatuste komitee ja midagi muuta? Või on selleks vaja tugevat kätt kõrgeimast juhtkonnast ja korraldust? Hiljuti kirjutasin Facebookis, kuidas üks vähetuntud pank läbi korralduste tööriistu rakendab: kirjutasime korralduse, rakendame aasta, vaatame, mis juhtub. See on loomulikult pikk ja kurb.

Kui oluline on juhtide jaoks saada isiklikke saavutusi, arvestamata ettevõtte saavutusi?

Kui te neile küsimustele vastate, on parem arusaamine sellest, kas teil on ettevõttes selline probleem.

Infrastruktuur kui kood

Pärast seda, kui see probleem on lahendatud, on esimene oluline praktika, ilma milleta on keeruline DevOpsis edasi liikuda, infrastruktuur kui kood.

Kuna infrastruktuuri kui koodi mõistetakse sageli järgmiselt:

— Automaatige kõik bash'is, katke end skriptidega, et administraatoritel oleks vähem käsitsi tööd!

Kuid see ei ole tõsi.

Infrastruktuur kui kood tähendab, et IT-süsteem, millega te töötate, kirjeldatakse koodina, et pidevalt mõista selle seisundit.

Koos teiste meeskondadega loote koodi kujul kaardi, mis on kõigile arusaadav ja mille kaudu saab orienteeruda ja navigeerida. Pole vahet, kas see on tehtud Chef'i, Ansible'i, Salt'i abil või kasutatakse YAML-faile Kubernetes'is — vahet pole.

Konverentsil rääkis kolleeg 2GIS-st, kuidas nad lõid oma sisemise tööriista Kubernetes'i jaoks, mis kirjeldab üksikute süsteemide ülesehitust. 500 süsteemi kirjeldamiseks vajasid nad eraldi tööriista, mis selle kirjelduse genereerib. Kui see kirjeldus on olemas, saavad kõik üksteisega võrrelda, jälgida muudatusi, kuidas seda muuta ja täiustada, millest puudu jääb.

Olge nõus, eraldi bash-skriptid ei anna tavaliselt seda arusaamist. Ühes ettevõttes, kus ma töötasin, oli isegi nimetus "write only"-skript — kui skript on kirjutatud, siis ei saa seda enam lugeda. Ma arvan, et see on teile samuti tuttav.

Infrastruktuur kui kood on kood, mis kirjeldab infrastruktuuri tegelikku seisundit. Selle koodi kallal töötab koos hulk toote-, infrastruktuuri- ja teenuste meeskondi ning kõige tähtsam on, et kõik nad peavad mõistma, kuidas see kood üldse töötab.

Kood on dokumenteeritud parimate kooditöötluspraktikate järgselt: koostöö arendus, koodivaatlus, XP-programmeerimine, testimine, pull-requestid, CI infrastruktuuri koodi jaoks — see kõik on hea ja seda saab kasutada.

Koodist saab kõikide inseneride ühine keel.

Infrastruktuuri muutmine koodis ei võta palju aega. Jah, infrastruktuuri koodis võib samuti olla tehniline võlg. Tavaliselt kohtavad meeskonnad seda umbes poolteise aasta pärast, kui nad on hakanud rakendama "infrastruktuuri kui kood" kujul hunnik skripte või isegi Ansible'i, mille nad kirjutavad nagu spagetikood, ja lisavad sinna veel bash-skripte.

Oluline: kui te pole seda jama veel proovinud, pidage meeles, et Ansible ei ole bash! Lugege hoolikalt dokumentatsiooni, uurige, mida selle kohta üldiselt kirjutatakse.

Infrastruktuur kui kood on infrastruktuurikoodi jagamine eraldi kihtideks.

Meie ettevõttes eristame kolme põhikihti, mis on hästi arusaadavad ja lihtsad, kuid neid võib olla rohkem. Saate vaadata oma infrastruktuurikoodi ja öelda, kas teil on see tingimus või mitte. Kui kihte ei ole eristatav, siis tuleb leida aega ja natuke refaktoreerida.


Põhikiht on see, kuidas konfigureeritakse OS, varukoopiad ja muud madala taseme asjad, näiteks kuidas Kubernetes põhitootena üles seada.

Teenuste tase on need teenused, mida te arendajale pakute: logimise teenus, jälgimise teenus, andmebaasi teenus, tasakaalustamisteenus, järjekorra teenus, pidev kohaletoimetamine teenus — hulga teenuseid, mida erinevad meeskonnad saavad arendusele pakkuda. Kõik need teenused tuleb teie konfiguratsioonihaldussüsteemis eraldi moodulitena kirjeldada.

Kiht, kus rakendusi luuakse ja kirjeldatakse, kuidas neid kahte eelmist kihti toetatakse.

Kontrollküsimused

Kas teie ettevõttes on ühine infrastruktuuri hoidla? Kas te jälgite tehnilist võlga infrastruktuuris? Kas kasutate arendustavasid infrastruktuuri hoidlas? Kas teie infrastruktuur on jagatud kihtideks? Võite viidata skeemile Base-service-APP. Kui keeruline on muudatusi teha?

Kui olete kokku puutunud olukordadega, kus muudatuste tegemine võttis poolteist päeva, tähendab see, et teil on tekkinud tehniline võlg ja sellega tuleb tegeleda. Olete kokku puutunud tehnilise võla takistustega infrastruktuurikoodis. Mäletan palju selliseid lugusid, kus mõne CCTL muutmiseks tuli ümber kirjutada pool infrastruktuurikoodist, sest loovus ja soov kõik automatiseerida viisid selleni, et kõik oli ummistunud, kõik nupud olid eemaldatud ja vajalik on refaktoreerida.

Pidev kohaletoimetamine

Kokkuvõtteks võrdleme deebet- ja krediite. Esiteks esitatakse infrastruktuuri kirjeldus, mis võib olla üsna põhiline. Pole vajalik kõike detailselt kirjeldada, kuid mingit põhilist kirjeldust on vaja, et saaksite sellega töötada. Vastasel juhul ei ole selge, mille peal edasi pidevat tarnet teha. Kõik need praktikad käivituvad samal ajal, kui jõuate DevOps'i, kuid alustada tuleb sellest, et mõista, mis teil on, ja kuidas sellega juhtida. See on infrastruktuuri nagu koodi praktika.

Pärast seda, kui on aru saadud, mis teil on ja kuidas sellega juhtida, hakkate välja mõtlema, kuidas arendaja koodi võimalikult kiiresti tootmisse saata. Ma mõtlen koos arendajaga – peame meeles, et probleem on „kaevudes”, st mitte eraldi inimesed seda välja mõtlema, vaid meeskonnana.

Kui me Vanja Evtuhooviga nägime esimest raamatut Jez Hämblalt ja autorite grupilt „Continuous Delivery”, mis ilmus 2009. aastal, mõtlesime kaua, kuidas tõlkida selle pealkirja vene keelde. Tahtsime tõlkida kui „Pidev tarnimine”, kuid kahjuks tõlkisime selle kui „Pidev kohaletoimetamine”. Mulle tundub, et meie pealkirjas on midagi sellist vene moodi, jõuliselt.

Pidev kohaletoimetamine – see tähendab

Kood, mis asub toote andmehoidlas, on alati valmis tootmisse minema.See võib mitte minna, kuid on alati selleks valmis. Seega kirjutate alati koodi koos seletamatult ärevustunde, misilmast allpool. See tunne tekib sageli, kui väljastate infrastruktuuri koodi. See ärevustunne peab olema olemas – see tekitab mõtlemisprotsesse, mis võimaldavad koodi kirjutada veidi teistsuguselt. See peaks olema fikseeritud arenduseeskirjades.

Pideva kohaletoimetamiseks on vajalik artefakti formaat, mis läbib infrastruktuuri platvormi. Kui viskate infrastruktuuri platvormile erineva formaadiga „eluea jäätmeid”, siis muutub see teistmoodi ühtsustuks, seda on raske hooldada ning tekib tehnilise võla probleem. Artefakti formaat tuleb ühtlustada – see on samuti kollektiivne ülesanne: tuleb koos kokku tulla, ajusid raputada ja välja mõelda see formaat.

Aeg continually improves and adapts to the production environment during its passage through the delivery pipeline. When the artifact moves through the pipeline, it constantly encounters certain inconvenient issues similar to those faced by the artifact you deploy to production. In traditional development, this would be managed by a sysadmin deploying it, but in the DevOps process, this happens constantly: sometimes it's tested, other times it's thrown into a Kubernetes cluster that resembles production more or less, and suddenly load testing is initiated.

This somewhat resembles the game Pac-Man — the artifact goes through a certain story. It is important to monitor whether the code is truly progressing through the story and whether it is somehow related to your production. Stories from production can be integrated into the Continuous Delivery process: it used to be that something failed, so let's program this scenario into the system. Each time the code will go through this scenario as well, preventing you from encountering that issue again next time. You will be informed about it long before it reaches your client.

Different deployment strategies. For example, you use AB testing or canary deployments to explore the code differently across various clients, gathering information on how the code operates before it is released to 100 million users.

"Constant delivery" looks like this.

The delivery process Dev, CI, Test, PreProd, Prod — is not a separate environment; it consists of stages or stations with unburnable sums through which your artifact passes.

If you have infrastructure code described as Base Service APP, it helps not to forget all scenarios, and write them down in code form for this artifact, to promote the artifact and modify it along the way.

Self-check questions

Is the time from feature description to production rollout less than a week in 95% of cases? Is the quality of the artifact improving at each stage of the pipeline? Is there a story through which it progresses? Are you using different deployment strategies?

If all the answers are yes, then you are incredibly awesome! Please write your answers in the comments — I would be glad to see them).

Feedback

See on kõige keerulisem praktik, mis olemas on. DevOpsConf konverentsil rääkis Infobipi kolleeg sellest ja ta segas veidi sõnu, sest see on tõesti väga keeruline praktika, mis käsitleb seda, et tuleb jälgida absoluutselt kõike!

Näiteks, kunagi ammu, kui ma töötasin Qikis ja me mõistsime, et tuleb jälgida kõike. Me tegime seda ja Zabbixis oli meil 150 000 elemente, mida pidevalt jälgiti. See oli kohutav, tehniline direktor keerutas oma pead:

— Poisid, miks te serverit segaduses hoidma peate?

Aga hiljem juhtus olukord, mis näitas, et see on tõeliselt suurepärane strateegia.

Üks teenus hakkas pidevalt kokku kukkuma. Alguses see ei kukkunud, mis on huvitav, sinna koodi ei lisatud, sest see oli põhiline broker, milles praktiliselt ei olnud ärifunktsioone - see edastas lihtsalt sõnumeid erinevate teenuste vahel. Teenus ei muutunud 4 kuud ja äkki hakkas see kukkuma veaga "Segmentation fault."

Olime šokis, avasime oma graafikud Zabbixis ja selgus, et poolteist nädalat tagasi muutus API-teenuse päringute käitumine oluliselt. Edasi vaatasime, et teatud tüüpi sõnumite saatmise sagedus muutus. Hiljem selgitasime välja, et nende Android-kliendid. Küsisime:

— Poisid, mis teil poolteist nädalat tagasi juhtus?

Vastuseks kuulsime huvitavat lugu sellest, et nad uuendasid kasutajaliidest. Vaevalt keegi kohe ütleb, et nad vahetasid HTTP-raamatukogu. Android-kliendi jaoks on see nagu seep vannitoas - nad lihtsalt ei mäleta seda. Lõpuks, 40-minutilise vestluse järel, saime teada, et nad vahetasid HTTP-raamatukogu ja sellel muutusid vaikimisi ajad. See tõi kaasa olukorra, et API serveri liikluse käitumine muutus, mis põhjustas lahingu brokeris ja see hakkas kukkuma.

Ilma sügava jälgimiseta ei oleks seda üldse võimalik avastada.. Kui organisatsioonis on aga veel probleem "kaevudega", kus igaüks viskab süü teise kaela, võib see kesta aastaid. Sa lihtsalt taaskäivitat server, kuna probleemi on võimatu lahendada. Kui sa jälgid ja jälgite kõiki sündmusi, mis sul on, ning kasutad jälgimist nagu testimist — kirjutad koodi ja kohe näitad, kuidas seda jälgida, samuti koodi kujul (meil on juba infrastruktuur kui kood), siis on kõik selge nagu peopesa. Ieven keerulised probleemid on kergesti jälgitavad.

Kogu teave selle kohta, mis toimub artefaktil iga etapi jooksul tarnimisprotsessis, tuleks koguda — mitte tootmisprotsessis.

Jälgimine tuleb laadida CI-sse, ja seal on juba näha teatud põhiasju. Edasi näed neid nii Testis, PredProd'is kui ka koormustestimises. Kogu teavet tuleb koguda kõigil etappidel, ja mitte ainult mõõdikud ja statistika, vaid ka logid: kuidas rakendus tööle läks, anomaaliad — kogu teave koguge.

Vastasel juhul on keeruline aru saada. Olen juba öelnud, et DevOps on suurem keerukus. Selle keerukusega toimetulemiseks on vaja head analüütikat..

Küsimused iseseisvaks kontrolliks.

Kas teie jälgimine ja logimine on arendamise tööriist teie jaoks? Kas teie arendajad, sealhulgas teie, mõtlevad koodi kirjutamisel sellele, kuidas seda jälgida?

Kas te kuulete probleemidest klientidelt? Kas mõistate klienti paremini jälgimise ja logimise kaudu? Kas te mõistate süsteemi paremini jälgimise ja logimise kaudu? Kas te muudate süsteemi lihtsalt selle pärast, et näete süsteemis tõusu ja mõistate, et veel 3 nädala pärast läheb kõik põhja?

Kui teil on need kolm komponenti, siis võite mõelda sellele, milline on teie ettevõtte infrastruktuuri platvorm.

Infrastruktuuri platvorm.

Mõte ei ole selles, et see on iga ettevõtte laialivalguvate tööriistade kogum.

Infrastruktuuri platvormi mõte on selles, et kõik meeskonnad kasutavad neid tööriistu ja arendavad neid koos.

On selge, et on eraldi meeskonnad, kes vastutavad infrastruktuuri platvormi eraldi osade arendamise eest. Kuid vastutus infrastruktuuri platvormi arendamise, toimimise ja edendamise eest lasub igal inseneril. Sisetasandil muutub see üldiseks tööriistaks.

Käskude meeskond arendab infrastruktuuri platvormi, kohtleb seda hoolikalt nagu enda IDE-d. Oma IDE-s installite erinevad pistikprogrammid, et kõik oleks ilus ja kiiresti, seadistate otseteed. Kui avate Sublime, Atomi või Visual Studio Code'i, tulevad koodihäired ja te mõistate, et on võimatu töötada, te tunnete end kohe kurvalt ja jooksed oma IDE-d parandama.

Koheldakse täpselt samamoodi teie infrastruktuuri platvormi. Kui te mõistate, et midagi on valesti, esitage taotlus, kui te ei suuda seda ise parandada. Kui aga midagi lihtsat — parandage ise, saatke pull request — poisid vaatavad, lisavad. See on veidi erinev lähenemine inseneritööriistadele arendaja peas.

Infrastruktuuri platvorm tagab artefakti ülekande arendajalt kliendile pideva kvaliteedi tõusuga. IP-s on programmeeritud ajaloode kogum, mis juhtub koodiga tootmises. Aastate jooksul tekib neid lugematul hulgal, osa neist on unikaalsed ja kuuluvad ainult teile — neid ei ole võimalik Google'ist leida.

Sellest hetkest alates muutub infrastruktuuri platvorm teie konkurentsieeliseks, sest see sisaldab seda, mida konkurendi tööriistas ei ole. Mida sügavam on teie IP, seda suurem on teie konkurentsieelis ajakohasus. Tekib vendor lock: võite kasutada kellegi teise platvormi, kuid kasutades kellegi teise kogemust, ei saa te aru, kui relevantne see teile on. Jah, mitte iga ettevõte ei suuda ehitada Amazonitüüpi platvormi. See on keeruline piir, kus ettevõtte kogemus on seotud selle positsiooniga turul, ja vendor lock'i ei saa sinna lasta. Sellest on samuti oluline mõelda.

Schema

See on põhiline skeem infrastruktuuri platvormist, mis aitab teil kõik praktika ja protsessid DevOps-ettevõttes paika saada.

Vaadakem, millest see koosneb.

Ressursside orkestreerimise süsteem, mis pakub rakendustele ja muudele teenustele CPU-d, mälu, ketast. Selle peal on madala taseme teenused: jälgimine, logimine, CI/CD mootor, artefaktide hoidmine, infrastruktuur kui kood süsteem.

Kõrge taseme teenused: andmebaas teenusena, järjekorrad teenusena, Load Balance teenusena, piltide suurendamine teenusena, Suured Andmed tehasena teenusena. Selle peal — pipeline, mis varustab pidevalt muudetud koodi teie kliendile.

Te saite teavet selle kohta, kuidas teie tarkvara töötab kliendi juures, muute, uuesti varustate selle koodiga, saite teavet - ja nii arendate pidevalt nii infrastruktuuriplatvormi kui ka oma tarkvara.

Tarnepipeline koosneb paljusid etappidest. Kuid see on põhimõtteline skeem, mis on esitatud näitena - ei pea seda täpselt kordama. Etapid suhtlevad teenustega nagu teenustega - iga plokk platvormil kannab oma lugu: kuidas eraldatakse ressursse, kuidas rakendus käivitatakse, töötab ressurssidega, jälgitakse, muudetakse.

Oluline on mõista, et iga platvormi osa kannab lugu, ja küsida endalt - millist lugu see plokk kannab, võib-olla on mõistlik see kõrvaldada ja asendada kolmanda osapoole teenusega. Näiteks, kas saame selle ploki asendada Okmeteriga? Võib-olla on nad juba arendanud seda ekspertiisi palju rohkem kui meie. Aga võib-olla ei ole - võib-olla on meil ainulaadne ekspertiis, mida meil on vaja arendada Prometheusega.

Platvormi loomine

See on keeruline suhtlemisprotsess. Kui teil on põhipraktikad, alustate suhtlemist erinevate inseneride ja spetsialistide vahel, kes töötavad välja nõuded ja standardid ning muudavad neid pidevalt erinevate tööriistade ja lähenemiste jaoks. Siin on oluline kultuur, mis on DevOpsis.

Kultuuriga on kõik väga lihtne - see on koostöö ja suhtlemine, see tähendab soovi töötada koos ühisväljal, soovi omada sama tööriista koos. Siin ei ole mingit rocket science - kõik on väga lihtne, banaalne. Näiteks, me kõik elame samas trepikojas ja hoidame selle puhtust - selline kultuuritase.

Aga mis teiega on?

Taaskord küsimused, mida saate endalt küsida.

Kas infrastruktuuri platvorm on eristunud? Kes vastutab selle arendamise eest? Kas te mõistate oma infrastruktuuri platvormi konkurentsieeliseid?

Need to constantly ask yourself these questions. If something can be moved to external services, it should be done; if an external service starts blocking your progress, you need to build a system internally.

So, DevOps…

… it’s a complex system that must include:

• A digital product.
• Business modules that develop this digital product.
• Product teams that write code.
• Continuous Delivery practices.
• Platform as a service.
• Infrastructure as a service.
• Infrastructure as code.
• Specific practices to maintain reliability, embedded within DevOps.
• A feedback practice that describes all of this.

You can use this framework, highlighting what you already have in your company in some form: whether it has evolved or still needs development.

In just a couple of weeks, DevOpsConf 2019. as part of RIT++. Come to the conference, where you'll find many great talks on continuous delivery, infrastructure as code, and DevOps transformation. Broneerige piletid, the final price deadline is May 20

Allikas: habr.com