Otomato Software'i asutaja ja direktor Anton Weiss, kes on üks Iisraeli esimese DevOps-sertifitseerimise algatajatest ja instruktoritest, rääkis eelmisel aastal kaose teooriast ja kaose inseneri põhialustest ning selgitas, kuidas tulevikus ideaalne DevOps-organisatsioon välja näeb.
Oleme valmistanud ette ettekande tekstiversiooni.
Tere hommikust!
DevOpsDays Moskvas toimub teist aastat järjest, mina olen teist korda sellel laval, paljud teist on teist korda selles saalis. Mis see tähendab? See tähendab, et DevOps-liikumine Venemaal kasvab, areneb ja mis kõige tähtsam, on aeg rääkida, mis DevOps tegelikult 2018. aastal on.
Küsimus käib, kes arvab, et 2018. aastal on DevOps juba amet? Kas on keegi. Kas saalis on DevOps-insenere, kelle ametijuhendis on kirjas „DevOps-insener”? Kas saalis on DevOps-juhtide? Neid pole. DevOps-arhitekte? Ka mitte. Vähe. Kas tõesti kellelgi pole ametinimetuses, et ta on DevOps-insener?
See tähendab, et enamik teist arvab, et see on antipattern? Et sellist ametit ei tohiks olla? Me võime arvata kõike, mida tahame, kuid samal ajal liigub tööstus uhkelt edasi DevOps-trummi helide saatel.
Kas keegi on kuulnud uuest teemast, mis nimetatakse DevDevOps? See on uus meetod, mis võimaldab tagada tõhus koostöö arendajate ja DevOps-ide vahel. Tõsi küll, see pole nii uus. Kui vaadata Twitterit, siis räägiti sellest juba 4 aastat tagasi. Ja huvi selle vastu kasvab ja kasvab, see tähendab, et probleem on olemas. Probleem tuleb lahendada.
Me oleme loovad inimesed, me ei lepi niisama. Me ütleme: DevOps ei ole piisavalt kõikehõlmav sõna, seal puuduvad veel mitmed huvitavad elemendid. Ning me läheme oma salajastesse laboritesse ja hakkame looma huvitavaid muteeringuid: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Loogika on raudne, eks? Meil ei ole funktsionaalset tarnehankesüsteemi, meie süsteemid on ebastabiilsed ja kasutajad on rahulolematud, me ei jõua tarkvara õigel ajal välja anda, ei mahtu eelarvesse. Kuidas me seda kõike lahendame? Me leiutame uue sõna! See hakkab lõppema silbiga „Ops” ja probleem on lahendatud.
Nii et ma nimetan seda lähenemist „Ops ja probleem on lahendatud”.
Kõik see jääb tagaplaanile, kui me meenutame endale, miks me selle kõik välja mõtlesime. Me mõtlesime välja kogu selle DevOpsi, et muuta tarkvara tarnimist ja oma tööd selles protsessis võimalikult sujuvaks, valutuks, efektiivseks ja mis kõige tähtsam, meeldivaks.
DevOps kasvas välja valust. Meil on küllalt kannatada. Et see kõik juhtuks, tugineme igihaljatele praktikatele: tõhus koostöö, voogude praktikad ja mis kõige tähtsam, süsteemne mõtlemine, sest ilma selleta ei toimi DevOps.
Mis on süsteem?
Ja kui me juba rääkisime süsteemsest mõtlemisest, meenutame endale, mis on süsteem.
Kui sa oled häkker-revolutsionäär, siis süsteem on sinu jaoks ühemõtteliselt kurjus. See on pilv, mis ripub sinu kohal ja sunnib sind tegema seda, mida sa teha ei soovi.
Süsteemse mõtlemise seisukohalt on süsteem tervik, mis koosneb osadest. Selles mõttes oleme kõik meie süsteem. Organisatsioonid, kus me töötame, on süsteemid. Ja see, mida me ehitame, on samuti süsteem.
Kogu see on osa ühest suurest sotsiaaltehnoloogilisest süsteemist. Ja ainult siis, kui me mõistame, kuidas see sotsiaaltehnoloogiline süsteem koos töötab, suudame me seda tõeliselt optimeerida.
Süsteemse mõtlemise seisukohalt on süsteemil mitmeid huvitavaid omadusi. Esiteks, see koosneb osadest, mis tähendab, et selle käitumine sõltub osade käitumisest. Samal ajal on kõik osad omavahel seotud. Seega, mida rohkem on süsteemis osi, seda keerulisem on mõista või ennustada selle käitumist.
Käitumise seisukohalt on siin veel üks huvitav fakt. Süsteem suudab teha midagi, mida ükski selle eraldi osa ei suuda.
Kuidas ütles doktor Russell Ackoff (üks süsteemse mõtlemise rajajaid), on seda üsna lihtne tõestada mõtteeksperimendi abil. Näiteks, kes siin saalis oskab koodi kirjutada? Palju käsi, ja see on normaalne, sest see on üks meie ala peamistest nõuetest. Sa oskad kirjutada, aga kas su käed eraldi sinust saavad koodi kirjutada? On inimesi, kes ütlevad: „Mul ei kirjuta käed koodi, mul kirjutab aju koodi”. Aga kas aju suudab eraldi sinust koodi kirjutada? No, suure tõenäosusega ei.
Aju on hämmastav masin, me ei tea isegi 10% sellest, kuidas see töötab, kuid see ei saa funktsioneerida eraldi meie organismi süsteemist. Seda on lihtne tõestada: avage oma kolju, võtke sealt aju välja, asetage see arvuti ette ja laske tal proovida kirjutada midagi lihtsat. Näiteks "Hello, world" Pythonis.
Kui süsteem suudab teha midagi, mida ükski selle osa eraldi teha ei saa, siis tähendab see, et selle käitumine ei sõltu selle osade käitumisest. Millest see siis sõltub? See sõltub nende osade vahelisest suhtlemisest. Seega, mida rohkem osi, seda keerulisemad on suhted, seda keerulisem on aru saada ja ennustada süsteemi käitumist. See muudab süsteemi kaootiliseks, kuna isegi kõige tähtsusetum ja palja silmaga nähtamatu muutus ühe süsteemi osas võib viia täiesti ettearvamatute tulemusteni.
Seda tundlikkust esialgsete tingimuste suhtes avastas ja uuris esmakordselt Ameerika meteoroloog Ed Lorenz. Hiljem nimetati seda "liblikatefektiks" ja see viis teadusliku mõtte suuna arenguni, mida nimetatakse "chaosteaduseks". See teooria oli ühekordne paradigma muutus 20. sajandi teaduses.
Kaosteadus
Inimesed, kes uurivad kaost, nimetavad end kaosoloogideks.
Selle ettekande tegelikuks põhjuseks oli see, et töötades keerukate jaotatud süsteemide ja suurte rahvusvaheliste organisatsioonidega, sain ma mingil hetkel aru, et ma tunnen ennast selle seas. Ma olen kaosoloog. See on omamoodi nutikas viis öelda: "Ma ei saa aru, mis siin toimub ja ei tea, mida sellega teha."
Ma arvan, et paljud teist tunnevad end samuti sageli niimoodi, seega olete ka teie kaosoloogid. Kutsun teid kaosoloogide gildisse. Süsteemid, mida me, kallid kolleegid kaosoloogid, uurime, kutsutakse "keerukateks kohanduvateks süsteemideks."
Mis on kohanemisvõime? Kohanemisvõime tähendab, et sellise kohandatava süsteemi osade individuaalne ja kollektiivne käitumine muutub ja isekorraldub vastuseks süsteemis toimuvale sündmusele või mikrosündmuste jada. See tähendab, et süsteem kohandub muutustega isekorraldamise kaudu. Ja see isekorraldamise võime põhineb vabatahtlikul, täiesti detsentraliseeritud koostööl vabade autonoomsete agentide vahel.
Veel üks huvitav selliste süsteemide omadus on see, et need on vabalt skaleeritavad. See peaks kindlasti huvitama meid kui kaosotehnikate insenere. Nii et kui me ütleme, et keerulise süsteemi käitumist määrab selle osade vaheline interaktsioon, siis mis meid peaks huvitama? Interaktsioon.
On veel kaks huvitavat järeldust.
Esiteks mõistame me, et keerulist süsteemi ei ole võimalik lihtsustada, lihtsustades selle osi. Teiseks on ainus viis keerulise süsteemi lihtsustamiseks sujuvamate interaktsioonide loomine selle osade vahel.
Kuidas me suhtleme? Me kõik oleme osa suurest teabe süsteemist, mida nimetatakse inimühiskonnaks. Me suhtleme ühise keele kaudu, kui see meil olemas on, kui me selle leiame.
Aga keel iseenesest on keeruline kohandatav süsteem. Seega, et suhelda tõhusamalt ja lihtsamalt, on meil vaja luua teatud protokolle. See tähendab teatud sümbolite ja tegevuste järjekorda, mis muudavad meie vahelise teabevahetuse lihtsamaks, ettenähtavamaks ja arusaadavamaks.
Ma tahan öelda, et keerukas, kohandav, detsentraliseeritud ja kaootiline käitumine on jälgitav kõikjal. Nii neis süsteemides, mida me loome, kui ka neis süsteemides, mille osa me oleme.
Kuna ma ei soovi rääkida tühja juttu, vaatame, kuidas muutuvad need süsteemid, mida me koos loome.
Sa ootasid seda sõna, ma saan aru. Oleme DevOps konverentsil, see sõna kuuldub täna kuskil sada tuhat korda ja see tuleb meile öösel unedesse.
Mikroteenused on esimene tarkvaraarhitektuur, mis tekkis vastusena DevOpsi praktikale, mille eesmärk on muuta meie süsteemid paindlikumaks, skaleeritavamaks ja tagada pidev toimetamine. Kuidas see seda teeb? Teenuste mahu vähendamise, probleemipiiride kitsendamise ja toimetamise ajaperioodi lühendamise kaudu. See tähendab, et me vähendame ja lihtsustame süsteemi osi, suurendame nende arvu, mistõttu suurenenud keerukus nende osade vahelise suhtluse osas toob kaasa uusi probleeme, mida peame lahendama.
Mikroteenused ei ole veel lõpp, mikroteenused on tegelikult juba eilne päev, sest on tulnud Serverless. Kõik serverid on kadunud, servereid pole, operatsioonisüsteeme pole, ainult puhas täidetav kood. Konfiguratsioonid eraldi, olekud eraldi, kõik juhitakse sündmustega. Ilu, puhtus, rahu, mitte midagi ei juhtu, kõik on korras.
Kus on keerukus? Keerukus on ilmselgelt suhtlemises. Kui palju saab üks funktsioon üksi teha? Kuidas ta suhtleb teiste funktsioonidega? Sõnumijoone, andmebaaside, koormuse jaotajate kaudu. Kuidas taastada mingi sündmus, kui see ebaõnnestub? Palju küsimusi ja vähe vastuseid.
Mikroteenused ja Serverless on kõik, mida meie arvuti hipsterid kutsume Cloud Native. See kõik on seotud pilvega. Kuid pilv on oma olemuselt samuti piiratud skaleeritavuse poolest. Oleme harjunud mõtlema sellele kui jaotatud süsteemile. Tegelikult, kus elavad pilveteenuse pakkujate serverid? Andmekeskustes. See tähendab, et meil on siin teatud tsentraliseeritud, väga piiratud jaotatud mudel.
Täna mõistame, et asjade internet ei ole enam ainult kõlavaid sõnu selle kohta, et isegi tagasihoidlike ennustuste kohaselt ootab meid järgmistel viiel-kümnel aastal miljardeid seadmeid, mis on ühendatud internetiga. Suur hulk kasulikke ja kasutu andmeid, mis voolavad pilve ja laaditakse pilvest alla.
Pilv ei suuda sellega hakkama saada, seetõttu räägime üha enam sellest, mida nimetatakse "äärmise arvutuse" (edge computing). Või mulle meeldib ka imeline määratlemine "fog computing". See on kaetud romantismi ja müsteeriumi müütilise kihiga.
Uduvad arvutamisel räägitakse sellest, et pilved on tsentraliseeritud vee, auru, jää ja kivide kogumid. Udu on aga veepiisad, mis on meie õhus laiali jaotatud.
Udusfääris teevad enamik tööst iseseisvalt või koostöös teiste pisikestega need veepiisad. Nad pöörduvad pilve poole ainult siis, kui on tõeliselt hädasti vaja.
Seega räägime jälle detsentraliseerimisest, autonoomsusest, ja loomulikult mõistavad paljud teist juba, kuhu see kõik viib, sest ei saa rääkida detsentraliseerimisest, ilma et mainiksime plokiahelat.
On neid, kes usuvad, need, kes on investeerinud krüptovaluutasse. On neid, kes usuvad, aga kardavad, nagu mina näiteks. Ja on ka neid, kes ei usu. Siin on erinevaid seisukohti. On tehnoloogia, uus arusaam, ja on probleeme. Nagu iga uus tehnoloogia, tõstatab see rohkem küsimusi, kui annab vastuseid.
Hüpe plokiahela ümber on arusaadav. Isegi kui kõrvale jätta kullakaevanduse ülemäärane interesse, lubab see tehnoloogia helget tulevikku: rohkem vabadust, rohkem autonoomiat, jagatud globaalset usaldust. Mida siin mitte soovida?
Seega hakkab üha rohkem insenere üle kogu maailma arendama detsentraliseeritud rakendusi. Ja see on jõud, millest ei saa lihtsalt öelda: 'Ahh, plokiahel on lihtsalt halvasti rakendatud jagatud andmebaas.' Või nagu skeptikud armastavad öelda: 'Plokiahelal ei ole tegelikke rakendusi.' Kui järele mõelda, siis 150 aastat tagasi räägiti samasuguseid asju elektri kohta. Ja isegi mingis osas olid nad õiged, sest see, mida elekter täna võimaldab, oli 19. sajandil täiesti ebatõenäoline.
Muide, kes teab, mis logo ekraanil on? See on Hyperledger. See on projekt, mis on arendatud The Linux Foundationi eestvedamisel, sisaldades rida plokiahela tehnoloogiaid. See on tõeliselt meie avatud koodi kogukonna jõud.
Kaosetehnoloogia
Nii et süsteem, mida me arendame, muutub üha keerulisemaks, üha kaootilisemaks, üha kohanemisvõimelisemaks. Netflix on mikroteenuste süsteemide pioneer. Nad olid ühed esimesed, kes seda mõistsid, ja nad töötasid välja hulga tööriistu, mida nad nimetasid Simian Army, millest tuntum on . Ta määratles selle, mis sai tuntuks kui .
Muide, ettekande kallal töötades tõlkisime selle teksti vene keelde, nii et käige läbi , loe, kommenteeri, kritiseeri.
Lühidalt, kaose insenerimise põhimõtted ütlevad järgmist. Komplekssed hajusad süsteemid on oma olemuselt ettearvamatud ja neis on paratamatult vigu. Vead on vältimatuid, seega peame need vead aktsepteerima ja nendega täiesti teisiti töötama.
Me peame ise proovima need vead meie tootmisüsteemidesse tuua, et testida meie süsteemide kohanduvust, eneseorganiseerimise võimet ja ellujäämisvõimet.
Ja see muudab kõik. Mitte ainult seda, kuidas me süsteemi tootmisesse viime, vaid ka seda, kuidas me neid arendame ja testime. Stabiliseerimisprotsessi, koodi külmutamist pole; hoopis vastupidi, pidev destabiliseerimise protsess. Me püüame süsteemi hävitada ja näha, kas see suudab ellu jääda.
Hajus süsteemide integreerimisprotokollid
Seetõttu peab meie süsteem ka mingil moel muutuma. Et nad muutuksid vastupidavamaks, vajavad nad uusi suhtlemisprotokolle oma osade vahel. Et need osad suudaksid kokkuleppele jõuda ja mingisugust eneseorganiseerimist saavutada. Ja tekivad erinevad uued tööriistad, uued protokollid, mida ma nimetan "hajusate süsteemide suhtlemisprotokollideks".
Millest ma räägin? Esiteks, projektist . Üks katse luua ühine hajus jälgimisprotokoll, mis on täiesti asendamatu tööriist keerukate hajusate süsteemide tõrkeotsinguks.
Next is . Me ütleme, et me ei saa ette näha, mis meie süsteemiga juhtub, seega on vajalik tõsta selle observability, jälgitavust. Opentracing kuulub vahendite perekonda, mis pakuvad meie süsteemide jälgitavust. Kuid jälgitavust vajame selleks, et määrata, kas süsteem käitub nii, nagu me seda ootame, või mitte. Kuidas me määrame oodatava käitumise? Selle kaudu, et määratleme selles mingisuguse poliitika, mingisuguse reeglite kogumi. Open Policy Agent projekt tegeleb nende reeglite kogumi määratlemisega laias spektris: juurdepääsust kuni ressursside paigutamiseni.
Nagu me ütlesime, meie süsteemid muutuvad üha enam sündmustel põhinevaks. Serverless on suurepärane näide sündmustel põhinevatest süsteemidest. Selleks, et saaksime edastada sündmusi süsteemide vahel ja neid jälgida, on meil vajalik ühine keel, mingi protokoll, kuidas me räägime sündmustest, kuidas me neid üksteisele edastame. Sellega tegeleb projekt nimega .
Katkestamatu muudatuste voog, mis peseb meie süsteeme ja pidevalt neid destabiliseerib, on katkestamatu voog tarkvaralisest artefaktist. Selleks, et saaksime toetada seda pidevat muudatuste voogu, on meil vajalik ühine protokoll, mille abil me suudame rääkida, mis on tarkvaraline artefakt, kuidas see on kontrollitud, millise verifikatsiooni see on läbinud. Sellega tegeleb projekt nimega . Seega on see ühine protokoll tarkvaraliste artefaktide metainfo jaoks.
Ja lõpuks, kui me tahame, et meie süsteemid oleksid täiesti iseseisvad, kohanduvad ja isekorralduvad, peame andma neile õiguse isee ütlemise. Projekt nimega just sellega tegeleb. See on samuti projekt Cloud Native Computing Foundationi all.
Kõik need projektid on noored, nad vajavad kõiki meie armastust, meie kontrolli. See on kõik avatud kood, meie testimine, meie rakendamine. Nad näitavad meile, millises suunas tehnoloogia liigub.
Aga DevOps ei ole kunagi olnud peamiselt tehnoloogia, vaid alati on olnud see koostöö inimeste vahel. Ja seetõttu, kui me tahame, et süsteemid, mida me arendame, muudaksid, peame muutuma ka meie. Tegelikult me juba muutume, meil ei ole justkui valikut.
On imeline Briti kirjanik Rachel Botsmani teos, kus ta kirjutab usalduse arengust inimkonna ajaloos. Ta ütleb, et algselt, primitiivsetes ühiskondades, oli usaldus lokaalset, see tähendab, et me usaldasime ainult neid, keda me isiklikult teadsime.
Seejärel järgnes väga pikk periood - pime aeg, mil usaldus oli keskne, mil me hakkasime usaldama inimesi, keda me ei tunne, tuginedes sellele, et me kuulume sama sotsiaalse või riikliku institutsiooni alla.
Ja see, mida me täna näeme meie kaasaegses maailmas: usaldus muutub üha jagatumaks ja detsentraliseeritumaks ning selle aluseks on teabevoolude vabadus ja teabe kättesaadavus.
Kui järele mõelda, siis seda kättesaadavust, mis muudab usalduse võimalikuks, viime me ellu. See tähendab, et ka see, kuidas me koostööd teeme ja mida me teeme, peab muutuma, sest tsentraliseeritud hierarhilised IT-organisatsioonid vanast koolist lakavad toimimast. Need hakkavad kaduma.
DevOps-organisatsioonide alused
Täiuslik DevOps-organisatsioon tulevikus on detsentraliseeritud, kohandatav süsteem, mis koosneb iseseisvatest meeskondadest, milles igaühes on iseseisvad indiviidid. Need meeskonnad on laiali üle kogu maailma ning nad teevad tõhusalt koostööd asün kroonsete kommunikatsioonide ja läbipaistvate teabevahetusprotokollide kaudu. Väga ilus, eks? Väga kaunis tulevik.
Loomulikult on see kõik võimatu ilma kultuuriliste muutusteta. Meil peavad olema transformatsiooni juhtimine, isiklik vastutus ja sisemine motivatsioon.
See on DevOps-organisatsioonide alus: teabe läbipaistvus, asünkroonsed suhtlused, transformatiivne juhtimine, detsentraliseeritus.
Põlemine
Süsteemid, osa millest me oleme, ja need, mida me ehitame, muutuvad järjest keerulisemaks, ja meie, inimesed, oleme selle mõttega raskustes, on raske loobuda kontrolli illusioonist. Me püüame neid jätkuvalt kontrollida ja see viib sageli põlemiseni. Räägin seda oma kogemuse põhjal, olen ka selle läbi elanud, olen samuti ettenägematute tõrgete ohver.
Põlemine juhtub siis, kui püüame kontrollida seda, mis ei ole olemuslikult kontrollitav. Kui me põleme läbi, kaotab kõik mõtte, kuna me kaotame soovi luua midagi uut, me võtame kaitsepositsiooni ja hakkame kaitsma seda, mis meil on.
Inseneri amet, nagu ma endale tihti meelde tuletan, on eelkõige loominguline amet. Kui me kaotame soovi midagi luua, muutume me tuhkadeks, muutume meil tollest. Inimesed põlevad läbi, põlevad läbi terved organisatsioonid.
Minu arvates on ainus viis, kuidas mitte kaotada head, mis on meie ametis, aktsepteerida loovuse kaose jõudu ja ehitada koostööd selle printsiipide alusel.
Seda ma teile soovin: armastage oma tööd, armastage seda, mida me teeme. See maailm elab teabest, meil on au teda toita. Niisiis, õppigem kaost, olgem kaosolooge, toogem väärtust, looge midagi uut ja probleemid, nagu oleme juba avastanud, on vältimatud; kui need ilmuvad, siis ütleme lihtsalt "Ops!" ja probleem on lahendatud.
Mis peale Chaos Monkey?
Tegelikult on kõik need tööriistad nii noored. Netflix ehitas ka kõik tööriistad enda jaoks. Ehitage tööriistad enda jaoks. Loe kaose inseneri printsiipide kohta ja järgige neid printsiippe, mitte ärge otsige teisi tööriistu, mida keegi teine on juba ehitanud.
Püüdke mõista, kuidas teie süsteemid purunevad ja hakake neid purustama, et näha, kuidas nad lööke taluvad. See on esmatähtis. Tööriistu saab alati otsida. Projekte on igasuguseid.
Ma ei saanud täpselt aru hetkes, kui rääkisite, et süsteemi ei saa lihtsustada selle komponente lihtsustades, ja kohe läksite mikroteenuste juurde, mis just lihtsustavad süsteemi komponentide lihtsustamise kaudu ja keerukust suurendades. Tõepoolest, need on kaks omavahel vastuolus olevat osa.
Täiesti õige, mikroteenused on väga vastuoluline teema. Tegelikult tõstab osade lihtsustamine paindlikkust. Mida mikroteenused meile pakuvad? Nad pakuvad meile paindlikkust ja kiirus, kuid lihtsust nad meile kindlasti ei too. Need suurendavad keerukust.
Seega, DevOpsi filosoofias, pole mikroteenused mingi suur õnnistus?
Igal õnnistusel on tagaküljed. On õnnistus: see tõstab paindlikkust, annab meile võimaluse kiiremini muudatusi sisse viia, kuid suurendab süsteemi keerukust ja seega ka haprust.
Kumale rohkem rõhku panna: suhtluse lihtsusele või osade lihtsusele?
Fookus on kindlasti interaktsiooni lihtsustamisel, sest kui me vaatame seda, kuidas me koos töötame, siis tuleb eelkõige pöörata tähelepanu suhtlemise lihtsustamisele, mitte igaühe töö lihtsustamisele. Sest töö lihtsustamine — see muudab meid robotiteks. McDonald'sis toimib see hästi, kui sul on ette antud: siia paned burgeri, siia valad kastme. Meie loomingulises töös see täielikult ei tööta.
Kas tõsi on, et kõik, mida te rääkisite, elab konkurentsivaba maailmas, kus segadus on hea ja seal pole konfliktide, keegi ei soovi kedagi süüa või tappa? Kuidas peaks konkurents ja DevOps elama?
See sõltub sellest, millest konkurentsist me räägime. Kas töökohal või ettevõtete vahelisest konkurentsist?
Teenuste konkurentsist, mis eksisteerib, sest teenused — need ei ole mitte ainult mõned ettevõtted. Me loome uue tüüpi teavet keskkonda, ja ükski keskkond ei saa elada ilma konkurentsita. Konkurents on igal pool.
Võtame näiteks Netflixi kui rollimudeli. Miks nad selle välja töötasid? Sest nad pidid olema konkurentsivõimelised. see paindlikkus ja liikumise kiirus on just nimelt see konkurentsinõue, see toob kaootilisuse meie süsteemidesse. Nii et kaos ei ole see, mida me teadlikult teeme, sest me seda soovime, see on see, mis juhtub, kuna maailm seda nõuab. Meil tuleb lihtsalt kohanduda. Ja kaos on tõepoolest konkurentsi tulemus.
Kas see tähendab, et kaos on eesmärkide puudumine? Või need eesmärgid, mida me ei soovi näha? Me oleme majakeses ja ei mõista teiste eesmärke. Tegelikult on konkurents tingitud sellest, et meil on selged eesmärgid ja me teame, kuhu me iga järgmise hetke jooksul jõuame. Minu arust on see DevOpsi olemus.
Samuti on see vaade küsimusele. Ma arvan, et meie kõigi eesmärk on sama: ellu jääda ja teha seda
maksimaalse naudingu juures. Ja igal organisatsioonil on sama konkurentsi eesmärk. Ellujäämine toimub sageli konkurentsivõitluses, siin ei saa midagi teha.
Sel aastal toimub konverents 7. detsembril «Tehnopolis». Me võtame ettekandeteemade ettepanekuid vastu kuni 11. novembrini. meile, kui soovite esineda.
Registreerimine osalejate jaoks on avatud, pileti hind on 7000 rubla. Liituge meiega!
Allikas: habr.com
