Temos o prazer de anunciar uma grande parceria no DevOps Survey Brasil 2019. A 4Linux está vindo como parceiro estratégico no no objetivo de entender como está sendo aplicado DevOps e o ecossistema em torno dele nas organizações no Brazil: 4Linux.

Como parte da parceria, todos que preencheram a pesquisa até o dia ³⁰⁄₀₆ concorrem à dois cursos EAD de uma das principais empresas de treinamento em tecnologias e práticas relacionadas a DevOps. Para preencher a pesquisa, clique no link:

• http://bit.ly/devops_2019

Referências:

• https://blog.4linux.com.br/devops-survey-brazil-2019/

Quer saber um pouco mais sobre o Workshop sobre Blameless Postmortem, entre em contato conosco:

• https://www.maburix.com/contact/

Um texto de 2017 tem uma introdução sobre Blameless e Postmortem.

Autor: Fernando Ike

Nos dias 24 e 25 de Maio aconteceu o DevOpsDays Porto Alegre 2019, é o DevOpsDays no Brasil com mais edições. DevOpsDays é um evento sobre DevOps realizado em diversas cidades no mundo, ele é um evento de comunidade para comunidade que discute, debate e propõe temas, métodos e técnicas para além de ferramenta. Se você tiver numa cidade com um DevOpsDays, não deixe de participar.

Eu tive a honra de participar como palestrante falando “Depressão e o que ela afeta os profissionais de TI”, a apresentação teve como tópico central como as pessoas que trabalham praticamente só com a mente são afetados pelos ambientes de trabalho e qual o impacto de uma doença como Depressão, Crise de Ansiedade ou Burnout as pessoas e organizações. A mini descrição da apresentação:

Não importa se a organização é uma startup descolada uma empresa tradicional, elas devem ter políticas para manter a boa saúde mental de seus colaboradores, principalmente os profissionais de TI que basicamente são “trabalhadores da mente”. Esta apresentação é uma reflexão de como alguns tipos de configuração de ambiente de trabalho não beneficiam a saúde mental, métricas abusivas de produtividade a saúde mental dos profissionais de TI e algumas formas de mitigá-las.

Se quiser saber um pouco mais como foi a apresentação, basta ver aqui embaixo.

Esta apresentação é baseada no texto “A depressão e a TI“

Autor: Fernando Ike

Esta é uma das perguntas recorrentes que nos fazem, este é um ensaio sobre DevOps e requisitos funcionais e não-funcionais. Mas antes de tudo, vamos primeiramente definir o que é Requisito Funcional:

“Os requisitos funcionais são características que um software deve ter para atender ao que usuário precisa para realizar sua tarefa ou trabalho”

O MITRE é famoso pela base dados sobre vulnerabilidade de diversos softwares ao longo de muitos anos, contudo eles têm uma documentação muito rica sobre Desenvolvimento de Software, Operação de TI e Segurança. O documento “The MITRE Systems Engineering Guide” tem uma definição excelente sobre o tema: “Requisitos funcionais estão associados à capacidade/aplicação necessária para suportar diretamente os usuários na realização das suas missões/tarefas (funcionalidades, componentes, etc.)“.

Definido o que é Requisito Funcional, alguns anos atrás a minha definição sobre DevOps era “DevOps significa uma cultura para permitir que as organizações (e a TI) alterarem seus processos, transformando-as de organizações de baixa para alta performance”. Desde então esta definição precisava ser um pouco mais detalhada para - “***DevOps é uma mudança cultural na cultura de TI com foco entrega rápida de serviços aplicando práticas de Agile, Lean, SRE e Safety Culture orientado a propósito do negócio. Ele é implementado através de ferramentas que automatizam processos, possibilitando a experimentação, a aprendizagem com foco nas pessoas e cultura.***”

Observando as definições sobre DevOps e Requisitos Funcionais não há uma relação direta entre eles, certo? realmente não há. Ainda que fosse realizado um esforço de simplificação do termo um esforço de simplificação hipotética do significado do termo DevOps para somente ser uma ferramenta de Continuous Delivery (Entrega Contínua), orquestração de nuvem ou monitoramento aplicando conceitos de Observability não poderia ser considerado qualquer uma destas derramentas ou melhor, os serviços providos por elas como requisito funcional porque nenhuma delas representam diretamente a entrega de funcionalidades para o usuário/cliente.

Isso pode parecer um pouco estranho porque poderia argumentar que o todas elas ajudam entregar um melhor serviço, resiliência e disponibilidade. Contudo, nenhum deles está relacionado de fato com entrega de fato, porque eles dão o suporte o que se entrega ao usuário/cliente. Ou seja, eles estão indiretamente relacionado as funcionalidades que serão entregues aos usuários/clientes. Exceto se eles forem o escopo da entrega.

DevOps não pode ser considerado como Requisito funcional, mas poderia ser considerado como Requisito Não Funcional?

Recorrendo novamente ao “The MITRE System Engineering Guide”, ele define Requisito Não Funcional como - “… é um requisito que com critérios específicos can pode ser usado para julgar a operação de um sistema, ao invés de comportamentos específicos. Pode se tratar de uma propriedade que o produto final deve ter, padrões pelos quais devem ser criados ou o ambiente que deve existir. Exemplos são usabilidade, facilidade de manutenção, extensibilidade, escalabilidade, reusabilidade, segurança e portabilidade”.

Considerando a definição no início do texto sobre DevOps, ele também não poderia ser definido como Requisito Não Funcional, isso porque ele está relacionado a mudança cultural. Se levarmos em consideração que algumas organizações consideram DevOps como uma função de trabalho (exemplo: DevOps Engineering), torna-se um pouco estranho porque DevOps deixaria de ser um requisito funcional e/ou não funcional para se tornar um usuário/cliente que solicita funcionalidades funcionais e não funcionais. Equipes ou funções de trabalho que são consideradas DevOps são disfuncionais do ponto de vista da organização mas este tema sobre equipes será melhor discutido em outro texto.

Contudo, há uma maneira de ver DevOps como parte indireta das entregas como parte de Requisitos Não Funcionais quando aplicado a ferramentas/serviços ou arquitetura de sistema. Exemplo:

Uma aplicação de autorização de compra de um E-Commerce deve ser resiliente, ter a maior disponibilidade possível e desempenho para suportar picos de tráfego como Black Friday e campanhas promocionais. Uma das abordagens para entregar seria usar Orquestradores de containers como Kubernetes instalado em diferentes datacenters, ou melhor, em diferentes regiões de disponibilidade e se o E-Commerce estiver num IaaS, o site também deverá adotar arquitetura de Micro Serviços, criptografia end-to-end, etc.

Considerando que a organização estipulou algumas métrica para o E-Commerce de:

• SLA de disponibilidade é de 99% e SLO de 99,7%
• SLO 90% para latência de 500 milisegundos para autorizações de compra.
• 100% dos deploys em produção deverão passar sem erros nos Testes Unitários, de Sistema, Integração no ambiente de homologação. Como também deverão passar com score mínimo B nos testes de maturidade e manutenção de código.
• A plataforma onde será realizado o Deploy será o Kubernetes porque o desenvolvimento foi realizado em containers
• Cada deploy deverá ocorrer com um Side Car junto a aplicação porque o ambiente de produção está configurado com uma rede Service Mesh.
• Cada Micro Serviço deverá ter ao menos duas instâncias em cada região de disponibilidade do provedor de nuvem (IaaS) e healthcheck.
• Cada Micro-Serviço deverá diferentes níveis de logs e os mesmos deverão ser enviados para um serviço de Correlacionamento de Eventos, como também, para de monitoramento.
• Não poderá esquecer de implementar em cada Micro Serviço a biblioteca do Serviço de Profiler usado pela organização para aplicar os conceitos de Observability.

Os Requisitos Não Funcionais solicitados pelo E-Commerce estão diretamente relacionado à várias ferramentas, serviços e conceitos que tornaram-se populares com DevOps. Apesar dele não ser considerado diretamente como parte de Requisitos Funcionais e Não Funcionais, DevOps influenciam diretamente a entrega deles para os usuários/clientes com potencial de maior qualidade, resiliência, disponibilidade e segurança usando diversas ferramentas, métodos e técnicas relacionadas a DevOps.

Comentem. :)

Autor: Fernando Ike

Nós gostaríamos de entender melhor como as práticas relacionadas a DevOps estão sendo aplicadas nos diferentes tipos de organizações no Brasil, como também, entender como é a cultura DevOps em cada uma. Ao final da pesquisa vamos liberar a nossa visão sobre os dados coletados juntamente com os parceiros participantes. Para responder a pesquisa não deve tomar muito do seu tempo, nossa estimativa é de mais ou menos 8 minutos.

• http://bit.ly/devops_2019

Dúvidas sobre a pesquisa ou ajudar na divulgação, entre em contato:

• https://www.maburix.com/contact/

Autor: Fernando Ike

Autor: Fernando Ike