Anton Weiss, oprjochter en direkteur fan Otomato Software, ien fan 'e inisjatyfnimmers en ynstrukteurs fan' e earste DevOps-sertifikaasje yn Israel, spruts op ferline jier oer chaos teory en de haadprinsipes fan chaos engineering, en ek útlein hoe't de ideale DevOps organisaasje fan 'e takomst wurket.
Wy hawwe in tekstferzje fan it rapport taret.
Goeiemoarn
DevOpsDays yn Moskou foar it twadde jier op rige, dit is myn twadde kear op dit poadium, in protte fan jo binne foar de twadde kear yn dizze keamer. Wat betsjut dat? Dit betsjut dat de DevOps-beweging yn Ruslân groeit, fermannichfâldigt, en it wichtichste betsjut dat it tiid is om te praten oer wat DevOps is yn 2018.
Stek jo hannen op dy't tinke dat DevOps al in berop is yn 2018? Der binne sokke. Binne d'r DevOps-yngenieurs yn 'e keamer waans taakbeskriuwing seit "DevOps Engineer"? Binne d'r DevOps-managers yn 'e keamer? Der is gjin soks. DevOps arsjitekten? Ek nee. Net genoach. Is it echt wier dat gjinien seit dat se in DevOps-yngenieur binne?
Dat de measte fan jo tinke dat dit in anty-patroan is? Dat sa'n berop net bestean moat? Wy kinne tinke wat wy wolle, mar wylst wy tinke, giet de yndustry plechtich foarút nei it lûd fan 'e DevOps-trompet.
Wa hat heard oer in nij ûnderwerp neamd DevDevOps? Dit is in nije technyk dy't effektive gearwurking mooglik makket tusken ûntwikkelders en devops. En net sa nij. Nei Twitter te oardieljen, begûnen se hjir al 4 jier lyn oer te praten. En oant no ta groeit en groeit de belangstelling hjirfoar, dat is, der is in probleem. It probleem moat oplost wurde.
Wy binne kreative minsken, wy binne net gewoan rêstich. Wy sizze: DevOps is net in wiidweidich genôch wurd; it mist noch alle soarten ferskillende, nijsgjirrige eleminten. En wy geane nei ús geheime laboratoaren en begjinne ynteressante mutaasjes te produsearjen: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
De logika is izerbeklaaid, krekt? Us leveringssysteem is net funksjoneel, ús systemen binne ynstabyl en ús brûkers binne ûntefreden, wy hawwe gjin tiid om software op 'e tiid út te rollen, wy passe net yn it budzjet. Hoe sille wy dit alles oplosse? Wy komme mei in nij wurd! It sil einigje mei "Ops" en it probleem is oplost.
Dat ik neam dizze oanpak - "Ops, en it probleem is oplost."
Dit alles ferdwynt op 'e eftergrûn as wy ússels herinnerje wêrom't wy dit alles kamen. Wy kamen mei dit hiele DevOps-ding om softwareferliening en ús eigen wurk yn dit proses sa ûnbehindere, pynlik, effisjint, en vooral, noflik mooglik te meitsjen.
DevOps groeide út pine. En wy binne wurch fan it lijen. En om dit alles te barren, fertrouwe wy op evergreen praktiken: effektive gearwurking, flowpraktiken, en vooral, systeemtinken, want sûnder dat wurket gjin DevOps.
Wat is it systeem?
En as wy it al hawwe oer systeemtinken, litte wy ússels herinnerje wat in systeem is.
As jo in revolúsjonêre hacker binne, dan is it systeem dúdlik kwea foar jo. It is in wolk dy't oer jo hinget en jo twingt dingen te dwaan dy't jo net wolle.
Ut it eachpunt fan systeemtinken is in systeem in gehiel dat út dielen bestiet. Yn dizze sin is elk fan ús in systeem. De organisaasjes wêryn wy wurkje binne systemen. En wat jo en ik bouwe wurdt in systeem neamd.
Dit alles is ûnderdiel fan ien grut sosjaal-technologysk systeem. En allinich as wy begripe hoe't dit sosjaal-technologyske systeem gearwurket, allinich dan kinne wy wat yn dizze saak echt optimalisearje.
Ut in systeem tinken perspektyf, in systeem hat ferskate nijsgjirrige eigenskippen. Earst bestiet it út dielen, wat betsjut dat har gedrach hinget fan it gedrach fan 'e dielen. Boppedat binne al syn dielen ek ôfhinklik fan elkoar. It docht bliken dat hoe mear dielen in systeem hat, hoe dreger it is om syn gedrach te begripen of te foarsizzen.
Fanút in gedrachspunt is der in oar nijsgjirrich feit. It systeem kin wat dwaan dat net ien fan syn yndividuele dielen kin dwaan.
As Dr Russell Ackoff (ien fan 'e grûnlizzers fan systeem tinken) sei, dit is frij maklik te bewizen mei in gedachte eksperimint. Bygelyks, wa yn 'e keamer wit hoe te skriuwen koade? D'r binne in protte hannen, en dit is normaal, om't dit ien fan 'e wichtichste easken is foar ús berop. Witte jo hoe te skriuwen, mar kinne jo hannen skriuwe koade apart fan dysels? D'r binne minsken dy't sille sizze: "It binne net myn hannen dy't de koade skriuwe, it is myn harsens dat de koade skriuwt." Kin jo harsens koade apart fan jo skriuwe? No, wierskynlik net.
It brein is in geweldige masine, wy witte net iens 10% fan hoe't it dêr wurket, mar it kin net apart funksjonearje fan it systeem dat ús lichem is. En dit is maklik te bewizen: doch dyn skedel iepen, nim dyn harsens út, set dy foar de kompjûter, lit him besykje wat ienfâldich te skriuwen. "Hallo, wrâld" yn Python bygelyks.
As in systeem wat kin dwaan dat net ien fan syn dielen apart kin, dan betsjut dit dat syn gedrach net bepaald wurdt troch it gedrach fan syn dielen. Wêr wurdt it dan troch bepaald? It wurdt bepaald troch de ynteraksje tusken dizze dielen. En dêrtroch, hoe mear dielen, hoe komplekser de ynteraksjes, hoe dreger it is om it gedrach fan it systeem te begripen en te foarsizzen. En dit makket sa'n systeem chaotysk, om't elke, sels de meast ûnbelangrike, ûnsichtbere feroaring yn elk diel fan it systeem kin liede ta folslein ûnfoarspelbere resultaten.
Dizze gefoelichheid foar begjinomstannichheden waard earst ûntdutsen en studearre troch Amerikaanske meteorolooch Ed Lorenz. Dêrnei waard it it "flintereffekt" neamd en late ta de ûntwikkeling fan in beweging fan wittenskiplike gedachte neamd "chaos teory". Dizze teory waard ien fan 'e grutte paradigmaferoaringen yn' e wittenskip fan 'e 20e ieu.
Chaos teory
Minsken dy't gaos bestudearje neame harsels chaosologen.
Eigentlik wie de reden foar dit rapport dat ik, wurkje mei komplekse ferspraat systemen en grutte ynternasjonale organisaasjes, op in stuit realisearre dat dit is wa't ik fiel. Ik bin in chaosolooch. Dit is yn prinsipe in tûke manier om te sizzen: "Ik begryp net wat hjir bart en ik wit net wat ik der oan dwaan moat."
Ik tink dat in protte fan jim ek faak sa fiele, dus jim binne ek chaosologen. Ik noegje jo út foar it gilde fan chaosologen. De systemen dy't jo en ik, bêste kollega-chaosologen, sille studearje, wurde "komplekse adaptive systemen" neamd.
Wat is oanpassingsfermogen? Oanpassingsfermogen betsjut dat it yndividuele en kollektyf gedrach fan dielen yn sa'n adaptyf systeem feroaret en sels organisearret, reagearret op eveneminten of keatlingen fan mikro-eveneminten yn it systeem. Dat is, it systeem past him oan feroaringen troch selsorganisaasje. En dit fermogen om sels te organisearjen is basearre op 'e frijwillige, folslein desintralisearre gearwurking fan frije autonome aginten.
In oare nijsgjirrige eigenskip fan sokke systemen is dat se frij skalberber binne. Wat soe ús, as chaosologen-yngenieurs, sûnder mis ynteressearje moatte. Dus, as wy seine dat it gedrach fan in kompleks systeem wurdt bepaald troch de ynteraksje fan syn dielen, wat moatte wy dan ynteressearre wêze? Wikselwurking.
D'r binne noch twa nijsgjirrige fynsten.
Earst, wy begripe dat in kompleks systeem kin net ferienfâldige wurde troch ferienfâldigjen syn dielen. Twadder is de ienige manier om in kompleks systeem te ferienfâldigjen troch de ynteraksjes tusken har dielen te ferienfâldigjen.
Hoe dogge wy omgean? Jo en ik binne allegear ûnderdielen fan in grut ynformaasjesysteem neamd minsklike maatskippij. Wy ynteraksje fia in mienskiplike taal, as wy it hawwe, as wy it fine.
Mar taal sels is in kompleks adaptyf systeem. Dêrom, om effisjinter en ienfâldich te ynteraksje, moatte wy wat soarte protokollen oanmeitsje. Dat is, wat opienfolging fan symboalen en aksjes dy't de útwikseling fan ynformaasje tusken ús ienfâldiger, mear foarsisber, mear begryplik meitsje sil.
Ik wol sizze dat trends nei kompleksiteit, nei oanpassingsfermogen, nei desintralisaasje, nei gaos yn alles werom te finen binne. En yn 'e systemen dy't jo en ik bouwe, en yn dy systemen dêr't wy diel fan binne.
En om net ûnbegrûn te wêzen, litte wy sjen hoe't de systemen dy't wy meitsje feroarje.
Jo wachtsje op dit wurd, begryp ik. Wy binne op in DevOps-konferinsje, hjoed sil dit wurd sa'n hûnderttûzen kear heard wurde en dan sille wy der nachts oer dreame.
Mikrotsjinsten binne de earste software-arsjitektuer dy't ûntstie as in reaksje op DevOps-praktiken, dy't is ûntworpen om ús systemen fleksibeler, skalberber te meitsjen en trochgeande levering te garandearjen. Hoe docht se dit? Troch it ferminderjen fan it folume fan tsjinsten, it ferminderjen fan de omfang fan problemen dy't dizze tsjinsten ferwurkje, it ferminderjen fan de levertiid. Dat is, wy ferminderje en ferienfâldigje dielen fan it systeem, tanimme harren oantal, en dêrtroch, de kompleksiteit fan ynteraksjes tusken dizze dielen hieltyd grutter, dat is, nije problemen ûntstean dy't wy moatte oplosse.
Mikrotsjinsten binne net it ein, mikrotsjinsten binne yn 't algemien juster al, om't Serverless komt. Alle servers ôfbaarnd, gjin servers, gjin bestjoeringssystemen, gewoan pure útfierbere koade. Konfiguraasjes binne apart, steaten binne apart, alles wurdt regele troch eveneminten. Skientme, skjinens, stilte, gjin eveneminten, neat bart, folsleine oarder.
Wêr is de kompleksiteit? De muoite leit fansels yn 'e ynteraksjes. Hoefolle kin ien funksje sels dwaan? Hoe wurket it mei oare funksjes? Berjochtwachtrijen, databases, balancers. Hoe kinne jo in evenemint opnij oanmeitsje as in mislearring barde? In protte fragen en in pear antwurden.
Microservices en Serverless binne wat wy geek-hipsters neame Cloud Native. It giet allegear oer de wolk. Mar de wolk is ek ynherent beheind yn syn skalberens. Wy binne wend om it te tinken as in ferspraat systeem. Yn feite, wêr libje de servers fan wolkproviders? Yn datasintra. Dat is, wy hawwe hjir in soarte fan sintralisearre, tige beheind, ferspraat model.
Tsjintwurdich begripe wy dat it Internet of Things net langer allinich grutte wurden is dat sels neffens beskieden foarsizzingen miljarden apparaten ferbûn mei it ynternet yn 'e kommende fiif oant tsien jier op ús wachtsje. In enoarme hoemannichte nuttige en nutteleaze gegevens dy't sille wurde gearfoege yn 'e wolk en uploaded út' e wolk.
De wolk sil net duorje, dus wy prate hieltyd mear oer iets dat edge computing hjit. Of ik hâld ek fan 'e prachtige definysje fan "fog computing". It is omhuld yn de mystyk fan romantyk en mystearje.
Mist komputer. It punt is dat wolken sintralisearre klompen fan wetter, stoom, iis en stiennen binne. En mist is wetterdruppels dy't om ús hinne ferspraat binne yn 'e atmosfear.
Yn it mistparadigma wurdt it measte wurk dien troch dizze drippen folslein autonoom of yn gearwurking mei oare drippen. En se draaie allinich nei de wolk as se echt yndruk wurde.
Dat is, wer desintralisaasje, autonomy, en, fansels, in protte fan jo begripe al wêr't dit alles hinne giet, om't jo net oer desintralisaasje prate kinne sûnder de blockchain te neamen.
D'r binne dejingen dy't leauwe, dit binne dyjingen dy't ynvestearre hawwe yn cryptocurrency. Der binne dyjingen dy't leauwe mar bang binne, lykas ik bygelyks. En der binne dyjingen dy't net leauwe. Hjir kinne jo oars behannelje. D'r is technology, in nije ûnbekende saak, d'r binne problemen. Lykas elke nije technology ropt it mear fragen op dan it antwurdet.
De hype om blockchain is begryplik. Goudkoarts oan 'e kant, de technology sels hâldt opmerklike beloften foar in helderdere takomst: mear frijheid, mear autonomy, ferspraat wrâldwide fertrouwen. Wat is net te wollen?
Dêrtroch begjinne mear en mear yngenieurs oer de heule wrâld desintralisearre applikaasjes te ûntwikkeljen. En dit is in krêft dy't net kin wurde ûntslein troch gewoan te sizzen: "Ahh, blockchain is gewoan in min ymplementearre ferspraat databank." Of as skeptisy graach sizze: "D'r binne gjin echte applikaasjes foar blockchain." As jo der oer tinke, 150 jier lyn seinen se itselde oer elektrisiteit. En se hienen sels yn guon opsichten gelyk, want wat elektrisiteit hjoeddedei mooglik makket, wie yn de 19e iuw op gjin inkelde manier mooglik.
Trouwens, wa wit wat foar logo op it skerm stiet? Dit is Hyperledger. Dit is in projekt dat wurdt ûntwikkele ûnder auspysjes fan The Linux Foundation en omfettet in set blockchain-technologyen. Dit is wirklik de sterkte fan ús iepen boarne-mienskip.
Chaos Engineering
Dat, it systeem dat wy ûntwikkelje wurdt hieltyd komplekser, mear en mear chaotysk, en mear en mear oanpasber. Netflix binne pioniers fan mikroservicesystemen. Se wiene ûnder de earsten dy't dit begrepen, se ûntwikkele in set ark dat se Simian Army neamden, wêrfan de meast ferneamde wie . Hy definiearre wat bekend waard as .
Trouwens, yn it proses fan it wurk oan it rapport hawwe wy dizze tekst sels oerset yn it Russysk, dus gean nei , lêze, kommentaar, skele.
Koartsein sizze de prinsipes fan chaos engineering it folgjende. Komplekse ferspraat systemen binne ynherint ûnfoarspelber en ynherint buggy. Flaters binne ûnûntkomber, wat betsjut dat wy dizze flaters moatte akseptearje en op in folslein oare manier mei dizze systemen wurkje.
Wy sels moatte besykje dizze flaters yn te fieren yn ús produksjesystemen om ús systemen te testen foar deselde oanpassingsfermogen, dit fermogen foar selsorganisaasje, foar oerlibjen.
En dat feroaret alles. Net allinich hoe't wy systemen yn produksje lansearje, mar ek hoe't wy se ûntwikkelje, hoe't wy se testen. D'r is gjin proses fan stabilisaasje of befriezing fan 'e koade; krekt oarsom, d'r is in konstant proses fan destabilisaasje. Wy besykje it systeem te deadzjen en te sjen dat it bliuwt te oerlibjen.
Ferspraat systeem yntegraasje protokollen
Dêrtroch fereasket dit dat ús systemen op ien of oare manier feroarje. Om har stabiler te wurden, hawwe se wat nije protokollen nedich foar ynteraksje tusken har dielen. Sadat dizze dielen oerienkomme kinne en ta in soarte fan selsorganisaasje komme kinne. En alle soarten nije ark, nije protokollen ûntsteane, dy't ik neam "protokollen foar de ynteraksje fan ferspraat systemen."
Wêr haw ik it oer? Earst, it projekt . Guon besykje in algemien ferspraat trackingprotokol te meitsjen, dat in absolút ûnmisber ark is foar it debuggen fan komplekse ferspraat systemen.
Fierder - . Wy sizze dat wy net kinne foarsizze wat sil barre mei it systeem, dat is, wy moatte fergrutsje syn observability, observability. Opentracing heart ta in famylje fan ark dy't observabiliteit jouwe oan ús systemen. Mar wy hawwe observabiliteit nedich om te bepalen oft it systeem gedraacht sa't wy it ferwachtsje of net. Hoe definiearje wy ferwachte gedrach? Troch in soarte fan belied te definiearjen, wat set regels. It projekt Open Policy Agent wurket oan it definiearjen fan dizze set regels oer in spektrum fariearjend fan tagong ta boarne tawizing.
Lykas wy seine, binne ús systemen hieltyd mear evenemint-oandreaune. Serverless is in geweldich foarbyld fan evenemint-oandreaune systemen. Om foar ús te oerdrage eveneminten tusken systemen en track se, wy moatte wat mienskiplike taal, wat mienskiplik protokol foar hoe't wy prate oer eveneminten, hoe't wy stjoere se oan elkoar. Dit is wat in projekt neamd .
De konstante stream fan feroaringen dy't oer ús systemen spoelt, dy't har konstant destabilisearje, is in trochgeande stream fan software-artefakten. Om dizze konstante stream fan feroaringen te behâlden, hawwe wy in soarte fan mienskiplik protokol nedich wêrmei't wy kinne prate oer wat in softwareartefakt is, hoe't it wurdt hifke, hokker ferifikaasje it is trochjûn. Dit is wat in projekt neamd . Dat is, in mienskiplik metadata protokol foar software artefakten.
En úteinlik, as wy wolle dat ús systemen folslein ûnôfhinklik, oanpasber en selsorganisearre binne, moatte wy har it rjocht jaan op selsidentifikaasje. Projekt neamd Dit is krekt wat hy docht. Dit is ek in projekt ûnder auspysjes fan de Cloud Native Computing Foundation.
Al dizze projekten binne jong, se hawwe allegear ús leafde nedich, ús validaasje. Dit is allegear iepen boarne, ús testen, ús ymplemintaasje. Se litte ús sjen wêr't technology op giet.
Mar DevOps hat nea primêr west oer technology, it hat altyd gong oer gearwurking tusken minsken. En dus, as wy wolle dat de systemen dy't wy ûntwikkelje feroarje, dan moatte wy sels feroarje. Yn feite, wy feroarje yn elts gefal; wy hawwe net folle fan in kar.
Der is in prachtich Britske skriuwster Rachel Botsman, wêryn't se skriuwt oer de evolúsje fan fertrouwen troch de minsklike skiednis. Se seit dat fertrouwen yn 't earstoan, yn primitive maatskippijen, lokaal wie, dat is, wy fertrouden allinich dyjingen dy't wy persoanlik kenne.
Doe wie der in hiel lange perioade - in tsjustere tiid doe't fertrouwen waard sintralisearre, doe't wy begûn te fertrouwen minsken dy't wy net kenne op grûn fan it feit dat wy hearre ta deselde iepenbiere of steat ynstelling.
En dit is wat wy sjogge yn ús moderne wrâld: fertrouwen wurdt hieltyd mear ferspraat en desintralisearre, en it is basearre op de frijheid fan ynformaasjestreamen, op de beskikberens fan ynformaasje.
As jo der oer neitinke, is dizze tagonklikheid, dy't dit fertrouwen mooglik makket, wat jo en ik útfiere. Dat betsjut dat sawol de manier wêrop wy gearwurkje as de manier wêrop wy it dogge moatte feroarje, om't de sintralisearre, hiërargyske IT-organisaasjes fan âlds net mear wurkje. Se begjinne te stjerren.
DevOps Organisaasje Fundamentals
De ideale DevOps-organisaasje fan 'e takomst is in desintralisearre, oanpasber systeem gearstald út autonome teams, elk besteande út autonome yndividuen. Dizze teams binne ferspraat oer de wrâld, wurkje effektyf mei elkoar gear mei asynchrone kommunikaasje, mei help fan heul transparante kommunikaasjeprotokollen. Hiel moai, is it net? In hiel moaie takomst.
Fansels is neat fan dit mooglik sûnder kulturele feroaring. Wy moatte transformaasjeliederskip hawwe, persoanlike ferantwurdlikens, ynterne motivaasje.
Dit is de basis fan DevOps-organisaasjes: ynformaasjetransparânsje, asynchrone kommunikaasje, transformaasjeliederskip, desintralisaasje.
Burnout
De systemen wêrfan wy diel útmeitsje en dejingen dy't wy bouwe binne hieltyd chaotysk, en it is lestich foar ús minsken om dizze gedachte om te gaan, it is lestich om de yllúzje fan kontrôle op te jaan. Wy besykje troch te gean om se te kontrolearjen, en dit liedt faak ta burn-out. Ik sis dit út myn eigen ûnderfining, ik rekke ek ferbaarnd, ik waard ek útskeakele troch ûnfoarsjoene mislearrings yn produksje.
Burnout komt foar as wy besykje eat te kontrolearjen dat ynherint net te kontrolearjen is. As wy útbaarne, ferliest alles syn betsjutting, om't wy de winsk ferlieze om wat nij te dwaan, wurde wy definsyf en begjinne te ferdigenjen wat wy hawwe.
It berop yngenieur, sa't ik mysels faaks graach herinnerje, is foarearst in kreatyf berop. As wy de winsk ferlieze om wat te meitsjen, dan wurde wy yn jiske, yn jiske. Minsken baarne út, hiele organisaasjes baarne út.
Yn myn miening, allinich it akseptearjen fan 'e kreative krêft fan' e gaos, allinich it bouwen fan gearwurking neffens har prinsipes is wat ús sil helpe om net te ferliezen wat goed is yn ús berop.
Dit is wat ik jo winskje: fan jo baan hâlde, fan wat wy dogge. Dizze wrâld feeds op ynformaasje, wy hawwe de eare om it te fieden. Dus litte wy chaos studearje, lit ús chaosologen wêze, lit ús wearde bringe, wat nij meitsje, goed, problemen, lykas wy al fûn hawwe, binne ûnûntkomber, en as se ferskine, sille wy gewoan sizze "Ops!", en it probleem is oplost .
Wat oars as Chaos Monkey?
Yn feite binne al dizze ynstruminten sa jong. Deselde Netflix boude ark foar harsels. Bou jo eigen ark. Lês de prinsipes fan chaos-technyk en libje nei dy prinsipes ynstee fan besykje oare ark te finen dy't in oar al hat boud.
Besykje te begripen hoe't jo systemen ôfbrekke en begjinne se ôf te brekken en sjoch hoe't se ophâlde. Dit komt earst. En jo kinne sykje nei ark. Der binne allerhanne projekten.
Ik net hielendal begripe it momint doe't jo seine dat it systeem kin net ferienfâldige troch ferienfâldigjen syn komponinten, en fuortendaliks ferhuze op microservices, dy't ferienfâldigje it systeem troch ferienfâldigjen fan de komponinten sels en komplisearjende ynteraksjes. Dit binne yn wêzen twa dielen dy't inoar tsjinsprekke.
Dat is krekt, mikrotsjinsten binne in heul kontroversjeel ûnderwerp yn 't algemien. Yn feite fergruttet it ferienfâldigjen fan dielen de fleksibiliteit. Wat leverje mikrotsjinsten? Se jouwe ús fleksibiliteit en snelheid, mar se jouwe ús perfoarst gjin ienfâld. Se fergrutsje de muoite.
Dat, yn 'e DevOps-filosofy binne mikrotsjinsten net sa'n goed ding?
Elk goed hat in efterkant. It foardiel is dat it fergruttet de fleksibiliteit, wêrtroch't wy feroaringen flugger kinne meitsje, mar it fergruttet de kompleksiteit en dêrom de fragiliteit fan it hiele systeem.
Dochs, wat is mear klam: op it ferienfâldigjen fan ynteraksje of op it ferienfâldigjen fan dielen?
De klam leit fansels op it ferienfâldigjen fan ynteraksjes, want as wy dit sjogge út it eachpunt fan hoe't wy mei jo wurkje, dan moatte wy foarearst omtinken jaan oan it ferienfâldigjen fan ynteraksjes, en net op it ferienfâldigjen fan it wurk fan elk fan ús apart. Want it ferienfâldigjen fan wurk betsjut om te feroarjen yn robots. Hjir by McDonald's wurket it gewoan as jo ynstruksjes hawwe: hjir sette jo de burger, hjir giet de saus derop. Dit wurket hielendal net yn ús kreatyf wurk.
Is it wier dat alles wat jo sein libbet yn in wrâld sûnder konkurrinsje, en de gaos dêr is sa soarte, en der binne gjin tsjinstellingen binnen dizze gaos, gjinien wol ite of deadzje immen? Hoe moatte konkurrinsje en DevOps gean?
No, it hinget ôf fan hokker soarte konkurrinsje wy it oer hawwe. Giet it oer konkurrinsje op it wurkplak of konkurrinsje tusken bedriuwen?
Oer de konkurrinsje fan tsjinsten dy't besteane om't tsjinsten net ferskate bedriuwen binne. Wy meitsje in nij soarte fan ynformaasjeomjouwing, en elke omjouwing kin net libje sûnder konkurrinsje. Der is oeral konkurrinsje.
Deselde Netflix, wy nimme se as in rolmodel. Wêrom kamen se mei dit? Want se moasten kompetitive wêze. Dizze fleksibiliteit en snelheid fan beweging is krekt de heul konkurrearjende eask; it yntroduseart chaos yn ús systemen. Dat is, chaos is net iets dat wy bewust dogge om't wy it wolle, it is iets dat bart om't de wrâld it freget. Wy moatte gewoan oanpasse. En gaos, it is krekt it resultaat fan konkurrinsje.
Betsjut dit dat gaos as it wie it ûntbrekken fan doelen is? Of dy doelen dy't wy net wolle sjen? Wy binne yn 'e hûs en begripe de doelen fan oaren net. Konkurrinsje komt yn feite troch it feit dat wy dúdlike doelen hawwe en wy witte wêr't wy op elk folgjende momint yn 'e tiid sille einigje. Dit, út myn eachpunt, is de essinsje fan DevOps.
Ek in blik op de fraach. Ik tink dat wy allegearre itselde doel hawwe: oerlibje en it mei dwaan
grutste wille. En it kompetitive doel fan elke organisaasje is itselde. Survival komt faak foar troch konkurrinsje, d'r is neat dat jo kinne dwaan.
Dit jier konferinsje sil plakfine op 7 desimber by Technopolis. Wy akseptearje oanfragen foar rapporten oant 11 novimber. ús as jo prate wolle.
Registraasje foar dielnimmers is iepen, kaartsjes kostje 7000 roebel. Kom by ûs!
Boarne: www.habr.com