DevOps se v posledních letech stalo velmi populárním tématem. Mnoho lidí sní o vstupu do ní, ale jak ukazuje praxe, často jen kvůli výši platů.
Někteří lidé uvádějí DevOps ve svém životopisu, i když ne vždy znají nebo nerozumí podstatě tohoto termínu. Někdo si myslí, že po prostudování Ansible, GitLab, Jenkins, Terraform a podobně (ve výčtu lze pokračovat podle chuti) se okamžitě stanete „devopsistou“. To samozřejmě není pravda.
Posledních pár let se věnuji především implementaci DevOps v různých společnostech. Předtím pracoval více než 20 let na pozicích od systémového administrátora po IT ředitele. V současné době hlavní inženýr DevOps ve společnosti Playgendary.
Kdo je DevOps
Nápad napsat článek vznikl po další otázce: "kdo je DevOps?" Stále neexistuje zavedený termín pro to, co nebo kdo to je. Některé z odpovědí jsou již v tomto . Nejprve z něj vyzdvihnu hlavní body a poté se podělím o své postřehy a myšlenky.
DevOps není specialista, kterého lze najmout, ani sada nástrojů a ani oddělení vývojářů s inženýry.
DevOps je filozofie a metodologie.
Jinými slovy, je to soubor postupů, které pomáhají vývojářům aktivně komunikovat se správci systému. Tedy propojovat a integrovat pracovní procesy do sebe.
S příchodem DevOps zůstala struktura a role specialistů stejné (jsou vývojáři, jsou inženýři), ale změnila se pravidla interakce. Hranice mezi odděleními se stírají.
Cíle DevOps lze popsat ve třech bodech:
- Software musí být pravidelně aktualizován.
- Software se musí dělat rychle.
- Software by měl být nasazen pohodlně a v krátkém čase.
Pro DevOps neexistuje jediný nástroj. Konfigurace, dodání a studium několika produktů neznamená, že se ve společnosti objevil DevOps. Existuje mnoho nástrojů a všechny se používají v různých fázích, ale slouží jednomu společnému účelu.
A to je jen část nástrojů DevOps
Již více než 2 roky dělám pohovory s lidmi na pozici DevOps inženýr a uvědomil jsem si, jak důležité je jasně pochopit podstatu tohoto termínu. Nashromáždily se mi konkrétní zkušenosti, postřehy a myšlenky, o které se chci podělit.
Ze zkušenosti s rozhovorem vidím následující obrázek: specialisté, kteří považují DevOps za pracovní pozici, mají obvykle nedorozumění s kolegy.
Byl tam nápadný příklad. Mladý muž přišel na pohovor se spoustou chytrých slov ve svém životopise. Ve svých posledních třech zaměstnáních měl praxi 5-6 měsíců. Opustil jsem dva startupy, protože „nevzlétly“. Ale o třetí společnosti řekl, že mu tam nikdo nerozumí: vývojáři píší kód na Windows a ředitel nutí tento kód „zabalit“ do běžného Dockeru a zabudovat do potrubí CI/CD. Ten chlap řekl spoustu negativních věcí o svém současném působišti a svých kolezích - chtěl jsem jen odpovědět: "Takže neprodáte slona."
Pak jsem mu položil otázku, která je u každého kandidáta na mém seznamu vysoko.
— Co pro vás osobně znamená DevOps?
- Obecně nebo jak to vnímám?
Zajímal mě jeho osobní názor. Znal teorii a původ tohoto termínu, ale silně s nimi nesouhlasil. Věřil, že DevOps je pracovní název. Tady leží kořen jeho problémů. Stejně jako další specialisté se stejným názorem.
Zaměstnavatelé, kteří hodně slyšeli o „kouzlu DevOps“, chtějí najít člověka, který přijde a vytvoří toto „kouzlo“. A uchazeči z kategorie „DevOps is a job“ nechápou, že s tímto přístupem nebudou schopni naplnit očekávání. A obecně si do životopisu napsali DevOps, protože je to trend a hodně se za to platí.
Metodologie a filozofie DevOps
Metodika může být teoretická i praktická. V našem případě je to to druhé. Jak jsem uvedl výše, DevOps je soubor postupů a strategií používaných k dosažení stanovených cílů. A v každém případě se může v závislosti na obchodních procesech společnosti výrazně lišit. Což to nedělá lepší ani horší.
Metodika DevOps je pouze prostředkem k dosažení cílů.
Nyní o tom, co je filozofie DevOps. A to je asi nejtěžší otázka.
Je poměrně obtížné formulovat krátkou a výstižnou odpověď, protože ještě nebyla formalizována. A jelikož vyznavači filozofie DevOps se více věnují praxi, na filozofování prostě není čas. Jedná se však o velmi důležitý proces. Navíc přímo souvisí s inženýrskou činností. Existuje dokonce specializovaná oblast znalostí - .
Na mé univerzitě takový předmět nebyl, vše jsem si musel nastudovat sám pomocí materiálů, které jsem našel v 90. letech. Téma je volitelné pro inženýrské vzdělání, proto chybí formalizace odpovědi. Ale ti lidé, kteří jsou vážně ponořeni do DevOps, začínají pociťovat určitého „ducha“ nebo „nevědomou komplexnost“ všech firemních procesů.
S využitím vlastní zkušenosti jsem se pokusil formalizovat některé „postuláty“ této filozofie. Výsledek je následující:
- DevOps není něco nezávislého, co lze rozdělit do samostatné oblasti znalostí nebo činnosti.
- Všichni zaměstnanci společnosti by se měli při plánování svých aktivit řídit metodikou DevOps.
- DevOps ovlivňuje všechny procesy v rámci společnosti.
- DevOps existuje proto, aby snižoval časové náklady na jakékoli procesy v rámci společnosti, aby byl zajištěn rozvoj jejích služeb a maximální zákaznický komfort.
- DevOps, moderním jazykem, je proaktivní pozice každého zaměstnance společnosti, jejímž cílem je snižování časových nákladů a zlepšování kvality IT produktů kolem nás.
Myslím, že mé „postuláty“ jsou samostatným tématem k diskusi. Nyní je ale na čem stavět.
Co DevOps dělá
Klíčovým slovem je zde komunikace. Existuje mnoho komunikací, jejichž iniciátorem by měl být přesně stejný inženýr DevOps. proč tomu tak je? Protože to je filozofie a metodologie a teprve potom inženýrské znalosti.
Nemohu mluvit se 100% jistotou o západním trhu práce. O trhu DevOps v Rusku toho ale vím docela dost. Kromě stovek rozhovorů jsem se za poslední rok a půl zúčastnil stovek technických předprodejů služby „Implementace DevOps“ pro velké ruské společnosti a banky.
V Rusku je DevOps stále velmi mladé, ale již trendy téma. Pokud vím, jen v Moskvě byl nedostatek takových specialistů v roce 2019 více než 1000 2 lidí. A slovo Kubernetes pro zaměstnavatele je skoro jako červený hadr na býka. Příznivci tohoto nástroje jsou připraveni jej použít i tam, kde to není nutné a ekonomicky výhodné. Zaměstnavatel ne vždy chápe, v jakých případech je vhodnější použít, a při správném nasazení stojí údržba clusteru Kubernetes 3–XNUMXkrát více než nasazení aplikace pomocí konvenčního clusterového schématu. Použijte jej tam, kde ho opravdu potřebujete.
Implementace DevOps je finančně nákladná. A má své opodstatnění pouze tam, kde přináší ekonomické výhody v jiných oblastech, a nikoli sám o sobě.
Inženýři DevOps jsou ve skutečnosti průkopníci – jsou to právě oni, kdo by měl jako první implementovat tuto metodiku do firmy a budovat procesy. Aby to bylo úspěšné, musí specialista neustále komunikovat se zaměstnanci a kolegy na všech úrovních. Jak obvykle říkám, do procesu implementace DevOps by měli být zapojeni všichni zaměstnanci společnosti: od uklízečky po generálního ředitele. A to je předpoklad. Pokud nejmladší člen týmu neví a nerozumí tomu, co je DevOps a proč se provádějí určité organizační akce, pak úspěšná implementace nebude fungovat.
Technik DevOps také potřebuje čas od času použít administrativní zdroj. Například k překonání „rezistence prostředí“ – když tým není připraven přijmout nástroje a metodiku DevOps.
Vývojář by měl pouze psát kód a testy. Nepotřebuje k tomu supervýkonný notebook, na kterém nasadí a lokálně bude podporovat celou projektovou infrastrukturu. Například vývojář front-endu uchovává všechny prvky aplikace na svém notebooku, včetně databáze, emulátoru S3 (minio) atd. To znamená, že tráví spoustu času udržováním této místní infrastruktury a sám se potýká se všemi problémy takového řešení. Místo vývoje kódu pro frontu. Takoví lidé mohou být velmi odolní vůči jakékoli změně.
Jsou ale týmy, které naopak rády zavádějí nové nástroje a metody a aktivně se tohoto procesu účastní. I když ani v tomto případě nebyla komunikace mezi inženýrem DevOps a týmem zrušena.
Když DevOps není potřeba
Jsou situace, kdy DevOps není potřeba. To je fakt – je potřeba to pochopit a přijmout.
V první řadě se to týká jakýchkoli společností (zejména malých podniků), kdy jejich zisk není přímo závislý na přítomnosti či absenci IT produktů, které poskytují informační služby klientům. A tady nemluvíme o webových stránkách společnosti, ať už je to statická „vizitka“ nebo s dynamickými bloky zpráv atd.
DevOps je vyžadován, když spokojenost vašeho klienta a jeho přání vrátit se k vám opět závisí na dostupnosti těchto informačních služeb pro interakci s klientem, jejich kvalitě a cílení.
Pozoruhodným příkladem je jedna známá banka. Společnost nemá klasické klientské kanceláře, tok dokumentů probíhá prostřednictvím pošty nebo kurýrů a mnoho zaměstnanců pracuje z domova. Firma přestala být jen bankou a podle mě se proměnila v IT firmu s rozvinutými technologiemi DevOps.
Řadu dalších příkladů a přednášek lze nalézt v záznamech tematických setkání a konferencí. Některé z nich jsem osobně navštívil – to je velmi užitečná zkušenost pro ty, kteří se chtějí tímto směrem rozvíjet. Zde jsou odkazy na kanály YouTube s dobrými přednáškami a materiály o DevOps:
Nyní se podívejte na své podnikání a zamyslete se nad tímto: Jak moc závisí vaše společnost a její zisky na produktech IT, aby umožnily interakci se zákazníky?
Pokud vaše společnost prodává ryby v malém obchodě a jediným IT produktem jsou dvě konfigurace 1C: Enterprise (účetnictví a UNF), pak nemá smysl mluvit o DevOps.
Pokud pracujete ve velkém obchodním a výrobním podniku (například vyrábíte lovecké pušky), měli byste o tom přemýšlet. Můžete převzít iniciativu a sdělit svému vedení vyhlídky na implementaci DevOps. No, a zároveň vést tento proces. Proaktivní pozice je jednou z důležitých zásad filozofie DevOps.
Velikost a objem ročního finančního obratu není hlavním kritériem pro určení, zda vaše společnost potřebuje DevOps.
Představme si velký průmyslový podnik, který neinteraguje přímo se zákazníky. Například některé automobilky a společnosti vyrábějící automobily. Teď si nejsem jistý, ale podle mých minulých zkušeností se po mnoho let veškerá komunikace se zákazníky odehrávala prostřednictvím e-mailu a telefonu.
Jejich klienty jsou omezený seznam prodejců automobilů. A každému je přidělen specialista od výrobce. Veškerý tok interních dokumentů probíhá prostřednictvím SAP ERP. Interní zaměstnanci jsou v podstatě klienty informačního systému. Tento IS je ale řízen klasickými prostředky řízení clusterových systémů. Což vylučuje možnost použití postupů DevOps.
Proto závěr: pro takové podniky není implementace DevOps něčím kriticky důležitým, pokud si připomeneme cíle metodiky z úvodu článku. Ale nevylučuji, že dnes používají nějaké nástroje DevOps.
Na druhé straně existuje mnoho malých společností, které vyvíjejí software pomocí metodologie, filozofie, postupů a nástrojů DevOps. A věří, že náklady na implementaci DevOps jsou náklady, které jim umožňují efektivně konkurovat na softwarovém trhu. Příklady takových společností lze vidět .
Hlavní kritérium pro pochopení, zda je DevOps potřeba: jakou hodnotu mají vaše IT produkty pro společnost a zákazníky.
Pokud je hlavním produktem společnosti, který generuje zisk, software, potřebujete DevOps. A není tak důležité, jestli vyděláváte skutečné peníze pomocí jiných produktů. Patří sem i internetové obchody nebo mobilní aplikace s hrami.
Jakékoli hry existují díky financování: přímo nebo nepřímo od hráčů. V Playgendary vyvíjíme bezplatné mobilní hry s více než 200 lidmi přímo zapojenými do jejich tvorby. Jak používáme DevOps?
Ano, přesně tak, jak je popsáno výše. Neustále komunikuji s vývojáři a testery a vedu interní školení zaměstnanců o metodice a nástrojích DevOps.
Nyní aktivně používáme Jenkins jako CI/CD pipelines nástroj pro provádění všech montážních linek s Unity a následné nasazení do App Store a Play Market. Více z klasické sady nástrojů:
- Ásana - pro řízení projektů. Integrace s Jenkinsem byla nakonfigurována.
- Google Meet – pro videokonference.
- Slack – pro komunikaci a různá upozornění, včetně upozornění od Jenkinse.
- Atlassian Confluence - pro dokumentaci a skupinovou práci.
Naše bezprostřední plány zahrnují zavedení analýzy statického kódu pomocí SonarQube a provádění automatizovaného testování uživatelského rozhraní pomocí Selenium ve fázi kontinuální integrace.
Místo závěru
Rád bych zakončil následující myšlenkou: Chcete-li se stát vysoce kvalifikovaným inženýrem DevOps, je životně důležité naučit se komunikovat naživo s lidmi.
Inženýr DevOps je týmový hráč. A nic jiného. Iniciativa v komunikaci s kolegy by měla vycházet od něj, a ne pod vlivem nějakých okolností. Specialista DevOps musí vidět a navrhnout nejlepší řešení pro tým.
A ano, implementace jakéhokoli řešení bude vyžadovat mnoho diskusí a nakonec se může úplně změnit. Takový člověk, který se samostatně vyvíjí, navrhuje a realizuje své nápady, má pro tým i pro zaměstnavatele stále větší hodnotu. Což se v konečném důsledku promítne do výše jeho měsíční odměny nebo v podobě dalších bonusů.
Zdroj: www.habr.com