{"id":39219,"date":"2019-10-31T22:28:31","date_gmt":"2019-10-31T19:28:31","guid":{"rendered":"https:\/\/prohoster.info\/blog\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire\/"},"modified":"2019-10-31T22:28:31","modified_gmt":"2019-10-31T19:28:31","slug":"devops-i-haos-dostavka-po-v-detsentralizovannom-mire","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","title":{"rendered":"DevOps e Caos: entrega de software em um mundo descentralizado","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

O fundador e diretor da \"Otomato Software\", um dos proponentes e instrutores da primeira certifica\u00e7\u00e3o DevOps em Israel, Anton Weiss, compartilhou no ano passado DevOpsDays Moscovo<\/a><\/noindex> sobre a teoria do caos e os principais princ\u00edpios da engenharia do caos, al\u00e9m de explicar como seria a organiza\u00e7\u00e3o DevOps ideal do futuro.<\/p>\n

Preparamos uma vers\u00e3o em texto da apresenta\u00e7\u00e3o. <\/p>\n

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center>
\n<\/a><\/noindex>
\nBom dia! <\/p>\n

O DevOpsDays em Moscovo acontece pelo segundo ano consecutivo, e eu estou novamente neste palco, muitos de voc\u00eas est\u00e3o aqui pela segunda vez. E o que isso significa? Significa que o movimento DevOps na R\u00fassia est\u00e1 crescendo, se multiplicando, e o mais importante, significa que chegou a hora de falarmos sobre o que \u00e9 DevOps em 2018. <\/p>\n

Levantem as m\u00e3os aqueles que acham que em 2018 DevOps j\u00e1 \u00e9 uma profiss\u00e3o? Tem algu\u00e9m. Existem engenheiros DevOps na sala, cujo t\u00edtulo inclui \"engenheiro DevOps\"? E gerentes DevOps? N\u00e3o tem ningu\u00e9m. Arquitetos DevOps? Tamb\u00e9m n\u00e3o. Poucos. Realmente ningu\u00e9m tem escrito que \u00e9 engenheiro DevOps?<\/p>\n

Ent\u00e3o, a maioria de voc\u00eas acha que isso \u00e9 um antipadr\u00e3o? Que essa profiss\u00e3o n\u00e3o deveria existir? Podemos pensar o que quisermos, mas enquanto pensamos, a ind\u00fastria avan\u00e7a solenemente ao som do toque da DevOps.<\/p>\n

Quem ouviu sobre um novo tema chamado DevDevOps? \u00c9 uma nova metodologia que permite uma colabora\u00e7\u00e3o eficaz entre desenvolvedores e DevOps. E n\u00e3o \u00e9 t\u00e3o nova. Pelo que vejo no Twitter, j\u00e1 se falava sobre isso h\u00e1 4 anos. E at\u00e9 hoje o interesse continua a crescer, ou seja, existe um problema. Precisamos resolver esse problema.<\/p>\n

\"DevOps
\n
\nSomos pessoas criativas e n\u00e3o nos contentamos facilmente. Dizemos que DevOps \u00e9 uma palavra insuficientemente abrangente, que falta uma s\u00e9rie de elementos interessantes. E vamos para nossos laborat\u00f3rios secretos e come\u00e7amos a criar muta\u00e7\u00f5es curiosas: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.<\/p>\n

\"DevOps
\n
\nA l\u00f3gica \u00e9 inquestion\u00e1vel, certo? Nosso sistema de entrega n\u00e3o \u00e9 funcional, nossas sistemas s\u00e3o inst\u00e1veis e os usu\u00e1rios est\u00e3o insatisfeitos, n\u00e3o conseguimos liberar software a tempo, n\u00e3o conseguimos ficar dentro do or\u00e7amento. Como vamos resolver tudo isso? Vamos inventar uma nova palavra! Ela vai terminar em \"Ops\", e o problema estar\u00e1 resolvido.<\/p>\n

Assim, eu chamo essa abordagem de \"Ops, e o problema est\u00e1 resolvido\".<\/p>\n

Tudo isso fica em segundo plano quando nos lembramos do porqu\u00ea de termos criado tudo isso. Criamos todo esse DevOps para tornar a entrega de software e nosso pr\u00f3prio trabalho nesse processo o mais fluido, indolor, eficiente e, acima de tudo, agrad\u00e1vel poss\u00edvel. <\/p>\n

O DevOps cresceu da dor. Estamos cansados de sofrer. E para que tudo isso aconte\u00e7a, baseamo-nos em pr\u00e1ticas perenes: colabora\u00e7\u00e3o eficaz, pr\u00e1ticas de fluxo e, mais importante, pensamento sist\u00eamico, porque sem isso nenhum DevOps funciona.<\/p>\n

O que \u00e9 um sistema?<\/b><\/h3>\n

\nE se estamos falando sobre pensamento sist\u00eamico, vamos nos lembrar do que \u00e9 um sistema.<\/p>\n

\"DevOps
\n
\nSe voc\u00ea \u00e9 um hacker revolucion\u00e1rio, ent\u00e3o para voc\u00ea o sistema \u00e9 um mal absoluto. \u00c9 uma nuvem que paira sobre voc\u00ea e te obriga a fazer o que voc\u00ea n\u00e3o quer fazer. <\/p>\n

\"DevOps
\n
\nDo ponto de vista do pensamento sist\u00eamico, um sistema \u00e9 um todo que consiste em partes. Nesse sentido, cada um de n\u00f3s \u00e9 um sistema. As organiza\u00e7\u00f5es em que trabalhamos s\u00e3o sistemas. E aquilo que estamos construindo juntos \u00e9 chamado de sistema.<\/p>\n

Tudo isso \u00e9 parte de um grande sistema sociotecnol\u00f3gico. E s\u00f3 se entendermos como esse sistema sociotecnol\u00f3gico funciona em conjunto, poderemos realmente otimizar algo nesse processo. <\/p>\n

Do ponto de vista do pensamento sist\u00eamico, o sistema possui caracter\u00edsticas interessantes. Em primeiro lugar, \u00e9 composto por partes, o que significa que seu comportamento depende do comportamento das partes. Al\u00e9m disso, todas as suas partes tamb\u00e9m s\u00e3o interdependentes. Portanto, quanto mais partes um sistema tem, mais dif\u00edcil fica entender ou prever seu comportamento. <\/p>\n

Do ponto de vista do comportamento, existe mais um fato interessante. Um sistema pode fazer algo que nenhuma de suas partes individuais consegue fazer. <\/p>\n

Como disse o Dr. Russell Ackoff (um dos fundadores do pensamento sist\u00eamico), isso pode ser facilmente demonstrado atrav\u00e9s de um experimento mental. Por exemplo, quem aqui sabe escrever c\u00f3digo? Muitas m\u00e3os se levantam, e isso \u00e9 normal, pois \u00e9 uma das exig\u00eancias b\u00e1sicas da nossa profiss\u00e3o. Voc\u00ea \u00e9 capaz de escrever, mas suas m\u00e3os, separadas de voc\u00ea, podem escrever c\u00f3digo? Existem pessoas que dir\u00e3o: 'N\u00e3o s\u00e3o minhas m\u00e3os que escrevem c\u00f3digo, \u00e9 meu c\u00e9rebro que escreve c\u00f3digo'. E o c\u00e9rebro pode escrever c\u00f3digo separado de voc\u00ea? Bem, provavelmente n\u00e3o. <\/p>\n

O c\u00e9rebro \u00e9 uma m\u00e1quina incr\u00edvel; n\u00f3s conhecemos apenas 10% de como ele funciona, mas n\u00e3o pode operar isoladamente do sistema que \u00e9 nosso organismo. E isso pode ser facilmente provado: abra seu cr\u00e2nio, retire o c\u00e9rebro de l\u00e1, coloque-o diante de um computador e veja se consegue escrever algo simples. \"Hello, world\" em Python, por exemplo.<\/p>\n

Se um sistema pode fazer algo que nenhuma de suas partes, isoladamente, consegue fazer, isso significa que seu comportamento n\u00e3o \u00e9 definido pelo comportamento de suas partes. Pelo que ele \u00e9 ent\u00e3o definido? Ele \u00e9 determinado pela intera\u00e7\u00e3o entre essas partes. E, consequentemente, quanto mais partes, mais complexas s\u00e3o as intera\u00e7\u00f5es e mais dif\u00edcil \u00e9 compreender e prever o comportamento do sistema. Isso torna o sistema ca\u00f3tico, pois qualquer pequena e invis\u00edvel altera\u00e7\u00e3o em qualquer uma das partes do sistema pode levar a resultados completamente imprevis\u00edveis. <\/p>\n

Essa sensibilidade \u00e0s condi\u00e7\u00f5es 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\u00edfico conhecido como \"teoria do caos\". Essa teoria se tornou uma das principais mudan\u00e7as de paradigma na ci\u00eancia do s\u00e9culo 20.<\/p>\n

Teoria do Caos<\/b><\/h3>\n

\nAs pessoas que estudam o caos se chamam de caos\u00f3logos.<\/p>\n

\"DevOps
\n
\nNa verdade, a raz\u00e3o por tr\u00e1s desta apresenta\u00e7\u00e3o \u00e9 que, ao trabalhar com sistemas complexos e organiza\u00e7\u00f5es internacionais grandes, cheguei ao ponto em que percebi que \u00e9 isso que sou. Eu sou um caos\u00f3logo. \u00c9, digamos, uma maneira engenhosa de dizer: \"Eu n\u00e3o entendo o que est\u00e1 acontecendo aqui e n\u00e3o sei o que fazer com isso.\" <\/p>\n

Eu acho que muitos de voc\u00eas tamb\u00e9m se sentem assim com frequ\u00eancia, ent\u00e3o voc\u00eas tamb\u00e9m s\u00e3o caos\u00f3logos. Convido voc\u00eas para a guilda dos caos\u00f3logos. Os sistemas que n\u00f3s, queridos colegas caos\u00f3logos, iremos estudar, s\u00e3o chamados de \"sistemas adaptativos complexos\". <\/p>\n

O que \u00e9 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 \u00e0s mudan\u00e7as por meio da autoorganiza\u00e7\u00e3o. E essa capacidade de autoorganiza\u00e7\u00e3o \u00e9 baseada na colabora\u00e7\u00e3o volunt\u00e1ria e completamente descentralizada de agentes aut\u00f4nomos livres.<\/p>\n

Outra propriedade interessante desses sistemas \u00e9 que eles s\u00e3o livremente escal\u00e1veis. O que, como engenheiros do caos, deve nos interessar indiscutivelmente. Assim, se dissemos que o comportamento de um sistema complexo \u00e9 determinado pela intera\u00e7\u00e3o de suas partes, o que deve nos interessar? A intera\u00e7\u00e3o. <\/p>\n

H\u00e1 mais duas conclus\u00f5es interessantes.
\n \"DevOps
\n
\nEm primeiro lugar, entendemos que um sistema complexo n\u00e3o pode ser simplificado pela simplifica\u00e7\u00e3o de suas partes. Em segundo lugar, a \u00fanica maneira de simplificar um sistema complexo \u00e9 atrav\u00e9s da simplifica\u00e7\u00e3o das intera\u00e7\u00f5es entre suas partes. <\/p>\n

Como interagimos? Todos n\u00f3s somos partes de um grande sistema informativo chamado sociedade humana. Interagimos atrav\u00e9s de uma linguagem comum, se a tivermos, se a encontrarmos.<\/p>\n

\"DevOps
\n
\nMas a linguagem por si s\u00f3 \u00e9 um sistema adaptativo complexo. Portanto, para interagir de maneira mais eficaz e simples, precisamos criar alguns protocolos. Ou seja, uma sequ\u00eancia de s\u00edmbolos e a\u00e7\u00f5es que tornar\u00e1 a troca de informa\u00e7\u00f5es entre n\u00f3s mais simples, mais previs\u00edvel, mais clara.<\/p>\n

Quero dizer que as tend\u00eancias para a complexidade, a adaptabilidade, a descentraliza\u00e7\u00e3o e o caos est\u00e3o presentes em tudo. Nas sistemas que constru\u00edmos e nos sistemas dos quais fazemos parte.<\/p>\n

E para n\u00e3o ser apenas uma afirma\u00e7\u00e3o vazia, vamos observar como os sistemas que criamos mudam.<\/p>\n

\"DevOps
\n
\nVoc\u00ea estava esperando por essa palavra, eu sei. Estamos na confer\u00eancia DevOps e hoje essa palavra ser\u00e1 mencionada cerca de cem mil vezes e depois nos perseguir\u00e1 \u00e0 noite.<\/p>\n

Microservi\u00e7os s\u00e3o a primeira arquitetura de software que surgiu como uma rea\u00e7\u00e3o \u00e0s pr\u00e1ticas DevOps, destinada a tornar nossos sistemas mais flex\u00edveis, escal\u00e1veis e a garantir entrega cont\u00ednua. Como isso \u00e9 poss\u00edvel? Atrav\u00e9s da redu\u00e7\u00e3o do volume de servi\u00e7os, da diminui\u00e7\u00e3o das fronteiras dos problemas que esses servi\u00e7os lidam e da diminui\u00e7\u00e3o do tempo de entrega. Ou seja, estamos diminuindo e simplificando partes do sistema, aumentando sua quantidade. Assim, inevitavelmente a complexidade das intera\u00e7\u00f5es entre essas partes aumenta, surgindo novos problemas que precisamos resolver.<\/p>\n

\"DevOps
\n
\nMicroservi\u00e7os n\u00e3o s\u00e3o o fim; na verdade, microservi\u00e7os j\u00e1 s\u00e3o um conceito ultrapassado, pois o Serverless est\u00e1 chegando. Todos os servidores queimaram, n\u00e3o h\u00e1 servidores, n\u00e3o h\u00e1 sistemas operacionais, apenas c\u00f3digo execut\u00e1vel puro. As configura\u00e7\u00f5es s\u00e3o separadas, os estados s\u00e3o separados, tudo \u00e9 gerenciado por eventos. Beleza, pureza, tranquilidade; n\u00e3o h\u00e1 eventos, nada acontece, tudo est\u00e1 em ordem. <\/p>\n

Onde est\u00e1 a complexidade? A complexidade, como podemos perceber, est\u00e1 nas intera\u00e7\u00f5es. Quanto uma fun\u00e7\u00e3o pode fazer sozinha? Como ela interage com outras fun\u00e7\u00f5es? Filas de mensagens, bancos de dados, balanceadores. Como recriar um evento quando ocorre uma falha? Uma infinidade de perguntas e poucas respostas.<\/p>\n

Microservi\u00e7os e Serverless s\u00e3o tudo o que n\u00f3s, hipsters da computa\u00e7\u00e3o, chamamos de Cloud Native. \u00c9 tudo sobre a nuvem. Mas a nuvem, em sua ess\u00eancia, tamb\u00e9m \u00e9 limitada em termos de escalabilidade. Costumamos pensar nela como um sistema distribu\u00eddo. Na verdade, onde est\u00e3o os servidores dos provedores de nuvem? Em data centers. Ou seja, temos aqui um modelo centralizado, muito limitado e distribu\u00eddo.<\/p>\n

Hoje entendemos que a internet das coisas n\u00e3o se resume a palavras chamativas; mesmo de acordo com previs\u00f5es modestas, nos pr\u00f3ximos cinco a dez anos, seremos cercados por bilh\u00f5es de dispositivos conectados \u00e0 internet. Uma enorme quantidade de dados \u00fateis e in\u00fateis que ser\u00e1 integrada na nuvem e que ser\u00e1 alimentada a partir dela. <\/p>\n

A nuvem n\u00e3o suportar\u00e1 isso, por isso falamos cada vez mais sobre o que chamamos de \"computa\u00e7\u00e3o de borda\". Ou, ainda, gosto da defini\u00e7\u00e3o maravilhosa de \"fog computing\". Isso \u00e9 envolto em uma m\u00edstica de romantismo e mist\u00e9rio.<\/p>\n

\"DevOps
\n
\nComputa\u00e7\u00e3o nebulosa. Refere-se ao fato de que as nuvens s\u00e3o aglomerados centralizados de \u00e1gua, vapor, gelo e pedras. E o nevoeiro \u00e9 composto por got\u00edculas de \u00e1gua dispersas ao nosso redor na atmosfera. <\/p>\n

Na paradigma nevoento, a maior parte do trabalho \u00e9 realizada por essas got\u00edculas de forma completamente aut\u00f4noma ou em colabora\u00e7\u00e3o com outras got\u00edculas. E elas se conectam \u00e0 nuvem apenas quando realmente necess\u00e1rio. <\/p>\n

Ou seja, novamente a descentraliza\u00e7\u00e3o, a autonomia, e, claro, muitos de voc\u00eas j\u00e1 entendem para onde tudo isso est\u00e1 indo, porque n\u00e3o se pode falar sobre descentraliza\u00e7\u00e3o sem mencionar blockchain. <\/p>\n

\"DevOps
\n
\nExistem aqueles que acreditam, que s\u00e3o os que investiram em criptomoedas. Existem os que acreditam, mas t\u00eam medo, como eu, por exemplo. E h\u00e1 aqueles que n\u00e3o acreditam. Cada um pode ter uma vis\u00e3o diferente. Existe uma tecnologia, uma nova e desconhecida, e h\u00e1 problemas. Como qualquer nova tecnologia, ela levanta mais perguntas do que respostas. <\/p>\n

O hype em torno do blockchain \u00e9 compreens\u00edvel. Mesmo se deixarmos de lado a febre do ouro, a pr\u00f3pria tecnologia promete um futuro brilhante: mais liberdade, mais autonomia, confian\u00e7a global distribu\u00edda. O que n\u00e3o gostar disso? <\/p>\n

Consequentemente, cada vez mais engenheiros em todo o mundo come\u00e7am a desenvolver aplica\u00e7\u00f5es descentralizadas. E essa \u00e9 uma for\u00e7a que n\u00e3o pode ser ignorada, simplesmente dizendo: \"Ah, o blockchain \u00e9 apenas um banco de dados distribu\u00eddo mal implementado\". Ou como os c\u00e9ticos gostam de dizer: \"N\u00e3o h\u00e1 aplica\u00e7\u00f5es reais para o blockchain\". Se pensarmos, 150 anos atr\u00e1s eles diziam a mesma coisa sobre eletricidade. E at\u00e9 certo ponto estavam certos, pois o que a eletricidade torna poss\u00edvel hoje era completamente inimagin\u00e1vel no s\u00e9culo 19.<\/p>\n

A prop\u00f3sito, quem sabe qual \u00e9 o logo na tela? \u00c9 o Hyperledger. \u00c9 um projeto desenvolvido sob os ausp\u00edcios da The Linux Foundation, que inclui um conjunto de tecnologias de blockchain. \u00c9 realmente uma for\u00e7a na nossa comunidade de c\u00f3digo aberto.<\/p>\n

Engenharia do caos<\/b><\/h3>\n

\n\"DevOps
\n
\nEnt\u00e3o, o sistema que estamos desenvolvendo se torna cada vez mais complexo, cada vez mais ca\u00f3tico e adapt\u00e1vel. O Netflix foi um pioneiro em sistemas de microservi\u00e7os. Eles foram um dos primeiros a perceber isso e desenvolveram um conjunto de ferramentas que chamaram de Simian Army, sendo o mais famoso deles Chaos Monkey<\/a><\/noindex>. Ele definiu o que ficou conhecido como \u00abprinc\u00edpios da engenharia do caos\u00bb<\/a><\/noindex>.<\/p>\n

Ali\u00e1s, durante o trabalho na apresenta\u00e7\u00e3o, n\u00f3s at\u00e9 traduzimos esse texto para o russo, ent\u00e3o acesse o link<\/a><\/noindex>, leia, comente, critique.<\/p>\n

Em suma, os princ\u00edpios da engenharia do caos dizem o seguinte. Sistemas distribu\u00eddos complexos s\u00e3o, por sua pr\u00f3pria natureza, imprevis\u00edveis e t\u00eam, por natureza, falhas. Falhas s\u00e3o inevit\u00e1veis, o que significa que precisamos aceit\u00e1-las e trabalhar com esses sistemas de uma maneira completamente diferente. <\/p>\n

Devemos tentar introduzir essas falhas em nossos sistemas de produ\u00e7\u00e3o para testar a adaptabilidade, a capacidade de auto-organiza\u00e7\u00e3o e a sobreviv\u00eancia desses sistemas. <\/p>\n

E isso muda tudo. N\u00e3o apenas a forma como colocamos o sistema em produ\u00e7\u00e3o, mas tamb\u00e9m como o desenvolvemos, como o testamos. N\u00e3o existe um processo de estabiliza\u00e7\u00e3o, congelamento de c\u00f3digo; pelo contr\u00e1rio, existe um processo cont\u00ednuo de desestabiliza\u00e7\u00e3o. Tentamos destruir o sistema e ver se ele continua a sobreviver.<\/p>\n

Protocolos de Integra\u00e7\u00e3o de Sistemas Distribu\u00eddos<\/b><\/h3>\n

\n\"DevOps
\n
\nConsequentemente, isso exige que nossos sistemas tamb\u00e9m mudem de alguma forma. Para que se tornem mais resilientes, eles precisam de novos protocolos de intera\u00e7\u00e3o entre suas partes. Para que essas partes possam se comunicar e chegar a alguma forma de auto-organiza\u00e7\u00e3o. E assim surgem v\u00e1rias novas ferramentas, novos protocolos, que eu chamo de \u00abprotocolos de intera\u00e7\u00e3o de sistemas distribu\u00eddos\u00bb.<\/p>\n

\"DevOps
\n
\nSobre o que estou falando? Em primeiro lugar, o projeto Opentracing<\/a><\/noindex>. Uma tentativa de criar um protocolo comum de rastreamento distribu\u00eddo, que \u00e9 uma ferramenta absolutamente essencial para depurar sistemas distribu\u00eddos complexos.<\/p>\n

\"DevOps
\n
\nEm seguida \u2014 (OPA) fornece a capacidade de criar pol\u00edticas sobre pilhas de aplica\u00e7\u00f5es em nuvem no Kubernetes, desde ingress at\u00e9 service mesh.<\/a><\/noindex>. Dizemos que n\u00e3o podemos prever o que ocorrer\u00e1 com o sistema, portanto precisamos aumentar sua observabilidade. O Opentracing pertence \u00e0 fam\u00edlia de ferramentas que proporcionam visibilidade aos nossos sistemas. Mas a observabilidade \u00e9 necess\u00e1ria para determinar se o sistema se comporta da maneira que esperamos ou n\u00e3o. Como podemos determinar o comportamento esperado? Atrav\u00e9s da defini\u00e7\u00e3o de uma pol\u00edtica, um conjunto de regras. O projeto Open Policy Agent lida com a defini\u00e7\u00e3o desse conjunto de regras em uma ampla gama de \u00e1reas, desde acesso at\u00e9 aloca\u00e7\u00e3o de recursos.<\/p>\n

\"DevOps
\n
\nComo dissemos, nossos sistemas est\u00e3o se tornando cada vez mais gerenciados por eventos. Serverless \u00e9 um \u00f3timo exemplo de sistemas gerenciados por eventos. Para que possamos transmitir eventos entre sistemas e monitor\u00e1-los, precisamos de uma linguagem comum, um protocolo comum de como falamos sobre eventos, como os transmitimos uns aos outros. Isso \u00e9 o que o projeto chamado Cloudevents<\/a><\/noindex>.<\/p>\n

\"DevOps
\n
\nFluxo cont\u00ednuo de mudan\u00e7as que permeia nossos sistemas, desestabilizando-os constantemente, \u00e9 um fluxo cont\u00ednuo de artefatos de software. Para que possamos sustentar esse fluxo constante de mudan\u00e7as, precisamos de um protocolo comum pelo qual possamos nos comunicar sobre o que \u00e9 um artefato de software, como ele \u00e9 validado, que verifica\u00e7\u00e3o ele passou. Isso \u00e9 o que o projeto chamado Grafeas<\/a><\/noindex>. Portanto, um protocolo comum de metadados de artefatos de software.<\/p>\n

\"DevOps
\n
\nE, finalmente, se quisermos que nossos sistemas sejam totalmente aut\u00f4nomos, adaptativos, auto-organizados, precisamos lhes dar o direito \u00e0 autoidentifica\u00e7\u00e3o. O projeto chamado spiffe<\/a><\/noindex> \u00e9 exatamente isso que faz. Este tamb\u00e9m \u00e9 um projeto sob a \u00e9gide da Cloud Native Computing Foundation.<\/p>\n

Todos esses projetos s\u00e3o jovens, todos precisam do nosso amor, da nossa verifica\u00e7\u00e3o. Todo esse c\u00f3digo \u00e9 aberto, nosso teste, nossa implementa\u00e7\u00e3o. Eles nos mostram para onde a tecnologia est\u00e1 se movendo. <\/p>\n

Mas DevOps nunca foi, em primeiro lugar, sobre tecnologia, sempre foi sobre colabora\u00e7\u00e3o entre pessoas. Portanto, se quisermos que os sistemas que desenvolvemos mudem, n\u00f3s tamb\u00e9m devemos mudar. Na verdade, j\u00e1 estamos mudando, n\u00e3o temos muita escolha. <\/p>\n

\"DevOps
\n
\nH\u00e1 um maravilhoso livro<\/a><\/noindex> livro da escritora brit\u00e2nica Rachel Botsman, no qual ela escreve sobre a evolu\u00e7\u00e3o da confian\u00e7a ao longo da hist\u00f3ria da humanidade. Ela afirma que, originalmente, em sociedades primitivas, a confian\u00e7a era local, ou seja, confi\u00e1vamos apenas naqueles que conhec\u00edamos pessoalmente. <\/p>\n

Depois, houve um longo per\u00edodo - uma era sombria, quando a confian\u00e7a era centralizada, quando passamos a confiar em pessoas que n\u00e3o conhec\u00edamos com base no fato de que pertenc\u00edamos a uma mesma institui\u00e7\u00e3o social ou estatal.<\/p>\n

E eis o que vemos em nosso mundo moderno: a confian\u00e7a est\u00e1 se tornando cada vez mais distribu\u00edda e descentralizada, baseada na liberdade dos fluxos de informa\u00e7\u00e3o e na acessibilidade da informa\u00e7\u00e3o. <\/p>\n

Se pensarmos bem, essa mesma acessibilidade, que torna essa confian\u00e7a poss\u00edvel, \u00e9 algo que n\u00f3s mesmos promovemos. Isso significa que a forma como colaboramos e como fazemos isso deve mudar, pois as organiza\u00e7\u00f5es de TI centralizadas e hier\u00e1rquicas do velho tipo est\u00e3o perdendo efic\u00e1cia. Elas come\u00e7am a se extinguir. <\/p>\n

Fundamentos das organiza\u00e7\u00f5es DevOps<\/b><\/h3>\n

\nA organiza\u00e7\u00e3o DevOps ideal do futuro \u00e9 um sistema descentralizado e adapt\u00e1vel, composto por equipes aut\u00f4nomas, cada uma formada por indiv\u00edduos aut\u00f4nomos. Essas equipes est\u00e3o espalhadas pelo mundo, colaborando de forma eficaz umas com as outras por meio de comunica\u00e7\u00e3o ass\u00edncrona e protocolos de troca de informa\u00e7\u00f5es altamente transparentes. Muito bonito, n\u00e3o \u00e9? Um futuro muito belo.<\/p>\n

Claro, tudo isso \u00e9 imposs\u00edvel sem mudan\u00e7as culturais. Precisamos de uma lideran\u00e7a transformacional, responsabilidade pessoal e motiva\u00e7\u00e3o interna.<\/p>\n

\"DevOps
\n
\nEssa \u00e9 a base das organiza\u00e7\u00f5es DevOps: transpar\u00eancia da informa\u00e7\u00e3o, comunica\u00e7\u00f5es ass\u00edncronas, lideran\u00e7a transformacional, descentraliza\u00e7\u00e3o. <\/p>\n

Burnout<\/b><\/h3>\n

\nOs sistemas dos quais fazemos parte e aqueles que constru\u00edmos est\u00e3o se tornando cada vez mais ca\u00f3ticos, e nos, seres humanos, temos dificuldade em lidar com essa ideia, e \u00e9 dif\u00edcil abrir m\u00e3o da ilus\u00e3o de controle. Tentamos continuar a control\u00e1-los, e isso muitas vezes leva ao burnout. Falo isso por experi\u00eancia pr\u00f3pria, eu tamb\u00e9m passei por isso, sou uma v\u00edtima de falhas imprevistas em produ\u00e7\u00e3o.<\/p>\n

\"DevOps
\n
\nO burnout ocorre quando tentamos controlar o que, por sua pr\u00f3pria natureza, n\u00e3o pode ser controlado. Quando queimamos, tudo perde o sentido, porque perdemos o desejo de fazer algo novo, nos colocamos em uma posi\u00e7\u00e3o defensiva e come\u00e7amos a defender o que j\u00e1 temos. <\/p>\n

A profiss\u00e3o de engenheiro, como eu gosto muitas vezes de me lembrar, \u00e9 principalmente uma profiss\u00e3o criativa. Se perdemos o desejo de criar algo, nos transformamos em cinzas, nos tornamos poeira. Pessoas queimam, organiza\u00e7\u00f5es inteiras queimam.<\/p>\n

Na minha opini\u00e3o, apenas a aceita\u00e7\u00e3o do poder criativo do caos, apenas a constru\u00e7\u00e3o da coopera\u00e7\u00e3o com base em seus princ\u00edpios \u2014 isso \u00e9 o que nos ajudar\u00e1 a n\u00e3o perder o que h\u00e1 de bom em nossa profiss\u00e3o. <\/p>\n

Isso \u00e9 o que desejo a voc\u00ea: amar seu trabalho, amar o que fazemos. Este mundo se alimenta de informa\u00e7\u00e3o, e temos a honra de aliment\u00e1-lo. Ent\u00e3o, vamos estudar o caos, ser caologistas, trazer valor, criar algo novo, e os problemas, como j\u00e1 percebemos, s\u00e3o inevit\u00e1veis, e quando eles surgirem, diremos simplesmente 'Ops!', e o problema estar\u00e1 resolvido. <\/p>\n

O que al\u00e9m do Chaos Monkey?<\/b><\/p>\n

Na verdade, todas essas ferramentas s\u00e3o relativamente novas. A Netflix desenvolveu ferramentas para suas pr\u00f3prias necessidades. Construa ferramentas para voc\u00ea. Leia os princ\u00edpios da engenharia do caos e siga esses princ\u00edpios, ao inv\u00e9s de tentar encontrar outras ferramentas que algu\u00e9m j\u00e1 criou. <\/p>\n

Tente entender como seus sistemas falham e comece a caus\u00e1-las para ver como eles suportam os impactos. Isso \u00e9 o mais importante. As ferramentas podem ser pesquisadas. Existem v\u00e1rios projetos. <\/p>\n

N\u00e3o entendi muito bem o ponto que voc\u00ea mencionou sobre n\u00e3o simplificar um sistema, simplificando seus componentes, e logo em seguida falar sobre microservi\u00e7os, que justamente simplificam o sistema ao simplificar os pr\u00f3prios componentes e complicar as intera\u00e7\u00f5es. Esse s\u00e3o, na verdade, duas partes que se contradizem. <\/b><\/p>\n

Exatamente, microservi\u00e7os s\u00e3o um tema muito controverso. Na verdade, simplificar partes aumenta a flexibilidade. O que os microservi\u00e7os nos oferecem? Eles nos d\u00e3o flexibilidade e velocidade, mas definitivamente n\u00e3o nos proporcionam simplicidade. Eles aumentam a complexidade.<\/p>\n

Ent\u00e3o, na filosofia DevOps, os microservi\u00e7os n\u00e3o s\u00e3o uma ben\u00e7\u00e3o?<\/b><\/p>\n

Qualquer benef\u00edcio tem seu lado negativo. H\u00e1 um benef\u00edcio: isso aumenta a flexibilidade, nos permite fazer mudan\u00e7as mais rapidamente, mas tamb\u00e9m aumenta a complexidade e, consequentemente, a fragilidade de todo o sistema. <\/p>\n

No final, onde deve estar o foco: na simplifica\u00e7\u00e3o das intera\u00e7\u00f5es ou na simplifica\u00e7\u00e3o das partes?<\/b> <\/p>\n

A \u00eanfase, sem d\u00favida, est\u00e1 na simplifica\u00e7\u00e3o da intera\u00e7\u00e3o, porque se olharmos para isso em termos de como trabalhamos juntos, devemos, primeiro de tudo, prestar aten\u00e7\u00e3o na simplifica\u00e7\u00e3o das intera\u00e7\u00f5es, e n\u00e3o na simplifica\u00e7\u00e3o do trabalho de cada um de n\u00f3s separadamente. Porque simplificar o trabalho significa transformar as pessoas em rob\u00f4s. Isso funciona bem no McDonald's, onde voc\u00ea tem a instru\u00e7\u00e3o: coloque o hamb\u00farguer aqui, despeje o molho aqui. Isso n\u00e3o funciona de forma alguma no nosso trabalho criativo.<\/p>\n

\u00c9 verdade que tudo o que voc\u00ea descreveu vive em um mundo sem concorr\u00eancia, e que l\u00e1 o caos \u00e9 t\u00e3o benigno, sem contradi\u00e7\u00f5es dentro desse caos, onde ningu\u00e9m quer devorar ou matar ningu\u00e9m? Como a concorr\u00eancia e o DevOps devem coexistir?<\/b><\/p>\n

Bem, depende de que tipo de concorr\u00eancia estamos falando. Sobre a concorr\u00eancia no local de trabalho ou a concorr\u00eancia entre empresas? <\/p>\n

Sobre a concorr\u00eancia dos servi\u00e7os que existem, porque os servi\u00e7os n\u00e3o s\u00e3o v\u00e1rias empresas. Estamos criando um novo tipo de ambiente informativo, e qualquer ambiente n\u00e3o pode existir sem concorr\u00eancia. Em toda parte h\u00e1 concorr\u00eancia.<\/b><\/p>\n

Tomemos a Netflix como exemplo de modelo. Eles inventaram isso por qu\u00ea? Porque precisavam ser competitivos. Essa flexibilidade e velocidade de movimento s\u00e3o exatamente a exig\u00eancia competitiva, trazendo um certo caos aos nossos sistemas. Ou seja, o caos n\u00e3o \u00e9 algo que fazemos conscientemente porque queremos, mas \u00e9 o que acontece porque o mundo exige isso. Temos que nos adaptar. E o caos, na verdade, \u00e9 o resultado da concorr\u00eancia.<\/p>\n

Isso significa que o caos \u00e9 uma aus\u00eancia de metas, certo? Ou aquelas metas que n\u00e3o queremos ver? Estamos em nossa bolha e n\u00e3o entendemos as metas dos outros. A concorr\u00eancia, na verdade, \u00e9 poss\u00edvel porque temos metas bem definidas e sabemos aonde queremos chegar a cada momento seguinte. Para mim, essa \u00e9 a ess\u00eancia do DevOps.<\/b><\/p>\n

\u00c9 uma maneira de ver a quest\u00e3o. Acredito que a nossa meta comum \u00e9: sobreviver e fazer isso com
\na maior satisfa\u00e7\u00e3o poss\u00edvel. E a meta competitiva de qualquer organiza\u00e7\u00e3o \u00e9 a mesma. A sobreviv\u00eancia muitas vezes ocorre em uma luta competitiva, n\u00e3o h\u00e1 muito o que fazer.<\/p>\n

Neste ano, a confer\u00eancia DevOpsDays Moscovo<\/a><\/noindex> ocorrer\u00e1 em 7 de dezembro no 'Tecnop\u00f3lis'. At\u00e9 11 de novembro, estamos aceitando propostas para palestras. Escreva para<\/a><\/noindex> n\u00f3s, se voc\u00ea quiser se apresentar.<\/p>\n

As inscri\u00e7\u00f5es para os participantes est\u00e3o abertas, o ingresso custa 7000 rublos. Junte-se a n\u00f3s! \n<\/p><\/blockquote>\n

Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c DevOpsDays Moscow \u043f\u0440\u043e \u0442\u0435\u043e\u0440\u0438\u044e \u0445\u0430\u043e\u0441\u0430 \u0438 \u0433\u043b\u0430\u0432\u043d\u044b\u0435 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0445\u0430\u043e\u0441\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0438\u0438, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u043b, \u043a\u0430\u043a \u0443\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u0430\u044f DevOps-\u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f \u0431\u0443\u0434\u0443\u0449\u0435\u0433\u043e. \u041c\u044b \u043f\u0440\u0438\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0442\u0435\u043a\u0441\u0442\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u0414\u043e\u0431\u0440\u043e\u0435 \u0443\u0442\u0440\u043e! DevOpsDays \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 \u0432\u0442\u043e\u0440\u043e\u0439 \u0433\u043e\u0434 \u043f\u043e\u0434\u0440\u044f\u0434, \u044f \u0432\u0442\u043e\u0440\u043e\u0439 \u0440\u0430\u0437 \u043d\u0430 \u044d\u0442\u043e\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29435,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39219","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47DevOps e Caos: entrega de software em um mundo descentralizado | ProHoster","description":"O fundador e diretor da \"Otomato Software\", um dos proponentes e instrutores da primeira certifica\u00e7\u00e3o DevOps em Israel, Anton Weiss, compartilhou no ano passado","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0435\u0432\u041e\u043f\u0441 \u0438 \u0425\u0430\u043e\u0441: \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0430 \u041f\u041e \u0432 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u043e\u043c \u043c\u0438\u0440\u0435 | ProHoster","og:description":"\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:28:31+00:00","article:modified_time":"2019-10-31T19:28:31+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39219","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:19:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:41","updated":"2026-01-24 01:19:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/39219","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=39219"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/39219\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/29435"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=39219"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=39219"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=39219"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}