ITSM para equipes de alta velocidade
Como executar o suporte de TI da maneira DevOps
Está comprovado que levar os princípios de DevOps para as equipes de engenharia e serviços de TI melhora muito a qualidade do serviço, o moral da equipe, a solução de problemas e a produtividade. Na verdade, empresas que adotam princípios de DevOps relatam uma média de satisfação do cliente 45% maior, um aumento de 43% na produtividade dos funcionários, melhoria de 41% nas taxas de defeito e custos relacionados à TI 38% menores.
Com estatísticas como essas, integrar os princípios de DevOps ao gerenciamento de serviços de TI é uma grande vitória para as empresas. Mas também pode soar como uma mudança complicada para as equipes. As boas notícias? Não é tão complicado quanto parece. As chaves para serviços de maior desempenho são tão simples que podem surpreendê-lo.
O que é DevOps?
Então, o que exatamente é DevOps? É um conjunto de práticas que aproxima duas equipes que, com frequência, ficam separadas e costumam bater cabeça: desenvolvimento e operações. A meta é colaboração, comunicação aberta e encontrar maneiras para que ambos os departamentos alcancem as respectivas metas.
Como os especialistas explicam: “DevOps é um conjunto de práticas que automatiza os processos entre o desenvolvimento de software e as equipes de TI para que possam compilar, testar e lançar software com mais rapidez e confiabilidade. O conceito de DevOps tem por base a criação de uma cultura de colaboração entre equipes que costumavam funcionar nos respectivos silos. Entre os benefícios prometidos estão maior confiança, lançamentos mais rápidos de software, capacidade de resolver itens críticos com rapidez e melhor gerenciamento do trabalho não planejado”.
Por que DevOps para suporte de TI?
Do ponto de vista de negócios, os números falam por si mesmos: satisfação do cliente 45% melhor, produtividade dos funcionários 43% maior, redução de 38% nos custos relacionados à TI. O movimento de DevOps ajudou os resultados dos negócios de forma significativa. Que é provavelmente o motivo de 4 entre 5 empresas dizerem que estão usando pelo menos alguns princípios de DevOps.
Atraente para as próprias equipes, quando bem-feito, o DevOps melhora a satisfação, a colaboração e o reconhecimento dos funcionários e da equipe. Ele suaviza processos difíceis, acelera tarefas e remove uma camada de burocracia que há muito tempo tem causado tensões em equipes de TI, desenvolvimento e outras equipes inter-relacionadas.
Onde as equipes de operações costumavam ficar frustradas com novos lançamentos sobre os quais não sabiam nada e que não estavam preparadas para suportar (e, de acordo com a Gartner, é o que causa 85–87% dos incidentes), o DevOps abre as linhas de comunicação e prepara as operações de TI para o que está por vir. Onde as equipes de desenvolvimento ficavam frustradas com o recuo de operações que retardavam os lançamentos, agora as equipes podem trabalhar juntas para lançamentos mais rápidos que não colocam promessas de SLA e objetivos de SLO em risco.
DevOps para serviço de TI: práticas recomendadas
Priorizar a mudança cultural
O maior desafio da integração com DevOps é a mudança cultural.
As organizações tradicionais de TI são muitas vezes isoladas, com a equipe de desenvolvimento trabalhando dentro de seu próprio ecossistema separado e as operações assumindo o comando—muitas vezes com pouco ou nenhum aviso de mudanças de sistemas antes que elas aconteçam—assim que uma mudança é lançada.
Por outro lado, as organizações de DevOps priorizam a colaboração e a comunicação entre equipes (por meio de práticas e ferramentas como dias de hackers, reuniões rápidas e salas de bate-papo).
Abraçar essa mudança significa adotar novas ferramentas, novos processos e uma nova perspectiva cultural que prioriza a comunicação entre equipes e o sucesso compartilhado.
Automatizar onde for possível
Os ganhos de produtividade de DevOps resultam, pelo menos em parte, de uma filosofia que prioriza a automação. Adotar o DevOps é incentivar as equipes a perguntar sempre: onde a gente pode automatizar?
A gente pode automatizar a revisão de código para erros comuns? Podemos automatizar sistemas para vincular problemas, incidentes e solicitações às alterações ou liberações que podem ter causado o seu acionamento? Podemos automatizar verificações e balanços que nos impedem de liberar código que não atenda aos requisitos legais ou de segurança? Podemos automatizar sistemas para congelar novos lançamentos quando estivermos perigosamente próximos de nossas metas de SLO?
Existem dezenas de maneiras de automatizar e melhorar as métricas de DevOps. Três das mais comuns são:
- Fluxo de trabalho (por exemplo: mover tickets de suporte pela central de atendimento mais rapidamente)
- Conhecimento (quando um incidente acontece, a ferramenta de gerenciamento de serviços deve automaticamente mostrar o conhecimento e a documentação relevantes)
- Escalonamento (se houver apenas duas pessoas na sua organização que possam resolver um problema, um sistema inteligente deve escalá-lo diretamente para elas em vez de seguir caminhos rígidos e lineares de escalonamento)
Acompanhar métricas importantes
À medida que as operações de desenvolvimento e de TI trabalham juntas, as boas práticas determinam que elas também rastreiem como as coisas estão indo.
Indicadores-chave de desempenho (KPIs) de DevOps comuns incluem MTBF (tempo médio entre falhas), MTTR (tempo médio para recuperação, reparo, resposta ou resolução), MTTF (tempo médio para falha) e MTTA (tempo médio para confirmação). Muitas empresas também dependem de números como o número de alertas ou solicitações geradas em um determinado período, o custo do tempo de inatividade por minuto ou o custo do suporte por chamada/solicitação.
As métricas que suas equipes vão precisar rastrear dependem das próprias equipes, das promessas feitas aos clientes em seus contratos de SLA, das metas de SLO que você acordou com a organização e de quaisquer pontos de problemas específicos que você esteja segmentando. Também é importante perceber que as métricas são um alvo em movimento. À medida que as coisas mudam dentro da empresa — dos produtos que a TI está suportando para as necessidades das partes interessadas até todas as obrigações legais ou de segurança externas — as métricas que você rastreia e como as acompanha também podem precisar mudar.
Priorizar o compartilhamento
DevOps é superar a diferença entre criação e manutenção, criadores e apoiadores. É criar visualizações, metas, processos e vocabulário compartilhados. É compartilhar conhecimento e comunicação. É ter conjuntos de ferramentas, recursos e bases de código compartilhados. E, talvez o mais importante, é ter propriedade compartilhada—o que significa responsabilidade compartilhada e sucessos compartilhados.
Para muitas organizações tradicionais, fazer a mudança para DevOps significa repensar como você define, recompensa e acompanha essas responsabilidades e sucessos compartilhados. Os objetivos das equipes de desenvolvimento e operações estão em desacordo? O sucesso de uma equipe dificulta o sucesso para a outra equipe?
Por exemplo: se a equipe de desenvolvimento estiver encarregada de lançar novos recursos o mais rápido possível e a equipe de operações de TI tiver a tarefa de manter o tempo de atividade, essas duas metas podem ter um impacto negativo entre si. As operações podem querer retardar os desenvolvedores a fim de superar as metas de tempo de atividade e o desenvolvimento pode reenviar as operações para impedir que eles atinjam suas metas de lançamento.
A solução para muitas equipes de DevOps é uma abordagem SRE, em que enquanto o tempo de atividade estiver dentro das metas de SLO, as equipes de desenvolvimento vão poder lançar tanto quanto desejarem. E quando o tempo de atividade cair para níveis inaceitáveis, todos os lançamentos vão congelar até que as equipes trabalhem juntas para obter tempo de atividade de volta para onde ele precisa estar.
ITIL vs. DevOps
Se você seguir o ITIL, talvez esteja se perguntando onde DevOps se encaixa. Para muitas empresas, as práticas de ITIL e DevOps podem funcionar juntas. Na verdade, aqui na Atlassian, vemos muitas empresas abraçando as vantagens e os pontos fortes de ambas.
Como este artigo sobre DevOps vs. ITIL explica: “Precisamos de ambos. Estamos falando de caixas complementares, não competitivas. Precisamos ser capazes de trabalhar de forma mais inteligente e rápida, mas também ainda precisamos de processos e controle. As equipes e organizações modernas e de alto desempenho estão começando a perceber as vantagens e usar elementos de ambos — elas estão indo além da ideia de ultimato (um ou outro)”.
O ITIL tende a abordar as melhores práticas para operações, suporte, governança e outras funções principais de negócios. O DevOps coloca em jogo coisas como entrega contínua, cultura de não atribuição de culpa, ferramentas de colaboração e práticas ágeis que aprimoram e desenvolvem as práticas há muito incorporadas às diretrizes do ITIL.
Ferramentas para organizações orientadas a DevOps
Adotar uma abordagem DevOps também pode significar adotar novas ferramentas—para comunicação, automação e colaboração entre equipes.
Ao avaliar novas ferramentas, é importante fazer perguntas como:
- Esta ferramenta funciona no nosso ambiente e se integra às ferramentas existentes?
- Ela atende às nossas necessidades?
- Todas as ferramentas novas funcionam juntas em um conjunto de ferramentas abrangente e coeso?
Talvez a gente seja parcial, mas na Atlassian, a gente usa o Jira Service Management para gerenciamento de serviços de TI, o Jira Software para desenvolvimento de software e o Bitbucket para o repositório de códigos.
Parte da razão pela qual essas ferramentas funcionam tão bem é que elas funcionam bem juntas. E quando estiver se afastando dos silos dentro das estruturas da sua equipe, você também vai querer se afastar dos silos em qualquer ferramenta que escolher.
The Total Economic Impact™ Of Atlassian For ITSM
The Total Economic Impact™ of Atlassian Jira Service Management. The report includes cost savings and business benefits enabled by Jira Service Management.
Leia o artigoAtlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
Leia o artigo