Téma DevOps sa v posledných rokoch stala veľmi populárnou. Mnohí túžia zapojiť sa do tejto oblasti, ale prax ukazuje, že často len kvôli výške platov.
Niektorí uvádzajú vo svojich životopisoch DevOps, aj keď nie vždy vedia a rozumejú podstate tohto termínu. Niekto si myslí, že ak sa naučia Ansible, GitLab, Jenkins, Terraform a podobné nástroje (zoznam možno pokračovať podľa vlastného výberu), hneď sa stanú "devopsom". To samozrejme nie je pravda.
Posledných niekoľko rokov sa väčšinou zaoberám implementáciou DevOps v rôznych spoločnostiach. Predtým som viac ako 20 rokov pracoval na pozíciách od systémového administrátora po IT riaditeľa. Teraz som DevOps Lead Engineer v Playgendary.
Kto je DevOps
Nápad na napísanie článku vznikol po ďalšej otázke: "Kto je DevOps?". Doteraz neexistuje ustálený termín, čo alebo kto to je. Časť odpovedí už je v tomto . Najprv vyzdvihnem hlavné tézy z neho a potom sa podelím o svoje pozorovania a myšlienky.
DevOps nie je odborník, ktorého možno najať, nie je to súbor nástrojov a ani oddelenie vývojárov s inžiniermi.
DevOps je filozofia a metodológia.
Inými slovami, je to súbor praktík, ktorý pomáha aktívne prepojiť vývojárov so systémovými administrátormi. Teda prepojiť a integrovať pracovné procesy navzájom.
S príchodom DevOps zostala štruktúra a úlohy odborníkov rovnaké (sú vývojári, sú inžinieri), ale zmenili sa pravidlá interakcie. Hranice medzi oddeleniami sa rozmazali.
Ciele DevOps môžeme popísať troma bodmi:
- Softvér by mal byť pravidelne aktualizovaný.
- Softvér by mal byť vyvíjaný rýchlo.
- Softvér by mal byť nasadzovaný pohodlne a v krátkych časových rámcoch.
DevOps nemá jediný nástroj. Nastaviť, nainštalovať a študovať niekoľko produktov neznamená, že v spoločnosti sa objavil DevOps. Nástrojov je veľmi veľa a všetky sa používajú v rôznych fázach, ale slúžia jednej spoločnej veci.
A to je len časť nástrojov DevOps
Už viac ako 2 roky pohováram ľudí na pozíciu DevOps inžiniera a uvedomil som si, ako významné je presne chápať podstatu tohto termínu. Naakumulovalo sa špecifické skúsenosti, pozorovania a myšlienky, ktoré chcem zdieľať.
Z vlastných skúseností z pohovorov vidím takúto situáciu: u odborníkov, ktorí pokladajú DevOps za pracovnú pozíciu, zvyčajne existujú nedorozumenia s kolegami.
Bol jasný príklad. Na pohovor prišiel mladý muž s množstvom inteligentných slov v životopise. Na posledných troch pracovných miestach mal prax 5-6 mesiacov. Z dvoch startupov odišiel, pretože „neuspel“. Čo sa týka tretej firmy, povedal, že ho tam nikto nechápe: vývojári píšu kód pre Windows, a riaditeľ ho núti tento kód „zabalit“ do bežného Dockeru a integrovať do CI/CD pipelinu. Chlapec povedal veľa negatívneho o svojom súčasnom zamestnaní a kolegoch — tak sa chcelo povedať: „Tak ty slona nepredáš“.
Potom som mu položil otázku, ktorá je v mojom zozname jednou z prvých pre každého kandidáta.
— Čo pre teba osobne znamená DevOps?
— Vôbec alebo ako to vnímam ja?
Zaujímalo ma jeho osobné stanovisko. Poznal teóriu a pôvod termínu, ale bol s nimi kategoricky nesúhlasný. Myslel si, že DevOps je pozícia. Tu sa ukrýva korene jeho problémov. Rovnako ako u iných špecialistov so rovnakým názorom.
Zamestnávatelia, ktorí počuli o „mágii DevOps“, chcú nájsť človeka, ktorý príde a túto „magickú“ atmosféru vytvorí. A uchádzači z kategórie „DevOps je pozícia“ nechápu, že s takýmto prístupom nebudú môcť splniť očakávania. A vo všeobecnosti napísali vo svojom životopise DevOps, pretože je to trend a platia za to veľa.
Metodológia a filozofia DevOps
Metodológia môže byť teoretická a praktická. V našom prípade — druhé. Ako som spomenul vyššie, DevOps je súbor praktík a stratégií, ktoré sa používajú na dosiahnutie stanovených cieľov. A v každom prípade, v závislosti od obchodných procesov spoločnosti, sa môže podstatne líšiť. Čo ho nerobí lepším alebo horším.
Metodológia DevOps je iba prostriedok na dosiahnutie stanovených cieľov.
Teraz k tomu, čo je filozofia DevOps. A to je asi najťažšia otázka.
Formulovať krátku a presnú odpoveď je dosť ťažké, pretože ešte nebola formalizovaná. A pretože adepti filozofie DevOps sa viac zaoberajú praxou — na filozofovanie jednoducho nie je čas. Napriek tomu je to veľmi dôležitý proces. A priamo sa týka inžinierskej činnosti. Existuje dokonca špecializovaná oblasť poznania — .
Na mojej vysokej škole taký predmet neexistoval, musel som sa všetko naučiť sám z materiálov, ktoré som dokázal nájsť v 90. rokoch. Téma nie je povinná pre inžinierske vzdelanie, odtiaľ aj absencia formalizácie odpovede. No ľudia, ktorí sa vážne zaoberali DevOps, začínajú pociťovať akýsi "duch" alebo "nevedomú všetkost" všetkých procesov v spoločnosti.
Na svojich skúsenostiach som sa snažil formalizovať niektoré "postuláty" tejto filozofie. Výsledok je nasledovný:
- DevOps nie je niečo samostatné, čo by sa dalo vyčleniť ako samostatný smer poznania alebo činnosti.
- DevOps metodológiou by sa mali riadiť všetci zamestnanci spoločnosti pri plánovaní svojej činnosti.
- DevOps sa týka všetkých procesov v rámci spoločnosti.
- DevOps existuje na to, aby znižoval časové náklady na akékoľvek procesy v spoločnosti s cieľom zabezpečiť rozvoj jej služieb a maximálny komfort pre klienta.
- DevOps, moderným jazykom, je proaktívna pozícia každého zamestnanca spoločnosti zameraná na znižovanie časových nákladov a zlepšovanie kvality IT produktov okolo nás.
Myslím, že moje "postuláty" sú samostatnou témou na diskusiu. Ale teraz je od čoho odrážať.
Čo robí DevOps
Kľúčové slovo tu je - komunikácia. Veľa komunikácií, iniciátorom ktorých by mal byť práve ten DevOps inžinier. Prečo? Pretože toto je filozofia a metodológia, a až potom technické znalosti.
O západnom trhu práce nemôžem hovoriť s 100% istotou. Ale o trhu DevOps v Rusku viem pomerne veľa. Okrem stoviek pohovorov, za posledné jedno a pol roka som sa zúčastnil na stovke technických presalev pre službu "Implementácia DevOps" pre veľké ruské spoločnosti a banky.
V Slovensku je DevOps ešte stále mladá, ale už trendová téma. Pokiaľ viem, len v Bratislave bol v roku 2019 nedostatok takých odborníkov viac ako 1000. A slovo Kubernetes je pre zamestnávateľov takmer ako červená handra pre býka. Zástancovia tohto nástroja sú ochotní ho použiť aj tam, kde to nie je potrebné a ekonomicky výhodné. Zamestnávateľ nie vždy rozumie, v ktorých prípadoch je vhodnejšie použiť čo, pričom pri správnom nasadení obsah klastra Kubernetes stojí 2-3 krát viac, než nasadenie aplikácie podľa bežnej klastrové schémy. Používajte ho tam, kde je skutočne potrebný.
Nasadenie DevOps z pohľadu financií — je drahé. A je odôvodnené len tam, kde prináša ekonomický prospech v iných oblastiach, a nie samo o sebe.
DevOps inžinieri sú v podstate priekopníci — práve oni by mali ako prví zavádzať v spoločnosti túto metodológiu a budovať procesy. Aby to bolo úspešné, špecialista musí neustále interagovať so zamestnancami a kolegami na všetkých úrovniach. Ako zvyčajne hovorím, do procesu implementácie DevOps by mali byť zapojení všetci zamestnanci spoločnosti: od upratovačky po CEO. A toto je povinná podmienka. Ak najmladší člen tímu nebude vedieť a chápať, čo DevOps je a prečo sa vykonávajú tie alebo oné organizačné činnosti, úspešná implementácia sa nepodarí.
DevOps inžinier potrebuje z času na čas využívať administratívny zdroj. Napríklad, na prekonanie "odolnosti prostredia" — keď tím nie je pripravený prijať nástroje a metodológiu DevOps.
Programátor by mal písať len kód a testy. Na to nepotrebuje supersilný notebook, na ktorom bude rozvíjať a udržiavať lokálne celú infraštruktúru projektu. Napríklad, frontend developer má na svojom notebooku všetky prvky aplikácie, vrátane databázy, emulátora S3 (minio) a iné. To znamená, že trávi veľa času udržiavaním tejto lokálnej infraštruktúry a sám bojuje so všetkými problémami takéhoto riešenia. Namiesto toho, aby vyvíjal kód pre front. Takíto ľudia môžu byť veľmi odporne voči akýmkoľvek zmenám.
Sú však tímové, ktoré naopak vítajú zavádzanie nových nástrojov a metód a aktívne sa zúčastňujú na tomto procese. Aj keď v takýchto prípadoch nikto nezrušil komunikáciu medzi DevOps inžinierom a tímom.
Keď DevOps nie je potrebný
Sú situácie, keď DevOps nie je potrebný. Je to fakt, ktorý treba pochopiť a prijať.
To sa predovšetkým týka akýchkoľvek spoločností (najmä malého biznisu), keď ich zisk priamo nezávisí od prítomnosti alebo neprítomnosti IT produktov, ktoré poskytujú informačné služby klientom. A tu nejde o webovú stránku spoločnosti, či už je to statická 'vizitka' alebo s dynamickými blokmi správ atď.
DevOps je potrebný, keď kvalita a cielenosť týchto informačných služieb interakcie s klientom ovplyvňuje spokojnosť vašich klientov a ich túžbu vracať sa práve k vám.
Jasným príkladom je jeden známy banka. Spoločnosť nemá tradičné klientské pobočky, dokumentový obeh sa realizuje prostredníctvom pošty alebo kuriérov, a mnoho zamestnancov pracuje z domu. Spoločnosť prestala byť len bankou a podľa môjho názoru sa stala IT spoločnosťou s vyvinutými DevOps technológiami.
Mnoho ďalších príkladov a prednášok je možné nájsť v záznamoch tematických meetupov a konferencií. Niektoré z nich som navštívil osobne - je to veľmi užitočný zážitok pre tých, ktorí sa chcú rozvíjať v tomto smere. Tu sú odkazy na YouTube kanály s dobrými prednáškami a materiálmi o DevOps:
Teraz sa pozrite na svoj biznis a zamyslite sa nad tým: ako veľmi závisí vaša spoločnosť a jej zisk od IT produktov, ktoré zabezpečujú interakciu s klientom?
Ak vaša spoločnosť predáva ryby v malej predajni a jedinými IT produktmi sú dve konfigurácie 1C: Podnik (Účtovníctvo a UNF), potom asi nemá zmysel hovoriť o DevOps.
Ak však pracujete v veľkej obchodnej a výrobných podniku (napríklad vyrábate poľovné pušky), potom stojí za úvahu. Môžete prejaviť iniciatívu a sprostredkovať svojmu vedeniu perspektívy zavádzania DevOps. Nuž, a zároveň viesť tento proces. Proaktívny prístup je jedným z dôležitých postulátov filozofie DevOps.
Veľkosť a objem ročného finančného obratu nie je hlavným kritériom na určenie, či vaša spoločnosť potrebuje DevOps.
Predstavme si veľké priemyselné podniky, ktoré neinteragujú priamo so zákazníkmi. Napríklad niektoré automobilky a výrobné spoločnosti. Teraz si nie som istý, ale podľa svojej predchádzajúcej skúsenosti sa celé roky všetka interakcia so zákazníkmi vykonávala prostredníctvom e-mailu a telefónu.
Ich zákazníci sú obmedzený zoznam automobilových predajcov. A k každému je priradený odborník od výrobcu. Celý vnútorný dokumentačný obeh prebieha cez ERP SAP. Interní zamestnanci sú v podstate zákazníkmi informačného systému. Ale správa tohto IS je realizovaná tradičnými prostriedkami riadenia klastrových systémov. To vylučuje možnosť používania praktík DevOps.
Odtiaľ vyplýva záver: pre takéto podniky implementácia DevOps nie je niečo kriticky dôležité, ak si spomenieme na ciele metodológie z začiatku článku. Ale nevylučujem, že nejaké nástroje DevOps sa dnes používajú.
Na druhej strane existuje mnoho malých spoločností, ktoré vyvíjajú softvér s využitím metodológie, filozofie, praktík a nástrojov DevOps. A považujú náklady na implementáciu DevOps za výdavky, ktoré im umožňujú efektívne konkurovať na trhu softvéru. Príklady takýchto spoločností možno vidieť. .
Hlavným kritériom na pochopenie, či potrebujete DevOps: akú hodnotu majú vaše IT produkty pre spoločnosť a zákazníkov.
Ak je hlavným produktom spoločnosti, ktorý prináša zisk, softvér — potrebujete DevOps. A nie je tak dôležité, či zarábate skutočné peniaze prostredníctvom iných tovarov. Sem tiež patrí internetové obchody alebo mobilné aplikácie s hrami.
Akékoľvek hry existujú vďaka financovaniu: priamemu alebo nepriameho zo strany hráčov. V Playgendary vyvíjame bezplatné mobilné hry, na ktorých priamej tvorbe sa podieľa viac ako 200 ľudí. Ako používame DevOps?
Áno, presne tak, ako je opísané vyššie. Neustále komunikujem s vývojármi a testermi, organizujem interné školenia zamestnancov o metodológii a nástrojoch DevOps.
V súčasnosti aktívne používame Jenkins ako nástroj CI/CD pipelines na vykonávanie všetkých zostavovacích konvejrov s Unity a následné nasadenie do App Store a Play Market. Ešte z klasickej sady nástrojov:
- Asana – na správu projektov. Je nastavená integrácia s Jenkins.
- Google Meet – na uskutočňovanie videohovorov.
- Slack – na komunikáciu a rôzne oznámenia, vrátane notifikácií z Jenkins.
- Atlassian Confluence – na dokumentáciu a skupinovú prácu.
V najbližších plánoch je zavedenie statickej analýzy kódu pomocou SonarQube a vykonanie automatizovaného UI testovania pomocou Selenium v rámci procesu Continuous Integration.
Na záver
Chcem skončiť nasledujúcou myšlienkou: aby sa človek stal vysoko kvalifikovaným DevOps inžinierom, je nevyhnutné naučiť sa živo komunikovať s ľuďmi.
DevOps inžinier je tímový hráč. A inak to nejde. Iniciatíva v komunikácii s kolegami by mala vychádzať od neho samého, a nie pod vplyvom nejakých okolností. DevOps špecialista by mal vidieť a navrhovať najlepšie riešenie pre tím.
A áno, zavedenie akéhokoľvek riešenia si vyžaduje množstvo diskusií a na konci sa môže úplne zmeniť. Samostatne sa rozvíjajúc, navrhujúc a realizujúc svoje nápady – taký človek predstavuje čoraz väčšiu hodnotu pre tím aj pre zamestnávateľa. Čo sa nakoniec odráža aj na výške jeho mesačnej odmeny alebo v podobe dodatočných zárobkov.
Zdroj: habr.com
