Kezdő útmutató a DevOps-hoz: Hogyan lehet bejutni az iparba?

Ha karrierjét indítja, vagy a DevOps-ra való áttérést tervezi, az első dolgok közül egyik megtanulása az, hogy a DevOps inkább módszertan, mint munkakör. A DevOps célja, hogy áthidalja az IT működés és a fejlesztés közötti bármilyen szakadékot, hogy ösztönözze a két fél közötti együttműködést és részvételt az esetleges meglepetések csökkentése érdekében, amikor alkalmazást kell telepíteni a termelésre, nagy hangsúlyt fektetve az automatizálásra és a szabványosításra.

Mindezek mellett sokan közülünk szólunk, akik prédikálják a DevOps alapértékeit, és vannak olyan felelősségi körük, amelyek a DevOps módszertanának szenvednek, így minket DevOps mérnökökké tesznek. Tapasztalataim szerint ezeknek a felelősségeknek a középpontjába kerültek:

  • Infrastruktúra (Cloud vagy On-prem)
  • Monitoring
  • Automatizálás
  • Hálózat
  • Biztonság
  • Kiadás és telepítés (CI / CD)

Nyilvánvaló, hogy ez széles körű tudást igényel ahhoz, hogy teljes mértékben jártas legyen a karrierjének a DevOps-ban történő megkezdésekor, és nem hiszem, hogy létezik egyetemi vagy egyetemi diploma, melynek neve „Bachelor of DevOps”. Szóval, hogyan mások indították el a DevOps karrierjét?

Tapasztalataim szerint a DevOps mérnökei 2 háttérrel rendelkeznek:

1- Fejlesztő, akit érdekel az infrastruktúra és a műveletek.

2- Rendszergazda, nagy fejlesztési készségekkel.

Függetlenül attól, hogy milyen utat választ, vagy akár akkor is, ha karrierjét azonnal el akarta kezdeni a DevOps-ban, a DevOps természete miatt gyakran találja meg magát, hogy összehangolja a több csapatból származó információkat (háttérkép, előlap, DB stb.), És ott tartózkodik a minden közepe. Ez egyszerre áldás és átok, de ez attól függ, hogy ki akarja venni az élményt.

Most, hogy kicsit megértette a DevOps Engineer szerepét egy szervezetben, áttekintem néhány puha és kemény készséget, amelyek szerintem kulcsfontosságúak a sikerhez.

Automatizáljon minden mentalitást:

https://xkcd.com/974/

Röviden megemlítettem, hogy DevOps mérnökként nem akarja, hogy blokkoló lehessen egy telepítésnél. Tehát fontos neked, mint DevOps mérnöknek, hogy rendelkezzen egy olyan szerszámkészlettel, amely rendkívül kényelmes. És valóban ezeket az eszközöket fel lehet osztani néhány kategóriába:

1- Infrastruktúra mint kód, példák a Terraform, a CloudFormation, az ARM vagy a Google Cloud Deployment Manager.

2- A konfigurációkezelés példái az Ansible, a Chef, a Puppet vagy a PowerShell DSC

3- Szkriptnyelv, például Python, Bash vagy GO

4 - Parancssor, a környezettől függően (Linux vagy Windows), de nagyon kényelmes. Felejtsd el a munkaterhelés felhasználói felületről történő megszerzését.

5 - Repository Management, nem fogsz messze menni ebben az iparágban, ha nem fogadsz el Git-et vagy valamilyen VCS-t. Tanulja meg, fogadja el a munkafolyamatokba, mivel egy napot takarít meg.

A kristálytiszta tisztázás szempontjából nem releváns a pontos eszköz, amelyre bukkant, az itt az, hogy megértsük, mihez és miért van szükségük ezekre az eszközökre. Ezek a pontos eszközök megváltoztatják a túlórát, de a készségek és a koncepciók átadhatók.

Ezek az eszközök elősegítik az ad-hoc változtatások végrehajtását, a CI / CD csővezetékek felépítését, méretarányát, és ami a legfontosabb, hogy az üzleti igényeket a lehető legrövidebb időn belül teljesítse.

Tartsa be a szabványokat:

Az összes általunk említett eszköz nagyszerű, de óvatosságnak tartjuk, hogy 2 mérnök ugyanazokat a pontos eszközöket használhatja, de eltérő megvalósításban részesül. Mindkettő lehet 100% -ban érvényes és helyes, csak különféle. Ennek megoldására hozzon létre vagy fogadjon el egy szabványt a kódolásról és az eszközökről.

Az egyik első dolgom, amelyet a csapat tett, amikor átvállaltuk az Ansible-t, hogy szigorú YAML szabványt alakítson ki. Ez rendkívül fontos, mert az idő múlásával új csapattagokkal csatlakozhat, és végül akár a fejlesztők számára is megnyithatja néhány eszközét.

Dokumentum, dokumentum, dokumentum:

Amikor elkezdi alkalmazni az IaC-t, a Konfigurációkezelő eszközöket stb., Gyorsan rájön, hogy bármilyen dokumentációnak a Confluence-ben vagy a Wikiben történő elírása elveszett csata. A „Deklarációs kód” az igazság forrássá és munkadokumentumává válik.

De meg fogja kérdezni, hol dokumentáljuk, hogyan lehet mindezt futtatni? Azt mondanám, hogy a README.md fájl repóban mindig ezt fogja elvégezni.

Mindig ellenőrizze, hogy a projekt elszámolja-e a dokumentációt, ide tartozik a kód megjegyzése. Könnyebb megtenni, ha fejlesztem, nem pedig a végén.

Kommunikáció és részvétel:

Ne állítsa fel a vakdarabot, és ne dolgozzon egy feladaton anélkül, hogy megbizonyosodott arról, hogy teljes mértékben megérti a csapat jövőképe és céljait. A csapat célja az automatizálás, az infrastruktúra mint a kód stb. Segít megérteni, hogyan járul hozzá pozitívan a csapathoz, a saját karrierjéhez és végül az üzleti élethez.

Különösen a DevOps esetében kommunikálnia kell a csapaton belül és kívülről más csapatokkal is. Nagyon hiszem, hogy a legjobb rendszereket úgy tervezték meg és valósították meg, amikor egy keresztfunkcionális csapat tagjai vagytok, és mindenki felajánlja szakértelmét és tapasztalatait. A Slalom Build során láthatja, hogy ezt a részt nagyon komolyan vesszük, mivel közvetlenül a Terméktechnikai Módszertanunkba (PEM) építettük.

Soha ne mondja: „Így csináltuk mindig”:

Túl gyakran hallottam ezt a sort a karrierem során, a DevOps állapota mindig változik és mozog, ha egyáltalán tettél valamit, akkor mindig van fejlődés. Legyen nyitott az új ötletekre és új eszközökre.

A tanulás éles értelme:

Attól függően, hogy a DevOps melyik területén fókuszál, rengeteg tanúsítás érhető el, akár felhőalapú szolgáltatásokból, mint például AWS, GCP, Azure stb., Akár eszközökről, például Kubernetes, VMware, RedHat stb.

A tanúsítások nagyszerűek, mivel segítenek alapvető ismereteket adni, ám nem éri el valós tapasztalatok megadását, amelyek jelentősen eltérhetnek egymástól, mint egy teszt. A kettő közötti szakadék áthidalására azt találom, hogy cikkek olvasása és a podcastok hallgatása segít egy kicsit felépíteni ezt a tapasztalatot, de semmi sem győzöm meg az igazi valós tapasztalatokat. Néhány podcastot hallgatok, hogy kapcsolatba léphessek az új fejleményekkel, és egy kicsit segítsem a tapasztalataimat:

  • Teljes verem rádió
  • Google Cloud Platform Podcast
  • Az InfoQ Podcast (ez a személyes kedvencem)
  • Minden dolog DevOps

Ennélfogva az iparunkban el kell olvasni a Google webhelybiztonsági mérnöki könyvének, mivel ez segít megérteni néhány, az itt tárgyalt alapvető fogalmat.