Anton Weiss, fundador e diretor da Otomato Software, um dos iniciadores e instrutores da primeira certificação DevOps em Israel, falou no ano passado sobre a teoria do caos e os princípios básicos da engenharia do caos, e também explicou como funciona a organização DevOps ideal do futuro.
Preparamos uma versão em texto do relatório.
Bom dia!
DevOpsDays em Moscou pelo segundo ano consecutivo, esta é minha segunda vez neste palco, muitos de vocês estão nesta sala pela segunda vez. O que isso significa? Isso significa que o movimento DevOps na Rússia está crescendo, se multiplicando e, o mais importante, significa que chegou a hora de falar sobre o que é DevOps em 2018.
Levanta a mão quem pensa que DevOps já é profissão em 2018? Existem tais. Há algum engenheiro de DevOps na sala cuja descrição de trabalho diz “Engenheiro de DevOps”? Há algum gerente de DevOps na sala? Não existe tal. Arquitetos DevOps? Também não. Insuficiente. É realmente verdade que ninguém diz que é engenheiro de DevOps?
Então a maioria de vocês acha que isso é um antipadrão? Que tal profissão não deveria existir? Podemos pensar o que quisermos, mas enquanto pensamos, a indústria avança solenemente ao som da trombeta do DevOps.
Quem já ouviu falar de um novo tópico chamado DevDevOps? Esta é uma nova técnica que permite uma colaboração eficaz entre desenvolvedores e devops. E não é tão novo. A julgar pelo Twitter, já começaram a falar sobre isso há 4 anos. E até agora o interesse por isso está crescendo cada vez mais, ou seja, há um problema. O problema precisa ser resolvido.
Somos pessoas criativas, não apenas descansamos. Dizemos: DevOps não é uma palavra suficientemente abrangente; ainda carece de todos os tipos de elementos diferentes 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 é rígida, certo? Nosso sistema de entrega não funciona, nossos sistemas são instáveis e nossos usuários estão insatisfeitos, não temos tempo para lançar o software a tempo, não cabemos no orçamento. Como vamos resolver tudo isso? Vamos inventar uma nova palavra! Terminará com "Ops" e o problema estará resolvido.
Então eu chamo essa abordagem de “Ops, e o problema está resolvido”.
Tudo isso fica em segundo plano se nos lembrarmos por que inventamos tudo isso. Criamos toda essa coisa de DevOps para tornar a entrega de software e nosso próprio trabalho nesse processo o mais desimpedido, indolor, eficiente e, o mais importante, agradável possível.
O DevOps surgiu da dor. E estamos cansados de sofrer. E para que tudo isso aconteça, contamos com práticas perenes: colaboração eficaz, práticas de fluxo e, o mais importante, pensamento sistêmico, porque sem ele nenhum DevOps 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, então para você o sistema é claramente mau. É uma nuvem que paira sobre você e o força a fazer coisas que você não quer.
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 o que você e eu estamos construindo é chamado de sistema.
Tudo isso faz parte de um grande sistema sociotecnológico. E só se entendermos como funciona este sistema sociotecnológico em conjunto, só então poderemos realmente otimizar algo nesta matéria.
Do ponto de vista do pensamento sistêmico, um sistema possui várias propriedades interessantes. Primeiro, consiste em partes, o que significa que o seu comportamento depende do comportamento das partes. Além disso, todas as suas partes também são interdependentes. Acontece que quanto mais peças um sistema tiver, mais difícil será compreender ou prever seu comportamento.
Do ponto de vista comportamental, há outro fato interessante. O sistema pode fazer algo que nenhuma de suas partes individuais pode fazer.
Como disse o Dr. Russell Ackoff (um dos fundadores do pensamento sistêmico), isso é muito fácil de provar com um experimento mental. Por exemplo, quem na sala sabe escrever código? São muitas mãos, e isso é normal, porque esse é um dos principais requisitos da nossa profissão. Você sabe escrever, mas suas mãos conseguem escrever código separadamente de você? Tem gente que dirá: “Não são minhas mãos que escrevem o código, é meu cérebro que escreve o código”. Seu cérebro pode escrever código separadamente de você? Bem, provavelmente não.
O cérebro é uma máquina incrível, não sabemos nem 10% de como ele funciona ali, mas não pode funcionar separado do sistema que é o nosso corpo. E isso é fácil de provar: abra o crânio, tire o cérebro, coloque na frente do computador, deixe-o tentar escrever algo simples. “Olá, mundo” em Python, por exemplo.
Se um sistema pode fazer algo que nenhuma de suas partes pode fazer separadamente, isso significa que seu comportamento não é determinado pelo comportamento de suas partes. Pelo que então é determinado? É determinado pela interação entre essas partes. E, consequentemente, quanto mais peças, mais complexas são as interações, mais difícil é compreender e prever o comportamento do sistema. E isso torna esse sistema caótico, porque qualquer mudança invisível, mesmo a mais insignificante, em qualquer parte do sistema pode levar a resultados completamente imprevisíveis.
Esta sensibilidade às condições iniciais foi descoberta e estudada pela primeira vez pelo meteorologista americano Ed Lorenz. Posteriormente, foi chamado de “efeito borboleta” e levou ao desenvolvimento de um movimento de pensamento científico denominado “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 autodenominam caosologistas.
Na verdade, a razão deste 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 caosólogo. Esta é basicamente uma maneira inteligente de dizer: “Não entendo o que está acontecendo aqui e não sei o que fazer a respeito”.
Acho que muitos de vocês também se sentem assim com frequência, então também são caosólogos. Convido você para a guilda dos caosologistas. Os sistemas que você e eu, queridos colegas caosólogos, estudaremos são chamados de “sistemas adaptativos complexos”.
O que é adaptabilidade? Adaptabilidade significa que o comportamento individual e coletivo das partes de tal sistema adaptativo muda e se auto-organiza, respondendo a eventos ou cadeias de microeventos no sistema. Ou seja, o sistema se adapta às mudanças por meio da auto-organização. E esta capacidade de auto-organização baseia-se 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. O que sem dúvida deveria nos interessar, como engenheiros-caosólogos. Então, se disséssemos que o comportamento de um sistema complexo é determinado pela interação de suas partes, então em que deveríamos estar interessados? Interação.
Existem mais duas descobertas interessantes.
Primeiro, 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 é simplificar as interações entre as suas partes.
Como interagimos? Você e eu somos partes 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. Assim, para interagir de forma 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, mais previsível, mais compreensível.
Quero dizer que as tendências para a complexidade, para a adaptabilidade, para a descentralização, para o caos podem ser detectadas em tudo. E nos sistemas que você e eu estamos construindo e nos sistemas dos quais fazemos parte.
E para não ser infundado, vejamos como os sistemas que criamos estão a mudar.
Você estava esperando por essa palavra, eu entendo. Estamos em uma conferência DevOps, hoje essa palavra será ouvida cerca de cem mil vezes e depois sonharemos com ela à noite.
Os microsserviços são a primeira arquitetura de software que surgiu como reação às práticas de DevOps, projetada para tornar nossos sistemas mais flexíveis, mais escaláveis e garantir entrega contínua. Como ela faz isso? Ao reduzir o volume de serviços, diminuindo a abrangência dos problemas que esses serviços processam, reduzindo o tempo de entrega. Ou seja, reduzimos e simplificamos partes do sistema, aumentamos o seu número e, consequentemente, a complexidade das interações entre essas partes aumenta invariavelmente, ou seja, surgem novos problemas que temos que resolver.
Os microsserviços não são o fim, os microsserviços, em geral, já são ontem, porque o Serverless está chegando. Todos os servidores foram incendiados, nenhum servidor, nenhum sistema operacional, apenas puro código executável. As configurações são separadas, os estados são separados, tudo é controlado por eventos. Beleza, limpeza, silêncio, nenhum acontecimento, nada acontece, ordem completa.
Onde está a complexidade? A dificuldade, claro, está 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 algum evento quando ocorreu uma falha? Muitas perguntas e poucas respostas.
Microsserviços e Serverless são o que nós, geeks descolados, chamamos de Cloud Native. É tudo uma questão de nuvem. Mas a nuvem também é inerentemente limitada na sua escalabilidade. Estamos acostumados a pensar nele como um sistema distribuído. Na verdade, onde ficam os servidores dos provedores de nuvem? Em data centers. Ou seja, temos aqui uma espécie de modelo centralizado, muito limitado, distribuído.
Hoje entendemos que a Internet das Coisas não é mais apenas palavrões que, mesmo de acordo com previsões modestas, 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 carregados da nuvem.
A nuvem não vai durar, por isso falamos cada vez mais sobre algo chamado edge computing. Ou também gosto da maravilhosa definição de “computação em neblina”. Está envolto no misticismo do romantismo e do mistério.
Computação em nevoeiro. A questão é que as nuvens são aglomerados centralizados de água, vapor, gelo e pedras. E a neblina são gotículas de água que estão espalhadas ao nosso redor na atmosfera.
No paradigma da neblina, 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 recorrem à nuvem apenas quando realmente ficam pressionados.
Ou seja, novamente descentralização, autonomia e, claro, muitos de vocês já entendem para onde tudo isso vai dar, porque não se pode falar em descentralização sem mencionar o blockchain.
Há quem acredite, são aqueles que investiram em criptomoeda. Há quem acredite mas tenha medo, como eu, por exemplo. E há quem não acredite. Aqui você pode tratar de forma diferente. Existe tecnologia, um novo assunto desconhecido, existem problemas. Como qualquer nova tecnologia, levanta mais questões do que respostas.
O hype em torno do blockchain é compreensível. Deixando de lado a corrida do ouro, a própria tecnologia contém promessas notáveis para um futuro melhor: mais liberdade, mais autonomia, confiança global distribuída. O que há para não querer?
Conseqüentemente, cada vez mais engenheiros em todo o mundo estão começando a desenvolver aplicações descentralizadas. E este é um poder que não pode ser descartado simplesmente dizendo: “Ahh, blockchain é apenas um banco de dados distribuído mal implementado”. Ou como os céticos gostam de dizer: “Não existem aplicações reais para blockchain”. Se você pensar bem, há 150 anos eles disseram a mesma coisa sobre eletricidade. E tinham até razão em alguns aspectos, porque o que a electricidade torna possível hoje não era de forma alguma possível no século XIX.
Aliás, quem sabe que tipo de logotipo está na tela? Este é o Hyperledger. Este é um projeto que está sendo desenvolvido sob os auspícios da The Linux Foundation e inclui um conjunto de tecnologias blockchain. Esta é verdadeiramente a força da nossa comunidade de código aberto.
Engenharia do Caos
Assim, o sistema que estamos a desenvolver está a tornar-se cada vez mais complexo, cada vez mais caótico e cada vez mais adaptativo. A Netflix é pioneira em sistemas de microsserviços. Eles foram os primeiros a entender isso, desenvolveram um conjunto de ferramentas que chamaram de Exército Símio, o mais famoso dos quais foi . Ele definiu o que ficou conhecido como .
A propósito, no processo de trabalho no relatório, até traduzimos este texto para o russo, então vá para , leia, comente, repreenda.
Resumidamente, os princípios da engenharia do caos dizem o seguinte. Sistemas distribuídos complexos são inerentemente imprevisíveis e cheios de bugs. Os erros são inevitáveis, o que significa que precisamos de aceitar estes erros e trabalhar com estes sistemas de uma forma completamente diferente.
Nós próprios devemos tentar introduzir estes erros nos nossos sistemas de produção, a fim de testar os nossos sistemas quanto a esta mesma adaptabilidade, esta mesma capacidade de auto-organização, de sobrevivência.
E isso muda tudo. Não apenas como lançamos sistemas em produção, mas também como os desenvolvemos, como os testamos. Não há processo de estabilização ou congelamento do código; pelo contrário, há um processo constante de desestabilização. Estamos tentando matar o sistema e vê-lo continuar a sobreviver.
Protocolos de integração de sistemas distribuídos
Conseqüentemente, isso exige que nossos sistemas 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 concordar e chegar a algum tipo de auto-organização. E surgem todos os tipos de novas ferramentas, novos protocolos, que chamo de “protocolos para a interação de sistemas distribuídos”.
Do que estou falando? Primeiro, o projeto . Alguns tentam criar um protocolo geral de rastreamento distribuído, que é uma ferramenta absolutamente indispensável para depurar sistemas distribuídos complexos.
Mais longe - . Dizemos que não podemos prever o que vai acontecer com o sistema, ou seja, precisamos aumentar a sua observabilidade, a observabilidade. Opentracing pertence a 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 definimos o comportamento esperado? Definindo algum tipo de política, algum conjunto de regras. O projecto Open Policy Agent dedica-se a definir este conjunto de regras num espectro que vai desde o acesso à atribuição de recursos.
Como dissemos, nossos sistemas são cada vez mais orientados a eventos. Serverless é um ótimo exemplo de sistemas orientados a eventos. Para podermos transferir eventos entre sistemas e rastreá-los, precisamos de alguma linguagem comum, de algum protocolo comum sobre como falamos sobre eventos, como os transmitimos uns aos outros. Isto é o que um projeto chamado .
O fluxo constante de mudanças que atinge nossos sistemas, desestabilizando-os constantemente, é um fluxo contínuo de artefatos de software. Para mantermos esse fluxo constante de mudanças, precisamos de algum tipo de protocolo comum através do qual possamos falar sobre o que é um artefato de software, como ele é testado, por qual verificação ele passou. Isto é o que um projeto chamado . Ou seja, um protocolo de metadados comum para artefatos de software.
E, finalmente, se quisermos que os nossos sistemas sejam completamente independentes, adaptáveis e auto-organizados, devemos dar-lhes o direito à auto-identificação. Projeto chamado Isso é exatamente o que ele faz. Este também é um projeto sob os auspícios da Cloud Native Computing Foundation.
Todos esses projetos são jovens, todos precisam do nosso amor, da nossa validação. Tudo isso é código aberto, nossos testes, nossa implementação. Eles nos mostram para onde a tecnologia está caminhando.
Mas o DevOps nunca foi principalmente uma questão de tecnologia, sempre foi uma questão de colaboração entre pessoas. E, consequentemente, se quisermos que os sistemas que desenvolvemos mudem, então nós próprios devemos mudar. Na verdade, estamos mudando de qualquer maneira; não temos muita escolha.
Há um maravilhoso A escritora britânica Rachel Botsman, na qual 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, confiávamos apenas em quem conhecemos pessoalmente.
Depois houve um período muito longo - uma época sombria em que a confiança estava centralizada, em que começámos a confiar em pessoas que não conhecemos com base no facto de pertencermos à mesma instituição pública ou estatal.
E é isto que vemos no nosso mundo moderno: a confiança está a tornar-se cada vez mais distribuída e descentralizada, e baseia-se na liberdade dos fluxos de informação, na disponibilidade de informação.
Se você pensar bem, essa mesma acessibilidade, que torna essa confiança possível, é o que você e eu estamos implementando. Isto significa que tanto a forma como colaboramos como a forma como o fazemos devem mudar, porque as antigas organizações de TI centralizadas e hierárquicas já não funcionam. Eles começam a morrer.
Fundamentos da organização DevOps
A organização DevOps ideal do futuro é um sistema descentralizado e adaptativo composto por equipes autônomas, cada uma composta por indivíduos autônomos. Estas equipas estão espalhadas por todo o mundo, colaborando eficazmente entre si através de comunicação assíncrona, utilizando protocolos de comunicação altamente transparentes. Muito lindo, não é? Um futuro muito lindo.
É claro que nada disto é possível sem uma mudança cultural. Devemos ter liderança transformacional, responsabilidade pessoal, motivação interna.
Esta é 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 cada vez mais caóticos, e é difícil para nós, humanos, lidar com este pensamento, é difícil abrir mão da ilusão de controle. Tentamos continuar a controlá-los e isso muitas vezes leva ao esgotamento. Digo isso por experiência própria, também me queimei, também fiquei incapacitado por falhas imprevistas na produção.
O esgotamento ocorre quando tentamos controlar algo que é inerentemente incontrolável. Quando nos esgotamos, tudo perde o sentido porque perdemos a vontade de fazer algo novo, ficamos na defensiva e passamos a defender o que temos.
A profissão de engenheiro, como sempre gosto de me lembrar, é antes de tudo uma profissão criativa. Se perdermos o desejo de criar algo, viramos cinzas, viramos cinzas. Pessoas se esgotam, organizações inteiras se esgotam.
Na minha opinião, só aceitar o poder criativo do caos, só construir a cooperação de acordo com os seus princípios é o que nos ajudará a não perder o que há de bom na nossa profissão.
É isso que desejo para você: que ame o seu trabalho, que ame o que fazemos. Este mundo se alimenta de informação, temos a honra de alimentá-lo. Então vamos estudar o caos, vamos ser caosólogos, vamos agregar valor, criar algo novo, enfim, os problemas, como já descobrimos, são inevitáveis, e quando eles aparecerem, simplesmente diremos “Ops!”, e o problema está resolvido .
O que além do Macaco do Caos?
Na verdade, todos estes instrumentos são muito jovens. A mesma Netflix construiu ferramentas para si. Construa suas próprias ferramentas. Leia os princípios da engenharia do caos e viva de acordo com esses princípios, em vez de tentar encontrar outras ferramentas que alguém já construiu.
Tente entender como seus sistemas falham e comece a decompô-los e veja como eles se comportam. Isto vem primeiro. E você pode procurar ferramentas. Existem todos os tipos de projetos.
Não entendi muito bem o momento em que você disse que o sistema não pode ser simplificado simplificando seus componentes, e imediatamente passou para os 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, microsserviços são um tema muito controverso em geral. Na verdade, simplificar as peças aumenta a flexibilidade. O que os microsserviços oferecem? Dão-nos flexibilidade e rapidez, mas certamente não nos dão simplicidade. Eles aumentam a dificuldade.
Então, na filosofia DevOps, os microsserviços não são uma coisa tão boa?
Qualquer bem tem um reverso. A vantagem é que aumenta a flexibilidade, permitindo-nos fazer alterações mais rapidamente, mas aumenta a complexidade e, portanto, a fragilidade de todo o sistema.
Ainda assim, o que dá mais ênfase: na simplificação da interação ou na simplificação das partes?
A ênfase, claro, está na simplificação das interações, porque se olharmos para isso do ponto de vista de como trabalhamos com vocês, então, antes de tudo, precisamos prestar atenção à simplificação das interações, e não à simplificação do trabalho. de cada um de nós separadamente. Porque simplificar o trabalho significa transformar-se em robôs. Aqui no McDonald's funciona normalmente quando você tem instruções: aqui você coloca o hambúrguer, aqui você despeja o molho. Isso não funciona em nosso trabalho criativo.
É verdade que tudo o que você disse vive em um mundo sem competição, e o caos lá é tão bom, e não há contradições dentro desse caos, ninguém quer comer ou matar ninguém? Como a concorrência e o DevOps devem se comportar?
Bem, depende de que tipo de competição estamos falando. Trata-se de concorrência no local de trabalho ou de concorrência entre empresas?
Sobre a concorrência de serviços que existe porque os serviços não são várias empresas. Estamos a criar um novo tipo de ambiente de informação e qualquer ambiente não pode viver sem concorrência. Há concorrência em todos os lugares.
O mesmo Netflix, nós os tomamos como modelo. Por que eles inventaram isso? Porque eles precisavam ser competitivos. Esta flexibilidade e velocidade de movimento são precisamente o requisito muito competitivo; introduzem o caos nos nossos sistemas. Ou seja, o caos não é algo que fazemos conscientemente porque queremos, é algo que acontece porque o mundo exige. Só temos que nos adaptar. E o caos é justamente o resultado da competição.
Isso significa que o caos é a ausência de objetivos, por assim dizer? Ou aqueles objetivos que não queremos ver? Estamos em casa e não entendemos os objetivos dos outros. A competição, na verdade, se deve ao fato de termos objetivos claros e sabermos onde iremos parar a cada momento seguinte. Esta, do meu ponto de vista, é a essência do DevOps.
Também dê uma olhada na pergunta. Penso que todos temos o mesmo objectivo: sobreviver e fazê-lo com
maior prazer. E o objetivo competitivo de qualquer organização é o mesmo. A sobrevivência geralmente ocorre por meio da competição, não há nada que você possa fazer a respeito.
A conferência deste ano acontecerá no dia 7 de dezembro em Technopolis. Aceitamos inscrições para relatórios até 11 de novembro. nós se você quiser falar.
As inscrições para participantes estão abertas, os ingressos custam 7000 rublos. Junte-se a nós!
Fonte: habr.com