Mantenha o foco em entregar valor com DevOps, SRE e FinOps

Nesse texto irei trazer algumas coisas que demorei a aprender na trilha que segui de desenvolvimento de software, talvez por não ter seguido um caminho mais “tradicional”, ou talvez porque não se vê tantos holofotes/clickbaits sobre esses assuntos para quem escolheu o caminho de transformar café em código.

Quantos blogs sobre a melhor forma de usar a memória na tecnologia X você já viu? Um vídeo sobre melhor estrutura de dados para o problema Y? Alguém falando no passarinho azul que você deveria prestar atenção nas melhorias assintóticas?

Mas quantos falam sobre confiabilidade? Ou sobre maximizar o retorno sobre o investimento? Que te ensinam a transformar o seu ambiente para que todos trabalhem focados em entregar valor?

Talvez o que tenha me levado a ser um programador um cado melhor não foi saber extrair até a última gota de suco que um framewok pode dar, talvez tenha sido algo mais simples, talvez até mais obvio, talvez tenha sido o fato de eu ter aprendido que devemos resolver o problema considerando a perspectiva do usuário/cliente e a perspectiva de quem paga para manter o sistema de pé.

Aqui entra o kit de ferramentas que no início costumamos deixar para trás, e, estranhamente, depois temos um certa resistência em voltar para buscar esse tal kit, ou simplesmente, talvez por conta de como a mídia/mercado lida com ele, não damos a devida atenção, apesar disso, esse kit é o que traz a transformação. Aqui entram as ferramentas que vem com a cultura DevOps, as práticas de SRE e os princípios do FinOps.

A cultura DevOps

Muito se fala em DevOps, mas colocar toda a teoria em pratica não é trivial. Você facilmente verá vagas DevOps que estarão pedindo conhecimentos em alguma FERRAMENTA de CI/CD, FERRAMENTA disso e FERRAMENTA daquilo. Talvez por isso que essa “cultura”, quase que ironicamente, tem ficado distante do mundinho das pessoas desenvolvedoras, onde muitas vezes ainda se joga o pacotinho por cima do muro, onde o detentor do conhecimento sobre a FERRAMENTA de sustentação que acaba ficando com a carga da operação.

O DevOps até pode ser isso sim, todavia, como cultura, deve ajudar a alinhar pessoas, processos e ferramentas para um foco mais direcionado ao cliente. Como cultura, não deve ser de um time, não deve ser de uma pessoa. Você, todos os dias, pode praticar essa cultura, você pode ser a pessoa que está em busca de aumentar a transparência, a comunicação e a colaboração.

Algumas das principais práticas de DevOps incluem:

1. Colaboração: DevOps enfatiza a necessidade de as equipes trabalharem juntas de forma integrada, quebrando silos e promovendo uma cultura de colaboração entre os departamentos.
2. Integração: DevOps incentiva a integração das equipes de desenvolvimento e operações, permitindo uma comunicação e coordenação mais suaves durante todo o ciclo de vida do desenvolvimento de software.
3. Automação: DevOps enfatiza o uso de ferramentas e processos de automação para agilizar o desenvolvimento, teste e implantação, reduzindo a probabilidade de erro humano e melhorando a eficiência.
4. Integração Contínua: DevOps promove a integração contínua de alterações de código, permitindo que as equipes detectem e resolvam problemas no início do processo de desenvolvimento.
5. Entrega contínua: o DevOps enfatiza a importância da entrega contínua, permitindo que as equipes lancem software com rapidez e confiança.
6. Continuous Deployment: DevOps promove o uso de continuous deploy, permitindo que as equipes liberem alterações de código de forma automática e contínua, sem a necessidade de intervenção humana.
7. Teste: DevOps enfatiza a necessidade de testes completos durante todo o ciclo de vida do desenvolvimento de software, garantindo que o software seja confiável, seguro e de alta qualidade.
8. Monitoramento: o DevOps enfatiza a importância do monitoramento de software na produção, permitindo que as equipes detectem e resolvam rapidamente os problemas à medida que surgem.
9. Segurança: DevOps coloca uma forte ênfase na segurança em todo o ciclo de vida do desenvolvimento de software, garantindo que o software esteja seguro e protegido contra ameaças potenciais.
10. Aprendendo com as falhas: DevOps promove uma cultura de aprendizado e melhoria contínua, incentivando as equipes a aprender com as falhas e fazer melhorias iterativas ao longo do tempo.
11. Melhoria do trabalho diário: DevOps incentiva as equipes a melhorar continuamente seus processos de trabalho diários, buscando maior eficiência e eficácia em todos os aspectos do ciclo de vida do desenvolvimento de software.

Referências:

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win

The Unicorn Project

As práticas de SRE

SRE vai no mesmo caminho de DevOps, dado que o próprio Google inicia o livro com class SRE implements interface DevOps não seria surpresa esse caminho, contudo não se trata de manter FERRAMENTAS de observabilidade ou FERRAMENTA XPTO, tampouco pra ser a operação com uma nova roupagem. SRE emerge das práticas de engenharia para mudar todo o ciclo de vida de desenvolvimento de sistemas (SDLC). No kit de ferramentas de SRE você vai ter o seu usuário/cliente no centro da discussão. Você vai aprender que a esperança não é uma estratégia, então, com isso, você precisa responder a seguinte pergunta: com que seus usuários/clientes se importam? Se você não tem esse resposta, não adianta nenhum código, não adianta nenhuma metodologia ágil hypada. Sem essa resposta é tiro no escuro. Em suma, aqui você vai adquirir ferramentas para construir o projeto confiável e manter-lo saudável em produção.

SLA

Se alguma demanda chegou para ser feita sem que fique claro a volumetria, tempo máximo que uma operação pode ser executada e quantidade de erros máximos tolerados (existem muitos outros SLIs, mas não é o foco aqui), provavelmente não estamos com um SLA bem definido, ou seja, provavelmente não estamos nos esforçando para ter uma métrica que corresponda, mesmo que de forma imprecisa, a satisfação do nosso usuário/cliente. Sem SLA não estaremos prontos para criar mecanismos de defesa(SLO) para que os problemas não impactem negativamente a receita.

Algumas das principais práticas do SRE incluem:

• Objetivos de nível de serviço (SLOs): defina objetivos claros e mensuráveis para a disponibilidade, latência e desempenho de seus sistemas.
• Orçamentos de erro: Use SLOs para definir orçamentos de erro, que definem o nível aceitável de degradação do serviço que pode ocorrer sem afetar os usuários.
• Automação: Automatize o máximo possível para reduzir o risco de erro humano e melhorar a confiabilidade.
• Monitoramento: Monitore seus sistemas continuamente para detectar e diagnosticar problemas rapidamente.
• Resposta a incidentes: Desenvolva um processo de resposta a incidentes claro e bem documentado para minimizar o tempo de inatividade e mitigar o impacto das falhas.
• Revisão pós-incidente: Conduza revisões completas pós-incidente para identificar as causas principais das falhas e evitar que elas ocorram novamente no futuro.

Referências:

Engenharia de Confiabilidade do Google: Como o Google Administra Seus Sistemas de Produção

The Site Reliability Workbook: Practical Ways to Implement SRE

Seeking Sre: Conversations about Running Production Systems at Scale

Database Reliability Engineering: Designing and Operating Resilient Database Systems

Microsserviços Prontos Para a Produção: Construindo Sistemas Padronizados em uma Organização de Engenharia de Software

Os princípios do FinOps

É uma prática comum no mercado que a gestão do custo da nuvem seja centralizada em uma área. Essas informações de custo são passadas ao setor financeiro, que tenta se manter atualizado sobre o custo dos próximos meses da nuvem.

Assim como na era Dev vs Ops, já ficou claro que essa fluxo não é sustentável, precisamos nos conscientizar que nossas aplicações são (ou deveriam ser) da responsabilidade de quem constrói, lembra “you build it, you run it”?, então por que a responsabilidade sobre custos e de como maximizar o retorno sobre o investimento não deveria ficar com quem desenvolve?

Mudança cultural

Existe toda uma jornada FinOps para ser aplicada, e assim como DevOps, também há uma barreira cultural. FinOps trata de remover silos e bloqueadores, capacitar os times de engenharia para fornecer melhores recursos, aplicativos e migrações com mais eficiência; também traz uma conversa multifuncional sobre onde e quando investir, deixando claro para todos porque estão tomando essas decisões.

Aqui estão alguns dos princípios-chave do FinOps:

• Responsabilidade: Cada equipe e indivíduo deve ser responsável pelos custos que incorrer.
• Responsabilidade: Equipes e indivíduos devem ser responsabilizados por seus gastos e devem ter visibilidade do impacto de suas decisões no orçamento geral.
• Proatividade: é importante identificar e resolver possíveis problemas de custo antes que eles se tornem um problema.
• Eficiência: Otimize os gastos usando os recursos mais econômicos e eliminando o desperdício.
• Transparência: tornar os custos visíveis e compreensíveis para todos na organização.
• Colaboração: promova a colaboração entre as equipes para garantir que os custos sejam gerenciados de forma eficaz em toda a organização.

Referências:

FinOps Foundation — What is FinOps?

AWS Cloud Financial Management

Cost Optimization Pillar — AWS Well-Architected Framework

Conclusão:

Devemos lembrar que a programação é uma forma de resolver problemas, e não um fim em si. Se ficarmos presos na obsessão pela otimização prematura e pelo conhecimento técnico detalhado, podemos perder de vista o objetivo principal: entregar valor para o usuário/cliente. As práticas DevOps, SRE e FinOps podem nos ajudar a manter o foco nesse objetivo, trabalhando em equipe, criando soluções eficientes e com custos controlados.

Por fim, gostaria de deixar um último pensamento:

“O software é uma arte. É algo que requer habilidade, paciência e dedicação. É um processo contínuo de aprendizado, erro e correção. E acima de tudo, é um processo colaborativo, que exige a contribuição de muitos para alcançar o sucesso.” — Linus Torvalds

Espero ter contribuído com algumas ideias para a sua jornada como pessoa desenvolvedora. Lembre-se sempre de manter o foco no usuário/cliente, trabalhar em equipe e buscar o aprendizado constante. E acima de tudo, não se esqueça de tomar um café de vez em quando para manter as ideias fluindo!