Kur eiti su šiomis žiniomis, ką veikti projekte ir kiek uždirbti, ką pasakyti ir paklausti interviu metu, - sako Aleksandras Titovas, „Express 42“ vadovaujantis partneris ir autorius. .
Sveiki! Nors terminas „DevOps“ egzistuoja nuo 2009 m., rusų bendruomenėje vis dar nėra sutarimo. Tikriausiai pastebėjote, kad vieni DevOps laiko specialybe, kiti – filosofija, treti šį terminą laiko technologijų rinkiniu. Jau daug kartų koncertavau su apie šios krypties plėtrą, todėl šiame straipsnyje nenagrinėsiu. Leiskite man pasakyti, kad „Express 42“ į jį įtraukiame:
DevOps – tai specifinė metodika, skaitmeninio produkto kūrimo kultūra, kai gamyboje dalyvauja visi komandos specialistai.
Klasikinėje įmonių plėtroje viskas vyksta nuosekliai: programavimas, testavimas ir tik tada veikimas, o šio proceso greitis nuo idėjos iki gamybos – 3 mėnesiai. Tai pasaulinė skaitmeninių produktų problema, nes neįmanoma greitai gauti atsiliepimų iš klientų.
„DevOps“ įrankiai ir metodai yra skirti užtikrinti, kad kūrimo, testavimo ir operacijų procesai vyktų vienu metu.
Kas išplaukia iš šio požiūrio?
- Negalite pasamdyti „inžinieriaus“, kuris ateis ir išspręs visas gamybos problemas. Visa komanda turi taikyti techniką.
- „DevOps“ NĖRA kita sysadmin forma, kurią reikia atnaujinti. „DevOps inžinierius“ skamba maždaug taip pat, kaip „Agile developer“.
- Jei komanda naudoja Kubernetes, Ansible, Prometheus, Mesosphere ir Docker, tai nereiškia, kad ten buvo įdiegta DevOps praktika.
Gyvenimas po „DevOps“ niekada nebus toks pat
DevOps metodas visų pirma yra kitoks mąstymas, vystymosi kaip visumos ir savo vietos procese suvokimas. Internetinį kursą suskirstėme į 2 blokus:
1. Apsisprendimas
Pirma, mes išsamiai išnagrinėjame DevOps metodo esmę, o studentai atranda naujų vaidmenų komandoje, pamato, kuris iš jų labiau reaguoja, ir patys nusprendžia, kuria kryptimi tobulėti.
2. Priemonės ir praktika
Studentai įvaldo specifines technologijas DevOps metodo požiūriu.
„DevOps“ įrankiai gali būti naudojami tiek „DevOps“, tiek klasikiniame kūrime. Akivaizdžiausias pavyzdys būtų „Ansible“ konfigūracijos valdymo įrankio naudojimas. Jis buvo sukurtas ir sumanytas įgyvendinti DevOps praktiką „Infrastruktūra kaip kodas“, o tai reiškia, kad aprašomos įvairios sistemos būsenos – nuo operacinės sistemos nustatymų iki taikomosios programinės įrangos. Aprašymas yra padalintas į sluoksnius ir leidžia valdyti sudėtingą, nuolat besikeičiančią konfigūraciją. Tačiau inžinieriai dažnai naudoja Ansible kaip būdą paleisti bash scenarijus keliose mašinose. Tai nėra nei blogai, nei gerai, tačiau reikia suprasti, kad „Ansible“ buvimas negarantuoja „DevOps“ buvimo įmonėje.
Esame procese Būsite panirę į programos, panašios į garsųjį Reddit, kūrimo procesą, pradedant nuo monolitinės jos versijos, žingsnis po žingsnio pereinant prie mikro paslaugų. Žingsnis po žingsnio įsisavinsime naujus įrankius: Git, Ansible, Gitlab ir užbaigsime su Kubernetes ir Prometheus.
Kalbant apie praktikas, laikysimės trijų DevOps vadove aprašytų kelių taktikos – nuolatinio pristatymo praktikos, grįžtamojo ryšio praktikos, o viso kurso esmė yra nuolatinio mokymosi kartu su savo sistema praktika.
Ką šios žinios suteikia kiekvienam iš specialistų?
Sistemos administratoriams
Praktika leis jums pereiti nuo administravimo prie nuolatinio pristatymo vamzdyno ir infrastruktūros platformos programinės įrangos pristatymui kūrimo. Esmė ta, kad jis sukuria produktą – infrastruktūros platformą kūrėjams, kuri padeda jiems greitai perkelti pakeitimus į gamybą.
Anksčiau sistemos administratoriai buvo paskutinis bastionas, po kurio viskas pereina į gamybą. Ir iš esmės jie užsiėmė nuolatiniu gaisrų gesinimu – kurio šviesoje gana sunku įsigilinti į verslo poreikius, galvoti apie produktą ir naudą vartotojui.
DevOps metodo dėka mąstymas keičiasi. Sistemos administratorius supranta, kaip paversti konfigūraciją į kodą, kokia praktika tam egzistuoja.
Tai svarbu, nes įmonės vis labiau suvokia, kad joms reikia ne tik viską automatizuoti, t.y. tai, ką iš esmės buvo įpratę daryti senosios mokyklos sistemų administratoriai, kurie be to mažai bendravo ir neinformavo komandos apie visus atliktus pakeitimus. Dabar komandos ieško tų, kurie taps vidinės infrastruktūros produkto gamintoju ir padės sujungti atskirtus procesus į vieną.
Kūrėjai
Kūrėjas nustoja mąstyti tik algoritmais. Jis įgyja darbo su infrastruktūra įgūdžių, kraštovaizdžio architektūrinio suvokimo įgūdžius. Toks kūrėjas supranta, kaip programa veikia, kaip ji eina per nuolatinį pristatymo vamzdyną, kaip ją stebėti, kaip užregistruoti, kad tai būtų naudinga klientui. Dėl to visos šios žinios leidžia parašyti atitinkamą kodą.
Testuotojams
Testavimas jau seniai pereina į automatinį režimą, visi sakome, kad daug testų reikia ne daryti, o rašyti :) Testavimas tampa viso Jūsų prekės pristatymo vamzdyno dalimi. Testuotojas turi ne tik išmokti rašyti kodą, bet ir suprasti, kaip jį integruoti į nuolatinio pristatymo sistemas, kaip gauti grįžtamąjį ryšį iš kodo visuose pristatymo etapuose ir kaip nuolat tobulinti testavimą, kad būtų galima aptikti klaidas. kuo anksčiau.
Taigi išeina, kad visi trys etapai vyksta vienu metu. Pavyzdžiui, tai gali atrodyti taip:
Kūrėjas parašo kodą, iš karto parašo jo testus ir aprašo dokerio konteinerį kodui, kuris turėtų būti paleistas. Taip pat iš karto aprašomas monitoringas, kuris stebės šios paslaugos veikimą gamyboje, ir visa tai įsipareigoja.
Kai prasideda nuolatinė integracija, procesai vyksta vienu metu. Paslauga paleidžiama ir sukonfigūruojama. Tuo pačiu metu paleidžiamas dokerio konteineris ir patikrinama, ar jis veikia. Tuo pačiu metu visa informacija patenka į registravimo sistemą. Ir taip kiekviename kūrimo etape – pasirodo, tai tikras sistemos administratorių, kūrėjų ir testuotojų komandinis darbas.
Studijavau „DevOps“, o kas toliau?
Kaip žinote, vienas lauke nėra karys. Jei jūsų įmonė nenaudoja šio metodo, įgyti įgūdžiai bus nenaudojami. O susipažinę su DevOps metodais greičiausiai nenorėsite būti įmonės plėtros sraigteliu. Gali būti viena išimtis: esate sistemos administratorius komandoje ir galite iš naujo sukurti visus procesus nauju būdu. Čia verta pridurti, kad yra daug įmonių, kurios taiko šį metodą, ir jos nėra paveiktos uždarymo ir ieško specialistų. Nes „DevOps“ yra internetinių produktų kūrimas.
O dabar apie gerus dalykus: „DevOps“ praktikos ir įrankių įvaldymas yra maždaug +30% jūsų vertės darbo rinkoje. Atlyginimai prasideda nuo 140 tūkstančių rublių, tačiau, žinoma, priklauso nuo jūsų pagrindinės specialybės ir funkcionalumo.
Galite peržiūrėti laisvas darbo vietas, pažymėtas „orientuota į infrastruktūrą“, kur yra testavimo automatizavimas, mikro paslaugų programų kūrimas naudojant debesų technologijas, laisvos vietos infrastruktūros inžinieriams ir visokios nuorodos į „DevOps“. Tiesiog nepamirškite, kad kiekviena įmonė šiuo apibrėžimu reiškia kažką skirtingą – atidžiai perskaitykite aprašymą.
Pradėjus mūsų kursą, supratau – daugelis žmonių po kurso patenka į „DevOps“ inžinieriaus pinkles. Jie suranda laisvą vietą minėtu pavadinimu, gauna gerą pasiūlymą, o tada ateina į darbą ir supranta, kad Jenkinse turės išlaikyti trijų puslapių bash scenarijų. Kur yra „Kubernetes“, „ChatOps“, „Canary“ leidimai ir visa tai? Bet nieko nėra, nes įmonei nereikia DevOps kaip metodikos, o naudoja individualias naujoves.
Tai yra priežastis intensyviai iš įmonės pasidomėti, kaip veikia programinės įrangos pristatymo procesas, technologijų krūva ir kokias pareigas atliksite.
Jei darbdavys į jūsų klausimus atsako abstrakčiai, tarsi iš knygos, be detalių, tai greičiausiai įmonėje dar nėra „DevOps“ proceso, tačiau tai nėra priežastis atsisakyti, išstudijuokite įmonę ir jos produktus, ar yra internete. paslaugos, kurias kuria pati įmonė, mobiliosios aplikacijos , produktų idėjos.
Jei taip, paaiškinkite, ar turėsite dirbti tiesiogiai su šiomis sistemomis, ar yra galimybė horizontaliai judėti šių paslaugų komandoms, demonstruojant gerus DevOps praktikos rezultatus. Jei taip, tuomet verta eiti ir būti aktyviam bei naudingam, o jei baigsite mūsų kursą, pastarasis garantuotas.
Svarbu pažymėti, kad Devops praktikai įgyja tikrą vertę tik turėdami kūrimo/administravimo/testavimo patirties. Tik tada žinios bus ne abstrakčios, o praturtins specialistą (visomis prasmėmis). Todėl idėja „išmokti „DevOps“ nuo nulio“ yra maždaug tokia pati, kaip išmokti „naudoti objektyvus nuo nulio“, jei niekada nelaikėte fotoaparato rankose ir nerežisavote fotografavimo. Norėdami padėti apsispręsti, ar kursas jums tinka, atlikome stojamąjį testą, kuris patikrins jūsų pakankamą žinių lygį.
Manau, viena iš gudrybių - kad mokymo eigoje kiekvienas studentas pats nusprendžia, kuria kryptimi nori tobulėti. Dažnai matome perėjimus, kai kūrėjas tampa infrastruktūros inžinieriumi, o administratorius supranta, kad jam įdomu rašyti kodą – tada toliau mokosi kalbos ir ją papildo įgytais DevOps įgūdžiais. Todėl ypač laukiame tų, kurie jaučia, kad jų karjera įstrigo kryžkelėje. Kursų pradžia gegužės 28 d., tačiau prisijungti galima praėjus 2 savaitėms nuo užsiėmimų pradžios. Galite peržiūrėti programą ir atlikti testą . Iki pasimatymo OTUS!
Šaltinis: www.habr.com