A cultura DevOps nasceu da necessidade de uma melhor colaboração entre as equipes de desenvolvimento e operação na área de TI. Mesmo que suas funções sejam complementares, existe uma contradição objetiva entre as duas partes: uma é responsável por trazer mudanças e novas funcionalidades; a outra, por manter as aplicações disponíveis e estáveis.

Em fevereiro de 2001, foi criado o Manifesto Ágil, que aos poucos foi se disseminando pela indústria de software. Seus princípios são:

• → Indivíduos e interações mais que processos e ferramentas;
• → Software em funcionamento mais que documentação abrangente;
• → Colaboração com o cliente mais que negociação de contratos;
• → Responder a mudanças mais que seguir um plano.

O desenvolvimento ágil pressupõe a construção de softwares de maneira colaborativa, apostando no empenho de equipes multidisciplinares. Esse modelo se opõe ao desenvolvimento tradicional, no qual os processos eram executados em cascata, ou seja, uma etapa só podia começar quando outra era finalizada.

Em 2009, oito anos depois, em uma conferência chamada Velocity Conference, uma das palestras foi a "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr", ministrada por John Allspaw e Paul Hammond. Entre os participantes estava Patrick Debois, que já estudava formas de integrar times de desenvolvimento e operação. No mesmo ano, Debois organizou o primeiro DevOps Days e sacramentou o termo pelo mundo.

Um dos objetivos da cultura DevOps é maximizar o valor das entregas e fazê-las de forma contínua ao cliente/negócio. Além disso, é importante também gerar indicadores de modo a metrificar o que é importante em relação aos objetivos do negócio.

Com isso em mente, as equipes convergem para que esses objetivos sejam atingidos através de ciclos ágeis.

A observabilidade é a capacidade de observação fornece visibilidade profunda em aplicativos modernos distribuídos para identificação e resolução de problemas mais rápidas e automatizadas.

• Exemplos:
• → Logs: ELK
• → Métricas: Zabbix e Prometheus
• → Traces e APM: Jaeger, X-ray

A sigla SRE vem do inglês Site Reliability Engineering (Engenharia de Confiabilidade de Sites). É uma metodologia que foi desenvolvida pelo Google, pautada em alguns princípios do DevOps e com alguns pilares definidos como, por exemplo: disponibilidade, latência, performance, confiabilidade e monitoração. Ou, como dizem os engenheiros que desenvolveram a metodologia: SRE é o que acontece quando você pede para um engenheiro de software projetar um time de operações.