Anton Weiss, zakladateľ a riaditeľ Otomato Software, jeden z iniciátorov a inštruktorov prvej certifikácie DevOps v Izraeli, vystúpil na minuloročnom o teórii chaosu a hlavných princípoch chaosového inžinierstva a tiež vysvetlil, ako funguje ideálna organizácia DevOps budúcnosti.
Pripravili sme textovú verziu správy.
Dobré ráno!
DevOpsDays v Moskve už druhý rok po sebe, na tomto pódiu som druhýkrát, mnohí z vás ste v tejto miestnosti už druhýkrát. Čo to znamená? To znamená, že hnutie DevOps v Rusku rastie, znásobuje sa a čo je najdôležitejšie, znamená to, že nastal čas hovoriť o tom, čo je DevOps v roku 2018.
Zdvihnite ruky, kto si myslí, že DevOps je už v roku 2018 profesiou? Existujú také. Sú v miestnosti nejakí inžinieri DevOps, ktorých popis práce hovorí „DevOps Engineer“? Sú v miestnosti nejakí manažéri DevOps? Taký neexistuje. Architekti DevOps? Tiež nie. Nedostatočné. Je naozaj pravda, že nikto nehovorí, že je inžinierom DevOps?
Takže väčšina z vás si myslí, že je to anti-vzor? Že by takéto povolanie nemalo existovať? Môžeme si myslieť, čo chceme, no zatiaľ čo my rozmýšľame, priemysel sa slávnostne posúva vpred za zvuku trúbky DevOps.
Kto počul o novej téme s názvom DevDevOps? Ide o novú techniku, ktorá umožňuje efektívnu spoluprácu medzi vývojármi a vývojármi. A nie až taký nový. Súdiac podľa Twitteru, začali o tom hovoriť už pred 4 rokmi. A doteraz záujem o to rastie a rastie, to znamená, že je tu problém. Problém je potrebné vyriešiť.
Sme kreatívni ľudia, nemáme len pokoj. Hovoríme: DevOps nie je dostatočne obsiahle slovo, stále mu chýbajú rôzne, zaujímavé prvky. A ideme do našich tajných laboratórií a začneme vyrábať zaujímavé mutácie: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logika je železná, však? Náš doručovací systém je nefunkčný, naše systémy sú nestabilné a naši používatelia sú nespokojní, nestíhame zavádzať softvér načas, nezmestíme sa do rozpočtu. Ako to všetko vyriešime? Vymyslíme nové slovo! Skončí to "Ops" a problém je vyriešený.
Takže tento prístup nazývam - "Ops a problém je vyriešený."
Toto všetko ustúpi do pozadia, ak si pripomenieme, prečo sme na to všetko prišli. Vymysleli sme celú túto vec DevOps, aby sme doručovanie softvéru a našu vlastnú prácu v tomto procese zabezpečili čo najpohodlnejšie, bezbolestne, najefektívnejšie a čo je najdôležitejšie.
DevOps vyrástol z bolesti. A sme unavení z utrpenia. A aby sa toto všetko stalo, spoliehame sa na stále zelené postupy: efektívnu spoluprácu, postupy toku a hlavne systémové myslenie, pretože bez toho žiadne DevOps nefunguje.
Aký je systém?
A ak už hovoríme o systémovom myslení, pripomeňme si, čo je systém.
Ak ste revolučný hacker, potom je pre vás systém jednoznačne zlý. Je to mrak, ktorý nad vami visí a núti vás robiť veci, ktoré nechcete.
Z hľadiska systémového myslenia je systém celkom, ktorý sa skladá z častí. V tomto zmysle je každý z nás systém. Organizácie, v ktorých pracujeme, sú systémy. A to, čo vy a ja budujeme, sa nazýva systém.
To všetko je súčasťou jedného veľkého sociálno-technologického systému. A iba ak pochopíme, ako tento sociálno-technologický systém spolupracuje, iba vtedy budeme môcť v tejto veci skutočne niečo optimalizovať.
Z pohľadu systémového myslenia má systém rôzne zaujímavé vlastnosti. Po prvé, pozostáva z častí, čo znamená, že jej správanie závisí od správania sa častí. Okrem toho sú všetky jeho časti navzájom závislé. Ukazuje sa, že čím viac častí má systém, tým ťažšie je pochopiť alebo predpovedať jeho správanie.
Z hľadiska správania je tu ešte jeden zaujímavý fakt. Systém dokáže niečo, čo nedokáže žiadna z jeho jednotlivých častí.
Ako povedal Dr. Russell Ackoff (jeden zo zakladateľov systémového myslenia), je to celkom jednoduché dokázať myšlienkovým experimentom. Napríklad, kto v miestnosti vie písať kód? Existuje veľa rúk, a to je normálne, pretože je to jedna z hlavných požiadaviek na našu profesiu. Vieš písať, ale dokážu tvoje ruky písať kód oddelene od teba? Sú ľudia, ktorí povedia: „Nie moje ruky píšu kód, ale môj mozog. Dokáže váš mozog písať kód oddelene od vás? No asi nie.
Mozog je úžasný stroj, nevieme ani 10% toho, ako tam funguje, ale nemôže fungovať oddelene od systému, ktorým je naše telo. A to sa dá ľahko dokázať: otvor si lebku, vytiahni mozog, polož ho pred počítač, nech skúsi napísať niečo jednoduché. Napríklad „Ahoj, svet“ v Pythone.
Ak systém dokáže niečo, čo žiadna z jeho častí nedokáže samostatne, potom to znamená, že jeho správanie nie je určené správaním jeho častí. Podľa čoho sa to potom určuje? Je určená interakciou medzi týmito časťami. A teda čím viac častí, tým zložitejšie sú interakcie, tým ťažšie je pochopiť a predpovedať správanie systému. A to robí takýto systém chaotickým, pretože akákoľvek, aj tá najnepodstatnejšia, neviditeľná zmena v ktorejkoľvek časti systému môže viesť k úplne nepredvídateľným výsledkom.
Túto citlivosť na počiatočné podmienky prvýkrát objavil a študoval americký meteorológ Ed Lorenz. Následne sa to nazývalo „motýľový efekt“ a viedlo k rozvoju hnutia vedeckého myslenia nazývaného „teória chaosu“. Táto teória sa stala jednou z hlavných zmien paradigmy vo vede 20. storočia.
Teória chaosu
Ľudia, ktorí študujú chaos, sa nazývajú chaosológmi.
V skutočnosti dôvodom tejto správy bolo, že pri práci s komplexnými distribuovanými systémami a veľkými medzinárodnými organizáciami som si v určitom momente uvedomil, že práve na toto sa cítim. Som chaosológ. Toto je v podstate šikovný spôsob, ako povedať: „Nechápem, čo sa tu deje, a neviem, čo s tým mám robiť.
Myslím, že aj mnohí z vás to tak často vnímate, takže ste aj chaosológovia. Pozývam vás do cechu chaosológov. Systémy, ktoré vy a ja, drahí kolegovia chaosológovia, budeme študovať, sa nazývajú „komplexné adaptívne systémy“.
Čo je prispôsobivosť? Adaptabilita znamená, že individuálne a kolektívne správanie častí v takomto adaptívnom systéme sa mení a samoorganizuje, pričom reaguje na udalosti alebo reťazce mikroudalostí v systéme. To znamená, že systém sa prispôsobuje zmenám prostredníctvom sebaorganizácie. A táto schopnosť sebaorganizácie je založená na dobrovoľnej, úplne decentralizovanej spolupráci slobodných autonómnych agentov.
Ďalšou zaujímavou vlastnosťou takýchto systémov je, že sú voľne škálovateľné. Čo by nás, ako chaosológov-inžinierov, nepochybne malo zaujímať. Ak sme teda povedali, že správanie zložitého systému je určené interakciou jeho častí, čo by nás teda malo zaujímať? Interakcia.
Existujú ešte dva zaujímavé zistenia.
Po prvé, chápeme, že zložitý systém nemožno zjednodušiť zjednodušením jeho častí. Po druhé, jediný spôsob, ako zjednodušiť zložitý systém, je zjednodušiť interakcie medzi jeho časťami.
Ako spolu interagujeme? Vy a ja sme všetci súčasťou veľkého informačného systému nazývaného ľudská spoločnosť. Komunikujeme prostredníctvom spoločného jazyka, ak ho máme, ak ho nájdeme.
Samotný jazyk je však komplexný adaptívny systém. Preto, aby sme mohli efektívnejšie a jednoduchšie interagovať, musíme vytvoriť nejaký druh protokolov. Teda nejaký sled symbolov a úkonov, vďaka ktorým bude výmena informácií medzi nami jednoduchšia, predvídateľnejšia, zrozumiteľnejšia.
Chcem povedať, že vo všetkom sa dajú vysledovať trendy ku komplexnosti, k prispôsobivosti, k decentralizácii, k chaosu. A v systémoch, ktoré vy a ja budujeme, a v tých systémoch, ktorých sme súčasťou.
A aby sme neboli neopodstatnení, pozrime sa, ako sa menia systémy, ktoré vytvárame.
Toto slovo ste čakali, rozumiem. Sme na konferencii DevOps, dnes toto slovo zaznie asi stotisíckrát a potom sa nám o ňom bude v noci snívať.
Mikroslužby sú prvou softvérovou architektúrou, ktorá vznikla ako reakcia na postupy DevOps, ktorá je navrhnutá tak, aby naše systémy boli flexibilnejšie, škálovateľnejšie a zabezpečili nepretržité poskytovanie. Ako to robí? Znížením objemu služieb, zmenšením rozsahu problémov, ktoré tieto služby spracovávajú, skrátením času dodania. To znamená, že zmenšujeme a zjednodušujeme časti systému, zvyšujeme ich počet a podľa toho sa neustále zvyšuje zložitosť interakcií medzi týmito časťami, to znamená, že vznikajú nové problémy, ktoré musíme riešiť.
Mikroslužby nie sú koniec, mikroslužby sú vo všeobecnosti už včera, pretože prichádza Serverless. Všetky servery zhoreli, žiadne servery, žiadne operačné systémy, len čistý spustiteľný kód. Konfigurácie sú oddelené, stavy oddelené, všetko je riadené udalosťami. Krása, čistota, ticho, žiadne akcie, nič sa nedeje, úplný poriadok.
Kde je zložitosť? Problém je samozrejme v interakciách. Koľko dokáže jedna funkcia urobiť sama? Ako interaguje s inými funkciami? Fronty správ, databázy, balancery. Ako znovu vytvoriť nejakú udalosť, keď došlo k zlyhaniu? Veľa otázok a málo odpovedí.
Microservices a Serverless sú to, čo my geekskí hipsteri nazývame Cloud Native. Všetko je to o cloude. Ale cloud je tiež vo svojej podstate obmedzený vo svojej škálovateľnosti. Zvykli sme si o ňom uvažovať ako o distribuovanom systéme. Kde vlastne žijú servery poskytovateľov cloudu? V dátových centrách. To znamená, že tu máme akýsi centralizovaný, veľmi obmedzený, distribuovaný model.
Dnes už chápeme, že internet vecí už nie sú len veľké slová, že aj podľa skromných predpovedí nás v najbližších piatich až desiatich rokoch čakajú miliardy zariadení pripojených k internetu. Obrovské množstvo užitočných a zbytočných dát, ktoré budú zlúčené do cloudu a nahrané z cloudu.
Cloud nevydrží, a tak čoraz častejšie hovoríme o niečom, čo sa nazýva edge computing. Alebo sa mi páči aj úžasná definícia „fog computingu“. Je zahalená mystikou romantizmu a tajomstva.
Fog computing. Ide o to, že oblaky sú centralizované zhluky vody, pary, ľadu a kameňov. A hmla sú kvapky vody, ktoré sú rozptýlené okolo nás v atmosfére.
V paradigme hmly väčšinu práce vykonávajú tieto kvapôčky úplne autonómne alebo v spolupráci s inými kvapkami. A na oblak sa obracajú až vtedy, keď ich naozaj tlačí.
To znamená opäť decentralizácia, autonómia a, samozrejme, mnohí z vás už chápu, kam to všetko smeruje, pretože nemôžete hovoriť o decentralizácii bez toho, aby ste spomenuli blockchain.
Sú tí, ktorí veria, sú to tí, ktorí investovali do kryptomeny. Sú takí, ktorí veria, ale majú strach, ako napríklad ja. A sú aj takí, ktorí neveria. Tu môžete zaobchádzať inak. Je tu technológia, nová neznáma záležitosť, sú tu problémy. Ako každá nová technológia vyvoláva viac otázok ako odpovedí.
Hype okolo blockchainu je pochopiteľný. Odhliadnuc od zlatej horúčky, samotná technológia má pozoruhodné prísľuby pre lepšiu budúcnosť: viac slobody, viac autonómie, distribuovaná globálna dôvera. Čo nechceš?
V súlade s tým čoraz viac inžinierov na celom svete začína vyvíjať decentralizované aplikácie. A to je sila, ktorú nemožno zavrhnúť jednoduchým vyslovením: „Ach, blockchain je len zle implementovaná distribuovaná databáza.“ Alebo ako skeptici radi hovoria: „Neexistujú žiadne skutočné aplikácie pre blockchain.“ Keď sa nad tým zamyslíte, pred 150 rokmi hovorili to isté o elektrine. A dokonca mali v niečom pravdu, pretože to, čo dnes umožňuje elektrina, nebolo možné v 19. storočí.
Mimochodom, kto vie, aké logo je na obrazovke? Toto je Hyperledger. Ide o projekt, ktorý sa vyvíja pod záštitou The Linux Foundation a zahŕňa sadu blockchainových technológií. Toto je skutočne sila našej open source komunity.
Chaos Engineering
Takže systém, ktorý vyvíjame, sa stáva čoraz zložitejším, chaotickejším a stále prispôsobivejším. Netflix je priekopníkom mikroservisných systémov. Boli medzi prvými, ktorí to pochopili, vyvinuli súbor nástrojov, ktoré nazvali Simian Army, z ktorých najznámejší bol . Definoval to, čo sa stalo známym ako .
Mimochodom, v procese práce na správe sme tento text dokonca preložili do ruštiny, takže choďte na , čítať, komentovať, nadávať.
Stručne povedané, princípy chaosového inžinierstva hovoria nasledovné. Komplexné distribuované systémy sú vo svojej podstate nepredvídateľné a vo svojej podstate zabugované. Chyby sú nevyhnutné, čo znamená, že musíme tieto chyby akceptovať a pracovať s týmito systémami úplne iným spôsobom.
My sami sa musíme pokúsiť zaviesť tieto chyby do našich výrobných systémov, aby sme otestovali naše systémy na rovnakú adaptabilitu, práve túto schopnosť sebaorganizácie, na prežitie.
A to všetko mení. Nielen ako zavádzame systémy do výroby, ale aj ako ich vyvíjame, ako ich testujeme. Neexistuje proces stabilizácie alebo zmrazenia kódu, naopak, neustále prebieha proces destabilizácie. Snažíme sa zabiť systém a vidíme, že aj naďalej prežije.
Protokoly pre integráciu distribuovaného systému
V súlade s tým si to vyžaduje, aby sa naše systémy nejako zmenili. Aby sa stali stabilnejšími, potrebujú nejaké nové protokoly na interakciu medzi ich časťami. Aby sa tieto časti mohli dohodnúť a prísť k nejakej samoorganizácii. A vznikajú všetky druhy nových nástrojov, nové protokoly, ktoré nazývam „protokoly pre interakciu distribuovaných systémov“.
O čom to hovorím? Po prvé, projekt . Niektorí sa pokúšajú vytvoriť všeobecný distribuovaný sledovací protokol, ktorý je absolútne nevyhnutným nástrojom na ladenie zložitých distribuovaných systémov.
Ďalej - . Hovoríme, že nevieme predvídať, čo bude so systémom, to znamená, že musíme zvýšiť jeho pozorovateľnosť, pozorovateľnosť. Opentracing patrí do rodiny nástrojov, ktoré poskytujú pozorovateľnosť našim systémom. Potrebujeme však pozorovateľnosť, aby sme mohli určiť, či sa systém správa tak, ako očakávame, alebo nie. Ako definujeme očakávané správanie? Definovaním nejakého druhu politiky, nejakého súboru pravidiel. Projekt Open Policy Agent pracuje na definovaní tohto súboru pravidiel v celom spektre od prístupu až po prideľovanie zdrojov.
Ako sme už povedali, naše systémy sú čoraz viac riadené udalosťami. Serverless je skvelým príkladom systémov riadených udalosťami. Aby sme mohli prenášať udalosti medzi systémami a sledovať ich, potrebujeme nejaký spoločný jazyk, nejaký spoločný protokol, ako o udalostiach hovoríme, ako si ich navzájom prenášame. Tak sa volá projekt .
Neustály prúd zmien, ktorý zaplavuje naše systémy a neustále ich destabilizuje, je nepretržitým prúdom softvérových artefaktov. Na to, aby sme udržali tento neustály tok zmien, potrebujeme nejaký spoločný protokol, prostredníctvom ktorého sa môžeme rozprávať o tom, čo je softvérový artefakt, ako sa testuje, akým overením prešiel. Tak sa volá projekt . Teda spoločný metaúdajový protokol pre softvérové artefakty.
A napokon, ak chceme, aby naše systémy boli úplne nezávislé, prispôsobivé a samoorganizované, musíme im dať právo na sebaidentifikáciu. Projekt tzv Presne toto robí. Aj toto je projekt pod záštitou Cloud Native Computing Foundation.
Všetky tieto projekty sú mladé, všetky potrebujú našu lásku, naše potvrdenie. Toto všetko je open source, naše testovanie, naša implementácia. Ukazujú nám, kam technológia smeruje.
DevOps ale nikdy nebolo primárne o technológiách, vždy išlo o spoluprácu medzi ľuďmi. A teda, ak chceme, aby sa systémy, ktoré vyvíjame, zmenili, musíme sa zmeniť aj my sami. V skutočnosti sa aj tak meníme; nemáme príliš na výber.
Existuje úžasné Britská spisovateľka Rachel Botsmanová, v ktorej píše o vývoji dôvery v histórii ľudstva. Hovorí, že spočiatku v primitívnych spoločnostiach bola dôvera miestna, to znamená, že sme dôverovali iba tým, ktorých osobne poznáme.
Potom nastalo veľmi dlhé obdobie – doba temna, keď sa centralizovala dôvera, keď sme začali dôverovať ľuďom, ktorých nepoznáme na základe toho, že patríme do tej istej verejnej alebo štátnej inštitúcie.
A to je to, čo vidíme v našom modernom svete: dôvera sa čoraz viac distribuuje a decentralizuje a je založená na slobode informačných tokov, na dostupnosti informácií.
Ak sa nad tým zamyslíte, práve táto dostupnosť, ktorá umožňuje túto dôveru, je to, čo vy a ja implementujeme. To znamená, že sa musí zmeniť spôsob, akým spolupracujeme, aj spôsob, akým to robíme, pretože centralizované, hierarchické IT organizácie v minulosti už nefungujú. Začnú odumierať.
Základy organizácie DevOps
Ideálna organizácia DevOps budúcnosti je decentralizovaný, adaptívny systém zložený z autonómnych tímov, z ktorých každý pozostáva z autonómnych jednotlivcov. Tieto tímy sú roztrúsené po celom svete a efektívne medzi sebou spolupracujú pomocou asynchrónnej komunikácie s použitím vysoko transparentných komunikačných protokolov. Veľmi krásne, však? Veľmi krásna budúcnosť.
Samozrejme, nič z toho nie je možné bez kultúrnych zmien. Musíme mať transformačné vedenie, osobnú zodpovednosť, vnútornú motiváciu.
Toto je základ organizácií DevOps: informačná transparentnosť, asynchrónna komunikácia, transformačné vedenie, decentralizácia.
Vyhorieť
Systémy, ktorých sme súčasťou a tie, ktoré budujeme, sú čoraz chaotické a pre nás ľudí je ťažké sa s touto myšlienkou vyrovnať, je ťažké vzdať sa ilúzie kontroly. Snažíme sa ich naďalej kontrolovať a často to vedie k vyhoreniu. Hovorím to z vlastnej skúsenosti, tiež som sa popálil, znemožnili ma aj nepredvídané poruchy vo výrobe.
K vyhoreniu dochádza, keď sa snažíme ovládať niečo, čo je vo svojej podstate nekontrolovateľné. Keď vyhoríme, všetko stráca zmysel, pretože strácame chuť robiť niečo nové, dostávame sa do defenzívy a začíname brániť to, čo máme.
Inžinierske povolanie, ako si často rád pripomínam, je v prvom rade tvorivé povolanie. Ak stratíme túžbu niečo vytvoriť, zmeníme sa na popol, premeníme sa na popol. Ľudia vyhoreli, vyhoreli celé organizácie.
Podľa mňa len akceptovanie tvorivej sily chaosu, len budovanie spolupráce podľa jeho princípov je to, čo nám pomôže nestratiť to dobré v našej profesii.
To je to, čo vám želám: milovať svoju prácu, milovať to, čo robíme. Tento svet sa živí informáciami, my máme tú česť ho kŕmiť. Poďme teda študovať chaos, buďme chaosológmi, prinášajme hodnotu, tvorme niečo nové, no, problémy, ako sme už zistili, sú nevyhnutné a keď sa objavia, jednoducho povieme „Ops!“ A problém je vyriešený.
Čo iné ako Chaos Monkey?
V skutočnosti sú všetky tieto nástroje také mladé. Rovnaký Netflix si vytvoril nástroje pre seba. Zostavte si vlastné nástroje. Prečítajte si princípy chaosového inžinierstva a dodržujte tieto princípy, namiesto toho, aby ste sa snažili nájsť iné nástroje, ktoré už vytvoril niekto iný.
Pokúste sa pochopiť, ako sa vaše systémy rozpadajú, začnite ich búrať a uvidíte, ako vydržia. Toto je na prvom mieste. A môžete hľadať nástroje. Existujú všetky druhy projektov.
Úplne som nepochopil moment, keď ste povedali, že systém sa nedá zjednodušiť zjednodušením jeho komponentov, a hneď ste prešli k mikroslužbám, ktoré zjednodušujú systém tým, že zjednodušujú samotné komponenty a komplikujú interakcie. Ide v podstate o dve časti, ktoré si navzájom odporujú.
Presne tak, mikroslužby sú vo všeobecnosti veľmi kontroverznou témou. Zjednodušenie častí v skutočnosti zvyšuje flexibilitu. Čo poskytujú mikroslužby? Poskytujú nám flexibilitu a rýchlosť, ale určite nám nedávajú jednoduchosť. Zvyšujú náročnosť.
Takže vo filozofii DevOps nie sú mikroslužby až taká dobrá vec?
Každé dobro má odvrátenú stranu. Výhodou je, že zvyšuje flexibilitu, umožňuje nám rýchlejšie vykonávať zmeny, no zvyšuje zložitosť a tým aj krehkosť celého systému.
Na čo sa však kladie väčší dôraz: na zjednodušenie interakcie alebo na zjednodušenie častí?
Dôraz je samozrejme kladený na zjednodušenie interakcií, pretože ak sa na to pozrieme z pohľadu toho, ako s vami pracujeme, tak v prvom rade treba dbať na zjednodušovanie interakcií, a nie na zjednodušovanie práce každého z nás zvlášť. Pretože zjednodušiť prácu znamená premeniť sa na roboty. Tu v McDonalde to funguje normálne, keď máte návod: tu dáte burger, tu nalejete omáčku. Toto v našej tvorivej práci vôbec nefunguje.
Je pravda, že všetko, čo ste povedali, žije vo svete bez konkurencie a chaos tam je taký láskavý a v tomto chaose nie sú žiadne rozpory, nikto nechce nikoho zjesť ani zabiť? Ako by mala fungovať konkurencia a DevOps?
No záleží na tom, o akej konkurencii sa bavíme. Ide o konkurenciu na pracovisku alebo konkurenciu medzi firmami?
O konkurencii služieb, ktoré existujú, pretože služby nie sú viaceré spoločnosti. Vytvárame nový typ informačného prostredia a žiadne prostredie nemôže žiť bez konkurencie. Všade je konkurencia.
To isté Netflix, berieme ich ako vzor. Prečo s tým prišli? Pretože potrebovali byť konkurencieschopní. Táto flexibilita a rýchlosť pohybu je práve tou veľmi konkurenčnou požiadavkou, ktorá vnáša do našich systémov chaos. To znamená, že chaos nie je niečo, čo vedome robíme, pretože to chceme, je to niečo, čo sa deje, pretože si to svet vyžaduje. Len sa musíme prispôsobiť. A chaos, to je presne výsledok súťaže.
Znamená to, že chaos je absencia gólov? Alebo tie ciele, ktoré nechceme vidieť? Sme v dome a nerozumieme cieľom iných. Konkurencia je v skutočnosti spôsobená tým, že máme jasné ciele a v každej ďalšej chvíli vieme, kde skončíme. Toto je z môjho pohľadu podstata DevOps.
Tiež sa pozrite na otázku. Myslím, že všetci máme rovnaký cieľ: prežiť a urobiť to s
najväčšie potešenie. A konkurenčný cieľ každej organizácie je rovnaký. K prežitiu často dochádza vďaka konkurencii, s tým nemôžete nič urobiť.
Tohtoročná konferencia sa uskutoční 7. decembra v Technopolise. Prihlášky na reportáže prijímame do 11. novembra. nás, ak by ste chceli hovoriť.
Registrácia pre účastníkov je otvorená, vstupenky stoja 7000 XNUMX rubľov. Pripoj sa k nám!
Zdroj: hab.com