La plej malĝoja afero en la nuna situacio estas, ke IT iom post iom fariĝas industrio, kie tute ne ekzistas vorto "halto" en la nombro da respondecoj por persono.
Legante vakantaĵojn, foje oni eĉ vidas ne 2-3 homojn, sed tutan kompanion en unu persono, ĉiuj rapidas, teknika ŝuldo kreskas, la malnova heredaĵo aspektas kiel perfekteco sur la fono de novaj produktoj, ĉar ĝi almenaŭ havas dokon kaj komentojn en la kodo, novaj produktoj estas skribitaj kun la rapido de la lumo, sed kiel rezulto, ili ne povas esti uzataj dum alia jaro post kiam ili estas skribitaj, kaj ofte ĉi-jare ne alportas profiton, krome, la kosto de la nubo estas pli alta ol la vendoj de la servo. La mono de investantoj iras al la prizorgado de servo, kiu ankoraŭ ne funkcias, sed kiu jam estis liberigita al la reto kiel laboristo.
Ekzemple: konata kompanio, kies remasterizado de malnova ludo ricevis la plej malaltajn taksojn en la historio de la industrio. Mi estis unu el tiuj, kiuj aĉetis ĉi tiun produkton, sed eĉ nun ĉi tiu produkto terure funkcias, kaj en teorio ankoraŭ ne devus esti liberigita en ĉi tiu formo. Repagoj, taksado-falo, grandega nombro da uzantmalpermesoj sur la forumoj por plendoj pri la laboro de servoj. La nombro da diakiloj ne ĝojas, sed teruras, sed tamen - la produkto ne estas uzebla. Se ĉi tiu aliro kondukas al tiaj rezultoj por kompanio, kiu disvolviĝas ekde 91, tiam por kompanioj, kiuj ĵus komencas, la situacio estas eĉ pli malbona.
Sed ni rigardis la rezultojn de ĉi tiu aliro fare de la uzanto de la servo, kaj nun ni rigardu la problemojn, kiujn havas dungitoj.
Mi ofte aŭdas la deklaron, ke ne devus ekzisti DevOps-teamoj, ke ĉi tio estas metodaro ktp., sed la problemo estas, ke ial kompanioj ĉesis serĉi noks, dba, infruktors kaj konstruinĝenieroj - nun ĉio estas DevOps-inĝeniero. en ununura persono. Kompreneble, en unuopaj kompanioj ankoraŭ ekzistas tiaj vakantaĵoj, sed ili estas malpli kaj malpli. Multaj nomis ĉi tiun evoluon, mi persone vidas degradadon en ĉi tio, estas neeble konservi bonan nivelon de scio en ĉiuj areoj, kaj samtempe sukcesas labori ne pli ol 8 horojn. Kompreneble, ĉi tiuj estas fantazioj. Fakte, multaj IT-laboristoj estas devigitaj labori kaj 12 kaj 14 horojn, el kiuj estas pagitaj 8. Kaj ofte sen libertagoj, ĉar "Mi ricevis taskon, ne estas dokoj aŭ kurboj, kaj la servo kostas monon", kaj por 1 en la nubo, vi povas, principe, ne ricevi salajron en du monatoj, precipe se vi laboras laŭ IP-bazo. Fakte, ni perdas la vorton en komerco, kune kun la disiĝo de devoj, mi ĉiam pli alfrontas la fakton, ke administrantoj eniras en disvolvajn procezojn sen kompreni ion ajn, ili konfuzas komercajn datumojn kaj aplikaĵon, kiel rezulto, kaoso. komenciĝas.
Kiam ĥaoso komenciĝas, komerco volas trovi la kulpulon, kaj ĉi tie vi bezonas universalan kulpulon, estas malfacile kulpigi pli ol 10 homojn, do administrantoj kunigas siajn postenojn, ĉar ju pli da devoj havas 1 specialisto, des pli facile estas fari. pruvi lian neglektemon. Kaj en la kondiĉoj de Agile, trovi la "kulpajn" kaj batadon estas la bazo de ĉi tiu metodaro por fari komercon en administrado. Agile estis delonge ekster IT, kaj ĝia ĉefa koncepto fariĝis la postulo de ĉiutagaj rezultoj. La problemo estas, ke tre specialigita specialisto ne ĉiam havos ĉiutagan rezulton, kio signifas, ke estos pli malfacile raporti, kaj ĉi tio estas alia kialo, kial entreprenoj volas "specialistojn pri ĉio". Sed la ĉefa kialo, kompreneble, estas la etato - li estas la ĉefa kialo de ĉiuj ŝanĝoj, pro la monhelpo, homoj konsentis labori por si mem kaj tiu ulo. Sed finfine, kiel en aliaj lokoj, ĝi nun fariĝis simple devigo, por pli malgranda pago por pli granda nombro da servoj provizitaj.
Nun vi ofte eĉ povas vidi artikolojn, kiujn programistoj jam devus povi disfaldi, devus trakti la infrastrukturon apud DevOps-inĝeniero, sed al kio ĉi tio kondukas? Ĝuste - al falo en la kvalito de servoj, al falo en la kvalito de programistoj. Laŭvorte antaŭ 2 tagoj, mi klarigis al la programisto, ke vi povas skribi kaj legi de malsamaj gastigantoj, kaj ili pruvis al mi kun ŝaŭmo ĉe la buŝo, ke ili neniam vidis ion tian, jen ĝi estas en la agordoj orm gastiganto, haveno, db, uzanto, pasvorto kaj jen ĝi .... Sed la programisto scias kiel lanĉi deplojojn, skribi yamls .... Sed li jam forgesas pri unutestoj kaj komentoj en la kodo.
Kiel rezulto, ni vidas la jenon - konstanta prilaborado, serĉado de solvoj al problemoj ekster laborhoroj, konstanta trejnado dum semajnfinoj, kaj ne por pliigi enspezon, sed por teni nin flosante. Programistoj estas devigitaj helpi DevOps-inĝenieron kun CI / KD, kaj se la programisto ne havas tempon, li komencas silenti, kaj administrantoj komencas kompoŝti cerbojn, kaj se ĉi tio ne helpas pliigi la deziron labori kromlaboron, tiam apliki. punoj kaj monpunoj, la persono serĉas novan laboron, postlasante teknikan ŝuldon de la grandeco de Everest, kiel rezulto, la ŝuldo komencas kreski ankaŭ inter programistoj. ili estas devigitaj skribi kodon kun malpli refactoring por havi tempon helpi aŭ malnovan aŭ novan DevOps-inĝenieron, kaj administrantoj estas sufiĉe kontentaj pri ĉio, ĉar estas kulpa homo kaj oni povas lin tuj vidi, kio signifas, ke la ĉefa regulo en Agile-administrado estas observita, la kulpa estas trovita, la rezultoj de lia skurĝado videblas.
Iam ĉe ITGM mi faris prezenton "kiam ni lernas diri ne" - ĝiaj rezultoj estis tre malkaŝaj. Grandega nombro da homoj kredas, ke ĉi tiu vorto estas tabuo, kaj ĝis ni ĉesos pensi tiel, la problemoj nur kreskos.
Parte inspiris min skribi ĉi tiun artikolon., sed mi eble skribos ĝin en malpli agrablaj terminoj poste.
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Ĉu vi renkontis en la laboro, kiam la dunganto provis anstataŭigi plurajn homojn kun vi?
-
65,6%Jes, mi renkontas ĝin regule
-
5,4%Jes, renkontite 1 fojon15
-
15,4%Ne rimarkis43
-
13,6%Mi estas labormaniulo, mi mem laboras kromlaborojn38
Voĉdonis 279 uzantoj. 34 uzantoj sindetenis.
fonto: www.habr.com