A DevOps definíciója nagyon összetett, ezért minden alkalommal elölről kell kezdenünk a vitát. Csak Habréról ezer publikáció jelent meg ebben a témában. De ha ezt olvassa, valószínűleg tudja, mi az a DevOps. Mert én nem. Helló az én nevem Alexander Titov (@), és csak a DevOps-ról beszélünk, és megosztom a tapasztalataimat.
Régóta gondolkozom azon, hogyan tegyem hasznossá a történetemet, ezért sok kérdés lesz itt – olyanok is, amelyeket magamnak és cégünk ügyfeleinek teszek fel. E kérdések megválaszolásával jobb lesz a megértés. Elmondom, miért van szükség a DevOps-ra az én szemszögemből, mi az, az én szemszögemből, és hogyan érthető meg, hogy az én szemszögemből ismét a DevOps felé haladsz. Az utolsó pont a kérdéseken keresztül lesz. Ha megválaszolja őket magának, megértheti, hogy cége a DevOps felé halad-e, vagy vannak-e problémák valamilyen módon.
Egy időben a fúziók és felvásárlások hullámait lovagoltam meg. Először egy Qik nevű kis startupnál dolgoztam, majd egy kicsit nagyobb cég, a Skype vette meg, amit aztán egy kicsit nagyobb cég, a Microsoft vett meg. Abban a pillanatban kezdtem látni, hogyan alakul át a DevOps ötlete a különböző méretű cégekben. Ezt követően kezdett el érdeklődni a DevOps piaci szemszögből való megismerése iránt, és kollégáimmal megalapítottuk az Express 42 céget. 6 éve haladunk a piac hullámain.
Többek között a DevOps Moszkva közösség egyik szervezője és a DevOps-Days 2017 szervezője vagyok, de 2018-at nem én szerveztem. Az Express 42 számos céggel működik együtt. Ott fejlesztjük a DevOps-t, figyeljük, hogyan történik, következtetéseket vonunk le, elemezzük, elmondjuk mindenkinek a következtetéseinket, és megtanítjuk az embereket a DevOps gyakorlatokra. Általánosságban elmondható, hogy mindent megteszünk, hogy növeljük tapasztalatainkat és szakértelmünket ezen a területen.
Miért a DevOps?
Az első kérdés, ami mindenkit és mindig is kísért: miért? Sokan azt hiszik, hogy a DevOps csak automatizálás vagy hasonló, amivel már minden cég rendelkezett.
— Folyamatos integrációnk volt – ez azt jelenti, hogy már volt DevOps, és miért van szükség erre a cuccra? Szórakoznak külföldön, de minket akadályoznak a munkában!
A közösség és a módszertan 9 éves fejlesztése során már világossá vált, hogy ez még mindig nem marketingcsillám, de még mindig nem teljesen világos, hogy miért van rá szükség. Mint minden eszköznek és folyamatnak, a DevOps-nak is vannak konkrét céljai, amelyeket végül elér.
Mindez annak köszönhető, hogy a világ változik. Eltávolodik a vállalati szemlélettől, amikor a cégek egyenesen egy álom felé haladnak, ahogy pétervári klasszikusunk énekelte, A pontból B pontba egy bizonyos stratégia szerint, egy erre épített struktúrával.
Elvileg az informatikában mindent ennek a szemléletnek megfelelően kell felépíteni. Itt az IT-t kizárólag a folyamatok automatizálására használják.
Az automatizálás nem változik gyakran, mert ha egy cég egy jól bejáratott kerékvágásba megy, mit kell változtatni? Működik – ne nyúljon hozzá. A világ megközelítései most változnak, és az Agilisnak nevezett megközelítés azt sugallja, hogy a B végpont nem látható azonnal.
Amikor egy vállalat végigmegy a piacon, együttműködik egy ügyféllel, folyamatosan feltárja a piacot és megváltoztatja a B végpontot. Ráadásul minél gyakrabban változtat a cég irányvonalán, annál sikeresebb a végén, mert több piacot választ. fülkéket.
A stratégiát egy érdekes cég mutatja be, amelyről nemrég értesültem. A One Box Shave előfizetéses házhozszállítási szolgáltatás borotvákhoz és borotválkozási kiegészítőkhöz dobozban. Tudják, hogyan szabhatják testre „dobozukat” a különböző ügyfelek számára. Ezt egy bizonyos szoftver végzi, amely aztán elküldi a megrendelést az árut előállító koreai gyárba.
Ezt a terméket az Unilever vásárolta meg 1 milliárd dollárért. Most versenyez a Gillette-tel, és elvette a fogyasztók jelentős részét az amerikai piacon. One Box Shave mondja:
- 4 penge? Komolyan? Miért van szüksége erre - nem javítja a borotválkozás minőségét. Egy speciálisan kiválasztott krém, illat és egy kiváló minőségű, két pengéjű borotva sokkal több problémát old meg, mint az a hülye 4 Gillette penge! Hamarosan elérjük a 10-et?
Így változik a világ. Az Unilever azt állítja, hogy remek informatikai rendszerük van, amely lehetővé teszi ezt. Végül is koncepciónak tűnik A piacra kerülési idő, amiről még senki nem beszélt.
A piacra jutás ideje nem az, hogy milyen gyakran telepítjük. Gyakran telepíthető, de a kiadási ciklusok hosszúak lesznek. Ha a három hónapos kiadási ciklusokat egymásra helyezzük, és egy héttel eltoljuk őket, akkor kiderül, hogy a vállalat hetente egyszer telepíti őket. És az ötlettől a végső megvalósításig 3 hónap telik el.
A piacra jutás ideje az ötlettől a végső megvalósításig eltelt idő minimalizálásáról szól.
Ebben az esetben a szoftver kölcsönhatásba lép a piaccal. A One Box Shave webhely így működik együtt az ügyféllel. Nincsenek értékesítőik – csak egy webhely, ahol a látogatók rákattintva kívánságokat hagynak maguk után. Ennek megfelelően folyamatosan újat kell feltenni az oldalra, és a kívánságoknak megfelelően frissíteni kell. Például Dél-Koreában másképp borotválkoznak, mint Oroszországban, és nem a fenyő, hanem például a sárgarépa és a vanília illatát szeretik.
Mivel szükség van az oldal tartalmának gyors megváltoztatására, a szoftverfejlesztés jelentősen megváltozik. Szoftveren keresztül kell kiderítenünk, mit akar az ügyfél. Korábban ezt néhány körforgásos úton tanultuk meg, például az üzletvezetésen keresztül. Aztán megterveztük, beírtuk a követelményeket az informatikai rendszerbe, és minden menő volt. Most más a helyzet – a szoftvert mindenki, aki részt vesz a folyamatban, a mérnököket is tervezi, mert a műszaki specifikációk révén megismerik a piac működését, és megosztják tapasztalataikat a vállalkozással.
Például a Qiknél hirtelen megtudtuk, hogy az emberek nagyon szeretnek névjegyzékeket feltölteni a szerverre, és elláttak velünk egy alkalmazást. Kezdetben nem gondoltunk rá. Egy klasszikus cégnél mindenki úgy döntött volna, hogy ez hiba, mivel a specifikációban nem szerepelt, hogy remekül kell működnie, és általában a térdre építették, kikapcsolták volna a funkciót, és azt mondták volna: „Senkinek nincs szüksége erre, a a legfontosabb az, hogy a fő funkció működjön.” . A technológiai cég pedig lehetőséget lát ebben, és ennek megfelelően kezdi meg a szoftver megváltoztatását.
1968-ban egy látnoki srác, Melvin Conway megfogalmazta a következő ötletet.
A rendszert létrehozó szervezetet a szervezet kommunikációs struktúráját lemásoló tervezés korlátozza.
Részletesebben, ahhoz, hogy más típusú rendszereket tudjunk gyártani, egy másik típusú vállalaton belül is kommunikációs struktúrával kell rendelkeznie. Ha az Ön kommunikációs struktúrája felső hierarchikus, akkor ez nem teszi lehetővé olyan rendszerek létrehozását, amelyek nagyon magas piacra jutási idő mutatót tudnak biztosítani.
Olvas tud . A DevOps kultúra vagy filozófia megértéséhez fontos, mert az egyetlen dolog, ami alapvetően változik a DevOps-ban, az a csapatok közötti kommunikáció szerkezete.
A folyamat szempontjából a DevOps előtt minden szakasz: az elemzés, a fejlesztés, a tesztelés, az üzemeltetés lineáris volt.
A DevOps esetében mindezek a folyamatok egyszerre mennek végbe.
A piacra jutás ideje az egyetlen módja ennek. Azok számára, akik a régi folyamatban dolgoztak, ez kissé kozmikusnak tűnik, és általában olyan.
Szóval miért van szükséged DevOps-ra?
Digitális termékfejlesztéshez. Ha a cége nem rendelkezik digitális termékkel, nincs szükség DevOps-ra – ez nagyon fontos.
A DevOps legyőzi a szekvenciális szoftvergyártás sebességkorlátait. Ebben minden folyamat egyszerre megy végbe.
Növekszik a nehézség. Amikor a DevOps evangélisták azt mondják, hogy megkönnyíti a szoftverek kiadását, ez nonszensz.
A DevOps segítségével a dolgok csak bonyolultabbak lesznek.
Az Avito standnál tartott konferencián láthatta, milyen volt egy Docker konténer telepítése – irreális feladat. A bonyolultság túlzóvá válik; egyszerre több labdával kell zsonglőrködni.
A DevOps teljesen megváltoztatja a folyamatot és a szervezet szervezetét — pontosabban nem a DevOps változik, hanem a digitális termék. A DevOps használatához még teljesen meg kell változtatnia ezt a folyamatot.
Kérdések szakemberhez
Mid van? Kérdések, melyeket feltehetsz magadnak, miközben egy cégnél dolgozol és szakemberként fejlődsz.
Van stratégiája digitális termék létrehozására? Ha van, az már jó. Ez azt jelenti, hogy cége a DevOps felé halad.
Cége már készít digitális terméket? Ez azt jelenti, hogy egy szinttel magasabbra léphetsz, és érdekesebben csinálhatod a dolgokat – ismét DevOps szemszögéből. Csak ebből a szempontból beszélek.
Az Ön cége az egyik piacvezető a digitális termékek piacán? A Spotify, a Yandex, az Uber olyan vállalatok, amelyek jelenleg a technológiai fejlődés csúcsán vannak.
Tedd fel magadnak ezeket a kérdéseket, és ha minden válasz nemleges, akkor talán nem kellene DevOps-ot csinálni ennél a cégnél. Ha a DevOps témája igazán érdekes számodra, talán... át kellene költözned egy másik céghez? Ha a céged be akar lépni a DevOps-ba, de Ön minden kérdésre nemmel válaszolt, akkor olyan, mint az a gyönyörű orrszarvú, amely soha nem fog megváltozni.
Szervezet
Mint mondtam, a Conway-törvény szerint a vállalat szervezete megváltozik. Kezdem azzal, hogy szervezeti szempontból mi akadályozza meg a DevOps behatolását a cégbe.
A "kutak" problémája
Az angol "Silo" szót itt "is"-nek fordítják oroszra. A probléma lényege az nincs információcsere a csapatok között. Mindegyik csapat mélyen beleás a szakértelmébe anélkül, hogy közös térképet készítene a navigációhoz.
Bizonyos szempontból ez egy olyan személyre emlékeztet, aki most érkezett Moszkvába, és még nem tudja, hogyan kell navigálni a metrótérképen. A moszkoviták általában nagyon jól ismerik a területüket, és Moszkva egész területén a metrótérkép segítségével tudnak navigálni. Amikor először jössz Moszkvába, nem rendelkezel ezzel a képességgel, és egyszerűen összezavarodsz.
A DevOps azt javasolja, hogy vészelje át ezt a zavart pillanatot, és minden részleg dolgozzon együtt egy közös interakciós térkép kialakításán.
Ezt két tényező akadályozza.
A vállalatirányítási rendszer következménye. Külön hierarchikus „kutakba” épül. Például vannak bizonyos KPI-k a vállalatoknál, amelyek támogatják ezt a rendszert. Másrészt annak az embernek az agya, aki nehezen tudja túllépni szakértelme határait és eligazodni az egész rendszerben, akadályba ütközik. Egyszerűen kényelmetlen. Képzelje el, hogy a bangkoki repülőtéren tartózkodik – nem fog gyorsan eligazodni. A DevOps-ban is nehéz eligazodni, ezért az emberek azt mondják, hogy útmutatót kell találnod, hogy odaérj.
De a legfontosabb dolog az, hogy a DevOps szellemiségétől átitatott, Fowlert és egy csomó más könyvet olvasott mérnök „kutak” problémája abban nyilvánul meg, hogy A "kutak" nem engedik meg, hogy "nyilvánvaló" dolgokat csinálj. Gyakran összejövünk a DevOps Moszkva után, beszélgetünk egymással, és az emberek panaszkodnak:
— Csak a CI-t akartuk elindítani, de kiderült, hogy a vezetőségnek nincs rá szüksége.
Ez pontosan azért történik, mert CI и Folyamatos szállítási folyamat számos vizsgálat határán állnak. Egyszerűen a szervezeti szintű „kutak” problémájának leküzdése nélkül nem fog tudni előrelépni, bármit is csinál, és bármilyen szomorú is az.
A folyamat minden résztvevője a cégben: backend és frontend fejlesztők, tesztelés, DBA, üzemeltetés, hálózat, a saját irányába kotorászik, és senkinek nincs közös térképe, kivéve a menedzseret, aki valahogy figyeli és kezeli őket a „megosztás” segítségével. és hódíts” módszerrel.
Az emberek harcolnak néhány csillagért vagy zászlóért, mindenki a szakértelmét ásja.
Ebből kifolyólag, amikor felmerül a feladat mindezek összekapcsolása és egy közös csővezeték kiépítése, és már nem kell harcolni a csillagokért és zászlókért, akkor felmerül a kérdés – mégis mit tegyünk? Valahogy meg kell állapodnunk, de senki nem tanított meg minket erre az iskolában. Iskola óta tanítanak bennünket: nyolcadik osztály - hűha! - hetedik osztályhoz képest! Itt is ugyanaz.
A te cégedben is így van?
Ennek ellenőrzéséhez a következő kérdéseket teheti fel magának.
Használnak-e a csapatok közös eszközöket, és hozzájárulnak-e a közös eszközök megváltoztatásához?
Milyen gyakran szerveződnek át a csapatok – egyes szakemberek az egyik csapatból egy másik csapathoz költöznek? Ez DevOps környezetben válik normálissá, mert néha az ember egyszerűen nem érti, mit csinál egy másik szakterület. Egy másik osztályra költözik, és ott dolgozik két hétig, hogy elkészítse magának a tájékozódási és interakciós térképet ezzel az osztállyal.
Lehet-e váltóbizottságot alakítani és változtatni a dolgokon? Vagy ehhez a legmagasabb vezetés és irányítás erős keze kell? Nemrég írtam a Facebookon, hogy egy kevéssé ismert bank megbízásokon keresztül eszközöket valósít meg: írunk egy megbízást, egy évig végrehajtjuk, és meglátjuk, mi lesz. Ez persze hosszú és szomorú.
Mennyire fontos, hogy a vezetők személyes eredményeket kapjanak anélkül, hogy figyelembe vennék a vállalat eredményeit?
Ha ezeket a kérdéseket megválaszolja magának, akkor világosabbá válik, hogy van-e ilyen probléma a cégében.
Az infrastruktúra kódként
A probléma megoldása után az első fontos gyakorlat, amely nélkül nehéz továbblépni a DevOps-ban infrastruktúra kódként.
Leggyakrabban az infrastruktúrát kódként a következőképpen érzékelik:
— Automatizáljunk mindent bash-ban, takarodjunk scriptekkel, hogy kevesebb kézi munkájuk legyen az adminoknak!
De ez nem igaz.
Az infrastruktúra mint kód azt jelenti, hogy kód formájában írja le azt az informatikai rendszert, amellyel dolgozik, hogy folyamatosan megértse annak állapotát.
Más csapatokkal közösen létrehoz egy térképet kód formájában, amelyet mindenki érthet, és amelyen navigálni és navigálni tud. Nem számít, hogy milyen felületen történik – Chef, Ansible, Salt vagy YAML-fájlok használata Kubernetesben – nincs különbség.
A konferencián egy kolléga a 2GIS-től elmesélte, hogyan készítették el a Kubernetes számára saját belső dolgot, ami az egyes rendszerek felépítését írja le. 500 rendszer leírásához külön eszközre volt szükségük, amely ezt a leírást generálja. Ha megvan ez a leírás, mindenki ellenőrizheti egymást, figyelemmel kísérheti a változásokat, hogyan lehet változtatni, javítani, mi hiányzik.
Egyetértek, az egyes bash szkriptek általában nem biztosítják ezt a megértést. Az egyik cégnél, ahol dolgoztam, még a „csak írható” szkriptnek is volt neve – amikor a forgatókönyv meg van írva, de már nem lehet elolvasni. Szerintem ez neked is ismerős.
Az infrastruktúra olyan, amilyen a kód kód, amely leírja az infrastruktúra jelenlegi állapotát. Számos termék-, infrastruktúra- és szervizcsapat dolgozik együtt ezen a kódon, és ami a legfontosabb, mindannyiuknak meg kell érteniük a kód tényleges működését.
A kódot a legjobb kódolási gyakorlatok szerint karbantartják: közös fejlesztés, kód áttekintés, XP-programozás, tesztelés, pull kérések, CI kód infrastruktúrákhoz - mindez megfelelő és használható.
A kód minden mérnök közös nyelvévé válik.
Az infrastruktúra kódbeli megváltoztatása nem sok időt vesz igénybe. Igen, az infrastruktúra kódnak is lehet technikai tartozása. Általában másfél évvel azután találkoznak vele a csapatok, hogy elkezdték implementálni az „infrastruktúrát mint kódot” egy csomó script vagy akár az Ansible formájában, amit úgy írnak, mint a spagettikódot, és bash szkripteket is bedobnak a mixbe!
Fontos: Ha még nem próbáltad ezt a cuccot, ne feledd Az Ansible nem bash! Olvassa el figyelmesen a dokumentációt, tanulmányozza át, mit írnak róla.
Az infrastruktúra mint kód az infrastruktúra kódjának külön rétegekre való szétválasztása.
Cégünknél 3 alapréteget különböztetünk meg, amelyek nagyon áttekinthetőek és egyszerűek, de lehet, hogy több is van belőlük. Megnézheti az infrastruktúra kódját, és megállapíthatja, hogy fennáll-e ez a feltétel. Ha nincs kiemelve réteg, akkor szánni kell egy kis időt, és egy kicsit újra kell alakítani.
alapréteg - így van beállítva az operációs rendszer, a mentések és egyéb alacsony szintű dolgok, például a Kubernetes alapszinten történő telepítése.
Szolgáltatási szint - ezeket a szolgáltatásokat nyújtod a fejlesztőnek: naplózás mint szolgáltatás, monitorozás mint szolgáltatás, adatbázis mint szolgáltatás, Balancer mint szolgáltatás, queue mint szolgáltatás, Folyamatos szállítás mint szolgáltatás - egy csomó szolgáltatás, amit az egyes csapatok biztosíthatja a fejlődést. Mindezt külön modulokban kell leírni a konfigurációkezelő rendszerben.
Az a réteg, ahol az alkalmazások készülnek és leírja, hogyan fognak kibontakozni az előző két réteg tetején.
Ellenőrző kérdések
Az Ön cége rendelkezik közös infrastruktúra-tárral? Kezeli a műszaki adósságot az infrastruktúrájában? Használ fejlesztési gyakorlatokat infrastruktúra-tárban? Az infrastruktúrája rétegekre van felosztva? Ellenőrizheti a Base-service-APP diagramot. Mennyire nehéz változtatni?
Ha azt tapasztalta, hogy másfél napig tartott a változtatások végrehajtása, ez azt jelenti, hogy technikai tartozása van, és dolgoznia kell vele. Most véletlenül egy technikai adósságrakeszbe botlott az infrastruktúra kódjában. Sok ilyen történetre emlékszem, amikor néhány CCTL megváltoztatásához át kell írni az infrastruktúra kód felét, mert a kreativitás és az automatizálási vágy oda vezetett, hogy mindenhol minden korrodálódott, a fogantyúkat eltávolították, és refaktorálni kell.
Folyamatos szállítás
Hasonlítsuk össze a terhelést a hitellel. Először az infrastruktúra leírása következik, ami meglehetősen alapszintű lehet. Nem kell mindent részletesen leírni, de néhány alapvető leírás szükséges, hogy dolgozhasson vele. Ellenkező esetben nem világos, hogy mi legyen a következő lépés a folyamatos szállítással. Mindezek a gyakorlatok egyszerre bontakoznak ki, amikor a DevOps-hoz érkezel, de minden azzal kezdődik, hogy megérted, mi van, és hogyan kezeld azt. Pontosan ez az infrastruktúra mint kód gyakorlata.
Miután világossá válik, hogy megvan, és hogyan kell kezelni, elkezdi kitalálni, hogyan küldje el a fejlesztői kódot a lehető leggyorsabban éles üzembe. Mármint a fejlesztővel együtt - emlékszünk a „kutak” problémájára, vagyis nem egyéni emberek, hanem egy csapat találkoznak ezzel.
Amikor együtt vagyunk Vanya Evtukhovich látta az első könyvet Jez Humble és szerzői csoportok "Folyamatos szállítás", amely 2009-ben jelent meg, sokáig gondolkodtunk azon, hogyan fordítsuk le a címét oroszra. Le akarták fordítani „folyamatosan szállítani”, de sajnos „folyamatos kézbesítés”-nek fordították. Nekem úgy tűnik, hogy van valami orosz a nevünkben, nyomással.
Folyamatosan szállító eszközöket
A terméktárban lévő kód mindig letölthető éles verzióra. Lehet, hogy nincs leeresztve, de mindig készen áll rá. Ennek megfelelően mindig nehezen megmagyarázható szorongással írsz kódot a farokcsontod alatt. Gyakran megjelenik az infrastruktúra kódjának közzétételekor. Ennek a szorongás érzésének jelen kell lennie - olyan agyi folyamatokat indít el, amelyek lehetővé teszik, hogy egy kicsit másképp írjon kódot. Ezt a fejlesztésen belül a szabályzatban rögzíteni kell.
A következetes megjelenítéshez olyan műtermékformátumra van szükség, amely egy infrastruktúra-platformon fut. Ha egy infrastrukturális platformon átdobjuk a különböző formátumú „élethulladékot”, akkor az egységessé válik, nehezen karbantartható, és felmerül a technikai adósság problémája. A műtárgy formátumát össze kell hangolni – ez is kollektív feladat: össze kell fognunk, fel kell zúgnunk az agyunkkal, és ki kell találnunk ezt a formátumot.
A műterméket folyamatosan fejlesztik és a gyártási környezetnek megfelelően változtatják, ahogy halad a szállítási csővezetéken. Amikor egy műtermék mozog a csővezetéken, folyamatosan találkozik számára kellemetlen dolgokkal, amelyek hasonlóak ahhoz, amit a gyártásba helyezett műtárgy találkozik. Ha a klasszikus fejlesztésben ezt egy rendszergazda csinálja, aki a rolloutot végzi, akkor a DevOps folyamatban ez folyamatosan történik: itt tesztelték néhány teszttel, itt bedobták egy Kubernetes clusterbe, ami többé-kevésbé hasonló. gyártásba, majd hirtelen elkezdték a terheléses tesztelést.
Ez némileg a Pac-Man játékra emlékeztet – a műtárgy valamilyen történeten megy keresztül. Ugyanakkor fontos ellenőrizni, hogy a kód valóban átmegy-e a történeten, és hogy kapcsolódik-e valamilyen módon az Ön produkciójához. A gyártásból származó történetek belerángathatók a Continuous Delivery folyamatba: így volt, amikor valami leesett, most programozzuk be ezt a forgatókönyvet a rendszeren belül. Minden alkalommal, amikor a kód átmegy ezen a forgatókönyvön, akkor legközelebb nem fog találkozni ezzel a problémával. Sokkal hamarabb értesül róla, mint ahogy az ügyfeléhez eljut.
Különböző telepítési stratégiák. Például AB-tesztelést vagy Canary-telepítéseket használ a kód különböző klienseken történő tesztelésére, a kód működésével kapcsolatos információk megszerzésére, és sokkal korábban, mint amikor 100 millió felhasználóra terjesztik.
A „következetesen szállít” így néz ki.
A Dev, CI, Test, PreProd, Prod szállítási folyamat nem különálló környezet, ezek tűzálló összegekkel rendelkező szakaszok vagy állomások, amelyeken áthalad a műtermék.
Ha van olyan infrastruktúra kódja, amelyet Base Service APP-ként írnak le, akkor ez segít ne felejtsd el az összes forgatókönyvet, és írja le őket ennek a műterméknek a kódjaként, műtárgy népszerűsítése és menet közben változtasd meg.
Önellenőrző kérdések
Az esetek 95%-ában a funkció leírásától a gyártásba kerülésig eltelt idő kevesebb, mint egy hét? Javul a műtárgy minősége a csővezeték minden szakaszában? Van olyan történet, amin keresztül megy? Használ különböző telepítési stratégiákat?
Ha minden válasz igen, akkor hihetetlenül jófej vagy! Írja meg válaszait a megjegyzésekben - örülök).
Visszacsatolás
Ez a legnehezebb gyakorlat az összes közül. A DevOpsConf konferencián egy Infobip-es kolléga, aki erről beszélt, kissé megzavarodott a szavaiban, mert ez tényleg egy nagyon összetett gyakorlat arról, hogy mindent figyelni kell!
Például nagyon régen, amikor a Qiknél dolgoztam, és rájöttünk, hogy mindent ellenőriznünk kell. Ezt meg is tettük, és most 150 000 tételünk van a Zabbixban, amelyeket folyamatosan figyelünk. Ijesztő volt, a műszaki igazgató a halántékára csavarta az ujját:
- Srácok, miért erőszakoljátok meg a szervert valami homályos dologgal?
De aztán történt egy incidens, amely megmutatta, hogy ez valóban nagyon klassz stratégia.
Az egyik szolgáltatás folyamatosan lefagyott. Kezdetben nem omlott le, ami érdekes, a kód nem került oda, mert egy alap bróker volt, aminek gyakorlatilag semmi üzleti funkciója nem volt - egyszerűen csak üzeneteket küldött az egyes szolgáltatások között. A szolgáltatás 4 hónapig nem változott, és hirtelen elkezdett összeomlani a „Szegmentációs hiba” hibával.
Megdöbbentünk, megnyitottuk a grafikonjainkat a Zabbixban, és kiderült, hogy másfél hete az API-szolgáltatásban, amelyet ez a bróker használ, nagyon megváltozott a kérések viselkedése. Ezután azt láttuk, hogy megváltozott egy bizonyos típusú üzenet küldésének gyakorisága. Később rájöttünk, hogy ezek androidos kliensek. Megkérdeztük:
- Srácok, mi történt veletek másfél hete?
Válaszul egy érdekes történetet hallottunk arról, hogyan alakították át a felhasználói felületet. Nem valószínű, hogy bárki azonnal azt mondja, hogy megváltoztatta a HTTP könyvtárat. Az Android kliensek számára ez olyan, mintha szappant cserélnének a fürdőszobában – egyszerűen nem emlékeznek. Ennek eredményeként 40 perces beszélgetés után rájöttünk, hogy megváltoztatták a HTTP-könyvtárat, és megváltoztak az alapértelmezett időzítések. Ez az API szerver forgalmi viselkedésének megváltozásához vezetett, ami olyan helyzethez vezetett, amely versenyt okozott a brókeren belül, és az összeomlott.
Mély ellenőrzés nélkül ezt általában lehetetlen megnyitni. Ha a szervezetnél még mindig ott van a „kút” problémája, amikor mindenki egymásnak dobálja a pénzt, ez évekig élhet. Egyszerűen indítsa újra a szervert, mert lehetetlen megoldani a problémát. Amikor figyeled, nyomon követed, nyomon követed az összes eseményed, amivel rendelkezel, és tesztelésként használod a monitorozást – írj kódot és azonnal jelezd, hogyan kell figyelni, akár kód formájában is (az infrastruktúra kódként már megvan), minden világossá válik, a tenyéren. Még az ilyen összetett problémák is könnyen nyomon követhetők.
Gyűjtsön össze minden információt arról, hogy mi történik a műtermékkel a szállítási folyamat minden szakaszában – nem a gyártás során.
Töltsd fel a monitorozást a CI-re, és ott máris látható lesz néhány alapvető dolog. Később látni fogja őket a Test, a PredProd és a terhelési tesztelésben. Gyűjtsön információkat minden szakaszban, nem csak a mutatókat, statisztikákat, hanem naplókat is: az alkalmazás megjelenési módja, anomáliák - gyűjtsön össze mindent.
Ellenkező esetben nehéz lesz kitalálni. Már mondtam, hogy a DevOps összetettebb. Ahhoz, hogy megbirkózzon ezzel a bonyolultsággal, normál elemzésre van szüksége.
Kérdések az önkontrollhoz
Az Ön monitorozása és naplózása a fejlesztési eszköz az Ön számára? Amikor kódot ír, a fejlesztői, köztük Ön is, gondolnak-e arra, hogyan figyeljék azt?
Hallott-e problémákról az ügyfelektől? Jobban megérti az ügyfelet a megfigyelésből és a naplózásból? A megfigyelésből és naplózásból jobban megérted a rendszert? Csak azért változtat a rendszeren, mert látta, hogy a rendszerben a tendencia növekszik, és megérti, hogy további 3 hét múlva minden meghal?
Ha ez a három összetevő megvan, elgondolkodhat azon, hogy milyen infrastrukturális platformmal rendelkezik a cégében.
Infrastruktúra platform
A lényeg nem az, hogy minden vállalatnál különböző eszközökről van szó.
Az infrastrukturális platform lényege, hogy minden csapat használja ezeket az eszközöket és közösen fejleszti azokat.
Nyilvánvaló, hogy külön csapatok vannak, amelyek az infrastruktúra-platform egyes részeinek fejlesztéséért felelősek. Ugyanakkor minden mérnök felelősséget visel az infrastruktúra-platform fejlesztéséért, teljesítményéért és népszerűsítéséért. Belső szinten általános eszközzé válik.
Minden csapat fejleszti az infrastrukturális platformot, és gondosan kezeli saját IDE-ként. Az IDE-ben különféle bővítményeket telepít, hogy minden szép és gyors legyen, és konfigurálja a gyorsbillentyűket. Amikor megnyitod a Sublime, Atom vagy a Visual Studio Code-ot, özönlenek a kódhibák, és rájössz, hogy egyáltalán nem lehet dolgozni, azonnal elszomorodsz, és rohansz megjavítani az IDE-t.
Ugyanígy kezelje infrastrukturális platformját. Ha megérti, hogy valami nem stimmel, akkor hagyjon fel egy kérést, ha nem tudja saját maga megjavítani. Ha van valami egyszerű, szerkessze saját maga, küldjön lehúzási kérelmet, a srácok megfontolják és hozzáadják. Ez egy kicsit más megközelítés a mérnöki eszközökhöz a fejlesztő fejében.
Az infrastruktúra platform biztosítja a műtárgy átvitelét a fejlesztésből a kliensbe a minőség folyamatos javításával. Az IP-cím egy sor történettel van programozva, amelyek az éles kóddal történnek. A fejlesztési évek során rengeteg ilyen történet született, némelyikük egyedi, és csak Önre vonatkozik – nem lehet Google-be keresni.
Ezen a ponton az infrastrukturális platform az Ön versenyelőnyévé válik, mert van benne valami, ami nincs benne a versenytárs eszközében. Minél mélyebb az IP-je, annál nagyobb a versenyelőnye a piacra jutási idő tekintetében. Itt jelenik meg szállítózár probléma: Elfogadhatja valaki más platformját, de valaki más tapasztalatait felhasználva nem fogja megérteni, mennyire releváns az Ön számára. Igen, nem minden cég tud olyan platformot építeni, mint az Amazon. Ez egy nehéz sor, ahol a cég tapasztalatai relevánsak a piaci pozíció szempontjából, és ott nem lehet szállítói zárat használni. Ezt is fontos átgondolni.
A rendszer
Ez egy infrastruktúra-platform alapdiagramja, amely segít beállítani az összes gyakorlatot és folyamatot egy DevOps vállalatnál.
Nézzük, miből áll.
Erőforrás hangszerelési rendszer, amely CPU-t, memóriát, lemezt biztosít az alkalmazásokhoz és egyéb szolgáltatásokhoz. Ennek a tetején - alacsony szintű szolgáltatások: figyelés, naplózás, CI/CD motor, műtermék tárolás, infrastruktúra rendszerkódként.
Magasabb szintű szolgáltatások: adatbázis, mint szolgáltatás, sorok, mint szolgáltatás, Load Balance, mint szolgáltatás, képméretezés, mint szolgáltatás, Big Data factory, mint szolgáltatás. Ennek a tetején - folyamat, amely folyamatosan módosított kódot szállít az ügyfélnek.
Információkat kap arról, hogyan működik a szoftvere a kliens számára, megváltoztatja azt, újra megadja ezt a kódot, információkat kap – és így folyamatosan fejleszti mind az infrastruktúra platformját, mind a szoftverét.
Az ábrán a szállítási csővezeték több szakaszból áll. De ez egy sematikus diagram, amelyet példaként adunk meg - nem kell egyenként megismételni. A szakaszok úgy lépnek kapcsolatba a szolgáltatásokkal, mintha szolgáltatások lennének – a platform minden egyes eleme magában hordozza a saját történetét: hogyan történik az erőforrások elosztása, az alkalmazás elindítása, az erőforrásokkal való együttműködés, a figyelés és a változások.
Fontos megérteni, hogy a platform minden része egy történetet hordoz, és kérdezd meg magadtól, milyen történetet hordoz ez a tégla, esetleg ki kell dobni, és egy harmadik féltől származó szolgáltatásra kell cserélni. Lehet-e például tégla helyett Okmetert beépíteni? Talán a srácok már sokkal jobban kifejlesztették ezt a szakértelmet, mint mi. De lehet, hogy nem – talán egyedülálló szakértelemmel rendelkezünk, telepítenünk kell a Prometheust és tovább kell fejlesztenünk.
A platform létrehozása
Ez egy összetett kommunikációs folyamat. Ha megvan az alapgyakorlat, kommunikációba kezd a különböző mérnökök és szakemberek között, akik követelményeket és szabványokat dolgoznak ki, és folyamatosan módosítják azokat különböző eszközökre és megközelítésekre. A DevOps kultúrája itt fontos.
A kultúrával minden nagyon egyszerű - az együttműködésről és a kommunikációról szól, vagyis az egymással közös munkavégzés vágya, egy hangszer együtt forgatásának vágya. Itt nincs rakétatudomány - minden nagyon egyszerű, banális. Például mindannyian a bejáratban élünk, és tisztán tartjuk – ez a kultúra ilyen szintű.
Mid van?
Ismét kérdések, amelyeket feltehet magának.
Az infrastrukturális platform dedikált? Ki a felelős a fejlesztéséért? Megérti infrastrukturális platformja versenyelőnyeit?
Folyamatosan fel kell tenned magadnak ezeket a kérdéseket. Ha valamit át lehet vinni harmadik fél szolgáltatásaira, akkor azt át kell vinni; ha egy harmadik féltől származó szolgáltatás elkezdi blokkolni a mozgását, akkor rendszert kell felépítenie magában.
Szóval DevOps...
... ez egy összetett rendszer, a következőkkel kell rendelkeznie:
- Digitális termék.
- Üzleti modulok, amelyek ezt a digitális terméket fejlesztik.
- Termékcsoportok, amelyek kódot írnak.
- Folyamatos szállítási gyakorlatok.
- Platformok, mint szolgáltatás.
- Az infrastruktúra mint szolgáltatás.
- Az infrastruktúra kódként.
- Külön gyakorlatok a megbízhatóság fenntartására, beépítve a DevOps-ba.
- Egy visszacsatolási gyakorlat, amely mindent leír.
Ezt a diagramot használhatja, kiemelve benne azt, ami valamilyen formában már megvan a cégében: kialakult-e vagy még fejlesztésre szorul.
Pár hét múlva vége lesz . a RIT++ részeként. Gyere el a konferenciára, ahol sok klassz riportot találsz a folyamatos szállításról, az infrastruktúráról mint kódról és a DevOps átalakításról. , az utolsó árhatáridő május 20
Forrás: will.com