O fundador e diretor da "Otomato Software", um dos proponentes e instrutores da primeira certificação DevOps em Israel, Anton Weiss, compartilhou no ano passado sobre a teoria do caos e os principais princípios da engenharia do caos, além de explicar como seria a organização DevOps ideal do futuro.
Preparamos uma versão em texto da apresentação.
Bom dia!
O DevOpsDays em Moscovo acontece pelo segundo ano consecutivo, e eu estou novamente neste palco, muitos de vocês estão aqui pela segunda vez. E o que isso significa? Significa que o movimento DevOps na Rússia está crescendo, se multiplicando, e o mais importante, significa que chegou a hora de falarmos sobre o que é DevOps em 2018.
Levantem as mãos aqueles que acham que em 2018 DevOps já é uma profissão? Tem alguém. Existem engenheiros DevOps na sala, cujo título inclui "engenheiro DevOps"? E gerentes DevOps? Não tem ninguém. Arquitetos DevOps? Também não. Poucos. Realmente ninguém tem escrito que é engenheiro DevOps?
Então, a maioria de vocês acha que isso é um antipadrão? Que essa profissão não deveria existir? Podemos pensar o que quisermos, mas enquanto pensamos, a indústria avança solenemente ao som do toque da DevOps.
Quem ouviu sobre um novo tema chamado DevDevOps? É uma nova metodologia que permite uma colaboração eficaz entre desenvolvedores e DevOps. E não é tão nova. Pelo que vejo no Twitter, já se falava sobre isso há 4 anos. E até hoje o interesse continua a crescer, ou seja, existe um problema. Precisamos resolver esse problema.
Somos pessoas criativas e não nos contentamos facilmente. Dizemos que DevOps é uma palavra insuficientemente abrangente, que falta uma série de elementos interessantes. E vamos para nossos laboratórios secretos e começamos a criar mutações curiosas: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
A lógica é inquestionável, certo? Nosso sistema de entrega não é funcional, nossas sistemas são instáveis e os usuários estão insatisfeitos, não conseguimos liberar software a tempo, não conseguimos ficar dentro do orçamento. Como vamos resolver tudo isso? Vamos inventar uma nova palavra! Ela vai terminar em "Ops", e o problema estará resolvido.
Assim, eu chamo essa abordagem de "Ops, e o problema está resolvido".
Tudo isso fica em segundo plano quando nos lembramos do porquê de termos criado tudo isso. Criamos todo esse DevOps para tornar a entrega de software e nosso próprio trabalho nesse processo o mais fluido, indolor, eficiente e, acima de tudo, agradável possível.
O DevOps cresceu da dor. Estamos cansados de sofrer. E para que tudo isso aconteça, baseamo-nos em práticas perenes: colaboração eficaz, práticas de fluxo e, mais importante, pensamento sistêmico, porque sem isso nenhum DevOps funciona.
O que é um sistema?
E se estamos falando sobre pensamento sistêmico, vamos nos lembrar do que é um sistema.
Se você é um hacker revolucionário, então para você o sistema é um mal absoluto. É uma nuvem que paira sobre você e te obriga a fazer o que você não quer fazer.
Do ponto de vista do pensamento sistêmico, um sistema é um todo que consiste em partes. Nesse sentido, cada um de nós é um sistema. As organizações em que trabalhamos são sistemas. E aquilo que estamos construindo juntos é chamado de sistema.
Tudo isso é parte de um grande sistema sociotecnológico. E só se entendermos como esse sistema sociotecnológico funciona em conjunto, poderemos realmente otimizar algo nesse processo.
Do ponto de vista do pensamento sistêmico, o sistema possui características interessantes. Em primeiro lugar, é composto por partes, o que significa que seu comportamento depende do comportamento das partes. Além disso, todas as suas partes também são interdependentes. Portanto, quanto mais partes um sistema tem, mais difícil fica entender ou prever seu comportamento.
Do ponto de vista do comportamento, existe mais um fato interessante. Um sistema pode fazer algo que nenhuma de suas partes individuais consegue fazer.
Como disse o Dr. Russell Ackoff (um dos fundadores do pensamento sistêmico), isso pode ser facilmente demonstrado através de um experimento mental. Por exemplo, quem aqui sabe escrever código? Muitas mãos se levantam, e isso é normal, pois é uma das exigências básicas da nossa profissão. Você é capaz de escrever, mas suas mãos, separadas de você, podem escrever código? Existem pessoas que dirão: 'Não são minhas mãos que escrevem código, é meu cérebro que escreve código'. E o cérebro pode escrever código separado de você? Bem, provavelmente não.
O cérebro é uma máquina incrível; nós conhecemos apenas 10% de como ele funciona, mas não pode operar isoladamente do sistema que é nosso organismo. E isso pode ser facilmente provado: abra seu crânio, retire o cérebro de lá, coloque-o diante de um computador e veja se consegue escrever algo simples. "Hello, world" em Python, por exemplo.
Se um sistema pode fazer algo que nenhuma de suas partes, isoladamente, consegue fazer, isso significa que seu comportamento não é definido pelo comportamento de suas partes. Pelo que ele é então definido? Ele é determinado pela interação entre essas partes. E, consequentemente, quanto mais partes, mais complexas são as interações e mais difícil é compreender e prever o comportamento do sistema. Isso torna o sistema caótico, pois qualquer pequena e invisível alteração em qualquer uma das partes do sistema pode levar a resultados completamente imprevisíveis.
Essa sensibilidade às condições iniciais foi descoberta e estudada pela primeira vez pelo meteorologista americano Ed Lorenz. Posteriormente, recebeu o nome de "efeito borboleta" e levou ao desenvolvimento de um movimento de pensamento científico conhecido como "teoria do caos". Essa teoria se tornou uma das principais mudanças de paradigma na ciência do século 20.
Teoria do Caos
As pessoas que estudam o caos se chamam de caosólogos.
Na verdade, a razão por trás desta apresentação é que, ao trabalhar com sistemas complexos e organizações internacionais grandes, cheguei ao ponto em que percebi que é isso que sou. Eu sou um caosólogo. É, digamos, uma maneira engenhosa de dizer: "Eu não entendo o que está acontecendo aqui e não sei o que fazer com isso."
Eu acho que muitos de vocês também se sentem assim com frequência, então vocês também são caosólogos. Convido vocês para a guilda dos caosólogos. Os sistemas que nós, queridos colegas caosólogos, iremos estudar, são chamados de "sistemas adaptativos complexos".
O que é adaptabilidade? Adaptabilidade significa que o comportamento individual e coletivo das partes em um sistema adaptativo muda e se autoorganiza, respondendo a eventos ou cadeias de microeventos no sistema. Ou seja, o sistema se adapta às mudanças por meio da autoorganização. E essa capacidade de autoorganização é baseada na colaboração voluntária e completamente descentralizada de agentes autônomos livres.
Outra propriedade interessante desses sistemas é que eles são livremente escaláveis. O que, como engenheiros do caos, deve nos interessar indiscutivelmente. Assim, se dissemos que o comportamento de um sistema complexo é determinado pela interação de suas partes, o que deve nos interessar? A interação.
Há mais duas conclusões interessantes.
Em primeiro lugar, entendemos que um sistema complexo não pode ser simplificado pela simplificação de suas partes. Em segundo lugar, a única maneira de simplificar um sistema complexo é através da simplificação das interações entre suas partes.
Como interagimos? Todos nós somos partes de um grande sistema informativo chamado sociedade humana. Interagimos através de uma linguagem comum, se a tivermos, se a encontrarmos.
Mas a linguagem por si só é um sistema adaptativo complexo. Portanto, para interagir de maneira mais eficaz e simples, precisamos criar alguns protocolos. Ou seja, uma sequência de símbolos e ações que tornará a troca de informações entre nós mais simples, mais previsível, mais clara.
Quero dizer que as tendências para a complexidade, a adaptabilidade, a descentralização e o caos estão presentes em tudo. Nas sistemas que construímos e nos sistemas dos quais fazemos parte.
E para não ser apenas uma afirmação vazia, vamos observar como os sistemas que criamos mudam.
Você estava esperando por essa palavra, eu sei. Estamos na conferência DevOps e hoje essa palavra será mencionada cerca de cem mil vezes e depois nos perseguirá à noite.
Microserviços são a primeira arquitetura de software que surgiu como uma reação às práticas DevOps, destinada a tornar nossos sistemas mais flexíveis, escaláveis e a garantir entrega contínua. Como isso é possível? Através da redução do volume de serviços, da diminuição das fronteiras dos problemas que esses serviços lidam e da diminuição do tempo de entrega. Ou seja, estamos diminuindo e simplificando partes do sistema, aumentando sua quantidade. Assim, inevitavelmente a complexidade das interações entre essas partes aumenta, surgindo novos problemas que precisamos resolver.
Microserviços não são o fim; na verdade, microserviços já são um conceito ultrapassado, pois o Serverless está chegando. Todos os servidores queimaram, não há servidores, não há sistemas operacionais, apenas código executável puro. As configurações são separadas, os estados são separados, tudo é gerenciado por eventos. Beleza, pureza, tranquilidade; não há eventos, nada acontece, tudo está em ordem.
Onde está a complexidade? A complexidade, como podemos perceber, está nas interações. Quanto uma função pode fazer sozinha? Como ela interage com outras funções? Filas de mensagens, bancos de dados, balanceadores. Como recriar um evento quando ocorre uma falha? Uma infinidade de perguntas e poucas respostas.
Microserviços e Serverless são tudo o que nós, hipsters da computação, chamamos de Cloud Native. É tudo sobre a nuvem. Mas a nuvem, em sua essência, também é limitada em termos de escalabilidade. Costumamos pensar nela como um sistema distribuído. Na verdade, onde estão os servidores dos provedores de nuvem? Em data centers. Ou seja, temos aqui um modelo centralizado, muito limitado e distribuído.
Hoje entendemos que a internet das coisas não se resume a palavras chamativas; mesmo de acordo com previsões modestas, nos próximos cinco a dez anos, seremos cercados por bilhões de dispositivos conectados à internet. Uma enorme quantidade de dados úteis e inúteis que será integrada na nuvem e que será alimentada a partir dela.
A nuvem não suportará isso, por isso falamos cada vez mais sobre o que chamamos de "computação de borda". Ou, ainda, gosto da definição maravilhosa de "fog computing". Isso é envolto em uma mística de romantismo e mistério.
Computação nebulosa. Refere-se ao fato de que as nuvens são aglomerados centralizados de água, vapor, gelo e pedras. E o nevoeiro é composto por gotículas de água dispersas ao nosso redor na atmosfera.
Na paradigma nevoento, a maior parte do trabalho é realizada por essas gotículas de forma completamente autônoma ou em colaboração com outras gotículas. E elas se conectam à nuvem apenas quando realmente necessário.
Ou seja, novamente a descentralização, a autonomia, e, claro, muitos de vocês já entendem para onde tudo isso está indo, porque não se pode falar sobre descentralização sem mencionar blockchain.
Existem aqueles que acreditam, que são os que investiram em criptomoedas. Existem os que acreditam, mas têm medo, como eu, por exemplo. E há aqueles que não acreditam. Cada um pode ter uma visão diferente. Existe uma tecnologia, uma nova e desconhecida, e há problemas. Como qualquer nova tecnologia, ela levanta mais perguntas do que respostas.
O hype em torno do blockchain é compreensível. Mesmo se deixarmos de lado a febre do ouro, a própria tecnologia promete um futuro brilhante: mais liberdade, mais autonomia, confiança global distribuída. O que não gostar disso?
Consequentemente, cada vez mais engenheiros em todo o mundo começam a desenvolver aplicações descentralizadas. E essa é uma força que não pode ser ignorada, simplesmente dizendo: "Ah, o blockchain é apenas um banco de dados distribuído mal implementado". Ou como os céticos gostam de dizer: "Não há aplicações reais para o blockchain". Se pensarmos, 150 anos atrás eles diziam a mesma coisa sobre eletricidade. E até certo ponto estavam certos, pois o que a eletricidade torna possível hoje era completamente inimaginável no século 19.
A propósito, quem sabe qual é o logo na tela? É o Hyperledger. É um projeto desenvolvido sob os auspícios da The Linux Foundation, que inclui um conjunto de tecnologias de blockchain. É realmente uma força na nossa comunidade de código aberto.
Engenharia do caos
Então, o sistema que estamos desenvolvendo se torna cada vez mais complexo, cada vez mais caótico e adaptável. O Netflix foi um pioneiro em sistemas de microserviços. Eles foram um dos primeiros a perceber isso e desenvolveram um conjunto de ferramentas que chamaram de Simian Army, sendo o mais famoso deles . Ele definiu o que ficou conhecido como .
Aliás, durante o trabalho na apresentação, nós até traduzimos esse texto para o russo, então acesse , leia, comente, critique.
Em suma, os princípios da engenharia do caos dizem o seguinte. Sistemas distribuídos complexos são, por sua própria natureza, imprevisíveis e têm, por natureza, falhas. Falhas são inevitáveis, o que significa que precisamos aceitá-las e trabalhar com esses sistemas de uma maneira completamente diferente.
Devemos tentar introduzir essas falhas em nossos sistemas de produção para testar a adaptabilidade, a capacidade de auto-organização e a sobrevivência desses sistemas.
E isso muda tudo. Não apenas a forma como colocamos o sistema em produção, mas também como o desenvolvemos, como o testamos. Não existe um processo de estabilização, congelamento de código; pelo contrário, existe um processo contínuo de desestabilização. Tentamos destruir o sistema e ver se ele continua a sobreviver.
Protocolos de Integração de Sistemas Distribuídos
Consequentemente, isso exige que nossos sistemas também mudem de alguma forma. Para que se tornem mais resilientes, eles precisam de novos protocolos de interação entre suas partes. Para que essas partes possam se comunicar e chegar a alguma forma de auto-organização. E assim surgem várias novas ferramentas, novos protocolos, que eu chamo de «protocolos de interação de sistemas distribuídos».
Sobre o que estou falando? Em primeiro lugar, o projeto . Uma tentativa de criar um protocolo comum de rastreamento distribuído, que é uma ferramenta absolutamente essencial para depurar sistemas distribuídos complexos.
Em seguida — . Dizemos que não podemos prever o que ocorrerá com o sistema, portanto precisamos aumentar sua observabilidade. O Opentracing pertence à família de ferramentas que proporcionam visibilidade aos nossos sistemas. Mas a observabilidade é necessária para determinar se o sistema se comporta da maneira que esperamos ou não. Como podemos determinar o comportamento esperado? Através da definição de uma política, um conjunto de regras. O projeto Open Policy Agent lida com a definição desse conjunto de regras em uma ampla gama de áreas, desde acesso até alocação de recursos.
Como dissemos, nossos sistemas estão se tornando cada vez mais gerenciados por eventos. Serverless é um ótimo exemplo de sistemas gerenciados por eventos. Para que possamos transmitir eventos entre sistemas e monitorá-los, precisamos de uma linguagem comum, um protocolo comum de como falamos sobre eventos, como os transmitimos uns aos outros. Isso é o que o projeto chamado .
Fluxo contínuo de mudanças que permeia nossos sistemas, desestabilizando-os constantemente, é um fluxo contínuo de artefatos de software. Para que possamos sustentar esse fluxo constante de mudanças, precisamos de um protocolo comum pelo qual possamos nos comunicar sobre o que é um artefato de software, como ele é validado, que verificação ele passou. Isso é o que o projeto chamado . Portanto, um protocolo comum de metadados de artefatos de software.
E, finalmente, se quisermos que nossos sistemas sejam totalmente autônomos, adaptativos, auto-organizados, precisamos lhes dar o direito à autoidentificação. O projeto chamado é exatamente isso que faz. Este também é um projeto sob a égide da Cloud Native Computing Foundation.
Todos esses projetos são jovens, todos precisam do nosso amor, da nossa verificação. Todo esse código é aberto, nosso teste, nossa implementação. Eles nos mostram para onde a tecnologia está se movendo.
Mas DevOps nunca foi, em primeiro lugar, sobre tecnologia, sempre foi sobre colaboração entre pessoas. Portanto, se quisermos que os sistemas que desenvolvemos mudem, nós também devemos mudar. Na verdade, já estamos mudando, não temos muita escolha.
Há um maravilhoso livro da escritora britânica Rachel Botsman, no qual ela escreve sobre a evolução da confiança ao longo da história da humanidade. Ela afirma que, originalmente, em sociedades primitivas, a confiança era local, ou seja, confiávamos apenas naqueles que conhecíamos pessoalmente.
Depois, houve um longo período - uma era sombria, quando a confiança era centralizada, quando passamos a confiar em pessoas que não conhecíamos com base no fato de que pertencíamos a uma mesma instituição social ou estatal.
E eis o que vemos em nosso mundo moderno: a confiança está se tornando cada vez mais distribuída e descentralizada, baseada na liberdade dos fluxos de informação e na acessibilidade da informação.
Se pensarmos bem, essa mesma acessibilidade, que torna essa confiança possível, é algo que nós mesmos promovemos. Isso significa que a forma como colaboramos e como fazemos isso deve mudar, pois as organizações de TI centralizadas e hierárquicas do velho tipo estão perdendo eficácia. Elas começam a se extinguir.
Fundamentos das organizações DevOps
A organização DevOps ideal do futuro é um sistema descentralizado e adaptável, composto por equipes autônomas, cada uma formada por indivíduos autônomos. Essas equipes estão espalhadas pelo mundo, colaborando de forma eficaz umas com as outras por meio de comunicação assíncrona e protocolos de troca de informações altamente transparentes. Muito bonito, não é? Um futuro muito belo.
Claro, tudo isso é impossível sem mudanças culturais. Precisamos de uma liderança transformacional, responsabilidade pessoal e motivação interna.
Essa é a base das organizações DevOps: transparência da informação, comunicações assíncronas, liderança transformacional, descentralização.
Burnout
Os sistemas dos quais fazemos parte e aqueles que construímos estão se tornando cada vez mais caóticos, e nos, seres humanos, temos dificuldade em lidar com essa ideia, e é difícil abrir mão da ilusão de controle. Tentamos continuar a controlá-los, e isso muitas vezes leva ao burnout. Falo isso por experiência própria, eu também passei por isso, sou uma vítima de falhas imprevistas em produção.
O burnout ocorre quando tentamos controlar o que, por sua própria natureza, não pode ser controlado. Quando queimamos, tudo perde o sentido, porque perdemos o desejo de fazer algo novo, nos colocamos em uma posição defensiva e começamos a defender o que já temos.
A profissão de engenheiro, como eu gosto muitas vezes de me lembrar, é principalmente uma profissão criativa. Se perdemos o desejo de criar algo, nos transformamos em cinzas, nos tornamos poeira. Pessoas queimam, organizações inteiras queimam.
Na minha opinião, apenas a aceitação do poder criativo do caos, apenas a construção da cooperação com base em seus princípios — isso é o que nos ajudará a não perder o que há de bom em nossa profissão.
Isso é o que desejo a você: amar seu trabalho, amar o que fazemos. Este mundo se alimenta de informação, e temos a honra de alimentá-lo. Então, vamos estudar o caos, ser caologistas, trazer valor, criar algo novo, e os problemas, como já percebemos, são inevitáveis, e quando eles surgirem, diremos simplesmente 'Ops!', e o problema estará resolvido.
O que além do Chaos Monkey?
Na verdade, todas essas ferramentas são relativamente novas. A Netflix desenvolveu ferramentas para suas próprias necessidades. Construa ferramentas para você. Leia os princípios da engenharia do caos e siga esses princípios, ao invés de tentar encontrar outras ferramentas que alguém já criou.
Tente entender como seus sistemas falham e comece a causá-las para ver como eles suportam os impactos. Isso é o mais importante. As ferramentas podem ser pesquisadas. Existem vários projetos.
Não entendi muito bem o ponto que você mencionou sobre não simplificar um sistema, simplificando seus componentes, e logo em seguida falar sobre microserviços, que justamente simplificam o sistema ao simplificar os próprios componentes e complicar as interações. Esse são, na verdade, duas partes que se contradizem.
Exatamente, microserviços são um tema muito controverso. Na verdade, simplificar partes aumenta a flexibilidade. O que os microserviços nos oferecem? Eles nos dão flexibilidade e velocidade, mas definitivamente não nos proporcionam simplicidade. Eles aumentam a complexidade.
Então, na filosofia DevOps, os microserviços não são uma benção?
Qualquer benefício tem seu lado negativo. Há um benefício: isso aumenta a flexibilidade, nos permite fazer mudanças mais rapidamente, mas também aumenta a complexidade e, consequentemente, a fragilidade de todo o sistema.
No final, onde deve estar o foco: na simplificação das interações ou na simplificação das partes?
A ênfase, sem dúvida, está na simplificação da interação, porque se olharmos para isso em termos de como trabalhamos juntos, devemos, primeiro de tudo, prestar atenção na simplificação das interações, e não na simplificação do trabalho de cada um de nós separadamente. Porque simplificar o trabalho significa transformar as pessoas em robôs. Isso funciona bem no McDonald's, onde você tem a instrução: coloque o hambúrguer aqui, despeje o molho aqui. Isso não funciona de forma alguma no nosso trabalho criativo.
É verdade que tudo o que você descreveu vive em um mundo sem concorrência, e que lá o caos é tão benigno, sem contradições dentro desse caos, onde ninguém quer devorar ou matar ninguém? Como a concorrência e o DevOps devem coexistir?
Bem, depende de que tipo de concorrência estamos falando. Sobre a concorrência no local de trabalho ou a concorrência entre empresas?
Sobre a concorrência dos serviços que existem, porque os serviços não são várias empresas. Estamos criando um novo tipo de ambiente informativo, e qualquer ambiente não pode existir sem concorrência. Em toda parte há concorrência.
Tomemos a Netflix como exemplo de modelo. Eles inventaram isso por quê? Porque precisavam ser competitivos. Essa flexibilidade e velocidade de movimento são exatamente a exigência competitiva, trazendo um certo caos aos nossos sistemas. Ou seja, o caos não é algo que fazemos conscientemente porque queremos, mas é o que acontece porque o mundo exige isso. Temos que nos adaptar. E o caos, na verdade, é o resultado da concorrência.
Isso significa que o caos é uma ausência de metas, certo? Ou aquelas metas que não queremos ver? Estamos em nossa bolha e não entendemos as metas dos outros. A concorrência, na verdade, é possível porque temos metas bem definidas e sabemos aonde queremos chegar a cada momento seguinte. Para mim, essa é a essência do DevOps.
É uma maneira de ver a questão. Acredito que a nossa meta comum é: sobreviver e fazer isso com
a maior satisfação possível. E a meta competitiva de qualquer organização é a mesma. A sobrevivência muitas vezes ocorre em uma luta competitiva, não há muito o que fazer.
Neste ano, a conferência ocorrerá em 7 de dezembro no 'Tecnopólis'. Até 11 de novembro, estamos aceitando propostas para palestras. nós, se você quiser se apresentar.
As inscrições para os participantes estão abertas, o ingresso custa 7000 rublos. Junte-se a nós!
Fonte: habr.com
