Conferência para fãs do DevOps

Obviamente, isso é sobre DevOpsConf . Se você não entrar em detalhes, em 30 de setembro e 1º de outubro realizaremos uma conferência sobre a unificação dos processos de desenvolvimento, teste e operação, e se você entrar nisso, peço gato.

Dentro da estrutura da abordagem DevOps, todas as partes do desenvolvimento tecnológico do projeto estão interligadas, ocorrem em paralelo e afetam uma à outra. De particular importância aqui é a criação de processos de desenvolvimento automatizados que podem ser alterados, simulados e testados em tempo real. Isso ajuda a responder instantaneamente às mudanças no mercado.

Na conferência, queremos mostrar como essa abordagem afeta o desenvolvimento do produto. Como é a confiabilidade e adaptabilidade do sistema para o cliente. Como o DevOps altera a estrutura e a abordagem da empresa para a organização do fluxo de trabalho.

Nos bastidores

É importante saber não apenas o que diferentes empresas estão fazendo como parte da abordagem do DevOps, mas também entender por que isso é tudo. Portanto, convidamos não apenas especialistas para o Comitê de Programa, mas especialistas que veem o discurso do DevOps sob diferentes perspectivas:

• engenheiros seniores;
• desenvolvedores
• timlides;
• CTO.

Por um lado, isso cria dificuldades e conflitos ao discutir pedidos de relatórios. Se um engenheiro estiver interessado em analisar um acidente grave, é mais importante para o desenvolvedor entender como criar software que funcione nas nuvens e infra-estruturas. Mas, concordando, criamos um programa que será valioso e interessante para todos: de engenheiros a CTO.



A tarefa da nossa conferência não é apenas selecionar relatórios com mais alta tecnologia, mas apresentar o quadro geral: como a abordagem do DevOps funciona na prática, que tipo de rake você pode executar ao passar para novos processos. Ao mesmo tempo, criamos a parte do conteúdo, passando da tarefa de negócios para tecnologias específicas.

As seções da conferência permanecerão as mesmas da última vez .

• Plataforma de infraestrutura.
• Infraestrutura como um código.
• Entrega contínua.
• Feedback.
• Arquitetura no DevOps, DevOps for CTO.
• Práticas de SRE.
• Treinamento e gestão do conhecimento.
• Segurança, DevSecOps.
• Transformação de DevOps.

Chamada de trabalhos: que relatórios estamos procurando

Dividimos condicionalmente o público potencial da conferência em cinco grupos: engenheiros, desenvolvedores, especialistas em segurança, líderes de equipe e CTOs. Cada grupo tem sua própria motivação para vir à conferência. E, se você observar o DevOps a partir dessas posições, poderá entender como focar seu tópico e onde colocar ênfase.

Para engenheiros que estão criando uma plataforma de infraestrutura, é importante entender as tendências existentes, quais tecnologias são as mais avançadas agora. Eles estarão interessados ​​em se familiarizar com a experiência real do uso dessas tecnologias e trocar pontos de vista. Um engenheiro ouvirá com prazer um relatório com uma análise de algum acidente grave; nós, por sua vez, tentaremos captar e aperfeiçoar esse relatório.

Para os desenvolvedores, é importante entender um conceito como aplicativo nativo da nuvem . Ou seja, como desenvolver software para que ele funcione nas nuvens e em várias infra-estruturas. O desenvolvedor precisa receber constantemente feedback do software. Aqui, queremos ouvir casos sobre como as empresas constroem esse processo, como monitorar o desempenho do software e como funciona todo o processo de entrega.

É importante que os profissionais de segurança cibernética entendam como configurar o processo de segurança para que não pare os processos de desenvolvimento e as mudanças dentro da empresa. Os tópicos sobre os requisitos que o DevOps faz para esses especialistas serão interessantes.

Os Timlids querem saber como funciona o processo de entrega contínua em outras empresas. De que maneira a empresa foi para isso, como foram criados os processos de desenvolvimento, a garantia de qualidade no DevOps. Os colegas de equipe nativos da nuvem também são interessantes. E também - perguntas sobre a interação dentro da equipe e entre equipes de desenvolvedores e engenheiros.

Para o CTO, o mais importante é descobrir como combinar todos esses processos e ajustá-los às necessidades dos negócios. Ele garante que o aplicativo seja confiável para os negócios e para o cliente. E aqui você precisa entender quais tecnologias funcionarão sob quais tarefas de negócios, como construir todo o processo etc. O CTO também é responsável pelo orçamento. Por exemplo, ele deve entender quanto dinheiro ele precisa gastar em especialistas em reciclagem para que eles possam trabalhar no DevOps.



Se você tem algo a dizer nessas ocasiões, não fique em silêncio; envie um relatório . O prazo para a chamada de trabalhos é 20 de agosto. Quanto mais cedo você aparecer, mais tempo será para finalizar o relatório e se preparar para a apresentação. Portanto, não aperte.

Bem, se você não precisa falar publicamente, basta comprar um ingresso e vir 30 de setembro e 1º de outubro para conversar com colegas. Prometemos que será interessante e inspirador.

Como vemos o DevOps

Para entender exatamente o que queremos dizer com DevOps, recomendo ler (ou reler) minha palestra “ O que é DevOps ”. Caminhando pelas ondas do mercado, observei como a idéia do DevOps está sendo transformada em empresas de diferentes tamanhos: de uma pequena startup a multinacionais. O relatório baseia-se em uma série de perguntas, respondendo-as; você pode entender se a sua empresa está migrando para o DevOps ou se há problemas em algum lugar.

O DevOps é um sistema complexo, que deve ter:

• Produto digital.
• Os módulos de negócios que este produto digital está desenvolvendo.
• Equipes de produtos que escrevem código.
• Práticas de entrega contínua.
• Plataformas como um serviço.
• Infraestrutura como serviço.
• Infraestrutura como um código.
• Práticas de confiabilidade separadas conectadas no DevOps.
• Prática de feedback que descreve tudo isso.

No final do relatório, existe um esquema que dá uma idéia do sistema DevOps na empresa. Isso permitirá que você veja quais processos em sua empresa já estão depurados e quais precisam ser criados apenas.



Você pode assistir ao relatório em vídeo aqui .

E agora haverá um bônus: vários vídeos do RIT ++ 2019 relacionados aos problemas mais comuns da transformação do DevOps.

Infraestrutura da empresa como produto

Artyom Naumenko lidera a equipe de DevOps na Skyeng e cuida do desenvolvimento da infraestrutura de sua empresa. Ele contou como a infraestrutura afeta os processos de negócios no SkyEng: como calcular o ROI, quais métricas devem ser escolhidas para o cálculo e como trabalhar para melhorá-las.

No caminho para microsserviços

A Nixys está comprometida em oferecer suporte a projetos da web e sistemas distribuídos. Seu diretor técnico Boris Ershov contou como transferir produtos de software, cujo desenvolvimento começou há cerca de 5 anos (ou mais), para os trilhos modernos.



Como regra, esses projetos são um mundo especial, onde existem cantos escuros e antigos da infraestrutura que os engenheiros atuais não sabem sobre eles. E as abordagens uma vez selecionadas para arquitetura e desenvolvimento estão desatualizadas e não podem fornecer aos negócios o mesmo ritmo de desenvolvimento e lançamento de novas versões. Como resultado, cada versão do produto se transforma em uma aventura incrível, onde algo constantemente cai e no lugar mais inesperado.

Os gerentes de tais projetos enfrentam inevitavelmente a necessidade de transformar todos os processos tecnológicos. Em seu relatório, Boris disse:

• Como escolher a arquitetura adequada ao projeto e arrumar a infraestrutura;
• quais ferramentas usar e quais armadilhas são encontradas no caminho da transformação;
• o que fazer a seguir.

Automação de lançamento ou como entregar rapidamente e sem problemas

Alexander Korotkov é um desenvolvedor líder do sistema CI / CD do CIAN. Ele falou sobre ferramentas de automação que melhoraram a qualidade e reduziram o tempo de entrega do código na produção em 5 vezes. Mas esses resultados não poderiam ter sido alcançados com apenas uma automação; portanto, Alexander chamou a atenção para as mudanças nos processos de desenvolvimento.

Como os acidentes o ajudam a aprender?

Alexey Kirpichnikov implementa DevOps e infraestrutura no SKB Kontur há 5 anos. Por três anos, cerca de mil fakaps de diferentes graus épicos aconteceram em sua empresa. Entre eles, por exemplo, 36% foram causados ​​pelo lançamento de um release de baixa qualidade na produção e 14% foram causados ​​por trabalhos de manutenção de ferro no data center.

A obtenção de informações precisas sobre acidentes permite o arquivamento de relatórios (post-mortem), que os engenheiros da empresa conduzem há vários anos seguidos. Postmortem escreve o engenheiro de plantão, que foi o primeiro a responder ao sinal sobre o acidente e começou a consertar tudo. Por que engenheiros de tortura que combatem falsas à noite, escrevendo relatórios? Esses dados permitem que você veja toda a imagem e mova o desenvolvimento da infraestrutura na direção certa.

Em seu discurso, Alexey compartilhou como escrever um post-mortem realmente útil e como implementar a prática de tais relatórios em uma grande empresa. Se você gosta de histórias sobre como alguém estragou tudo, assista a um vídeo da apresentação.



Entendemos que sua visão do DevOps pode não coincidir com nossos pontos de vista. Será interessante saber como você vê a transformação do DevOps. Compartilhe suas experiências e visões sobre este tópico nos comentários.

Quais relatórios já aceitamos no programa?

Nesta semana, o Comitê de Programa adotou quatro relatórios: sobre segurança, infraestrutura e práticas de SRE.

Talvez o tópico mais doloroso da transformação do DevOps: como garantir que os funcionários do departamento de segurança da informação não arruinem as conexões já construídas entre desenvolvimento, operação e administração. Algumas empresas ficam sem um departamento de segurança da informação . Como, então, garantir a segurança das informações? Isso informará Mona Arkhipova do sudo.su. Com o relatório dela, aprendemos:

• o que e de quem é necessário proteger;
• quais são os processos de segurança de rotina;
• Como os processos de TI e IS se cruzam
• o que é CIS CSC e como implementá-lo;
• como e por quais indicadores realizar verificações regulares de SI.

O próximo relatório aborda o desenvolvimento da infraestrutura como código. Reduza a quantidade de rotina manual e não transforme todo o projeto em caos, isso é possível? Maxim Kostrikin, da Ixtens , responderá a essa pergunta. Suas empresas usam o Terraform para trabalhar com a infraestrutura da AWS. A ferramenta é conveniente, mas a questão é como usá-la para evitar a aparência de um grande bloco de código. A manutenção desse patrimônio custará cada vez mais a cada ano.

O Maxim mostrará como os padrões de posicionamento de código destinados a simplificar a automação e o desenvolvimento funcionam.

Ouviremos outro relatório sobre a infraestrutura de Vladimir Ryabov, da Playkey . Aqui falaremos sobre a plataforma de infraestrutura e aprenderemos:

• como entender se a capacidade de armazenamento está sendo usada com eficiência;
• quantas centenas de usuários podem receber 10 TB de conteúdo se apenas 20 TB de armazenamento forem usados;
• como compactar dados 5 vezes e fornecê-los aos usuários em tempo real;
• como em tempo real para sincronizar dados entre vários data centers;
• como excluir qualquer influência de usuários um sobre o outro no uso seqüencial de uma máquina virtual.

O segredo dessa mágica está na tecnologia ZFS para FreeBSD e seu mais recente fork do ZFS no Linux . Vladimir compartilhará casos da Playkey.

Matvey Kukuy, do Amixr.IO, está pronto para contar com exemplos da vida o que é o SRE e como isso ajuda a construir sistemas confiáveis. O Amixr.IO transmite incidentes de clientes através de seu back-end, dezenas de equipes de serviço em todo o mundo já resolveram 150 mil casos. Na conferência, Matvey compartilhará estatísticas e insights que sua empresa acumulou, resolvendo problemas de clientes e analisando fakapy.

Mais uma vez, peço que você não seja ganancioso e compartilhe sua experiência com o DevOps-samurai. Inscreva -se no relatório e teremos 2,5 meses para preparar uma excelente apresentação. Se você quer ser ouvinte, assine o boletim informativo com atualizações do programa e pense seriamente nos bilhetes de reserva antecipada, porque eles subirão de preço mais perto das datas da conferência.