Anton Weiss, Otomato Software asutaja ja direktor, üks esimese DevOps sertifikaadi algatajatest ja juhendajatest Iisraelis, esines eelmise aasta üritusel. kaoseteooriast ja kaoseinseneri peamistest põhimõtetest ning selgitas ka, kuidas töötab ideaalne tuleviku DevOps-organisatsioon.
Oleme koostanud aruande tekstiversiooni.
Tere hommikust!
DevOpsDays Moskvas teist aastat järjest, see on minu teine kord sellel laval, paljud teist on selles ruumis teist korda. Mida see tähendab? See tähendab, et DevOpsi liikumine Venemaal kasvab, paljuneb ja mis kõige tähtsam, see tähendab, et on saabunud aeg rääkida sellest, mis DevOps on 2018. aastal.
Tõstke käsi, kes arvavad, et DevOps on 2018. aastal juba elukutse? Selliseid on. Kas ruumis on DevOpsi insenere, kelle ametijuhendis on kirjas "DevOpsi insener"? Kas ruumis on DevOpsi haldureid? Sellist ei ole. DevOpsi arhitektid? Samuti ei. Mitte piisavalt. Kas on tõesti tõsi, et keegi ei ütle, et nad on DevOpsi insenerid?
Nii et enamik teist arvab, et see on mustervastane? Et sellist ametit ei tohiks olla? Võime mõelda, mida tahame, kuid mõtlemise ajal liigub tööstus pidulikult edasi DevOpsi trompeti kõlamise saatel.
Kes on kuulnud uuest teemast nimega DevDevOps? See on uus tehnika, mis võimaldab arendajate ja arendajate vahel tõhusat koostööd. Ja mitte nii uus. Twitteri järgi otsustades hakkasid nad sellest rääkima juba 4 aastat tagasi. Ja siiani huvi selle vastu kasvab ja kasvab, ehk siis on probleem. Probleem vajab lahendamist.
Oleme loomingulised inimesed, me ei jää lihtsalt rahulikuks. Me ütleme: DevOps ei ole piisavalt kõikehõlmav sõna, sellel puuduvad endiselt kõikvõimalikud erinevad huvitavad elemendid. Ja me läheme oma salajastesse laboritesse ja hakkame tootma huvitavaid mutatsioone: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Loogika on raudne, eks? Meie tarnesüsteem ei tööta, meie süsteemid on ebastabiilsed ja meie kasutajad on rahulolematud, meil ei ole aega tarkvara õigeaegseks juurutamiseks, me ei mahu eelarvesse. Kuidas me seda kõike lahendame? Me mõtleme välja uue sõna! See lõpeb tekstiga "Ops" ja probleem on lahendatud.
Nii et ma nimetan seda lähenemisviisi - "Oh, ja probleem on lahendatud."
See kõik jääb tagaplaanile, kui meenutame endale, miks me selle kõige peale tulime. Me mõtlesime välja kogu selle DevOpsi asja, et muuta tarkvara tarnimine ja meie enda töö selles protsessis võimalikult takistamatuks, valutuks, tõhusaks ja mis kõige tähtsam, nauditavaks.
DevOps kasvas välja valust. Ja me oleme kannatustest väsinud. Ja selleks, et see kõik juhtuks, tugineme igihaljastele praktikatele: tõhusale koostööle, voopraktikatele ja mis kõige tähtsam – süsteemsele mõtlemisele, sest ilma selleta ei tööta ükski DevOps.
Mis on süsteem?
Ja kui me juba räägime süsteemsest mõtlemisest, siis tuletagem meelde, mis on süsteem.
Kui olete revolutsiooniline häkker, siis teie jaoks on süsteem selgelt kuri. See on pilv, mis ripub sinu kohal ja sunnib sind tegema asju, mida sa ei taha.
Süsteemse mõtlemise seisukohalt on süsteem tervik, mis koosneb osadest. Selles mõttes on igaüks meist süsteem. Organisatsioonid, milles me töötame, on süsteemid. Ja seda, mida teie ja mina ehitame, nimetatakse süsteemiks.
Kõik see on osa ühest suurest sotsiaaltehnoloogilisest süsteemist. Ja ainult siis, kui mõistame, kuidas see sotsiaal-tehnoloogiline süsteem koos toimib, saame selles küsimuses midagi tõeliselt optimeerida.
Süsteemse mõtlemise vaatenurgast on süsteemil mitmeid huvitavaid omadusi. Esiteks koosneb see osadest, mis tähendab, et selle käitumine sõltub osade käitumisest. Pealegi on kõik selle osad ka üksteisest sõltuvad. Selgub, et mida rohkem osi on süsteemil, seda keerulisem on selle käitumist mõista või ennustada.
Käitumise seisukohalt on veel üks huvitav fakt. Süsteem suudab teha midagi, mida ükski selle üksikutest osadest ei suuda.
Nagu dr Russell Ackoff (üks süsteemse mõtlemise rajajaid) ütles, on seda mõtteeksperimendiga üsna lihtne tõestada. Näiteks kes ruumis teab, kuidas koodi kirjutada? Käsi on palju ja see on normaalne, sest see on meie eriala üks peamisi nõudeid. Kas sa oskad kirjutada, aga kas su käed suudavad koodi kirjutada sinust eraldi? On inimesi, kes ütlevad: "Minu käed ei kirjuta koodi, vaid minu aju kirjutab koodi." Kas teie aju saab kirjutada koodi teist eraldi? No ilmselt mitte.
Aju on hämmastav masin, me ei tea isegi 10% sellest, kuidas see seal töötab, kuid see ei saa toimida eraldi süsteemist, mis on meie keha. Ja seda on lihtne tõestada: avage oma kolju, võtke aju välja, pange see arvuti ette, laske tal proovida midagi lihtsat kirjutada. "Tere, maailm" näiteks Pythonis.
Kui süsteem suudab teha midagi, mida ükski selle osadest eraldi teha ei saa, siis see tähendab, et selle käitumist ei määra tema osade käitumine. Mille järgi see siis määratakse? Selle määrab nende osade vastastikune mõju. Ja vastavalt sellele, mida rohkem osi, mida keerulisem on vastasmõju, seda keerulisem on süsteemi käitumist mõista ja ennustada. Ja see muudab sellise süsteemi kaootiliseks, sest mis tahes, isegi kõige ebaolulisem, nähtamatu muutus süsteemi mis tahes osas võib viia täiesti ettearvamatute tulemusteni.
Selle tundlikkuse algtingimuste suhtes avastas ja uuris esmakordselt Ameerika meteoroloog Ed Lorenz. Hiljem nimetati seda "liblikaefektiks" ja see viis teadusliku mõtte liikumiseni, mida nimetatakse "kaoseteooriaks". Sellest teooriast sai üks peamisi paradigmamuutusi 20. sajandi teaduses.
Kaose teooria
Inimesed, kes uurivad kaost, nimetavad end kaosoloogideks.
Tegelikult oli selle raporti põhjuseks see, et keeruliste hajutatud süsteemide ja suurte rahvusvaheliste organisatsioonidega töötades mõistsin mingil hetkel, et see on see, kellena ma tunnen. Olen kaosoloog. See on põhimõtteliselt nutikas viis öelda: "Ma ei saa aru, mis siin toimub ja ma ei tea, mida sellega teha."
Ma arvan, et paljud teist tunnevad samuti sageli nii, seega olete ka kaosoloogid. Kutsun teid kaosoloogide gildi. Süsteeme, mida teie ja mina, kallid kaosoloogid, uurime, nimetatakse "keerulisteks adaptiivseteks süsteemideks".
Mis on kohanemisvõime? Kohanemisvõime tähendab, et osade individuaalne ja kollektiivne käitumine sellises adaptiivses süsteemis muutub ja organiseerub ise, reageerides sündmustele või mikrosündmuste ahelatele süsteemis. See tähendab, et süsteem kohandub muutustega iseorganiseerumise kaudu. Ja see iseorganiseerumisvõime põhineb vabade autonoomsete agentide vabatahtlikul, täielikult detsentraliseeritud koostööl.
Selliste süsteemide teine huvitav omadus on see, et need on vabalt skaleeritavad. Mis peaks meid kui kaosolooge-insenere kahtlemata huvitama. Niisiis, kui me ütleme, et keerulise süsteemi käitumise määrab selle osade koosmõju, siis millest peaksime meid huvitama? Interaktsioon.
On veel kaks huvitavat leidu.
Esiteks mõistame, et keerulist süsteemi ei saa lihtsustada selle osade lihtsustamisega. Teiseks, ainus viis keeruka süsteemi lihtsustamiseks on lihtsustada selle osade vahelisi koostoimeid.
Kuidas me suhtleme? Sina ja mina oleme kõik osad suurest infosüsteemist, mida nimetatakse inimühiskonnaks. Suhtleme ühise keele kaudu, kui see meil on, kui leiame.
Kuid keel ise on keeruline adaptiivne süsteem. Seetõttu peame tõhusamaks ja lihtsamaks suhtlemiseks looma mingisugused protokollid. See tähendab, et teatud sümbolite ja toimingute jada, mis muudab meievahelise teabevahetuse lihtsamaks, etteaimatavamaks, arusaadavamaks.
Tahan öelda, et suundumusi keerukuse, kohanemisvõime, detsentraliseerimise, kaose suunas on võimalik jälgida kõiges. Ja süsteemides, mida teie ja mina ehitame, ja nendes süsteemides, mille osa me oleme.
Ja et mitte olla alusetu, vaatame, kuidas meie loodud süsteemid muutuvad.
Sa ootasid seda sõna, ma saan aru. Oleme DevOpsi konverentsil, täna kuuleb seda sõna umbes sada tuhat korda ja siis näeme sellest öösel und.
Mikroteenused on esimene tarkvaraarhitektuur, mis tekkis vastusena DevOpsi tavadele ja mille eesmärk on muuta meie süsteemid paindlikumaks, skaleeritavamaks ja tagada pidev tarne. Kuidas ta seda teeb? Vähendades teenuste mahtu, vähendades nende teenustega seotud probleemide ulatust, vähendades tarneaega. See tähendab, et vähendame ja lihtsustame süsteemi osi, suurendame nende arvu ja vastavalt suureneb nende osade vahelise interaktsiooni keerukus alati, see tähendab, et tekivad uued probleemid, mida peame lahendama.
Mikroteenused ei ole veel lõpp, mikroteenused on üldiselt juba eile, sest Serverless on tulemas. Kõik serverid põlesid maha, ei servereid ega operatsioonisüsteeme, vaid puhas käivitatav kood. Konfiguratsioonid on eraldi, olekud on eraldi, kõike juhivad sündmused. Ilu, puhtus, vaikus, ei mingeid üritusi, midagi ei toimu, täielik kord.
Kus on keerukus? Raskus seisneb muidugi suhtlemises. Kui palju saab üks funktsioon üksi ära teha? Kuidas see suhtleb teiste funktsioonidega? Sõnumijärjekorrad, andmebaasid, tasakaalustajad. Kuidas tõrke korral mõnda sündmust uuesti luua? Palju küsimusi ja vähe vastuseid.
Mikroteenused ja serverita on see, mida meie, nohikud hipsterid kutsume Cloud Native'iks. See kõik on seotud pilvega. Kuid pilv on ka oma mastaapsuses oma olemuselt piiratud. Oleme harjunud pidama seda hajutatud süsteemiks. Kus pilvepakkujate serverid tegelikult elavad? Andmekeskustes. See tähendab, et meil on siin mingi tsentraliseeritud, väga piiratud, hajutatud mudel.
Täna mõistame, et asjade internet pole enam lihtsalt suured sõnad, et isegi tagasihoidlike ennustuste kohaselt ootavad meid järgmise viie kuni kümne aasta jooksul miljardeid internetti ühendatud seadmeid. Tohutu hulk kasulikke ja kasutuid andmeid, mis liidetakse pilve ja laetakse pilvest üles.
Pilv ei kesta, seega räägime üha enam millestki, mida nimetatakse servaarvutuseks. Või meeldib mulle ka suurepärane määratlus "udu arvuti". Seda varjab romantismi ja salapära müstika.
Udu arvutamine. Asi on selles, et pilved on tsentraliseeritud vee, auru, jää ja kivide tükid. Ja udu on veepiisad, mis on meie ümber atmosfääris hajutatud.
Uduparadigmas teevad need tilgad suurema osa tööst täiesti autonoomselt või koostöös teiste tilkadega. Ja nad pöörduvad pilve poole alles siis, kui nad on tõesti survestatud.
See tähendab jällegi detsentraliseerimist, autonoomiat ja loomulikult saavad paljud teist juba aru, kuhu see kõik läheb, sest detsentraliseerimisest ei saa rääkida plokiahelat mainimata.
On neid, kes usuvad, need on need, kes on krüptovaluutasse investeerinud. On neid, kes usuvad, aga kardavad, nagu mina näiteks. Ja on neid, kes ei usu. Siin saate ravida erinevalt. On tehnoloogia, uus tundmatu asi, on probleeme. Nagu iga uus tehnoloogia, tekitab see rohkem küsimusi kui annab vastuseid.
Hüpe plokiahela ümber on mõistetav. Kullapalavik kõrvale, tehnoloogial endal on märkimisväärseid lubadusi helgema tuleviku jaoks: rohkem vabadust, rohkem autonoomiat, hajutatud globaalset usaldust. Mida mitte tahta?
Sellest tulenevalt hakkavad üha enam insenere üle maailma välja töötama detsentraliseeritud rakendusi. Ja see on jõud, mida ei saa kõrvale jätta, öeldes lihtsalt: "Ahh, plokiahel on lihtsalt halvasti rakendatud hajutatud andmebaas." Või nagu skeptikud armastavad öelda: "Plokiahela jaoks pole tegelikke rakendusi." Kui järele mõelda, siis 150 aastat tagasi räägiti elektri kohta sama. Ja neil oli mõnes mõttes isegi õigus, sest see, mida täna elekter võimaldab, polnud 19. sajandil kuidagi võimalik.
Muide, kes teab, milline logo ekraanil on? See on Hyperledger. See on projekt, mida arendatakse Linuxi sihtasutuse egiidi all ja mis sisaldab plokiahela tehnoloogiate komplekti. See on meie avatud lähtekoodiga kogukonna tõeline tugevus.
Kaose tehnika
Seega muutub süsteem, mida me arendame, üha keerulisemaks, kaootilisemaks ja kohanemisvõimelisemaks. Netflix on mikroteenuste süsteemide pioneerid. Nad olid esimeste seas, kes sellest aru said, nad töötasid välja tööriistade komplekti, mida nad nimetasid Simian Armyks, millest kuulsaim oli . Ta määratles, mis sai tuntuks kui .
Muide, aruande kallal töötades tõlkisime selle teksti isegi vene keelde, nii et minge aadressile , lugege, kommenteerige, noomige.
Lühidalt öeldes ütlevad kaoseinseneri põhimõtted järgmist. Komplekssed hajutatud süsteemid on oma olemuselt ettearvamatud ja oma olemuselt lollakad. Vead on vältimatud, mis tähendab, et me peame nende vigadega leppima ja töötama nende süsteemidega täiesti erineval viisil.
Peame ise püüdma neid vigu oma tootmissüsteemidesse sisse viia, et testida oma süsteeme sama kohanemisvõime, iseorganiseerumise ja ellujäämise osas.
Ja see muudab kõike. Mitte ainult see, kuidas me süsteeme tootmisse laseme, vaid ka seda, kuidas me neid arendame, kuidas neid testime. Koodi stabiliseerumist ega külmutamist ei toimu, vastupidi, destabiliseerimine toimub pidevalt. Püüame süsteemi tappa ja näha, et see jätkab ellujäämist.
Hajutatud süsteemiintegratsiooni protokollid
Sellest tulenevalt peab see meie süsteeme kuidagi muutma. Et nad muutuksid stabiilsemaks, vajavad nad oma osade vaheliseks suhtlemiseks uusi protokolle. Et need osad saaksid kokku leppida ja jõuaksid mingisuguse iseorganiseerumiseni. Ja tekivad igasugused uued tööriistad, uued protokollid, mida ma nimetan "jaotatud süsteemide interaktsiooni protokollideks".
Millest ma räägin? Esiteks projekt . Mõned üritavad luua üldist hajutatud jälgimisprotokolli, mis on keeruliste hajutatud süsteemide silumiseks absoluutselt asendamatu tööriist.
Edasi - . Me ütleme, et me ei saa ennustada, mis süsteemiga juhtub, see tähendab, et me peame suurendama selle jälgitavust, vaadeldavust. Opentracing kuulub tööriistade perekonda, mis annavad meie süsteemidele vaadeldavuse. Kuid me vajame vaadeldavust, et teha kindlaks, kas süsteem käitub nii, nagu me eeldame või mitte. Kuidas me määratleme eeldatava käitumise? Määrates mingi poliitika, mingi reeglistiku. Projekt Open Policy Agent töötab selle nimel, et määratleda see reeglistik kogu spektri ulatuses, alates juurdepääsust kuni ressursside eraldamiseni.
Nagu me ütlesime, on meie süsteemid üha enam sündmustepõhised. Serverita on suurepärane näide sündmustepõhistest süsteemidest. Sündmuste edastamiseks süsteemide vahel ja nende jälgimiseks on meil vaja mingit ühist keelt, ühist protokolli, kuidas sündmustest rääkida, kuidas neid üksteisele edastada. Seda nimetatakse projekti .
Pidev muudatuste voog, mis meie süsteeme pidevalt destabiliseerib, on tarkvara artefaktide pidev voog. Et seda pidevat muutuste voogu säilitada, on meil vaja mingit ühist protokolli, mille kaudu saaksime rääkida, mis on tarkvaraartefakt, kuidas seda testitakse, millise kontrolli see on läbinud. Seda nimetatakse projekti . See tähendab, et tarkvara artefaktide jaoks on tavaline metaandmete protokoll.
Ja lõpuks, kui tahame, et meie süsteemid oleksid täiesti sõltumatud, kohanemisvõimelised ja iseorganiseeruvad, peame andma neile õiguse ennast identifitseerida. Projekt kutsus See on täpselt see, mida ta teeb. See on ka Cloud Native Computing Foundationi egiidi all olev projekt.
Kõik need projektid on noored, nad kõik vajavad meie armastust, meie kinnitust. See kõik on avatud lähtekoodiga, meie testimine, meie rakendamine. Need näitavad meile, kuhu tehnoloogia liigub.
Kuid DevOps pole kunagi olnud peamiselt tehnoloogia, see on alati olnud inimestevaheline koostöö. Ja vastavalt sellele, kui tahame, et meie arendatavad süsteemid muutuksid, peame muutuma ka meie ise. Tegelikult me muutume niikuinii; meil pole palju valikut.
Seal on imeline Briti kirjanik Rachel Botsman, milles ta kirjutab usalduse arengust läbi inimkonna ajaloo. Ta ütleb, et algselt oli primitiivsetes ühiskondades usaldus lokaalne, st usaldasime ainult neid, keda isiklikult tunneme.
Siis oli väga pikk periood – pime aeg, mil usaldus oli tsentraliseerunud, kui hakkasime usaldama inimesi, keda me ei tunne selle põhjal, et kuulume samasse avalikku või riigiasutusse.
Ja seda me oma kaasaegses maailmas näemegi: usaldus muutub üha hajutatumaks ja detsentraliseeritumaks ning selle aluseks on infovoogude vabadus, info kättesaadavus.
Kui järele mõelda, siis just seda ligipääsetavust, mis teeb selle usalduse võimalikuks, rakendame teie ja mina. See tähendab, et muutuma peab nii meie koostöö kui ka viis, kuna vanad tsentraliseeritud, hierarhilised IT-organisatsioonid enam ei tööta. Nad hakkavad välja surema.
DevOpsi organisatsiooni alused
Ideaalne tuleviku DevOps-organisatsioon on detsentraliseeritud, kohanemisvõimeline süsteem, mis koosneb autonoomsetest meeskondadest, millest igaüks koosneb autonoomsetest isikutest. Need meeskonnad on üle maailma laiali ja teevad üksteisega tõhusat koostööd, kasutades asünkroonset suhtlust ja väga läbipaistvaid sideprotokolle. Väga ilus, kas pole? Väga ilus tulevik.
Loomulikult pole see võimalik ilma kultuuriliste muutusteta. Meil peab olema transformatiivne juhtimine, isiklik vastutus, sisemine motivatsioon.
See on DevOpsi organisatsioonide alus: teabe läbipaistvus, asünkroonne suhtlus, transformatiivne juhtimine, detsentraliseerimine.
Läbipõlemine
Süsteemid, mille osaks me oleme ja mida me ehitame, on järjest kaootilisemad ning meil, inimestel, on raske selle mõttega toime tulla, raske on loobuda kontrolli illusioonist. Püüame neid jätkuvalt kontrollida ja see viib sageli läbipõlemiseni. Ütlen seda omast kogemusest, sain ka põletushaavu, samuti invaliidistasid mind ettenägematud rikked tootmises.
Läbipõlemine tekib siis, kui püüame kontrollida midagi, mis on oma olemuselt kontrollimatu. Kui me läbi põleme, kaotab kõik mõtte, sest kaob soov midagi uut teha, asume kaitsesse ja hakkame kaitsma seda, mis meil on.
Inseneri elukutse, nagu mulle sageli meeldib meelde tuletada, on eelkõige loominguline elukutse. Kui me kaotame soovi midagi luua, muutume tuhaks, muutume tuhaks. Inimesed põlevad läbi, terved organisatsioonid põlevad läbi.
Minu meelest ainult kaose loova jõuga leppimine, ainult selle põhimõtete järgi koostöö ülesehitamine on see, mis aitab meil mitte kaotada seda, mis on meie erialal hea.
Seda ma soovin teile: armastage oma tööd, armastage seda, mida teeme. See maailm toitub teabest, meil on au seda toita. Nii et uurigem kaost, olgem kaosoloogid, toome väärtust, loome midagi uut, noh, probleemid, nagu me juba avastasime, on vältimatud ja kui need ilmnevad, ütleme lihtsalt "Ops!" ja probleem on lahendatud .
Mis muud kui Chaos Monkey?
Tegelikult on kõik need pillid nii noored. Seesama Netflix ehitas endale tööriistad. Ehitage oma tööriistad ise. Lugege kaoseinseneri põhimõtteid ja järgige neid põhimõtteid, selle asemel, et püüda leida muid tööriistu, mille keegi teine on juba ehitanud.
Proovige mõista, kuidas teie süsteemid lagunevad, alustage nende lagunemist ja vaadake, kuidas need vastu peavad. See tuleb kõigepealt. Ja võite otsida tööriistu. Projekte on igasuguseid.
Ma ei saanud päris hästi aru hetkest, kui ütlesite, et süsteemi ei saa lihtsustada selle komponentide lihtsustamisega, ja läksin kohe edasi mikroteenuste juurde, mis lihtsustavad süsteemi, lihtsustades komponente endid ja raskendades interaktsioone. Need on sisuliselt kaks osa, mis on üksteisega vastuolus.
Täpselt nii, mikroteenused on üldiselt väga vastuoluline teema. Tegelikult suurendab osade lihtsustamine paindlikkust. Mida mikroteenused pakuvad? Need annavad meile paindlikkust ja kiirust, kuid kindlasti ei anna nad meile lihtsust. Need suurendavad raskust.
Niisiis, DevOpsi filosoofias pole mikroteenused nii head?
Igal kaubal on tagakülg. Selle eeliseks on see, et see suurendab paindlikkust, võimaldades meil muudatusi kiiremini teha, kuid see suurendab kogu süsteemi keerukust ja seega ka haprust.
Kummal on siiski suurem rõhk: interaktsiooni lihtsustamisel või osade lihtsustamisel?
Rõhk on loomulikult interaktsioonide lihtsustamisel, sest kui me vaatame seda sellest vaatenurgast, kuidas me teiega töötame, siis ennekõike peame pöörama tähelepanu interaktsioonide lihtsustamisele, mitte töö lihtsustamisele. igaühest meist eraldi. Sest töö lihtsustamine tähendab muutumist robotiteks. Siin McDonaldsis töötab see normaalselt, kui sul on juhised: siia paned burgeri, siin kallad kastme peale. Meie loometöös see üldse ei toimi.
Kas on tõsi, et kõik, mida sa ütlesid, elab maailmas, kus pole konkurentsi, ja sealne kaos on nii lahke ja selles kaose sees pole vastuolusid, keegi ei taha kedagi süüa ega tappa? Kuidas peaks konkurentsil ja DevOpsil minema?
Eks see oleneb sellest, millisest konkurentsist me räägime. Kas tegemist on konkurentsiga töökohal või ettevõtetevahelise konkurentsiga?
Teenuste konkurentsist, mis eksisteerib seetõttu, et teenuseid ei ole mitu ettevõtet. Loome uut tüüpi infokeskkonda ja ükski keskkond ei saa elada ilma konkurentsita. Igal pool on konkurents.
Seesama Netflix, võtame neid eeskujuks. Miks nad selle peale tulid? Sest nad pidid olema konkurentsivõimelised. See paindlikkus ja liikumiskiirus on just väga konkurentsinõue, see toob meie süsteemidesse kaose. See tähendab, et kaos ei ole midagi, mida me teadlikult teeme sellepärast, et me seda tahame, see on midagi, mis juhtub, sest maailm seda nõuab. Peame lihtsalt kohanema. Ja kaos, see on täpselt konkurentsi tulemus.
Kas see tähendab, et kaos on justkui eesmärkide puudumine? Või need eesmärgid, mida me näha ei taha? Oleme majas ega mõista teiste eesmärke. Konkurents on tegelikult tingitud sellest, et meil on selged eesmärgid ja me teame, kuhu me igal järgmisel ajahetkel välja jõuame. Minu vaatenurgast on see DevOpsi olemus.
Vaata ka küsimust. Ma arvan, et meil kõigil on sama eesmärk: ellu jääda ja sellega hakkama saada
suurim rõõm. Ja iga organisatsiooni konkurentsieesmärk on sama. Ellujäämine toimub sageli konkurentsi kaudu, sa ei saa sellega midagi teha.
Selle aasta konverents toimub 7. detsembril Technopolises. Aruannete avaldusi võtame vastu kuni 11. novembrini. meile, kui soovite rääkida.
Osalejate registreerimine on avatud, piletid maksavad 7000 rubla. Liitu meiega!
Allikas: www.habr.com