Antonas Weissas, „Otomato Software“ įkūrėjas ir direktorius, vienas iš pirmojo „DevOps“ sertifikavimo Izraelyje iniciatorių ir instruktorių, kalbėjo praėjusių metų renginyje. apie chaoso teoriją ir pagrindinius chaoso inžinerijos principus, taip pat paaiškino, kaip veikia ideali ateities DevOps organizacija.
Parengėme tekstinę ataskaitos versiją.
Labas rytas
DevOpsDays Maskvoje antrus metus iš eilės, tai jau antras kartas šioje scenoje, daugelis iš jūsų šiame kambaryje jau antrą kartą. Ką tai reiškia? Tai reiškia, kad „DevOps“ judėjimas Rusijoje auga, daugėja, o svarbiausia – tai reiškia, kad atėjo laikas kalbėti apie tai, kas yra „DevOps“ 2018 m.
Pakelkite rankas, kas mano, kad 2018 m. DevOps jau yra profesija? Yra tokių. Ar kambaryje yra „DevOps“ inžinierių, kurių pareigybės aprašyme nurodyta „DevOps inžinierius“? Ar kambaryje yra „DevOps“ valdytojų? Tokios nėra. „DevOps“ architektai? Taip pat ne. Nepakankamai. Ar tikrai tiesa, kad niekas nesako esąs „DevOps“ inžinierius?
Taigi dauguma jūsų mano, kad tai yra antimodelis? Kad tokios profesijos neturėtų būti? Galime galvoti, ką norime, bet kol galvojame, pramonė iškilmingai juda į priekį, skambant DevOps trimitui.
Kas girdėjo apie naują temą „DevDevOps“? Tai nauja technika, leidžianti veiksmingai bendradarbiauti kūrėjams ir devops. Ir ne toks naujas. Sprendžiant iš Twitter, jie jau pradėjo apie tai kalbėti prieš 4 metus. Ir iki šiol susidomėjimas tuo auga ir auga, tai yra, yra problema. Problema turi būti išspręsta.
Esame kūrybingi žmonės, ne tik ilsimamės. Mes sakome: „DevOps“ nėra pakankamai išsamus žodis, jam vis dar trūksta įvairių įdomių elementų. Mes einame į savo slaptas laboratorijas ir pradedame gaminti įdomias mutacijas: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logika geležinė, tiesa? Mūsų pristatymo sistema neveikia, sistemos nestabilios, o vartotojai nepatenkinti, nespėjame laiku įdiegti programinės įrangos, netelpame į biudžetą. Kaip visa tai išspręsime? Sugalvosime naują žodį! Tai baigsis „Ops“ ir problema išspręsta.
Taigi aš vadinu šį požiūrį - „Oi, ir problema išspręsta“.
Visa tai išnyksta į antrą planą, jei primename sau, kodėl visa tai sugalvojome. Mes sugalvojome visą šį „DevOps“ dalyką, kad programinės įrangos pristatymas ir mūsų pačių darbas šiame procese būtų kuo netrukdomas, neskausmingas, efektyvesnis ir, svarbiausia, malonesnis.
DevOps išaugo iš skausmo. Ir mes pavargome nuo kančios. O kad visa tai įvyktų, remiamės amžinai žaliuojančiomis praktikomis: efektyviu bendradarbiavimu, srautų praktikomis ir, svarbiausia, sisteminiu mąstymu, nes be jo neveikia joks DevOps.
Kas yra sistema?
Ir jei jau kalbame apie sisteminį mąstymą, priminkime sau, kas yra sistema.
Jei esate revoliucinis įsilaužėlis, tada jums sistema yra aiškiai blogi. Tai debesis, kuris pakimba virš jūsų ir verčia daryti tai, ko nenorite.
Sisteminio mąstymo požiūriu sistema yra visuma, susidedanti iš dalių. Šia prasme kiekvienas iš mūsų yra sistema. Organizacijos, kuriose dirbame, yra sistemos. O tai, ką jūs ir aš kuriame, vadinama sistema.
Visa tai yra vienos didelės socialinės-technologinės sistemos dalis. Ir tik tada, kai suprasime, kaip ši socialinė-technologinė sistema veikia kartu, tik tada galėsime ką nors iš tikrųjų optimizuoti šiuo klausimu.
Sisteminio mąstymo požiūriu sistema turi įvairių įdomių savybių. Pirma, jis susideda iš dalių, o tai reiškia, kad jo elgsena priklauso nuo dalių elgesio. Be to, visos jo dalys taip pat yra tarpusavyje susijusios. Pasirodo, kuo daugiau sistemos dalių, tuo sunkiau suprasti ar numatyti jos elgesį.
Elgsenos požiūriu yra dar vienas įdomus faktas. Sistema gali padaryti tai, ko negali padaryti jokia atskira jos dalis.
Kaip sakė daktaras Russellas Ackoffas (vienas iš sisteminio mąstymo įkūrėjų), tai gana lengva įrodyti minties eksperimentu. Pavyzdžiui, kas iš kambario žino, kaip parašyti kodą? Rankų daug, ir tai normalu, nes tai yra vienas pagrindinių reikalavimų mūsų profesijai. Ar mokate rašyti, bet ar jūsų rankos gali rašyti kodą atskirai nuo jūsų? Yra žmonių, kurie pasakys: „Kodą rašo ne mano rankos, o mano smegenys“. Ar jūsų smegenys gali rašyti kodą atskirai nuo jūsų? Na, tikriausiai ne.
Smegenys yra nuostabi mašina, net 10% nežinome, kaip jos veikia, tačiau jos negali veikti atskirai nuo sistemos, kuri yra mūsų kūnas. Ir tai lengva įrodyti: atidarykite kaukolę, išimkite smegenis, padėkite jas priešais kompiuterį, leiskite jam pabandyti parašyti ką nors paprasto. Pavyzdžiui, „Sveikas, pasauli“ Python.
Jei sistema gali padaryti ką nors, ko negali padaryti nei viena jos dalis, tai reiškia, kad jos elgseną lemia ne jos dalių elgesys. Tai kuo tada lemia? Tai lemia šių dalių sąveika. Ir atitinkamai kuo daugiau dalių, tuo sudėtingesnės sąveikos, tuo sunkiau suprasti ir numatyti sistemos elgesį. Ir dėl to tokia sistema tampa chaotiška, nes bet koks, net ir pats nereikšmingiausias, nematomas bet kurios sistemos dalies pasikeitimas gali lemti visiškai nenuspėjamus rezultatus.
Šį jautrumą pradinėms sąlygoms pirmasis atrado ir ištyrė amerikiečių meteorologas Edas Lorenzas. Vėliau jis buvo vadinamas „drugelio efektu“ ir paskatino mokslinės minties judėjimo, vadinamo „chaoso teorija“, vystymąsi. Ši teorija tapo vienu iš pagrindinių XX amžiaus mokslo paradigmų poslinkių.
Chaoso teorija
Chaosą tyrinėjantys žmonės save vadina chaosologais.
Tiesą sakant, šio pranešimo priežastis buvo ta, kad dirbdamas su sudėtingomis paskirstytomis sistemomis ir didelėmis tarptautinėmis organizacijomis, tam tikru momentu supratau, kad tai aš jaučiuosi. Aš esu chaosologas. Iš esmės tai yra protingas būdas pasakyti: „Aš nesuprantu, kas čia vyksta, ir nežinau, ką su tuo daryti“.
Manau, kad daugelis iš jūsų taip pat dažnai taip jaučiasi, todėl esate ir chaosologai. Kviečiu į chaosologų gildiją. Sistemos, kurias jūs ir aš, mieli kolegos chaosologai, tyrinėsime, vadinamos „sudėtingomis prisitaikančiomis sistemomis“.
Kas yra prisitaikymas? Prisitaikymas reiškia, kad individualus ir kolektyvinis dalių elgesys tokioje adaptyvioje sistemoje kinta ir savaime organizuojasi, reaguodamas į įvykius ar mikroįvykių grandines sistemoje. Tai yra, sistema prisitaiko prie pokyčių per saviorganizaciją. Ir šis gebėjimas savarankiškai organizuoti yra pagrįstas savanorišku, visiškai decentralizuotu laisvų autonominių agentų bendradarbiavimu.
Dar viena įdomi tokių sistemų savybė yra ta, kad jos yra laisvai keičiamos. Kas neabejotinai turėtų mus, chaosologus-inžinierius, sudominti. Taigi, jei sakytume, kad sudėtingos sistemos elgesį lemia jos dalių sąveika, tai kuo turėtume domėtis? Sąveika.
Yra dar du įdomūs atradimai.
Pirma, mes suprantame, kad sudėtingos sistemos negalima supaprastinti supaprastinant jos dalis. Antra, vienintelis būdas supaprastinti sudėtingą sistemą yra supaprastinti jos dalių sąveiką.
Kaip mes bendraujame? Jūs ir aš esame didelės informacinės sistemos, vadinamos žmonių visuomene, dalys. Bendraujame per bendrą kalbą, jei ją turime, jei randame.
Tačiau pati kalba yra sudėtinga prisitaikanti sistema. Atitinkamai, norėdami sąveikauti efektyviau ir paprasčiau, turime sukurti tam tikrus protokolus. Tai yra, tam tikra simbolių ir veiksmų seka, dėl kurios keitimasis informacija tarp mūsų bus paprastesnis, labiau nuspėjamas, suprantamesnis.
Noriu pasakyti, kad visame kame galima atsekti tendencijas į kompleksiškumą, į prisitaikymą, į decentralizaciją, į chaosą. Ir sistemose, kurias kuriame jūs ir aš, ir tose sistemose, kurių dalis esame.
Kad nebūtų be pagrindo, pažiūrėkime, kaip keičiasi mūsų kuriamos sistemos.
Jūs laukėte šio žodžio, suprantu. Esame DevOps konferencijoje, šiandien šis žodis bus išgirstas apie šimtą tūkstančių kartų, o paskui sapnuosime naktį.
„Microservices“ yra pirmoji programinės įrangos architektūra, kuri atsirado kaip reakcija į „DevOps“ praktiką, kuri skirta padaryti mūsų sistemas lankstesnėms, labiau keičiamo dydžio ir užtikrinti nuolatinį pristatymą. Kaip ji tai daro? Sumažinus paslaugų apimtį, sumažinant šių paslaugų apdorojamų problemų mastą, sutrumpinant pristatymo laiką. Tai yra, mes sumažiname ir supaprastiname sistemos dalis, padidiname jų skaičių, todėl šių dalių sąveikos sudėtingumas nuolat didėja, tai yra, atsiranda naujų problemų, kurias turime išspręsti.
Mikropaslaugos dar ne pabaiga, mikropaslaugos apskritai jau vakar, nes ateina be serverių. Sudegė visi serveriai, jokių serverių, jokių operacinių sistemų, tik grynas vykdomasis kodas. Konfigūracijos atskiros, būsenos atskiros, viską valdo įvykiai. Grožis, švara, tyla, jokių įvykių, nieko nevyksta, visiška tvarka.
Kur sudėtingumas? Žinoma, sunkumas yra sąveikoje. Kiek viena funkcija gali padaryti pati? Kaip jis sąveikauja su kitomis funkcijomis? Pranešimų eilės, duomenų bazės, balansuotojai. Kaip atkurti įvykį, kai įvyko gedimas? Daug klausimų ir mažai atsakymų.
„Microservices“ ir „Serveris be serverių“ yra tai, ką mes, hipsteriai, vadiname „Cloud Native“. Viskas apie debesį. Tačiau debesis taip pat iš prigimties yra ribotas. Esame įpratę galvoti apie tai kaip apie paskirstytą sistemą. Tiesą sakant, kur gyvena debesų paslaugų teikėjų serveriai? Duomenų centruose. Tai yra, čia turime savotišką centralizuotą, labai ribotą, paskirstytą modelį.
Šiandien suprantame, kad daiktų internetas nebėra tik dideli žodžiai, kad net ir pagal kuklias prognozes per ateinančius penkerius–dešimt metų mūsų laukia milijardai prie interneto prijungtų įrenginių. Didžiulis kiekis naudingų ir nenaudingų duomenų, kurie bus sujungti į debesį ir įkelti iš debesies.
Debesis nesitęs, todėl vis dažniau kalbame apie tai, kas vadinama krašto kompiuterija. Arba man taip pat patinka nuostabus „rūko skaičiavimo“ apibrėžimas. Jį gaubia romantizmo ir paslapties mistika.
Rūko skaičiavimas. Esmė ta, kad debesys yra centralizuotos vandens, garų, ledo ir akmenų sankaupos. O rūkas – tai vandens lašeliai, išsibarstę aplink mus atmosferoje.
Rūko paradigmoje didžiąją dalį darbo šie lašeliai atlieka visiškai savarankiškai arba bendradarbiaudami su kitais lašeliais. Ir jie kreipiasi į debesį tik tada, kai juos tikrai labai prispaudžia.
Tai vėlgi decentralizacija, autonomija ir, žinoma, daugelis iš jūsų jau supranta, kur visa tai veda, nes negalima kalbėti apie decentralizaciją nepaminėdami blokų grandinės.
Yra tikinčiųjų, tai tie, kurie investavo į kriptovaliutą. Yra tokių, kurie tiki, bet bijo, kaip, pavyzdžiui, aš. Ir yra tokių, kurie netiki. Čia galite gydyti skirtingai. Yra technologijos, naujas nežinomas dalykas, yra problemų. Kaip ir bet kuri nauja technologija, ji kelia daugiau klausimų nei atsakymų.
Ažiotažas apie „blockchain“ yra suprantamas. Atmetus aukso karštligę, pati technologija turi puikių pažadų šviesesnei ateičiai: daugiau laisvės, daugiau savarankiškumo, paskirstyto pasaulinio pasitikėjimo. Ko nenorėti?
Atitinkamai, vis daugiau inžinierių visame pasaulyje pradeda kurti decentralizuotas programas. Ir tai yra galia, kurios negalima atmesti tiesiog pasakant: „Ak, „blockchain“ yra tik prastai įgyvendinta paskirstyta duomenų bazė. Arba, kaip mėgsta sakyti skeptikai: „Nėra realių „blockchain“ programų. Jei gerai pagalvoji, prieš 150 metų tą patį kalbėjo apie elektrą. Ir jie tam tikra prasme buvo net teisūs, nes tai, ką elektra leidžia šiandien, XIX amžiuje niekaip nebuvo įmanoma.
Beje, kas žino, koks logotipas yra ekrane? Tai yra „Hyperledger“. Tai projektas, kurį globoja „The Linux Foundation“ ir apima blokų grandinės technologijų rinkinį. Tai tikrai mūsų atvirojo kodo bendruomenės stiprybė.
Chaoso inžinerija
Taigi mūsų kuriama sistema tampa vis sudėtingesnė, chaotiškesnė ir vis labiau prisitaikanti. „Netflix“ yra mikro paslaugų sistemų pionieriai. Jie buvo vieni pirmųjų, kurie tai suprato, jie sukūrė įrankių rinkinį, kurį pavadino Simijos armija, iš kurių garsiausias buvo . Jis apibrėžė, kas tapo žinoma kaip .
Beje, rengdami ataskaitą mes net išvertėme šį tekstą į rusų kalbą, tad eikite į , skaityti, komentuoti, barti.
Trumpai tariant, chaoso inžinerijos principai sako taip. Sudėtingos paskirstytos sistemos iš prigimties yra nenuspėjamos ir iš prigimties klaidingos. Klaidos yra neišvengiamos, o tai reiškia, kad turime priimti šias klaidas ir dirbti su šiomis sistemomis visiškai kitaip.
Mes patys turime stengtis įvesti šias klaidas į savo gamybos sistemas, kad išbandytume savo sistemų prisitaikymą, gebėjimą organizuotis ir išgyventi.
Ir tai viską keičia. Ne tik kaip paleidžiame sistemas į gamybą, bet ir kaip jas kuriame, kaip testuojame. Nėra kodo stabilizavimo ar užšalimo proceso, priešingai, yra nuolatinis destabilizavimo procesas. Bandome sunaikinti sistemą ir matyti, kad ji toliau išliks.
Paskirstyti sistemos integravimo protokolai
Atitinkamai, mūsų sistemos turi kažkaip pasikeisti. Kad jie taptų stabilesni, jiems reikia naujų protokolų, skirtų jų dalių sąveikai. Kad šios dalys susitartų ir susitvarkytų. Atsiranda visokių naujų įrankių, naujų protokolų, kuriuos aš vadinu „paskirstytų sistemų sąveikos protokolais“.
Apie ką aš kalbu? Pirma, projektas . Kai kurie bando sukurti bendrą paskirstytą sekimo protokolą, kuris yra visiškai nepakeičiamas įrankis sudėtingoms paskirstytoms sistemoms derinti.
Toliau - . Sakome, kad negalime nuspėti, kas atsitiks su sistema, tai yra, reikia didinti jos stebimumą, stebimumą. „Opentracing“ priklauso įrankių šeimai, kuri suteikia galimybę stebėti mūsų sistemas. Tačiau mums reikia stebėjimo, kad galėtume nustatyti, ar sistema elgiasi taip, kaip mes tikimės, ar ne. Kaip apibrėžiame laukiamą elgesį? Apibrėžiant kažkokią politiką, kažkokias taisykles. Atviros politikos agento projektas siekia apibrėžti šį taisyklių rinkinį įvairiuose diapazonuose nuo prieigos iki išteklių paskirstymo.
Kaip minėjome, mūsų sistemos vis labiau priklauso nuo įvykių. Be serverio yra puikus įvykiais pagrįstų sistemų pavyzdys. Kad galėtume perkelti įvykius iš vienos sistemos į kitą ir juos sekti, mums reikia bendros kalbos, bendro protokolo, kaip mes kalbame apie įvykius, kaip perduodame juos vieni kitiems. Taip vadinamas projektas .
Nuolatinis pokyčių srautas, kuris plauna mūsų sistemas ir nuolat jas destabilizuoja, yra nuolatinis programinės įrangos artefaktų srautas. Kad galėtume išlaikyti šį nuolatinį pokyčių srautą, mums reikia kažkokio bendro protokolo, per kurį galėtume kalbėti apie tai, kas yra programinės įrangos artefaktas, kaip jis testuojamas, kokį patikrinimą praėjo. Taip vadinamas projektas . Tai yra, įprastas programinės įrangos artefaktų metaduomenų protokolas.
Ir galiausiai, jei norime, kad mūsų sistemos būtų visiškai nepriklausomos, prisitaikančios ir savaime organizuotos, turime suteikti joms teisę į savęs identifikavimą. Projektas vadinamas Būtent tai jis daro. Tai taip pat projektas, kurį globoja „Cloud Native Computing Foundation“.
Visi šie projektai yra jauni, jiems visiems reikia mūsų meilės, mūsų patvirtinimo. Visa tai yra atvirojo kodo, mūsų bandymai, mūsų įgyvendinimas. Jie parodo, kur link juda technologijos.
Tačiau „DevOps“ niekada nebuvo susijęs su technologijomis, ji visada buvo susijusi su žmonių bendradarbiavimu. Ir, atitinkamai, jei norime, kad mūsų kuriamos sistemos keistųsi, turime keistis ir mes patys. Tiesą sakant, mes vis tiek keičiamės; neturime daug pasirinkimo.
Yra nuostabus Britų rašytoja Rachel Botsman, kurioje ji rašo apie pasitikėjimo raidą žmonijos istorijoje. Ji sako, kad iš pradžių primityviose visuomenėse pasitikėjimas buvo vietinis, tai yra, pasitikėjome tik tais, kuriuos pažinojome asmeniškai.
Tada buvo labai ilgas laikotarpis – tamsus laikas, kai buvo centralizuotas pasitikėjimas, kai pradėjome pasitikėti žmonėmis, kurių nepažįstame pagal tai, kad priklausome tai pačiai viešajai ar valstybinei institucijai.
Ir štai ką matome mūsų šiuolaikiniame pasaulyje: pasitikėjimas vis labiau pasiskirsto ir decentralizuojasi, o jis grindžiamas informacijos srautų laisve, informacijos prieinamumu.
Jei gerai pagalvotumėte, būtent šį prieinamumą, dėl kurio galimas pasitikėjimas, įgyvendiname jūs ir aš. Tai reiškia, kad turi keistis ir mūsų bendradarbiavimo būdas, ir tai, kaip tai darome, nes centralizuotos, hierarchinės IT organizacijos seniau nebeveikia. Jie pradeda mirti.
„DevOps“ organizacijos pagrindai
Ideali ateities DevOps organizacija yra decentralizuota, prisitaikanti sistema, sudaryta iš savarankiškų komandų, kurių kiekvieną sudaro savarankiški asmenys. Šios komandos yra išsibarsčiusios visame pasaulyje, efektyviai bendradarbiaujančios viena su kita naudodamos asinchroninį ryšį, naudodamos itin skaidrius komunikacijos protokolus. Labai gražu, ar ne? Labai graži ateitis.
Žinoma, tai neįmanoma be kultūrinių pokyčių. Turime turėti transformacinę lyderystę, asmeninę atsakomybę, vidinę motyvaciją.
Tai yra DevOps organizacijų pagrindas: informacijos skaidrumas, asinchroninė komunikacija, transformacinė lyderystė, decentralizacija.
Perdegimas
Sistemos, kurių dalis esame ir kurias kuriame, tampa vis chaotiškesnės, o mums, žmonėms, sunku susidoroti su šia mintimi, sunku atsisakyti kontrolės iliuzijos. Stengiamės ir toliau juos kontroliuoti, o tai dažnai sukelia perdegimą. Tai sakau iš savo patirties, aš irgi apdegiau, taip pat buvau neįgalus dėl nenumatytų gedimų gamyboje.
Perdegimas atsiranda, kai bandome kontroliuoti tai, kas iš prigimties yra nekontroliuojama. Kai perdegame, viskas praranda prasmę, nes prarandame norą daryti kažką naujo, pradedame gintis ir pradedame ginti tai, ką turime.
Inžinieriaus profesija, kaip dažnai mėgstu sau priminti, pirmiausia yra kūrybinė profesija. Jei prarandame norą ką nors kurti, tada pavirstame pelenais, virstame pelenais. Žmonės perdega, ištisos organizacijos perdega.
Mano nuomone, tik priėmimas chaoso kūrybinės galios, tik bendradarbiavimo kūrimas pagal jo principus yra tai, kas padės neprarasti to, kas mūsų profesijoje yra gera.
To ir linkiu tau: mylėti savo darbą, mylėti tai, ką darome. Šis pasaulis minta informacija, mums tenka garbė ją maitinti. Taigi tyrinėkime chaosą, būkime chaosologai, neškime vertę, kurkime kažką naujo, na, problemos, kaip jau išsiaiškinome, yra neišvengiamos, o joms atsiradus tiesiog pasakysime „Ops!“ Ir problema išspręsta.
Kas kitas, išskyrus Chaoso beždžionę?
Tiesą sakant, visi šie instrumentai yra tokie jauni. Tas pats „Netflix“ sukūrė įrankius sau. Sukurkite savo įrankius. Perskaitykite chaoso inžinerijos principus ir laikykitės tų principų, o ne ieškokite kitų įrankių, kuriuos kažkas jau sukūrė.
Pabandykite suprasti, kaip sugenda jūsų sistemos, pradėkite jas ardyti ir pažiūrėkite, kaip jos laikosi. Tai pirmiausia. Ir jūs galite ieškoti įrankių. Yra visokių projektų.
Nelabai supratau momento, kai pasakėte, kad sistemos negalima supaprastinti supaprastinant jos komponentus, ir iškart perėjau prie mikropaslaugų, kurios supaprastina sistemą supaprastindamos pačius komponentus ir apsunkindamos sąveiką. Tai iš esmės dvi dalys, kurios prieštarauja viena kitai.
Tiesa, mikropaslaugos apskritai yra labai prieštaringa tema. Tiesą sakant, dalių supaprastinimas padidina lankstumą. Ką teikia mikropaslaugos? Jie suteikia mums lankstumo ir greičio, bet tikrai nesuteikia mums paprastumo. Jie padidina sunkumą.
Taigi, DevOps filosofijoje mikropaslaugos nėra toks geras dalykas?
Bet koks gėris turi ir atvirkštinę pusę. Privalumas yra tai, kad jis padidina lankstumą, leidžia mums greičiau atlikti pakeitimus, tačiau tai padidina visos sistemos sudėtingumą, taigi ir pažeidžiamumą.
Vis dėlto, kas labiau akcentuojama: sąveikos supaprastinimas ar dalių supaprastinimas?
Žinoma, dėmesys skiriamas sąveikos supaprastinimui, nes jei žiūrėsime iš to, kaip dirbame su jumis, pirmiausia turime atkreipti dėmesį į sąveikos supaprastinimą, o ne į darbo supaprastinimą. kiekvieno iš mūsų atskirai. Nes supaprastinti darbą reiškia virsti robotais. Pas mus McDonalde veikia normaliai, kai turi instrukcijas: čia dedi mėsainį, čia užpili padažą. Mūsų kūrybiniame darbe tai visiškai neveikia.
Ar tiesa, kad viskas, ką sakėte, gyvena pasaulyje be konkurencijos, o chaosas ten toks malonus, ir šiame chaose nėra prieštaravimų, niekas nenori nieko valgyti ar žudyti? Kaip turėtų elgtis konkurencija ir „DevOps“?
Na, tai priklauso nuo to, apie kokią konkurenciją kalbame. Ar tai apie konkurenciją darbo vietoje ar konkurenciją tarp įmonių?
Apie paslaugų konkurenciją, kuri egzistuoja todėl, kad paslaugos nėra kelios įmonės. Kuriame naujo tipo informacinę aplinką ir bet kuri aplinka negali gyventi be konkurencijos. Visur yra konkurencija.
Tas pats „Netflix“, mes juos laikome sektinu pavyzdžiu. Kodėl jie tai sugalvojo? Nes jie turėjo būti konkurencingi. Šis judėjimo lankstumas ir greitis yra būtent labai konkurencingas reikalavimas; tai mūsų sistemose įveda chaosą. Tai reiškia, kad chaosas nėra kažkas, ką mes sąmoningai darome, nes to norime, tai kažkas, kas vyksta, nes pasaulis to reikalauja. Mes tiesiog turime prisitaikyti. Ir chaosas, tai kaip tik konkurencijos rezultatas.
Ar tai reiškia, kad chaosas yra tikslų nebuvimas? Arba tie tikslai, kurių nenorime matyti? Mes esame namuose ir nesuprantame kitų tikslų. Konkurencija iš tikrųjų kyla dėl to, kad turime aiškius tikslus ir žinome, kur atsidursime kiekvieną kitą akimirką. Tai, mano požiūriu, yra „DevOps“ esmė.
Taip pat pažiūrėkite į klausimą. Manau, kad visi turime tą patį tikslą: išgyventi ir tai padaryti
didžiausias malonumas. Ir bet kurios organizacijos konkurencinis tikslas yra tas pats. Išgyvenimas dažnai vyksta per konkurenciją, nieko negali padaryti.
Šių metų konferencija gruodžio 7 dieną vyks Technopolyje. Prašymus ataskaitoms gauti priimame iki lapkričio 11 d. mums, jei norite pasikalbėti.
Dalyvių registracija vyksta, bilietai kainuoja 7000 rublių. Prisijunk prie mūsų!
Šaltinis: www.habr.com