Kion necesas por ke IT-kompanio sukcesu en 2019? Prelegantoj ĉe konferencoj kaj renkontiĝoj diras multajn laŭtajn vortojn, kiuj ne ĉiam estas kompreneblaj por normalaj homoj. La lukto por deplojo tempo, mikroservoj, forlaso de la monolito, DevOps transformo kaj multe, multe pli. Se ni forĵetas vortan belecon kaj parolas rekte kaj en la rusa, tiam ĉio estas simpla tezo: faru altkvalitan produkton, kaj faru ĝin kun komforto por la teamo.
Ĉi-lasta fariĝis kritike grava. Komerco finfine venis al la konkludo, ke komforta disvolva procezo pliigas produktivecon, kaj se ĉio estas elpurigita kaj funkcias kiel horloĝo, ĝi ankaŭ donas iom da spaco por manovro en kritikaj situacioj. Iam, pro ĉi tiu manovro, certa inteligenta persono elpensis sekurkopiojn, sed la industrio disvolviĝas, kaj ni venis al DevOps-inĝenieroj - homoj, kiuj transformas la procezon de interago inter evoluo kaj ekstera infrastrukturo en io taŭga kaj ne rilata al ŝamanismo.
Ĉi tiu tuta "modula" rakonto estas mirinda, sed... Okazis, ke iuj el la administrantoj estis abrupte nomataj DevOps, kaj DevOps-inĝenieroj mem komencis esti postulataj havi almenaŭ la kapablojn de telepatio kaj klarvido.
Antaŭ ol ni parolu pri modernaj problemoj de disponigado de infrastrukturo, ni difinu, kion ni volas diri per ĉi tiu termino. En la nuna momento, la situacio evoluis tiel, ke ni atingis la duecon de tiu ĉi koncepto: infrastrukturo povas esti kondiĉe ekstera kaj kondiĉe interna.
Per ekstera infrastrukturo ni signifas ĉion, kio certigas la funkciecon de la servo aŭ produkto, kiun la teamo disvolvas. Ĉi tiuj estas serviloj de aplikaĵo aŭ retejo, gastigado kaj aliaj servoj, kiuj certigas la funkciecon de la produkto.
La interna infrastrukturo inkluzivas servojn kaj ekipaĵojn, kiuj estas uzataj de la evoluiga teamo mem kaj aliaj dungitoj, el kiuj kutime estas multaj. Ĉi tiuj estas internaj serviloj de kodaj stoksistemoj, loke deplojita taskmanaĝero kaj ĉio, ĉio, ĉio, kio ekzistas ene de la kompania intrareto.
Kion faras sistemadministranto en firmao? Krom la laboro de administrado de ĉi tiu tre kompania intrareto, ĝi ofte portas la ŝarĝon de ekonomiaj zorgoj por certigi la operablecon de oficeja ekipaĵo. La administranto estas la sama ulo, kiu rapide trenos novan sisteman unuon aŭ rezervan tekkomputilon pretan por uzo el la malantaŭa ĉambro, donos freŝan klavaron kaj rampos kvarpiede tra la oficejoj, etendante la Ethernet-kablon. Administranto estas loka posedanto kaj reganto de ne nur internaj kaj eksteraj serviloj, sed ankaŭ komerca administranto. Jes, iuj administrantoj povas labori nur en la sistema aviadilo, sen aparataro. Ili devas esti apartigitaj en apartan subklason de "infrastrukturaj administrantoj". Kaj iuj specialiĝas pri servado ekskluzive de oficejaj ekipaĵoj; feliĉe, se la kompanio havas pli ol cent homojn, la laboro neniam finiĝas. Sed neniu el ili estas devopoj.
Kiuj estas DevOps? Devopoj estas uloj, kiuj parolas pri la interago de programaro-disvolviĝo kun ekstera infrastrukturo. Pli precize, modernaj devopoj estas implikitaj en la evoluaj kaj deplojprocezoj multe pli profunde ol iam estis implikitaj administrantoj, kiuj simple alŝutis ĝisdatigojn al ftp. Unu el la ĉefaj taskoj de DevOps-inĝeniero nun estas certigi komfortan kaj efike strukturitan procezon de interago inter evoluteamoj kaj produkta infrastrukturo. Ĝuste ĉi tiuj homoj respondecas pri deplojado de malfunkciaj kaj deplojsistemoj; estas ĉi tiuj homoj, kiuj deprenas iom da ŝarĝo de programistoj kaj koncentriĝas kiel eble plej multe pri sia ege grava tasko. Samtempe, devopoj neniam funkcios novan kablon aŭ eldonos novan tekkomputilon el la malantaŭa ĉambro (c) KO
Kio estas la kapto?
Al la demando "Kiu estas DevOps?" duono de la laboristoj en la kampo komencas respondi ion kiel "Nu, mallonge, ĉi tiu estas la administranto, kiu ..." kaj plu en la teksto. Jes, iam, kiam la profesio de DevOps-inĝeniero ĵus emerĝis el la plej talentaj administrantoj koncerne servan prizorgadon, la diferencoj inter ili ne estis evidentaj por ĉiuj. Sed nun, kiam la funkcioj de devops kaj administranto en la teamo fariĝis radikale malsamaj, estas neakcepteble konfuzi ilin unu kun la alia, aŭ eĉ egaligi ilin.
Sed kion tio signifas por komerco?
Dungado, ĉio temas pri ĝi.
Vi malfermas vakanton por "Sistema Administranto", kaj la postuloj listigitaj tie estas "interagado kun evoluo kaj klientoj", "CI/KD-liversistemo", "prizorgado de la serviloj kaj ekipaĵoj de la kompanio", "administrado de internaj sistemoj" ktp. on; vi komprenas, ke la dunganto parolas sensencaĵon. La kapto estas, ke anstataŭ "Sistema Administranto" la vaka titolo devus esti "DevOps-Inĝeniero", kaj se ĉi tiu titolo estas ŝanĝita, tiam ĉio enkadriĝas.
Tamen, kian impreson oni ricevas leginte tian vakanton? Ke la kompanio serĉas plurmaŝinan funkciigiston, kiu disfaldiĝos kaj sistemon de kontrolo kaj monitorado de versioj kaj premos la tordilon per siaj dentoj...
Sed por ne pliigi la gradon de drogmanio en la labormerkato, sufiĉas nomi vakantaĵojn per siaj propraj nomoj kaj klare kompreni, ke inĝeniero de DevOps kaj administranto de la sistemo estas du malsamaj estaĵoj. Sed la neretenebla deziro de iuj dungantoj prezenti la plej vastan eblan liston de postuloj al kandidato kondukas al tio, ke "klasikaj" sistemaj administrantoj ĉesas kompreni, kio okazas ĉirkaŭ ili. Kio, la profesio mutacias kaj ili estas malantaŭ la tempoj?
Ne ne kaj ankoraŭ unu fojon ne. Administrantoj de infrastrukturoj, kiuj administros la internajn servilojn de la firmao, aŭ okupos subtenajn postenojn L2/L3 kaj helpos aliajn dungitojn, ne foriris kaj ne foriros.
Ĉu ĉi tiuj specialistoj povas iĝi DevOps-inĝenieroj? Kompreneble ili povas. Fakte, ĉi tio estas rilata medio, kiu postulas sistemajn administrajn kapablojn, sed aldone al ĉi tio, estas aldonita laboro kun monitorado, liveraj sistemoj kaj, ĝenerale, proksima interago kun la evoluiga kaj testa teamo.
Alia DevOps Problemo
Fakte, ĉio ne estas limigita al nur dungado kaj konstanta konfuzo inter administrantoj kaj devops. En iu momento, la komerco alfrontis la problemon de liverado de ĝisdatigoj kaj interago de la evolua teamo kun la fina infrastrukturo.
Eble estis kiam onklo kun brilantaj okuloj stariĝis sur la scenejo de iu konferenco kaj diris: "Ni faras tion kaj nomas ĝin DevOps. Ĉi tiuj uloj solvos ĉiujn viajn problemojn" - kaj komencis rakonti kiom bona estas la vivo en la kompanio post efektivigo de DevOps-praktikoj.
Tamen, ne sufiĉas dungi DevOps-inĝenieron por ke ĉio funkciu kiel ĝi devus. La kompanio devas sperti kompletan transformon de DevOps, tio estas, la rolo kaj kapabloj de nia DevOps ankaŭ devas esti klare komprenitaj flanke de la teamo de disvolviĝo kaj testado de produktoj. Ni havas "mirindan" rakonton pri ĉi tiu temo, kiu plene ilustras la tutan brutalecon, kiu okazas en kelkaj lokoj.
Situacio. DevOps estas bezonata por disfaldi sistemon de revalidigo de versio sen vere esplori kiel ĝi funkcios. Ni supozu, ke ene de la Uzantoj-sistemo estas apartaj kampoj por antaŭnomo, familia nomo kaj pasvorto. Aperos nova versio de la produkto, sed por programistoj, "retroligo" estas nur magia vergo, kiu riparos ĉion, kaj ili eĉ ne scias kiel ĝi funkcias. Do, ekzemple, en la sekva flikaĵo la programistoj kombinis la antaŭnomajn kampojn, lanĉis ĝin en produktadon, sed la versio ial malrapidas. Kio okazas? Administrado venas al devops kaj diras "Tiru la ŝaltilon!", tio estas, petas al li reveni al la antaŭa versio. Kion faras devops? Ĝi revenas al la antaŭa versio, sed ĉar la programistoj ne volis eltrovi kiel ĉi tiu malfunkciigo estis farita, neniu diris al la devops-teamo, ke la datumbazo ankaŭ devas esti refarita. Kiel rezulto, ĉio kraŝas por ni, kaj anstataŭ malrapida retejo, uzantoj vidas eraron "500", ĉar la malnova versio ne funkcias kun la kampoj de la nova datumbazo. Devops ne scias pri tio. La programistoj silentas. La administrado komencas perdi siajn nervojn kaj monon kaj memoras la sekurkopiojn, ofertante retiriĝi de ili tiel ke "almenaŭ io funkcios." Kiel rezulto, uzantoj perdas ĉiujn siajn datumojn dum tempodaŭro.
La nuksoj, kompreneble, iras al devops, kiuj "ne faris taŭgan rollback-sistemon", kaj neniu zorgas, ke la alko en ĉi tiu rakonto estas programistoj.
La konkludo estas simpla: sen normala aliro al DevOps kiel tia, ĝi malmulte utilas.
La ĉefa afero por memori: DevOps-inĝeniero ne estas magiisto, kaj sen kvalitaj komunikadoj kaj dudirekta interago kun evoluo, li ne traktos siajn taskojn. Devs ne povas esti lasitaj solaj kun siaj "problemoj" aŭ donitaj la komandon "ne enmiksiĝi kun la programistoj, ilia tasko estas kodigi", kaj tiam esperi, ke en kritika momento ĉio funkcios kiel ĝi devus. Ne tiel funkcias.
Esence, DevOps estas kompetenteco ĉe la limo inter administrado kaj teknologio. Plie, estas malproksima de evidente, ke devus esti pli da teknologio ol administrado en ĉi tiu koktelo. Se vi vere volas konstrui pli rapidajn kaj pli efikajn evoluajn procezojn, vi devas fidi vian devops-teamon. Li konas la ĝustajn ilojn, li efektivigis similajn projektojn, li scias kiel fari ĝin. Helpu lin, aŭskultu liajn konsilojn, ne provu izoli lin en ian aŭtonoman unuon. Se administrantoj povas labori memstare, tiam devopoj estas senutilaj ĉi-kaze; ili ne povos helpi vin pliboniĝi, se vi mem ne volas akcepti ĉi tiun helpon.
Kaj lasta afero: ĉesu ofendi administrantojn de infrastrukturoj. Ili havas sian propran, ege gravan fronton de laboro. Jes, administranto povas fariĝi DevOps-inĝeniero, sed ĉi tio devus okazi laŭ peto de la persono mem, kaj ne sub premo. Kaj estas nenio malbona pri tio, ke sistemadministranto volas resti sistemadministranto - jen lia aparta profesio kaj lia rajto. Se vi volas sperti profesian transformon, tiam vi neniam devas forgesi, ke vi devos konstrui ne nur teknologiajn kapablojn, sed ankaŭ administrajn kapablojn. Plej verŝajne, dependos de vi kiel gvidanto kunigi ĉiujn ĉi homojn kaj instrui ilin komuniki en la sama lingvo.
fonto: www.habr.com