Ko reikia, kad IT įmonė būtų sėkminga 2019 metais? Konferencijų ir susitikimų lektoriai sako daug skambių žodžių, kurie ne visada suprantami normaliems žmonėms. Kova dėl diegimo laiko, mikropaslaugų, monolito atsisakymo, DevOps transformacijos ir daug, daug daugiau. Jei atsisakome žodinio grožio ir kalbame tiesiai bei rusiškai, tada viskas susiveda į paprastą tezę: pagaminkite kokybišką gaminį ir darykite tai patogiai komandai.
Pastarasis tapo labai svarbus. Verslas pagaliau priėjo prie išvados, kad patogus kūrimo procesas didina produktyvumą, o jei viskas derinama ir veikia kaip laikrodis, tai suteikia ir šiek tiek manevro erdvės kritinėse situacijose. Kažkada šio manevro vardan tam tikras protingas žmogus sugalvojo atsargines kopijas, bet pramonė vystosi, ir mes priėjome prie DevOps inžinierių – žmonių, kurie plėtros ir išorinės infrastruktūros sąveikos procesą paverčia kažkuo adekvačiu ir nesusijęs su šamanizmu.
Visa ši „modulinė“ istorija nuostabi, bet... Taip jau susiklostė, kad kai kurie administratoriai staiga buvo pavadinti „DevOps“, o iš pačių „DevOps“ inžinierių pradėjo reikalauti bent jau telepatijos ir aiškiaregystės įgūdžių.
Prieš kalbėdami apie šiuolaikines infrastruktūros suteikimo problemas, apibrėžkime, ką turime omenyje šiuo terminu. Šiuo metu situacija susiklosčiusi taip, kad pasiekėme šios sąvokos dvilypumą: infrastruktūra gali būti sąlyginai išorinė ir sąlyginai vidinė.
Išorine infrastruktūra turime omenyje viską, kas užtikrina komandos kuriamos paslaugos ar produkto funkcionalumą. Tai aplikacijų ar svetainių serveriai, priegloba ir kitos paslaugos, užtikrinančios produkto funkcionalumą.
Vidinė infrastruktūra apima paslaugas ir įrangą, kuria naudojasi pati kūrimo komanda ir kiti darbuotojai, kurių paprastai būna daug. Tai yra vidiniai kodų saugojimo sistemų serveriai, lokaliai įdiegta užduočių tvarkyklė ir viskas, viskas, viskas, kas egzistuoja įmonės intranete.
Ką įmonėje veikia sistemos administratorius? Be šio įmonės intraneto administravimo, dažnai tenka ir ekonominių rūpesčių naštai užtikrinti biuro įrangos veikimą. Administratorius yra tas pats, kuris greitai iš užpakalinio kambario ištemps naują sisteminį bloką arba atsarginį naudojimui paruoštą nešiojamąjį kompiuterį, išduos naują klaviatūrą ir keturiomis kojomis šliaužios per biurus, tempdamas Ethernet kabelį. Administratorius yra vietinis ne tik vidinių ir išorinių serverių savininkas ir valdytojas, bet ir verslo vadovas. Taip, kai kurie administratoriai gali dirbti tik sistemos plokštumoje, be techninės įrangos. Jie turėtų būti atskirti į atskirą „infrastruktūros sistemų administratorių“ poklasį. O kai kurie specializuojasi tik biuro įrangos aptarnavime; laimei, jei įmonėje dirba daugiau nei šimtas žmonių, darbas niekada nesibaigia. Tačiau nė vienas iš jų nėra devopas.
Kas yra „DevOps“? Devops yra vaikinai, kurie kalba apie programinės įrangos kūrimo sąveiką su išorine infrastruktūra. Tiksliau, šiuolaikiniai devopai yra įtraukti į kūrimo ir diegimo procesus daug giliau, nei kada nors dalyvavo administratoriai, kurie tiesiog įkėlė naujinimus į ftp. Viena iš pagrindinių „DevOps“ inžinieriaus užduočių dabar yra užtikrinti patogų ir efektyviai struktūrizuotą sąveikos tarp kūrimo komandų ir produkto infrastruktūros procesą. Būtent šie žmonės yra atsakingi už atšaukimo ir diegimo sistemų diegimą; būtent šie žmonės nuima dalį kūrėjų apkrovos ir kiek įmanoma daugiau dėmesio skiria savo nepaprastai svarbiai užduočiai. Tuo pačiu metu „devops“ niekada nepaleis naujo laido arba neišduos naujo nešiojamojo kompiuterio iš galinės patalpos (c) KO
Koks laimikis?
Į klausimą „Kas yra „DevOps“? pusė lauko darbuotojų pradeda atsakyti maždaug taip: „Na, trumpai tariant, tai yra administratorius, kuris ...“ ir toliau tekste. Taip, kažkada, kai DevOps inžinieriaus profesija dar tik veržėsi iš talentingiausių paslaugų priežiūros administratorių, skirtumai tarp jų buvo akivaizdūs ne visiems. Tačiau dabar, kai devopų ir admino funkcijos komandoje kardinaliai skiriasi, jų painiojimas ar net tapatinimas yra nepriimtinas.
Bet ką tai reiškia verslui?
Įdarbinimas, viskas apie tai.
Jūs atidarote laisvą darbo vietą „Sistemos administratoriui“, o ten nurodyti reikalavimai yra „sąveika su plėtra ir klientais“, „CI/CD pristatymo sistema“, „įmonės serverių ir įrangos priežiūra“, „vidinių sistemų administravimas“ ir pan. įjungta; supranti, kad darbdavys šneka nesąmones. Bėda ta, kad vietoj „System Administrator“ laisvos darbo vietos pavadinimas turėtų būti „DevOps Engineer“, o jei šis pavadinimas pakeičiamas, viskas stoja į savo vietas.
Tačiau koks įspūdis susidaro skaitant tokią laisvą vietą? Kad įmonė ieško kelių mašinų operatoriaus, kuris įdiegtų ir versijų valdymo, ir stebėjimo sistemą, ir dantimis suspaustų twisterį...
Tačiau norint nedidinti priklausomybės nuo narkotikų laipsnio darbo rinkoje, užtenka laisvas darbo vietas vadinti tinkamais vardais ir aiškiai suprasti, kad „DevOps“ inžinierius ir sistemos administratorius yra du skirtingi subjektai. Tačiau nenumaldomas kai kurių darbdavių noras kandidatui pateikti kuo platesnį reikalavimų sąrašą veda prie to, kad „klasikiniai“ sistemų administratoriai nustoja suprasti, kas vyksta aplinkui. Ką, profesija mutuoja ir jie atsilieka nuo laiko?
Ne ne ir dar kartą ne. Infrastruktūros administratoriai, kurie valdys įmonės vidinius serverius arba užims L2/L3 palaikymo pareigas ir padės kitiems darbuotojams, niekur nedingo ir nesiruošia.
Ar šie specialistai gali tapti „DevOps“ inžinieriais? Žinoma, jie gali. Tiesą sakant, tai yra susijusi aplinka, kuriai reikalingi sistemos administravimo įgūdžiai, tačiau prie to pridedamas darbas su stebėjimo, pristatymo sistemomis ir apskritai glaudus bendravimas su kūrimo ir testavimo komanda.
Kita „DevOps“ problema
Tiesą sakant, viskas neapsiriboja vien samdymu ir nuolatiniu administratorių ir devops painiavomis. Tam tikru momentu verslas susidūrė su atnaujinimų pristatymo ir kūrimo komandos sąveikos su galutine infrastruktūra problema.
Galbūt tai buvo tada, kai dėdė spindinčiomis akimis atsistojo ant kokios nors konferencijos scenos ir pasakė: „Mes tai darome ir vadiname „DevOps“. Šie vaikinai išspręs visas jūsų problemas“ – ir pradėjo pasakoti, koks geras gyvenimas kompanijoje įdiegus DevOps praktiką.
Tačiau neužtenka pasamdyti „DevOps“ inžinierių, kad viskas veiktų taip, kaip turėtų. Įmonėje turi būti atlikta visiška „DevOps“ transformacija, tai yra, mūsų „DevOps“ vaidmuo ir galimybės taip pat turi būti aiškiai suprantamos produktų kūrimo ir testavimo komandos pusėje. Šia tema turime „nuostabią“ istoriją, kuri visiškai iliustruoja visą kai kuriose vietose vykstantį brutalumą.
Situacija. „DevOps“ turi įdiegti versijos atšaukimo sistemą, iš tikrųjų nesigilinant į tai, kaip ji veiks. Tarkime, kad Vartotojų sistemoje yra atskiri vardo, pavardės ir slaptažodžio laukai. Išeina nauja produkto versija, tačiau kūrėjams „atšaukimas“ yra tik burtų lazdelė, kuri viską sutvarkys, o jie net nežino, kaip tai veikia. Taigi, pavyzdžiui, kitame pataise kūrėjai sujungė vardo ir pavardės laukus, išleido į gamybą, tačiau versija kažkodėl lėta. Kas vyksta? Vadovybė ateina į „devops“ ir sako „Patrauk jungiklį!“, Tai yra, prašo jo grįžti į ankstesnę versiją. Ką veikia devops? Ji grįžta į ankstesnę versiją, bet kadangi kūrėjai nenorėjo išsiaiškinti, kaip buvo atliktas šis atšaukimas, niekas nepasakė devops komandai, kad duomenų bazė taip pat turi būti grąžinta. Dėl to pas mus viskas užstringa, o vietoje lėtos svetainės vartotojai mato klaidą „500“, nes senoji versija neveikia su naujos duomenų bazės laukeliais. Devops apie tai nežino. Kūrėjai tyli. Vadovybė pradeda prarasti nervus ir pinigus ir prisimena atsargines kopijas, siūlydama atsisakyti jų, kad „bent kažkas pavyktų“. Dėl to vartotojai per tam tikrą laiką praranda visus savo duomenis.
Riešutai, žinoma, eina į devops, kurie „nesukūrė tinkamos atšaukimo sistemos“, ir niekam nerūpi, kad šios istorijos briedžiai yra kūrėjai.
Išvada paprasta: be įprasto požiūrio į „DevOps“ tai mažai naudinga.
Svarbiausia atsiminti: „DevOps“ inžinierius nėra magas, be kokybiškų ryšių ir dvipusio sąveikos su plėtra jis nesusidoros su savo užduotimis. Kūrėjai negali būti palikti vieni su savo „problemais“ arba duoti komandos „nesikišti su kūrėjais, jų darbas yra koduoti“, o tada tikėtis, kad kritiniu momentu viskas veiks taip, kaip turėtų. Tai ne taip.
Iš esmės „DevOps“ yra valdymo ir technologijų ribos kompetencija. Be to, toli gražu nėra akivaizdu, kad šiame kokteilyje turėtų būti daugiau technologijų nei valdymo. Jei tikrai norite sukurti greitesnius ir efektyvesnius kūrimo procesus, turite pasitikėti savo devops komanda. Jis žino tinkamus įrankius, yra įgyvendinęs panašius projektus, žino, kaip tai padaryti. Padėkite jam, klausykite jo patarimų, nesistenkite jo izoliuoti į kokį nors savarankišką vienetą. Jei administratoriai gali dirbti patys, tada devopai šiuo atveju yra nenaudingi; jie negalės padėti jums tapti geresniems, jei patys nenorite priimti šios pagalbos.
Ir paskutinis dalykas: nustokite įžeidinėti infrastruktūros administratorius. Jie turi savo, nepaprastai svarbų darbo frontą. Taip, administratoriumi gali tapti „DevOps“ inžinieriumi, tačiau tai turėtų įvykti paties žmogaus pageidavimu, o ne spaudžiant. Ir nieko blogo tame, kad sistemos administratorius nori likti sistemos administratoriumi – tai jo atskira profesija ir teisė. Jei norite patirti profesinę transformaciją, niekada nepamirškite, kad turėsite įgyti ne tik technologinius, bet ir valdymo įgūdžius. Greičiausiai jūs, kaip lyderis, turėsite suburti visus šiuos žmones ir išmokyti juos bendrauti ta pačia kalba.
Šaltinis: www.habr.com