Anton Weiss, stigter en direkteur van Otomato Software, een van die inisieerders en instrukteurs van die eerste DevOps-sertifisering in Israel, het verlede jaar gepraat oor chaosteorie en die hoofbeginsels van chaos-ingenieurswese, en het ook verduidelik hoe die ideale DevOps-organisasie van die toekoms werk.
Ons het 'n teksweergawe van die verslag voorberei.
Goeie more
DevOpsDays in Moskou vir die tweede jaar in 'n ry, dit is my tweede keer op hierdie verhoog, baie van julle is vir die tweede keer in hierdie kamer. Wat beteken dit? Dit beteken dat die DevOps-beweging in Rusland groei, vermeerder, en bowenal beteken dit dat die tyd aangebreek het om te praat oor wat DevOps in 2018 is.
Steek jou hande op wie dink dat DevOps reeds in 2018 'n beroep is? Daar is sulkes. Is daar enige DevOps-ingenieurs in die kamer wie se posbeskrywing sê "DevOps Engineer"? Is daar enige DevOps-bestuurders in die kamer? Daar is nie so nie. DevOps-argitekte? Ook nie. Nie genoeg. Is dit regtig waar dat niemand sê hulle is 'n DevOps-ingenieur nie?
So meeste van julle dink dit is 'n anti-patroon? Dat so 'n beroep nie moet bestaan nie? Ons kan dink wat ons wil, maar terwyl ons dink, beweeg die bedryf plegtig vorentoe na die klank van die DevOps-trompet.
Wie het gehoor van 'n nuwe onderwerp genaamd DevDevOps? Dit is 'n nuwe tegniek wat doeltreffende samewerking tussen ontwikkelaars en devops moontlik maak. En nie so nuut nie. Te oordeel aan Twitter het hulle al 4 jaar gelede hieroor begin praat. En tot nou toe groei en groei belangstelling hierin, dit wil sê daar is 'n probleem. Die probleem moet opgelos word.
Ons is kreatiewe mense, ons rus nie net rustig nie. Ons sê: DevOps is nie 'n omvattende genoeg woord nie; dit kort steeds allerhande verskillende, interessante elemente. En ons gaan na ons geheime laboratoriums en begin interessante mutasies produseer: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Die logika is yster, reg? Ons afleweringstelsel is nie funksioneel nie, ons stelsels is onstabiel en ons gebruikers is ontevrede, ons het nie tyd om sagteware betyds uit te voer nie, ons pas nie by die begroting in nie. Hoe gaan ons dit alles oplos? Ons sal met 'n nuwe woord vorendag kom! Dit sal eindig met "Ops" en die probleem is opgelos.
So ek noem hierdie benadering - "Ops, en die probleem is opgelos."
Dit vervaag alles op die agtergrond as ons onsself herinner hoekom ons met dit alles vorendag gekom het. Ons het met hierdie hele DevOps-ding vorendag gekom om sagteware-aflewering en ons eie werk in hierdie proses so ongehinderd, pynloos, doeltreffend en die belangrikste, aangenaam as moontlik te maak.
DevOps het uit pyn gegroei. En ons is moeg vir lyding. En om dit alles te laat gebeur, maak ons staat op immergroen praktyke: effektiewe samewerking, vloeipraktyke, en die belangrikste, stelseldenke, want daarsonder werk geen DevOps nie.
Wat is die stelsel?
En as ons reeds van sisteemdenke praat, laat ons onsself herinner wat 'n sisteem is.
As jy 'n revolusionêre hacker is, dan is die stelsel vir jou duidelik boos. Dis ’n wolk wat oor jou hang en jou dwing om dinge te doen wat jy nie wil doen nie.
Uit die oogpunt van sisteemdenke is 'n sisteem 'n geheel wat uit dele bestaan. In hierdie sin is elkeen van ons 'n sisteem. Die organisasies waarin ons werk, is stelsels. En wat ek en jy bou, word 'n stelsel genoem.
Dit alles is deel van een groot sosio-tegnologiese stelsel. En slegs as ons verstaan hoe hierdie sosio-tegnologiese stelsel saamwerk, eers dan sal ons in staat wees om werklik iets in hierdie saak te optimaliseer.
Vanuit 'n sisteemdenkperspektief het 'n sisteem verskeie interessante eienskappe. Eerstens bestaan dit uit dele, wat beteken dat die gedrag daarvan afhang van die gedrag van die dele. Boonop is al sy dele ook interafhanklik. Dit blyk dat hoe meer dele 'n stelsel het, hoe moeiliker is dit om sy gedrag te verstaan of te voorspel.
Vanuit 'n gedragsoogpunt is daar nog 'n interessante feit. Die stelsel kan iets doen wat nie een van sy individuele dele kan doen nie.
Soos dr. Russell Ackoff (een van die stigters van sisteemdenke) gesê het, dit is redelik maklik om met 'n gedagte-eksperiment te bewys. Byvoorbeeld, wie in die kamer weet hoe om kode te skryf? Daar is baie hande, en dit is normaal, want dit is een van die hoofvereistes vir ons beroep. Weet jy hoe om te skryf, maar kan jou hande kode apart van jou skryf? Daar is mense wat sal sê: "Dit is nie my hande wat die kode skryf nie, dit is my brein wat die kode skryf." Kan jou brein kode apart van jou skryf? Wel, waarskynlik nie.
Die brein is 'n wonderlike masjien, ons weet nie eers 10% van hoe dit daar werk nie, maar dit kan nie apart funksioneer van die sisteem wat ons liggaam is nie. En dit is maklik om te bewys: maak jou skedel oop, haal jou brein uit, sit dit voor die rekenaar, laat hom iets eenvoudig probeer skryf. "Hallo, wêreld" in Python, byvoorbeeld.
As 'n sisteem iets kan doen wat nie een van sy dele afsonderlik kan doen nie, beteken dit dat sy gedrag nie deur die gedrag van sy dele bepaal word nie. Waardeur word dit dan bepaal? Dit word bepaal deur die interaksie tussen hierdie dele. En dienooreenkomstig, hoe meer dele, hoe meer kompleks die interaksies, hoe moeiliker is dit om die gedrag van die stelsel te verstaan en te voorspel. En dit maak so 'n stelsel chaoties, want enige, selfs die mees onbeduidende, onsigbare verandering in enige deel van die stelsel kan tot heeltemal onvoorspelbare resultate lei.
Hierdie sensitiwiteit vir aanvanklike toestande is die eerste keer ontdek en bestudeer deur die Amerikaanse weerkundige Ed Lorenz. Daarna is dit die "vlinder-effek" genoem en het gelei tot die ontwikkeling van 'n beweging van wetenskaplike denke genaamd "chaosteorie". Hierdie teorie het een van die groot paradigmaverskuiwings in die 20ste eeuse wetenskap geword.
Chaos teorie
Mense wat chaos bestudeer, noem hulself chaosoloë.
Eintlik was die rede vir hierdie verslag dat ek, terwyl ek met komplekse verspreide stelsels en groot internasionale organisasies gewerk het, op 'n stadium besef het dat dit is wie ek voel. Ek is 'n chaosoloog. Dit is basies 'n slim manier om te sê: "Ek verstaan nie wat hier aangaan nie en ek weet nie wat om daaraan te doen nie."
Ek dink dat baie van julle ook dikwels so voel, so julle is ook chaosoloë. Ek nooi jou uit na die gilde van chaosoloë. Die stelsels wat ek en jy, liewe mede-chaosoloë, sal bestudeer, word "komplekse aanpasbare stelsels" genoem.
Wat is aanpasbaarheid? Aanpasbaarheid beteken dat die individuele en kollektiewe gedrag van dele in so 'n aanpasbare sisteem verander en self-organiseer, reageer op gebeure of kettings van mikro-gebeure in die sisteem. Dit wil sê, die sisteem pas aan by veranderinge deur selforganisasie. En hierdie vermoë om self te organiseer is gebaseer op die vrywillige, heeltemal gedesentraliseerde samewerking van vrye outonome agente.
Nog 'n interessante eienskap van sulke stelsels is dat hulle vrylik skaalbaar is. Wat ons, as chaosoloë-ingenieurs, ongetwyfeld behoort te interesseer. Dus, as ons gesê het dat die gedrag van 'n komplekse stelsel bepaal word deur die interaksie van sy dele, waarin moet ons dan belangstel? Interaksie.
Daar is nog twee interessante bevindings.
Eerstens verstaan ons dat 'n komplekse stelsel nie vereenvoudig kan word deur sy dele te vereenvoudig nie. Tweedens, die enigste manier om 'n komplekse stelsel te vereenvoudig, is deur die interaksies tussen sy dele te vereenvoudig.
Hoe tree ons in interaksie? Ek en jy is almal dele van 'n groot inligtingstelsel genaamd menslike samelewing. Ons het interaksie deur 'n gemeenskaplike taal, as ons dit het, as ons dit vind.
Maar taal self is 'n komplekse aanpasbare sisteem. Gevolglik, om meer doeltreffend en eenvoudig te kan kommunikeer, moet ons 'n soort protokolle skep. Dit wil sê, een of ander volgorde van simbole en aksies wat die uitruil van inligting tussen ons eenvoudiger, meer voorspelbaar, meer verstaanbaar sal maak.
Ek wil sê dat tendense na kompleksiteit, na aanpasbaarheid, na desentralisasie, na chaos in alles opgespoor kan word. En in die sisteme wat ek en jy bou, en in daardie sisteme waarvan ons deel is.
En om nie ongegrond te wees nie, kom ons kyk hoe die stelsels wat ons skep, verander.
Jy het gewag vir hierdie woord, ek verstaan. Ons is by 'n DevOps-konferensie, vandag sal hierdie woord omtrent 'n honderdduisend keer gehoor word en dan sal ons snags daaroor droom.
Mikrodienste is die eerste sagteware-argitektuur wat na vore gekom het as 'n reaksie op DevOps-praktyke, wat ontwerp is om ons stelsels meer buigsaam, meer skaalbaar te maak en deurlopende aflewering te verseker. Hoe doen sy dit? Deur die volume dienste te verminder, die omvang van probleme wat hierdie dienste verwerk te verminder, die afleweringstyd te verminder. Dit wil sê, ons verminder en vereenvoudig dele van die stelsel, vermeerder hul aantal, en dienooreenkomstig neem die kompleksiteit van interaksies tussen hierdie dele altyd toe, dit wil sê nuwe probleme ontstaan wat ons moet oplos.
Mikrodienste is nie die einde nie, mikrodienste is oor die algemeen reeds gister, want Serverless kom. Alle bedieners het afgebrand, geen bedieners, geen bedryfstelsels nie, net suiwer uitvoerbare kode. Konfigurasies is apart, state is apart, alles word beheer deur gebeure. Skoonheid, netheid, stilte, geen gebeure, niks gebeur nie, volledige orde.
Waar is die kompleksiteit? Die moeilikheid is natuurlik in die interaksies. Hoeveel kan 'n funksie op sy eie doen? Hoe werk dit in wisselwerking met ander funksies? Boodskaprye, databasisse, balanseerders. Hoe om 'n gebeurtenis te herskep wanneer 'n mislukking plaasgevind het? Baie vrae en min antwoorde.
Mikrodienste en bedienerloos is wat ons geek hipsters Cloud Native noem. Dit gaan alles oor die wolk. Maar die wolk is ook inherent beperk in sy skaalbaarheid. Ons is gewoond daaraan om daaraan te dink as 'n verspreide stelsel. Trouens, waar woon wolkverskaffers se bedieners? In datasentrums. Dit wil sê, ons het 'n soort gesentraliseerde, baie beperkte, verspreide model hier.
Vandag verstaan ons dat die Internet van Dinge nie meer net groot woorde is nie dat selfs volgens beskeie voorspellings miljarde toestelle wat aan die internet gekoppel is, in die volgende vyf tot tien jaar op ons wag. 'n Groot hoeveelheid nuttige en nuttelose data wat in die wolk saamgesmelt en vanaf die wolk opgelaai sal word.
Die wolk sal nie hou nie, so ons praat toenemend van iets wat randrekenaars genoem word. Of ek hou ook van die wonderlike definisie van "fog computing". Dit is gehul in die mistiek van romantiek en misterie.
Misberekening. Die punt is dat wolke gesentraliseerde klompe water, stoom, ys en klippe is. En mis is waterdruppels wat om ons in die atmosfeer gestrooi is.
In die misparadigma word die meeste van die werk deur hierdie druppels heeltemal outonoom of in samewerking met ander druppels gedoen. En hulle draai eers na die wolk wanneer hulle regtig gedruk word.
Dit wil sê weer desentralisasie, outonomie, en natuurlik verstaan baie van julle reeds waarheen dit alles gaan, want jy kan nie oor desentralisasie praat sonder om die blokketting te noem nie.
Daar is diegene wat glo, dit is diegene wat in cryptocurrency belê het. Daar is diegene wat glo maar bang is, soos ek byvoorbeeld. En daar is diegene wat nie glo nie. Hier kan jy anders behandel. Daar is tegnologie, 'n nuwe onbekende saak, daar is probleme. Soos enige nuwe tegnologie, laat dit meer vrae ontstaan as wat dit beantwoord.
Die hype rondom blockchain is verstaanbaar. Goudstormloop opsy, die tegnologie self hou merkwaardige beloftes in vir 'n beter toekoms: meer vryheid, meer outonomie, verspreide globale vertroue. Wat wil jy nie hê nie?
Gevolglik begin meer en meer ingenieurs regoor die wêreld gedesentraliseerde toepassings ontwikkel. En dit is 'n krag wat nie van die hand gewys kan word deur bloot te sê: "Ah, blockchain is net 'n swak geïmplementeerde verspreide databasis." Of soos skeptici daarvan hou om te sê: "Daar is geen werklike toepassings vir blockchain nie." As jy daaroor dink, 150 jaar gelede het hulle dieselfde oor elektrisiteit gesê. En hulle was selfs in sekere opsigte reg, want wat elektrisiteit vandag moontlik maak, was geensins moontlik in die 19de eeu nie.
Terloops, wie weet watter soort logo op die skerm is? Dit is Hyperledger. Dit is 'n projek wat onder die vaandel van The Linux Foundation ontwikkel word en sluit 'n stel blokkettingtegnologieë in. Dit is werklik die sterkte van ons oopbrongemeenskap.
Chaos Ingenieurswese
Dus, die stelsel wat ons ontwikkel, word meer en meer kompleks, meer en meer chaoties, en meer en meer aanpasbaar. Netflix is pioniers van mikrodiensstelsels. Hulle was van die eerstes wat dit verstaan het, hulle het 'n stel gereedskap ontwikkel wat hulle Simian Army genoem het, waarvan die bekendste . Hy het gedefinieer wat bekend geword het as .
Terloops, in die proses om aan die verslag te werk, het ons selfs hierdie teks in Russies vertaal, so gaan na , lees, lewer kommentaar, skel.
Kortliks sê die beginsels van chaos-ingenieurswese die volgende. Komplekse verspreide stelsels is inherent onvoorspelbaar en inherent karig. Foute is onvermydelik, wat beteken dat ons hierdie foute moet aanvaar en op 'n heeltemal ander manier met hierdie stelsels moet werk.
Ons moet self probeer om hierdie foute in ons produksiestelsels in te voer om ons stelsels te toets vir dieselfde aanpasbaarheid, hierdie einste vermoë tot selforganisasie, vir oorlewing.
En dit verander alles. Nie net hoe ons stelsels in produksie bekendstel nie, maar ook hoe ons dit ontwikkel, hoe ons dit toets. Daar is geen proses van stabilisering of bevriesing van die kode nie; inteendeel, daar is 'n konstante proses van destabilisering. Ons probeer die stelsel doodmaak en sien dat dit aanhou oorleef.
Verspreide stelselintegrasieprotokolle
Gevolglik vereis dit dat ons stelsels op een of ander manier verander. Om vir hulle meer stabiel te word, benodig hulle 'n paar nuwe protokolle vir interaksie tussen hul dele. Sodat hierdie dele kan saamstem en tot een of ander selforganisasie kan kom. En allerhande nuwe gereedskap, nuwe protokolle ontstaan, wat ek noem "protokolle vir die interaksie van verspreide stelsels."
Waarvan praat ek? Eerstens die projek . Sommige poog om 'n algemene verspreide opsporingsprotokol te skep, wat 'n absoluut onontbeerlike hulpmiddel is om komplekse verspreide stelsels te ontfout.
Verder - . Ons sê dat ons nie kan voorspel wat met die sisteem gaan gebeur nie, dit wil sê ons moet die waarneembaarheid, waarneembaarheid daarvan verhoog. Opentracing behoort aan 'n familie van gereedskap wat waarneembaarheid aan ons stelsels gee. Maar ons het waarneembaarheid nodig om te bepaal of die stelsel optree soos ons dit verwag of nie. Hoe definieer ons verwagte gedrag? Deur 'n soort beleid, 'n stel reëls te definieer. Die Open Policy Agent-projek werk daaraan om hierdie stel reëls oor 'n spektrum te definieer wat wissel van toegang tot hulpbrontoewysing.
Soos ons gesê het, word ons stelsels toenemend gebeurtenisgedrewe. Bedienerloos is 'n goeie voorbeeld van gebeurtenisgedrewe stelsels. Om gebeurtenisse tussen stelsels oor te dra en na te spoor, het ons 'n gemeenskaplike taal nodig, 'n gemeenskaplike protokol vir hoe ons oor gebeure praat, hoe ons dit aan mekaar oordra. Dit is wat 'n projek genoem het .
Die konstante stroom veranderinge wat oor ons stelsels spoel en dit voortdurend destabiliseer, is 'n deurlopende stroom sagteware-artefakte. Om hierdie konstante vloei van veranderinge te handhaaf, benodig ons 'n soort algemene protokol waardeur ons kan praat oor wat 'n sagteware-artefak is, hoe dit getoets word, watter verifikasie dit geslaag het. Dit is wat 'n projek genoem het . Dit wil sê, 'n algemene metadataprotokol vir sagteware-artefakte.
En laastens, as ons wil hê dat ons stelsels heeltemal onafhanklik, aanpasbaar en self-georganiseerd moet wees, moet ons hulle die reg tot selfidentifikasie gee. Projek genoem Dit is presies wat hy doen. Dit is ook 'n projek onder die vaandel van die Cloud Native Computing Foundation.
Al hierdie projekte is jonk, hulle het almal ons liefde, ons bekragtiging nodig. Dit is alles oopbron, ons toetsing, ons implementering. Hulle wys ons waarheen tegnologie op pad is.
Maar DevOps het nog nooit hoofsaaklik oor tegnologie gegaan nie, dit was nog altyd oor samewerking tussen mense. En dienooreenkomstig, as ons wil hê dat die stelsels wat ons ontwikkel moet verander, dan moet ons self verander. Trouens, ons verander in elk geval; ons het nie veel van 'n keuse nie.
Daar is 'n wonderlike Britse skrywer Rachel Botsman, waarin sy oor die evolusie van vertroue deur die menslike geskiedenis skryf. Sy sê aanvanklik, in primitiewe samelewings, was vertroue plaaslik, dit wil sê, ons het net diegene vertrou wat ons persoonlik geken het.
Toe was daar ’n baie lang tydperk – ’n donker tyd toe vertroue gesentraliseer is, toe ons mense begin vertrou het wat ons nie ken nie op grond van die feit dat ons aan dieselfde publieke of staatsinstelling behoort.
En dit is wat ons in ons moderne wêreld sien: vertroue word al hoe meer verspreid en gedesentraliseerd, en dit is gebaseer op die vryheid van inligtingvloei, op die beskikbaarheid van inligting.
As jy daaroor dink, is hierdie einste toeganklikheid, wat hierdie vertroue moontlik maak, wat ek en jy implementeer. Dit beteken dat beide die manier waarop ons saamwerk en die manier waarop ons dit doen moet verander, want die gesentraliseerde, hiërargiese IT-organisasies van ouds werk nie meer nie. Hulle begin doodgaan.
DevOps Organisasie Fundamentals
Die ideale DevOps-organisasie van die toekoms is 'n gedesentraliseerde, aanpasbare stelsel wat bestaan uit outonome spanne, elk bestaande uit outonome individue. Hierdie spanne is oor die wêreld versprei en werk effektief met mekaar saam deur asinchroniese kommunikasie te gebruik, met hoogs deursigtige kommunikasieprotokolle. Baie mooi, is dit nie? 'n Baie mooi toekoms.
Natuurlik is niks hiervan moontlik sonder kulturele verandering nie. Ons moet transformasieleierskap, persoonlike verantwoordelikheid, interne motivering hê.
Dit is die basis van DevOps-organisasies: inligting deursigtigheid, asinchroniese kommunikasie, transformasionele leierskap, desentralisasie.
Uitbrand
Die stelsels waarvan ons deel is en dié wat ons bou is toenemend chaoties, en dit is moeilik vir ons mense om hierdie gedagte te hanteer, dit is moeilik om die illusie van beheer prys te gee. Ons probeer voortgaan om hulle te beheer, en dit lei dikwels tot uitbranding. Ek sê dit uit eie ervaring, ek het ook verbrand, ek is ook gestrem deur onvoorsiene mislukkings in produksie.
Uitbranding vind plaas wanneer ons probeer om iets te beheer wat inherent onbeheerbaar is. Wanneer ons uitbrand, verloor alles sy betekenis, want ons verloor die begeerte om iets nuuts te doen, ons raak verdedigend en begin verdedig wat ons het.
Die ingenieursberoep, soos ek myself dikwels wil herinner, is in die eerste plek 'n kreatiewe beroep. As ons die begeerte verloor om iets te skep, dan verander ons in as, verander in as. Mense brand uit, hele organisasies brand uit.
Na my mening, net die aanvaarding van die kreatiewe krag van chaos, net die bou van samewerking volgens die beginsels daarvan is wat ons sal help om nie te verloor wat goed is in ons beroep nie.
Dit is wat ek vir jou wens: om lief te wees vir jou werk, om lief te hê vir wat ons doen. Hierdie wêreld voed op inligting, ons het die eer om dit te voed. So kom ons bestudeer chaos, kom ons wees chaosoloë, kom ons bring waarde, skep iets nuuts, wel, probleme, soos ons reeds uitgevind het, is onvermydelik, en wanneer hulle verskyn, sal ons eenvoudig sê “Ops!” En die probleem is opgelos.
Wat anders as Chaos Monkey?
Trouens, al hierdie instrumente is so jonk. Dieselfde Netflix het gereedskap vir hulself gebou. Bou jou eie gereedskap. Lees die beginsels van chaos-ingenieurswese en leef tot daardie beginsels eerder as om ander gereedskap te probeer vind wat iemand anders reeds gebou het.
Probeer om te verstaan hoe jou stelsels afbreek en begin hulle afbreek en kyk hoe hulle stand hou. Dit kom eerste. En jy kan gereedskap soek. Daar is allerhande projekte.
Ek het die oomblik nie mooi verstaan toe jy gesê het dat die stelsel nie vereenvoudig kan word deur sy komponente te vereenvoudig nie, en het dadelik aanbeweeg na mikrodienste, wat die stelsel vereenvoudig deur die komponente self te vereenvoudig en interaksies te bemoeilik. Dit is in wese twee dele wat mekaar weerspreek.
Dit is reg, mikrodienste is in die algemeen 'n baie kontroversiële onderwerp. Trouens, die vereenvoudiging van dele verhoog buigsaamheid. Wat bied mikrodienste? Hulle gee ons buigsaamheid en spoed, maar hulle gee ons beslis nie eenvoud nie. Hulle verhoog die moeilikheidsgraad.
Dus, in die DevOps-filosofie is mikrodienste nie so 'n goeie ding nie?
Enige goed het 'n keersy. Die voordeel is dat dit buigsaamheid verhoog, wat ons in staat stel om vinniger veranderinge aan te bring, maar dit verhoog die kompleksiteit en dus die broosheid van die hele stelsel.
Tog, wat is meer klem: op die vereenvoudiging van interaksie of op die vereenvoudiging van dele?
Die klem is natuurlik op die vereenvoudiging van interaksies, want as ons hierna kyk vanuit die oogpunt van hoe ons met jou werk, dan moet ons eerstens aandag gee aan die vereenvoudiging van interaksies, en nie op die vereenvoudiging van die werk nie. van elkeen van ons afsonderlik. Want om werk te vereenvoudig beteken om in robotte te verander. Hier by McDonald's werk dit normaal as jy instruksies het: hier sit jy die burger, hier gooi jy die sous daarop. Dit werk glad nie in ons kreatiewe werk nie.
Is dit waar dat alles wat jy gesê het in 'n wêreld sonder mededinging leef, en die chaos daar is so vriendelik, en daar is geen teenstrydighede binne hierdie chaos nie, niemand wil iemand eet of doodmaak nie? Hoe moet kompetisie en DevOps vaar?
Wel, dit hang af van watter soort kompetisie ons praat. Gaan dit oor mededinging in die werkplek of mededinging tussen maatskappye?
Oor die kompetisie van dienste wat bestaan omdat dienste nie verskeie maatskappye is nie. Ons skep 'n nuwe tipe inligtingsomgewing, en enige omgewing kan nie sonder mededinging leef nie. Daar is oral mededinging.
Dieselfde Netflix, ons neem hulle as 'n rolmodel. Hoekom het hulle hiermee vorendag gekom? Omdat hulle mededingend moes wees. Hierdie buigsaamheid en spoed van beweging is juis die baie mededingende vereiste; dit stel chaos in ons stelsels in. Dit wil sê, chaos is nie iets wat ons bewustelik doen omdat ons dit wil hê nie, dit is iets wat gebeur omdat die wêreld dit vereis. Ons moet net aanpas. En chaos, dit is juis die gevolg van mededinging.
Beteken dit dat chaos as 't ware die afwesigheid van doelwitte is? Of daardie doelwitte wat ons nie wil sien nie? Ons is in die huis en verstaan nie die doelwitte van ander nie. Mededinging is in werklikheid te danke aan die feit dat ons duidelike doelwitte het en ons weet waar ons op elke volgende oomblik in tyd sal eindig. Dit, uit my oogpunt, is die essensie van DevOps.
Kyk ook na die vraag. Ek dink ons het almal dieselfde doel: om te oorleef en dit mee te doen
grootste plesier. En die mededingende doelwit van enige organisasie is dieselfde. Oorlewing vind dikwels plaas deur kompetisie, daar is niks wat jy daaraan kan doen nie.
Vanjaar se konferensie word op 7 Desember by Technopolis gehou. Tot 11 November aanvaar ons aansoeke vir verslae. ons as jy wil praat.
Registrasie vir deelnemers is oop, kaartjies kos 7000 XNUMX roebels. Sluit by ons aan!
Bron: will.com