ProHoster > Blogs > Administrācija > Par administratoriem, devops, nebeidzamu apjukumu un DevOps transformāciju uzņēmumā

Par administratoriem, devops, nebeidzamu apjukumu un DevOps transformāciju uzņēmumā

Par administratoriem, devops, nebeidzamu apjukumu un DevOps transformāciju uzņēmumā

Kas nepiecieÅ”ams, lai IT uzņēmums 2019. gadā bÅ«tu veiksmÄ«gs? Lektori konferencēs un sanāksmēs saka daudz skaļu vārdu, kas ne vienmēr ir saprotami normāliem cilvēkiem. Cīņa par izvietoÅ”anas laiku, mikropakalpojumiem, atteikÅ”anos no monolÄ«ta, DevOps transformāciju un daudz ko citu. Ja mēs atmetam verbālo skaistumu un runājam tieÅ”i un krieviski, tad viss nonāk pie vienkārÅ”as tēzes: izgatavojiet augstas kvalitātes produktu un dariet to ar komfortu komandai.

Pēdējais ir kļuvis ļoti svarÄ«gs. Bizness beidzot ir nonācis pie secinājuma, ka ērts izstrādes process palielina produktivitāti, un, ja viss tiek atkļūdots un darbojas kā pulkstenis, tas arÄ« dod zināmu manevrÄ“Å”anas iespēju kritiskās situācijās. Kādreiz Ŕī manevra dēļ kāds gudrs cilvēks izdomāja rezerves kopijas, bet nozare attÄ«stās, un mēs nonācām pie DevOps inženieriem - cilvēkiem, kuri attÄ«stÄ«bas un ārējās infrastruktÅ«ras mijiedarbÄ«bas procesu pārvērÅ” par kaut ko adekvātu un nav saistÄ«ts ar Å”amanismu.

Viss Å”is ā€œmodulāraisā€ stāsts ir brÄ«niŔķīgs, bet... SagadÄ«jās tā, ka daži no administratoriem pēkŔņi tika nodēvēti par DevOps, un paÅ”iem DevOps inženieriem sāka prasÄ«t vismaz telepātijas un gaiÅ”redzÄ«bas prasmes.

Pirms runāt par mÅ«sdienu problēmām infrastruktÅ«ras nodroÅ”ināŔanā, definēsim, ko mēs saprotam ar Å”o terminu. PaÅ”reizējā brÄ«dÄ« situācija ir izveidojusies tā, ka esam nonākuÅ”i lÄ«dz Ŕī jēdziena dualitātei: infrastruktÅ«ra var bÅ«t nosacÄ«ti ārēja un nosacÄ«ti iekŔēja.

Ar ārējo infrastruktÅ«ru saprotam visu, kas nodroÅ”ina komandas attÄ«stāmā pakalpojuma vai produkta funkcionalitāti. Tie ir lietojumprogrammu vai vietņu serveri, hostings un citi pakalpojumi, kas nodroÅ”ina produkta funkcionalitāti.

IekŔējā infrastruktÅ«ra ietver pakalpojumus un aprÄ«kojumu, ko izmanto pati izstrādes komanda un citi darbinieki, kuru parasti ir daudz. Tie ir koda glabāŔanas sistēmu iekŔējie serveri, lokāli izvietots uzdevumu pārvaldnieks un viss, viss, viss, kas pastāv uzņēmuma iekÅ”tÄ«klā.

Ko uzņēmumā dara sistēmas administrators? Papildus Ŕī korporatÄ«vā iekÅ”tÄ«kla administrÄ“Å”anas darbam tas bieži vien ir saistÄ«ts ar ekonomisku apsvērumu nastu, lai nodroÅ”inātu biroja aprÄ«kojuma darbÄ«bu. Admins ir tas pats puisis, kurÅ” ātri izvilks no aizmugures istabas jaunu sistēmas bloku vai rezerves portatÄ«vo datoru, kas ir gatavs lietoÅ”anai, izdos jaunu tastatÅ«ru un četrrāpus rāpo pa birojiem, stiepjot Ethernet kabeli. Administrators ir ne tikai iekŔējo un ārējo serveru vietējais Ä«paÅ”nieks un pārvaldÄ«tājs, bet arÄ« uzņēmuma vadÄ«tājs. Jā, daži administratori var strādāt tikai sistēmas plaknē, bez aparatÅ«ras. Tie ir jāiedala atseviŔķā ā€œinfrastruktÅ«ras sistēmu administratoruā€ apakÅ”klasē. Un daži specializējas tikai biroja aprÄ«kojuma apkalpoÅ”anā; par laimi, ja uzņēmumā ir vairāk nekā simts cilvēku, darbs nekad nebeidzas. Bet neviens no viņiem nav devops.

Kas ir DevOps? Devops ir puiÅ”i, kuri runā par programmatÅ«ras izstrādes mijiedarbÄ«bu ar ārējo infrastruktÅ«ru. PrecÄ«zāk, mÅ«sdienu devops ir iesaistÄ«ts izstrādes un izvietoÅ”anas procesos daudz dziļāk, nekā jebkad bija iesaistÄ«ti administratori, kuri vienkārÅ”i augÅ”upielādēja atjauninājumus uz ftp. Viens no galvenajiem DevOps inženiera uzdevumiem tagad ir nodroÅ”ināt ērtu un efektÄ«vi strukturētu mijiedarbÄ«bas procesu starp izstrādes komandām un produktu infrastruktÅ«ru. TieÅ”i Å”ie cilvēki ir atbildÄ«gi par atcelÅ”anas un izvietoÅ”anas sistēmu izvietoÅ”anu; tie ir tie, kas noņem daļu no izstrādātāju slodzes un pēc iespējas vairāk koncentrējas uz savu ārkārtÄ«gi svarÄ«go uzdevumu. Tajā paŔā laikā devops nekad nepalaidÄ«s jaunu kabeli vai neizdos jaunu klēpjdatoru no aizmugures telpas (c) KO

Kāds ir loms?

Uz jautājumu "Kas ir DevOps?" puse lauka strādnieku sāk atbildēt kaut ko lÄ«dzÄ«gu ā€œNu, Ä«si sakot, tas ir administrators, kurÅ” ...ā€ un tālāk tekstā. Jā, kādreiz, kad DevOps inženiera profesija tikko izcēlās no servisa uzturÄ“Å”anas ziņā talantÄ«gākajiem administratoriem, atŔķirÄ«bas starp viņiem nebija acÄ«mredzamas visiem. Taču tagad, kad devopa un admin funkcijas komandā ir kļuvuÅ”as kardināli atŔķirÄ«gas, ir nepieņemami tos sajaukt savā starpā vai pat pielÄ«dzināt.

Bet ko tas nozīmē biznesam?

Noma, tas viss ir par to.

JÅ«s atverat vakanci uz ā€œSistēmas administratoruā€, un tajā norādÄ«tās prasÄ«bas ir ā€œmijiedarbÄ«ba ar attÄ«stÄ«bu un klientiemā€, ā€œCI/CD piegādes sistēmaā€, ā€œuzņēmuma serveru un aprÄ«kojuma uzturÄ“Å”anaā€, ā€œiekŔējo sistēmu administrÄ“Å”anaā€ utt. ieslēgts; tu saproti, ka darba devējs runā muļķības. Āķis ir tāds, ka ā€œSistēmas administratoraā€ vietā vakances nosaukumam jābÅ«t ā€œDevOps Engineerā€, un, ja Å”is nosaukums tiek mainÄ«ts, viss nostājas savās vietās.

Tomēr kāds iespaids rodas, lasot Ŕādu vakanci? Ka uzņēmums meklē vairāku maŔīnu operatoru, kurÅ” izvietos gan versiju kontroles, gan uzraudzÄ«bas sistēmu un izspiedÄ«s tvisteri ar zobiem...

Bet, lai darba tirgÅ« nepalielinātu atkarÄ«bas no narkotikām, pietiek nosaukt vakances Ä«stajos vārdos un skaidri saprast, ka DevOps inženieris un sistēmas administrators ir divas dažādas vienÄ«bas. Taču dažu darba devēju nepārvaramā vēlme izvirzÄ«t kandidātam pēc iespējas plaŔāku prasÄ«bu sarakstu noved pie tā, ka ā€œklasiskieā€ sistēmu administratori pārstāj saprast, kas notiek apkārt. Ko, profesija mutē un viņi ir atpalikuÅ”i no laika?

Nē nē un vēl vienu reizi nē. InfrastruktÅ«ras administratori, kas pārvaldÄ«s uzņēmuma iekŔējos serverus vai ieņems L2/L3 atbalsta amatus un palÄ«dzēs citiem darbiniekiem, nav devuÅ”ies prom un netaisās aiziet.

Vai Å”ie speciālisti var kļūt par DevOps inženieriem? Protams, viņi var. Faktiski Ŕī ir saistÄ«ta vide, kas prasa sistēmas administrÄ“Å”anas prasmes, bet papildus tam tiek pievienots darbs ar monitoringa, piegādes sistēmām un kopumā cieÅ”a mijiedarbÄ«ba ar izstrādes un testÄ“Å”anas komandu.

Vēl viena DevOps problēma

PatiesÄ«bā viss neaprobežojas tikai ar pieņemÅ”anu darbā un pastāvÄ«gu sajukumu starp administratoriem un devops. Kādā brÄ«dÄ« uzņēmums saskārās ar problēmu, kas saistÄ«ta ar atjauninājumu piegādi un izstrādes komandas mijiedarbÄ«bu ar galÄ«go infrastruktÅ«ru.

VarbÅ«t tas notika, kad onkulis ar mirdzoŔām acÄ«m piecēlās uz kādas konferences skatuves un teica: ā€œMēs to darām un saucam par DevOps. Å ie puiÅ”i atrisinās visas jÅ«su problēmasā€ - un sāka stāstÄ«t, cik laba ir dzÄ«ve uzņēmumā pēc DevOps prakses ievieÅ”anas.

Tomēr nepietiek ar DevOps inženiera nolÄ«gÅ”anu, lai viss darbotos tā, kā vajadzētu. Uzņēmumam ir jāveic pilnÄ«ga DevOps transformācija, tas ir, mÅ«su DevOps loma un iespējas ir skaidri jāsaprot arÄ« produktu izstrādes un testÄ“Å”anas komandas pusē. Mums ir "brÄ«niŔķīgs" stāsts par Å”o tēmu, kas pilnÄ«bā ilustrē visu brutalitāti, kas notiek dažviet.

Situācija. DevOps ir jāizvieto versijas atcelÅ”anas sistēma, Ä«sti neiedziļinoties tajā, kā tā darbosies. Pieņemsim, ka Lietotāju sistēmā ir atseviŔķi lauki vārdam, uzvārdam un parolei. Iznāk jauna produkta versija, taču izstrādātājiem ā€œatgrieÅ”anaā€ ir tikai burvju nÅ«jiņa, kas visu izlabos, un viņi pat nezina, kā tas darbojas. Tā, piemēram, nākamajā ielāpā izstrādātāji apvienoja vārda un uzvārda laukus, izrullēja to ražoÅ”anā, taču versija nez kāpēc ir lēna. Kas notiek? VadÄ«ba ierodas devops un saka ā€œPavelciet slēdzi!ā€, tas ir, lÅ«dz viņam atgriezties pie iepriekŔējās versijas. Ko dara devops? Tas atgriežas pie iepriekŔējās versijas, taču, tā kā izstrādātāji nevēlējās noskaidrot, kā Ŕī atcelÅ”ana tika veikta, neviens neteica devops komandai, ka arÄ« datu bāze ir jāatgriež. Rezultātā mums viss sabrÅ«k un lēnas mājas lapas vietā lietotāji redz ā€œ500ā€ kļūdu, jo vecā versija nestrādā ar jaunās datu bāzes laukiem. Devops par to nezina. Izstrādātāji klusē. VadÄ«ba sāk zaudēt nervus un naudu un atceras dublējumus, piedāvājot atkāpties no tiem, lai "vismaz kaut kas izdotos". Tā rezultātā lietotāji noteiktā laika periodā zaudē visus savus datus.

Rieksti, protams, iet uz devops, kas "neizveidoja pareizu atcelÅ”anas sistēmu", un nevienu neinteresē, ka Å”ajā stāstā redzamie aļņi ir izstrādātāji.

Secinājums ir vienkārŔs: bez normālas pieejas DevOps kā tādai tas ir maz lietderīgi.
Galvenais, kas jāatceras: DevOps inženieris nav burvis, un bez kvalitatÄ«vas komunikācijas un divvirzienu mijiedarbÄ«bas ar attÄ«stÄ«bu viņŔ netiks galā ar saviem uzdevumiem. Izstrādātājus nevar atstāt vienus ar savām ā€œproblēmāmā€ vai dot komandu ā€œnejaukties ar izstrādātājiem, viņu uzdevums ir kodētā€, un tad cerēt, ka kritiskā brÄ«dÄ« viss darbosies kā nākas. Tas nedarbojas tā.

BÅ«tÄ«bā DevOps ir kompetence uz robežas starp pārvaldÄ«bu un tehnoloÄ£iju. Turklāt nebÅ«t nav acÄ«mredzams, ka Å”ajā kokteilÄ« vajadzētu bÅ«t vairāk tehnoloÄ£ijai nekā vadÄ«bai. Ja patieŔām vēlaties izveidot ātrākus un efektÄ«vākus izstrādes procesus, jums jāuzticas savai devops komandai. ViņŔ zina pareizos rÄ«kus, viņŔ ir Ä«stenojis lÄ«dzÄ«gus projektus, viņŔ zina, kā to izdarÄ«t. PalÄ«dziet viņam, klausieties viņa padomu, nemēģiniet viņu izolēt kaut kādā autonomā vienÄ«bā. Ja administratori var strādāt paÅ”i, tad devops Å”ajā gadÄ«jumā ir bezjēdzÄ«gs; viņi nevarēs jums palÄ«dzēt kļūt labākam, ja jÅ«s pats nevēlaties pieņemt Å”o palÄ«dzÄ«bu.

Un pēdējā lieta: beidziet aizvainot infrastruktÅ«ras administratorus. Viņiem ir sava, ārkārtÄ«gi svarÄ«ga darba fronte. Jā, administrators var kļūt par DevOps inženieri, taču tam ir jānotiek pēc paÅ”a cilvēka lÅ«guma, nevis zem spiediena. Un nav nekas slikts, ka sistēmas administrators vēlas palikt sistēmas administrators - tā ir viņa atseviŔķā profesija un viņa tiesÄ«bas. Ja vēlies veikt profesionālu transformāciju, tad nekad nedrÄ«kst aizmirst, ka bÅ«s jāveido ne tikai tehnoloÄ£iskās, bet arÄ« vadÄ«bas prasmes. Visticamāk, tas bÅ«s jÅ«su kā vadÄ«tāja ziņā, lai visus Å”os cilvēkus apvienotu un iemācÄ«tu viņiem sazināties vienā valodā.

Avots: www.habr.com

Pievieno komentāru