Téma DevOps se v posledních letech stalo velmi populárním. Mnozí sní o tom, že se do něj zapojí, ale jak ukazuje praxe, často pouze kvůli výši platů.
Někteří uvádějí v svém životopise DevOps, i když ne vždy chápou podstatu termínu. Někdo si myslí, že když se naučí Ansible, GitLab, Jenkins, Terraform a podobné (seznam lze pokračovat dle vlastního uvážení), hned se stane „devopsem“. To samozřejmě není pravda.
Posledních několik let se převážně zabývám implementací DevOps v různých společnostech. Předtím jsem více než 20 let pracoval na pozicích od systémového administrátora po IT ředitele. Nyní jsem DevOps Lead Engineer ve společnosti Playgendary.
Kdo je DevOps
Nápad napsat článek vznikl po dalším dotazu: „kdo je DevOps?“. Dosud neexistuje ustálený termín, co nebo kdo to vlastně je. Část odpovědí už je v tomto . Nejprve vyzdvihnu hlavní teze z něj a poté se podělím o své pozorování a myšlenky.
DevOps není specialista, kterého lze najmout, není to soubor nástrojů a není to oddělení vývojářů s inženýry.
DevOps je filozofie a metodologie.
Jinými slovy, je to soubor praktik, který pomáhá aktivně spolupracovat vývojářům se systémovými administrátory. To znamená propojovat a integrovat pracovní procesy do sebe.
S příchodem DevOps struktura a role specialistů zůstaly stejné (jsou zde vývojáři, jsou zde inženýři), ale změnila se pravidla interakce. Hranice mezi odděleními se rozostřily.
Cíle DevOps lze popsat třemi body:
- Software by měl být pravidelně aktualizován.
- Software by měl být vyvíjen rychle.
- Software by měl být nasazován pohodlně a v krátkých lhůtách.
DevOps nemá jediný nástroj. Nastavit, nainstalovat a naučit se několik produktů neznamená, že ve společnosti existuje DevOps. Nástrojů je mnoho a všechny se používají v různých fázích, ale slouží jednomu společnému cíli.
A to je pouze část nástrojů DevOps
Už více než 2 roky pohovoruji s lidmi na pozici DevOps inženýra a uvědomil jsem si, jak důležité je jasně chápat podstatu termínu. Nahromadilo se specifické zkušenosti, pozorování a myšlenky, kterými se chci podělit.
Z zkušenosti pohovorů vidím takový obraz: specialisté, kteří považují DevOps za pozici, obvykle mají nedorozumění s kolegy..
Byl jasným příkladem. Na pohovor přišel mladý muž s hromadou chytrých slov v životopise. V posledních třech zaměstnáních měl praxi 5-6 měsíců. Z obou startupů odešel, protože "neuspěly". A pokud jde o třetí společnost, řekl, že tam ho nikdo nechápe: vývojáři píší kód pro Windows, a ředitel nutí tento kód "zabalit" do obyčejného Dockeru a integrovat do CI/CD pipeline. Chlapec mluvil negativně o svém současném místě práce a jeho kolezích — jako by chtěl odpovědět: „Tak ty slona neprodáš.“
Potom jsem mu položil otázku, která je v mém seznamu jedna z prvních pro každého kandidáta.
— Co pro tebe osobně znamená DevOps?
— Obecně, nebo jak to vnímám já?
Zajímalo mě jeho osobní názory. Znal teorii a původ pojmu, ale byl s nimi kardinálně nesouhlasný. Myslel si, že DevOps je pozice. A to je kořen jeho problémů. Stejně jako u dalších specialistů s podobným názorem.
Zaměstnavatelé, kteří si vyslechli o „kouzlech DevOps“, chtějí najít člověka, který přijde a toto „kouzlo“ vytvoří. A uchazeči z řady „DevOps je pozice“ nechápou, že při takovém přístupu nebudou schopni splnit očekávání. A celkově napsali ve svém životopise DevOps, protože je to trend a za to se dobře platí.
Metodologie a filozofie DevOps
Metodologie může být teoretická a praktická. V našem případě — druhé. Jak jsem již zmínil, DevOps je soubor praktik a strategií, které se používají k dosažení stanovených cílů. A v každém případě, v závislosti na obchodních procesech společnosti, se může významně lišit. Co ho nezpůsobuje být lepší nebo horší.
Metodologie DevOps je jen prostředkem k dosažení stanovených cílů.
Nyní k tomu, co je filozofie DevOps. A to je pravděpodobně ta nejtěžší otázka.
Formulovat krátkou a výstižnou odpověď je dost obtížné, protože ještě není formalizována. A protože zasvěcenci filozofie DevOps se více zabývají praxí — na filozofování prostě není čas. Nicméně, je to velmi důležitý proces. A to přímo související s inženýrskou činností. Existuje dokonce specializovaná oblast poznání — .
Na mé univerzitě takový předmět nebyl, musel jsem se všechno naučit sám z materiálů, které jsem našel v devadesátých letech. Téma není povinné pro inženýrské vzdělání, a proto chybí formální odpověď. Ale ti, kteří se vážně ponořili do DevOps, začínají cítit jakýsi "duch" nebo "neuvědomovanou všemocnost" všech procesů ve společnosti.
Na základě svých zkušeností jsem se snažil formalizovat některé "postuláty" této filozofie. Výsledky jsou následující:
- DevOps není něčím samostatným, co by se dalo vyčlenit jako samostatný směr znalostí nebo činnosti.
- DevOps metodologií by se měli řídit všichni zaměstnanci společnosti, když plánují svou činnost.
- DevOps se dotýká všech procesů uvnitř společnosti.
- DevOps existuje, aby snižoval časové náklady na jakékoliv procesy uvnitř společnosti a zajistil rozvoj jejích služeb a maximální komfort klienta.
- DevOps, moderně řečeno, je proaktivní postoj každého zaměstnance společnosti, zaměřený na snížení časových ztrát a zlepšení kvality IT produktů kolem nás.
Myslím, že moje "postuláty" jsou samostatným tématem k diskusi. Ale nyní je tu něco, od čeho se odrazit.
Co dělá DevOps
Klíčové slovo zde je komunikace. Je zde spousta komunikací, jejichž iniciátorem by měl být právě ten DevOps inženýr. Proč? Protože to je filozofie a metodologie, a teprve poté inženýrské znalosti.
O západním trhu práce nemohu mluvit s 100% jistotou. Ale o trhu DevOps v Rusku vím docela dost. Kromě stovek pohovorů jsem za posledního jeden a půl roku účastnil ve stovce technických presales na službu "Implementace DevOps" pro velké ruské firmy a banky.
V Česku je DevOps stále ještě velmi mladé, ale už trendové téma. Jak vím, pouze v Praze byl za rok 2019 nedostatek těchto specialistů více než 1000 lidí. A slovo Kubernetes je pro zaměstnavatele téměř jako červený hadr pro býka. Zastánci tohoto nástroje jsou ochotni ho používat i tam, kde to není potřeba a ekonomicky nevýhodné. Zaměstnavatel často nerozumí, kdy je vhodnější použít co, a při správném nasazení obsah klastru Kubernetes stojí 2-3krát více než nasazení aplikace podle běžného klastrového schématu. Používejte ho tam, kde je skutečně potřebný.
Zavedení DevOps z hlediska peněz — je drahé. A je oprávněno pouze tam, kde přináší ekonomický prospěch v jiných oblastech, a ne samo o sobě.
DevOps inženýři jsou vlastně pionýři — právě oni by měli jako první zavádět tuto metodologii do firmy a budovat procesy. Aby to bylo úspěšné, odborník by měl neustále spolupracovat se zaměstnanci a kolegy na všech úrovních. Jak obvykle říkám, do procesu zavádění DevOps by měli být zapojeni všichni zaměstnanci firmy: od uklízečky po CEO. A to je nezbytná podmínka. Pokud nejmladší člen týmu nebude vědět a rozumět, co je to DevOps a proč se provádějí ty či ony organizační kroky, úspěšné zavedení nebude možné.
Také DevOps inženýr potřebuje občas využít administrativní zdroje. Například k překonání "odporu prostředí" — když tým není připraven přijmout nástroje a metodologii DevOps.
Vývojář by měl psát pouze kód a testy. K tomu nepotřebuje supervýkonný notebook, na kterém by rozbíhal a udržoval celou infrastrukturu projektu lokálně. Například front-end vývojář má na svém notebooku všechny prvky aplikace, včetně databáze, emulátoru S3 (minio) a dalšího. To znamená, že tráví spoustu času udržováním této lokální infrastruktury a sám bojuje se všemi problémy takového řešení. Místo toho, aby vyvíjel kód pro front. Takoví lidé mohou silně odporovat jakýmkoliv změnám.
Existují však týmy, které naopak vítají zavádění nových nástrojů a metod a aktivně se účastní tohoto procesu. I v takovém případě však nikdo nezrušil komunikaci mezi DevOps inženýrem a týmem.
Kdy DevOps není potřeba
Někdy nastávají situace, kdy DevOps není potřeba. To je fakt, který je třeba chápat a akceptovat.
To se především týká jakýchkoli firem (zejména malého podnikání), kdy jejich zisk přímo nezávisí na přítomnosti nebo nepřítomnosti IT produktů, které poskytují zákazníkům informační služby. A zde nejde o web firmy, ať už je to statická "vizitka" nebo s dynamickými novinkami atd.
DevOps je potřebný, když závisí na přítomnosti těchto informačních služeb pro interakci se zákazníkem, jejich kvalitě a cílení spokojenost vašich zákazníků a jejich touha se k vám znovu vracet.
Jasným příkladem je jedna známá banka. Společnost nemá běžné klientské kanceláře, dokumenty se spravují prostřednictvím pošty nebo kurýrů, a spousta zaměstnanců pracuje z domova. Společnost přestala být pouze bankou a podle mého názoru se proměnila v IT firmu s vyvinutými DevOps technologiemi.
Mnoho dalších příkladů a přednášek lze nalézt v záznamech tematických meet-upů a konferencí. Některé z nich jsem osobně navštívil — je to velmi cenná zkušenost pro ty, kteří se chtějí v tomto směru rozvíjet. Zde jsou odkazy na YouTube kanály s dobrými přednáškami a materiály o DevOps:
Nyní se podívejte na své podnikání a zamyslete se nad jednou věcí: jak moc závisí vaše firma a její zisk na IT produktech, které zajišťují interakci se zákazníkem?
Pokud vaše firma prodává ryby v malém obchodě a jediným IT produktem jsou dvě konfigurace 1C: Podnik (Účetnictví a UNF), pak zřejmě nemá smysl mluvit o DevOps.
Pokud však pracujete ve velkém obchodním a výrobním podniku (například vyrábíte lovecké zbraně), pak byste se měli zamyslet. Můžete projevovat iniciativu a přenést na své vedení perspektivy zavedení DevOps. A zároveň vést tento proces. Proaktivní přístup je jedním z důležitých postulátů filozofie DevOps.
Velikost a objem ročního finančního obratu není hlavním kritériem pro určení, zda vaše společnosti DevOps potřebuje.
Představme si velký průmyslový podnik, který přímo nekomunikuje se zákazníky. Například některé automobilky a výrobci automobilů. Teď si nejsem jistý, ale z mých minulých zkušeností, mnohá léta veškerá interakce se zákazníky probíhala e-mailem a telefonicky.
Jejich klienti jsou omezený seznam dealerů automobilů. A ke každému je přiřazen odborník od výrobce. Celá vnitřní administrativa probíhá prostřednictvím ERP SAP. Interní zaměstnanci jsou v podstatě klienty informačního systému. Ale správa tohoto IS se provádí klasickými prostředky pro řízení clusterových systémů. To vylučuje možnost použití praktik DevOps.
Z toho vyplývá: pro takové podniky není zavedení DevOps něčím kriticky důležitým, pokud si vzpomeneme na cíle metodologie na začátku článku. Ale nevylučuji, že některé nástroje DevOps mohou být využívány i dnes.
Na druhou stranu existuje mnoho malých společností, které vyvíjejí software s využitím metodologie, filosofie, praktik a nástrojů DevOps. A tvrdí, že náklady na zavedení DevOps jsou náklady, které jim umožňují efektivně soutěžit na trhu s softwarem. Příklady takových společností lze vidět. .
Hlavním kritériem pro pochopení, zda je DevOps potřebné: jaký význam mají vaše IT produkty pro společnost a klienty.
Pokud je hlavním produktem společnosti, který přináší zisk, software — potřebujete DevOps. A není tak důležité, zda vyděláváte skutečné peníze pomocí jiných produktů. Sem lze také zahrnout internetové obchody nebo mobilní aplikace s hrami.
Jakékoliv hry existují díky financování: přímému nebo nepřímému ze strany hráčů. V Playgendary vyvíjíme bezplacné mobilní hry, na jejichž bezprostředním vzniku se podílí více než 200 lidí. Jak používáme DevOps?
Ano, přesně tak, jak bylo popsáno výše. Neustále komunikuji s vývojáři a testery, pořádám interní školení zaměstnanců o metodologii a nástrojích DevOps.
V současné době aktivně používáme Jenkins jako nástroj pro CI/CD pipeline pro provádění všech build konvejnerů s Unity a následné nasazení do App Store a Play Market. Dále z klasického souboru nástrojů:
- Asana — pro řízení projektů. Je nastavena integrace s Jenkins.
- Google Meet — pro videohovory.
- Slack — pro komunikaci a různá upozornění, včetně notifikací z Jenkins.
- Atlassian Confluence — pro dokumentaci a týmovou spolupráci.
V nejbližší budoucnosti plánujeme implementovat statickou analýzu kódu pomocí SonarQube a provést automatizované UI testování pomocí Selenium v rámci Continuous Integration.
Na závěr
Chtěl bych zakončit následující myšlenkou: abyste se stali vysoce kvalifikovaným DevOps inženýrem, je nezbytně nutné naučit se žít komunikaci s lidmi.
DevOps inženýr je týmový hráč. A jinak to nejde. Iniciativa v komunikaci s kolegy by měla vycházet od něj samého, a ne pod vlivem nějakých okolností. DevOps specialista by měl vidět a navrhnout nejlepší řešení pro tým.
A ano, zavedení jakéhokoli řešení vyžaduje spoustu diskuzí, a na konci se může vůbec změnit. Osoba, která se sama rozvíjí, navrhuje a realizuje své nápady — takový člověk představuje stále větší hodnotu jak pro tým, tak pro zaměstnavatele. Co se nakonec odráží i na výši jeho měsíční odměny nebo formou dalších prémií.
Zdroj: habr.com
