Az 'Otomato Software' alapítója és igazgatója, Anton Weiss, aki Izrael első DevOps tanúsítványának iniciátorai és oktatói közé tartozik, tavaly beszélt a kaosz elméletéről és a kaosz mérnökség főbb alapelveiről, valamint elmagyarázta, hogyan néz ki a jövő tökéletes DevOps-szervezete.
Elkészült a beszámoló szöveges változata.
Jó reggelt!
A DevOpsDays Moszkvában már második éve zajlik, másodszor vagyok ezen a színpadon, és sokan közülöttetek másodszor vannak ebben a teremben. Mit is jelent ez? Azt, hogy a DevOps mozgalom Oroszországban növekszik, terjed, és ami még fontosabb, itt az idő, hogy beszéljünk arról, mi is a DevOps 2018-ban.
Emelje fel a kezét, aki úgy gondolja, hogy 2018-ban a DevOps már szakma? Vannak ilyenek. Van a teremben DevOps mérnök, akinek a munkaköri leírásában szerepel, hogy 'DevOps mérnök'? Van a teremben DevOps menedzser? Nincsenek. DevOps építészek? Azok sem. Nem sokan vannak. Tényleg senkinél nincs leírva, hogy DevOps mérnök?
Akkor a legtöbben úgy gondolják, hogy ez egy antipattern? Hogy ilyen szakmának nem szabadna léteznie? Gondolhatunk bármit, de míg mi gondolkodunk, az ipar ünnepélyesen halad előre a DevOps harsonájának hangjaira.
Ki hallott az új témáról, amit DevDevOps-nak hívnak? Ez egy új módszer, amely hatékony együttműködést biztosít a fejlesztők és a DevOps szakemberek között. Nem is olyan új. Ha a Twitterre nézünk, 4 évvel ezelőtt már elkezdték ezt tárgyalni. És azóta az érdeklődés folyamatosan nő, tehát a probléma létezik. Ezt a problémát meg kell oldani.
Kreatív emberek vagyunk, nem pihenünk meg olyan könnyen. Azt mondjuk, hogy a DevOps nem elég széleskörű kifejezés, hiányzik belőle még sok érdekes elem. És titkos laboratóriumaikba megyünk, és elkezdjük létrehozni a kíváncsi mutációinkat: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Meglepő logika, ugye? Nem funkcionális a szállítási rendszerünk, instabilak a rendszerek és elégedetlenek a felhasználók, nem tudjuk időben kiadni a szoftvert, nem tartjuk be a költségvetést. Hogyan fogjuk ezt mind megoldani? Kitalálunk egy új szót! Az 'Ops'-ra fog végződni, és a probléma megoldva.
Így hívom ezt a megközelítést - 'Ops, és a probléma megoldva'.
Mindez háttérbe szorul, ha emlékeztetjük magunkat arra, miért találtuk ki mindezt. Azért hoztuk létre ezt a DevOps-t, hogy a szoftverek szállítása és a saját munkánk ebben a folyamatban a lehető legzökkenőmentesebb, fájdalommentes, hatékony, és ami a legfontosabb, kellemes legyen.
A DevOps a fájdalomból született. Elegünk van a szenvedésből. És hogy mindez megtörténhessen, az örökzöld gyakorlatokra építünk: hatékony együttműködés, folyamatgyakorlatok, és ami a legfontosabb, a rendszerszemlélet, mert nélküle nincs DevOps.
Mi az a rendszer?
És ha már a rendszerszemléletnél tartunk, emlékeztessük magunkat arra, mi az a rendszer.
Ha te hackerváltozás vagy, akkor számodra a rendszer egyértelműen rossz. Ez egy felhő, ami a fejed fölött lebeg, és arra kényszerít, hogy azt tedd, amit nem akarsz.
A rendszerszemlélet szempontjából a rendszer egy egész, amely részekből áll. Ebben az értelemben mindannyiunk egy rendszer. Azok a szervezetek, ahol dolgozunk, rendszerek. És amit építünk, az is így hívják — rendszer.
Mindez egy nagy szociotechnikai rendszer része. Csak ha megértjük, hogyan működik együtt ez a szociotechnikai rendszer, akkor tudunk benne valóban optimalizálni valamit.
A rendszerszemlélet szempontjából a rendszernek különféle érdekes tulajdonságai vannak. Először is, részekből áll, ami azt jelenti, hogy a viselkedése függ a részek viselkedésétől. Ráadásul minden rész is kölcsönösen függ egymástól. Így minél több része van a rendszernek, annál nehezebb megérteni vagy megjósolni a viselkedését.
A viselkedés szempontjából még egy érdekes tény van. A rendszer képes olyasmit tenni, amit egyetlen egy rész sem tud megtenni.
Ahogy Dr. Russell Ackoff (a rendszerszemlélet egyik megalapozója) mondta, ezt elég könnyen be lehet bizonyítani egy gondolatkísérlettel. Például, ki tud itt a teremben kódot írni? Sok kéz, és ez rendben van, mert ez a szakmánk egyik alapkövetelménye. Te tudsz írni, de a kezeid önállóan tudnak kódot írni? Vannak olyanok, akik azt mondják: 'Nekem nem a kezeim írják a kódot, hanem az agyam írja a kódot.' De az agy önállóan tud kódot írni? Nos, valószínűleg nem.
Az agy egy csodálatos gépezet, és még 10%-át sem ismerjük annak, hogyan működik, de önállóan a saját rendszerén, amely a testünk, nem tud működni. Ezt könnyű bizonyítani: nyisd fel a koponyádat, vedd ki az agyadat, tedd egy számítógép elé, és nézd meg, tud-e írni valamit. Például a "Hello, world"-öt Pythonban.
Ha a rendszer képes olyan dolgot végrehajtani, amelyet egyik része sem tudna külön-külön megtenni, akkor azt jelenti, hogy a viselkedését nem a részei meghatározása alakítja. Akkor mi határozza meg? Az interakciók a részek között. Ennek megfelelően, minél több rész van, annál bonyolultabbak az interakciók, annál nehezebb megérteni és előre jelezni a rendszer viselkedését. Ez a rendszer kaotikussá válik, mert bármilyen apró, a szemen láthatatlan változás bármelyik részében teljesen kiszámíthatatlan eredményeket produkálhat.
Ez a kezdeti feltételekre való érzékenység először Ed Lorenz amerikai meteorológus által lett felfedezve és kutatva. Később a "pillangóhatás" néven vált ismertté, és egy olyan tudományos irányzat fejlődéséhez vezetett, amelyet "káoszelméletnek" neveznek. Ez az elmélet a 20. századi tudomány egyik alapvető paradigmaváltását jelentette.
Káoszelmélet
Azok az emberek, akik a káosz tanulmányozásával foglalkoznak, káoszológusoknak nevezik magukat.
A jelentésem valós okát az adja, hogy miközben bonyolult elosztott rendszerekkel és nagy nemzetközi szervezetekkel dolgoztam, egy időpontban rájöttem, hogy ez az, aki vagyok. Én egy káoszológus vagyok. Ez egy ügyes módja annak, hogy azt mondjam: "Nem értem, mi történik itt, és nem tudom, mit kezdjek ezzel."
Azt gondolom, hogy sokan közületek is gyakran érzik így magukat, tehát ti is káoszológusok vagytok. Meghívlak benneteket a káoszológusok céhébe. Azok a rendszerek, amelyeket mi, kedves kollégák, káoszológusok fogunk tanulmányozni, "bonyolult adaptív rendszerek".
Mi az alkalmazkodóképesség? Az alkalmazkodóképesség azt jelenti, hogy az egyéni és kollektív viselkedés elemei egy ilyen alkalmazkodó rendszeren belül megváltozik és önszerveződik, reagálva a rendszeren belüli eseményekre vagy eseményláncokra. Tehát a rendszer alkalmazkodik a változásokhoz önszerveződés révén. Ez az önszerveződési képesség pedig a szabad autonóm ügynökök önkéntes, teljesen decentralizált együttműködésén alapul.
Egy másik érdekes tulajdonsága ezeknek a rendszereknek, hogy szabadon skálázhatók. Ami minket, mint káoszkutató mérnököket, kétségtelenül érdekel. Tehát ha azt mondtuk, hogy egy komplex rendszer viselkedését annak részeinek kölcsönhatása határozza meg, akkor mi az, ami érdeklődésünket felkelti? A kölcsönhatás.
Még két érdekes következtetés van.
Először is, megértjük, hogy egy komplex rendszert lehetetlen egyszerűsíteni a részei leegyszerűsítésével. Másodszor, az egyetlen módja annak, hogy egy komplex rendszert leegyszerűsítsünk, az a kölcsönhatások egyszerűsítése a részei között.
Hogyan lépünk interakcióba? Mindannyian egy nagy információs rendszer, az emberi társadalom részei vagyunk. Közös nyelv révén lépünk kapcsolatba, ha van, ha megtaláljuk.
De a nyelv önmagában is egy összetett alkalmazkodó rendszer. Ennek megfelelően a hatékonyabb és egyszerűbb interakcióhoz bizonyos protokollok létrehozása szükséges. Tehát egyfajta szimbolikus sorozatra és cselekvésre, amely megkönnyíti az információcserét közöttünk, van szükség.
Azt szeretném mondani, hogy a bonyolultság, az alkalmazkodóképesség, a decentralizáció és a káosz felé mutató tendenciák mindenen nyomon követhetők. Akár azokon a rendszereken is, amelyeket mi építünk, akár azokban a rendszerekben, amelyeknek mi is részei vagyunk.
Annak érdekében, hogy ne legyek alaptalan, nézzük meg, hogyan változnak azok a rendszerek, amelyeket létrehozunk.
Megértem, hogy vártad ezt a szót. DevOps konferencián vagyunk, és ma ezt a szót valahol százezer alkalommal fogják mondani, aztán álmainkban is ez fog megjelenni.
A mikroszolgáltatások az első szoftverarchitektúrák, amelyek a DevOps gyakorlatokra adott válaszként jelentek meg, céljuk, hogy rugalmasabbá, skálázhatóbbá tegyék rendszereinket és biztosítsák a folyamatos szállítást. Hogyan érik el mindezt? A szolgáltatások volumenének csökkentésével, a problémák határainak csökkentésével, amelyeket ezek a szolgáltatások kezelnek, és a szállítási idő csökkentésével. Vagyis egyszerűsítjük a rendszer egyes részeit, növeljük az azok számát, ennek következtében pedig a köztük lévő interakciók bonyolultsága elkerülhetetlenül megnő, így új problémák merülnek fel, amelyeket nekünk kell megoldanunk.
A mikroszolgáltatások még nem a vég, ezek valójában már a tegnap napja, mivel megérkezett a Serverless. Minden szerver elégett, nincsenek szerverek, nincsenek operációs rendszerek, csak tiszta futtatható kód. A konfigurációk külön, az állapotok külön, minden események által van kezelve. Szépség, tisztaság, csend, nincsenek események, semmi nem történik, teljes rend.
Hol rejlik a bonyolultság? A bonyolultság, természetesen, az interakciókban rejlik. Mennyi mindent képes egy funkció önállóan megtenni? Hogyan lép kapcsolatba más funkciókkal? Üzenetsorok, adatbázisok, terheléselosztók. Hogyan lehet újra létrehozni egy eseményt, amikor hiba történik? Sok kérdés, és kevés válasz.
A mikroszolgáltatások és a Serverless mindaz, amit mi, számítástechnikával foglalkozó hipsterek, Cloud Native-nak nevezünk. Minden az cloud-ról szól. De az alapvetően szintén korlátozottan skálázható. Hagyományosan úgy gondoltunk rá, mint egy elosztott rendszerre. Valójában hol találhatók a felhőszolgáltatók szerverei? Adatközpontokban. Vagyis itt van egyfajta központosított, nagyon korlátozott elosztott modell.
Ma már tudjuk, hogy az internet of things nemcsak hangzatos szavak, hanem még a szerény előrejelzések szerint is az elkövetkező öt-tíz évben milliárdnyi eszköz csatlakozik majd az internethez. Határtalan mennyiségű hasznos és értelmetlen adat fog áramlani a felhőbe és onnan vissza.
A felhő nem bírja, ezért egyre inkább a perifériás számításokról beszélünk. Vagy, ahogy egyik kedvelt meghatározásom mondja: „fogs computing”. Ez a romantika és titokzatos mivolt ködébe burkolózik.
Ködös számítási felhők. Itt arról van szó, hogy a felhők központosított víz-, gőz-, jég- és kőzetgömbök. A köd pedig azok a vízcseppek, amelyek szétszóródnak körülöttünk a légkörben.
A ködös paradigmában a munka nagy része ezeken a cseppeken teljesen önállóan vagy más cseppekkel együtt történik. Csak akkor fordulnak a felhőhöz, amikor valóban szükség van rá.
Tehát újra decentralizáció, önállóság, és persze sokan már értik, hová vezet mindez, mert nem lehet a decentralizációról beszélni anélkül, hogy a blokkláncot ne említenénk meg.
Vannak, akik hisznek benne, ők azok, akik befektettek a kriptovalutákba. Vannak, akik hisznek, de félnek, mint például én. És vannak, akik nem hisznek. Erre különböző módon lehet tekinteni. Van technológia, egy új, érthetetlen dolog, vannak problémák. Mint bármely új technológiánál, ez is több kérdést vet fel, mint ahányra válaszokat kínál.
A blokklánc körüli hype érthető. Még ha félre is tesszük az aranylázat, magának a technológiának csodálatos ígéretei vannak a fényes jövőről: több szabadság, több önállóság, globálisan elosztott bizalom. Hát mit ne akarnánk ebből?
Ennek megfelelően egyre több mérnök világszerte kezd decentralizált alkalmazásokat fejleszteni. És ez az az erő, amellyel nem lehet figyelmen kívül hagyni, csak úgy, hogy azt mondjuk: „A blokklánc egyszerűen rosszul megvalósított elosztott adatbázis”. Vagy ahogy a szkeptikusok szeretnek mondani: „A blokkláncnak nincsenek valós alkalmazásai”. Ha belegondolunk, 150 évvel ezelőtt ugyanazt mondták az áramról. És bizonyos értelemben igazuk is volt, mert amit az áram ma lehetővé tesz, az a 19. században teljesen elképzelhetetlen volt.
Egyébként ki tudja, mi a logó a képernyőn? Ez a Hyperledger. Ez egy projekt, amelyet a Linux Alapítvány égisze alatt fejlesztenek, és magában foglal egy blokklánc-technológiákból álló készletet. Ez valóban a nyílt forráskódú közösségünk ereje.
Káosz mérnökség
Tehát az a rendszer, amelyet együtt fejlesztünk, egyre bonyolultabb, egyre kaotikusabb, egyre alkalmazkodóbb. A Netflix a mikroszolgáltatásos rendszerek úttörője. Ők voltak az elsők, akik ezt megértették, és kifejlesztettek egy eszközkészletet, amelyet Simian Army-nek neveztek el, a legismertebb eszköz pedig a . Ő definiálta azt, ami ismertté vált .
Mellesleg, a bemutató összeállítása során még le is fordítottuk ezt a szöveget oroszra, szóval nézzetek be a , olvassátok, kommentáljátok, bíráljátok.
Röviden a zűrzavaros mérnöki elvek a következőt mondják. A komplex elosztott rendszerek lényegüket tekintve kiszámíthatatlanok, és lényegükben hibákat tartalmaznak. A hibák elkerülhetetlenek, ami azt jelenti, hogy el kell fogadnunk ezeket a hibákat, és teljesen másképp kell dolgoznunk ezekkel a rendszerekkel.
Nekünk magunknak kell próbálnunk hibákat behozni a produkciós rendszereinkbe, hogy teszteljük ezeket a rendszereket ezen alkalmazkodóképesség, ezen önszerveződési képesség, és túlélési képesség szempontjából.
Ez mindent megváltoztat. Nemcsak azt, ahogyan a rendszert bevezetjük a gyakorlatba, hanem azt is, ahogyan fejlesztjük és teszteljük őket. Nincs stabilizáló folyamat, a kód fagyasztása, ehelyett van egy folyamatos de-stabilizáló folyamat. Megpróbáljuk megölni a rendszert, és látni, hogy az továbbra is túlél.
Elosztott Rendszer Integrációs Protokollok
Ezért megköveteli a rendszereinktől, hogy nekik is meg kell változniuk. Ahhoz, hogy ellenállóbbá váljanak, új interakciós protokollokra van szükségük a részeik között. Hogy ezek a részek meg tudják állapítani, és elérjék valamiféle önszerveződést. Új eszközök és új protokollok jönnek létre, amelyekre én csak úgy hivatkozom, hogy „elosiott rendszerek interakciós protokolljai.”
Miről beszélek? Először is, a . Egyfajta kísérlet a közös elosztott nyomkövető protokoll létrehozására, amely nélkülözhetetlen eszköz a komplex elosztott rendszerek hibakereséséhez.
Továbbá — . Azt mondjuk, hogy nem tudjuk megjósolni, mi fog történni a rendszerrel, tehát növelnünk kell a láthatóságát, az observabilityt. Az Opentracing a rendszereink láthatóságát biztosító eszközök családjába tartozik. De a láthatóságra azért van szükségünk, hogy meghatározzuk, a rendszer az elvárt módon viselkedik-e vagy sem. Hogyan határozzuk meg az elvárt viselkedést? Valamilyen politika, szabályrendszer meghatározásával. Az Open Policy Agent projekt e politikai keretek széles spektrumának meghatározására foglalkozik: a hozzáféréstől a források elhelyezéséig.
Ahogy mondtuk, rendszereink egyre inkább események vezéreltekké válnak. A Serverless egy nagyszerű példa az események vezérelte rendszerekre. Ahhoz, hogy eseményeket tudjunk átadni a rendszerek között és nyomon tudjuk követni őket, szükségünk van egy közös nyelvre, egy közös protokollra, amely meghatározza, hogyan beszélünk az eseményekről, hogyan adjuk át őket egymásnak. Ezzel foglalkozik a projekt, amelyet .
A folyamatos változások áramlása, amely elárasztja rendszereinket, folyamatosan destabilizálja őket, egy folyamatos áramlása a szoftveres artefaktumoknak. Ahhoz, hogy fenntarthassuk ezt az állandó változást, szükségünk van egy közös protokollra, amellyel arról beszélhetünk, mi a szoftveres artefaktum, hogyan ellenőriztük, milyen validációt kapott. Ezzel foglalkozik a projekt, amelyet . Tehát egy közös protokoll a szoftveres artefaktumok metadatáiról.
Végül, ha azt szeretnénk, hogy rendszereink teljesen önállóak, alkalmazkodók és önszerveződők legyenek, meg kell adnunk nekik a jogot az önazonosságra. Ezt a projektet valójában ezzel foglalkozik. Ez is a Cloud Native Computing Foundation égisze alatt működő projekt.
Mindezek a projektek fiatalok, mindnek szüksége van a szeretetünkre, a tesztelésünkre. Mind nyílt forráskódúak, a mi tesztelésünk, a mi implementációnk. Megmutatják nekünk, merre halad a technológia.
De a DevOps soha nem a technológiáról szólt elsősorban, mindig az emberek közötti együttműködésről szólt. Ennek megfelelően, ha azt akarjuk, hogy a rendszerek, amelyeket fejlesztünk, megváltozzanak, nekünk is változnunk kell. Valójában már így is változunk, különösen választásunk nincs.
Van egy nagyszerű a brit írónőtől, Rachel Botsmantól, amely az emberi történelem során a bizalom evolúciójáról szól. Azt mondja, hogy kezdetben, a primitív társadalmakban, a bizalom lokális volt, tehát csak azoknak bíztunk, akiket személyesen ismertünk.
Ezután volt egy nagyon hosszú időszak — a sötét kor, amikor a bizalom centralizált volt, amikor olyanoknak kezdtünk el bízni, akiket nem ismerünk, az alapján, hogy egy közintézményhez vagy állami intézményhez tartozunk.
Íme, amit a modern világunkban látunk: a bizalom egyre inkább elosztott és decentralizált, és az információs áramlások szabadságán, az információ hozzáférhetőségén alapul.
Ha elgondolkodunk rajta, ezt a hozzáférhetőséget, ami lehetővé teszi ezt a bizalmat, mi valósítjuk meg. Ez azt jelenti, hogy változnia kell annak is, ahogyan együttműködünk, és ahogyan ezt tesszük, mert a központosított, hierarchikus régi típusú IT-szervezetek elavulttá válnak. Elkezdik elveszíteni relevanciájukat.
A DevOps-szervezetek alapjai
A jövő tökéletes DevOps-szervezete egy decentralizált, alkalmazkodó rendszer, amely önálló csapatokból áll, amelyek mindegyike önálló egyénekből tevődik össze. Ezek a csapatok szerte a világban szétszórva hatékonyan működnek együtt aszinkron kommunikációval, nagyon átlátható információcsere protokollokkal. Nagyon szép, ugye? Nagyon szép jövő.
Természetesen mindez nem lehetséges kulturális változások nélkül. Transformációs vezetésre, egyéni felelősségvállalásra és belső motivációra van szükségünk.
Ez a DevOps-szervezetek alapja: az információk átláthatósága, aszinkron kommunikációk, transformációs vezetés, decentralizáció.
Kiégés
A rendszerek, amelyek részesei vagyunk, és amelyeket építünk, egyre kaotikusabbá válnak, és számunkra, embereknek, nehéz megbirkózni ezzel a gondolattal, nehéz lemondani a kontroll illúziójáról. Próbáljuk továbbra is irányítani őket, ami gyakran kiégéshez vezet. Ezt saját tapasztalataimra alapozom, én is megégettem magam, én is az előre nem látható hibák áldozataként vagyok jelen.
A kiégés akkor következik be, amikor megpróbáljuk irányítani azt, ami lényegében nem irányítható. Amikor kiégünk, minden értelmet nyer, mert elveszítjük a vágyat új dolgok létrehozására, védekező állásba helyezkedünk, és elkezdjük védeni azt, ami van.
A mérnöki szakma, ahogy gyakran emlékeztetem magam, elsősorban kreatív szakma. Ha elveszítjük a vágyat a dolgok létrehozására, akkor hamuvá válunk, a hamuvegyületté. Az emberek kiégnek, egész szervezetek égnek ki.
Szerintem csak a káosz teremtő erejének elfogadása, csak az ő elvei szerint történő együttműködés felépítése az, ami segíteni fog nekünk, hogy ne veszítsük el azt a jót, ami a szakmánkban van.
Amit kívánok nektek: szeressétek a munkátokat, szeressétek azt, amit csinálunk. Ez a világ információval táplálkozik, nekünk juttatott feladat ezeket táplálni. Szóval tanulmányozzuk a káoszt, legyünk káosztudósok, hozzunk értéket, alkossunk valami újat, és a problémák, ahogy már kiderült, elkerülhetetlenek, és amikor felmerülnek, csak annyit mondunk: «Ops!», és a probléma megoldva.
Mi van a Chaos Monkey-n kívül?
Valójában ezek az eszközök nagyon fiatalok. A Netflix is saját eszközöket épített. Építsetek saját eszközöket. Olvassátok el a káoszmérnöki elveket, és tartsatok azokhoz, ne próbáljatok mások által már létrehozott eszközöket keresni.
Próbáljátok megérteni, hogyan hibásodnak meg a rendszereitek, és kezdjetek el hibákat okozni, hogy lássátok, hogyan állják a sarat. Ez az első lépés. Az eszközöket meg lehet keresni. Vannak különféle projektek.
Nem igazán értettem, amikor arról beszéltél, hogy a rendszert nem szabad egyszerűsíteni az alkotóelemek egyszerűsítésével, majd azonnal áttértél a mikroszolgáltatásokra, amelyek éppen azt csinálják, hogy egyszerűsítik a rendszert az elemek egyszerűsítésével, és bonyolítják az interakciókat. Alapvetően két ellentmondó dologról van szó.
Teljesen igaz, a mikroszolgáltatások valóban ellentmondásos téma. Valójában az elemek egyszerűsítése növeli a rugalmasságot. Mit adnak a mikroszolgáltatások? Rugalmasságot és sebességet, de biztosan nem adnak egyszerűséget. Növelik a bonyolultságot.
Tehát a DevOps filozófiájában a mikroszolgáltatások nem olyan nagy áldás?
Minden áldásnak van árnyoldala. Van áldás: ez növeli a rugalmasságot, lehetővé teszi a gyorsabb változtatásokat, de növeli a bonyolultságot, és ennek megfelelően a rendszer törékenységét.
Mégis mire helyezzük a hangsúlyt: az interakciók egyszerűsítésére vagy az alkotóelemek egyszerűsítésére?
A hangsúly egyértelműen az interakciók egyszerűsítésén van, mert ha úgy nézzük, hogyan dolgozunk együtt, akkor először az interakciók egyszerűsítésére kell figyelnünk, nem pedig arra, hogy mindannyiunk munkáját külön-külön egyszerűsítsük. Mert a munka egyszerűsítése – ez robotokká való válást jelent. A McDonald'snál ez jól működik, amikor meg van írva: ide helyezd a hamburgert, ide öntsd a szószt. Ez a kreatív munkánkban egyáltalán nem működik.
Igaz, hogy minden, amit mondtál, egy verseny nélküli világban él, ahol a káosz olyan barátságos, és nincsenek ellentmondások ebben a káoszban, senki sem akar senkit megenni, meggyilkolni? Hogyan kell együtt élnie a versenynek és a DevOpsnak?
Ez attól függ, hogy milyen versenyről beszélünk. A munkahelyi versenyről vagy a cégek közötti versenyről?
A létező szolgáltatások versenyéről van szó, mert a szolgáltatások nem csupán különböző cégek. Új típusú információs környezetet teremtünk, és bármilyen környezet nem létezhet verseny nélkül. Mindenhol van verseny.
Ugyanaz a Netflix, vegyük őket példának. Miért találták ki ezt? Mert versenyképesnek kellett lenniük. Ez a rugalmasság és a mozgás sebessége éppen a versenykövetelmény, ami káoszt hoz a rendszereinkbe. Tehát a káosz nem az, amit tudatosan csinálunk, mert azt akarjuk, hanem ami abból adódik, hogy a világ ezt kívánja. Csak alkalmazkodnunk kell. És a káosz éppen a verseny eredménye.
Ez azt jelenti, hogy a káosz a célok hiányát jelenti? Vagy olyan célok, amiket nem akarunk látni? Mi itt vagyunk a házikónkban, és nem értjük mások céljait. A verseny valójában azért van, mert világos céljaink vannak, és tudjuk, hová érkezünk a következő időpillanatban. Ebben látom a DevOps lényegét.
Ez is egy nézőpont. Azt gondolom, hogy mindannyiunk célja ugyanaz: túlélni és ezt a lehető legnagyobb örömmel tenni.
És bármely szervezet verseny célja is ilyen. A túlélés gyakran a versenytartásban valósul meg, ezt nem lehet megkerülni.
Idén a konferencia december 7-én a 'Technopolis'-ban kerül megrendezésre. November 11-ig fogadjuk a jelentkezéseket az előadásokra. ha szeretnél előadni.
A résztvevők regisztrációja nyitva áll, a jegy ára 7000 rubel. Csatlakozzon hozzánk!
Forrás: habr.com
