Conceitos de DevOps e SRE
Tags: devops, sre, guiadeinfra
Published: 2020-07-31 20:59:58

---
canonical_url: https://medium.com/sysadminas/conceitos-de-devops-e-sre-bbb05bb3c9fe
---

Existem algumas disciplinas, frameworks e conjuntos de práticas que são seguidos na área de infra com o intuito de auxiliar os times a melhorar a sustentação e gerenciamento de seus serviços.

A fim de dar um exemplo prático, um time pode utilizar elementos da cultura DevOps para organizar os processos de entrega de software, os quais podem envolver uma integração contínua ou um bom nível de monitoramento, por exemplo. Além disso, também há empresas que adotaram recentemente a disciplina SRE para trazer confiabilidade para os sistemas.

A escolha de seguir a cultura DevOps ou a disciplina SRE vai depender da abordagem que a organização quer seguir.

Logo abaixo, vamos detalhar um pouco sobre o que é a cultura DevOps e a disciplina SRE. 

## DevOps

O termo DevOps é derivado da junção das palavras **Dev**elopment (Dev) e **Op**erations (Ops), que, em português, significam Desenvolvimento e Operações.

A cultura DevOps tem como objetivo fazer com que os times automatizem e monitorem todas as fases do desenvolvimento de software. Essa prática auxilia as empresas no processo de lançamento de novas versões de aplicações, pois eles geralmente são feitos em ambientes padronizados, em ciclos de desenvolvimentos mais curtos e mais frequentes, o que reduz o impacto na estabilidade da aplicação.

Nesse modelo, as equipes, geralmente de desenvolvimento e operações, compartilham processos e planejam o trabalho em conjunto, de modo com que consigam alinhar metas para alcançar sucesso no objetivo final.

**Práticas da cultura DevOps**

Neste tópico, estão listadas algumas práticas da cultura Devops, ele foi escrito com base no artigo [What is DevOps?](https://azure.microsoft.com/pt-br/overview/what-is-devops/#practices), da Microsoft.

**Controle de versão**: Através do controle de versão, é possível ter o histórico de todas as alterações feitas no código, além de permitir que várias pessoas desenvolvedoras trabalhem juntas na criação de um projeto. Atualmente, o [Git](https://git-scm.com/) é muito utilizado como sistema de controle de versão.

**Continuous Integration (CI)**: A Integração Contínua é uma prática presente no processo de desenvolvimento de software, em que as pessoas desenvolvedoras enviam as alterações feitas no código para um repositório central. Em seguida, esse código é compilado e testado (teste de unidade, teste de integração, entre outros). Esse processo pode acontecer várias vezes ao dia e, dessa forma, é possível garantir que problemas no código serão encontrados de maneira automática, facilitando a rastreabilidade e correção.

**Continuous Delivery (CD)**: A Entrega Contínua é um processo da engenharia de software que permite que o software desenvolvido, integrado e testado via CI seja colocado em produção de maneira ágil, segura e automatizada. 

**Infraestrutura como código (Infra as Code)**: Esse recurso permite aos times codificar as definições para gerenciar recursos de infraestrutura. Seus códigos geralmente são versionados, para que, sempre que necessário, sejam revisados e alterados. A infra como código anda em conjunto com o gerenciamento de configuração.
Confira mais sobre esse tema no tópico sobre [Infra as Code](https://dev.to/sysadminas/infrastructure-as-code-iac-413p).

**Gerenciamento de configuração**: Ao utilizar ferramentas de gerenciamento de configuração, é possível alterar os recursos de tecnologia como máquinas físicas, virtuais e bancos de dados de maneira controlada, o que diminui o risco de falhas humanas. Utilizar esse recurso facilita a administração de ambientes em qualquer escala.

**Monitoramento**: O monitoramento geralmente é feito com o objetivo de garantir com que os times tenham visibilidade completa da aplicação de ponta a ponta, de modo que possa ser possível identificar problemas ou desvios de comportamento o mais rápido possível. Pode-se ter visāo da sua aplicação através da coleta de logs e métricas de código e infraestrutura, por exemplo.
Confira mais sobre esse tema no tópico sobre [observabilidade](https://dev.to/sysadminas/observabilidade-4ome).

**Desenvolvimento de Software Ágil**: A metodologia ágil permite uma maior colaboração dos times envolvidos, bem como uma maior adaptação a mudanças na aplicação, pois os ciclos de desenvolvimentos são curtos e incrementais. Geralmente, times que seguem a metodologia agile conseguem atender às necessidades dos clientes de maneira contínua e rápida, diferente de outras metodologias, como a cascata, a qual tem um ciclo de desenvolvimento e entrega mais longo e sequencial.

## Site Reliability Engineering (SRE)

O conceito de SRE foi criado por Ben Treynor, em 2003, no Google. Na época, ele tinha como objetivo liderar um time de sete pessoas, o qual suportaria os sites do Google.

Segundo Ben Treynor, o SRE foca na confiabilidade do sistema, pois ele acredita que, a partir disso, é possível criar novas funcionalidades ou até mesmo novos produtos de maneira eficiente.

Um time de SRE é composto por pessoas de engenharia de software que geralmente tem skills voltadas para desenvolvimento e também sobre administração de sistemas. Essas pessoas dāo sustentação para as aplicações e também automatizam trabalhos que seriam feitos manualmente por uma analista de infra ou sysadmin, por exemplo. Eles geralmente gastam 50% do tempo em atividades operacionais e 50% do tempo criando ferramentas para automatizar tarefas.

Para gerenciar e calcular a disponibilidade dos serviços de maneira clara e correta, os SREs usam um conceito chamado de “objetivos de nível de serviço”, descrito no capítulo 4 do livro [Site Reliability Engineering](https://landing.google.com/sre/sre-book/chapters/service-level-objectives/).

O SLA e SLO determinam as premissas dos níveis de serviço, estabelecendo as métricas e indicadores que devem ser utilizados para atingir os objetivos que foram acordados.

SLA ou Service Level Agreement é um meio formal de destacar as métricas e resultados mensuráveis que o cliente espera receber e que o fornecedor precisa entregar com relação ao serviço prestado. Um exemplo de SLA pode ser um acordo de 99,8% de disponibilidade de um serviço de cloud.

SLO ou Service Level Objectives sāo características mensuráveis que estão dentro do SLA. Alguns exemplos de SLO sāo: tempo de resposta, disponibilidade ou qualidade do serviço ou aplicação.

Se você deseja saber mais sobre DevOps e SRE, acompanhe as dicas abaixo:

**Sugestões de livros**
[Building Secure & Reliable Systems](https://landing.google.com/sre/books/), de Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski e Adam Stubblefield, da  Editora: O’Reilly;
[The Site Reliability Workbook](https://landing.google.com/sre/books/), de Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara e Stephen Thorne, da Editora: O`Reilly;

[Site Reliability Engineering](https://landing.google.com/sre/books/), de Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy, da Editora: O`Reilly;
[Systems Performance: Enterprise and the Cloud](http://www.brendangregg.com/sysperfbook.html), de Brendan Gregg, da editora Pearson
[Pro Git](https://git-scm.com/book/en/v2), de Scott Chacon and Ben Straub.

**Sugestões de cursos** 
[Continuous Integration (CI) and Continuous Deployment (CD)](https://www.edx.org/course/continuous-integration-and-continuous-deployment), em inglês, da Microsoft;
[Introdução ao DevOps e SRE](https://training.linuxfoundation.org/training/introduction-to-devops-and-site-reliability-engineering-lfs162/) da Linux Foundation.

**Sugestão de certificação gratuita de Scrum**
[Certificação gratuita de Scrum Fundamentals](https://www.scrumstudy.com/certification/scrum-fundamentals-certified), da Scrum Study.

Caso conheça outras indicações de livros, certificações ou cursos, fique à vontade para deixar nos comentários. Ficarei feliz em adicionar a esse post!

*Esse texto faz parte do Guia de Infraestrutura de Tecnologia da Informação publicado no [Medium](https://medium.com/sysadminas/guia-de-infraestrutura-de-ti-30543bfe9922), no [dev.to](https://dev.to/sysadminas/guia-de-infraestrutura-de-ti-4m14), e na Open Library. Para checar todos os capítulos, clique [aqui](https://dev.to/sysadminas/guia-de-infraestrutura-de-ti-4m14) e acesse a Introdução.*