ESTUDO DE CASO
===
Participante: Enzo Lopes D'anjour de Souza

Nº de inscrição: 2020145

Código de validação: W_QPOEQWfeM=

###### Tags: `JFRN` `DevOps` `Docker` `Ansible` `Azure Devops` `ISO IEC 2007` `TDD` `Cucumber` `NGINX` `SonarQube` `Elastic Search` `Logstash` `Kibana`

## Descrição

### Problemática
Uma instituição possui um quadro de 500 colaboradores em sua sede. Os sistemas voltados diretamente ao negócio são desenvolvidos e mantidos por uma equipe interna, composta por 15 funcionários. Atualmente 10 sistemas web estão em produção, com expectativa para dobrar esta quantidade nos próximos 3 anos. Há uma demanda constante por aprimoramentos e correção de bugs. Indisponibilidade dos sistemas causa impacto severo nos negócios e na imagem da instituição. Alguns sistemas são de uso interno, enquanto outros são acessíveis externamente, mediante autenticação. Há ainda uma terceira categoria, composta por sistemas de acesso público. A conexão à Internet é fornecida por um provedor local. Uma rede Wi-Fi local é compartilhada por colaboradores e visitantes e utiliza a mesma infraestrutura da rede interna e de acesso à Internet.

Avaliação de riscos e estratégias para mitigação das ameaças
---

Para tal prática será necessário classificar os tipos de ativos conforme a ISO/IEC 27005.

## Ativos Primários
### Processos e atividades do negócio
Podem ser compreendidos como processos em qual a interrupção pode desencadear a interrupção do negócio.

### Informação

Pode ser compreendido como o apoio para o desempenho das atividades de negócio.

## Ativos de suporte.
### Hardware
Equipamentos físicos cruciais a operação do negócio;
### Software
Sistemas, programas, licenças que são de relevância para a operação do sistema;
### Rede
Dispositivos cujo a finalidade é interligar os hardwares a internet;
### Recursos Humanos
Todas as pessoas que estejam envolvidas com os sistemas (Pessoal de produção, Desenvolvedores, Tomadores de decisão);

## Classificação e listagem

| Ativo | Ameaças a operação visualizadas | Contramedida |
| -------- | -------- | -------- |
| Servidor Web | Configuração custosa de servidores. | Conteinerizar as aplicações e garantir a configuração da infraestrutura como código. |
| Servidor web | Queda por picos de demanda | Garantir que a infraestrutura seja bem orquestrada. |
| Redes | Invasão da rede de internet por meio do host de visitantes. | Isolar rede de trabalho da utilizada por visitantes, além de garantir a autenticação seja efetuada corretamente. |
| Redes | Indisponibilidade da internet pelo provedor local | Adição de ao menos outro provedor de internet.|
| Redes | Infraestrutura de internet ser a mesma de intranet | Aprivisionar a rede internet. |
| Sistemas | Bugs | Garantir a qualidade do código na origem com prática de TDD. |
| Sistemas | Demandas de aprimoramento | Garantir a priorização eficiente das tarefas. |
| Pessoas | Quantidade do efetivo para a quantidade de pessoas usando os sistemas e seu próximo aumento de escala | Telemetria em todos os processos e automatização de todas as partes possíveis, e, se possível, aumento de efetivo. |

Dado o mapeamento inicial a próxima etapa seria a priorização dos riscos, conforme a tolerância aos riscos que podem vir a ocorrer. Para tal mapeamento o ideal é utilizar da gravidade do risco, chance de ocorrência do risco, importância do ativo, multiplicar esses pontos e definir no próprio projeto qual é a tolerância a tais erros, desta maneira será possível priorizar adequadamente quais ameaças atacar primeiro.

Abordagem do ciclo de vida dos sistemas
---
Dado a listagem de riscos acima, como forma de mitigar grande parte dos riscos nos ativos primários, Sistemas e informação, o próximo passo será abordar algumas etapas para garantir que o ambiente de desenvolvimento e operação garanta a integridade de desenvolvimento e operação.

Nisso algumas práticas serão fundamentais.

### Definição do pipeline de implantação
Por quais etapas o software passará para sua implantação em produção? Quem serão os responsáveis por cada etapa? Qual será a taxa de tolerância a erros? Além de detalhamentos de como terão acesso a cadas etapas.

A mais testada e comum é a tradicional:
| Requisitos -->-->--> | Desenvolvimento -->-->--> | Testes -->-->-->| Homologação -->-->--> | Operação -->-->--> | Monitoramento -->-->--> |
| --------- | -------- | -------- | -------- | -------- | -------- |

Do ponto de vista da gestão de pessoas, visto que o efetivo é de 15 pessoas, dado a proporção de crescimento, que será de dobrar a quantidade de sistemas, ou seja, de 10 sistemas passar para 20 sistemas em 3 anos, deverá obrigatoriamente ocorrer a automatização dos processos. Nada melhor que algumas práticas e ferramentas de devops para assegurar e otimizar ainda mais o trabalho, garantindo a entrega de valor adequada.

Podendo ser, do ponto de vista de pessoas, a atribuição para:
| Requisitos & Homologação -->-->--> | Desenvolvimento & Testes -->-->--> | Operação & Monitoramento -->-->--> |
| --------- | -------- | -------- |

Podendo, e, do ponto de vista de processos a atribuição para:
| Requisitos & Homologação & Desenvolvimento & Testes & Operação & Monitoramento -->-->--> |
| --------- |

Pode parecer estranho tudo competer a todos, mas, se todas as ferramentas estiverem bem configuradas, existe a possibilidade. No mundo ideal, onde existe CD/CI e muito dos conceitos abaixo, isso será possivel, mas como o mundo ideal é diferente do real, deve se buscar ao máximo alcançar isso.

Aqui também se enquadram ferramentas de monitoramento de pipeline do projeto. Azure Devops é uma das mais completas, contendo todas as etapas desde a parte de tarefas, versionamento de código, testes automatizados, cd/ci, além de ser relativamente de baixo custo e facilmente configurável.

[Link para a documentação do Azure Devops](https://docs.microsoft.com/pt-br/azure/devops/pipelines/create-first-pipeline?view=azure-devops&viewFallbackFrom=vsts&tabs=java%2Cyaml%2Cbrowser%2Ctfs-2018-2)

### Definição de pronto.

A próxima etapa importante será a definição de uma tarefa estar pronta. O ideal é passar por todas etapas do fluxo acima, ainda que seja executada corretamente na sua etapa, para assim evitar que saia mal feito ou com algum erro a posteriori. Ou seja, uma tarefa deve estar testada e homologada em ambiente similar ao de produção.

Ou seja, engloba desde a criação até a eventual implementação em ambiente de produção e, caso não possível, em ambiente similar ao de produção, pois assim irá garantir que não existam gargalos, em quaisquer parte do desenvolvimento.

### CD/CI

Uma etapa muito importante é que o produto consiga "Rolar" pela esteira de produção entre as partes adequadamente. Nisso vem a configuração adequada de Deploy continuo e posterior implantação contínua, onde facilmente uma atualização conseguirá ir durante todas as etapas do ciclo de produção.

Isso reduzirá e muito os gargalos de produção, assegurando que as etapas sejam realizadas de forma a não existir entraves.

Poderá ser realizado pela definição direta no Azure DevOps, onde após a configuração será realizada realizada sem grandes entraves.

### Definição organizacional

Uma prática organizacional que vem garantindo alta produtividade e menores entraves de desenvolvimento é a estrutura em squads. Alguns autores da área relatam que normalmente em empresas pode ocorrer uma muralha que separa o mundo de DEV e o mundo de OPS, pois funcionalmente eles tem objetivos diferentes. Enquanto um quer a integridade do sistema, o outro quer a agilidade de novas funcionalidades, então seria ideal que fosse gerada essa integração entre os times.

Um squad tem em média 5-7 membros. Embora pareça pequeno, será o tamanho essencial para conseguir gerenciar as pessoas com eficiência, além de entre elas gerar uma afinidade. Assim, na medida do tempo, acabará constituindo-se uma identidade para o squad, e nisso turbinará muito a produtividade, gaantindo melhores práticas e agindo em sinergia os membros.

Outra prática que vem para agregar é a retrospectiva, que agrega muito na equipe, onde será visualizado os erros, acertos e potenciais melhorias que a equipe poderá otimizar, após uma sprint.

### Etapa do desenvolvimento
A melhor prática dado o contexto da criticidade dos sistemas além da reputação é a prática de TDD no desenvolvimento. De acordo com a Microsoft aplicar testes automatizados no desenvolvimento reduz de 40% a 90% a chance de erros em relação a projetos similares sem TDD, e custo de manter o produto sendo reduzido ao longo do tempo.

Caso o desenvolvimento seja de intuito de mantenimento/produção e não possua cobertura de testes, pode-se ir realizando nas partes que forem sendo alteradas, para no longo prazo ir aumentando a cobertura.

Outra excelente ferramenta é a de análise de código, como é o caso do SonarQube, que faz facilmente análise de vulnerabilidades, erros, dívida técnica, melhores práticas, assegurando assim um código melhor para o desenvolvedor.

[Documentação JUnit](https://junit.org/junit5/docs/current/api/)
### Lean e MVP

No contexto de entrega e aprender com as entregas, temos dois conceitos importantes, o primeiro sendo o de MVP. Por meio dele será efetuado a entrega contínua, onde os clientes conseguirão testar uma funcionalidade, se ela faz sentido para continuar com ela, melhora-la ou abandona-la.

Pode se utilizar de teste A/B, Utilizando a prática de BDD. A ferramenta Cucumber vem para o aprendizado, e, por meio do canary deploy, ficando 95% dos usuários com a versão normal, 5% com a de teste, utilizando de NGINX para balancear o tráfego, além de medir e monitorar o usuário garantindo que seja visualizado corretamente a experiência dele, obter feedback de utilização e aprimorar o produto.

[Documentação Cucumber](https://docs.cucumber.io/docs/cucumber/)

[Documentação NGINX](https://nginx.org/en/docs/)

### Automatização de Infraestrutura

Para a parte de infraestrutura, algo que será fundamental é a etapa de automatização da infra, pois algo que pode gastar muito tempo será a configuração da mesma, caso seja feita manualmente. Neste passo entrará o Ansible, para conseguir fazer com eficácia tal configuração, poupando muito tempo de trabalho da equipe de infra.

[Documentação Ansible](https://docs.ansible.com/)

### Conteinerização

Para garantir que as aplicações sejam isoladas vem o conceito de conteineres, por meio docker, que irá auxiliar e muito a subida no ambiente para produção, pois todas as partes serão bem divididas e facilmente configuráveis.

[Documentação Docker](https://docs.docker.com/)

### Telemetria dos produtos de infra.
Após essa etapa de configuração e subida dos ambientes, vem uma fase muito importante, que será a de Telemetria. Tais dados gerados não devem se restringir somente equipe de infra, mas qualquer pessoa do fluxo de geração de valor, desde desenvolvedores, até o pessoal de infra, tendo acesso aos irradiadores de qualidade de forma fácil.

Por meio de tal vem a famosa Stack ELK: Elastic Search, Logstash e Kibana, onde garantirá que o todo será monitorado. Para os produtos antigos essa migração poderá ser realizada em etapas, garantindo o total alcance e monitoramento dos sistemas.

[Documentação ELK](https://www.elastic.co/guide/index.html)

### Abordagem cultural da empresa
Por último, mas não menos importante, vem a parte da cultura, pois de nada servirá ter ferramentas poderosas e uma equipe qualificada, quando há uma dificuldade de inovação e de auto aprendizado.

Então é crucial organizacionalmente garantir que as pessoas tenham vez. Embora pareça estranho para serviços cruciais e de alta disponibilidade, é preciso que as pessoas tenham margem para errar, pois o ativo mais precioso do fluxo de desenvolvimento e entrega de valor são as pessoas. Assim, quanto mais liberdade, de forma segura, for dada, melhor o produto final sairá. Importante é saber que a liberdade sempre deverá vir acompanhada com o auxílio, para garantir que todas as partes cresçam e tornar um ambiente sadio.

Caso ocorram erros durante o desenvolvimento, não se deve esquecer da inocuidade, e, quando os erros ocorrerem, deve-se realizar a Corda de Andon, onde os membros do fluxo de entrega se reunem para resolver o problema, afinal, 2 ou mais mentes funcionam melhor que apenas uma.

Mentoria e ensino com partes iniciantes será fundamental. Uma excelente prática é o pair programming, tanto da parte de infra quanto de desenvolvimento, pois será um investimento no curto/ médio prazo, assegurando que os iniciantes tenham a qualidade de um produto de um senior, com um menor tempo para qualificação.

Outro conceito crucial é o de obeya, assegurando uma visão estratégica do fluxo de entrega do produto.

A parte de injeção de erros em dependência, vem para agregar muito e garantir que conheça mais ao próprio produto, evitando assim futuros erros. Afinal, qual produto não deseja ter um exército símio similar ao case netflix?

Conclusão
---

" **Na adversidade, uns desistem, enquanto outros batem recordes.**" - Ayrton Senna.

O atual efetivo de 15 pessoas não dará conta do trabalho, em moldes tradicionais, dada a escala das tarefas e o trabalho a ser realizado. Para isso, deverá ser realizada uma abordagem com o máximo possível de automatização e uso de inteligência na realização das tarefas. Boas práticas organizacionais são sempre muito bem vindas.

Dependendo de como estão os sistemas antigos, isso poderá ser o maior gargalo no fluxo de produção, visto que as demandas são muito numerosas, e, se mal planejados, ou até implementados com práticas próximas ao Go Horse extreme, serem uma dor de cabeça gigantesca para seu mantenimento.

É importante lembrar que não deve ser negligenciada a parte de redes, pois, atualmente, somente com a visualização superficial, existem enormes brechas de segurança, onde facilmente invasores podem se aproveitar e explorar vulnerabilidades.

## Referências:

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 27005:2011: Tecnologia da Informação - Técnicas de Segurança - Gestão de riscos de segurança da informação. 2011. 97 p.

ANICHE, Mauricio Finavaro. Como a prática de TDD influencia o projeto de classes em sistemas orientados a objetos. 2012. 75 f. Dissertação (Mestrado) - Curso de Ciência da Computação, Instituto de Matemática e Estatística, Universidade de São Paulo, São Paulo, 2012. Disponível em: https://teses.usp.br/teses/disponiveis/45/45134/tde-31072012-181230/publico/dissertacao.pdf. Acesso em: 11 de setembro de 2020.

DAVIS, Jennifer; DANIELS, Ryn. Effective Devops: Building a culture of collaboration, affinity, and tooling at scale. Sebastopol: O’Reilly, 2016. 410 p. Disponível em: https://azure.microsoft.com/mediahandler/files/resourcefiles/effective-devops/Effective_DevOps.pdf. Acesso em: 11 set. 2020.

https://www.elastic.co/guide/index.html

https://docs.docker.com/

https://docs.ansible.com/

https://docs.cucumber.io/docs/cucumber/

https://nginx.org/en/docs/

https://junit.org/junit5/docs/current/api/

https://docs.microsoft.com/pt-br/azure/devops/pipelines/create-first-pipeline?view=azure-devops&viewFallbackFrom=vsts&tabs=java%2Cyaml%2Cbrowser%2Ctfs-2018-2