V poslednej dobe takéto reklamy zaplavili internet. Napriek príjemnému platu sa človek neubráni hanbe, že vo vnútri je napísaná divoká heréza. Najprv sa predpokladá, že „DevOps“ a „inžinier“ môžu byť nejakým spôsobom zlepené do jedného slova, a potom je tu náhodný zoznam požiadaviek, z ktorých niektoré sú jasne skopírované z voľného miesta správcu systému.
V tomto príspevku by som chcel trochu porozprávať o tom, ako sme sa dostali do tohto bodu života, čo to vlastne DevOps je a čo s tým teraz robiť.
Takéto voľné pracovné miesta sa dajú všemožne odsúdiť, no faktom zostáva: je ich veľa a takto momentálne funguje trh. Zorganizovali sme konferenciu devops a otvorene vyhlasujeme: „ - nie pre inžinierov DevOps." Mnohým sa to bude zdať zvláštne a divoké: prečo ľudia, ktorí robia úplne komerčnú akciu, idú proti trhu. Teraz si všetko vysvetlíme.
O kultúre a procesoch
Začnime tým, že DevOps nie je inžinierska disciplína. Všetko to začalo tým, že historicky zavedené rozdelenie rolí nefunguje pre kvalitu produktov. Keď programátori iba programujú, ale nechcú nič počuť o testovaní, softvér je plný chýb. Keď sa správcovia nestarajú o to, ako alebo prečo je softvér napísaný, podpora sa zmení na peklo.
Napríklad popis rozdielu medzi správcom systému a prístupom SRE k správe služieb . V rámci neho sa uskutočnili zaujímavé štúdie — je jasné, že najlepším vývojárom sa nejako podarí nasadiť nové zmeny do produkcie rýchlejšie ako raz za hodinu. Testujú rukami nie viac ako 10% (toto je vidieť z ). ako to robia? „Excel or die“ hovorí jeden z nadpisov správy. Podrobnú diskusiu o týchto štatistikách v kontexte testovania nájdete v hlavnej poznámke Barucha Sadogurského na našej ďalšej konferencii Heisenbug.
„Keď medzi súdruhmi neexistuje zhoda,
Veci pre nich nedopadnú dobre,
A nič z toho nebude, iba trápenie.
Bola raz labuť, rak a šťuka...“
Ktorá časť webových programátorov podľa vás skutočne rozumie podmienkam, za ktorých sa ich aplikácie používajú vo výrobe? Koľko z nich pôjde za adminom a pokúsi sa zistiť, čo sa stane, ak databáza spadne? A ktorý z nich pôjde za testermi a požiada ich, aby ich naučili správne písať testy? A sú tam aj ochrankári, produktoví manažéri a kopa ďalších ľudí.
Celková myšlienka DevOps je vytvoriť spoluprácu medzi rolami a oddeleniami. V prvom rade sa to nedosahuje nejakým šikovne nakonfigurovaným softvérom, ale nácvikom komunikácie. DevOps je o kultúre, postupoch, metodológii a procesoch. Neexistuje žiadna inžinierska špecializácia, ktorá by mohla odpovedať na tieto otázky.
Začarovaný kruh
Odkiaľ sa potom vzala disciplína „devops engineering“? Máme verziu! Nápady DevOps boli dobré – také dobré, že sa stali obeťami vlastného úspechu. Okolo celej tejto témy sa začali krútiť niektorí tieňoví náborári a obchodníci s ľuďmi, ktorí majú svoju atmosféru.
Predstavte si: včera ste robili shawarmu v Khimki a dnes ste už veľký muž, senior recruiter. Existuje celý proces hľadania a výberu kandidátov, všetko nie je jednoduché, musíte tomu rozumieť. Povedzme, že vedúci oddelenia povie: nájdite špecialistu na X. K X priradíme slovo „inžinier“ a máme hotovo. Potrebujete Linux? Toto je určite inžinier Linuxu, ak chcete DevOps, potom inžinier DevOps. Voľné miesto pozostáva nielen z titulu, ale je potrebné zadať aj nejaký text. Najjednoduchšie je zadať množinu kľúčových slov z Google, záleží na vašej fantázii. DevOps pozostáva z dvoch slov – „Dev“ a „Ops“, čo znamená, že musíme spojiť kľúčové slová súvisiace s vývojármi a správcami, všetko do jednej kôpky. Takto sa objavujú voľné miesta týkajúce sa znalosti 42 programovacích jazykov a 20 rokov súčasného používania Kubernetes a Swarm. Pracovný diagram.
Takto sa v mysliach ľudí zakorenil nezmyselný a nemilosrdný obraz istého „devopsového“ superhrdinu, ktorý každého nastaví tak, aby ho nasadil do Jenkinsa, a šťastie príde. Ach, keby bolo všetko také jednoduché. „A takto môžete loviť aj systémových administrátorov,“ myslí si HR, „je to módne slovo, kľúčové slová sú rovnaké, mali by vziať návnadu.“
Dopyt vytvára ponuku a všetky tieto voľné miesta zaplnilo šialené množstvo systémových administrátorov, ktorí si uvedomili: všetko môžete robiť rovnako ako predtým, ale dostanete niekoľkonásobne viac, keď sa budete nazývať „devops“. Rovnako ako ste manuálne konfigurovali servery cez SSH jeden po druhom, budete ich aj naďalej konfigurovať, ale teraz je to údajne prax devops. Ide o nejaký komplexný fenomén, čiastočne súvisiaci s podceňovaním klasických adminov a hype okolo DevOps, ale vo všeobecnosti sa stalo, čo sa stalo.
Takže máme ponuku a dopyt. Začarovaný kruh, ktorý sa živí sám. To je to, proti čomu bojujeme (aj vytvorením konferencie DevOops).
Samozrejme, okrem systémových administrátorov, ktorí sa premenovali na „devops“, existujú aj iní účastníci – napríklad profesionálni SRE alebo vývojári Infrastructure-as-Code.
Čo ľudia robia v DevOps (naozaj)
Takže chcete napredovať v učení a uplatňovaní postupov DevOps. Ale ako to urobiť, ktorým smerom sa pozerať? Je zrejmé, že by ste sa nemali slepo spoliehať na obľúbené kľúčové slová.
Ak existuje práca, niekto by ju mal robiť. Už sme zistili, že to nie sú „devops inžinieri“, potom kto sú? Správnejšie sa javí formulovať to nie z hľadiska pozícií, ale z hľadiska konkrétnych oblastí práce.
Najprv môžete osloviť jadro DevOps – procesy a kultúru. Kultúra je pomalý a ťažký biznis, a hoci je to tradične zodpovednosťou manažérov, každý je do toho nejakým spôsobom zapojený, od programátorov až po administrátorov. Pred pár mesiacmi Tim Lister :
„Kultúra je určená základnými hodnotami organizácie. Ľudia si to väčšinou nevšimnú, ale keďže sme dlhé roky pracovali v poradenstve, zvykli sme si to všímať. Vstúpite do spoločnosti a doslova v priebehu niekoľkých minút začnete cítiť, čo sa deje. Hovoríme tomu „príchuť“. Niekedy je táto vôňa naozaj dobrá. Niekedy spôsobuje nevoľnosť. (...) Nemôžete zmeniť kultúru, kým nepochopíte hodnoty a presvedčenia, ktoré stoja za konkrétnymi činmi. Správanie sa dá ľahko pozorovať, ale hľadanie presvedčení je ťažké. DevOps je len skvelým príkladom toho, ako sa veci stávajú čoraz zložitejšími.“
Nechýba samozrejme ani technická časť problému. Ak sa váš nový kód otestuje do mesiaca, ale bude vydaný až o rok neskôr a je fyzicky nemožné to všetko urýchliť, možno nebudete dodržiavať osvedčené postupy. Osvedčené postupy sú podporované dobrými nástrojmi. Napríklad s myšlienkou Infrastructure-as-Code na mysli môžete použiť čokoľvek od AWS CloudFormation a Terraform až po Chef-Ansible-Puppet. Toto všetko musíte vedieť a vedieť, a to je už dosť inžinierska disciplína. Dôležité je nezamieňať príčinu s následkom: najprv pracujete podľa princípov SRE a až potom tieto princípy implementujete vo forme nejakých konkrétnych technických riešení. Zároveň je SRE veľmi komplexná metodika, ktorá vám nepovie, ako nastaviť Jenkins, ale o piatich základných princípoch:
- Vylepšená komunikácia medzi rolami a oddeleniami
- Prijímanie chýb ako neoddeliteľná súčasť práce
- Vykonávanie zmien postupne
- Používanie nástrojov a inej automatizácie
- Meranie všetkého, čo sa dá zmerať
Toto nie je len nejaký súbor vyhlásení, ale konkrétne . Napríklad na ceste k akceptovaniu chýb budete musieť pochopiť riziká, zmerať dostupnosť a nedostupnosť služieb pomocou niečoho ako SLI () a SLO (), naučte sa písať posmrtné správy, aby ich písanie nebolo strašidelné.
V disciplíne SRE je používanie nástrojov len jednou časťou úspechu, aj keď dôležitou. Musíme sa neustále technicky rozvíjať, pozerať sa na to, čo sa deje vo svete a ako sa to dá uplatniť v našej práci.
Cloudové natívne riešenia sa teraz stali veľmi populárnymi. Ako dnes definuje Cloud Native Computing Foundation, technológie Cloud Native umožňujú organizáciám vyvíjať a prevádzkovať škálovateľné aplikácie v dnešných dynamických prostrediach, ako sú verejné, súkromné a hybridné cloudy. Príklady zahŕňajú kontajnery, servisné siete, mikroslužby, nemennú infraštruktúru a deklaratívne API. Všetky tieto techniky umožňujú, aby voľne spojené systémy zostali elastické, ovládateľné a dobre pozorovateľné. Dobrá automatizácia umožňuje inžinierom vykonávať veľké zmeny často a s predvídateľnými výsledkami bez toho, aby to bolo náročné. To všetko podporuje hromada známych nástrojov, ako sú Docker a Kubernetes.
Táto pomerne komplikovaná a široká definícia je spôsobená skutočnosťou, že oblasť je tiež pomerne zložitá. Na jednej strane sa tvrdí, že nové zmeny do tohto systému by sa mali pridať celkom jednoducho. Na druhej strane, prísť na to, ako vytvoriť druh kontajnerového prostredia, v ktorom voľne prepojené služby žijú na softvérovo definovanej infraštruktúre a sú tam dodávané pomocou kontinuálneho CI/CD, a okolo toho všetkého vybudovať postupy DevOps – to všetko si vyžaduje viac. než jeden jesť psa.
Čo s tým všetkým robiť
Každý rieši tieto problémy po svojom: môžete napríklad zverejniť normálne voľné miesta, aby ste prerušili začarovaný kruh. Môžete zistiť, čo znamenajú slová ako DevOps a Cloud Native, a použiť ich správne a k veci. Môžete sa rozvíjať v DevOps a demonštrovať správne prístupy na svojom príklade.
Robíme konferenciu , ktorá poskytuje príležitosť hlbšie sa ponoriť do vecí, o ktorých sme práve hovorili. Na tento účel existuje niekoľko skupín prehľadov:
- Procesy a kultúra;
- Inžinierstvo spoľahlivosti miesta;
- Cloud Native;
Ako si vybrať, kam ísť? Je tu jeden jemný bod. Na jednej strane je DevOps o interakcii a naozaj chceme, aby ste sa zúčastnili prezentácií z rôznych blokov. Na druhej strane, ak ste manažér vývoja, ktorý sa prišiel na konferenciu sústrediť na jednu konkrétnu úlohu, tak vás nikto neobmedzuje – zrejme pôjde o blok o procesoch a kultúre. Nezabudnite, že po konferencii (po vyplnení formulára spätnej väzby) budete mať nahrávky, takže menej dôležité prezentácie si môžete kedykoľvek pozrieť neskôr.
Je zrejmé, že na samotnej konferencii nemôžete ísť na tri skladby naraz, takže program organizujeme tak, že každý časový úsek má témy pre každý vkus.
Zostáva len pochopiť, čo robiť, ak ste inžinier DevOps! Najprv sa pokúste určiť, čo vlastne robíte. Zvyčajne radi volajú toto slovo:
- Vývojári, ktorí pracujú na infraštruktúre. Skupiny správ o SRE a Cloud Native sú pre vás najvhodnejšie.
- Správcovia systému. Tu je to zložitejšie. DevOops nie je o správe systému. Našťastie na tému správy systému je na internete množstvo výborných konferencií, kníh, článkov, videí atď. Na druhej strane, ak máte záujem rozvíjať sa v zmysle chápania kultúry a procesov, spoznávať cloudové technológie a detaily života s Cloud Native, radi vás uvidíme! Zamyslite sa nad týmto: robíte administratívu a čo potom budete robiť? Aby ste sa náhle neocitli v nepríjemnej situácii, mali by ste sa to teraz naučiť.
Je tu ešte jedna možnosť: trváte na tom a naďalej budete tvrdiť, že ste konkrétne inžinier DevOps a nič iné, nech už to znamená čokoľvek. Potom vás musíme sklamať, DevOops nie je konferencia pre inžinierov DevOps!
Posunúť z v Mníchove
DevOops 2020 Moskva sa bude konať 29. – 30. apríla v Moskve, vstupenky sú už dostupné .
Prípadne môžete do 8. februára. Upozorňujeme, že pri vypĺňaní formulára musíte vybrať cieľové publikum, ktoré bude mať z vašej správy najväčší úžitok (v zozname je ukryté prekvapenie).
Zdroj: hab.com