Anton Weiss, az Otomato Software alapítója és igazgatója, az első izraeli DevOps tanúsítás egyik kezdeményezője és oktatója beszélt a tavalyi a káoszelméletről és a káoszmérnökség főbb elveiről, valamint elmagyarázta, hogyan működik a jövő ideális DevOps-szervezete.
Elkészítettük a jelentés szöveges változatát.
Jó reggelt!
DevOpsDays Moszkvában már második éve, ez a második alkalom ezen a színpadon, sokan közületek másodszor vagytok ebben a teremben. Mit jelent? Ez azt jelenti, hogy a DevOps mozgalom Oroszországban növekszik, szaporodik, és ami a legfontosabb, ez azt jelenti, hogy eljött az idő, hogy beszéljünk arról, mi is a DevOps 2018-ban.
Tegye fel a kezét, aki szerint a DevOps 2018-ban már szakma? Vannak ilyenek. Vannak olyan DevOps mérnökök a szobában, akiknek a munkaköri leírása szerint „DevOps mérnök”? Vannak DevOps-menedzserek a szobában? Nincs ilyen. DevOps építészek? Szintén nem. Nem elég. Tényleg igaz, hogy senki sem mondja, hogy DevOps mérnök?
Szóval a legtöbben azt gondoljátok, hogy ez antiminta? Hogy ilyen szakma ne létezzen? Gondolhatunk, amit csak akarunk, de miközben gondolkodunk, az iparág ünnepélyesen halad előre a DevOps trombita hangja mellett.
Ki hallott már a DevDevOps nevű új témáról? Ez egy új technika, amely hatékony együttműködést tesz lehetővé a fejlesztők és a fejlesztők között. És nem is annyira új. A Twitterből ítélve már 4 éve elkezdtek erről beszélni. Mostanáig pedig egyre nő az érdeklődés ez iránt, vagyis van egy probléma. A problémát meg kell oldani.
Kreatív emberek vagyunk, nem csak pihenünk. Azt mondjuk: a DevOps nem elég átfogó szó, mégis hiányzik belőle mindenféle, érdekes elem. És elmegyünk titkos laboratóriumainkba, és elkezdünk érdekes mutációkat előállítani: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
A logika vaskalapos, nem? Szállítási rendszerünk nem működőképes, rendszereink instabilok és felhasználóink elégedetlenek, nincs időnk a szoftvereket időben kihelyezni, nem férünk bele a költségvetésbe. Hogyan fogjuk mindezt megoldani? Majd kitalálunk egy új szót! "Ops" lesz a vége, és a probléma megoldódott.
Tehát ezt a megközelítést úgy hívom: "Op, és a probléma megoldódott."
Mindez háttérbe szorul, ha emlékeztetjük magunkat, hogy miért is jutottunk ehhez az egészhez. Ezt az egész DevOps dolgot azért találtuk ki, hogy a szoftverszállítást és a saját munkánkat ebben a folyamatban a lehető legakadálytalanabbá, fájdalommentesebbé, hatékonyabbá és legfőképpen élvezetesebbé tegyük.
A DevOps a fájdalomtól nőtt ki. És belefáradtunk a szenvedésbe. És hogy mindez megtörténjen, örökzöld gyakorlatokra támaszkodunk: hatékony együttműködésre, áramlási gyakorlatokra, és ami a legfontosabb, rendszeres gondolkodásra, mert enélkül nem működik a DevOps.
Mi az a rendszer?
És ha már rendszergondolkodásról beszélünk, emlékeztessük magunkat, mi is az a rendszer.
Ha forradalmi hacker vagy, akkor számodra a rendszer egyértelműen gonosz. Ez egy felhő, amely feletted lóg, és olyan dolgokra kényszerít, amelyeket nem akarsz.
A rendszergondolkodás szempontjából a rendszer részekből álló egész. Ebben az értelemben mindegyikünk egy rendszer. A szervezetek, amelyekben dolgozunk, rendszerek. És amit te és én építünk, azt rendszernek nevezzük.
Mindez egyetlen nagy társadalmi-technológiai rendszer része. És csak akkor tudunk igazán optimalizálni valamit ebben a kérdésben, ha megértjük, hogyan működik együtt ez a társadalmi-technológiai rendszer.
A rendszerszemléletű gondolkodás szempontjából egy rendszernek számos érdekes tulajdonsága van. Először is részekből áll, ami azt jelenti, hogy viselkedése az alkatrészek viselkedésétől függ. Sőt, minden része egymásra utal. Kiderült, hogy minél több részből áll egy rendszer, annál nehezebb megérteni vagy előre jelezni a viselkedését.
Viselkedési szempontból van még egy érdekes tény. A rendszer képes olyasmire, amire egyetlen része sem képes.
Ahogy Dr. Russell Ackoff (a rendszergondolkodás egyik megalapítója) mondta, ezt meglehetősen könnyű egy gondolatkísérlet segítségével bizonyítani. Például ki tudja a teremből kódot írni? Sok a kéz, és ez normális, mert ez az egyik fő követelmény a szakmánkkal szemben. Tudsz írni, de a kezed külön írhat kódot tőled? Vannak, akik azt mondják: „Nem a kezem írja a kódot, hanem az agyam írja a kódot.” Az agyad képes külön kódot írni tőled? Nos, valószínűleg nem.
Az agy egy csodálatos gép, még 10%-át sem tudjuk, hogyan működik ott, de nem tud külön működni a testünk rendszerétől. És ezt könnyű bebizonyítani: nyissa ki a koponyáját, vegye ki az agyát, tegye a számítógép elé, hadd próbáljon meg valami egyszerűt írni. „Hello, world” például Pythonban.
Ha egy rendszer képes olyasmire, amit külön-külön egyik része sem, akkor ez azt jelenti, hogy viselkedését nem a részek viselkedése határozza meg. Akkor mi határozza meg? E részek közötti kölcsönhatás határozza meg. És ennek megfelelően minél több rész, minél bonyolultabb a kölcsönhatás, annál nehezebb megérteni és előre jelezni a rendszer viselkedését. Ez pedig kaotikussá teszi egy ilyen rendszert, mert a rendszer bármely részének bármilyen, még a legjelentéktelenebb, láthatatlan változása is teljesen kiszámíthatatlan eredményekhez vezethet.
Ezt a kezdeti körülményekre való érzékenységet először Ed Lorenz amerikai meteorológus fedezte fel és tanulmányozta. Később ezt „pillangó-effektusnak” nevezték el, és a tudományos gondolkodás „káoszelméletének” nevezett mozgalmának kialakulásához vezetett. Ez az elmélet a 20. századi tudomány egyik fő paradigmaváltásává vált.
Káoszelmélet
A káoszt tanulmányozó emberek káoszológusnak nevezik magukat.
Valójában ennek a jelentésnek az volt az oka, hogy bonyolult elosztott rendszerekkel és nagy nemzetközi szervezetekkel dolgozva egy bizonyos ponton rájöttem, hogy én is így érzem magam. Én káoszológus vagyok. Ez alapvetően egy okos módja annak, hogy kimondja: „Nem értem, mi folyik itt, és nem tudom, mit csináljak vele.”
Azt hiszem, sokan közületek is gyakran érzitek így, tehát káoszológusok is vagytok. Meghívlak a káoszológusok céhébe. Azokat a rendszereket, amelyeket Ön és én, kedves káoszológus kollégák, tanulmányozni fogunk, „komplex adaptív rendszereknek” nevezzük.
Mi az alkalmazkodóképesség? Az alkalmazkodóképesség azt jelenti, hogy egy ilyen adaptív rendszerben a részek egyéni és kollektív viselkedése megváltozik és önszerveződik, reagálva a rendszer eseményeire vagy mikroesemények láncolatára. Vagyis a rendszer önszerveződéssel alkalmazkodik a változásokhoz. Ez az önszerveződési képesség pedig a szabad autonóm ágensek önkéntes, teljesen decentralizált együttműködésén alapul.
Az ilyen rendszerek másik érdekes tulajdonsága, hogy szabadon skálázhatók. Ami minket, káoszológusokat-mérnököket kétségtelenül érdekel. Tehát, ha azt mondjuk, hogy egy összetett rendszer viselkedését a részeinek kölcsönhatása határozza meg, akkor mire kell kíváncsi? Kölcsönhatás.
Van még két érdekes megállapítás.
Először is megértjük, hogy egy összetett rendszert nem lehet egyszerűsíteni a részeinek egyszerűsítésével. Másodszor, egy összetett rendszer egyszerűsítésének egyetlen módja a részei közötti kölcsönhatások egyszerűsítése.
Hogyan lépünk kapcsolatba? Te és én mindannyian egy emberi társadalomnak nevezett nagy információs rendszer részei vagyunk. Egy közös nyelven keresztül kommunikálunk, ha van, ha megtaláljuk.
De a nyelv maga egy összetett adaptív rendszer. Ennek megfelelően a hatékonyabb és egyszerűbb interakció érdekében valamilyen protokollt kell létrehoznunk. Vagyis valamilyen szimbólum- és cselekvéssor, amely egyszerűbbé, kiszámíthatóbbá, érthetőbbé teszi a köztünk folyó információcserét.
Azt akarom mondani, hogy a komplexitás, az alkalmazkodóképesség, a decentralizáció, a káosz irányába mutató tendenciák mindenben nyomon követhetők. És azokban a rendszerekben, amelyeket te és én építünk, és azokban a rendszerekben, amelyeknek mi is a részei vagyunk.
És hogy ne legyünk alaptalanok, nézzük meg, hogyan változnak az általunk létrehozott rendszerek.
Ezt a szót vártad, értem. Egy DevOps konferencián vagyunk, ma vagy százezerszer elhangzik majd ez a szó, aztán éjjel álmodni fogunk róla.
A mikroszolgáltatások az első olyan szoftverarchitektúra, amely a DevOps gyakorlataira reagálva jelent meg, és amelynek célja, hogy rendszereinket rugalmasabbá, skálázhatóbbá és folyamatosabbá tegye. Hogy csinálja ezt? A szolgáltatások mennyiségének csökkentésével, a szolgáltatások által feldolgozott problémák körének csökkentésével, a szállítási idő csökkentésével. Vagyis csökkentjük és egyszerűsítjük a rendszer részeit, növeljük a számukat, és ennek megfelelően változatlanul növekszik ezen részek közötti interakciók bonyolultsága, vagyis új problémák merülnek fel, amelyeket meg kell oldanunk.
A mikroszolgáltatásoknak még nincs vége, a mikroszolgáltatásoknak általában már tegnap, mert jön a Serverless. Minden szerver leégett, se szerver, se operációs rendszer, csak tiszta futtatható kód. A konfigurációk különállóak, az állapotok különállóak, mindent az események irányítanak. Szépség, tisztaság, csend, semmi esemény, nem történik semmi, teljes rend.
Hol itt a komplexitás? A nehézség természetesen az interakciókban van. Mennyire képes egy függvény önmagában? Hogyan működik együtt más funkciókkal? Üzenetsorok, adatbázisok, egyensúlyozók. Hogyan lehet újra létrehozni valamilyen eseményt hiba esetén? Sok kérdés és kevés válasz.
A mikroszolgáltatásokat és a szerver nélkülieket mi, geek hipszterek Cloud Native-nek hívják. Minden a felhőről szól. De a felhő méretezhetősége is eredendően korlátozott. Megszoktuk, hogy elosztott rendszernek gondoljuk. Valójában hol élnek a felhőszolgáltatók szerverei? Adatközpontokban. Vagyis van itt egyfajta központosított, nagyon korlátozott, elosztott modellünk.
Ma már tudjuk, hogy a tárgyak internete már nem csak nagy szó, hogy szerény jóslatok szerint is internethez kapcsolódó eszközök milliárdjai várnak ránk a következő öt-tíz évben. Hatalmas mennyiségű hasznos és haszontalan adat, amelyet a felhőbe egyesítenek és a felhőből töltenek fel.
A felhő nem fog kitartani, ezért egyre gyakrabban beszélünk az úgynevezett élszámításról. Illetve szeretem a „köd számítástechnika” csodálatos definícióját is. A romantika és a titokzatosság miszticizmusába burkolózva.
Köd számítás. A lényeg az, hogy a felhők vízből, gőzből, jégből és kövekből álló központosított csomók. A köd pedig vízcseppek, amelyek szétszóródnak körülöttünk a légkörben.
A köd paradigmában a munka nagy részét ezek a cseppek teljesen önállóan vagy más cseppekkel együttműködve végzik. És csak akkor fordulnak a felhő felé, ha nagyon megszorulnak.
Vagyis megint decentralizáció, autonómia, és persze sokan már értitek, hogy hova vezet mindez, mert nem beszélhetünk decentralizációról a blokklánc említése nélkül.
Vannak, akik hisznek, ezek azok, akik kriptovalutába fektettek be. Van, aki hisz, de fél, mint például én. És vannak, akik nem hisznek. Itt másképp lehet bánni. Van technológia, új ismeretlen ügy, vannak problémák. Mint minden új technológia, ez is több kérdést vet fel, mint amennyi választ ad.
A blokklánc körüli hype érthető. Az aranylázat félretéve, maga a technológia figyelemre méltó ígéreteket rejt a szebb jövő felé: több szabadság, több autonómia, megosztott globális bizalom. Mit ne akarjunk?
Ennek megfelelően világszerte egyre több mérnök kezd decentralizált alkalmazások fejlesztésébe. És ez egy olyan erő, amelyet nem lehet figyelmen kívül hagyni azzal, hogy egyszerűen azt mondod: "Ahh, a blokklánc csak egy rosszul megvalósított elosztott adatbázis." Vagy ahogy a szkeptikusok mondják: „A blokkláncnak nincsenek valódi alkalmazásai.” Ha belegondolunk, 150 évvel ezelőtt ugyanezt mondták az elektromosságról. És még bizonyos tekintetben igazuk is volt, mert amit ma az elektromosság lehetővé tesz, az semmiképpen nem volt lehetséges a 19. században.
Egyébként ki tudja, milyen logó van a képernyőn? Ez a Hyperledger. Ez egy olyan projekt, amelyet a The Linux Foundation égisze alatt fejlesztenek, és egy sor blokklánc-technológiát tartalmaz. Ez valóban a nyílt forráskódú közösségünk erőssége.
Chaos Engineering
Tehát a rendszer, amelyet fejlesztünk, egyre bonyolultabbá, egyre kaotikusabbá és egyre jobban alkalmazkodóbbá válik. A Netflix a mikroszolgáltatási rendszerek úttörője. Ők az elsők között értették ezt meg, kifejlesztettek egy olyan eszközkészletet, amelyet Simian Army-nak neveztek, amelyek közül a leghíresebb a . Meghatározta, hogy miként vált ismertté .
Mellesleg, a jelentés kidolgozása során még ezt a szöveget is lefordítottuk oroszra, úgyhogy menjen ide , olvasni, kommentelni, szidni.
Röviden, a káoszmérnöki elvek a következőket mondják. Az összetett elosztott rendszerek eleve kiszámíthatatlanok és eredendően hibásak. A hibák elkerülhetetlenek, ami azt jelenti, hogy el kell fogadnunk ezeket a hibákat, és teljesen más módon kell dolgoznunk ezekkel a rendszerekkel.
Nekünk is meg kell próbálnunk ezeket a hibákat bevezetni a termelési rendszereinkbe, hogy teszteljük rendszereinket ugyanerre az alkalmazkodóképességre, éppen erre az önszerveződő képességre, a túlélésre.
És ez mindent megváltoztat. Nemcsak azt, hogy miként indítjuk el a rendszereket a termelésben, hanem azt is, hogyan fejlesztjük, hogyan teszteljük. Nincs a kód stabilizálásának vagy lefagyásának folyamata, éppen ellenkezőleg, állandó a destabilizációs folyamat. Megpróbáljuk megölni a rendszert, és látni, hogy továbbra is fennmarad.
Elosztott rendszerintegrációs protokollok
Ennek megfelelően ehhez valamilyen módon meg kell változniuk a rendszereinken. Ahhoz, hogy stabilabbá váljanak, új protokollokra van szükségük a részeik közötti interakcióhoz. Hogy ezek a részek megegyezzenek és valamiféle önszerveződéshez jussanak. És mindenféle új eszköz, új protokoll keletkezik, amelyeket én „elosztott rendszerek interakciójának protokolljainak” nevezek.
miről beszélek? Először is a projekt . Vannak, akik megpróbálnak létrehozni egy általános elosztott nyomkövetési protokollt, amely abszolút nélkülözhetetlen eszköz az összetett elosztott rendszerek hibakereséséhez.
Tovább - . Azt mondjuk, hogy nem tudjuk megjósolni, hogy mi lesz a rendszerrel, vagyis növelni kell a megfigyelhetőségét, megfigyelhetőségét. Az Opentracing olyan eszközök családjába tartozik, amelyek megfigyelhetőséget biztosítanak rendszereink számára. De megfigyelhetőségre van szükségünk annak meghatározásához, hogy a rendszer úgy viselkedik-e, ahogyan elvárjuk, vagy sem. Hogyan határozzuk meg az elvárt viselkedést? Valamiféle politika, valamilyen szabályrendszer meghatározásával. Az Open Policy Agent projekt azon dolgozik, hogy meghatározza ezt a szabálykészletet a hozzáféréstől az erőforrás-elosztásig terjedő spektrumban.
Mint mondtuk, rendszereink egyre inkább eseményközpontúak. A szerver nélküli az eseményvezérelt rendszerek nagyszerű példája. Ahhoz, hogy az eseményeket a rendszerek között át tudjuk vinni és követni tudjuk, szükségünk van valamilyen közös nyelvre, közös protokollra, hogy hogyan beszélünk az eseményekről, hogyan továbbítjuk azokat egymásnak. Ezt hívják egy projektnek .
A rendszereinket folyamatosan destabilizáló változások folyamatos folyama szoftveres műtermékek folyamatos folyama. Ahhoz, hogy ezt az állandó változási áramlást fenntarthassuk, szükségünk van valamiféle közös protokollra, amelyen keresztül beszélhetünk arról, hogy mi az a szoftvertermék, hogyan tesztelik, milyen ellenőrzésen ment át. Ezt hívják egy projektnek . Vagyis a szoftverműtermékek közös metaadat-protokollja.
És végül, ha azt akarjuk, hogy rendszereink teljesen függetlenek, adaptívak és önszerveződjenek, meg kell adnunk nekik az önazonosítás jogát. A projekt neve Pontosan ezt teszi. Ez is egy projekt a Cloud Native Computing Foundation égisze alatt.
Mindezek a projektek fiatalok, mindegyiknek szüksége van a szeretetünkre, az érvényesítésünkre. Ez mind nyílt forráskódú, a mi tesztelésünk, a mi megvalósításunk. Megmutatják, merre halad a technológia.
De a DevOps soha nem elsősorban a technológiáról szólt, hanem mindig is az emberek közötti együttműködésről. És ennek megfelelően, ha azt akarjuk, hogy az általunk kifejlesztett rendszerek megváltozzanak, akkor nekünk magunknak kell változnunk. Valójában egyébként is változunk, nincs sok választásunk.
Van egy csodálatos Rachel Botsman brit írónő, amelyben a bizalom fejlődéséről ír az emberiség történelme során. Azt mondja, kezdetben a primitív társadalmakban a bizalom lokális volt, vagyis csak azokban bíztunk, akiket személyesen ismerünk.
Aztán volt egy nagyon hosszú időszak - egy sötét időszak, amikor a bizalom centralizálódott, amikor elkezdtünk megbízni azokban az emberekben, akiket nem ismerünk azon tény alapján, hogy ugyanahhoz a köz- vagy állami intézményhez tartozunk.
És ezt látjuk modern világunkban: a bizalom egyre inkább megoszlik, decentralizálódik, és az információáramlás szabadságán, az információ elérhetőségén alapszik.
Ha belegondolunk, éppen ezt az akadálymentesítést, amely lehetővé teszi ezt a bizalmat, valósítjuk meg Ön és én. Ez azt jelenti, hogy mind az együttműködési módnak, mind pedig annak módjának változnia kell, mert a régi központosított, hierarchikus informatikai szervezetek már nem működnek. Kezdenek kihalni.
A DevOps szervezeti alapjai
A jövő ideális DevOps-szervezete egy decentralizált, adaptív rendszer, amely autonóm csapatokból áll, amelyek mindegyike autonóm egyénekből áll. Ezek a csapatok szétszóródtak a világban, hatékonyan együttműködnek egymással aszinkron kommunikációval, rendkívül átlátható kommunikációs protokollok használatával. Nagyon szép, nem? Nagyon szép jövő.
Természetesen mindez nem lehetséges kulturális változás nélkül. Átalakító vezetéssel, személyes felelősséggel, belső motivációval kell rendelkeznünk.
Ez a DevOps szervezetek alapja: információs átláthatóság, aszinkron kommunikáció, transzformációs vezetés, decentralizáció.
Kiég
A rendszerek, amelyeknek a részesei vagyunk, és amelyeket felépítettünk, egyre kaotikusabbak, és nekünk, embereknek nehéz megbirkózni ezzel a gondolattal, nehéz feladni az irányítás illúzióját. Igyekszünk továbbra is kontrollálni őket, és ez gyakran kiégéshez vezet. Ezt saját tapasztalatból mondom, én is megégtem, engem is rokkant voltam a gyártás előre nem látható kudarcai miatt.
A kiégés akkor következik be, amikor megpróbálunk irányítani valamit, ami eredendően ellenőrizhetetlen. Amikor kiégünk, minden elveszti értelmét, mert elveszítjük a vágyat, hogy valami újat tegyünk, védekezni kezdünk, és elkezdjük megvédeni azt, amink van.
A mérnöki szakma, ahogyan gyakran emlékeztetem magam, mindenekelőtt kreatív szakma. Ha elveszítjük a vágyat, hogy valamit létrehozzunk, akkor hamuvá válunk, hamuvá válunk. Emberek égnek ki, egész szervezetek égnek ki.
Véleményem szerint csak a káosz teremtő erejének elfogadása, csak az együttműködés elvei szerinti építése az, ami segít abban, hogy ne veszítsük el azt, ami a mi szakmánkban jó.
Ezt kívánom neked: szeresse a munkáját, szeresse azt, amit csinálunk. Ez a világ információval táplálkozik, nekünk az a megtiszteltetés, hogy tápláljuk. Tehát tanulmányozzuk a káoszt, legyünk káoszológusok, hozzunk értéket, hozzunk létre valami újat, nos, a problémák, mint már rájöttünk, elkerülhetetlenek, és amikor megjelennek, egyszerűen csak azt mondjuk, hogy „Op!” És a probléma megoldódott.
Mi más, mint a Chaos Monkey?
Valójában ezek a hangszerek olyan fiatalok. Ugyanaz a Netflix épített magának eszközöket. Készítse el saját szerszámait. Olvassa el a káosztervezés alapelveit, és kövesse ezeket az elveket, ahelyett, hogy más eszközöket keresne, amelyeket valaki más már épített.
Próbáld megérteni, hogyan tönkremennek a rendszereid, és kezdd el lebontani őket, és nézd meg, hogyan tartanak fenn. Ez az első. És kereshet eszközöket. Mindenféle projekt létezik.
Nem egészen értettem azt a pillanatot, amikor azt mondtad, hogy a rendszer nem egyszerűsíthető le az összetevőinek egyszerűsítésével, és azonnal áttértem a mikroszolgáltatásokra, amelyek maguk az összetevők egyszerűsítésével és az interakciók bonyolításával egyszerűsítik a rendszert. Ez lényegében két rész, amelyek ellentmondanak egymásnak.
Így van, a mikroszolgáltatások általában nagyon vitatott téma. Valójában az alkatrészek egyszerűsítése növeli a rugalmasságot. Mit nyújtanak a mikroszolgáltatások? Rugalmasságot és gyorsaságot biztosítanak számunkra, de az egyszerűséget biztosan nem. Növelik a nehézséget.
Tehát a DevOps filozófiában a mikroszolgáltatások nem olyan jó dolgok?
Minden jónak van egy másik oldala is. Előnye, hogy növeli a rugalmasságot, lehetővé téve számunkra, hogy gyorsabban változtassunk, de növeli az egész rendszer összetettségét és ezáltal törékenységét.
Mégis, mi a nagyobb hangsúly: az interakció vagy a részek egyszerűsítése?
A hangsúly természetesen az interakciók egyszerűsítésén van, mert ha ezt abból a szempontból nézzük, hogy hogyan dolgozunk veled, akkor mindenekelőtt az interakciók egyszerűsítésére kell figyelnünk, nem pedig a munka egyszerűsítésére. mindegyikünkről külön-külön. Mert a munka leegyszerűsítése azt jelenti, hogy robotokká válunk. Nálunk a McDonald's-ban akkor működik rendesen, ha van instrukciód: ide rakod a hamburgert, ide önted rá a szószt. Ez egyáltalán nem működik a kreatív munkánkban.
Igaz-e, hogy minden, amit mondtál, egy verseny nélküli világban él, és ott olyan kedves a káosz, és ebben a káoszban nincsenek ellentmondások, senki nem akar megenni vagy megölni senkit? Hogyan járjon a verseny és a DevOps?
Nos, ez attól függ, hogy milyen versenyről beszélünk. A munkahelyi vagy a vállalatok közötti versenyről van szó?
A szolgáltatások versenyéről, amelyek azért léteznek, mert a szolgáltatások nem több cégből állnak. Új típusú információs környezetet hozunk létre, és egyetlen környezet sem élhet verseny nélkül. Mindenhol verseny van.
Ugyanaz a Netflix, példaképnek vesszük őket. Miért találták ki ezt? Mert versenyképesnek kell lenniük. Ez a mozgási rugalmasság és gyorsaság éppen a nagyon versenyképes követelmény, ami káoszt hoz rendszereinkbe. Vagyis a káosz nem valami, amit tudatosan teszünk, mert akarjuk, hanem valami, ami azért történik, mert a világ ezt követeli. Csak alkalmazkodnunk kell. A káosz pedig pontosan a verseny eredménye.
Ez azt jelenti, hogy a káosz a célok hiánya? Vagy azok a célok, amelyeket nem akarunk látni? A házban vagyunk, és nem értjük mások céljait. A verseny valójában annak köszönhető, hogy világosak a céljaink, és minden következő pillanatban tudjuk, hova jutunk. Az én nézőpontom szerint ez a DevOps lényege.
Egy pillantást a kérdésre is. Azt hiszem, mindannyiunknak ugyanaz a célja: túlélni és megtenni
legnagyobb öröm. És minden szervezet versenycélja ugyanaz. A túlélés gyakran a versengés révén történik, ez ellen nem tudsz mit tenni.
Az idei konferencia december 7-én kerül sor a Technopolisban. A beszámolókra november 11-ig várjuk a jelentkezéseket. nekünk, ha szeretnél beszélni.
A résztvevők regisztrációja nyitott, a jegyek ára 7000 rubel. Csatlakozz hozzánk!
Forrás: will.com