Suporte e manutenção geridos de aplicações
Manter em funcionamento o software que já está em produção, dentro do seu SLA e da sua fila de tickets: triagem, correções na causa, releases de correção, atualizações de dependências e de plataforma, resposta a incidentes de segurança e tratamento de incidentes. Segunda e terceira linha, por engenheiros que também constroem, para que uma falha recorrente seja corrigida e não apenas reiniciada.
Porque este é um problema dos parceiros
O suporte é a parte de um serviço gerido que é fácil de vender e difícil de dotar de pessoas. Chega de forma irregular, exige pessoas capazes de ler código desconhecido sob pressão de tempo e, no momento em que lá coloca os seus melhores engenheiros, estes deixam de estar disponíveis para o trabalho que paga melhor. A resposta habitual é um nível separado e mais barato que fecha tickets sem nunca corrigir nada, e o cliente repara no espaço de um trimestre.
A nossa resposta é que as pessoas do suporte são engenheiros. Podem alterar o sistema, e não apenas descrevê-lo, que é a única forma de um incidente recorrente deixar de se repetir.
O que assumimos
Triagem e diagnóstico
Assumir o que a primeira linha não consegue resolver, reproduzi-lo e dizer o que realmente está errado, em vez de o encerrar como não reproduzível.
Correções que se mantêm
Defeitos corrigidos na causa, com um teste de regressão escrito para toda a classe de bug e não apenas para o ticket em causa, para que o mesmo incidente não volte no trimestre seguinte.
Releases e patches
Releases de correção entregues através do seu pipeline e do seu processo de gestão de alterações, com dependências, versões de frameworks e runtimes de plataforma mantidos atualizados, em vez de derivarem para uma crise de atualização.
Resposta a incidentes de segurança
Um aviso de segurança publicado sobre algo de que depende é uma razão incondicional para atualizar, e não um item do backlog. Acompanhamo-lo, aplicamos o patch e dizemos-lhe qual foi a exposição.
Monitorização e incidentes
Acompanhamento dos alertas que já existem, acrescento dos que deveriam existir e tratamento de incidentes, com um relato escrito posterior do que aconteceu e do que impede que se repita.
Pequenas alterações
O fluxo constante de pequenas melhorias que mantém um cliente satisfeito e nunca justifica um projeto: tratado dentro da mesma capacidade e nas mesmas condições.
O seu SLA, avaliado com honestidade
Não publicamos objetivos de tempo de resposta e de resolução, porque um número inventado antes de alguém ter visto o seu sistema não vale nada para si nem para o seu cliente. Em vez disso, lemos o SLA que já deve, dizemos-lhe quais as partes que podemos realmente assumir e que cobertura isso exige, e comprometemo-nos com isso por escrito.
O mesmo se aplica à cobertura fora do horário. Quando um projeto a exige e a combinámos à partida, é assegurada por pessoas recrutadas ou alocadas para esse horário, e não acordando alguém e esperando que corra bem. Já trabalhamos em horários europeus, australianos e do Pacífico dos EUA noutros projetos, pelo que a questão é qual a janela de que precisa, e não se é possível.
Assumir um sistema que não construímos
Que é o caso normal. Nove tomadas a cargo até agora, a mais antiga escrita em 2008.
Primeiro, uma revisão só de leitura
Obtemos acesso ao código, à infraestrutura e ao histórico de tickets antes de sermos responsáveis por qualquer deles, e observamos em vez de alterar.
Uma lista escrita de riscos
O que é frágil, o que não tem patches, o que não está documentado e o que vai acordar alguém a meio da noite, ordenado por impacto na produção. Fica consigo, quer avancemos ou não.
A conversa sobre a cobertura
Lemos o SLA que deve ao seu cliente e dizemos-lhe com honestidade quais as partes que podemos assumir, que horário isso exige e quanto custa, antes de qualquer das partes assinar seja o que for.
Passagem de testemunho e, depois, produção
Um período de acompanhamento definido com quem detém hoje o conhecimento e, depois, assumimos a fila. Se já ninguém detém o conhecimento, é a revisão de riscos que serve de ponto de partida.
Sob o seu nome, se for esse o acordo
O suporte é normalmente a parte mais visível de um serviço gerido, pelo que é também onde ser white-label mais importa. Os nossos engenheiros podem trabalhar a partir de caixas de correio e contas que a sua empresa emita, responder no seu sistema de tickets e redigir relatórios de incidentes que reencaminha sem alterações; o seu cliente trata consigo ao longo de todo o processo. O desenvolvimento white-label descreve como isso se organiza, e aplica-se ao suporte exatamente da mesma forma.
Como é calculado o preço do suporte
Por pessoa, ao mês, para que o seu próprio custo seja previsível e possa calcular com base nele o preço de um contrato de suporte para o seu cliente. Todos registam o tempo no nosso próprio portal, vê as horas ao longo do mês e os mesmos valores geram a fatura, pelo que há um único registo com que ambas as partes reconciliam.
Quando o suporte coexiste com novo desenvolvimento, os dois constituem normalmente um só delivery pod e não dois contratos, de modo que as semanas calmas de um lado compensam as semanas de maior atividade do outro.
Perguntas sobre os acordos de suporte
O que abrange o suporte aplicacional gerido?
Manter a funcionar o software que já está em produção: triagem do que chega à fila, reprodução e correção de defeitos, resposta às questões técnicas que o primeiro nível não consegue resolver, publicação de versões de correção, manutenção das dependências e das versões das plataformas em dia, vigilância dos alertas e gestão de incidentes quando algo falha. É trabalho de segundo e terceiro nível; o seu primeiro nível mantém-se onde está.
Trabalham de acordo com o nosso SLA?
Sim. Não publicamos objetivos de resposta e de resolução, porque um número inventado antes de conhecer o seu sistema não vale nada. Lemos o SLA que já deve ao seu cliente, dizemos com honestidade que partes podemos assumir e que cobertura seria necessária, e comprometemo-nos com isso por escrito.
Podem assegurar cobertura fora de horas ou de prevenção?
Sim. A cobertura fora de horas e de prevenção é acordada à partida, escrita nos termos de suporte e assegurada por pessoas cujo horário de trabalho a comporta, para que um incidente à noite chegue a alguém que está de turno e não a alguém acordado de propósito.
Conseguem dar suporte a um sistema que não desenvolveram?
Esse é o caso normal. Até à data, nove takeovers, o mais antigo escrito em 2008. O suporte de um sistema herdado começa com uma revisão só de leitura e uma lista escrita de riscos ordenados por impacto em produção, pelo que as primeiras semanas são passadas a perceber aquilo por que se é realmente responsável, em vez de adivinhar sob pressão.
As mesmas pessoas que dão suporte ao sistema também o alteram?
Sim, e é essa a ideia. Os engenheiros do suporte são engenheiros, e não um nível separado que se limita a fechar tickets, pelo que um incidente recorrente pode ser corrigido na causa em vez de ser reiniciado todas as segundas-feiras. Quando tem connosco tanto uma frente de desenvolvimento como uma de suporte, as duas partilham revisão de código e decisões de arquitetura.
Como é cobrado o suporte?
Por pessoa, por mês, para que o seu custo seja previsível e possa fixar o preço de um contrato de suporte ao seu cliente com base nele. As horas são registadas no nosso portal e ficam visíveis para si ao longo do mês, e os mesmos valores geram a fatura, pelo que há uma única fonte para ambas as partes.
Tem sistemas para manter em funcionamento?
Diga-nos quais são os sistemas, o que promete o seu SLA e onde o suporte atual falha. Lemos tudo e dizemos-lhe quais as partes que podemos assumir, incluindo as que não podemos.