O fundador e diretor da Otomato Software, um dos iniciadores e instrutores da primeira certificação de DevOps de Israel, Anton Weiss, falou sobre a teoria do caos e os princípios básicos da engenharia caótica no
DevOpsDays Moscow no ano passado e também explicou como funciona a organização ideal do futuro para o DevOps.
Preparamos uma versão em texto do relatório.
Bom dia
DevOpsDays em Moscou pelo segundo ano consecutivo, sou a segunda vez neste estágio, muitos de vocês são a segunda vez nesta sala. O que isso significa? Isso significa que o movimento DevOps na Rússia está crescendo, se multiplicando e, o que é mais importante, significa que é hora de falar sobre o que é DevOps em 2018.
Levante a mão quem pensa que em 2018 o DevOps já é uma profissão? Existem alguns. Existem engenheiros de DevOps na sala que têm o "engenheiro de DevOps" escrito na descrição da tarefa? Existem gerentes de DevOps na sala? Não há nenhum. Arquitetos DevOps? Também não. Não chega. Na verdade, o que ninguém escreveu que ele é um engenheiro de DevOps?
Então, a maioria de vocês acha que isso é antipadrão? O que não deveria ser uma profissão? Podemos pensar em qualquer coisa, mas por enquanto achamos que o setor está avançando solenemente para os sons do canal DevOps.
Quem ouviu falar sobre um novo tópico chamado DevDevOps? Essa é uma técnica tão nova, que permite uma cooperação eficaz entre desenvolvedores e devops. E não tão novo. A julgar pelo twitter, então há 4 anos começaram a falar sobre isso. E ainda o interesse por isso está crescendo e crescendo, ou seja, há um problema. O problema deve ser resolvido.
Somos pessoas criativas, então simplesmente não se acalme. Dizemos: DevOps não é uma palavra suficientemente abrangente; ainda não existem elementos suficientes e interessantes. E vamos aos nossos laboratórios secretos e começamos a produzir mutações interessantes: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
A lógica é ferro, certo? Nosso sistema de entrega não é funcional, nossos sistemas são instáveis e os usuários estão insatisfeitos, não temos tempo para lançar o software no prazo, não cabemos no orçamento. Como vamos resolver tudo isso? Vamos chegar a uma nova palavra! Terminará em Ops e o problema será resolvido.
Então, eu chamo essa abordagem - "Ops, e o problema está resolvido".
Tudo isso desvanece-se em segundo plano, se nos lembrarmos por que criamos tudo isso. Criamos todo esse DevOps para tornar a entrega de software e nosso próprio trabalho nesse processo desobstruídos, indolor, eficaz e, o mais importante, agradável.
O DevOps cresceu de dor. E estamos cansados de sofrer. E para que isso aconteça, contamos com práticas sempre-vivas: colaboração eficaz, práticas de fluxo e, o mais importante, pensamento sistêmico, porque sem ela, o DevOps não funciona.
O que é um sistema?
E se já estamos falando sobre pensamento sistêmico, vamos nos lembrar do que é um sistema.
Se você é um hacker revolucionário, o sistema é um mal claro para você. Esta é uma nuvem que paira sobre você e faz você fazer o que não deseja.
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 para as quais trabalhamos são sistemas. E o que estamos construindo é o que é chamado - o sistema.
Tudo isso faz parte de um grande sistema sociotecnológico. E somente se entendermos como esse sistema sociotecnológico funciona em conjunto, só então podemos realmente otimizar algo nesse assunto.
Do ponto de vista do pensamento sistêmico, um sistema possui várias propriedades interessantes. Em primeiro lugar, consiste em partes, o que significa que seu comportamento depende do comportamento das partes. Além disso, todas as suas partes também são interdependentes. Acontece que, quanto mais partes o sistema tem, mais difícil é entender ou prever seu comportamento.
Em termos de comportamento, há outro fato interessante. O sistema pode fazer algo que nenhuma de suas partes individuais pode fazer.
Como disse o Dr. Russell Akoff (um dos fundadores do pensamento sistêmico), isso é fácil de provar com a ajuda de um experimento mental. Por exemplo, quem na platéia pode escrever código? Muitas mãos, e isso é normal, porque esse é um dos requisitos básicos da nossa profissão. Você pode escrever e suas mãos podem escrever código separadamente de você? Há pessoas que dizem: "Minhas mãos não escrevem código, meu cérebro escreve código". O cérebro pode escrever código separadamente de você? Bem, provavelmente não.
O cérebro é uma máquina incrível, 10% de nós não sabemos como funciona lá, mas não pode funcionar separadamente do sistema que nosso corpo é. E isso é fácil de provar: abra sua caixa de caveira, tire seu cérebro dela, coloque-a na frente do computador, deixe-a tentar escrever algo simples. "Olá, mundo" em Python, por exemplo.
Se um sistema pode fazer algo que nenhuma de suas partes individualmente pode fazer, isso significa que seu comportamento não é determinado pelo comportamento de suas partes. E então o que é determinado por? É determinado pela interação entre essas partes. E, consequentemente, quanto mais partes, mais difícil a interação, mais difícil é entender e prever o comportamento do sistema. E isso torna esse sistema caótico, porque qualquer alteração menor e invisível aos olhos em qualquer parte do sistema pode levar a resultados completamente imprevisíveis.
Essa sensibilidade às condições iniciais foi descoberta e investigada pelo meteorologista americano Ed Lorenz. Posteriormente, foi chamado de "efeito borboleta" e levou ao desenvolvimento de um movimento de pensamento científico chamado "teoria do caos". Essa teoria se tornou uma das principais mudanças de paradigma na ciência do século XX.
Teoria do caos
As pessoas que estudam o caos se chamam caosologistas.
Na verdade, a razão para este relatório foi que, trabalhando com sistemas distribuídos complexos e grandes organizações internacionais, em algum momento percebi que é assim que me sinto. Eu sou um caosologista. Essa, em geral, é uma maneira engenhosa de dizer: "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 com tanta frequência, então também são caosologistas. Convido você para a guilda de caosologistas. Os sistemas que nós, queridos colegas de caosologistas, estudaremos, são chamados de "sistemas adaptativos complexos".
O que é adaptabilidade? Adaptabilidade significa que o comportamento individual e coletivo das partes em um sistema tão adaptativo muda e se auto-organiza, respondendo a eventos ou cadeias de micro-eventos no sistema. Ou seja, o sistema se adapta às mudanças através da auto-organização. E essa capacidade de auto-organização se baseia na cooperação voluntária e completamente descentralizada de agentes autônomos livres.
Outra propriedade interessante de tais sistemas é que eles são livremente escaláveis. Que nós, como caosologistas-engenheiros, sem dúvida devemos ser de interesse. Então, se dissemos que o comportamento de um sistema complexo é determinado pela interação de suas partes, o que deveria nos interessar? Interação.
Há mais duas conclusões interessantes.
Primeiro, entendemos que um sistema complexo não pode ser simplificado, simplificando suas partes. Em segundo lugar, a única maneira de simplificar um sistema complexo é simplificar as interações entre suas partes.
Como interagimos? Todos fazemos parte de um grande sistema de informação chamado sociedade humana. Interagimos através de uma linguagem comum, se a tivermos, se a encontrarmos.
Mas a própria linguagem é um sistema adaptativo complexo. Portanto, para interagir de maneira mais eficiente e simples, precisamos criar algum tipo de protocolo. Ou seja, alguma sequência de símbolos e ações que tornarão a troca de informações entre nós mais simples, previsível e compreensível.
Quero dizer que as tendências à complicação, à adaptabilidade, à descentralização, à aleatoriedade estão localizadas em tudo. E naqueles sistemas que estamos construindo, e naqueles sistemas dos quais fazemos parte.
E, para não ser infundado, vejamos como os sistemas que criamos estão mudando.
Você estava esperando por essa palavra, eu entendo. Estamos na conferência do DevOps, hoje essa palavra soará em algum lugar centenas de milhares de vezes e depois sonharemos à noite.
Microservices é a primeira arquitetura de software que surgiu como uma reação às práticas de DevOps, projetada para tornar nossos sistemas mais flexíveis, escaláveis e garantir a entrega contínua. Como ela faz isso? Reduzindo o volume de serviços, reduzindo os limites dos problemas que esses serviços processam, reduzindo o tempo de entrega. Ou seja, reduzimos, simplificamos partes do sistema, aumentamos seu número, consequentemente, a complexidade das interações entre essas partes aumenta constantemente, ou seja, surgem novos problemas que precisamos resolver.
Os microsserviços não são o fim, os microsserviços são, em geral, já ontem, porque o Serverless está chegando. Todos os servidores queimados, sem servidores, sem sistemas operacionais, apenas código executável limpo. A configuração é separada, o estado é separado, tudo é orientado a eventos. Beleza, pureza, silêncio, sem eventos, nada acontece, ordem completa.
Onde está a dificuldade? Complexidade, é claro, nas interações. Quanto uma função pode fazer sozinha? Como ele interage com outras funções? Filas de mensagens, bancos de dados, balanceadores. Como recriar um evento quando ocorre uma falha? Um monte de perguntas e poucas respostas.
Microsserviços e sem servidor são tudo o que chamamos de descolados de computadores em Cloud Native. É tudo sobre a nuvem. Mas a nuvem também é essencialmente escalável. Estamos acostumados a pensar nisso como um sistema distribuído. De fato, onde vivem os servidores do provedor de nuvem? Nos data centers. Ou seja, aqui temos um certo modelo distribuído centralizado, muito limitado.
Hoje entendemos que a Internet das coisas não é mais apenas palavras grandes que, mesmo de acordo com previsões conservadoras, bilhões de dispositivos conectados à Internet nos aguardam nos próximos cinco a dez anos. Uma enorme quantidade de dados úteis e inúteis que serão mesclados na nuvem e inundados da nuvem.
Como a nuvem não suporta, estamos cada vez mais falando sobre o que é chamado de "computação periférica". Ou também gosto da maravilhosa definição de computação em neblina. Está esfarrapado com o misticismo do romantismo e do mistério.
Computação enevoada. O ponto é que as nuvens são coágulos centralizados de água, vapor, gelo e pedras. E o nevoeiro são gotículas de água espalhadas à nossa volta na atmosfera.
Em um paradigma nebuloso, a maior parte do trabalho é realizada por essas gotículas de forma totalmente autônoma ou em colaboração com outras gotículas. E eles se voltam para a nuvem apenas quando realmente o fazem.
Isso é, novamente, descentralização, autonomia e, é claro, muitos de vocês já entendem do que se trata, porque não podem falar sobre descentralização e não mencionar a blockchain.
Há quem acredite, esses são os que investiram em criptomoedas. Há quem acredite, mas tenha medo, como eu, por exemplo. E há quem não acredite. Aqui você pode se relacionar de maneira diferente. Existe tecnologia, um novo negócio incompreensível, há problemas. Como qualquer nova tecnologia, ela levanta mais perguntas do que respostas.
O hype em torno da blockchain é compreensível. Mesmo se você deixar de lado a corrida do ouro, a própria tecnologia faz promessas maravilhosas de um futuro melhor: mais liberdade, mais autonomia, confiança global distribuída. O que há para não querer?
Assim, mais e mais engenheiros em todo o mundo estão começando a desenvolver aplicativos descentralizados. E essa é uma força que não pode ser descartada simplesmente dizendo: "Ahh, o blockchain é apenas um banco de dados distribuído mal implementado". Ou como os céticos gostam de dizer: "Não há usos reais para o blockchain". Se você pensar bem, há 150 anos eles disseram a mesma coisa sobre eletricidade. E mesmo em alguns aspectos, eles estavam certos, porque o que a eletricidade possibilita hoje no século 19 era completamente irrealista de qualquer forma.
A propósito, quem sabe que tipo de logotipo existe na tela? Este é o Hyperledger. Este é um projeto que está sendo desenvolvido sob os auspícios da The Linux Foundation, que inclui um conjunto de tecnologias blockchain. Este é realmente o poder da nossa comunidade de código aberto.
Engenharia do Caos
Portanto, o sistema que estamos desenvolvendo está se tornando mais complexo, mais caótico, mais adaptável. Netflix - pioneiros em sistemas de microsserviços. Eles foram um dos primeiros a entender isso, eles desenvolveram um kit de ferramentas chamado Exército Simian, o mais famoso dos quais foi o
Chaos Monkey . Ele definiu o que ficou conhecido como
"princípios da engenharia do caos" .
A propósito, no processo de elaboração do relatório, traduzimos esse texto para o russo, então acesse o
link , leia, comente, repreenda.
Resumidamente, os princípios da engenharia do caos indicam o seguinte. Sistemas distribuídos complexos são inerentemente imprevisíveis e inerentemente possuem erros. Erros são inevitáveis, o que significa que precisamos aceitar esses erros e trabalhar com esses sistemas de uma maneira completamente diferente.
Nós mesmos devemos tentar introduzir esses erros em nossos sistemas de produção, a fim de testar nossos sistemas quanto a essa adaptabilidade, à capacidade de se auto-organizar e sobreviver.
E isso muda tudo. Não apenas como executamos o sistema em produção, mas também como os desenvolvemos, como os testamos. Não há processo de estabilização, congelamento de código, pelo contrário, há um processo constante de desestabilização. Estamos tentando matar o sistema e ver que ele continua a sobreviver.
Protocolos de integração de sistema distribuído
Consequentemente, isso exige que nossos sistemas também mudem de alguma forma. Para que se tornem mais estáveis, eles precisam de alguns novos protocolos de interação entre suas partes. Para que essas partes possam negociar e chegar a algum tipo de auto-organização. E existem todo tipo de novas ferramentas, novos protocolos, que eu chamo de "protocolos para a interação de sistemas distribuídos".
Do que estou falando? Primeiro, o projeto
Opentracing . Alguns tentam criar um protocolo comum para rastreamento distribuído, que é uma ferramenta absolutamente indispensável para depurar sistemas distribuídos complexos.
Em seguida é o
Open Policy Agent . Dizemos que não podemos prever o que acontecerá com o sistema, ou seja, precisamos aumentar sua observabilidade, observabilidade. Opentracing é uma família de ferramentas que dão observabilidade aos nossos sistemas. Mas precisamos de observabilidade para determinar se o sistema se comporta como esperamos ou não. Como determinamos o comportamento esperado? Ao definir nele algum tipo de política, algum tipo de conjunto de regras. O projeto Open Policy Agent está definindo esse conjunto de regras em uma ampla variedade: do acesso à alocação de recursos.
Como dissemos, nossos sistemas são cada vez mais orientados a eventos. Sem servidor é um ótimo exemplo de sistemas orientados a eventos. Para transmitir eventos entre sistemas e rastreá-los, precisamos de uma linguagem comum, algum protocolo comum de como falamos sobre eventos, como os transmitimos um ao outro. Este é um projeto chamado
Cloudevents .
O fluxo contínuo de mudanças que lava nossos sistemas, desestabilizando-os constantemente, é um fluxo contínuo de artefatos de software. Para podermos manter esse fluxo constante de mudanças, precisamos de um protocolo geral com o qual possamos falar sobre o que é um artefato de software, como é verificado, que verificação foi aprovada. Este é um projeto chamado
Grafeas . Ou seja, um protocolo comum de metadados de artefatos de software.
E, finalmente, se queremos que nossos sistemas sejam completamente independentes, adaptáveis e auto-organizados, devemos dar-lhes o direito à auto-identificação. Um projeto chamado
spiffe faz exatamente isso. Este também é um projeto patrocinado pela Cloud Native Computing Foundation.
Todos esses projetos são jovens, todos precisam do nosso amor, do nosso teste. Tudo isso é open source, nossos testes, nossa implementação. Eles nos mostram para que lado a tecnologia está se movendo.
Mas o DevOps nunca foi principalmente sobre tecnologia, mas sempre sobre colaboração entre pessoas. E, consequentemente, se queremos que os sistemas que desenvolvemos mudem, devemos mudar a nós mesmos. De fato, já estamos mudando, não temos escolha em particular.
Há um
livro maravilhoso
da escritora britânica Rachel Botsman no qual ela escreve sobre a evolução da confiança ao longo da história humana. Ela diz que, inicialmente, nas sociedades primitivas, a confiança era local, ou seja, confiamos apenas naqueles que conhecemos pessoalmente.
Houve um período muito longo - um período sombrio, em que a confiança era centralizada, quando começamos a confiar em pessoas que não conhecíamos, com base em que pertencemos à mesma instituição pública ou estatal.
E aqui está o que vemos em nosso mundo moderno: a confiança está se tornando cada vez mais distribuída e descentralizada, e é baseada nos fluxos de liberdade de informação, na disponibilidade de informações.
Se você pensar bem, essa mesma acessibilidade que possibilita essa confiança é o que estamos implementando.
Isso significa que a maneira como trabalhamos e a maneira como fazemos deve mudar, porque as organizações hierárquicas centralizadas de TI do tipo antigo param de funcionar. Eles começam a morrer.Noções básicas da organização DevOps
A organização ideal do DevOps para o futuro é um sistema adaptativo e descentralizado, composto por equipes autônomas, cada uma das quais composta por indivíduos autônomos. Essas equipes estão espalhadas por todo o mundo, elas efetivamente cooperam entre si usando comunicação assíncrona, usando protocolos de comunicação altamente transparentes. Muito linda né Um futuro muito bonito.Claro, tudo isso é impossível sem mudança cultural. Devemos ter liderança transformacional, responsabilidade pessoal, motivação interna.
Essa é a base das organizações do DevOps: transparência das informações, comunicações assíncronas, liderança transformacional, descentralização.Burnout
Os sistemas dos quais fazemos parte e aqueles que construímos são cada vez mais caóticos, e é difícil para nós, pessoas, lidar com essa idéia e abandonar a ilusão de controle. Tentamos continuar a controlá-los, e isso geralmente leva ao esgotamento. Digo isso por experiência própria, também me queimei, também desabilitei em falhas imprevistas de produção.
O esgotamento ocorre quando tentamos controlar algo que, em essência, não pode ser controlado. Quando nos esgotamos, tudo perde seu significado, porque perdemos o desejo de fazer algo novo, assumimos uma posição defensiva e começamos a defender o que é.A profissão de engenheiro, como gosto muitas vezes de me lembrar, é principalmente uma profissão criativa. Se perdermos o desejo de criar algo, então nos transformamos em cinzas, transformamos em cinzas. Pessoas se esgotam, organizações inteiras se esgotam.Na minha opinião, apenas aceitar o poder criativo do caos, apenas construir cooperação com base em seus princípios é o que nos ajuda a não perder o bem que existe em nossa profissão.O que eu quero para você: amar o meu trabalho, amar o que fazemos. Este mundo se alimenta de informações, temos a honra de alimentá-lo. Então, vamos estudar o caos, seremos caosologistas, agregaremos valor, criaremos algo novo, bem, e os problemas, como já descobrimos, são inevitáveis e, quando aparecerem, simplesmente diremos "Ops!", E o problema está resolvido.O que além do macaco do caos?De fato, todas essas ferramentas são muito novas. Esses Netflix construíram ferramentas para si mesmos. Crie ferramentas para si mesmo. Leia os princípios da engenharia do caos e cumpra-os, e não tente procurar outras ferramentas que outra pessoa já tenha construído.Tente entender como seus sistemas quebram e comece a quebrá-los e observe como eles suportam impactos. Isso é antes de tudo. E você pode procurar por ferramentas. Existem todos os tipos de projetos.Eu não entendi direito o momento em que você disse que o sistema não pode ser simplificado simplificando seus componentes e imediatamente mudou para microsserviços, que simplificam o sistema simplificando os próprios componentes e complicando as interações. Estas são essencialmente duas partes que se contradizem.É isso mesmo, os microsserviços são um tópico muito controverso em geral. De fato, simplificar as peças aumenta a flexibilidade. O que os microsserviços fornecem? Eles nos dão flexibilidade e velocidade, mas certamente não nos dão simplicidade de forma alguma. Eles aumentam a complexidade.Ou seja, na filosofia do DevOps, os microsserviços não são uma bênção?Qualquer bem tem um lado errado. Há um benefício: aumenta a flexibilidade, nos dá a capacidade de fazer alterações mais rapidamente, mas aumenta a complexidade e, consequentemente, a fragilidade de todo o sistema.Ainda, o que é mais ênfase: simplificação da interação ou simplificação de partes?A ênfase está, sem dúvida, na simplificação da interação, porque se a analisarmos do ponto de vista de como trabalhamos com você, primeiro precisamos prestar atenção à simplificação das interações, e não simplificar o trabalho de cada um de nós separadamente. Porque a simplificação do trabalho está se transformando em robôs. Mas no McDonald's funciona bem quando é prescrito para você: aqui você coloca o hambúrguer, aqui você coloca molho sobre ele. Isso em nosso trabalho criativo não funciona.É verdade que tudo o que você disse vive em um mundo sem competição, e o caos é tão gentil, e não há contradições nesse caos, ninguém quer comer, matar alguém? Como a concorrência e o DevOps devem viver?Bem, depende de que tipo de competição estamos falando. Concorrência no local de trabalho ou concorrência entre empresas?Sobre a concorrência de serviços que existem, porque serviços não são poucas empresas. Estamos criando um novo tipo de ambiente de informações e qualquer ambiente não pode viver sem concorrência. Em todos os lugares há concorrência.O mesmo Netflix, nós os levamos para um modelo. Por que eles inventaram isso? Porque eles precisavam ser competitivos. Essa flexibilidade e velocidade de movimento, é precisamente esse requisito muito competitivo, introduz aleatoriedade em nossos sistemas. Ou seja, o caos não é o que conscientemente fazemos, porque o queremos, é o que acontece porque o mundo exige. Nós apenas temos que nos adaptar. E caos, é apenas o resultado da competição.Isso significa que o caos é uma falta de objetivos? Ou aqueles objetivos que não queremos ver? Estamos em casa e não entendemos os objetivos dos outros. A competição, de fato, deve-se ao fato de termos objetivos claros e sabemos aonde chegaremos a cada momento seguinte. Nisto, do meu ponto de vista, a essência do DevOps.Também uma olhada na pergunta. Penso que todos temos um objetivo: sobreviver e fazê-lo com omaior prazer. E o objetivo competitivo de qualquer organização é o mesmo. A sobrevivência é comum em competição, não há nada a ser feito.Este ano, a conferência DevOpsDays Moscow será realizada em 7 de dezembro em Technopolis. Até 11 de novembro, aceitamos solicitações de relatórios. Envie- nos se você quiser falar.
As inscrições para os participantes estão abertas, um ingresso custa 7.000 rublos. Inscreva-se agora!