Anton Weiss, fundador i director d'Otomato Software, un dels iniciadors i instructors de la primera certificació DevOps a Israel, va parlar a l'any passat. sobre la teoria del caos i els principis principals de l'enginyeria del caos, i també va explicar com funciona l'organització DevOps ideal del futur.
Hem preparat una versió de text de l'informe.
Bon dia!
DevOpsDays a Moscou per segon any consecutiu, aquesta és la meva segona vegada en aquest escenari, molts de vosaltres esteu a aquesta sala per segona vegada. Què vol dir? Això vol dir que el moviment DevOps a Rússia està creixent, es multiplica i, el més important, vol dir que ha arribat el moment de parlar de què és DevOps el 2018.
Mans amunt, qui creu que DevOps ja és una professió el 2018? Hi ha tals. Hi ha enginyers de DevOps a la sala la descripció de la feina diu "Enginyer de DevOps"? Hi ha cap gestor de DevOps a la sala? No hi ha tal. Arquitectes DevOps? També no. No és suficient. És veritat que ningú diu que sigui un enginyer de DevOps?
Així que la majoria de vosaltres penseu que això és un antipatró? Que tal professió no hauria d'existir? Podem pensar el que vulguem, però mentre estem pensant, la indústria avança solemnement al so de la trompeta DevOps.
Qui ha sentit parlar d'un tema nou anomenat DevDevOps? Aquesta és una nova tècnica que permet una col·laboració efectiva entre desenvolupadors i devops. I no tan nou. A jutjar per Twitter, ja en van començar a parlar fa 4 anys. I fins ara l'interès per això va creixent i creixent, és a dir, hi ha un problema. El problema s'ha de resoldre.
Som persones creatives, no només estem tranquils. Diem: DevOps no és una paraula prou completa; encara li falta tota mena d'elements diferents i interessants. I anem als nostres laboratoris secrets i comencem a produir mutacions interessants: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
La lògica és ferma, oi? El nostre sistema de lliurament no funciona, els nostres sistemes són inestables i els nostres usuaris estan insatisfets, no tenim temps per implementar programari a temps, no encaixem en el pressupost. Com resoldrem tot això? Sortirem amb una paraula nova! Acabarà amb "Ops" i el problema està resolt.
Així que anomeno aquest enfocament: "Ops, i el problema està resolt".
Tot això s'esvaeix en un segon pla si ens recordem per què ens va ocórrer tot això. Hem plantejat tot aquest tema de DevOps per fer que l'entrega de programari i el nostre propi treball en aquest procés siguin tan lliures, indolors, eficients i, sobretot, agradables.
DevOps va sorgir del dolor. I estem cansats de patir. I perquè tot això succeeixi, confiem en pràctiques perennes: col·laboració efectiva, pràctiques de flux i, el més important, pensament de sistemes, perquè sense això cap DevOps funciona.
Quin és el sistema?
I si ja estem parlant de pensament de sistemes, recordem-nos què és un sistema.
Si sou un pirata informàtic revolucionari, per a vosaltres el sistema és clarament dolent. És un núvol que s'acosta sobre tu i t'obliga a fer coses que no vols fer.
Des del punt de vista del pensament sistemàtic, un sistema és un tot que consta de parts. En aquest sentit, cadascun de nosaltres és un sistema. Les organitzacions en què treballem són sistemes. I el que tu i jo estem construint s'anomena sistema.
Tot això forma part d'un gran sistema sociotecnològic. I només si entenem com funciona conjuntament aquest sistema sociotecnològic, només així podrem optimitzar realment alguna cosa en aquesta matèria.
Des d'una perspectiva de pensament sistemàtic, un sistema té diverses propietats interessants. En primer lloc, consta de peces, el que significa que el seu comportament depèn del comportament de les peces. A més, totes les seves parts també són interdependents. Resulta que com més parts té un sistema, més difícil és entendre o predir el seu comportament.
Des del punt de vista del comportament, hi ha un altre fet interessant. El sistema pot fer alguna cosa que cap de les seves parts individuals pot fer.
Com va dir el doctor Russell Ackoff (un dels fundadors del pensament de sistemes), això és bastant fàcil de demostrar amb un experiment mental. Per exemple, qui a la sala sap escriure codi? Hi ha moltes mans, i això és normal, perquè aquest és un dels principals requisits de la nostra professió. Saps escriure, però les teves mans poden escriure codi per separat de tu? Hi ha gent que dirà: "No són les meves mans les que escriuen el codi, és el meu cervell qui escriu el codi". El teu cervell pot escriure codi per separat de tu? Bé, probablement no.
El cervell és una màquina increïble, ni tan sols sabem el 10% de com funciona allà, però no pot funcionar per separat del sistema que és el nostre cos. I això és fàcil de demostrar: obre el teu crani, treu el teu cervell, posa-lo davant de l'ordinador, deixa'l provar d'escriure alguna cosa senzilla. "Hola, món" a Python, per exemple.
Si un sistema pot fer alguna cosa que cap de les seves parts pot fer per separat, això vol dir que el seu comportament no està determinat pel comportament de les seves parts. Aleshores, per què està determinat? Està determinat per la interacció entre aquestes parts. I, en conseqüència, com més parts, més complexes són les interaccions, més difícil és entendre i predir el comportament del sistema. I això fa que aquest sistema sigui caòtic, perquè qualsevol canvi invisible, fins i tot el més insignificant, en qualsevol part del sistema pot donar lloc a resultats completament impredictibles.
Aquesta sensibilitat a les condicions inicials va ser descoberta i estudiada per primera vegada pel meteoròleg nord-americà Ed Lorenz. Posteriorment, es va anomenar "efecte papallona" i va donar lloc al desenvolupament d'un moviment de pensament científic anomenat "teoria del caos". Aquesta teoria es va convertir en un dels principals canvis de paradigma de la ciència del segle XX.
Teoria del caos
Les persones que estudien el caos es diuen caosòlegs.
De fet, el motiu d'aquest informe va ser que, treballant amb sistemes distribuïts complexos i grans organitzacions internacionals, en algun moment em vaig adonar que aquest és el que em sembla. Sóc un caosòleg. Aquesta és bàsicament una manera intel·ligent de dir: "No entenc què està passant aquí i no sé què fer-hi".
Crec que molts de vosaltres també us sentiu així sovint, així que també sou uns caosòlegs. Et convido al gremi de caosòlegs. Els sistemes que tu i jo, estimats companys caosòlegs, estudiarem s'anomenen "sistemes adaptatius complexos".
Què és l'adaptabilitat? L'adaptabilitat significa que el comportament individual i col·lectiu de les parts d'un sistema adaptatiu canvia i s'autoorganitza, responent a esdeveniments o cadenes de microesdeveniments del sistema. És a dir, el sistema s'adapta als canvis mitjançant l'autoorganització. I aquesta capacitat d'autoorganització es basa en la cooperació voluntària i totalment descentralitzada d'agents autònoms lliures.
Una altra propietat interessant d'aquests sistemes és que són escalables lliurement. El que sens dubte ens hauria d'interessar, com a caosòlegs-enginyers. Per tant, si diguéssim que el comportament d'un sistema complex està determinat per la interacció de les seves parts, en què ens hauria d'interessar? Interacció.
Hi ha dues troballes més interessants.
En primer lloc, entenem que un sistema complex no es pot simplificar simplificant les seves parts. En segon lloc, l'única manera de simplificar un sistema complex és simplificant les interaccions entre les seves parts.
Com interactuem? Tu i jo som part d'un gran sistema d'informació anomenat societat humana. Interactuem a través d'un llenguatge comú, si el tenim, si el trobem.
Però el llenguatge en si és un sistema adaptatiu complex. En conseqüència, per poder interactuar de manera més eficient i senzilla, hem de crear algun tipus de protocols. És a dir, alguna seqüència de símbols i accions que farà que l'intercanvi d'informació entre nosaltres sigui més senzill, més previsible, més entenedor.
Vull dir que les tendències cap a la complexitat, cap a l'adaptabilitat, cap a la descentralització, cap al caos es poden rastrejar en tot. I en els sistemes que tu i jo estem construint, i en aquells sistemes dels quals formem part.
I per no ser infundat, mirem com estan canviant els sistemes que creem.
Estaves esperant aquesta paraula, ho entenc. Estem en una conferència de DevOps, avui aquesta paraula s'escoltarà unes cent mil vegades i després la somiarem a la nit.
Els microserveis són la primera arquitectura de programari que va sorgir com a reacció a les pràctiques de DevOps, que està dissenyada per fer que els nostres sistemes siguin més flexibles, més escalables i garantir un lliurament continu. Com ho fa ella? Reduint el volum de serveis, reduint l'abast dels problemes que processen aquests serveis, reduint el temps de lliurament. És a dir, reduïm i simplifiquem parts del sistema, n'augmentem el nombre i, en conseqüència, la complexitat de les interaccions entre aquestes parts augmenta invariablement, és a dir, sorgeixen nous problemes que hem de resoldre.
Els microserveis no són el final, els microserveis ho són, en general, ja ahir, perquè ve Serverless. Tots els servidors cremats, ni servidors, ni sistemes operatius, només codi executable pur. Les configuracions estan separades, els estats estan separats, tot està controlat per esdeveniments. Bellesa, neteja, silenci, sense esdeveniments, no passa res, ordre complet.
On és la complexitat? La dificultat, és clar, està en les interaccions. Quant pot fer una funció per si sola? Com interactua amb altres funcions? Cues de missatges, bases de dades, equilibradors. Com recrear algun esdeveniment quan es va produir un error? Moltes preguntes i poques respostes.
Els microserveis i els sense servidor són el que els hipsters frikis anomenem Cloud Native. Tot es tracta del núvol. Però el núvol també està inherentment limitat en la seva escalabilitat. Estem acostumats a pensar-ho com un sistema distribuït. De fet, on viuen els servidors dels proveïdors de núvol? En centres de dades. És a dir, aquí tenim una mena de model centralitzat, molt limitat i distribuït.
Avui entenem que Internet de les coses ja no són només grans paraules que, fins i tot segons modestes prediccions, milers de milions de dispositius connectats a Internet ens esperen en els propers cinc o deu anys. Una gran quantitat de dades útils i inútils que es fusionaran al núvol i es carregaran des del núvol.
El núvol no durarà, així que cada cop parlem més d'una cosa que s'anomena edge computing. O també m'agrada la meravellosa definició de "computació de boira". Està embolicat en el misticisme del romanticisme i el misteri.
Informàtica de boira. La qüestió és que els núvols són grups centralitzats d'aigua, vapor, gel i pedres. I la boira són gotes d'aigua que s'escampen al nostre voltant per l'atmosfera.
En el paradigma de la boira, la major part del treball el fan aquestes gotes de forma totalment autònoma o en col·laboració amb altres gotes. I es dirigeixen al núvol només quan realment estan molt pressionats.
És a dir, de nou la descentralització, l'autonomia i, per descomptat, molts de vosaltres ja enteneu cap a on va tot això, perquè no es pot parlar de descentralització sense esmentar el blockchain.
Hi ha qui creu, aquests són els que han invertit en criptomoneda. Hi ha qui creu però té por, com jo, per exemple. I hi ha qui no creu. Aquí pots tractar de manera diferent. Hi ha tecnologia, una nova qüestió desconeguda, hi ha problemes. Com qualsevol tecnologia nova, planteja més preguntes que no pas respon.
El bombo al voltant de blockchain és comprensible. A banda de la febre de l'or, la tecnologia en si té promeses notables per a un futur més brillant: més llibertat, més autonomia, confiança global distribuïda. Què és no voler?
En conseqüència, cada cop més enginyers d'arreu del món estan començant a desenvolupar aplicacions descentralitzades. I aquest és un poder que no es pot descartar simplement dient: "Ahh, blockchain és només una base de dades distribuïda mal implementada". O com diuen els escèptics: "No hi ha aplicacions reals per a blockchain". Si ho penseu, fa 150 anys deien el mateix de l'electricitat. I fins i tot tenien raó d'alguna manera, perquè el que l'electricitat fa possible avui no era de cap manera possible al segle XIX.
Per cert, qui sap quin tipus de logotip hi ha a la pantalla? Això és Hyperledger. Es tracta d'un projecte que s'està desenvolupant sota els auspicis de The Linux Foundation i que inclou un conjunt de tecnologies blockchain. Aquesta és realment la força de la nostra comunitat de codi obert.
Enginyeria del Caos
Així doncs, el sistema que estem desenvolupant és cada cop més complex, cada cop més caòtic i cada cop més adaptatiu. Netflix són pioners dels sistemes de microserveis. Van ser dels primers a entendre-ho, van desenvolupar un conjunt d'eines que van anomenar Exèrcit simià, la més famosa de les quals va ser . Va definir el que es coneixia com .
Per cert, en el procés de treball de l'informe, fins i tot hem traduït aquest text al rus, així que aneu a , llegir, comentar, renyar.
Breument, els principis de l'enginyeria del caos diuen el següent. Els sistemes distribuïts complexos són inherentment impredictibles i intrínsecament buggy. Els errors són inevitables, la qual cosa significa que hem d'acceptar aquests errors i treballar amb aquests sistemes d'una manera completament diferent.
Nosaltres mateixos hem d'intentar introduir aquests errors als nostres sistemes de producció per tal de provar els nostres sistemes per a aquesta mateixa adaptabilitat, aquesta mateixa capacitat d'autoorganització, de supervivència.
I això ho canvia tot. No només com posem sistemes en producció, sinó també com els desenvolupem, com els provem. No hi ha procés d'estabilització o congelació del codi, al contrari, hi ha un procés constant de desestabilització. Estem intentant matar el sistema i veure que segueixi sobrevivint.
Protocols d'integració de sistemes distribuïts
En conseqüència, això requereix que els nostres sistemes canviïn d'alguna manera. Per tal que siguin més estables, necessiten uns nous protocols d'interacció entre les seves parts. Perquè aquestes parts es puguin posar d'acord i arribar a algun tipus d'autoorganització. I sorgeixen tota mena de noves eines, nous protocols, que anomeno "protocols per a la interacció de sistemes distribuïts".
De què parlo? Primer, el projecte . Alguns intenten crear un protocol de seguiment distribuït general, que és una eina absolutament indispensable per depurar sistemes distribuïts complexos.
Més lluny - . Diem que no podem predir què passarà amb el sistema, és a dir, hem d'augmentar la seva observabilitat, observabilitat. Opentracing pertany a una família d'eines que donen observabilitat als nostres sistemes. Però necessitem observabilitat per determinar si el sistema es comporta com esperem o no. Com definim el comportament esperat? En definir algun tipus de política, un conjunt de regles. El projecte Open Policy Agent està treballant per definir aquest conjunt de regles en un espectre que va des de l'accés a l'assignació de recursos.
Com dèiem, els nostres sistemes estan cada cop més basats en esdeveniments. Sense servidor és un gran exemple de sistemes basats en esdeveniments. Perquè puguem transferir esdeveniments entre sistemes i fer-ne un seguiment, necessitem un llenguatge comú, un protocol comú sobre com parlem dels esdeveniments, com els transmetem els uns als altres. Així es deia un projecte .
El flux constant de canvis que arrossega els nostres sistemes, desestabilitzant-los constantment, és un flux continu d'artefactes de programari. Per tal de mantenir aquest flux constant de canvis, necessitem algun tipus de protocol comú a través del qual puguem parlar de què és un artefacte de programari, com es prova, quina verificació ha passat. Així es deia un projecte . És a dir, un protocol de metadades comú per a artefactes de programari.
I, finalment, si volem que els nostres sistemes siguin completament independents, adaptatius i autoorganitzats, els hem de donar dret a l'autoidentificació. Projecte anomenat Això és exactament el que fa. Aquest també és un projecte sota els auspicis de la Cloud Native Computing Foundation.
Tots aquests projectes són joves, tots necessiten el nostre amor, la nostra validació. Tot això és de codi obert, les nostres proves, la nostra implementació. Ens mostren cap a on va la tecnologia.
Però DevOps mai s'ha tractat principalment de tecnologia, sempre ha estat de col·laboració entre persones. I, en conseqüència, si volem que els sistemes que desenvolupem canviïn, hem de canviar nosaltres mateixos. De fet, estem canviant de totes maneres; no tenim gaire opció.
Hi ha un meravellós L'escriptora britànica Rachel Botsman, en la qual escriu sobre l'evolució de la confiança al llarg de la història de la humanitat. Diu que inicialment, a les societats primitives, la confiança era local, és a dir, només confiàvem en aquells que coneixíem personalment.
Després va haver-hi un període molt llarg, un temps fosc en què la confiança es va centralitzar, quan vam començar a confiar en persones que no coneixem pel fet que pertanyem a la mateixa institució pública o estatal.
I això és el que veiem en el nostre món modern: la confiança està cada cop més distribuïda i descentralitzada, i es basa en la llibertat de fluxos d'informació, en la disponibilitat d'informació.
Si hi penses bé, aquesta mateixa accessibilitat, que fa possible aquesta confiança, és el que estem implementant tu i jo. Això vol dir que tant la nostra manera de col·laborar com la manera de fer-ho han de canviar, perquè les organitzacions de TI centralitzades i jeràrquiques d'abans ja no funcionen. Comencen a morir.
Fonaments de l'organització DevOps
L'organització DevOps ideal del futur és un sistema descentralitzat i adaptatiu format per equips autònoms, cadascun format per individus autònoms. Aquests equips estan dispersos per tot el món, col·laborant eficaçment entre ells mitjançant la comunicació asíncrona, utilitzant protocols de comunicació altament transparents. Molt bonic, no? Un futur molt bonic.
Per descomptat, res d'això és possible sense un canvi cultural. Hem de tenir lideratge transformador, responsabilitat personal, motivació interna.
Aquesta és la base de les organitzacions DevOps: transparència de la informació, comunicacions asíncrones, lideratge transformacional, descentralització.
Burnout
Els sistemes dels que formem part i els que construïm són cada cop més caòtics, i als humans ens costa fer front a aquest pensament, és difícil renunciar a la il·lusió de control. Intentem seguir controlant-los, i això sovint porta a l'esgotament. Ho dic des de la meva pròpia experiència, també em vaig cremar, també vaig quedar inhabilitat per fallades imprevistes en la producció.
El burnout es produeix quan intentem controlar alguna cosa que és inherentment incontrolable. Quan ens esgotem, tot perd el seu sentit perquè perdem les ganes de fer alguna cosa nova, ens posem a la defensiva i comencem a defensar el que tenim.
La professió d'enginyer, com sovint m'agrada recordar-me, és abans que res una professió creativa. Si perdem el desig de crear alguna cosa, ens convertim en cendra, en cendra. La gent s'esgota, organitzacions senceres s'esgoten.
Al meu entendre, només acceptar el poder creatiu del caos, només construir la cooperació segons els seus principis és el que ens ajudarà a no perdre el que és bo a la nostra professió.
Això és el que et desitjo: estimar la teva feina, estimar el que fem. Aquest món s'alimenta d'informació, tenim l'honor d'alimentar-la. Així doncs, estudiem el caos, siguem caosòlegs, aportem valor, creem quelcom nou, bé, els problemes, com ja hem descobert, són inevitables, i quan apareguin, simplement direm “Ops!”, i el problema està resolt. .
Què més que Chaos Monkey?
De fet, tots aquests instruments són tan joves. Els mateixos Netflix van crear eines per si mateixos. Construeix les teves pròpies eines. Llegiu els principis de l'enginyeria del caos i compliu aquests principis en lloc d'intentar trobar altres eines que algú altre ja hagi construït.
Proveu d'entendre com es descomponen els vostres sistemes i comenceu a trencar-los i vegeu com aguanten. Això és el primer. I pots buscar eines. Hi ha tota mena de projectes.
No he acabat d'entendre el moment en què vas dir que el sistema no es pot simplificar simplificant els seus components, i de seguida vaig passar als microserveis, que simplifiquen el sistema simplificant els mateixos components i complicant les interaccions. Es tracta bàsicament de dues parts que es contradiuen.
És cert, els microserveis són un tema molt controvertit en general. De fet, la simplificació de peces augmenta la flexibilitat. Què ofereixen els microserveis? Ens donen flexibilitat i rapidesa, però certament no ens donen senzillesa. Augmenten la dificultat.
Per tant, segons la filosofia DevOps, els microserveis no són tan bo?
Qualsevol bé té un revers. El benefici és que augmenta la flexibilitat, permetent-nos fer canvis més ràpidament, però augmenta la complexitat i, per tant, la fragilitat de tot el sistema.
Tot i així, què hi ha més èmfasi: en la simplificació de la interacció o en la simplificació de parts?
L'èmfasi, per descomptat, està en la simplificació de les interaccions, perquè si mirem això des del punt de vista de com treballem amb tu, llavors, primer de tot, hem de parar atenció a la simplificació de les interaccions, i no a la simplificació del treball. de cadascú de nosaltres per separat. Perquè simplificar la feina vol dir convertir-se en robots. Aquí a McDonald's funciona amb normalitat quan tens instruccions: aquí poses l'hamburguesa, aquí hi aboques la salsa. Això no funciona gens en el nostre treball creatiu.
És cert que tot el que has dit viu en un món sense competència, i el caos que hi ha és tan amable, i no hi ha contradiccions dins d'aquest caos, ningú vol menjar ni matar ningú? Com hauria de ser la competència i DevOps?
Bé, depèn de quin tipus de competició estem parlant. Es tracta de competència en el lloc de treball o competència entre empreses?
Sobre la competència de serveis que hi ha perquè els serveis no són diverses empreses. Estem creant un nou tipus d'entorn d'informació, i qualsevol entorn no pot viure sense competència. Hi ha competència a tot arreu.
El mateix Netflix, els prenem com a model a seguir. Per què se'ls va ocórrer això? Perquè havien de ser competitius. Aquesta flexibilitat i velocitat de moviment és precisament el requisit molt competitiu; introdueix el caos als nostres sistemes. És a dir, el caos no és una cosa que fem conscientment perquè ho volem, és una cosa que passa perquè el món ho exigeix. Només ens hem d'adaptar. I el caos, és precisament fruit de la competència.
Això vol dir que el caos és l'absència d'objectius, per dir-ho? O aquells objectius que no volem veure? Estem a casa i no entenem els objectius dels altres. La competència, de fet, es deu al fet que tenim els objectius clars i sabem on anirem a parar en cada moment. Aquesta, des del meu punt de vista, és l'essència de DevOps.
També un cop d'ull a la pregunta. Crec que tots tenim el mateix objectiu: sobreviure i fer-ho
el major plaer. I l'objectiu competitiu de qualsevol organització és el mateix. La supervivència sovint es produeix mitjançant la competició, no hi pots fer res.
La conferència d'enguany tindrà lloc el 7 de desembre a Technopolis. Acceptem sol·licituds d'informes fins l'11 de novembre. nosaltres si vols parlar.
La inscripció per als participants està oberta, les entrades costen 7000 rubles. Uneix-te a nosaltres!
Font: www.habr.com