Anton Weiss, fundador e director de Otomato Software, un dos iniciadores e instrutores da primeira certificación DevOps en Israel, falou no ano pasado. sobre a teoría do caos e os principais principios da enxeñaría do caos, e tamén explicou como funciona a organización ideal de DevOps do futuro.
Elaboramos unha versión de texto do informe.
Bos días
DevOpsDays en Moscova por segundo ano consecutivo, esta é a miña segunda vez neste escenario, moitos de vós estades nesta sala por segunda vez. Qué significa? Isto significa que o movemento DevOps en Rusia está crecendo, multiplicándose e, o máis importante, significa que chegou o momento de falar sobre o que é DevOps en 2018.
Quen pensa que DevOps xa é unha profesión en 2018? Hai tales. Hai algún enxeñeiro de DevOps na sala cuxa descrición do traballo diga "Enxeñeiro de DevOps"? Hai algún xestor de DevOps na sala? Non hai tal. Arquitectos DevOps? Tamén non. Non suficiente. É verdade que ninguén di que sexa un enxeñeiro de DevOps?
Entón, a maioría de vós pensades que isto é un antipatrón? Que tal profesión non debería existir? Podemos pensar o que queiramos, pero mentres pensamos, a industria avanza solemnemente ao son da trompeta DevOps.
Quen escoitou falar dun novo tema chamado DevDevOps? Esta é unha nova técnica que permite unha colaboración eficaz entre desenvolvedores e devops. E non tan novo. A xulgar por Twitter, xa comezaron a falar disto hai 4 anos. E ata agora, o interese por isto vai medrando e medrando, é dicir, hai un problema. Hai que resolver o problema.
Somos persoas creativas, non só estamos tranquilos. Dicimos: DevOps non é unha palabra suficientemente completa; aínda carece de todo tipo de elementos diferentes e interesantes. E imos aos nosos laboratorios secretos e comezamos a producir mutacións interesantes: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
A lóxica é férrea, non? O noso sistema de entrega non funciona, os nosos sistemas son inestables e os nosos usuarios están insatisfeitos, non temos tempo para lanzar o software a tempo, non nos adaptamos ao orzamento. Como imos resolver todo isto? Imos dar unha nova palabra! Rematará con "Ops" e o problema está resolto.
Entón, chamo a este enfoque: "Ops, e o problema está resolto".
Todo isto pasa a un segundo plano se nos lembramos por que nos ocorreu todo isto. Ocorréusenos todo isto de DevOps para facer que a entrega de software e o noso propio traballo neste proceso sexa o máis sinxelo, indoloro, eficiente e, o máis importante, o máis agradable posible.
DevOps creceu da dor. E estamos fartos de sufrir. E para que todo isto suceda, confiamos en prácticas perennes: colaboración efectiva, prácticas de fluxo e, o máis importante, pensamento de sistemas, porque sen el non funciona ningún DevOps.
Cal é o sistema?
E se xa estamos a falar de pensamento sistémico, lembremos o que é un sistema.
Se es un hacker revolucionario, entón para ti o sistema é claramente malvado. É unha nube que pende sobre ti e que che obriga a facer cousas que non queres facer.
Desde o punto de vista do pensamento sistémico, un sistema é un todo que consta de partes. Neste sentido, cada un de nós é un sistema. As organizacións nas que traballamos son sistemas. E o que ti e eu estamos construíndo chámase sistema.
Todo isto forma parte dun gran sistema socio-tecnolóxico. E só se entendemos como funciona este sistema sociotecnolóxico en conxunto, só así poderemos optimizar realmente algo neste asunto.
Desde a perspectiva do pensamento sistémico, un sistema ten varias propiedades interesantes. En primeiro lugar, consta de partes, o que significa que o seu comportamento depende do comportamento das pezas. Ademais, todas as súas partes tamén son interdependentes. Resulta que cantas máis partes ten un sistema, máis difícil é comprender ou predicir o seu comportamento.
Dende o punto de vista do comportamento, hai outro dato interesante. O sistema pode facer algo que ningunha das súas partes individuais pode facer.
Como dixo o doutor Russell Ackoff (un dos fundadores do pensamento sistémico), isto é bastante fácil de demostrar cun experimento mental. Por exemplo, quen na sala sabe escribir código? Hai moitas mans, e iso é normal, porque este é un dos principais requisitos para a nosa profesión. Sabes escribir, pero as túas mans poden escribir código por separado de ti? Hai xente que dirá: "Non son as miñas mans as que escriben o código, é o meu cerebro quen escribe o código". Pode o teu cerebro escribir código por separado de ti? Ben, probablemente non.
O cerebro é unha máquina incrible, nin sequera sabemos o 10% de como funciona alí, pero non pode funcionar por separado do sistema que é o noso corpo. E isto é doado de demostrar: ábrete a caveira, sácalle o cerebro, pono diante do ordenador, déixao que intente escribir algo sinxelo. "Ola, mundo" en Python, por exemplo.
Se un sistema pode facer algo que ningunha das súas partes pode facer por separado, isto significa que o seu comportamento non está determinado polo comportamento das súas partes. Por que se determina entón? Está determinado pola interacción entre estas partes. E, en consecuencia, cantas máis partes, máis complexas son as interaccións, máis difícil é comprender e predicir o comportamento do sistema. E isto fai que un sistema deste tipo sexa caótico, porque calquera cambio invisible, incluso o máis insignificante, en calquera parte do sistema pode levar a resultados completamente imprevisibles.
Esta sensibilidade ás condicións iniciais foi descuberta e estudada por primeira vez polo meteorólogo estadounidense Ed Lorenz. Posteriormente, chamouse "efecto bolboreta" e levou ao desenvolvemento dun movemento de pensamento científico chamado "teoría do caos". Esta teoría converteuse nun dos principais cambios de paradigma na ciencia do século XX.
Teoría do caos
As persoas que estudan o caos chámanse caosólogos.
En realidade, o motivo deste informe foi que, traballando con complexos sistemas distribuídos e grandes organizacións internacionais, nalgún momento deime conta de que é o que me apetece. Son un caosólogo. Esta é basicamente unha forma intelixente de dicir: "Non entendo o que está a pasar aquí e non sei que facer ao respecto".
Creo que moitos de vós tamén adoitades sentir isto, polo que tamén sodes caosólogos. Convídote ao gremio dos caosólogos. Os sistemas que vostede e eu, queridos colegas caosólogos, estudaremos denomínanse "sistemas adaptativos complexos".
Que é a adaptabilidade? A adaptabilidade significa que o comportamento individual e colectivo das partes dun sistema tan adaptativo cambia e autoorganizase, respondendo a eventos ou cadeas de microeventos do sistema. É dicir, o sistema adáptase aos cambios mediante a autoorganización. E esta capacidade de autoorganización baséase na cooperación voluntaria e totalmente descentralizada dos axentes autónomos libres.
Outra propiedade interesante deste tipo de sistemas é que son libremente escalables. O que sen dúbida debería interesarnos, como caosólogos-enxeñeiros. Entón, se dixemos que o comportamento dun sistema complexo está determinado pola interacción das súas partes, entón en que nos debería interesar? Interacción.
Hai dous achados máis interesantes.
En primeiro lugar, entendemos que un sistema complexo non se pode simplificar simplificando as súas partes. En segundo lugar, a única forma de simplificar un sistema complexo é simplificando as interaccións entre as súas partes.
Como interactuamos? Ti e máis eu formamos parte dun gran sistema de información chamado sociedade humana. Interactuamos a través dunha linguaxe común, se a temos, se a atopamos.
Pero a propia linguaxe é un sistema adaptativo complexo. En consecuencia, para interactuar de forma máis eficiente e sinxela, necesitamos crear algún tipo de protocolos. É dicir, algunha secuencia de símbolos e accións que farán que o intercambio de información entre nós sexa máis sinxelo, máis previsible, máis comprensible.
Quero dicir que as tendencias á complexidade, á adaptabilidade, á descentralización, ao caos pódense rastrexar en todo. E nos sistemas que vostede e eu estamos construíndo, e naqueles sistemas dos que formamos parte.
E para non ser infundado, vexamos como están cambiando os sistemas que creamos.
Estabas esperando esta palabra, entendo. Estamos nunha conferencia de DevOps, hoxe esta palabra escoitarase unhas cen mil veces e logo soñarémola pola noite.
Os microservizos son a primeira arquitectura de software que xurdiu como reacción ás prácticas de DevOps, que está deseñada para facer os nosos sistemas máis flexibles, escalables e garantir a entrega continua. Como fai isto? Ao reducir o volume de servizos, reducindo o alcance dos problemas que procesan estes servizos, reducindo o tempo de entrega. É dicir, reducimos e simplificamos partes do sistema, aumentamos o seu número e, en consecuencia, a complexidade das interaccións entre estas partes aumenta invariablemente, é dicir, xorden novos problemas que temos que resolver.
Os microservizos non son o final, os microservizos son, en xeral, xa onte, porque está chegando Serverless. Todos os servidores queimados, sen servidores, sen sistemas operativos, só código executable puro. As configuracións están separadas, os estados están separados, todo está controlado por eventos. Beleza, limpeza, silencio, sen acontecementos, non pasa nada, orde completa.
Onde está a complexidade? A dificultade, por suposto, está nas interaccións. Canto pode facer unha función por si mesma? Como interactúa con outras funcións? Colas de mensaxes, bases de datos, equilibradores. Como recrear algún evento cando se produciu un fallo? Moitas preguntas e poucas respostas.
Os microservizos e os sen servidor son o que os hipsters frikis chamamos Cloud Native. Todo é sobre a nube. Pero a nube tamén está inherentemente limitada na súa escalabilidade. Estamos afeitos a pensalo como un sistema distribuído. De feito, onde viven os servidores dos provedores de nube? En centros de datos. É dicir, temos aquí unha especie de modelo centralizado, moi limitado e distribuído.
Hoxe entendemos que a Internet das Cousas xa non son só grandes palabras que, mesmo segundo prediccións modestas, miles de millóns de dispositivos conectados a Internet agardan por nós nos próximos cinco ou dez anos. Unha enorme cantidade de datos útiles e inútiles que se fusionarán na nube e cargaranse desde a nube.
A nube non durará, polo que falamos cada vez máis de algo chamado edge computing. Ou tamén me gusta a marabillosa definición de "fog computing". Está envolto no misticismo do romanticismo e do misterio.
Informática de néboa. A cuestión é que as nubes son masas centralizadas de auga, vapor, xeo e pedras. E a néboa son pingas de auga que se espallan ao noso redor pola atmosfera.
No paradigma da néboa, a maior parte do traballo realízano estas gotiñas de forma totalmente autónoma ou en colaboración con outras gotas. E recorren á nube só cando están realmente presionados.
É dicir, de novo a descentralización, a autonomía e, por suposto, moitos xa entendedes cara a onde vai todo isto, porque non se pode falar de descentralización sen mencionar o blockchain.
Hai quen cre, estes son os que investiron en criptomoeda. Hai quen cre pero ten medo, coma min, por exemplo. E hai quen non cre. Aquí podes tratar de xeito diferente. Hai tecnoloxía, un novo asunto descoñecido, hai problemas. Como calquera nova tecnoloxía, suscita máis preguntas das que responde.
O bombo ao redor da cadea de bloques é comprensible. Ademais da febre do ouro, a tecnoloxía en si ten promesas notables para un futuro máis brillante: máis liberdade, máis autonomía, confianza global distribuída. Que non é querer?
En consecuencia, cada vez máis enxeñeiros de todo o mundo comezan a desenvolver aplicacións descentralizadas. E este é un poder que non se pode descartar simplemente dicindo: "Ahh, blockchain é só unha base de datos distribuída mal implementada". Ou como lles gusta dicir aos escépticos: "Non hai aplicacións reais para blockchain". Se o pensas ben, hai 150 anos dicían o mesmo da electricidade. E mesmo tiñan razón nalgúns aspectos, porque o que hoxe fai posible a electricidade non era de ningún xeito posible no século XIX.
Por certo, quen sabe que tipo de logotipo hai na pantalla? Este é Hyperledger. Este é un proxecto que se está a desenvolver baixo os auspicios da Fundación Linux e que inclúe un conxunto de tecnoloxías blockchain. Esta é verdadeiramente a forza da nosa comunidade de código aberto.
Enxeñaría do Caos
Así, o sistema que estamos a desenvolver é cada vez máis complexo, cada vez máis caótico e cada vez máis adaptativo. Netflix é pioneiro dos sistemas de microservizos. Foron dos primeiros en entender isto, desenvolveron un conxunto de ferramentas que chamaron Exército Simio, a máis famosa das cales foi . Definiu o que se coñeceu como .
Por certo, no proceso de traballo no informe, ata traducimos este texto ao ruso, así que vai a , ler, comentar, regañar.
Brevemente, os principios da enxeñaría do caos din o seguinte. Os sistemas distribuídos complexos son inherentemente imprevisibles e intrínsecamente con erros. Os erros son inevitables, o que significa que debemos aceptar estes erros e traballar con estes sistemas dun xeito completamente diferente.
Nós mesmos debemos tentar introducir estes erros nos nosos sistemas de produción para probar os nosos sistemas para esa mesma adaptabilidade, esta mesma capacidade de autoorganización, de supervivencia.
E iso cambia todo. Non só como lanzamos sistemas á produción, senón tamén como os desenvolvemos e como os probamos. Non hai un proceso de estabilización ou conxelación do código, pola contra, hai un proceso constante de desestabilización. Estamos tentando matar o sistema e ver que segue sobrevivindo.
Protocolos de integración de sistemas distribuídos
En consecuencia, isto require que os nosos sistemas cambien dalgún xeito. Para que sexan máis estables, necesitan algúns novos protocolos de interacción entre as súas partes. Para que estas partes poidan poñerse de acordo e chegar a algún tipo de autoorganización. E xorden todo tipo de novas ferramentas, novos protocolos, que eu chamo "protocolos para a interacción de sistemas distribuídos".
De que falo? Primeiro, o proxecto . Algúns intentan crear un protocolo xeral de seguimento distribuído, que é unha ferramenta absolutamente indispensable para depurar sistemas distribuídos complexos.
Ademais - . Dicimos que non podemos predicir o que vai pasar co sistema, é dicir, necesitamos aumentar a súa observabilidade, a observabilidade. Opentracing pertence a unha familia de ferramentas que dan observabilidade aos nosos sistemas. Pero necesitamos observabilidade para determinar se o sistema se comporta como esperamos ou non. Como definimos o comportamento esperado? Ao definir algún tipo de política, algún conxunto de regras. O proxecto Open Policy Agent traballa para definir este conxunto de regras nun espectro que vai desde o acceso ata a asignación de recursos.
Como dixemos, os nosos sistemas están cada vez máis dirixidos por eventos. Serverless é un gran exemplo de sistemas impulsados por eventos. Para que poidamos transferir eventos entre sistemas e rastrexalos, necesitamos algunha linguaxe común, algún protocolo común sobre como falamos dos eventos, como os transmitimos entre si. Así se chamaba un proxecto .
O fluxo constante de cambios que invade os nosos sistemas, desestabilizalos constantemente, é un fluxo continuo de artefactos de software. Para poder manter este fluxo constante de cambios, necesitamos algún tipo de protocolo común a través do cal poidamos falar de que é un artefacto de software, como se proba, que verificación pasou. Así se chamaba un proxecto . É dicir, un protocolo de metadatos común para artefactos de software.
E, finalmente, se queremos que os nosos sistemas sexan completamente independentes, adaptables e autoorganizados, debemos darlles o dereito á autoidentificación. Proxecto chamado Isto é exactamente o que fai. Este é tamén un proxecto baixo os auspicios da Cloud Native Computing Foundation.
Todos estes proxectos son novos, todos precisan do noso amor, da nosa validación. Todo isto é de código aberto, as nosas probas, a nosa implementación. Amósanos cara a onde vai a tecnoloxía.
Pero DevOps nunca foi principalmente sobre tecnoloxía, sempre se tratou de colaboración entre persoas. E, en consecuencia, se queremos que os sistemas que desenvolvemos cambien, entón nós mesmos debemos cambiar. De feito, estamos cambiando de todos os xeitos; non temos moito remedio.
Hai unha marabillosa A escritora británica Rachel Botsman, na que escribe sobre a evolución da confianza ao longo da historia da humanidade. Ela di que inicialmente, nas sociedades primitivas, a confianza era local, é dicir, confiabamos só nos que coñecíamos persoalmente.
Despois houbo un período moi longo, un tempo escuro no que se centralizou a confianza, cando comezamos a confiar en persoas que non coñecemos polo feito de pertencer á mesma institución pública ou estatal.
E isto é o que vemos no noso mundo moderno: a confianza está cada vez máis distribuída e descentralizada, e baséase na liberdade de fluxos de información, na dispoñibilidade de información.
Se o pensas ben, esta mesma accesibilidade, que fai posible esta confianza, é o que ti e eu estamos implementando. Isto significa que tanto o xeito de colaborar como o de facelo deben cambiar, porque as organizacións informáticas centralizadas e xerarquizadas de sempre xa non funcionan. Comezan a morrer.
Fundamentos da organización de DevOps
A organización ideal de DevOps do futuro é un sistema descentralizado e adaptativo composto por equipos autónomos, cada un deles formado por individuos autónomos. Estes equipos están espallados por todo o mundo, colaborando eficazmente entre si mediante a comunicación asíncrona, utilizando protocolos de comunicación altamente transparentes. Moi bonito, non? Un futuro moi bonito.
Por suposto, nada disto é posible sen un cambio cultural. Debemos ter liderado transformador, responsabilidade persoal, motivación interna.
Esta é a base das organizacións DevOps: transparencia da información, comunicacións asíncronas, liderado transformacional, descentralización.
Queimado
Os sistemas dos que formamos parte e os que construímos son cada vez máis caóticos, e aos humanos cústanos facer fronte a este pensamento, é difícil renunciar á ilusión de control. Intentamos seguir controlándoos, e isto leva a miúdo ao burnout. Dígoo pola miña propia experiencia, tamén me queimei, tamén quedei incapacitado por fallos imprevistos na produción.
O burnout prodúcese cando tentamos controlar algo que é inherentemente incontrolable. Cando nos queimamos, todo perde o seu sentido porque perdemos as ganas de facer algo novo, poñémonos á defensiva e comezamos a defender o que temos.
A profesión de enxeñeiro, como me gusta lembrar moitas veces, é ante todo unha profesión creativa. Se perdemos o desexo de crear algo, entón convertémonos en cinzas, convertémonos en cinzas. Queiman a xente, queiman organizacións enteiras.
Na miña opinión, só aceptar o poder creativo do caos, só construír a cooperación segundo os seus principios é o que nos axudará a non perder o que é bo na nosa profesión.
Isto é o que che desexo: amar o teu traballo, amar o que facemos. Este mundo aliméntase de información, temos a honra de alimentala. Entón, estudemos o caos, sexamos caosólogos, aportemos valor, creemos algo novo, bueno, os problemas, como xa descubrimos, son inevitables, e cando aparezan, simplemente diremos “Ops!” E o problema está resolto.
Que máis que Chaos Monkey?
De feito, todos estes instrumentos son tan novos. Os mesmos Netflix construíu ferramentas por si mesmos. Constrúe as túas propias ferramentas. Le os principios da enxeñería do caos e cumpre con eses principios en lugar de tentar atopar outras ferramentas que xa construíu outra persoa.
Tenta entender como se avarian os teus sistemas e comeza a avarialos e mira como aguantan. Isto é o primeiro. E podes buscar ferramentas. Hai todo tipo de proxectos.
Non entendín moi ben o momento no que dixeches que o sistema non se pode simplificar simplificando os seus compoñentes, e inmediatamente pasei aos microservizos, que simplifican o sistema simplificando os propios compoñentes e complicando as interaccións. Estas son esencialmente dúas partes que se contradín.
É certo, os microservizos son un tema moi controvertido en xeral. De feito, simplificar pezas aumenta a flexibilidade. Que ofrecen os microservizos? Dannos flexibilidade e velocidade, pero certamente non nos dan sinxeleza. Aumentan a dificultade.
Entón, na filosofía DevOps, os microservizos non son tan bos?
Calquera ben ten un reverso. O beneficio é que aumenta a flexibilidade, o que nos permite facer cambios máis rápido, pero aumenta a complexidade e, polo tanto, a fraxilidade de todo o sistema.
Aínda así, que é máis énfase: en simplificar a interacción ou en simplificar partes?
A énfase, por suposto, está na simplificación das interaccións, porque se miramos isto desde o punto de vista de como traballamos contigo, entón, en primeiro lugar, debemos prestar atención a simplificar as interaccións, e non a simplificar o traballo. de cada un de nós por separado. Porque simplificar o traballo significa converterse en robots. Aquí en McDonald's funciona normalmente cando tes instrucións: aquí pons a hamburguesa, aquí botas a salsa. Isto non funciona en absoluto no noso traballo creativo.
É certo que todo o que dixeches vive nun mundo sen competencia, e o caos que hai é tan amable, e non hai contradicións dentro deste caos, ninguén quere comer nin matar a ninguén? Como debería ir a competencia e DevOps?
Pois depende de que tipo de competición esteamos a falar. Trátase de competencia no ámbito laboral ou competencia entre empresas?
Sobre a competencia de servizos que existen porque os servizos non son varias empresas. Estamos creando un novo tipo de ambiente de información, e calquera ambiente non pode vivir sen competencia. Hai competencia en todas partes.
Os mesmos Netflix, tomámolos como modelo a seguir. Por que se lles ocorreu isto? Porque tiñan que ser competitivos. Esta flexibilidade e velocidade de movemento é precisamente o requisito moi competitivo; introduce o caos nos nosos sistemas. É dicir, o caos non é algo que facemos conscientemente porque o queiramos, é algo que pasa porque o mundo o demanda. Só temos que adaptarnos. E o caos, é precisamente o resultado da competencia.
Significa isto que o caos é a ausencia de goles, por así dicir? Ou eses obxectivos que non queremos ver? Estamos na casa e non entendemos os obxectivos dos demais. A competencia, de feito, débese a que temos os obxectivos claros e sabemos onde imos chegar en cada momento. Esta, desde o meu punto de vista, é a esencia de DevOps.
Tamén unha ollada á pregunta. Creo que todos temos o mesmo obxectivo: sobrevivir e facelo
maior pracer. E o obxectivo competitivo de calquera organización é o mesmo. A supervivencia ocorre a miúdo a través da competencia, non hai nada que poidas facer respecto diso.
A conferencia deste ano terá lugar o 7 de decembro en Technopolis. Aceptamos solicitudes de informes ata o 11 de novembro. connosco se queres falar.
A inscrición para os participantes está aberta, as entradas custan 7000 rublos. Únete a nós!
Fonte: www.habr.com