Viime aikoina tällaiset mainokset ovat tulvineet Internetiä. Miellyttävästä palkasta huolimatta ei voi olla nolostumatta, että sisälle on kirjoitettu villiä harhaoppia. Aluksi oletetaan, että "DevOps" ja "insinööri" voidaan jotenkin liimata yhteen sanaksi, ja sitten on satunnainen luettelo vaatimuksista, joista osa on selvästi kopioitu sysadmin-vapaalta.
Tässä postauksessa haluaisin puhua hieman siitä, kuinka pääsimme tähän elämänvaiheeseen, mitä DevOps todella on ja mitä sille nyt tehdään.
Tällaiset avoimet työpaikat voidaan tuomita kaikin mahdollisin tavoin, mutta tosiasia on: niitä on monia, ja näin markkinat toimivat tällä hetkellä. Pidimme devops-konferenssin ja julistimme avoimesti: " - ei DevOps-insinööreille." Tämä tuntuu monista oudolta ja villiltä: miksi täysin kaupallista tapahtumaa järjestävät ihmiset menevät markkinoita vastaan. Nyt selitämme kaiken.
Kulttuurista ja prosesseista
Aloitetaan siitä tosiasiasta, että DevOps ei ole insinööritiede. Kaikki alkoi siitä, että historiallisesti vakiintunut roolijako ei toimi tuotteiden laadun kannalta. Kun ohjelmoijat vain ohjelmoivat, mutta eivät halua kuulla mitään testaamisesta, ohjelmisto on täynnä bugeja. Kun järjestelmänvalvojat eivät välitä kuinka tai miksi ohjelmisto on kirjoitettu, tuki muuttuu helvetiksi.
Esimerkiksi kuvaamalla eroa järjestelmänvalvojan ja SRE-lähestymistavan välillä palvelunhallinnassa . Mielenkiintoisia tutkimuksia on tehty sisällä - On selvää, että parhaat kehittäjät onnistuvat jotenkin ottamaan uusia muutoksia tuotantoon nopeammin kuin kerran tunnissa. He testaavat käsillään enintään 10% (tämä näkyy ). Miten he tekevät tämän? "Excel or die" sanoo yksi raportin otsikoista. Yksityiskohtaista keskustelua näistä tilastoista testauksen suhteen voit katsoa Baruch Sadogurskyn pääpuheenvuorossa. toisessa konferenssissamme, Heisenbugissa.
"Kun toverit eivät ole yksimielisiä,
No, heidän liiketoimintansa ei tee,
Ja se ei toimi häneltä, vain jauhoja.
Olipa kerran joutsen, rapu ja hauki..."
Minkä osan web-ohjelmoijista luulet todella ymmärtävän olosuhteet, joissa heidän sovelluksiaan käytetään tuotannossa? Kuinka moni heistä menee järjestelmänvalvojien luo ja yrittää selvittää, mitä tapahtuu, jos tietokanta kaatuu? Ja kuka heistä menee testaajien luo ja pyytää heitä opettamaan heille kuinka kokeita kirjoittaa oikein? Ja siellä on myös vartijoita, tuotepäälliköitä ja joukko muita ihmisiä.
DevOpsin yleisidea on luoda yhteistyötä roolien ja osastojen välillä. Ensinnäkin tämä ei saavuteta jollain taitavasti konfiguroidulla ohjelmistolla, vaan viestintäkäytännöllä. DevOps on kulttuurista, käytännöistä, metodologiasta ja prosesseista. Ei ole olemassa tekniikan erikoisalaa, joka voisi vastata näihin kysymyksiin.
Noidankehä
Mistä "devops-tekniikan" kurinalaisuus sitten tuli? Meillä on versio! DevOps-ideat olivat hyviä – niin hyviä, että niistä tuli oman menestyksensä uhreja. Jotkut hämärät rekrytoijat ja ihmissalakuljettajat, joilla on oma ilmapiiri, alkoivat kierrellä koko tämän aiheen ympärillä.
Kuvittele: eilen teit shawarmaa Khimkissä, ja tänään olet jo iso mies, vanhempi rekrytoija. Ehdokkaiden etsiminen ja valinta on koko prosessi, kaikki ei ole helppoa, sinun on ymmärrettävä. Oletetaan, että osastopäällikkö sanoo: etsi asiantuntija X:stä. Määritämme X:lle sanan "insinööri", ja homma on valmis. Tarvitsetko Linuxia? No, tämä on ehdottomasti Linux-insinööri, jos haluat DevOpsin, niin DevOps-insinööri. Avoinna oleva paikka ei koostu vain otsikosta, vaan myös tekstiä on syötettävä sisään. Helpoin tapa on antaa joukko avainsanoja Googlesta mielikuvituksesi mukaan. DevOps koostuu kahdesta sanasta - "Dev" ja "Ops", mikä tarkoittaa, että meidän on liimattava kehittäjiin ja ylläpitäjiin liittyvät avainsanat yhteen kasaan. Näin ilmaantuu avoimia työpaikkoja 42 ohjelmointikielen taidosta ja 20 vuoden Kubernetesin ja Swarmin samanaikaisesta käytöstä. Toimiva kaavio.
Näin ihmisten mieliin on juurtunut merkityksetön ja armoton kuva tietystä "devops"-supersankarista, joka konfiguroi kaikki sijoittumaan Jenkinsiin, ja onnellisuus tulee. Voi kun kaikki olisikin niin yksinkertaista. "Ja näin voit myös metsästää järjestelmänvalvojat", HR ajattelee, "se on muodikas sana, avainsanat ovat samat, heidän pitäisi ottaa syötti."
Kysyntä luo tarjontaa, ja kaikki nämä roskakorit ovat täyttyneet mielettömällä määrällä järjestelmänvalvojia, jotka tajusivat: voit tehdä kaiken samalla tavalla kuin ennen, mutta saada useita kertoja enemmän kutsumalla itseäsi "devops". Aivan kuten konfiguroit palvelimia SSH:n kautta manuaalisesti yksi kerrallaan, jatkat niiden määrittämistä, mutta nyt tämä on oletettavasti devops-käytäntö. Tämä on jonkinlainen monimutkainen ilmiö, joka liittyy osittain klassisten ylläpitäjien aliarvioimiseen ja DevOpsin ympärillä olevaan hypetykseen, mutta yleisesti ottaen mitä tapahtui, tapahtui.
Meillä on siis kysyntää ja tarjontaa. Noidankehä, joka ruokkii itseään. Tätä vastaan taistelemme (mukaan lukien luomalla DevOops-konferenssin).
Tietenkin järjestelmänvalvojien lisäksi, jotka ovat nimenneet itsensä uudelleen "devopsiksi", on muitakin osallistujia - esimerkiksi ammattimaisia SRE:itä tai Infrastructure-as-Code -kehittäjiä.
Mitä ihmiset tekevät DevOpsissa (todella)
Joten haluat päästä eteenpäin DevOps-käytäntöjen oppimisessa ja soveltamisessa. Mutta miten tämä tehdään, mihin suuntaan katsoa? On selvää, että sinun ei pitäisi sokeasti luottaa suosittuihin avainsanoihin.
Jos on työtä, jonkun pitäisi se tehdä. Olemme jo havainneet, että nämä eivät ole "devops-insinöörejä", keitä sitten ovat? Tuntuu oikeammalta muotoilla tämä ei tehtävien, vaan tiettyjen työalueiden kannalta.
Ensinnäkin voit käsitellä DevOpsin ydintä – prosesseja ja kulttuuria. Kulttuuri on hidasta ja vaikeaa bisnestä, ja vaikka se on perinteisesti johtajien vastuulla, kaikki ovat tavalla tai toisella mukana ohjelmoijista ylläpitäjiin. Pari kuukautta sitten Tim Lister :
”Kulttuurin määräävät organisaation perusarvot. Yleensä ihmiset eivät huomaa tätä, mutta olemme työskennelleet konsulttina monta vuotta, olemme tottuneet huomaamaan sen. Tulet yritykseen ja alat kirjaimellisesti muutaman minuutin sisällä tuntea mitä tapahtuu. Kutsumme tätä "makuksi". Joskus tämä tuoksu on todella hyvä. Joskus se aiheuttaa pahoinvointia. (...) Kulttuuria ei voi muuttaa ennen kuin tiettyjen toimien taustalla olevat arvot ja uskomukset ymmärretään. Käyttäytymistä on helppo havaita, mutta uskomusten etsiminen on vaikeaa. DevOps on vain loistava esimerkki siitä, kuinka asiat muuttuvat yhä monimutkaisemmiksi."
Asiassa on tietysti myös tekninen osa. Jos uusi koodisi testataan kuukaudessa, mutta se julkaistaan vasta vuoden kuluttua ja sitä on fyysisesti mahdotonta nopeuttaa, et välttämättä toimi hyvien käytäntöjen mukaisesti. Hyviä käytäntöjä tuetaan hyvillä työkaluilla. Esimerkiksi Infrastructure-as-Code-ajatus mielessä, voit käyttää mitä tahansa AWS CloudFormationista ja Terraformista Chef-Ansible-Puppetiin. Sinun on tiedettävä ja kyettävä tekemään tämä kaikki, ja tämä on jo melkoinen insinööritiede. On tärkeää olla sekoittamatta syytä ja seurausta: ensin toimitaan SRE:n periaatteiden mukaan ja vasta sitten toteutetaan nämä periaatteet tiettyjen teknisten ratkaisujen muodossa. Samaan aikaan SRE on erittäin kattava menetelmä, joka ei kerro sinulle, kuinka Jenkins asetetaan, vaan noin viidestä perusperiaatteesta:
- Parempi viestintä roolien ja osastojen välillä
- Virheiden hyväksyminen olennaisena osana työtä
- Muutoksia tehdään asteittain
- Työkalujen ja muun automaation käyttö
- Mittaa kaikkea mitä voidaan mitata
Tämä ei ole vain joukko lausuntoja, vaan tietty määrä . Esimerkiksi matkalla kohti virheiden hyväksymistä sinun on ymmärrettävä riskit, mitattava palvelujen saatavuus ja epäkäytettävyys käyttämällä jotain SLI:tä () ja SLO (), opettele kirjoittamaan kuolemanjälkeisiä kuvia, jotta niiden kirjoittaminen ei ole pelottavaa.
SRE-alalla työkalujen käyttö on vain yksi osa menestystä, vaikkakin tärkeä. Meidän tulee jatkuvasti kehittyä teknisesti, katsoa mitä maailmassa tapahtuu ja miten sitä voidaan soveltaa työssämme.
Cloud Native -ratkaisuista on puolestaan tullut erittäin suosittuja. Cloud Native Computing Foundationin tänään määrittelemän Cloud Native -teknologian avulla organisaatiot voivat kehittää ja käyttää skaalautuvia sovelluksia nykypäivän dynaamisissa ympäristöissä, kuten julkisissa, yksityisissä ja hybridipilveissä. Esimerkkejä ovat säiliöt, palveluverkot, mikropalvelut, muuttumaton infrastruktuuri ja deklaratiiviset sovellusliittymät. Kaikki nämä tekniikat mahdollistavat löyhästi kytkettyjen järjestelmien pysymisen joustavina, hallittavissa ja erittäin havaittavissa. Hyvä automaatio mahdollistaa sen, että insinöörit voivat tehdä suuria muutoksia usein ja ennustettavissa olevin tuloksin ilman, että siitä tulee vaivaa. Kaikkea tätä tukee joukko tunnettuja työkaluja, kuten Docker ja Kubernetes.
Tämä melko monimutkainen ja laaja määritelmä johtuu siitä, että alue on myös melko monimutkainen. Toisaalta väitetään, että tähän järjestelmään pitäisi lisätä yksinkertaisesti uusia muutoksia. Toisaalta keksiä, miten luoda eräänlainen konttiympäristö, jossa löyhästi kytketyt palvelut elävät ohjelmiston määrittelemässä infrastruktuurissa ja toimitetaan sinne jatkuvalla CI/CD:llä, ja rakentaa DevOps-käytäntöjä kaiken tämän ympärille - kaikki tämä vaatii enemmän kuin yksi syö koiraa.
Mitä tehdä tämän kaiken kanssa
Jokainen ratkaisee nämä ongelmat omalla tavallaan: voit esimerkiksi julkaista normaaleja avoimia työpaikkoja noidankehän katkaisemiseksi. Voit selvittää, mitä sanat, kuten DevOps ja Cloud Native, tarkoittavat, ja käyttää niitä oikein ja tarkoituksenmukaisesti. Voit kehittää DevOpsissa ja esitellä oikeat lähestymistavat esimerkilläsi.
Järjestämme konferenssin , joka tarjoaa mahdollisuuden syventää asioita, joista juuri puhuimme. Tätä varten on useita raporttiryhmiä:
- Prosessit ja kulttuuri;
- Työpaikan luotettavuustekniikka;
- Cloud Native;
Kuinka valita minne mennä? Tässä on hienovarainen pointti. Toisaalta DevOps on vuorovaikutusta, ja haluamme todella, että osallistut esityksiin eri lohkoista. Toisaalta, jos olet kehityspäällikkö, joka tuli konferenssiin keskittymään johonkin tiettyyn tehtävään, niin kukaan ei rajoita sinua - tämä on tietysti lohko prosesseista ja kulttuurista. Muista, että sinulla on tallenteita konferenssin jälkeen (palautelomakkeen täyttämisen jälkeen), jotta voit aina katsoa vähemmän tärkeät esitykset myöhemmin.
Ilmeisesti itse konferenssissa ei voi mennä kolmelle radalle kerralla, joten järjestämme ohjelman niin, että jokaisessa aikavälissä on aiheita jokaiseen makuun.
Jäljelle jää vain ymmärtää, mitä tehdä, jos olet DevOps-insinööri! Yritä ensin selvittää, mitä todella teet. Yleensä he haluavat kutsua tätä sanaa:
- Kehittäjät, jotka työskentelevät infrastruktuurin parissa. SRE:tä ja Cloud Nativea koskevat raporttiryhmät sopivat sinulle parhaiten.
- Järjestelmänvalvojat. Täällä se on monimutkaisempaa. DevOops ei koske järjestelmänhallintaa. Onneksi Internetissä on paljon erinomaisia konferensseja, kirjoja, artikkeleita, videoita jne. järjestelmänhallinnasta. Toisaalta, jos olet kiinnostunut kehittämään itseäsi kulttuurin ja prosessien ymmärtämisen suhteen, oppimaan pilviteknologioista ja elämän yksityiskohdista Cloud Nativen avulla, näkisimme mielellämme! Ajattele tätä: teet hallintoa, ja mitä sitten teet? Jotta et joutuisi yhtäkkiä epämiellyttävään tilanteeseen, sinun tulee oppia nyt.
On toinenkin vaihtoehto: jatkat ja väität olevasi erityisesti DevOps-insinööri eikä mitään muuta, mitä se sitten tarkoittaakaan. Sitten meidän on tuotettava sinulle pettymys, DevOops ei ole DevOps-insinöörien konferenssi!
Dia alkaen Münchenissä
DevOops 2020 Moskova järjestetään 29.-30. Moskovassa, lippuja on jo saatavilla .
Vaihtoehtoisesti voit helmikuun 8. päivään asti. Huomaa, että lomaketta täytettäessä sinun on valittava kohdeyleisö, joka hyötyy eniten raportistasi (listan sisällä on yllätys).
Lähde: will.com