Par administratoriem, devopsiem, bezgalīgu neskaidrību un DevOps transformāciju uzņēmumā

Kas nepieciešams IT uzņēmuma panākumiem 2019. gadā? Lekcijās un sanāksmēs lektori runā daudz skaļu un ne vienmēr saprotamu vārdu. Cīņa par izvietošanas laiku, mikropakalpojumi, atteikšanās no monolīta, DevOps transformācija un daudz, daudz kas cits. Ja atmetam vārdu skaistumu un runājam tieši, tad viss samazinās līdz vienkāršam apgalvojumam: izveidojiet kvalitatīvu produktu, un dariet to pats komfortabli komandai.

Pēdējais ir kļuvis kritiski svarīgs. Bizness beidzot ir nonācis pie domas, ka komfortabla izstrādes procesa uzlabo produktivitāti, un, ja viss ir noregulēts un darbojas kā pulkstenis, tas vēl dod zināmu manevru iespēju kritiskās situācijās. Kad reiz šī manevra dēļ kāds gudrs cilvēks izdomāja rezerves kopijas, bet nozare attīstās un mēs esam nonākuši pie DevOps inženieriem — cilvēkiem, kuri pārveido izstrādes un ārējās infrastruktūras mijiedarbības procesu par kaut ko saprātīgu un nesaistītu ar šamanismu.

Visa šī stāsts ar 'moduļa' principu ir brīnišķīgs, bet… Sanāca tā, ka daļu administratoru pēkšņi nosauca par DevOps, bet no pašiem DevOps inženieriem sāka prasīt vismaz telepātijas un skaidrredzes prasmes.

Pirms runājam par mūsdienu infrastruktūras nodrošināšanas problēmām, definēsim, ko mēs ar šo terminu saprotam. Pašlaik situācija ir izveidojusies tā, ka mēs esam nonākuši pie šī jēdziena dualitātes: infrastruktūra var būt nosacīti ārēja un nosacīti iekšēja.

Par ārējo infrastruktūru jāsaprot viss, kas nodrošina pakalpojuma vai produkta darbību, kuru izstrādā komanda. Tas ir lietojumprogrammu vai vietnes serveri, hostings un citi pakalpojumi, kas nodrošina produkta darbību.

Iekšējā infrastruktūra ietver pakalpojumus un aprīkojumu, ar ko izmanto pati izstrādes komanda un citi darbinieki, kuri parasti ir diezgan daudz. Tas ir iekšējie kodu glabāšanas serveri, lokāli izvietots uzdevumu pārvaldnieks un viss, kas pastāv korporatīvā intranetā.

Ko tad īsti dara sistēmas administrators uzņēmumā? Turklāt, strādājot ar korporatīvo intraneti, viņam bieži vien ir jāparūpējas arī par biroja aprīkojuma darbspējīgumu. Administrators ir tas puisis, kurš ātri atnes no noliktavas jaunu datoru vai darba gatavo klēpjdatoru, izsniedz jaunu tastatūru un rāpo pa kabinetiem, velkot Ethernet kabeli. Administrators ir vietējais saimnieks un pavēlnieks ne tikai iekšējā, bet arī ārējā serveriem, kā arī saimnieks. Jā, daži administratori var strādāt tikai sistēmiskajā jomā, bez aparatūras. Viņus var izcelt kā atsevišķu apakšklasi "infrastruktūras sistēmas administratorus". Bet kāds specializējas tikai biroja aprīkojuma apkalpē, jo, ja uzņēmumā ir vairāk nekā simts cilvēku, darbs nekad nebeidzas. Taču ne tie, ne citi nav devops.

Un kas ir DevOps? Devopsi ir puiši, kuri nodarbojas ar programmatūras izstrādes mijiedarbību ar ārējo infrastruktūru. Precīzāk, mūsdienu devopsi ir iesaistīti izstrādes un izvietošanas procesos daudz dziļāk, nekā kādreiz bija iesaistīti administratori, kuri vienkārši augšupielādēja atjauninājumus ftp. Viens no galvenajiem DevOps inženiera uzdevumiem šobrīd ir nodrošināt patīkamu un efektīvi veidotu kolaborācijas procesu starp izstrādes komandām un produkta infrastruktūru. Tieši šie cilvēki ir atbildīgi par sistēmu izvietošanas un atgūšanas procesu organizēšanu, tie uzņem daļu slodzes no izstrādātājiem un maksimāli koncentrējas uz savu ļoti svarīgo uzdevumu. Tajā pašā laikā devops nekad nevels jaunu kabeli vai neizsniedz jaunu klēpjdatoru no noliktavas (c) KO

Kur ir aizsardzība?

At the question "Who is a DevOps?" half of the industry workers start answering something like, "Well, basically, it’s such an admin who..." and continue from there. Yes, a long time ago, when the profession of DevOps engineer was just sprouting from the most talented service admins, the differences between them were not obvious to everyone. But now, when the roles of DevOps and admins in teams have become radically different, confusing them or even equating them is unacceptable.

But what does this mean for business?

Hiring, that's the issue.

You open a job listing for a "System Administrator," and it lists requirements like "interaction with development and clients," "CI/CD delivery system," "maintenance of company servers and equipment," "administration of internal systems," etc.; you understand that the employer is talking nonsense. The catch is that instead of "System Administrator," the job title should be "DevOps Engineer," and if this title is changed, everything falls into place.

However, what impression is created when reading such a vacancy? That the company is looking for a multitasker who will set up both version control and monitoring systems, and even compress their database with their teeth...

And to avoid raising the level of absurdity in the job market, it is enough to name vacancies accurately and clearly understand that a DevOps engineer and a system administrator are two different entities. However, the insatiable desire of some employers to demand as broad a list of requirements from candidates as possible leads to "classic" system administrators losing sight of what is happening around them. What, the profession is mutating and they are out of touch with reality?

No, no, and once again no. Infrastructure admins who will manage the company's internal servers or hold L2/L3 support positions to assist other employees have not gone anywhere and are not going anywhere.

Vai šie speciālisti var kļūt par DevOps inženieriem? Protams, var. Patiesībā, tas ir radniecīgs viņu videi, kas prasa sistēmā administrēšanas prasmes, taču, papildus tam, tiek pievienots darbs ar monitoringu, piegādes sistēmām un, kopumā, cieša sadarbība ar izstrādātāju un testēšanas komandu.

Vēl viena DevOps problēma

Patiesībā, tikai ar pieņemšanu darbā un pastāvīgu neskaidrību starp administratoriem un devops nav viss beidzies. Kādu brīdi uzņēmums saskārās ar problēmu, kad bija nepieciešams piegādāt jauninājumus un nodrošināt sadarbību starp izstrādes komandu un gala infrastruktūru.

Iespējams, tas notika tad, kad kādā konferences skatuvē uzkāpa onkulis ar ugunīgām acīm un teica: "Mēs darām tā un saucam to par DevOps. Šie puiši atrisinās visas jūsu problēmas" — un sāka stāstīt, cik labi dzīvojas kompānijā pēc DevOps prakses ieviešanas.

Tomēr nav pietiekami vienkārši pieņemt darbā DevOps inženieri, lai viss darbotos "kā vajag". Uzņēmumam jāveic pilnīga DevOps transformācija, t.i., mūsu devops lomai un iespējām jābūt skaidri apzinātām arī izstrādes un testēšanas komandas pusē. Par šo tēmu mums ir "brīnišķīga" stāsts, kas pilnībā ilustē visu, kas notiek vietām.

Situācija. No devopsa prasa izveidot versiju atgaitas sistēmu, īpaši neizprotot, kā tā darbosies. Pieņemsim, ka iekšējā sistēmā Users ir atsevišķi lauki vārda, uzvārda un paroles ievadīšanai. Parādās jauna produkta versija, bet izstrādātājiem "atgaitas" ir vienkārši burvju nūjiņa, kas visu salabo, un viņi pat neiztēlojas, kā tas darbojas. Tātad, piemēram, izstrādātāji kādā jaunajā labojumā apvienoja vārda un uzvārda laukus, izlaida to ražošanā, bet versija kaut kādu iemeslu dēļ palēninās. Kas notiek? Vadība pievēršas devopam un saka: "Pievilciet slēdzi!", t.i., lūdz viņu atgriezties pie iepriekšējās versijas. Ko dara devops? Viņš atgriežas pie iepriekšējās versijas, bet, tā kā izstrādātāji nevēlējās izprotot, kā veikt šo atgaitu, neviens devopam nepasaka, ka jāatgriež arī datu bāze. Rezultātā mēs zaudējam pilnīgi visu, un lietotāji, nevis palēninātu vietni, redz kļūdu "500", jo vecā versija nedarbojas ar jaunās bāzes laukiem. Devops par to nav informēts. Izstrādātāji klusē. Vadība sāk zaudēt nervus un naudu un atceras par rezerves kopijām, piedāvājot atgriezties no tām, lai "vismaz kaut kas strādātu". Rezultātā lietotāji zaudē visus savus datus kādā laika periodā.

Protams, izsist uz deleģētā devopa, kurš "neizveidoja pareizu atgaitas sistēmu", bet tas, ka zilos šajā stāstā ir izstrādātāji, nevienu neuztrauc.

Secinājums ir vienkāršs: bez normāla pieejas DevOps kā tādam no tā nav daudz labuma.
Galvenais, kas jāatceras: DevOps inženieris nav burvis, un bez kvalitatīvām komunikācijām un divvirzienu mijiedarbības ar izstrādātājiem viņš nesaskarsies ar saviem uzdevumiem. Devops nevar tikt atstāts vienam ar savām "problēmām" vai dot komandu "nelien pie izstrādātājiem, viņu darbs ir kodēt", un pēc tam cerēt, ka kritiskajā brīdī viss darbosies kā vajag. Tā tas nenotiek.

Pamatā, DevOps ir kompetences, kas atrodas starp vadību un tehnoloģijām. Turklāt tā nemaz nav acīmredzama, ka šajā tehnoloģiju kokteiļā vajadzētu būt vairāk nekā vadības. Ja jūs tiešām vēlaties izveidot ātrākus un efektīvākus izstrādes procesus, jums jāuzticas savam DevOps speciālistam. Viņš zina nepieciešamos rīkus, ir īstenojis līdzīgus projektus un zina, kā to izdarīt. Palīdziet viņam, ieklausieties viņa ieteikumos, nemēģiniet izolēt viņu kādā autonomā struktūrā. Ja administratori var strādāt paši, tad DevOps speciālisti šādā gadījumā būs nevajadzīgi, viņi nevarēs jums palīdzēt kļūt labākiem, ja paši nevēlētos pieņemt šo palīdzību.

Un vēl viens: beidziet aizskart infrastruktūras administratorus. Viņiem ir savs, ļoti svarīgs darba frontes uzdevums. Jā, administrators var kļūt par DevOps inženieri, taču tas jādara paša vēlēšanās, nevis piespiedu kārtā. Nav nekas slikts, ja sistēmu administrators vēlas palikt par sistēmu administratoru — tā ir viņa atsevišķā profesija un viņa tiesības. Ja ir vēlēšanās piedalīties profesionālajā transformācijā, noteikti nevajag aizmirst, ka būs jāattīsta ne tikai tehnoloģiskās prasmes, bet arī vadības prasmes. Visticamāk, būs jāapvieno visi šie cilvēki un jāmāca viņiem komunicēt vienā valodā tieši jums, kā vadītājam.

Avots: habr.com