DevOpsi määratlus on väga keeruline, nii et me peame selle üle arutlema iga kord uuesti. Ainuüksi Habré kohta on sellel teemal tuhat publikatsiooni. Aga kui sa seda loed, siis ilmselt tead, mis DevOps on. Sest ma ei ole. Tere minu nimi on Aleksander Titov (@) ja me räägime lihtsalt DevOpsist ja jagan oma kogemusi.
Olen pikka aega mõelnud, kuidas oma lugu kasulikuks muuta, nii et siin tekib palju küsimusi - neid, mida küsin endalt ja neid, mida küsin meie ettevõtte klientidelt. Nendele küsimustele vastates paraneb arusaam. Räägin teile, miks minu vaatenurgast DevOpsi vaja on, mis see on, jällegi minu vaatevinklist ja kuidas aru saada, et liigute minu vaatevinklist taas DevOpsi poole. Viimane punkt on küsimuste kaudu. Enda eest neile vastates saad aru, kas sinu ettevõte liigub DevOpsi poole või on kuidagi probleeme.
Omal ajal sõitsin ühinemiste ja ülevõtmiste lainetel. Kõigepealt töötasin väikeses idufirmas nimega Qik, seejärel ostis selle veidi suurem firma nimega Skype, mille ostis siis veidi suurem firma nimega Microsoft. Sel hetkel hakkasin nägema, kuidas DevOpsi idee erineva suurusega ettevõtetes muundub. Pärast seda tekkis mul huvi vaadata DevOpsi turu vaatevinklist ning asutasime kolleegidega firma Express 42. Juba 6 aastat oleme liikunud mööda turu laineid.
Muuhulgas olen üks DevOps Moskva kogukonna korraldajatest ja DevOps-Days 2017 korraldaja, kuid 2018. aastat ma ei korraldanud. Express 42 töötab paljude ettevõtetega. Kasvatame seal DevOpsi, jälgime, kuidas see juhtub, teeme järeldusi, analüüsime, räägime kõigile oma järeldused ja koolitame inimesi DevOpsi praktikas. Üldiselt anname endast parima, et suurendada oma kogemusi ja teadmisi selles valdkonnas.
Miks DevOps
Esimene küsimus, mis kõiki ja alati kummitab, on – miks? Paljud inimesed arvavad, et DevOps on lihtsalt automatiseerimine või sarnane asi, mis igal ettevõttel juba oli.
— Meil oli pidev integreerimine – see tähendab, et meil oli juba DevOps ja milleks seda kõike vaja on? Nad lõbutsevad välismaal, aga takistavad meil töötamast!
9-aastase kogukonna ja metoodika arendamise jooksul on juba selgeks saanud, et see pole ikka veel turunduslik sära, kuid siiani pole päris selge, miks seda vaja on. Nagu igal tööriistal ja protsessil, on ka DevOpsil konkreetsed eesmärgid, mille see lõpuks saavutab.
Kõik see on tingitud asjaolust, et maailm muutub. Ta eemaldub ettevõtlikust lähenemisest, kui ettevõtted liiguvad otse unistuse poole, nagu laulis meie Peterburi klassik, punktist A punkti B kindla strateegia järgi, selleks ehitatud teatud struktuuriga.
Põhimõtteliselt tuleks IT-s kõik selle lähenemise järgi üles ehitada. Siin kasutatakse IT-d eranditult protsesside automatiseerimiseks.
Automatiseerimine ei muutu sageli, sest kui ettevõte läheb sisse sissetallatud teerajale, siis mida on muuta? See töötab – ära puuduta seda. Nüüd on maailma lähenemisviisid muutumas ja Agile-nimeline lähenemine viitab sellele, et lõpp-punkti B pole kohe näha.
Kui ettevõte läbib turu, töötab koos kliendiga, uurib ta pidevalt turgu ja muudab lõpp-punkti B. Pealegi, mida sagedamini ettevõte suunda muudab, seda edukam on ta lõpuks, sest ta valib rohkem turgu nišše.
Strateegiat demonstreerib huvitav ettevõte, millest ma hiljuti teada sain. One Box Shave on tellitav pardlite ja habemeajamistarvikute tarneteenus karbis. Nad teavad, kuidas kohandada oma "kasti" erinevate klientide jaoks. Seda teeb teatud tarkvara, mis seejärel saadab tellimuse toodet tootvasse Korea tehasesse.
Unilever ostis selle toote 1 miljardi dollari eest. Nüüd konkureerib see Gillette'iga ja on Ameerika turult ära võtnud märkimisväärse osa tarbijatest. One Box Shave ütle:
- 4 tera? Kas sa oled tõsiselt? Miks seda vaja on – see ei paranda raseerimise kvaliteeti. Spetsiaalselt valitud kreem, lõhn ja kvaliteetne kahe teraga habemenuga lahendavad palju rohkem probleeme kui need nõmedad 4 Gillette tera! Kas jõuame varsti 10-ni?
Nii muutub maailm. Unilever väidab, et neil on lahe IT-süsteem, mis võimaldab seda teha. Lõpuks näeb see välja nagu kontseptsioon Turule jõudmise aeg, millest keegi pole juba rääkinud.
Turule jõudmise aja mõte ei seisne selles, kui sageli me kasutusele võtame. Saate sageli juurutada, kuid vabastamistsüklid on pikad. Kui kolmekuulised väljalasketsüklid asetatakse üksteise peale, nihutades neid nädala võrra, selgub, et ettevõte näib juurutavat kord nädalas. Ja ideest lõpliku teostuseni kulub 3 kuud.
Turule jõudmise aeg tähendab ideest lõpliku teostuseni kuluva aja minimeerimist.
Sel juhul suhtleb tarkvara turuga. Nii suhtleb One Box Shave veebisait kliendiga. Neil pole müügimehi – lihtsalt veebisait, kus külastajad klõpsavad ja jätavad soovid. Sellest lähtuvalt tuleb saidile pidevalt midagi uut postitada ja vastavalt soovidele uuendada. Näiteks Lõuna-Koreas raseerivad nad teistmoodi kui Venemaal ja neile meeldib mitte männi, vaid näiteks porgandi ja vanilli lõhn.
Kuna on vaja kiiresti muuta saidi sisu, muutub tarkvaraarendus suuresti. Tarkvara kaudu peame välja selgitama, mida klient soovib. Varem õppisime seda mõne ringtee kaudu, näiteks ärijuhtimise kaudu. Siis kujundasime selle, panime IT-süsteemi nõuded sisse ja kõik oli lahe. Nüüd on kõik teisiti – tarkvara kujundavad kõik protsessiga seotud inimesed, sealhulgas insenerid, sest tehniliste kirjelduste kaudu õpivad nad turu toimimist ja jagavad oma teadmisi ka ettevõttega.
Näiteks saime Qikis ootamatult teada, et inimestele väga meeldis kontaktiloendeid serverisse üles laadida, ja nad andsid meile rakenduse. Alguses me ei mõelnud sellele. Klassikalises ettevõttes oleksid kõik otsustanud, et see on viga, kuna spetsifikatsioonis ei öeldud, et see peaks suurepäraselt töötama ja seda rakendati üldiselt põlve peal, oleksid nad funktsiooni välja lülitanud ja öelnud: "Seda pole kellelegi vaja, kõige tähtsam on see, et põhifunktsionaalsus töötaks.“ . Ja tehnoloogiaettevõte näeb selles võimalust ja hakkab vastavalt sellele tarkvara muutma.
1968. aastal sõnastas visionäär Melvin Conway järgmise idee.
Süsteemi loov organisatsioon on piiratud disainiga, mis kordab selle organisatsiooni suhtlusstruktuuri.
Täpsemalt, teist tüüpi süsteemide tootmiseks peab teil olema ka teist tüüpi ettevõtte sees suhtlusstruktuur. Kui teie suhtlusstruktuur on tipphierarhiline, ei võimalda see teil luua süsteeme, mis suudavad pakkuda väga kõrget turustamisaja indikaatorit.
Loe keegi ei saa . See on oluline DevOpsi kultuuri või filosoofia mõistmiseks, sest Ainus, mis DevOpsis põhimõtteliselt muutub, on meeskondadevahelise suhtluse struktuur.
Protsessi seisukohast olid enne DevOpsi kõik etapid: analüüs, arendus, testimine, käitamine lineaarsed.
DevOpsi puhul toimuvad kõik need protsessid üheaegselt.
Turule jõudmise aeg on ainus viis seda teha. Inimestele, kes töötasid vana protsessi käigus, tundub see mõnevõrra kosmiline ja üldiselt nii.
Miks sa siis DevOpsi vajad?
Digitaalse tootearenduse jaoks. Kui teie ettevõttel pole digitaalset toodet, pole DevOpsi vaja – see on väga oluline.
DevOps ületab järjestikuse tarkvaratootmise kiiruspiirangud. Selles toimuvad kõik protsessid üheaegselt.
Raskused suurenevad. Kui DevOpsi evangelistid ütlevad teile, et see muudab teie jaoks tarkvara väljastamise lihtsamaks, on see jama.
DevOpsiga lähevad asjad ainult keerulisemaks.
Avito stendil toimunud konverentsil võis näha, mis tunne oli Dockeri konteineri kasutuselevõtt – ebareaalne ülesanne. Keerulisus muutub ülemääraseks; peate korraga žongleerima paljude pallidega.
DevOps muudab täielikult protsessi ja organisatsiooni ettevõttes — täpsemalt ei muutu DevOps, vaid digitoode. DevOpsi kasutamiseks peate seda protsessi siiski täielikult muutma.
Küsimused spetsialistile
Mis sul on? Küsimused, mida võid endalt küsida ettevõttes töötades ja spetsialistina arenedes.
Kas teil on digitaalse toote loomise strateegia? Kui on, on see juba hea. See tähendab, et teie ettevõte liigub DevOpsi poole.
Kas teie ettevõte loob juba digitaalset toodet? See tähendab, et saate tõusta veel ühe taseme kõrgemale ja teha asju huvitavamalt – jällegi DevOpsi vaatenurgast. Ma räägin ainult sellest vaatenurgast.
Kas teie ettevõte on üks turuliidreid digitaalsete toodete nišis? Spotify, Yandex, Uber on ettevõtted, mis on praegu tehnoloogia arengu tipus.
Esitage endale need küsimused ja kui kõik vastused on eitavad, siis võib-olla ei peaks te selles ettevõttes DevOpsi tegema. Kui DevOpsi teema sind tõesti huvitab, siis äkki... tasuks kolida teise firmasse? Kui teie ettevõte soovib minna DevOpsi, kuid vastasite kõigile küsimustele "Ei", siis on see nagu ilus ninasarvik, mis ei muutu kunagi.
Organisatsioon
Nagu ma ütlesin, muutub Conway seaduse järgi ettevõtte korraldus. Alustan sellest, mis takistab DevOpsil organisatsioonilisest vaatenurgast ettevõttesse tungimast.
"Kaevude" probleem
Ingliskeelne sõna "Silo" on siin tõlgitud vene keelde kui "ka". Selle probleemi mõte on selles meeskondade vahel infovahetust ei toimu. Iga meeskond uurib sügavalt oma teadmisi, koostamata navigeerimiseks ühist kaarti.
Mõnes mõttes meenutab see mulle inimest, kes on just saabunud Moskvasse ja ei tea veel, kuidas metrookaardil liigelda. Tavaliselt teavad moskvalased oma piirkonda väga hästi ja kogu Moskvas saavad nad navigeerida metrookaardi abil. Kui tulete esimest korda Moskvasse, pole teil seda oskust ja olete lihtsalt segaduses.
DevOps soovitab selle desorientatsiooni hetke üle elada ja kõik osakonnad teha koostööd ühise suhtluskaardi koostamiseks.
Seda takistavad kaks tegurit.
Ettevõtte juhtimissüsteemi tagajärg. See on ehitatud eraldi hierarhilistesse "kaevudesse". Näiteks on seda süsteemi toetavates ettevõtetes teatud KPI-d. Teisest küljest jäävad teele inimese ajud, kellel on raske oma teadmiste piire ületada ja kogu süsteemis navigeerida. See on lihtsalt ebamugav. Kujutage ette, et olete Bangkoki lennujaamas – te ei leia kiiresti ringi. DevOpsis on ka raske navigeerida ja seepärast ütlevad inimesed, et sinna jõudmiseks tuleb leida juhend.
Kuid kõige olulisem on see, et DevOpsi vaimust läbi imbunud, Fowlerit ja hunnikut teisi raamatuid lugenud inseneri “kaevude” probleem väljendub selles, et "kaevud" ei luba teha "ilmselgeid" asju. Saame sageli pärast DevOps Moscow kokku, räägime omavahel ja inimesed kurdavad:
— Tahtsime just CI käivitada, kuid selgus, et juhtkond ei vaja seda.
See juhtub just seetõttu CI и Pidev tarneprotsess on paljude uuringute piiril. Lihtsalt ilma "kaevude" probleemist organisatsiooni tasandil üle saamata ei saa te edasi liikuda, ükskõik mida teete ja kui kurb see ka poleks.
Iga protsessis osaleja ettevõttes: tausta- ja frontend-arendajad, testimine, DBA, operatsioon, võrk, kaevab omas suunas ja kellelgi pole ühist kaarti peale juhi, kes neid kuidagi jälgib ja haldab "jaga" abil. ja valluta” meetod.
Inimesed võitlevad mingite tähtede või lippude pärast, kõik kaevavad oma asjatundlikkust.
Sellest tulenevalt, kui tekib ülesanne kõik see kokku ühendada ja ühine torustik ehitada ning tähtede ja lippude pärast pole enam vaja võidelda, tekib küsimus - mida ikkagi teha? Peame kuidagi kokkuleppele jõudma, aga keegi ei õpetanud meile koolis, kuidas seda teha. Meile on koolist saadik õpetatud: kaheksas klass – vau! - võrreldes seitsmenda klassiga! Siin on sama.
Kas teie ettevõttes on sama?
Selle kontrollimiseks võite esitada endale järgmised küsimused.
Kas meeskonnad kasutavad ühiseid tööriistu ja panustavad nende ühiste tööriistade muutmisse?
Kui sageli meeskonnad ümber korraldavad – mõned spetsialistid ühest meeskonnast liiguvad teise meeskonda? DevOpsi keskkonnas muutub see normaalseks, sest mõnikord ei saa inimene lihtsalt aru, mida teine teadmisvaldkond teeb. Ta kolib teise osakonda, töötab seal kaks nädalat, et luua endale selle osakonnaga orienteerumise ja suhtlemise kaart.
Kas on võimalik moodustada muudatuskomisjon ja asju muuta? Või nõuab see kõrgeima juhtkonna ja suuna tugevat kätt? Kirjutasin hiljuti Facebookis, kuidas üks vähetuntud pank juurutab tellimuste kaudu tööriistu: kirjutame tellimuse, viime aasta läbi ja vaatame, mis saab. See on muidugi pikk ja kurb.
Kui oluline on juhtide jaoks isiklike saavutuste saamine ettevõtte saavutusi arvestamata?
Kui vastate nendele küsimustele enda jaoks, saab selgemaks, kas teie ettevõttes on selline probleem.
Infrastruktuur kui kood
Pärast selle probleemi lahendamist on esimene oluline praktika, ilma milleta on DevOpsis raske edasi liikuda infrastruktuur koodina.
Kõige sagedamini tajutakse infrastruktuuri kui koodi järgmiselt:
— Automatiseerime kõik bashis, katame end skriptidega, et administraatoritel oleks vähem käsitsitööd!
Aga see pole tõsi.
Taristu kui kood tähendab seda, et kirjeldad IT-süsteemi, millega töötad, koodi kujul, et selle olekust pidevalt aru saada.
Koos teiste meeskondadega loote koodikujulise kaardi, millest igaüks saab aru ning saab navigeerida ja navigeerida. Pole vahet, millega seda tehakse – Chef, Ansible, Salt või Kubernetesis YAML-failide kasutamine – vahet pole.
Konverentsil rääkis kolleeg 2GIS-ist, kuidas nad tegid Kubernetesele oma sisemise asja, 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 omavahel kontrollida, jälgida muutusi, kuidas seda muuta ja täiustada, millest puudu on.
Nõus, üksikud bash-skriptid tavaliselt seda arusaama ei anna. Ühes ettevõttes, kus ma töötasin, oli isegi "kirjutatava" skripti nimi - kui skript on kirjutatud, kuid seda pole enam võimalik lugeda. Ma arvan, et see on teilegi tuttav.
Infrastruktuur nagu kood on kood, mis kirjeldab infrastruktuuri hetkeseisu. Paljud toote-, infrastruktuuri- ja teenindusmeeskonnad töötavad selle koodi kallal koos ja mis kõige tähtsam, nad kõik peavad mõistma, kuidas see kood tegelikult töötab.
Koodi hooldatakse vastavalt parimatele kooditavadele: ühisarendus, koodi ülevaatus, XP-programmeerimine, testimine, tõmbamispäringud, CI kooditaristute jaoks – kõik see sobib ja on kasutatav.
Kood muutub kõigi inseneride ühiseks keeleks.
Infrastruktuuri muutmine koodis ei võta palju aega. Jah, infrastruktuuri koodil võib olla ka tehniline võlg. Tavaliselt puutuvad meeskonnad sellega kokku poolteist aastat pärast seda, kui nad hakkasid juurutama “infrastruktuuri kui koodi” hunniku skriptide või isegi Ansible kujul, mida nad kirjutavad nagu spagetikoodi, ja viskavad segusse ka bash-skripte!
Oluline: Kui te pole seda kraami veel proovinud, pidage seda meeles Ansible ei ole jube! Lugege hoolikalt dokumentatsiooni, uurige, mida nad selle kohta kirjutavad.
Infrastruktuur kui kood on infrastruktuuri koodi eraldamine eraldi kihtideks.
Meie ettevõttes eristame 3 põhikihti, mis on väga selged ja lihtsad, kuid neid võib olla rohkem. Saate vaadata oma infrastruktuuri koodi ja öelda, kas teil on see tingimus või mitte. Kui ühtki kihti pole esile tõstetud, peate võtma natuke aega ja veidi ümber kujundama.
aluskiht - nii konfigureeritakse OS, varukoopiad ja muud madala tasemega asjad, näiteks kuidas Kubernetes juurutatakse algtasemel.
Teenuse tase - need on teenused, mida arendajale pakute: logimine teenusena, jälgimine teenusena, andmebaas kui teenus, tasakaalustaja kui teenus, järjekord teenusena, pidev kohaletoimetamine teenusena - hunnik teenuseid, mida üksikud meeskonnad võib anda arengut. Seda kõike tuleb teie konfiguratsioonihaldussüsteemi eraldi moodulites kirjeldada.
Kiht, kus rakendusi tehakse ja kirjeldab, kuidas need kahe eelmise kihi peale lahti rulluvad.
Kontrollküsimused
Kas teie ettevõttel on ühine infrastruktuurihoidla? Kas haldate oma infrastruktuuri tehnilisi võlgu? Kas kasutate arendustavasid infrastruktuuri hoidlas? Kas teie infrastruktuur on jaotatud kihtideks? Saate vaadata diagrammi Base-service-APP. Kui raske on muudatust teha?
Kui olete kogenud, et muudatuste tegemiseks kulus poolteist päeva, tähendab see, et teil on tehniline võlg ja peate sellega tegelema. Sa lihtsalt komistasid oma infrastruktuuri koodis tehnilise võla reha otsa. Mäletan palju selliseid lugusid, kui mõne CCTL-i muutmiseks on vaja pool infrastruktuuri koodi ümber kirjutada, sest loovus ja soov kõike automatiseerida viis selleni, et kõik on igal pool roostetanud, kõik käepidemed eemaldatud ja on vaja refaktoreerida.
Pidev kohaletoimetamine
Võrdleme deebetit krediidiga. Kõigepealt tuleb kirjeldada infrastruktuuri, mis võib olla üsna lihtne. Te ei pea kõike üksikasjalikult kirjeldama, kuid sellega töötamiseks on vaja mõnda põhikirjeldust. Muidu pole selge, mida pideva tarnega edasi teha. Kõik need tavad arenevad välja üheaegselt, kui tulete DevOpsi, kuid see algab mõistmisest, mis teil on ja kuidas seda hallata. Just selline on infrastruktuuri kui koodi praktika.
Kui on selge, et teil on see olemas ja kuidas seda hallata, hakkate välja mõtlema, kuidas arendaja kood võimalikult kiiresti tootmisse saata. Pean silmas koos arendajaga - me mäletame "kaevude" probleemi, see tähendab, et selle peale ei tule mitte üksikud inimesed, vaid meeskond.
Kui oleme koos Vanja Evtuhhovitš nägi esimest raamatut Jez Humble ja autorite rühmad "Pidev kohaletoimetamine", mis ilmus 2009. aastal, mõtlesime kaua, kuidas selle pealkiri vene keelde tõlkida. Nad tahtsid seda tõlkida kui "Pidevalt tarnida", kuid kahjuks tõlgiti see kui "pidev kohaletoimetamine". Mulle tundub, et meie nimes on midagi venepärast, survega.
Pidevalt toimetavad vahendid
Tootehoidlas oleva koodi saab alati tootmisse alla laadida. Ta ei pruugi olla tühjenenud, kuid ta on alati selleks valmis. Seetõttu kirjutate koodi alati raskesti seletatava ärevuse tundega sabaluu all. See kuvatakse sageli infrastruktuuri koodi avaldamisel. See mingi ärevuse tunne peaks olema – see käivitab ajuprotsessid, mis võimaldavad koodi veidi teistmoodi kirjutada. See tuleks registreerida arenduse reeglites.
Järjepidevaks edastamiseks vajate artefaktivormingut, mis töötab kogu infrastruktuuri platvormil. Kui visata erinevas formaadis “elujäätmed” üle taristuplatvormi, siis see muutub ühtseks, seda on raske hooldada ja tekib tehnilise võla probleem. Artefakti formaat tuleb ühtlustada – see on ka kollektiivne ülesanne: me kõik peame kokku saama, oma ajud ragistama ja selle vormingu välja mõtlema.
Artefakti täiustatakse pidevalt ja seda muudetakse, et see sobiks tootmiskeskkonnaga, kui see liigub läbi tarnetorustiku. Kui artefakt liigub mööda konveieri, puutub see pidevalt kokku tema jaoks ebamugavate asjadega, mis on sarnased sellega, millega tootmisse lisatud artefakt kokku puutub. Kui klassikalises arenduses teeb seda süsteemiadministraator, kes teeb juurutamist, siis DevOps protsessis juhtub seda kogu aeg: siin testiti mingite testidega, siin visati Kubernetese klastrisse, mis on enam-vähem sarnane. tootmisse, siis järsku hakkasid nad koormustesti tegema.
See meenutab mõneti Pac-Mani mängu – artefakt läbib mingisuguse loo. Samas on oluline kontrollida, kas kood ka reaalselt loost läbi käib ja kas see on kuidagi sinu toodanguga seotud. Tootmislood saab tõmmata pideva tarnimise protsessi: see oli nii, kui midagi kukkus, nüüd lihtsalt programmeerime selle stsenaariumi süsteemi sees. Iga kord läbib kood ka selle stsenaariumi ja järgmisel korral te seda probleemi ei puutu. Saate sellest teada palju varem, kui see teie kliendini jõuab.
Erinevad kasutuselevõtustrateegiad. Näiteks kasutate AB-testimist või kanaari juurutusi, et testida koodi erinevatel klientidel erinevalt, hankida teavet koodi toimimise kohta ja palju varem kui siis, kui see 100 miljonile kasutajale avaldatakse.
„Järjepidevalt tarnida” näeb välja selline.
Tarneprotsess Dev, CI, Test, PreProd, Prod ei ole eraldiseisev keskkond, need on tulekindlate summadega etapid või jaamad, mida teie artefakt läbib.
Kui teil on infrastruktuurikood, mida kirjeldatakse kui Base Service APP, siis see aitab ärge unustage kõiki skripteja kirjutage need üles selle artefakti koodina, edendada artefakti ja muutke seda töö käigus.
Enesetesti küsimused
Funktsiooni kirjeldamisest tootmisse laskmiseni kulub 95% juhtudest vähem kui nädal? Kas artefakti kvaliteet paraneb torujuhtme igas etapis? Kas on mõni lugu, millest see läbi läheb? Kas kasutate erinevaid juurutamisstrateegiaid?
Kui kõik vastused on jaatavad, siis olete uskumatult lahe! Kirjutage oma vastused kommentaaridesse - mul on hea meel).
Võta meiega ühendust
See on kõige raskem praktika üldse. DevOpsConfi konverentsil oli kolleeg Infobipist sellest rääkides veidi segaduses, sest see on tõesti väga keeruline praktika, et kõike on vaja jälgida!
Näiteks kaua aega tagasi, kui töötasin Qikis ja saime aru, et peame kõike jälgima. Tegime seda ja meil on nüüd Zabbixis 150 000 üksust, mida pidevalt jälgitakse. See oli hirmutav, tehniline direktor väänas näppu oma templi poole:
- Poisid, miks te vägistate serverit millegi ebaselgega?
Kuid siis juhtus juhtum, mis näitas, et see on tõesti väga lahe strateegia.
Üks teenustest hakkas pidevalt kokku jooksma. Esialgu see kokku ei jooksnud, mis on huvitav, koodi sinna ei lisatud, kuna tegemist oli põhimaakleriga, millel ärifunktsionaalsus praktiliselt puudus - lihtsalt saatis sõnumeid üksikute teenuste vahel. Teenus ei muutunud 4 kuud ja järsku hakkas see tõrkega „Segmenteerimisviga” kokku jooksma.
Olime šokeeritud, avasime oma graafikud Zabbixis ja selgus, et poolteist nädalat tagasi muutus oluliselt selle maakleri kasutatava API teenuse päringute käitumine. Järgmisena nägime, et teatud tüüpi sõnumite saatmise sagedus oli muutunud. Hiljem saime teada, et need olid Androidi kliendid. Me küsisime:
— Poisid, mis teiega juhtus poolteist nädalat tagasi?
Vastuseks kuulsime huvitavat lugu sellest, kuidas nad kasutajaliidese ümber kujundasid. On ebatõenäoline, et keegi ütleb kohe, et muutis HTTP-teeki. Androidi klientide jaoks on see nagu seebi vahetamine vannitoas – nad lihtsalt ei mäleta. Selle tulemusel avastasime pärast 40-minutilist vestlust, et nad on muutnud HTTP-teeki ja selle vaikeajad on muutunud. See viis API-serveri liikluskäitumise muutumiseni, mis viis olukorrani, mis põhjustas maakleri sees võidujooksu ja see hakkas kokku jooksma.
Ilma põhjaliku jälgimiseta on seda üldiselt võimatu avada. Kui organisatsioonil on endiselt probleem "kaevud", kui kõik loobivad üksteisele raha, võib see elada aastaid. Te lihtsalt taaskäivitate serveri, sest probleemi pole võimalik lahendada. Kui jälgid, jälgid, jälgid kõiki endal olevaid sündmusi ja kasutad monitooringut testimisena – kirjuta kood ja anna kohe märku, kuidas seda jälgida, ka koodi kujul (taristu on meil juba koodina olemas), saab kõik selgeks, kuidas peopesal. Isegi selliseid keerukaid probleeme on lihtne jälgida.
Koguge kogu teave selle kohta, mis juhtub artefaktiga tarneprotsessi igas etapis – mitte tootmises.
Laadi seire CI-sse üles ja seal on mõned põhilised asjad juba näha. Hiljem näete neid jaotises Test, PredProd ja koormustest. Koguge teavet kõigis etappides, mitte ainult mõõdikuid, statistikat, vaid ka logisid: kuidas rakendus välja tuli, kõrvalekalded - koguge kõike.
Muidu on seda raske välja mõelda. Ma juba ütlesin, et DevOps on keerulisem. Selle keerukusega toimetulemiseks peab teil olema tavaline analüütika.
Küsimused enesekontrolliks
Kas teie jälgimine ja logimine on teie jaoks arendustööriist? Kas teie arendajad, sealhulgas teie, mõtlevad koodi kirjutades sellele, kuidas seda jälgida?
Kas kuulete klientidelt probleemidest? Kas mõistate klienti paremini jälgimisest ja logimisest? Kas mõistate süsteemi paremini jälgimise ja logimise põhjal? Kas muudad süsteemi lihtsalt sellepärast, et nägid, et süsteemis on trend kasvamas ja saad aru, et veel 3 nädala pärast sureb kõik välja?
Kui teil on need kolm komponenti, võite mõelda, milline taristuplatvorm teie ettevõttes on.
Infrastruktuuri platvorm
Asi pole selles, et tegemist on erinevate tööriistade komplektiga, mis igal ettevõttel on.
Taristuplatvormi mõte seisneb selles, et kõik meeskonnad kasutavad neid tööriistu ja arendavad neid koos.
On selge, et taristuplatvormi üksikute osade arendamise eest vastutavad eraldi meeskonnad. Kuid samal ajal vastutab iga insener infrastruktuuriplatvormi arendamise, toimivuse ja reklaamimise eest. Sisemisel tasandil muutub see tavaliseks tööriistaks.
Kõik meeskonnad arendavad infrastruktuuriplatvormi ja kohtlevad seda hoolikalt kui oma IDE-d. Installite oma IDE-sse erinevaid pistikprogramme, et kõik oleks kena ja kiire, ning konfigureerite kiirklahve. Kui avate Sublime'i, Atomi või Visual Studio Code'i, tulvavad sisse koodivead ja saate aru, et pole üldse võimalik töötada, tunnete kohe kurbust ja jooksete oma IDE-d parandama.
Kohtle oma infrastruktuuriplatvormi samamoodi. Kui saate aru, et selles on midagi valesti, jätke päring, kui te ei saa seda ise parandada. Kui on midagi lihtsat, muutke seda ise, saatke tõmbetaotlus, poisid kaaluvad seda ja lisavad selle. See on arendaja peas veidi erinev lähenemine inseneritööriistadele.
Infrastruktuuriplatvorm tagab artefakti ülekandmise arendusest kliendile koos pideva kvaliteedi paranemisega. IP on programmeeritud lugude komplektiga, mis juhtuvad tootmises oleva koodiga. Aastate jooksul on neid lugusid palju, mõned neist on ainulaadsed ja ainult teiega seotud - neid ei saa guugeldada.
Sel hetkel muutub infrastruktuuri platvorm teie konkurentsieeliseks, kuna sellesse on sisse ehitatud midagi, mida konkurendi tööriistas pole. Mida sügavam on teie IP, seda suurem on teie konkurentsieelis turuletuleku aja osas. Ilmub siin müüja lukustuse probleem: Võite võtta kellegi teise platvormi, kuid kellegi teise kogemust kasutades ei saa te aru, kui asjakohane see teie jaoks on. Jah, mitte iga ettevõte ei saa luua sellist platvormi nagu Amazon. See on keeruline liin, kus ettevõtte kogemused on olulised tema positsioonile turul ja seal ei saa müüja lukku kasutada. Sellele on samuti oluline mõelda.
Kava
See on infrastruktuuri platvormi põhiskeem, mis aitab teil seadistada DevOpsi ettevõttes kõik tavad ja protsessid.
Vaatame, millest see koosneb.
Ressursi orkestreerimissüsteem, mis pakub rakendustele protsessorit, mälu, ketast ja muid teenuseid. Selle peale - madala taseme teenused: monitooring, logimine, CI/CD mootor, artefaktide salvestamine, infrastruktuur süsteemikoodina.
Kõrgema taseme teenused: andmebaas kui teenus, järjekorrad kui teenus, Load Balance kui teenus, pildi suuruse muutmine kui teenus, Big Data tehas kui teenus. Selle peale - torujuhe, mis edastab teie kliendile pidevalt muudetud koodi.
Saate teavet selle kohta, kuidas teie tarkvara kliendi jaoks töötab, muudate seda, sisestate selle koodi uuesti, saate teavet - ja nii arendate pidevalt nii infrastruktuuri platvormi kui ka oma tarkvara.
Diagrammil koosneb tarnetorustik mitmest etapist. Kuid see on skemaatiline diagramm, mis on toodud näitena - seda pole vaja ükshaaval korrata. Etapid suhtlevad teenustega nii, nagu oleksid need teenused – igal platvormil on oma lugu: kuidas ressursse jaotatakse, kuidas rakendus käivitatakse, ressurssidega töötab, jälgitakse ja muutub.
Oluline on mõista, et iga platvormi osa kannab endas lugu, ja küsi endalt, mis lugu see tellis kannab, võib-olla tuleks see ära visata ja asendada mõne kolmanda osapoole teenusega. Kas näiteks tellise asemel on võimalik paigaldada Okmeter? Võib-olla on poisid seda asjatundlikkust juba palju rohkem arendanud kui meie. Aga võib-olla mitte – võib-olla on meil ainulaadsed teadmised, peame Prometheuse installima ja seda edasi arendama.
Platvormi loomine
See on keeruline suhtlusprotsess. Kui teil on põhilised praktikad, alustate suhtlemist erinevate inseneride ja spetsialistide vahel, kes töötavad välja nõudeid ja standardeid ning muudavad neid pidevalt erinevate tööriistade ja lähenemisviiside vastu. Siin on oluline DevOpsi kultuur.
Kultuuriga on kõik väga lihtne - see puudutab koostööd ja suhtlemist, ehk siis soov üksteisega ühisel alal töötada, soov koos ühe pilli vehkida. Siin pole raketiteadust – kõik on väga lihtne, banaalne. Näiteks me kõik elame sissepääsus ja hoiame seda puhtana – selline kultuuritase.
Mis sul on?
Jällegi küsimused, mida saate endalt küsida.
Kas taristuplatvorm on pühendatud? Kes vastutab selle arendamise eest? Kas saate aru oma taristuplatvormi konkurentsieelistest?
Neid küsimusi tuleb endalt pidevalt küsida. Kui midagi saab üle kanda kolmandate osapoolte teenustele, tuleks see üle kanda; kui kolmanda osapoole teenus hakkab teie liikumist takistama, siis peate enda sees süsteemi üles ehitama.
Niisiis, DevOps...
... see on keeruline süsteem, sellel peab olema:
- Digitoode.
- Ärimoodulid, mis arendavad seda digitaalset toodet.
- Tootemeeskonnad, kes kirjutavad koodi.
- Pidev kohaletoimetamise praktika.
- Platvormid kui teenus.
- Infrastruktuur kui teenus.
- Infrastruktuur kui kood.
- DevOpsi sisse ehitatud eraldi tavad töökindluse säilitamiseks.
- Tagasiside praktika, mis seda kõike kirjeldab.
Saate kasutada seda diagrammi, tuues sellel esile selle, mis teil teie ettevõttes mingil kujul juba on: kas see on välja kujunenud või vajab veel arendamist.
See saab läbi paari nädala pärast . RIT++ osana. Tulge konverentsile, kust leiate palju lahedaid aruandeid pideva tarnimise, infrastruktuuri kui koodi ja DevOpsi teisenduse kohta. , viimane hinnatähtaeg on 20. mai
Allikas: www.habr.com