Há algum tempo venho me perguntando se todo o arcabouço de boas práticas de gerenciamento de serviços, encabeçado pelo ITIL, continua sendo uma referência de primeira linha em empresas de ponta, também conhecidas como Big Techs.

Empresas como Google, Amazon, Netflix, Meta (Facebook) e Microsoft operam serviços em escala global que exigem altos níveis de confiabilidade, agilidade e eficiência.

Tradicionalmente, frameworks como ITIL e COBIT, normas como ISO/IEC 20000 e abordagens modernas como DevOps e SRE (Site Reliability Engineering) têm sido referência em ITSM (IT Service Management).

Dificilmente conseguimos fazer um benchmark dessas empresas para entender como funcionam suas entranhas em termos de governança e gestão de serviços.

Mas com uma boa pesquisa usando dados públicos é possível chegar em algumas suposições.

O meu propósito neste artigo é explorar a prática real dessas organizações para revelar quais frameworks e metodologias estão efetivamente moldando o futuro do gerenciamento de TI, mesmo que ainda não estejam encapsuladas em frameworks formais.

A evolução dos frameworks Tradicionais de gerenciamento de TI (ITSM)

ITIL: adaptação à era ágil

O ITIL tem sido amplamente adotado historicamente como guia de melhores práticas em gerenciamento de serviços de TI.

Permanece uma referência importante, mas evoluiu para se alinhar com a agilidade exigida pelas empresas modernas. A versão mais recente, ITIL4, incorporou metodologias ágeis e DevOps em seus princípios.

O ITIL 4 enfatiza conceitos de “High-Velocity IT” (TI de alta velocidade) para integrar práticas modernas de desenvolvimento e operação contínua. Por exemplo, o ITIL 4 redefine práticas de gerenciamento de mudanças para “change enablement”, focando menos em controle burocrático e mais em entregar valor com rapidez e segurança – alinhando-se a abordagens DevOps e Lean.

Em outras palavras, o ITIL 4 passou a abraçar Agile, DevOps e Lean como parte de suas recomendações, reconhecendo a necessidade de automação e descentralização de decisões para acompanhar a velocidade dos negócios digitais.

Isso indica que o ITIL não foi abandonado, mas sim adaptado. Continua fornecendo uma base sólida de práticas, porém agora servindo como complemento a métodos ágeis/DevOps em vez de um modelo rígido isolado.

COBIT: governança de TI nas big techs

O COBIT, por sua vez, permanece relevante principalmente no âmbito de governança de TI corporativa. Esse framework, mantido pela ISACA, foca em controle, conformidade e alinhamento estratégico de TI com o negócio. Empresas de grande porte utilizam princípios do COBIT para assegurar gestão de riscos, conformidade regulatória e alinhamento da TI aos objetivos organizacionais.

Em companhias de tecnologia avançada, é comum que as boas práticas de governança do COBIT sejam internalizadas nos processos de compliance e auditoria, ainda que essas empresas não citem explicitamente “COBIT” em seu dia a dia. Ou seja, os objetivos do COBIT (como controles eficientes e gestão de riscos) são perseguidos, mas muitas vezes por meio de estruturas internas customizadas e não necessariamente por meio de um programa formal de “COBIT seguido à risca”.

ISO/IEC 20000: Padrões Internacionais na sua governança

A norma internacional de sistema de gerenciamento de serviços de TI também continua presente, em especial para demonstração de qualidade de serviço por provedores de tecnologia. Várias empresas buscam certificação ISO 20000-1 para atestar aos clientes que seus processos de ITSM seguem padrões reconhecidos.

Um exemplo concreto é a Amazon Web Services (AWS), que em 2023 anunciou a certificação ISO/IEC 20000-1:2018 cobrindo mais de 100 serviços de sua plataforma de nuvem. Essa certificação indica que a AWS implementou e mantém um Sistema de Gerenciamento de Serviço (SMS) alinhado às melhores práticas internacionais, reforçando compromisso com qualidade e melhoria contínua.

O mesmo vale para outras provedoras de nuvem e serviços. A Microsoft e o Google Cloud também adotam padrões ISO (como 27001, 9001 e possivelmente 20000) para segmentos de seus serviços, visando atender clientes corporativos exigentes. 

Em resumo, normas como ISO 20000 continuam sendo um “selo de qualidade” buscado pelas empresas líderes, ainda que internamente elas combinem esses padrões com práticas ágeis.

Como as gigantes da tecnologia gerenciam seus serviços de TI?

Examinando individualmente as empresas citadas – Google, Amazon, Netflix, Meta e Microsoft – é possível observar como cada uma adaptou esses frameworks e práticas às suas necessidades, muitas vezes pioneirando abordagens inéditas de gerenciamento de serviços de TI.

Google: o berço do SRE

Foi no Google, por volta de 2003, que o framework SRE nasceu e foi , formalizado por Ben Treynor (que cunhou a frase “SRE é o que acontece quando você pergunta a engenheiros de software para projetar uma equipe de operações”).

Na prática, o Google não seguiu o ITIL tradicional em seus serviços. Em vez disso, se inspirou no ITIL, e criou uma cultura própria onde engenheiros de confiabilidade (SREs) trabalham em parceria com times de desenvolvimento, assumindo tarefas operacionais com enfoque em automação e engenharia.

Todos os principais serviços do Google (Pesquisa, Gmail, YouTube etc.) são gerenciados por times SRE, que definem Service Level Objectives (SLOs) para disponibilidade/latência e têm autoridade para, por exemplo, rejeitar lançamentos de novas versões que excedam o “orçamento de erros” permitido.

O Google publicou livros (como Site Reliability Engineering e The SRE Workbook) compartilhando essas práticas, que viraram referência para o setor. Além disso, o Google adotou e difundiu princípios DevOps – por exemplo, contribuindo para ferramentas de CI/CD e práticas de engenharia de lançamento (release engineering).

Em resumo, o Google prioriza SRE + DevOps como modelo de gestão de operações, focando em engenharia de software para resolver desafios de disponibilidade em vez de processos tradicionais de ITSM.

Amazon (AWS): a revolução do DevOps descentralizado

A Amazon incorporou desde cedo a essência do DevOps em sua cultura. O famoso mantra de Werner Vogels (CTO da Amazon) “You build it, you run it” guiou a estruturação das equipes: a Amazon por muito tempo operou com times de produto independentes (“two-pizza teams”) responsáveis tanto pelo desenvolvimento quanto pela operação de cada serviço.

Esse modelo é frequentemente citado como um dos exemplos mais puros de DevOps em larga escala – com lançamentos frequentes e autonomia total dos times para implementar e implantar funcionalidades.

Uma consequência dessa filosofia é que, historicamente, a Amazon não criou um grupo separado de SRE ou Engenharia de Confiabilidade. Diferente do Google, não havia um time central de SRE na AWS. Os próprios times de produto executavam as funções de operação e confiabilidade.

De acordo com depoimentos de ex-funcionários, “a Amazon nunca teve equipes de plataforma ou SRE dedicadas” – a estrutura orgânica distribuída era considerada suficiente. Entretanto, esse modelo extremamente descentralizado também traz desafios, como duplicação de esforços e carga operacional alta em cada equipe.

Recentemente, com a escala massiva da AWS e necessidades de eficiência, há sinais de que a Amazon possa estar evoluindo sua abordagem. Especula-se que a empresa comece a centralizar mais funções de engenharia de plataforma e confiabilidade nos próximos anos (mesmo que chamem esses grupos por outro nome) para reduzir custos e otimizar recursos.

Em todo caso, DevOps permanece no coração da Amazon – a empresa foi pioneira em práticas de integração contínua e implantação contínua (a AWS implementa milhões de deploys por ano). 

Frameworks tradicionais de ITSM (ITIL/ISO) na Amazon são mais evidentes no contexto de serviços para clientes corporativos. A AWS mantém documentação explicando como usar a nuvem em conformidade com ITIL e até alinhou seu AWS Cloud Adoption Framework aos princípios do ITIL para ajudar clientes empresariais a integrarem cloud + ITIL.

Além disso, como mencionado, a AWS obteve certificação ISO 20000 para muitos serviços, o que demonstra compromisso com práticas de gerenciamento de serviço padronizadas. Porém, internamente, a operação cotidiana é guiada por automação, DevOps e melhoria contínua.

Netflix: do NoOps à Engenharia do caos

A Netflix é famosa por sua cultura de engenharia radical, frequentemente associada ao termo “NoOps” – a ideia de eliminar a necessidade de uma equipe de operações tradicional, graças ao altíssimo nível de automação e responsabilização dos próprios desenvolvedores.

Na verdade, “NoOps” na Netflix foi um termo popularizado por volta de 2011 pelo então arquiteto Adrian Cockcroft, significando que “os desenvolvedores operam o que constroem” utilizando plataformas e ferramentas internas robustas.

A Netflix, desde sua migração total para a nuvem (AWS) em 2010-2012, implementou um modelo de DevOps extremo. Inicialmente tinha equipes de Ops separadas, mas enfrentou lentidão e silos. Então quebrou esses silos e adotou o modelo“Operate What You Build”.

Isso quer dizer que as mesmas equipes de engenharia de software assumiram todas as responsabilidades operacionais de suas aplicações (implantação, monitoramento, resposta a incidentes, performance, etc). Cada time passou a “possuir” seu serviço de ponta a ponta, reduzindo handoffs e acelerando ciclos.

Para viabilizar isso sem comprometer a confiabilidade, a Netflix investe pesado em automação e ferramentas internas. A empresa desenvolveu um famoso conjunto de utilitários de resiliência (Simian Army, incluindo o Chaos Monkey), bem como plataformas internas como o Spinnaker (plataforma de CD de código aberto) para facilitar deploys contínuos com segurança.

Conforme estudo de caso, a Netflix criou uma equipe central de ferramentas e infra (uma espécie de “Engineering Platform”) que constrói soluções compartilhadas de deployment, monitoramento, gerenciamento de configuração, etc., usadas por todos os times.

Essa centralização de tooling permite que os desenvolvedores tenham grande autonomia com mínimo esforço manual de operações, atingindo o ideal “NoOps” (na prática, alguém escreve o código operacional – só que são engenheiros de plataforma em vez de sysadmins tradicionais).

Além disso, a cultura “Freedom and Responsibility” da Netflix dá grande liberdade aos engenheiros. Por exemplo, não há janelas fixas para mudanças ou CAB (Change Advisory Board). Cada engenheiro pode implantar código em produção quando pronto. Em troca, espera-se alto nível de responsabilidade e competência.

O resultado dessa filosofia é notável: a Netflix consegue implantar centenas de mudanças por dia, inovar rapidamente (foi uma das primeiras a abraçar micro serviços) e ainda assim manter disponibilidade próxima de 100% para mais de 200 milhões de assinantes.

Em suma, a Netflix demonstrou que é possível alcançar os objetivos do ITSM (confiabilidade, qualidade) através de DevOps puro e automação, sem seguir frameworks tradicionais a risca.

Embora não use termos como ITIL, a Netflix efetivamente implementa os processos equivalentes (incidentes, mudanças, etc.) de forma automatizada e distribuída em sua plataforma.

Hoje, a Netflix inclusive contrata engenheiros com título de SRE em áreas específicas (p. ex. confiabilidade da CDN, plataforma de games) indicando que combina a cultura DevOps original com especialistas em confiabilidade quando necessário. Mas sempre mantendo o princípio base de “full cycle developers” capacitados para operar seus sistemas

Meta (Facebook): A Engenharia que Conecta Infraestrutura e Produto

A Meta adotou uma abordagem semelhante à do Google em termos de confiabilidade, porém com sua própria nomenclatura e nuances. No Facebook, a função análoga a SRE chama-se Production Engineering.

Production Engineers são descritos como “engenheiros híbridos de software e sistemas: a cola que mantém tudo coeso, integrando infraestrutura, software, equipes e processos”.

Essa disciplina foi criada no Facebook para precarizar com as equipes de desenvolvimento e garantir confiabilidade, escalabilidade, performance e segurança dos serviços em produção.

Na prática, um Production Engineer no Facebook atua muito parecido com um SRE: escreve código de automação, aprimora a infraestrutura, gere capacidade, responde a incidentes e promove boas práticas de arquitetura resiliente.

A cultura do Facebook sempre valorizou o movimento rápido (“move fast”), e enfrentou desafios de estabilidade especialmente durante seu crescimento explosivo na década de 2010. A solução foi incorporar engenharia de confiabilidade sem sacrificar agilidade. Daí o papel de PE, que trabalha dentro dos times de produto (em vez de um departamento separado) para trazer expertise de operações.

Isso reflete uma estratégia de “shared responsibility” semelhante ao DevOps: os desenvolvedores continuam donos do código, mas contam com Production Engineers incorporados para ajudar na robustez do serviço.

Em eventos públicos, engenheiros do Facebook detalharam como lidam com escalas massivas (bilhões de usuários): através de automação de testes em produção, práticas de canary releases, monitoração sofisticada e uma forte cultura de post-mortems sem culpabilização. Tudo isso claramente inspirado na escola SRE.

Em termos de frameworks formais, o Facebook não declara o uso do ITIL ou COBIT em seu ambiente de produto. Contudo, internamente a empresa provavelmente implementa processos equivalentes onde faz sentido (por exemplo, gestão de mudanças para implementações, ainda que via ferramentas internas, e não via aprovações manuais). O foco principal é engenharia de desempenho e confiabilidade contínua.

Vale notar que, assim como a Google lançou tendências com SRE, o Facebook/Meta influenciou a indústria com algumas inovações, como seu enfoque em automação de capacidade (autoscaling) e ferramentas open-source de infraestrutura (Ex: Cassandra, oskitten etc.), além de enfatizar a ideia de “infraestrutura imutável” e gerenciamento de configuração massivo via código – práticas agora comuns no DevOps/SRE moderno.

Microsoft: reinventando décadas de tradição em TI

Sendo uma empresa mais antiga que nasceu na era do software vendido em caixas, a Microsoft passou por uma transformação cultural significativa na última década para se alinhar às práticas de serviços em nuvem. Internamente, a Microsoft migrou de modelos tradicionais (eles tinham no passado o Microsoft Operations Framework – MOF – inspirado no ITIL) para um modelo ágil DevOps com seu movimento de “One Engineering” por volta de 2014.

Hoje, a Microsoft aplica DevOps extensivamente em seus ciclos de desenvolvimento. Equipes adotam integração contínua, trunk-based development, automação de testes e releases frequentes (inclusive o Windows passou a receber updates contínuos).

Um relato interno de 2020 detalha como a engenharia da Microsoft quebrou barreiras entre dev e ops, implementando responsabilidade end-to-end e métricas de fluxo para aumentar velocidade e qualidade.

Um exemplo dessa mudança foi a introdução do conceito de DRI (Directly Responsible Individual). Em cada equipe de produto, um engenheiro gira na função de “responsável direto” pelo atendimento a incidentes e qualidade do serviço, garantindo que sempre haja um ponto focal cuidando do live site – prática muito semelhante ao que SREs fazem.

Falando em SRE, a Microsoft também incorporou essas práticas especialmente para seus serviços de nuvem. O Microsoft Azure, que compete com AWS e GCP, montou equipes de Site Reliability Engineering para melhorar a estabilidade após algumas falhas notórias no início da década de 2010.

A Microsoft inclusive publica conteúdo educacional sobre SRE, por exemplo, detalhando o “SRE model” do Microsoft Fabric (uma plataforma de dados) para compartilhar com clientes como ela mantém confiabilidade de 99,95% através de monitoramento contínuo, safe deployments regionais, resposta rápida a incidentes e aprendizado pós-incidente.

Assim, ainda que a Microsoft venha de uma tradição de engenharia diferente, hoje adota os mesmos princípios que Google e outras no que tange a DevOps/SRE. E em paralelo, continua dando suporte a frameworks clássicos para quem precisa. 

Nos materiais do Azure e do Microsoft Learn há guias de mapping entre processos ITIL e recursos do Azure (por exemplo, como implementar Gerenciamento de Incidentes do ITIL usando Azure Monitor e Azure DevOps).

A Microsoft também participa de certificações ISO (como 20000) para seus serviços cloud, e apoia clientes corporativos em alinhamento com COBIT e ITIL. 

Em resumo, a Microsoft vive um modelo híbrido: internamente é DevOps-first e confiabilidade orientada a engenharia; externamente, mostra-se aderente a frameworks tradicionais para ser vista como parceiro confiável pelas empresas mais conservadoras.

Em suma…

Em todas essas empresas, é evidente a prioridade por práticas ágeis e engenharia de confiabilidade. ITIL, COBIT e ISO são mais visíveis em contextos de compliance, auditoria e relacionamento com clientes corporativos, enquanto DevOps e SRE ditam o ritmo da operação diária e desenvolvimento de produto.

Novas Tendências em ITSM abordagens emergentes das big techs

Além dos frameworks e práticas já mencionados, o cenário recente (2022-2025) trouxe novos conceitos e tendências em gerenciamento de serviços de TI que, embora ainda não formalizados como frameworks amplamente padronizados, estão sendo priorizados pelas empresas digitais de ponta. Dentre eles, destacam-se:

Engenharia de Plataforma (Platform Engineering)

Trata-se da criação de equipes e plataformas internas para prover ferramentas, automação e ambientes padronizados para os desenvolvedores. Em outras palavras, oferecer uma “experiência de desenvolvedor” otimizada, como um produto interno.

O objetivo é reduzir a complexidade do DevOps para os times de produto, centralizando a construção de ferramentas de CI/CD, monitoramento, infraestrutura como código, etc.

O Gartner apontou Platform Engineering como um dos top trends de 2023, definindo-o como “um conjunto curado de ferramentas, capacidades e processos projetados para consumo fácil por desenvolvedores e usuários finais”.

Empresas de ponta já trilhavam esse caminho. Vimos que Netflix, Amazon e outras implementaram times centrais para construir ferramentas comuns (CI/CD pipelines, observabilidade, gerenciamento de configuração) justamente para evitar que cada equipe tenha que “reinventar a roda”.

Agora esse movimento ganhou nome e metodologia própria – muitas organizações estão estabelecendo “Portais de DevOps Internos” ou “Plataformas de Self-Service” inspiradas nas práticas das big tech, visando acelerar a entrega com consistência e governança. 

Em suma, Platform Engineering é uma resposta à complexidade do DevOps em escala, e empresas líderes a utilizam para aumentar a produtividade e reduzir a carga cognitiva sobre seus desenvolvedores.

Observabilidade e AIOps: monitoramento avançado

Observability (Observabilidade) virou palavra de ordem no gerenciamento moderno. Mais do que simples monitoramento de infraestrutura, significa ter visibilidade abrangente e correlacionada das métricas, logs e traces de aplicações, de forma a diagnosticar proativamente problemas complexos em sistemas distribuídos.

Todas as empresas citadas investem pesado nisso. Por exemplo, o Google e a Meta desenvolveram sistemas internos de telemetry. A Netflix criou o Vizceral para visualização de tráfego em tempo real. A Microsoft e a Amazon oferecem suítes completas de observabilidade (Azure Monitor, AWS CloudWatch, etc.) para seus serviços.

Junto a isso, surge o termo AIOps (Artificial Intelligence for IT Operations), que Gartner e outros promovem como tendência: usar algoritmos de Machine Learning e IA para detectar anomalias, prever incidentes e automatizar respostas em ambientes de produção.

As big tech em si incorporam AIOps em seus processos internos. Por exemplo, o Facebook usa detecção automática de falhas de hardware e remediação via bots. O Google aplica ML para análise de registros de incidentes e a Microsoft embute recursos de detecção preditiva no Azure.

Embora nenhuma dessas empresas tenha “substituído” humanos completamente na gestão de operações, há um claro movimento para aproveitar IA e automação no suporte às equipes de SRE/DevOps, seja para priorizar alertas de forma inteligente, correlacionar eventos em cascata ou até auto-corrigir certos problemas sem intervenção manual.

Segurança Integrada (DevSecOps)

A preocupação com segurança e compliance tornou-se parte inseparável do ciclo DevOps nas empresas avançadas. Em vez de um time de segurança isolado no final do pipeline, práticas de DevSecOps buscam “segurança como código” – incorporando verificações automatizadas de vulnerabilidade, testes de segurança em CI/CD, monitoramento contínuo de conformidade e colaboração estreita entre desenvolvedores, ops e especialistas em segurança.

Google e Microsoft, por exemplo, adotam frameworks como NIST SSDF e SLSA para garantir integridade de supply chain de software.

O relatório Accelerate 2022 revelou “adoção surpreendentemente ampla de práticas emergentes de segurança” em conjunto com DevOps – por exemplo, 63% dos entrevistados já incorporavam análise de segurança de aplicações em seus pipelines de CI/CD. Ou seja, a gestão de serviços de TI agora também inclui garantir segurança desde a concepção até a operação, de forma automatizada e contínua.

Engenharia do Caos (Chaos Engineering)

Prática que surgiu na Netflix e se espalhou para outras (Google, Microsoft Azure Chaos Studio, etc.), consistindo em injetar falhas propositalmente nos sistemas em produção ou em ambientes de teste para verificar a robustez e os procedimentos de recuperação.

Essa abordagem “quebre as coisas de propósito” – inicialmente vista como radical – hoje é reconhecida como valiosa para construir resiliência. Faz parte do que a Gartner chamou de “Digital Immune System”, que combina técnicas como testes caóticos, automação, observabilidade e engenharia de SRE para imunizar os serviços contra falhas.

Empresas de ponta realizam regularmente game days (simulações de incidentes) e experimentos de caos para garantir que suas equipes e arquiteturas estejam preparadas para incidentes reais. Essa mentalidade de “falhar para aprender” reforça a cultura de melhoria contínua na gestão de serviços.

Finanças da Nuvem (FinOps)

Com a adoção massiva de nuvem, surgiu também a necessidade de gerenciar eficientemente o custo dos serviços (FinOps). Empresas digitais de ponta implantaram práticas para otimização contínua de recursos de cloud, envolvendo engenharia, operações e finanças em decisões de capacidade. 

Isso também começa a se difundir como disciplina formal em muitas organizações, garantindo que performance e confiabilidade sejam alcançadas de forma custo-efetiva.

ITSM e sua constante evolução  

Outras tendências como Edge computing management, gestão de experiência do cliente (XLAs em vez de apenas SLAs) e Enterprise Service Management (ESM) expandem o escopo do ITSM tradicional para além do TI, aplicando princípios de serviços a outras áreas do negócio.

Empresas de tecnologia de ponta estão na vanguarda de adoção dessas tendências: elas combinam práticas consagradas (DevOps/SRE) com novas ideias (Platform Engineering, Observability avançada, IA aplicada a operações, Chaos Engineering) para atingir níveis superiores de desempenho e confiabilidade. 

Enquanto modelos clássicos fornecem um alicerce, é nessa inovação constante – muitas vezes antes mesmo de haver um “framework” formal de mercado – que essas organizações encontram vantagem competitiva.

O futuro do ITSM: aprendendo com as gigantes digitais

Integração dos frameworks:

• Integração, não substituição: ITIL, COBIT e ISO continuam relevantes, mas funcionam melhor quando combinados a práticas de engenharia como DevOps e SRE. Não há choque de titãs, mas sim sinergia.
• Automação é combustível: grandes players provaram que, sem automação em pipelines, monitoramento e testes, a velocidade exigida pelo mercado simplesmente engasga.
• Cultura de responsabilidade: repassar paulatinamente a operação para as equipes de produto cria senso de dono e acelera a solução de problemas, reduzindo retrabalho e atritos organizacionais.

Como escolher o modelo ideal de ITSM para sua organização?

1. Mapeie suas necessidades de negócio: defina se a prioridade é velocidade de entrega, conformidade ou otimização de custos — isso orienta o mix de práticas.
2. Avalie maturidade e recursos: times enxutos e sem expertise em SRE devem começar por ITIL simplificado e automação leve; organizações com engenheiros de software experientes podem pular direto para DevOps/SRE.
3. Pilote antes de escalar: implemente um MVP de processos (fluxo de incidentes, mudanças controladas, deploys automatizados) em um único produto ou área e mensure ganhos antes de expandir.

O ITSM Híbrido: personalização para o seu negócio

O futuro do ITSM é híbrido, evolutivo e cada vez mais orientado por engenharia, automação e agilidade. As gigantes digitais já mostraram que a combinação entre governança, práticas modernas como SRE e DevOps, e frameworks tradicionais como ITIL e COBIT é o caminho mais eficaz para entregar valor em escala. E você — está pronto para aplicar esse modelo de excelência na sua realidade?

A ITSM na Prática oferece os cursos e certificações ideais para quem quer liderar essa transformação com segurança, autoridade e alinhamento às tendências mais adotadas pelas Big Techs. Prepare-se com conteúdos oficiais, instrutores experientes e foco em aplicação prática no seu dia a dia.