Do administrador do sistema para a pessoa

O DevOps possui pelo menos duas visualizações bem estabelecidas - do lado dos administradores de sistema e do lado dos desenvolvedores. Os primeiros costumam se gabar de estar usando Chef / Puppet / Ansible / Docker desde 200X, os últimos acreditam que o DevOps sobreviveu a si próprio e leva ao NoOps, ou que "embrulhei tudo em um contêiner e depois como ele vai".

Ao mesmo tempo, a empresa lê artigos sobre DevOps e espera que os caras abaixo descubram o que fazer com ele. Ao mesmo tempo, o próprio DevOps não acontece, o negócio não se parece com o Google, a empresa não se torna turquesa, as pessoas não criam novas abordagens para testar hipóteses no mundo.

Este artigo é sobre o DevOps como um sistema. Como isso ajuda os negócios, quais competências dos engenheiros devem aparecer para o DevOps, quais tarefas de negócios podem ser resolvidas pelo método DevOps de produção de software e quais erros são possíveis no caminho para a produção do DevOps e como evitá-los ou impedi-los. Como, no final, como um engenheiro pode se tornar um Homem e ser um criador neste mundo, como construir uma carreira para isso e como começar a olhar para a tecnologia humanamente.

O material é baseado na transcrição do relatório de Alexander osminog Titov da conferência DevOops 2017 de outubro de 2017.



Para aqueles que estão acostumados a assistir relatórios de conferências em gravações, anexamos um vídeo.



Trabalho para o Express 42. Minha história é sobre minha carreira, mas darei a ele dicas e conclusões interessantes. Ele tem um nome atraente "Do administrador do sistema para a pessoa". Separo o papel do administrador do sistema de alguma condição humana. O DevOps nos leva a ser não apenas artistas, mas criadores de novos produtos digitais e muito mais.

Como minha história se baseia na minha experiência, vou contar um pouco sobre mim. Comecei como administrador do sistema quando estava na universidade. Ele trabalhou no turno da noite, depois começou a trabalhar no turno do dia e depois subiu para a posição de administrador do sistema principal. Depois trabalhei nas redes sociais connectect.ua e fakultet.ru, depois como diretor técnico da empresa Oversan-Skalaksi. Esta foi uma das primeiras tentativas de lançar hospedagem na nuvem na Rússia, como se viu, uma tentativa muito precoce. A necessidade de hospedagem na nuvem na Rússia surgiu apenas agora. Acabamos de entender como usá-los, percebemos que esses são recursos flexíveis, que eles precisam escrever aplicativos de maneira diferente e assim por diante. Naqueles dias, ninguém entendia nada, então vender era muito difícil.

Depois, trabalhei em uma startup Qik do Vale do Silício, cujo escritório de desenvolvimento estava aqui na Rússia. Na Qik, senti realmente o benefício do conceito DevOps, porque em dois meses criamos um produto que passou de 0 a 5 milhões de usuários. Se em Oversan-Skalaxi, do ponto de vista do serviço, senti que o DevOps é necessário e as pessoas precisam entender o que é o DevOps para usar a hospedagem em nuvem, então em Qik senti isso como administrador de sistemas e como chefe do departamento de administradores de sistemas. Então fomos comprados pelo Skype e começamos a integrar lá, e também integrar os desenvolvimentos no campo do DevOps, porque não estava no Skype. E então o Skype comprou a Microsoft. Parece que ele chegou a uma empresa onde cerca de 40 pessoas e, depois de alguns anos, você trabalha em uma grande empresa com 100 mil funcionários. Foi uma experiência muito interessante.

Como resultado, não achei para onde ir mais longe nessas empresas, e meus colegas e eu abrimos o Express 42, que leva o DevOps às massas. Essa ideia se originou em Oversan-Skalaksi e me motivou. Entre outras coisas, estou torcendo muito pela comunidade DevOps na Rússia. Sou o organizador das reuniões DevOpsDays Moscow e Moscow DevOps.

Há muito tempo me preocupo que o uso do Ansible possa ser ruim ou bom. A ferramenta como um todo não resolve nada. Você pode usar o Docker, Kubernetes, instalar o Prometheus mais recente, mas ao mesmo tempo o que você faz não será diferente do que as pessoas que usam scripts bash possuem. Vou tentar responder por que isso acontece. De muitas maneiras, essa resposta está dentro de nós, portanto o artigo é chamado assim. O administrador do sistema pensa em escrever scripts bash para ele, e a pessoa pensa um pouco diferente.

Como o DevOps aparece na empresa?

Desenvolvedor DevOps

Existem várias maneiras pelas quais o DevOps pode aparecer em uma empresa. Uma dessas maneiras é quando os desenvolvedores, cansados ​​de pedir que os administradores de sistema façam alguma coisa, e depois de ouvir sobre o DevOps, tentam implementá-lo. Mas, ao mesmo tempo, eles têm um entendimento peculiar do DevOps. Eles acham que podem usar qualquer tecnologia, agrupar tudo em um contêiner do Docker e enviá-lo aos administradores de sistema, mas não pensam em como o código funcionará na produção. Eles não mudaram nada em suas cabeças para mudar para o DevOps, mas ao mesmo tempo estão começando a usar novas tecnologias.

Eu já vi muitas dessas empresas. Você vem a eles - eles têm quatro departamentos de desenvolvimento. Cada departamento grava seu próprio microsserviço, cada departamento possui seu próprio banco de dados. Alguém Redis, alguém PostgreSQL, alguém PostgreSQL e MySQL ao mesmo tempo. E eles acompanham isso, até que os bancos de dados aumentem para tamanhos que não podem mais.

Nesse ponto, tudo começa a desmoronar e desmoronar, e conseqüências aterradoras surgem. Este é um zoológico de tecnologia com o qual não está claro o que fazer. Além disso, a peculiaridade do desenvolvedor é que ele resolve o problema arrastando uma nova biblioteca. Eu acho que aqueles que trabalham com desenvolvedores do Node.js estão familiarizados com isso. Quando os desenvolvedores do Node.js veem que o banco de dados não está funcionando bem, eles podem pular do PostgreSQL para alguma versão, adicionar alguma extensão ou começar a usar o JSONB. Como resultado, surge um terrível estado da arquitetura, mas no geral eles estão satisfeitos com tudo. O aplicativo é difícil de gerenciar, você não consegue entender o que está acontecendo lá, ele tem baixa estabilidade, trava constantemente. Em resposta ao aplicativo com falha, os desenvolvedores mantêm algo mais lá, e ele continua a cair ainda mais e, como resultado, nada é entendido.

Sysadmin DevOps

Existe algo como DevOps-sysadmin. Geralmente, esses são caras muito poderosos que se provaram bem. Eles vêm e dizem: "Gente, você não pode viver assim, estamos cansados ​​de puxar esse fluido. Agora estamos automatizando tudo, faremos o pipeline de entrega, tão doce, maravilhoso e que funcione bem. Sabemos muito bem como o aplicativo deve funcionar na produção. Muito melhor do que esses peitos escrevendo no Node.js. E sabemos o que precisa ser usado para que tudo fique perfeito. ”

Várias vezes me deparei com o fato de que essas pessoas criaram o DevOps no FreeBSD. O resultado foi um sistema fechado, que eles mesmos escreveram e somente eles entenderam como funciona. Apesar da experiência do administrador de sistemas, não consegui descobrir, mas se não consegui, como o desenvolvedor deve entender como implantar por meio desse sistema de IC? Como resultado, proibi administrativamente o uso do FreeBSD na empresa, apesar de sinceramente amar e respeitar o próprio sistema, principalmente o OpenBSD. Mas uma semana depois, entre os servidores Linux, os servidores FreeBSD começaram a aparecer novamente, como agarics.

Os administradores de sistema do DevOps, assim como os desenvolvedores, pensam que a tecnologia é a coisa mais importante, nada pode ser feito sem eles. Se eles gostam da tecnologia, tentam colocá-la em qualquer lugar.
Na Oversan-Skalaxi, criamos o termo configurações e scripts somente para gravação. É quando uma pessoa pode escrever, mas ninguém sabe ler.

Ao mesmo tempo, os administradores de sistema continuam a reparar algo no sabão. Você vem a ele e oferece ajuda, e ele lhe dá algo com um tapete de três andares. Você não entende nada, porque precisa descobrir o que ele fez. Bem, se o desenvolvedor vier e disser, por exemplo, que ele precisa de um banco de dados tolerante a falhas? Ele receberá algo com este tapete de três andares, ele se sentará e não entenderá o que fazer com ele. Todos navegados, os desenvolvedores e administradores do sistema não se comunicam. Embora no interior seja usado o mais moderno e sofisticado.

A partir daí surgiu a idéia tradicional de administradores de sistemas: essa pessoa é multirracada e faz alguma coisa, mas você não entende exatamente o que é. A propósito, a maioria dos RH agora está procurando exatamente isso. Posso garantir que encontrar uma pessoa assim na empresa não poupará 100% dos problemas.

DevOps para empresas

Outra maneira para o surgimento do DevOps é do lado comercial. Alguns de seus principais gerentes foram a uma conferência de negócios, por exemplo, ao vale, onde disseram a ele que, se você não possui o Docker, alguma integração contínua (CI) e mais alguma coisa, não pode ser considerado empresa de tecnologia. O gerente retorna, coleta funcionários e lê palavras em um notebook: DevOps, Docker, Concourse CI. Os caras começam a entender, e então os cenários mistos mencionados acima acontecem: DevOps-developer, DevOps-sysadmin, e isso tudo leva a uma bagunça que você não consegue entender.

Na verdade, eu vejo constantemente essas situações. Por que isso está acontecendo: você vem à conferência, todo mundo tem uma visão racional e normal - depois você entra nas trincheiras, na produção e depois há lixo e fumaça? Ou seja, todos entendem tudo, mas por algum motivo eles não funcionam. Eu tenho uma hipótese de que todo mundo entende alguma parte, não todas. E agora tentarei falar holisticamente sobre DevOps.

Da empresa para o Agile

Em primeiro lugar, do ponto de vista dos negócios, estamos passando por um ponto de virada: estamos nos afastando de uma empresa que está implementando projetos monumentais para transferir o negócio em si do ponto A para o ponto B (por exemplo, uma estratégia de cinco anos para capturar 70% do mercado) ...

... e venha para o mundo do Agile. O ponto do Agile não é ser flexível, mas esse ponto A é conhecido e B não. E isso é o mais profundo que pode acontecer. Porque nem nós nem os negócios estamos acostumados a trabalhar com isso. Imagine que você não sabe o que acontecerá em uma semana ou duas semanas, que o líder veio até você e disse: "Então, tente me conseguir algo que não pode ser, escreva seu nome para não esquecer com pressa" . E você não sabe o que fazer, mas o mundo e os negócios estão se tornando assim, e você precisa se acostumar. E todas essas práticas, como Agile, Scrum, Kanban, não são sobre como viver com isso.


Estamos mudando do caminho das empresas e corporações para o caminho da tecnologia. Alguns softwares estão começando a interagir conosco no mercado. Se as pessoas anteriores, as empresas interagiam conosco, os vendedores telefonavam e assim por diante, agora para chamar um táxi, pedir pizza, ouvir música, vamos ao aplicativo. E um aplicativo é um software que alguém precisa escrever e se adaptar continuamente ao mercado. E nós, engenheiros e aqueles que estão envolvidos nos negócios, precisamos entender pela aplicação o que está acontecendo com o mercado. E no final, ele nos move em direção ao DevOps.

O DevOps não aparece porque um de vocês deve se sentir confortável e não porque precisa usar tecnologias mais frias. O NoSQL não é mais legal que o SQL; além disso, é muito pior que o SQL pelo estado há 3-4 anos atrás. Os bancos de dados SQL foram desenvolvidos por 20 anos e os do NoSQL por 1 ano. E lembramos o estado deplorável do MongoDB há 4 anos, quando não era um banco de dados.


O DevOps é o mesmo de antes, só que agora estamos fazendo tudo ao mesmo tempo. Se você é um desenvolvedor, escreve código e imediatamente escreve testes, um wrapper para o Kubernetes ou apenas um contêiner do Docker, como deve funcionar na produção. E, ao fazer isso, você deve atender a uma condição mínima - execute esse código. Como muitos desenvolvedores na época anterior não fizeram isso: o compilador compilou e o que começou lá e começou a trabalhar no contêiner de aplicativos já é a décima coisa. Ao mesmo tempo, escreva métricas, logs que devem ser coletados. E então você perde tudo no Delivery Pipeline, Jenkins, TeamCity ou qualquer outra coisa. Essa é uma diferença fundamental entre um desenvolvedor de uma corporação e um desenvolvedor de uma empresa de tecnologia. Aqui, o desenvolvedor começa a escrever não apenas algoritmos, mas todo o produto.

História do DevOps

Aqui é o momento de recorrer à história do DevOps. Como tudo isso aconteceu? Eu vivi isso, li constantemente as notícias, segui a cadeia histórica, como tudo parecia. E agora pessoas diferentes de anos diferentes me dizem versões diferentes do que é o DevOps e como isso aconteceu. E me parece importante voltar às raízes.

Em 2003, Ben Trainor, do Google, criou a equipe do SRE. O Google é a primeira grande empresa digital do mundo. Já em 2003, eles enfrentaram o problema de que, da maneira clássica a que todos os desenvolvedores de software estão acostumados, eles não podem fazer o que querem. E eles inovaram ao apresentar a equipe SRE e, desde então, desenvolveram essa prática.

Em 2009, John Alspaw e Paul Hammond fizeram uma palestra sobre como trabalhar juntos no Flickr e como eles compartilham 10 vezes por dia. Naquela época, foi uma sensação e uma explosão. E Patrick Deboit espionou este relatório e cunhou o termo DevOps, organizou a comunidade mundial para desenvolver ainda mais essa prática.

Surgiram empresas de tecnologia que precisavam compartilhar rapidamente. As abordagens antigas não se encaixavam e começaram a surgir novas. E sem problemas, naturalmente, eles foram reorganizados para que tivessem uma nova prática de criação de software.

Estamos em uma situação muito difícil, porque não tivemos essa mudança natural. Tais tecnologias chegam até nós quando algo já aconteceu lá, mas ainda não sabemos como usá-las. Lá, as pessoas evolutivamente chegaram a isso, e temos que fazer uma revolução, repensar tudo isso e, de alguma forma, transformá-la em seu próprio solo.

Como aplicar o DevOps?

Ao usar o DevOps, é muito importante perceber realmente que você está criando um produto digital e que o tempo de colocação no mercado (TTM) é importante para as empresas.

É importante transformar todas as equipes em equipes de desenvolvimento. Não há mais um administrador de sistema separado, um desenvolvedor separado. Porque aqueles a quem chamamos de administradores de sistema escrevem o que é chamado de plataforma de infraestrutura, e os desenvolvedores escrevem o que é chamado de produto e, portanto, fornecem um ao outro um serviço.

Outra coisa óbvia e muito importante que todos esquecemos é a organização do acúmulo e troca de conhecimentos dentro da equipe e entre equipes. Temos grandes problemas com isso. Não gostamos de compartilhar algo que, por exemplo, ainda não está pronto, e essa é a chave para o DevOps existir. Devemos falar sobre o que não está pronto, testar hipóteses, devemos estar abertos a alguém nos dizendo que eles não estão prontos. Como estamos acostumados, por exemplo, se os administradores de sistema testavam algo interessante, vinham, disseram, eles responderam: "Não, mas como isso funciona na produção, o que você testou?"

Administradores de sistemas, percebendo que em algum lugar que eles não entenderam, em algum lugar que eles não testaram, saem, fecham, e esse conhecimento desaparece, e não damos um passo adiante. E é certo dizer: "Gente, olhe! Você fez um trabalho muito legal, ótimo trabalho, mas há uma pergunta que eu realmente quero lhe perguntar: como isso funcionará na produção? Você já pensou sobre isso? "Da próxima vez que você nos mostrar como implementar essa função na produção, será muito legal!"
Eles já estão saindo com a tarefa. E no caso de nossa abordagem clássica russa "sim não não, todo lixo", eles saem com o pensamento "por que deveríamos fazer isso se todos nós fomos recusados" . E esse é um grande problema dentro da comunidade DevOps. Não compartilhamos um com o outro, porque não temos certeza de que isso não será reconhecido como óbvio ou não tão explícito quanto parece, e assim por diante.

Já ouvi dos organizadores da conferência que todo mundo exige um mega-hardcore. Bem, talvez você não possa fazer um megahardcore, mas para que uma pessoa compartilhe experiência real e que você possa falar sobre isso, também é legal.

Developer na DevOps

O desenvolvedor do DevOps não escreve o código, mas o produto. E isso não é óbvio, porque em institutos, cursos, livros que nós, como programadores, somos ensinados a escrever algoritmos, não produtos, eles são ensinados a resolver não um problema de negócios, mas um problema algorítmico. Este é um grande problema. É muito importante em sua mente acompanhar em que ponto você está resolvendo um problema algorítmico e em que momento é um problema real de negócios.

Em uma empresa que pratica DevOps, o desenvolvedor pensa imediatamente como seu código se integrará a outros componentes. Imediatamente começa a se comunicar sobre isso. Por exemplo, para esclarecer em um bate-papo um roteiro de uma alteração de API que ele usa para verificar. Este é o começo da cooperação.

O desenvolvedor tem uma idéia sobre a arquitetura do aplicativo - isso é muito importante, pois sem entender como a arquitetura funciona, quais são as camadas tecnológicas e como elas interagem entre si, é impossível pensar em integração.

O desenvolvedor sabe como o código funciona na batalha e entende o que está acontecendo com este aplicativo. No meu exemplo, quando um desenvolvedor grava código e um contêiner do Docker e monitora ao mesmo tempo, ele deve ter uma idéia de como a arquitetura funciona, como o código funciona na produção e se integra ao aplicativo. Aqueles que trabalham como administradores de sistemas ou engenheiros de infraestrutura, pensam em como transmitir esse conhecimento aos desenvolvedores. Sua tarefa é contar a eles sobre isso. Você pode contratar consultores, mas melhor sozinho.

Engenheiro de Infraestrutura

A próxima função do DevOps é o engenheiro de infraestrutura, que anteriormente era chamado de administrador do sistema. Não gosto muito do termo "engenheiro de DevOps" porque o DevOps é uma prática comum que abrange desenvolvimento, teste e operação. Como eu disse anteriormente, você pode ter um engenheiro de DevOps, uma equipe de DevOps, a melhor tecnologia e você não tem DevOps.

Um engenheiro de infraestrutura cria uma plataforma principalmente para o desenvolvimento de produtos, mas deve ser conveniente para os desenvolvedores. Esse equilíbrio deve ser tentado em conformidade.
Um engenheiro de infraestrutura usa várias camadas de abstração para fornecer serviços. Por exemplo, houve um bom relatório de Nikolai Ryzhikov sobre Kubernetes, ele mostrou como selecionar e usar várias camadas de abstração. Ele tinha um modelo ideal lá, que é colocado em prática. Esse modelo pode ser dividido em níveis separados de abstração. Isso é feito para reduzir a complexidade da solução e integração de problemas. Quando você tem níveis compreensíveis de abstração, pode alternar entre eles e ver onde estão as discrepâncias. Você não precisa confiar em camadas de abstração, mas elas são muito úteis para falar sobre isso. Ou seja, eles não devem ser absolutos, mas úteis.

O engenheiro de infraestrutura projeta a plataforma como um produto, sabe como ser o proprietário do produto, o que é o pensamento de design, sabe como coletar requisitos dos desenvolvedores. Mas esse é um nível alto, e não tenho certeza de que esses engenheiros estejam presentes no mercado na forma de engenheiros de infraestrutura.

Tecnólogo em testes

O testador também muda um pouco e se torna um tecnólogo que alcança a melhoria da qualidade do software e transforma esse processo em código.

Gerente de Liberação / Estação de Serviço

, , . , , , .

, : , , .


, , , — . , delivery pipeline, , , .

, , , — ( ), . , — , , , , continuous delivery pipeline.

, . (- CTO) — . , — , , , .


42 base-service-app. — () . . : , load balancers, , , CI- (TeamCity Jenkins ). , API, . , , CI Kubernetes.


Processos e tecnologias são cruciais. As tecnologias que você usa, além de si mesmas, têm uma maneira de usá-lo. Por exemplo, você pode cortar pão com uma faca ou matar uma pessoa. Portanto, é aqui, apenas no nosso caso é ainda mais complicado, ainda mais níveis de abstração. Os processos que você cria em torno disso são muito importantes. E esses processos, em princípio, ninguém pode criar, exceto você dentro da empresa, porque são altamente adaptados para aplicações específicas. Agora, em princípio, é impossível que, como antes, você tenha contratado um consultor de ITIL e ele tenha implementado todos os processos para você. O aplicativo Internet Banking e o Yandex.Music são diferentes como o céu e a terra. Existem princípios gerais, mas o processo em si é completamente diferente.

, . , - : « , — » .
, , , ( , , ). Isso é muito importante.

, DevOps, , , , , (Kubernetes, Prometheus, Docker . .), , .

, DevOps- . , , , . , continuous delivery, — , , . , , , . , , , « ». , .

O momento atual difere do antigo momento da empresa em que os padrões foram pregados lá e agora eles estão mudando continuamente. Nos últimos 3-4 anos, muitas tecnologias e padrões de uso foram alterados, é inútil consertá-los em documentos, apenas na cabeça das pessoas.

Se você gostou deste relatório, venha para a conferência DevOops 2018 : lá você pode não apenas ouvir os relatórios, mas também conversar com qualquer orador na área de discussão. A conferência será realizada em São Petersburgo em 14 de outubro, a partir de 1º de setembro, o custo dos ingressos aumentará.