DevOps fariĝis tre populara temo dum la lastaj jaroj. Multaj homoj revas aliĝi al ĝi, sed, kiel praktiko montras, ofte nur pro la nivelo de salajroj.
Iuj homoj listigas DevOps en sia vivresumo, kvankam ili ne ĉiam scias aŭ komprenas la esencon de la termino. Iuj homoj pensas, ke post studado de Ansible, GitLab, Jenkins, Terraform kaj similaj (la listo povas esti daŭrigita laŭ via gusto), vi tuj fariĝos "devopsisto". Ĉi tio kompreneble ne estas vera.
Dum la lastaj jaroj, mi ĉefe okupiĝas pri la efektivigo de DevOps en diversaj kompanioj. Antaŭ tio, li laboris dum pli ol 20 jaroj en postenoj, kiuj iras de sistemadministranto ĝis IT-direktoro. Nuntempe DevOps Ĉefa Inĝeniero ĉe Playgendary.
Kiu estas DevOps
La ideo verki artikolon ekestis post alia demando: "kiu estas DevOps?" Ankoraŭ ne ekzistas establita termino por kio aŭ kiu ĝi estas. Kelkaj el la respondoj jam estas en ĉi tio . Unue, mi reliefigos la ĉefajn punktojn el ĝi, kaj poste mi dividos miajn observojn kaj pensojn.
DevOps ne estas specialisto, kiu povas esti dungita, ne aro da utilecoj, kaj ne fako de programistoj kun inĝenieroj.
DevOps estas filozofio kaj metodaro.
Alivorte, ĝi estas aro da praktikoj, kiuj helpas programistojn aktive interagi kun sistemaj administrantoj. Tio estas, konekti kaj integri laborprocezojn unu en la alian.
Kun la apero de DevOps, la strukturo kaj roloj de specialistoj restis la samaj (estas programistoj, estas inĝenieroj), sed la reguloj de interagado ŝanĝiĝis. La limoj inter departementoj malklariĝis.
La celoj de DevOps povas esti priskribitaj en tri punktoj:
- La programaro devas esti ĝisdatigita regule.
- Programaro devas esti farita rapide.
- La programaro devas esti deplojita oportune kaj en mallonga tempo.
Ne ekzistas ununura ilo por DevOps. Agordi, liverante kaj studi plurajn produktojn ne signifas, ke DevOps aperis en la kompanio. Estas multaj iloj kaj ĉiuj estas uzataj en malsamaj stadioj, sed servas unu komunan celon.
Kaj ĉi tio estas nur parto de la DevOps-iloj
Mi intervjuis homojn por la pozicio de DevOps-inĝeniero dum pli ol 2 jaroj nun, kaj mi ekkomprenis kiom grava estas klare kompreni la esencon de la termino. Mi amasigis specifajn spertojn, observojn kaj pensojn, kiujn mi volas dividi.
El intervjua sperto, mi vidas la jenan bildon: specialistoj, kiuj konsideras DevOps kiel labortitolon, kutime havas miskomprenojn kun kolegoj.
Estis okulfrapa ekzemplo. Junulo venis al intervjuo kun multaj inteligentaj vortoj en sia vivresumo. Ĉe siaj lastaj tri laboroj, li havis 5-6 monatojn da sperto. Mi forlasis du noventreprenojn ĉar ili "ne ekflugis." Sed pri la tria kompanio, li diris, ke neniu komprenas lin tie: la programistoj skribas kodon en Vindozo, kaj la direktoro devigas ĉi tiun kodon esti "envolvita" en regula Docker kaj integrita en la CI/CD-dukto. La ulo diris multajn negativajn aferojn pri sia nuna laborloko kaj siaj kolegoj - mi volis nur respondi: "Do vi ne vendos elefanton."
Tiam mi faris al li demandon, kiu estas alta en mia listo por ĉiu kandidato.
— Kion DevOps signifas por vi persone?
- Ĝenerale aŭ kiel mi perceptas ĝin?
Mi interesiĝis pri lia persona opinio. Li konis la teorion kaj originon de la termino, sed li forte malkonsentis kun ili. Li kredis, ke DevOps estis labortitolo. Jen kie kuŝas la radiko de liaj problemoj. Same kiel aliaj specialistoj kun la sama opinio.
Dungantoj, aŭdinte multon pri la "magio de DevOps", volas trovi homon, kiu venos kaj kreos ĉi tiun "magion". Kaj kandidatoj de la kategorio "DevOps estas laboro" ne komprenas, ke per ĉi tiu aliro ili ne povos renkonti atendojn. Kaj, ĝenerale, ili skribis DevOps en sia vivresumo ĉar ĝi estas tendenco kaj ili multe pagas por ĝi.
DevOps-metodaro kaj filozofio
La metodaro povas esti teoria kaj praktika. En nia kazo, ĝi estas la dua. Kiel mi menciis supre, DevOps estas aro de praktikoj kaj strategioj uzataj por atingi deklaritajn celojn. Kaj en ĉiu kazo, depende de la komercaj procezoj de la kompanio, ĝi povas signife diferenci. Kio ne igas ĝin pli bona aŭ pli malbona.
La metodologio DevOps estas nur rimedo por atingi celojn.
Nun pri kio estas la filozofio DevOps. Kaj ĉi tio verŝajne estas la plej malfacila demando.
Estas sufiĉe malfacile formuli mallongan kaj koncizan respondon, ĉar ĝi ankoraŭ ne estis formaligita. Kaj ĉar adeptoj de la filozofio DevOps pli okupiĝas pri praktiko, simple ne estas tempo por filozofi. Tamen ĉi tio estas tre grava procezo. Krome, ĝi estas rekte rilata al inĝenieraj agadoj. Estas eĉ speciala areo de scio - .
Ne ekzistis tia fako en mia universitato; mi devis studi ĉion memstare uzante la materialojn kiujn mi povis trovi en la 90-aj jaroj. La temo estas nedeviga por inĝenieristiko, tial la manko de formaligo de la respondo. Sed tiuj homoj, kiuj estas serioze mergitaj en DevOps, komencas senti certan "spiriton" aŭ "senkonscian amplekson" de ĉiuj procezoj de la kompanio.
Uzante mian propran sperton, mi provis formaligi kelkajn el la "postulatoj" de ĉi tiu filozofio. La rezulto estas la sekva:
- DevOps ne estas io sendependa, kiu povas esti apartigita en aparta areo de scio aŭ agado.
- Ĉiuj dungitoj de la kompanio devas esti gvidataj de la DevOps-metodaro kiam ili planas siajn agadojn.
- DevOps influas ĉiujn procezojn ene de kompanio.
- DevOps ekzistas por redukti tempokostojn por iuj procezoj ene de kompanio por certigi la disvolviĝon de ĝiaj servoj kaj maksimuma klienta komforto.
- DevOps, en moderna lingvo, estas la iniciatema pozicio de ĉiu dungito de la firmao, celita redukti tempokostojn kaj plibonigi la kvaliton de la IT-produktoj ĉirkaŭ ni.
Mi pensas, ke miaj "postulatoj" estas aparta temo por diskuto. Sed nun estas io por konstrui.
Kion DevOps Faras
La ŝlosilvorto ĉi tie estas komunikado. Estas multaj komunikadoj, kies iniciatinto devus esti ĝuste tiu sama DevOps-inĝeniero. Kial estas tio? Ĉar ĉi tio estas filozofio kaj metodaro, kaj nur tiam inĝenieristiko.
Mi ne povas paroli kun 100% konfido pri la okcidenta labormerkato. Sed mi scias multe pri la DevOps-merkato en Rusio. Krom centoj da intervjuoj, dum la pasinta jaro kaj duono mi partoprenis en centoj da teknikaj antaŭvendoj por la servo "Efektivigo de DevOps" por grandaj rusaj kompanioj kaj bankoj.
En Rusio, DevOps estas ankoraŭ tre juna, sed jam tendenca temo. Laŭ mia scio, nur en Moskvo la manko de tiaj specialistoj en 2019 estis pli ol 1000 homoj. Kaj la vorto Kubernetes por dungantoj estas preskaŭ kiel ruĝa ĉifono por taŭro. Adeptoj de ĉi tiu ilo pretas uzi ĝin eĉ kie ĝi ne estas necesa kaj ekonomie profita. La dunganto ne ĉiam komprenas, en kiuj kazoj, kio estas pli taŭga por uzi, kaj kun taŭga disvastigo, konservi Kubernetes-grupon kostas 2-3 fojojn pli ol disfaldi aplikaĵon uzante konvencian grapolskemon. Uzu ĝin kie vi vere bezonas ĝin.
Efektivigi DevOps estas multekosta laŭ mono. Kaj ĝi pravigas nur tie, kie ĝi alportas ekonomiajn avantaĝojn en aliaj areoj, kaj ne memstare.
DevOps-inĝenieroj estas, fakte, pioniroj - ili estas tiuj, kiuj devus esti la unuaj por efektivigi ĉi tiun metodaron en la kompanio kaj konstrui procezojn. Por ke ĉi tio sukcesu, la specialisto devas konstante interagi kun dungitoj kaj kolegoj je ĉiuj niveloj. Kiel mi kutime diras, ĉiuj dungitoj de la kompanio devus esti implikitaj en la efektiviga procezo de DevOps: de la purigistino ĝis la CEO. Kaj ĉi tio estas antaŭkondiĉo. Se la plej juna membro de la teamo ne scias kaj komprenas kio estas DevOps kaj kial certaj organizaj agoj estas faritaj, tiam sukcesa efektivigo ne funkcios.
Ankaŭ, DevOps-inĝeniero bezonas uzi administran rimedon de tempo al tempo. Ekzemple, venki "median reziston" - kiam la teamo ne estas preta akcepti DevOps-iloj kaj metodaro.
La programisto devas nur skribi kodon kaj testojn. Por fari tion, li ne bezonas super-potencan tekkomputilon, sur kiu li deplojos kaj loke subtenos la tutan projektan infrastrukturon. Ekzemple, antaŭfina programisto konservas ĉiujn elementojn de la aplikaĵo sur sia tekkomputilo, inkluzive de la datumbazo, S3-emulilo (minio), ktp. Tio estas, li pasigas multe da tempo prizorgante ĉi tiun lokan infrastrukturon kaj sole luktas kun ĉiuj problemoj de tia solvo. Anstataŭ evoluigi kodon por la fronto. Tiaj homoj povas esti tre rezistemaj al ajna ŝanĝo.
Sed ekzistas teamoj, kiuj male, feliĉas enkonduki novajn ilojn kaj metodojn, kaj aktive partoprenas en ĉi tiu procezo. Kvankam eĉ en ĉi tiu kazo, komunikado inter la DevOps-inĝeniero kaj la teamo ne estis nuligita.
Kiam DevOps ne estas bezonata
Estas situacioj, kiam DevOps ne bezonas. Ĉi tio estas fakto - ĝi devas esti komprenita kaj akceptita.
Antaŭ ĉio, ĉi tio validas por iuj kompanioj (precipe malgrandaj entreprenoj), kiam ilia profito ne rekte dependas de la ĉeesto aŭ foresto de IT-produktoj, kiuj provizas informajn servojn al klientoj. Kaj ĉi tie ni ne parolas pri la retejo de la kompanio, ĉu ĝi estas statika "komerca karto" aŭ kun dinamikaj novaĵblokoj, ktp.
DevOps estas postulata kiam la kontento de via kliento kaj lia deziro reveni al vi denove dependas de la havebleco de ĉi tiuj informaj servoj por interago kun la kliento, ilia kvalito kaj celado.
Frapa ekzemplo estas unu konata banko. La kompanio ne havas tradiciajn klientajn oficejojn, dokumentfluo estas farita per poŝto aŭ kurieroj, kaj multaj dungitoj laboras hejme. La kompanio ĉesis esti nur banko kaj, laŭ mi, fariĝis IT-kompanio kun evoluintaj teknologioj DevOps.
Multaj aliaj ekzemploj kaj prelegoj troveblas en la registradoj de temaj renkontiĝoj kaj konferencoj. Iujn el ili mi vizitis persone - tio estas tre utila sperto por tiuj, kiuj volas disvolvi ĉi tiun direkton. Jen ligiloj al YouTube-kanaloj kun bonaj prelegoj kaj materialoj pri DevOps:
Nun rigardu vian komercon kaj pensu pri ĉi tio: Kiom via kompanio kaj ĝiaj profitoj dependas de IT-produktoj por ebligi klientan interago?
Se via kompanio vendas fiŝojn en malgranda vendejo kaj la sola IT-produkto estas du 1C: Entreprenaj agordoj (Kontado kaj UNF), tiam apenaŭ havas sencon paroli pri DevOps.
Se vi laboras ĉe granda komerca kaj fabrikada entrepreno (ekzemple, vi produktas ĉasfusilojn), tiam vi devus pensi pri tio. Vi povas preni la iniciaton kaj transdoni al via administrado la perspektivojn por efektivigi DevOps. Nu, kaj samtempe gvidu ĉi tiun procezon. Proaktiva pozicio estas unu el la gravaj dogmoj de la DevOps-filozofio.
La grandeco kaj volumo de jara financa spezo ne estas la ĉefa kriterio por determini ĉu via kompanio bezonas DevOps.
Ni imagu grandan industrian entreprenon, kiu ne interagas rekte kun klientoj. Ekzemple, kelkaj aŭtoproduktantoj kaj aŭto-produktaj kompanioj. Mi ne certas nun, sed laŭ mia pasinta sperto, dum multaj jaroj ĉiu klienta interago estis farita per retpoŝto kaj telefono.
Iliaj klientoj estas limigita listo de aŭtokomercistoj. Kaj al ĉiu estas asignita specialisto de la fabrikanto. Ĉiu interna dokumentfluo okazas per SAP ERP. Internaj dungitoj estas esence klientoj de la informsistemo. Sed ĉi tiu IS estas kontrolita per klasikaj rimedoj de administrado de aretsistemoj. Kiu ekskludas la eblecon uzi DevOps-praktikojn.
Tial la konkludo: por tiaj entreprenoj, la efektivigo de DevOps ne estas io kritike grava, se ni memoras la celojn de la metodaro ekde la komenco de la artikolo. Sed mi ne ekskludas, ke ili uzas iujn ilojn DevOps hodiaŭ.
Aliflanke, ekzistas multaj malgrandaj kompanioj, kiuj disvolvas programaron uzante DevOps-metodaron, filozofion, praktikojn kaj ilojn. Kaj ili kredas, ke la kosto de efektivigo de DevOps estas la kosto, kiu permesas al ili konkuri efike en la programara merkato. Ekzemploj de tiaj kompanioj povas esti viditaj .
La ĉefa kriterio por kompreni ĉu DevOps estas bezonata: kian valoron viaj IT-produktoj havas por la kompanio kaj klientoj.
Se la ĉefa produkto de la kompanio, kiu generas profiton, estas programaro, vi bezonas DevOps. Kaj ne tiom gravas se vi gajnas realan monon uzante aliajn produktojn. Ĉi tio ankaŭ inkluzivas retajn butikojn aŭ moveblajn aplikojn kun ludoj.
Ajnaj ludoj ekzistas danke al financado: rekta aŭ nerekta de la ludantoj. Ĉe Playgendary, ni disvolvas senpagajn moveblajn ludojn kun pli ol 200 homoj rekte implikitaj en ilia kreado. Kiel ni uzas DevOps?
Jes, ĝuste la sama kiel priskribite supre. Mi konstante komunikas kun programistoj kaj testistoj, kaj faras internan trejnadon por dungitoj pri DevOps-metodaro kaj iloj.
Ni nun aktive uzas Jenkins kiel CI/KD-duktan ilon por ekzekuti ĉiujn asembleajn duktojn kun Unity kaj postan deplojon al la App Store kaj Play Market. Pli el la klasika ilaro:
- Asana - por projekt-administrado. Integriĝo kun Jenkins estis agordita.
- Google Meet - por videokunvenoj.
- Slack - por komunikadoj kaj diversaj atentigoj, inkluzive de sciigoj de Jenkins.
- Atlassian Confluence - por dokumentado kaj grupa laboro.
Niaj tujaj planoj inkluzivas enkonduki statikan kodan analizon per SonarQube kaj fari aŭtomatigitan UI-testadon per Selenium en la Kontinua Integriĝo.
Anstataŭ konkludo
Mi ŝatus fini kun la sekva penso: por iĝi tre kvalifikita DevOps-inĝeniero, estas esenca lerni kiel komuniki vive kun homoj.
DevOps-inĝeniero estas teamludanto. Kaj nenio alia. La iniciato en komunikado kun kolegoj devus veni de li, kaj ne sub la influo de iuj cirkonstancoj. Specialisto de DevOps devas vidi kaj proponi la plej bonan solvon por la teamo.
Kaj jes, la efektivigo de ajna solvo postulos multan diskuton, kaj ĝis la fino ĝi povas tute ŝanĝiĝi. Disvolvante sendepende, proponante kaj efektivigante siajn ideojn, tia persono plivaloriĝas kaj por la teamo kaj por la dunganto. Kiu, finfine, estas reflektita en la kvanto de lia monata rekompenco aŭ en la formo de pliaj gratifikoj.
fonto: www.habr.com