Otomato Software'i asutaja ja direktor, esimese DevOps-sertifitseerimise algataja ja instruktori Antont Weiss rääkis eelmisel aastal kaose teooriast ja kaose inseneritehnika põhialustest, samuti selgitas ta, kuidas peaks olema ideaalne tuleviku DevOps-organisatsioon.
Oleme valmistanud ette raporti kirjaliku versiooni.
Tere hommikust!
DevOpsDays toimub Moskvas teist aastat järjest, mina olen teist korda sellel laval, paljud teist on selles saalis teist korda. Mis see aga tähendab? See tähendab, et DevOps-liikumine Venemaal kasvab, paljuneb, ja mis kõige olulisem, on aeg rääkida, mis on DevOps 2018. aastal.
Küsin, kes teie seas arvab, et 2018. aastal on DevOps juba amet? On selliseid. Kas saalis on DevOps-insenere, kelle tööülesannete kirjas seisab „DevOps-insener”? Kas saalis on DevOps-juhtijaid? Selliseid ei ole. DevOps-arhitekte? Ka neid pole. Üksjagu vähe. Kas tõesti kellelgi ei seisa kirjas, et ta on DevOps-insener?
Nii et enamik teist arvab, et see on anti-muster? Et sellist ametit ei tohiks olla? Me võime arvata, mida iganes, aga seni, kuni me arvame, liigub tööstus pidulikult edasi DevOps-pilli helide saatel.
Kes on kuulnud uuest teemast, mis kannab nime DevDevOps? See on selline uus meetod, mis võimaldab tagada tõhusat koostööd arendajate ja devopside vahel. Ja kuigi see ei ole nii uus. Kui vaadata Twitterit, siis hakati sellest rääkima juba neli aastat tagasi. Ja siiani kasvab huvi selle vastu üha enam, mis tähendab, et probleem on olemas. Probleem tuleb lahendada.
Me oleme loomingulised inimesed, me ei rahuldu lihtsalt niisama. Meie ütleme: DevOps on liiga kitsas mõisted, seal puuduvad erinevad huvitavad elemendid. Ja me läheme oma salajatesse laboritesse ning hakkame looma uudseid mutatsioone: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Loogika on raudne, eks? Meil on funktsionaalne tarnesüsteem, meie süsteemid on ebastabiilsed ja kasutajad on rahulolematud, me ei suuda tarkvara õigeaegselt välja anda, me ei püsi eelarves. Kuidas me seda kõike lahendame? Me leiame välja uue sõna! See lõpeb "Ops"-iga ja probleem on lahendatud.
Nii ma kutsun seda lähenemist — "Ops ja probleem on lahendatud."
See jääb taustale, kui me tuletame endale meelde, miks me kõik selle välja mõtlesime. Me välja mõeldud DevOps, et tarkvara tarnimine ja meie töö selles protsessis oleks võimalikult sujuv, valutuks, efektiivne ja mis kõige tähtsam, meeldiv.
DevOps kasvas valust. Ja me oleme sellest tüdinud. Et see kõik toimuks, põhineme me igikestvatel praktikatel: tõhus koostöö, voolupraktikad, ja mis kõige tähtsam, süsteemne mõtlemine, sest ilma selleta ei tööta ükski DevOps.
Mis on süsteem?
Ja kui me juba süsteemsest mõtlemisest räägime, siis tuletame endale meelde, mis on süsteem.
Kui sa oled hackeri-revolutsionäär, siis on süsteem sinu jaoks üheselt paha. See on pilv, mis hangub sinu kohale ja sunnib sind tegema seda, mida sa ei taha.
Süsteemse mõtlemise seisukohalt on süsteem tervik, mis koosneb osadest. Sellest vaatenurgast on igaühel meist süsteem. Organisatsioonid, kus me töötame, on süsteemid. Ja see, mida me koos loome, nimetatakseki - süsteem.
Kõik see on osa ühest suurest sotsiaaltehnoloogilisest süsteemist. Alles siis, kui me mõistame, kuidas see sotsiaaltehnoloogiline süsteem koos toimib, suudame me selles küsimuses tõeliselt optimeerida.
Süsteemse mõtlemise seisukohalt on süsteemil mitmeid huvitavaid omadusi. Esiteks koosneb see osadest, mis tähendab, et selle käitumine sõltub osade käitumisest. Samuti on kõik selle osad omavahel sõltuvad. Tulemuseks on see, et mida rohkem osasid süsteemil on, seda keerulisem on mõista või ennustada selle käitumist.
Käitumise seisukohalt on veel üks huvitav fakt. Süsteem suudab teha midagi sellist, mida ei suuda ükski selle eraldi osa.
Nagu ütles doktor Russell Ackoff (üks süsteemse mõtlemise rajajaid), on seda üsna lihtne tõestada mõttemängu abil. Näiteks, kui palju inimesi saalis oskab kirjutada koodi? Palju käsi, ja see on normaalne, sest see on meie ametialase töö üks põhitingimusi. Te kirjutate koodi, aga kas teie käed eraldi teevad seda? On inimesi, kes ütlevad: „Minu käed ei kirjuta koodi, mu aju kirjutab koodi.” Aga kas aju saab eraldi teilt koodi kirjutada? Tõenäoliselt ei saa.
Aju on imeline masin, me ei tea isegi 10% selle tööst, kuid toimida eraldi süsteemist, milleks on meie organism, ta ei saa. Ja 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 tema osa eraldi teha ei saa, siis tähendab see, et tema käitumine ei ole määratud tema osade käitumisega. Mida siis määrab? Seda määravad nendel osadel olevad interaktsioonid. Seega, mida rohkem osi, seda keerulisemad on interaktsioonid ja seda keerulisem on süsteemi käitumist mõista ja ennustada. See muudab süsteemi kaootiliseks, kuna igasugune, isegi kõige ebaolulisem, silmale nähtamatu muutus mõnes süsteemi osas võib viia täiesti ettenägematute tulemusteni.
Seda tundlikkust algtingimuste suhtes avastas ja uuris esmakordselt Ameerika meteoroloog Ed Lorenz. Hiljem kutsuti seda «liblikaeffect'iks» ja see viis teadusliku mõtlemise suuna kujunemiseni, mida tuntakse kui «kaose teooria». See teooria osutus üheks peamiseks paradigmamuutuseks 20. sajandi teaduses.
Kaose teooria
Inimesed, kes uurivad kaost, nimetavad end kaosoloogideks.
Tegelikult oli selle ettekande põhjuseks see, et töötades keeruliste hajutatud süsteemide ja suurte rahvusvaheliste organisatsioonidega, mõistsin ühel hetkel, et see on see, kellega ma end tunnen. Olen kaosoloog. See on omamoodi nutikas viis öelda: "Ma ei saa aru, mis siin toimub ja ei tea, mida sellega teha."
Mõtlen, et paljusid teist tunnevad end sageli samamoodi, seega olete ka teie kaosoloogid. Kutsun teid liituma kaosoloogide gildiga. Süsteemid, mida me, kallid kolleegid kaosoloogid, uurime, nimetatakse "keerukateks kohanduvateks süsteemideks".
Mis on kohanduvus? Kohanduvus tähendab, et osade individuaalne ja kollektiivne käitumine sellises kohandavas süsteemis muutub ja organiseerib end ümber, reageerides süsteemis toimuvatele sündmustele või mikro-sündmuste ahelatele. See tähendab, et süsteem kohandub muutustega läbi iseorganiseerumise. Ja see iseorganiseerumise võime põhineb vabatahtlikul, täielikult de.ts.5entraliseeritud koostööl vabade autonoomsete agentide vahel.
Veel huvitav omadus sellistes süsteemides on see, et need on vabalt skaleeritavad. See peaks huvitama meid kui kaosest insenerid. Kui me ütleme, et keerulise süsteemi käitumine määratakse selle osadevahelise suhtluse kaudu, siis mis peaks meid huvitama? Suhtlus.
On kaks huvitavat järeldust.
Esiteks mõistame, et keerulist süsteemi ei saa lihtsustada, lihtsustades selle osi. Teiseks on ainus viis keerulise süsteemi lihtsustamiseks lihtsustada selle osadevahelist suhtlemist.
Kuidas me suhtleme? Me kõik oleme osa suurest infosüsteemist, mida nimetatakse inimkonnaks. Me suhtleme ühise keele abil, kui see meil on, kui me selle leiame.
Aga keel iseenesest on keeruline kohandatav süsteem. Seega, et suhelda tõhusamalt ja selgemalt, on meil vaja luua mingisuguseid protokolle. See tähendab mingit sümbolite ja toimingute järjestust, mis muudab meie vahelise teabevahetuse lihtsamaks, ennustatavamaks ja arusaadavamaks.
Soovin öelda, et tendentsid keerukuse, kohandatavuse, detsentraliseerimise ja kaootilisuse suunas on kõikjal. Nii süsteemides, mida me koos loome, kui ka süsteemides, mille osa me oleme.
Ja et mitte olla sõnadega tühjad, vaatame, kuidas muutuvad need süsteemid, mida me koos loome.
Te ootasite seda sõna, ma mõistan. Oleme DevOps konverentsil, täna kõlab see sõna kuskil sada tuhat korda ja siis tuleb see meile öösel unenäos.
Mikroteenused on esimene tarkvaraarhitektuur, mis tekkis vastusena DevOps praktikatele, tuues meie süsteemidesse suuremat paindlikkust, skaleeritavust ja tagades pideva kohaletoimetamise. Kuidas see saavutatakse? Teenuste arvu vähendamise, probleemide piire vähendamise ja kohaletoimetamise aja lühendamise abil. Ehk me vähendame, lihtsustame süsteemi osi, suurendame nende arvu, mille tulemusena suureneb suhtlemise keerukus nende osade vahel ja tekivad uued probleemid, mida peame lahendama.
Mikroteenused ei ole veel lõpp — need on tegelikult juba eilne päev, sest jõuab Serverless. Kõik serverid on hävitatud, servereid ei ole, ei ole operatsioonisüsteeme, ainult puhas käivitatav kood. Konfiguratsioonid eraldi, seisundid eraldi, kõik haldab sündmusi. Ilu, puhtus, vaikus, ei ole sündmusi, ei juhtu midagi, täielik kord.
Kus on keerukus? Keerukus on selgelt interaktsioonides. Kui palju suudab üks funktsioon üksi teha? Kuidas see suhtleb teiste funktsioonidega? Sõnumijärjekorrad, andmebaasid, koormuse jaotajad. Kuidas luua mingit sündmust uuesti, kui juhtub rike? Palju küsimusi ja vähe vastuseid.
Mikroteenused ja Serverless on kõik see, mida meie, arvutikultuuri hipsterid, nimetame Pilv Native. See on kõik pilve kohta. 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 mingi tsentraliseeritud, väga piiratud, jaotatud mudel.
Täna mõistame, et asjade Internet pole enam ainult kõlavaid sõnu. Isegi tagasihoidlikud prognoosid näitavad, et järgmise viie kuni kümne aasta jooksul ootavad meid miljardid seadmed, mis on internetiga ühendatud. Suure hulga kasulike ja kasutu andmete voog, mis voolab pilve ja voolab pilvest välja.
Pilv ei tule selle koormusega toime, seetõttu räägime järjest rohkem sellest, mida tuntakse kui 'äärmuslikud arvutused'. Või mulle meeldib ka suurepärane määratlus 'uulutatud arvutamine'. See on kaetud romantismi ja saladuslikkuse müsteeriumiga.
Uulutatud arvutused. Jutt on sellest, et pilved on tsentraliseeritud vee, auru, jää ja kivide kogunemiskohad. Ning uulutus on veepiisad, mis on hajutatud meie ümber atmosfääri.
Uulutatud paradigma puhul täidavad enamik tööst nende tilgad täiesti iseseisvalt või koostöös teiste tilkadega. Nad pöörduvad pilve poole, ainult siis, kui tõeliselt vajavad abi.
See tähendab taas detsentraliseerimist, iseseisvust, ja loomulikult mõistavad paljud teist, kuhu see kõik läheb, sest ei saa rääkida detsentraliseerimisest, mainimata plokiahelat.
On inimesi, kes usuvad, et krüptovaluutasse investeerimine on õigustatud. On neid, kes usuvad, kuid kardavad, nagu mina. Ja on ka neid, kes ei usu. Siin võib suhtuda erinevalt. On tehnoloogia, uus ja arusaamatu asi, on probleeme. Nagu iga uus tehnoloogia, tekitab see rohkem küsimusi kui vastuseid.
Hype plokiahela ümber on arusaadav. Isegi kui tõukame kõrvale kuldaahnuse, pakub tehnoloogia iseenesest imelisi lubadusi helgest tulevikust: rohkem vabadust, rohkem autonoomiat, globaalne jaotatud usaldus. Mida siin ei võiks soovida?
Seetõttu hakkab järjest rohkem insenere üle kogu maailma arendama detsentraliseeritud rakendusi. See on jõud, millest ei saa lihtsalt mööda vaadata, öeldes: „Ah, plokiahel on lihtsalt halvasti rakendatud jaotatud andmebaas.” Või nagu skeptikud meeldib öelda: „Plokiahela jaoks pole mingit reaalset kasutust.” Kui süveneda, siis 150 aastat tagasi öeldi sama elektri kohta. Ja mingil määral oli neil õigus, sest see, mida elekter täna võimaldab, oli 19. sajandil täiesti väljastpoolt mõeldamatu.
Muide, kas keegi teab, mis logo ekraanil on? See on Hyperledger. See on projekt, mida arendatakse The Linux Foundationi juhtimisel, ja see hõlmab mitmeid plokiahelatehnoloogiaid. See on tõeliselt meie avatud lähtekoodiga kogukonna jõud.
Kaosetehnika
Nii et süsteem, mida me koos arendame, muutub järjest keerulisemaks, kaootilisemaks ja paindlikumaks. Netflix oli mikroteenuste süsteemide pioneer. Nad olid esimesed, kes seda mõistsid, ja nad arendasid välja tööriistade kogumi, mida nad nimetasid Simian Army, mille kõige tuntumaks osaks sai . See määratles selle, mis sai tuntuks kui .
Muide, töötades ettekande kallal, tõlkesime isegi selle teksti vene keelde, nii et tulge , lugema, kommenteerima, kritiseerima.
Lühidalt öeldes ütlevad kaosetehnika põhimõtted järgmist. Keerulised jaotatud süsteemid on iseenesest ettearvamatud ja neis esinevad vead. Vead on vältimatud, mis tähendab, et peame need vead aktsepteerima ja nendes süsteemides täiesti teistmoodi töötama.
Meie süsteemid peavad ise proovima neid vigu oma tootmissüsteemides, et testida meie süsteemide kohanduvust, enesekehtivuse ja ellujäämisvõimet.
Ja see muudab kõike. Mitte ainult seda, kuidas me süsteemi tootmisse paneme, vaid ka seda, kuidas me neid arendame ja testime. Stabiliseerimisprotsesse ega koodi külmutamist ei ole, pigem on jätkuv destabiliseerimisprotsess. Püüame süsteemi tappa ja näha, kuidas see jätkuvalt ellu jääb.
Jaotatud Süsteemide Integreerimise Protokollid
Seetõttu nõuab see meie süsteemidelt, et nad samuti muutuksid. Et nad muutuksid stabiilsemaks, vajavad nad uusi suhtlusprotokolle oma osade vahel. Et need osad saaksid kokkuleppele ning jõuda mingisuguse enesekorralduse järgimisele. Seal sünnivad igasugused uued tööriistad ja protokollid, mida ma kutsun "jaotatud süsteemide suhtlusprotokollideks".
Mille üle ma räägin? Esiteks, projekt . Ühe katse loomine jaotatud jälgimise üldprotokoll, mis on täiesti hädavajalik tööriist keerukate jaotatud süsteemide tõrgete leidmiseks.
Jätkame — . Me ütleme, et me ei suuda ennustada, mis meie süsteemiga juhtub, seega peame suurendama selle observability, jälgitavust. Opentracing kuulub nende tööriistade perekonda, mis pakuvad meie süsteemide jälgitavust. Aga jälgitavus on vajalik selleks, et määrata, kas süsteem käitub nii, nagu me ootame, või mitte. Kuidas me määrame oodatud käitumise? Selle määratlemise kaudu mingisuguse poliitika, reeglikogu kaudu. Open Policy Agent projekt tegeleb selle reeglikogu määratlemisega laias valikus valdkondades: juurdepääsust kuni ressursside paigutamiseni.
Kuidas me ütlesime, meie süsteemid muutuvad üha enam sündmustepõhiseks. Serverless on suurepärane näide sündmustepõhistest süsteemidest. Et saaksime edastada sündmusi süsteemide vahel ja neid jälgida, vajame mingit ühist keelt, mingit üldprotokolli selle kohta, kuidas me räägime sündmustest, kuidas me üksteisele neid edastame. Sellega tegeleb projekt nimega .
Jätkuv muutuste voog, mis peseb meie süsteeme, destabiliseerides neid pidevalt, on pidev tarkvaraliste artefaktide voog. Selleks, et suudaksime säilitada seda pidevat muutuste voogu, on meil vaja mingi ühist protokolli, mille abil saame rääkida sellest, mis on tarkvaraline artefakt, kuidas see on kontrollitud ja millise valideerimise see on läbinud. Sellega tegeleb projekt nimega . See tähendab, et tarkvaraliste artefaktide metandmete ühine protokoll.
Ja lõpuks, kui me tahame, et meie süsteemid oleksid täielikult iseseisvad, kohanemisvõimelised, enesekorraldusega, peame andma neile õiguse enesetuvastamiseks. Projekt nimega tegeleb just sellega. See on samuti Cloud Native Computing Foundation'i alluvuses olev projekt.
Kõik need projektid on noored, nad vajavad meie armastust, meie kontrolli. Kõik see on avatud kood, meie testimine, meie rakendamine. Nad näitavad meile, millises suunas tehnoloogia liigub.
Kuid DevOps ei ole kunagi olnud eelkõige tehnoloogiast, vaid see on alati olnud koostööst inimeste vahel. Seega, kui me tahame, et meie arendatavad süsteemid muutuksid, peame ka meie ise muutuma. Tegelikult muutume me niikuinii, meil ei ole tegelikult muud valikut.
On suurepärane Briti kirjaniku Rachel Botsmani poolt, kus ta kirjutab usalduse arengust põhimõtteliselt inimkonna ajaloos. Ta ütleb, et alguses, primitiivsetes ühiskondades, oli usaldus kohaliku, st me usaldasime ainult neid, keda me isiklikult teadsime.
Seejärel oli väga pikk periood – pime aeg, kui usaldus oli tsentraliseeritud, kui me hakkasime usaldama inimesi, keda me ei tunne, lähtudes sellest, et me kuulusime samasse sotsiaal- või riigiasutusse.
Ja siin on see, mida me näeme oma kaasaegses maailmas: usaldus muutub üha enam jagunemiseks ja detsentraliseerimiseks ning see põhineb vabade infovoogude ja teabe kergelt kättesaadavuse loomisel.
Kui süveneda, on just see kergesti kättesaadavus, mis muudab usalduse võimalikuks, see on meie ühiselt tehtud. See tähendab, et muutuda peab nii meie koostööpõhimõtted kui ka teostusviis, kuna vanamoodsad tsentraliseeritud IT-organisatsioonid lakavad toimimast. Need hakkavad hääbuma.
DevOps-organisatsioonide alused
Ideaalne tuleviku DevOps-organisatsioon on de tsentraliseeritud, kohandatav süsteem, mis koosneb autonoomsetest meeskondadest, millest igaühes on iseseisvad indiviidid. Need meeskonnad on laiali hajutatud üle kogu maailma ning nad suhtlevad tõhusalt omavahel asünkroonsete kommunikatsioonikanalite ja läbipaistvate teabevahetusprotokollide abil. Väga kaunis, eks? Väga ilus tulevik.
Loomulikult ei ole see kõik võimalik kultuuriliste muutusteta. Meil peavad olema transformatiivne juhtimine, isiklik vastutus, sisemine motivatsioon.
See ongi DevOps-organisatsioonide alus: teabe läbipaistvus, asünkroonsed suhted, transformatiivne juhtimine, de tsentraliseerimine.
Väsimus
Süsteemid, millesse me kuulume ja mida me ehitame, muutuvad järjest kaootilisemaks ja me, inimesed, leiame selle mõttega raskusi, on keeruline loobuda kontrolli illusioonist. Püüame neid jätkuvalt kontrollida, mis tihti viib läbipõlemiseni. Räägin seda oma kogemuse põhjal; olen ka põletanud, olen ka ootamatute tõrgete ohver.
Läbipõlemine toimub siis, kui püüame kontrollida seda, mis tegelikult kontrollimisele ei allu. Kui me läbipõleme, kaotab kõik mõtte, sest kaotame soov teha midagi uut, astume kaitsepositsioonile ja hakkame kaitsma seda, mis meil on.
Inseneri amet on, nagu mulle meeldib endale sageli meelde tuletada, eelkõige loominguline amet. Kui me kaotame soov teha midagi, muutume tuhkadeks, muutume ahjuks. Inimesed põlevad läbi, põlevad terved organisatsioonid.
Minu arvates aitab ainult kaose loovuse aktsepteerimine, ainult koostöö loomine selle põhimõtete alusel — see on see, mis aitab meil mitte kaotada seda head, mis meie ametis on.
Soovin teile, et armastaksite oma tööd ja teeksime seda, mida armastame. See maailm toitub teabest ning meil on au seda toita. Nii et õppigem kaost, olgem kaosteadlased, toome väärtust, loome midagi uut, ja probleemid, nagu oleme juba tuvastanud, on vältimatud. Kui need tekivad, ötleme lihtsalt „Ops!“, ja probleem on lahendatud.
Mis on peale Chaos Monkey?
Tegelikult on kõik need tööriistad nii noored. Ka Netflix ehitas tööriistad enda jaoks. Ehitage tööriistad enda jaoks. Tutvuge kaosest inseneri põhimõtetega ja järgige neid, mitte ärge püüdkem leida teisi tööriistu, mida keegi teine on juba loonud.
Püüdke mõista, kuidas teie süsteemid purunevad, ja hakake neid purustama, et näha, kuidas need lööke taluvad. See on peamine. Tööriistu saab hiljem otsida. Projekte on igasuguseid.
Ma ei saanud päris hästi aru hetkest, mil rääkisite, et süsteemi ei saa lihtsustada, lihtsustades selle komponente, ja seejärel liikudes mikroteenustele, mis tegelikult lihtsustavad süsteemi, kuid keeruliseks muutes komponentidevahelisi suhtlemisi. Tegelikult on need kaks osa vastandlikud.
Täiesti õige, mikroteenused on tõepoolest väga vastuoluline teema. Tegelikult suurendab osade lihtsustamine paindlikkust. Mida mikroteenused meile annavad? Nad annavad meile paindlikkuse ja kiirus, kuid lihtsust nad kindlasti ei too. Need suurendavad keerukust.
Nii et DevOpsi filosoofias ei ole mikroteenused nii suur õnnistus?
Iga hea asja taga on varjukülg. On headus: see suurendab paindlikkust, annab meile võimaluse teha kiiremaid muudatusi, kuid suurendab keerukust ja seega kogu süsteemi haprust.
Kuhu peaks rohkem rõhku panema: suhtlemise lihtsustamisele või osade lihtsustamisele?
Rõhk on kindlasti suhtlemise lihtsustamisel, sest kui vaatame seda, kuidas me koos töötame, siis tuleb eelkõige tähelepanu pöörata suhtlemise lihtsustamisele, mitte igaühe töö lihtsustamisele. Sest töö lihtsustamine tähendab roboteerimist. McDonald'sis töötab see kenasti, kui sul on ette kirjutatud: siia pannakse burger, siia valatakse kastet. See ei toimi meie loovtöös üldse.
Kas tõesti on nii, et kõik, mida te rääkisite, elab konkurentsivaba maailmas, kus kaos on nii hea ja selles kaoses ei ole vasturääkivusi, keegi ei taha kedagi süüa ega tappa? Kuidas peaksid konkurents ja DevOps elama?
See sõltub sellest, millise konkurentsi üle me räägime. Kas töökohal toimuva konkurentsi või ettevõtetevahelise konkurentsi kohta?
Teenuste konkurentsist, kuna teenused ei ole vaid mõned ettevõtted. Me loome uue tüübi info keskkonda, ja ükski keskkond ei saa elada ilma konkurentsita. Konkurents on igal pool.
Võtame näiteks Netflixi, kes on meie rollimudeli. Nad tõid selle ideed kuidas? Kuna neil oli vaja olla konkurentsivõimelised. See paindlikkus ja liikumise kiirus on täpselt see konkurentsinõue, mis toob kaost meie süsteemidesse. Nii et kaos ei ole see, mida me teadlikult teeme, sest me seda tahame; see on see, mis toimub, kuna maailm seda nõuab. Me lihtsalt peame kohanduma. Ja kaos ongi tegelikult konkurentsi tulemus.
Kas see tähendab, et kaos on eesmärkide puudumine? Või need eesmärgid, mida me ei taha näha? Me oleme oma mullis ja ei mõista teiste eesmärke. Konkurents, tegelikult, põhineb sellel, et meil on selged eesmärgid ja me teame, kuhu me igas järgnevuses suundume. Minu arvates on see DevOpsi olemus.
Ka selline vaade küsimusele. Ma arvan, et meie kõigi eesmärk on üks: ellu jääda ja teha seda võimalikult
suurima rõõmuga. Ja iga organisatsiooni konkurentsieesmärk on sama. Ellujäämine toimub sageli konkurentsivõitluses, sellega ei saa midagi teha.
Sel aastal toimub konverents 7. detsembril 'Tehnopolis'. Jätame ettekannete esitamise taotlusi avatuks kuni 11. novembrini. meile, kui soovite esineda.
Osalejate registreerimine on avatud, pilet maksab 7000 rubla. Liituge meiega!
Allikas: habr.com
