Anton Weiss, fundador y director de Otomato Software, uno de los iniciadores e instructores de la primera certificación DevOps en Israel, habló en la conferencia del año pasado. sobre la teoría del caos y los principios fundamentales de la ingeniería del caos, y también explicó cómo funciona la organización DevOps ideal del futuro.
Hemos preparado una versión de texto del informe.
Buenos días!
DevOpsDays en Moscú por segundo año consecutivo, esta es mi segunda vez en este escenario, muchos de ustedes están en esta sala por segunda vez. ¿Qué significa? Esto significa que el movimiento DevOps en Rusia está creciendo, multiplicándose y, lo más importante, que ha llegado el momento de hablar sobre qué es DevOps en 2018.
¿Levanten la mano quienes piensan que DevOps ya es una profesión en 2018? Los hay. ¿Hay algún ingeniero de DevOps en la sala cuya descripción de trabajo diga "Ingeniero de DevOps"? ¿Hay gerentes de DevOps en la sala? No hay tal. ¿Arquitectos DevOps? También no. No es suficiente. ¿Es realmente cierto que nadie dice ser ingeniero de DevOps?
Entonces, ¿la mayoría de ustedes piensa que esto es un antipatrón? ¿Que tal profesión no debería existir? Podemos pensar lo que queramos, pero mientras pensamos, la industria avanza solemnemente al son de la trompeta de DevOps.
¿Quién ha oído hablar de un nuevo tema llamado DevDevOps? Esta es una nueva técnica que permite una colaboración efectiva entre desarrolladores y devops. Y no tan nuevo. A juzgar por Twitter, ya empezaron a hablar de esto hace 4 años. Y hasta ahora el interés por esto va creciendo y creciendo, es decir, hay un problema. Es necesario resolver el problema.
Somos personas creativas, no sólo descansamos tranquilos. Decimos: DevOps no es una palabra lo suficientemente completa; todavía carece de todo tipo de elementos diferentes e interesantes. Y vamos a nuestros laboratorios secretos y comenzamos a producir mutaciones interesantes: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
La lógica es férrea, ¿verdad? Nuestro sistema de entrega no funciona, nuestros sistemas son inestables y nuestros usuarios están insatisfechos, no tenemos tiempo para implementar el software a tiempo, no nos ajustamos al presupuesto. ¿Cómo vamos a solucionar todo esto? ¡Se nos ocurrirá una nueva palabra! Terminará con "Ops" y el problema estará resuelto.
Por eso llamo a este enfoque: "Ops y el problema está resuelto".
Todo esto pasa a un segundo plano si recordamos por qué se nos ocurrió todo esto. Se nos ocurrió todo este asunto de DevOps para hacer que la entrega de software y nuestro propio trabajo en este proceso sea lo más libre de obstáculos, sencillo, eficiente y, lo más importante, agradable posible.
DevOps surgió del dolor. Y estamos cansados de sufrir. Y para que todo esto suceda, confiamos en prácticas siempre vigentes: colaboración efectiva, prácticas de flujo y, lo más importante, pensamiento sistémico, porque sin él ningún DevOps funciona.
¿Qué es un sistema?
Y si ya estamos hablando de pensamiento sistémico, recordemos qué es un sistema.
Si eres un hacker revolucionario, entonces para ti el sistema es claramente malvado. Es una nube que se cierne sobre ti y te obliga a hacer cosas que no quieres hacer.
Desde el punto de vista del pensamiento sistémico, un sistema es un todo que consta de partes. En este sentido, cada uno de nosotros es un sistema. Las organizaciones en las que trabajamos son sistemas. Y lo que tú y yo estamos construyendo se llama sistema.
Todo esto es parte de un gran sistema sociotecnológico. Y solo si entendemos cómo funciona este sistema sociotecnológico en conjunto, solo entonces podremos optimizar algo en este asunto.
Desde la perspectiva del pensamiento sistémico, un sistema tiene varias propiedades interesantes. Primero, consta de partes, lo que significa que su comportamiento depende del comportamiento de las partes. Además, todas sus partes también son interdependientes. Resulta que cuantas más partes tenga un sistema, más difícil será comprender o predecir su comportamiento.
Desde el punto de vista del comportamiento, hay otro dato interesante. El sistema puede hacer algo que ninguna de sus partes individuales puede hacer.
Como dijo el Dr. Russell Ackoff (uno de los fundadores del pensamiento sistémico), esto es bastante fácil de demostrar con un experimento mental. Por ejemplo, ¿quién en la sala sabe escribir código? Hay muchas manos, y esto es normal, porque es uno de los principales requisitos de nuestra profesión. ¿Sabes escribir, pero tus manos pueden escribir código por separado de ti? Hay gente que dirá: “No son mis manos las que escriben el código, es mi cerebro el que escribe el código”. ¿Puede tu cerebro escribir código por separado de ti? Bueno, probablemente no.
El cerebro es una máquina asombrosa, no sabemos ni el 10% de cómo funciona allí, pero no puede funcionar por separado del sistema que es nuestro cuerpo. Y esto es fácil de demostrar: abre tu cráneo, saca tu cerebro, ponlo frente a la computadora, deja que intente escribir algo simple. "Hola mundo" en Python, por ejemplo.
Si un sistema puede hacer algo que ninguna de sus partes puede hacer por separado, entonces esto significa que su comportamiento no está determinado por el comportamiento de sus partes. ¿Por qué entonces está determinado? Está determinado por la interacción entre estas partes. Y en consecuencia, cuantas más partes, más complejas sean las interacciones, más difícil será comprender y predecir el comportamiento del sistema. Y esto hace que dicho sistema sea caótico, porque cualquier cambio invisible, incluso el más insignificante, en cualquier parte del sistema puede conducir a resultados completamente impredecibles.
Esta sensibilidad a las condiciones iniciales fue descubierta y estudiada por primera vez por el meteorólogo estadounidense Ed Lorenz. Posteriormente, se le denominó “efecto mariposa” y condujo al desarrollo de un movimiento de pensamiento científico llamado “teoría del caos”. Esta teoría se convirtió en uno de los principales cambios de paradigma en la ciencia del siglo XX.
Teoria del caos
Las personas que estudian el caos se llaman a sí mismos caosólogos.
En realidad, el motivo de este informe fue que, trabajando con sistemas distribuidos complejos y grandes organizaciones internacionales, en algún momento me di cuenta de que esto es lo que me apetece. Soy caosólogo. Esta es básicamente una forma inteligente de decir: "No entiendo lo que está pasando aquí y no sé qué hacer al respecto".
Creo que muchos de ustedes también se sienten así a menudo, por lo que también son caosólogos. Te invito al gremio de caosólogos. Los sistemas que usted y yo, queridos colegas caosólogos, estudiaremos se denominan "sistemas adaptativos complejos".
¿Qué es la adaptabilidad? Adaptabilidad significa que el comportamiento individual y colectivo de las partes de dicho sistema adaptativo cambia y se autoorganiza, respondiendo a eventos o cadenas de microeventos en el sistema. Es decir, el sistema se adapta a los cambios mediante la autoorganización. Y esta capacidad de autoorganización se basa en la cooperación voluntaria y completamente descentralizada de agentes libres y autónomos.
Otra propiedad interesante de estos sistemas es que son libremente escalables. Lo que sin duda debería interesarnos a nosotros, como caosólogos-ingenieros. Entonces, si dijéramos que el comportamiento de un sistema complejo está determinado por la interacción de sus partes, ¿qué debería interesarnos? Interacción.
Hay dos hallazgos más interesantes.
Primero, entendemos que un sistema complejo no se puede simplificar simplificando sus partes. En segundo lugar, la única manera de simplificar un sistema complejo es simplificando las interacciones entre sus partes.
¿Cómo interactuamos? Tú y yo somos partes de un gran sistema de información llamado sociedad humana. Interactuamos a través de un lenguaje común, si lo tenemos, si lo encontramos.
Pero el lenguaje en sí es un sistema adaptativo complejo. En consecuencia, para interactuar de manera más eficiente y sencilla, necesitamos crear algún tipo de protocolos. Es decir, alguna secuencia de símbolos y acciones que harán que el intercambio de información entre nosotros sea más sencillo, más predecible, más comprensible.
Quiero decir que en todo se pueden rastrear tendencias hacia la complejidad, hacia la adaptabilidad, hacia la descentralización, hacia el caos. Y en los sistemas que usted y yo estamos construyendo, y en aquellos sistemas de los que formamos parte.
Y para no ser infundados, veamos cómo están cambiando los sistemas que creamos.
Estabas esperando esta palabra, lo entiendo. Estamos en una conferencia de DevOps, hoy esta palabra se escuchará unas cien mil veces y luego soñaremos con ella por la noche.
Los microservicios son la primera arquitectura de software que surgió como reacción a las prácticas de DevOps, que está diseñada para hacer que nuestros sistemas sean más flexibles, más escalables y garantizar una entrega continua. ¿Cómo hace esto? Al reducir el volumen de servicios, se reduce el alcance de los problemas que procesan estos servicios, se reduce el tiempo de entrega. Es decir, reducimos y simplificamos partes del sistema, aumentamos su número y, en consecuencia, la complejidad de las interacciones entre estas partes aumenta invariablemente, es decir, surgen nuevos problemas que tenemos que resolver.
Los microservicios no son el fin, los microservicios, en general, ya son ayer, porque llega Serverless. Todos los servidores se quemaron, ni servidores, ni sistemas operativos, solo código ejecutable puro. Las configuraciones están separadas, los estados están separados, todo está controlado por eventos. Belleza, limpieza, silencio, sin acontecimientos, no pasa nada, orden completo.
¿Dónde está la complejidad? La dificultad, por supuesto, está en las interacciones. ¿Cuánto puede hacer una función por sí sola? ¿Cómo interactúa con otras funciones? Colas de mensajes, bases de datos, balanceadores. ¿Cómo recrear algún evento cuando ocurrió una falla? Muchas preguntas y pocas respuestas.
Los microservicios y Serverless son lo que los geek hipsters llamamos Cloud Native. Se trata de la nube. Pero la nube también tiene una escalabilidad inherentemente limitada. Estamos acostumbrados a pensar en ello como un sistema distribuido. De hecho, ¿dónde residen los servidores de los proveedores de la nube? En centros de datos. Es decir, tenemos aquí una especie de modelo distribuido, centralizado y muy limitado.
Hoy entendemos que Internet de las cosas ya no son sólo palabras mayores: incluso según modestas predicciones, nos esperan miles de millones de dispositivos conectados a Internet en los próximos cinco a diez años. Una gran cantidad de datos útiles e inútiles que se fusionarán en la nube y se cargarán desde la nube.
La nube no durará, por eso hablamos cada vez más de algo llamado computación de borde. O también me gusta la maravillosa definición de “computación de niebla”. Está envuelto en el misticismo del romanticismo y el misterio.
Computación de niebla. La cuestión es que las nubes son acumulaciones centralizadas de agua, vapor, hielo y piedras. Y la niebla son gotas de agua que se esparcen a nuestro alrededor en la atmósfera.
En el paradigma de la niebla, la mayor parte del trabajo lo realizan estas gotas de forma completamente autónoma o en colaboración con otras gotas. Y recurren a la nube sólo cuando están realmente presionados.
Es decir, nuevamente descentralización, autonomía y, por supuesto, muchos de ustedes ya entienden hacia dónde va todo esto, porque no se puede hablar de descentralización sin mencionar la cadena de bloques.
Hay quienes creen, estos son los que han invertido en criptomonedas. Hay quienes creen pero tienen miedo, como yo, por ejemplo. Y hay quienes no creen. Aquí puedes tratar de manera diferente. Hay tecnología, una nueva incógnita, hay problemas. Como cualquier tecnología nueva, plantea más preguntas de las que responde.
El revuelo en torno a blockchain es comprensible. Dejando a un lado la fiebre del oro, la tecnología en sí misma encierra promesas notables para un futuro mejor: más libertad, más autonomía, confianza global distribuida. ¿Qué es no querer?
En consecuencia, cada vez más ingenieros de todo el mundo están empezando a desarrollar aplicaciones descentralizadas. Y este es un poder que no se puede descartar simplemente diciendo: "Ahh, blockchain es sólo una base de datos distribuida mal implementada". O como les gusta decir a los escépticos: "No existen aplicaciones reales para blockchain". Si lo piensas bien, hace 150 años decían lo mismo de la electricidad. Y en algunos aspectos incluso tenían razón, porque lo que la electricidad hace posible hoy en día no era posible en el siglo XIX.
Por cierto, ¿quién sabe qué tipo de logo hay en la pantalla? Este es Hyperledger. Este es un proyecto que se está desarrollando bajo los auspicios de The Linux Foundation e incluye un conjunto de tecnologías blockchain. Ésta es verdaderamente la fortaleza de nuestra comunidad de código abierto.
Ingeniería del Caos
Entonces, el sistema que estamos desarrollando se está volviendo cada vez más complejo, cada vez más caótico y cada vez más adaptable. Netflix son pioneros en sistemas de microservicios. Fueron de los primeros en entender esto, desarrollaron un conjunto de herramientas que llamaron Ejército Simio, la más famosa de las cuales fue . Definió lo que se conoció como .
Por cierto, en el proceso de elaboración del informe, incluso tradujimos este texto al ruso, así que vaya a , leer, comentar, regañar.
Brevemente, los principios de la ingeniería del caos dicen lo siguiente. Los sistemas distribuidos complejos son inherentemente impredecibles y con errores inherentes. Los errores son inevitables, lo que significa que debemos aceptarlos y trabajar con estos sistemas de una manera completamente diferente.
Nosotros mismos debemos intentar introducir estos errores en nuestros sistemas de producción para probar nuestros sistemas en busca de esta misma adaptabilidad, esta misma capacidad de autoorganización, de supervivencia.
Y eso lo cambia todo. No sólo cómo lanzamos los sistemas a producción, sino también cómo los desarrollamos y cómo los probamos. No hay ningún proceso de estabilización o congelamiento del código, al contrario, hay un proceso constante de desestabilización. Estamos tratando de acabar con el sistema y verlo continuar sobreviviendo.
Protocolos de integración de sistemas distribuidos
En consecuencia, esto requiere que nuestros sistemas cambien de alguna manera. Para que se vuelvan más estables, necesitan nuevos protocolos de interacción entre sus partes. Para que estas partes puedan ponerse de acuerdo y llegar a algún tipo de autoorganización. Y surgen todo tipo de nuevas herramientas, nuevos protocolos, que yo llamo "protocolos para la interacción de sistemas distribuidos".
¿De qué estoy hablando? Primero, el proyecto . Algunos intentan crear un protocolo de seguimiento distribuido general, que es una herramienta absolutamente indispensable para depurar sistemas distribuidos complejos.
Más lejos - . Decimos que no podemos predecir qué pasará con el sistema, es decir, necesitamos aumentar su observabilidad, observabilidad. Opentracing pertenece a una familia de herramientas que dan observabilidad a nuestros sistemas. Pero necesitamos observabilidad para determinar si el sistema se comporta como esperamos o no. ¿Cómo definimos el comportamiento esperado? Definiendo algún tipo de política, algún conjunto de reglas. El proyecto Open Policy Agent está trabajando para definir este conjunto de reglas en un espectro que va desde el acceso hasta la asignación de recursos.
Como dijimos, nuestros sistemas se basan cada vez más en eventos. Serverless es un gran ejemplo de sistemas controlados por eventos. Para que podamos transferir eventos entre sistemas y rastrearlos, necesitamos algún lenguaje común, algún protocolo común sobre cómo hablamos de eventos, cómo los transmitimos entre nosotros. Así se llama un proyecto .
El flujo constante de cambios que inunda nuestros sistemas, desestabilizándolos constantemente, es un flujo continuo de artefactos de software. Para que podamos mantener este flujo constante de cambios, necesitamos algún tipo de protocolo común a través del cual podamos hablar sobre qué es un artefacto de software, cómo se prueba y qué verificación ha pasado. Así se llama un proyecto . Es decir, un protocolo de metadatos común para artefactos de software.
Y finalmente, si queremos que nuestros sistemas sean completamente independientes, adaptables y autoorganizados, debemos darles el derecho a la autoidentificación. Proyecto llamado Esto es exactamente lo que hace. Este también es un proyecto bajo los auspicios de la Cloud Native Computing Foundation.
Todos estos proyectos son jóvenes, todos necesitan nuestro amor, nuestra validación. Todo esto es de código abierto, nuestras pruebas, nuestra implementación. Nos muestran hacia dónde se dirige la tecnología.
Pero DevOps nunca se ha centrado principalmente en la tecnología, siempre se ha centrado en la colaboración entre personas. Y, en consecuencia, si queremos que los sistemas que desarrollamos cambien, entonces nosotros mismos debemos cambiar. De hecho, estamos cambiando de todos modos; no tenemos muchas opciones.
Hay una maravillosa La escritora británica Rachel Botsman, en el que escribe sobre la evolución de la confianza a lo largo de la historia de la humanidad. Ella dice que inicialmente, en las sociedades primitivas, la confianza era local, es decir, confiábamos sólo en aquellos que conocíamos personalmente.
Luego hubo un período muy largo, una época oscura en la que la confianza estaba centralizada, cuando empezamos a confiar en personas que no conocemos por el hecho de que pertenecemos a la misma institución pública o estatal.
Y esto es lo que vemos en nuestro mundo moderno: la confianza está cada vez más distribuida y descentralizada, y se basa en la libertad de los flujos de información, en la disponibilidad de la información.
Si lo piensas bien, esta misma accesibilidad, que hace posible esta confianza, es lo que tú y yo estamos implementando. Esto significa que tanto la forma en que colaboramos como la forma en que lo hacemos debe cambiar, porque las organizaciones de TI centralizadas y jerárquicas de antaño ya no funcionan. Comienzan a morir.
Fundamentos de la organización DevOps
La organización DevOps ideal del futuro es un sistema adaptativo descentralizado compuesto por equipos autónomos, cada uno de ellos formado por individuos autónomos. Estos equipos están dispersos por todo el mundo y colaboran eficazmente entre sí mediante comunicación asincrónica y protocolos de comunicación altamente transparentes. Muy hermoso, ¿no? Un futuro muy hermoso.
Por supuesto, nada de esto es posible sin un cambio cultural. Debemos tener liderazgo transformacional, responsabilidad personal, motivación interna.
Esta es la base de las organizaciones DevOps: transparencia de la información, comunicaciones asincrónicas, liderazgo transformacional, descentralización.
Agotamiento
Los sistemas de los que formamos parte y los que construimos son cada vez más caóticos, y a los humanos nos resulta difícil hacer frente a este pensamiento, es difícil renunciar a la ilusión de control. Intentamos seguir controlándolos y esto a menudo conduce al agotamiento. Lo digo por experiencia propia, yo también me quemé, también quedé incapacitado por fallas imprevistas en la producción.
El agotamiento ocurre cuando intentamos controlar algo que es inherentemente incontrolable. Cuando nos quemamos todo pierde su sentido porque perdemos las ganas de hacer algo nuevo, nos ponemos a la defensiva y empezamos a defender lo que tenemos.
La profesión de ingeniero, como me gusta recordarme a menudo, es ante todo una profesión creativa. Si perdemos el deseo de crear algo, entonces nos convertimos en cenizas, nos convertimos en cenizas. La gente se agota, organizaciones enteras se agotan.
En mi opinión, sólo aceptar el poder creativo del caos, sólo construir la cooperación según sus principios, es lo que nos ayudará a no perder lo bueno de nuestra profesión.
Esto es lo que deseo para ti: que ames tu trabajo, que ames lo que hacemos. Este mundo se alimenta de información, tenemos el honor de alimentarla. Entonces, estudiemos el caos, seamos caosólogos, aportemos valor, creemos algo nuevo, bueno, los problemas, como ya hemos descubierto, son inevitables, y cuando aparezcan, simplemente diremos "¡Ops!" Y el problema está resuelto.
¿Qué más que el Mono del Caos?
De hecho, todos estos instrumentos son muy jóvenes. Los mismos Netflix crearon herramientas para ellos mismos. Construye tus propias herramientas. Lea los principios de la ingeniería del caos y cumpla con esos principios en lugar de intentar encontrar otras herramientas que otra persona ya haya creado.
Intente comprender cómo se estropean sus sistemas y comience a descomponerlos y vea cómo se mantienen. Esto es lo primero. Y puedes buscar herramientas. Hay todo tipo de proyectos.
No entendí muy bien el momento en que dijiste que el sistema no se puede simplificar simplificando sus componentes, e inmediatamente pasé a los microservicios, que simplifican el sistema simplificando los componentes mismos y complicando las interacciones. Se trata esencialmente de dos partes que se contradicen entre sí.
Así es, los microservicios son un tema muy controvertido en general. De hecho, simplificar piezas aumenta la flexibilidad. ¿Qué proporcionan los microservicios? Nos dan flexibilidad y velocidad, pero ciertamente no nos dan simplicidad. Aumentan la dificultad.
Entonces, en la filosofía DevOps, ¿los microservicios no son algo tan bueno?
Todo bien tiene un reverso. El beneficio es que aumenta la flexibilidad, permitiéndonos realizar cambios más rápido, pero aumenta la complejidad y por tanto la fragilidad de todo el sistema.
Aún así, ¿en qué se pone más énfasis: en simplificar la interacción o en simplificar las partes?
El énfasis, por supuesto, está en simplificar las interacciones, porque si miramos esto desde el punto de vista de cómo trabajamos con usted, entonces, en primer lugar, debemos prestar atención a simplificar las interacciones y no a simplificar el trabajo. de cada uno de nosotros por separado. Porque simplificar el trabajo significa convertirse en robots. Aquí en McDonald's funciona normalmente cuando tienes instrucciones: aquí pones la hamburguesa, aquí le echas la salsa. Esto no funciona en absoluto en nuestro trabajo creativo.
¿Es cierto que todo lo que dijiste vive en un mundo sin competencia, y el caos allí es tan amable, y no hay contradicciones dentro de este caos, nadie quiere comerse ni matar a nadie? ¿Cómo deberían funcionar la competencia y DevOps?
Bueno, depende de qué tipo de competencia estemos hablando. ¿Se trata de competencia en el lugar de trabajo o de competencia entre empresas?
Sobre la competencia de servicios que existe porque los servicios no son de varias empresas. Estamos creando un nuevo tipo de entorno de información y ningún entorno puede vivir sin competencia. Hay competencia en todas partes.
Los mismos Netflix, los tomamos como modelo a seguir. ¿Por qué se les ocurrió esto? Porque necesitaban ser competitivos. Esta flexibilidad y velocidad de movimiento es precisamente un requisito muy competitivo: introduce el caos en nuestros sistemas. Es decir, el caos no es algo que hacemos conscientemente porque lo queremos, es algo que sucede porque el mundo lo exige. Sólo tenemos que adaptarnos. Y el caos, es precisamente fruto de la competencia.
¿Significa esto que el caos es la ausencia de objetivos, por así decirlo? ¿O esos goles que no queremos ver? Estamos en la casa y no entendemos los objetivos de los demás. La competencia, de hecho, se debe al hecho de que tenemos objetivos claros y sabemos dónde terminaremos en cada momento. Ésta, desde mi punto de vista, es la esencia de DevOps.
También una mirada a la pregunta. Creo que todos tenemos el mismo objetivo: sobrevivir y hacerlo con
mayor placer. Y el objetivo competitivo de cualquier organización es el mismo. La supervivencia a menudo ocurre a través de la competencia, no hay nada que puedas hacer al respecto.
La conferencia de este año tendrá lugar el 7 de diciembre en Tecnópolis. Estamos aceptando solicitudes de informes hasta el 11 de noviembre. nosotros si quieres hablar.
La inscripción para los participantes está abierta, las entradas cuestan 7000 rublos. ¡Únete a nosotros!
Fuente: habr.com