Tópico 3.8 — Gestão de serviços e operação em produção

Na saúde e nos cuidados, a maior parte da vida, do custo e do risco clínico de um serviço está depois da entrada em produção — por isso a forma como você opera, monitora e apoia um serviço em produção é uma decisão de segurança do paciente, e não uma reflexão tardia de retaguarda.

Por que isso importa na saúde e nos cuidados#

O lançamento é o começo, e não o fim. Um serviço digital passa alguns meses sendo construído e, se tem sucesso, anos ou décadas sendo operado — e a operação é onde vai a maior parte do dinheiro e onde o dano de fato acontece. Um prontuário de cuidados compartilhado, um sistema de prescrição eletrônica ou uma plataforma de prontuários de maternidade só entrega valor enquanto está no ar, correto e responsivo. Quando se degrada ou falha, as consequências não são incômodo, mas tratamento atrasado, alergias perdidas, clínicas canceladas e clínicos voltando a gambiarras desconhecidas em papel sob pressão.

A saúde e os cuidados funcionam 24 horas por dia, sete dias por semana, e não podem parar. Quando o sistema de caixa de um supermercado falha, os clientes esperam; quando o sistema de administração de pacientes de um hospital falha, ambulâncias podem ser desviadas e listas eletivas adiadas. Isso dá à operação em produção um peso distintivo: a indisponibilidade é um evento de segurança clínica, e o plano de como você detecta, escala, comunica e se recupera dela faz parte do seu dever de cuidado. O ataque de ransomware WannaCry de 2017 — que forçou o cancelamento de milhares de consultas e operações do NHS — é o caso de referência de como uma falha operacional vira uma crise de segurança do paciente e de confiança pública (ver Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança).

Os líderes também precisam financiar e dotar de pessoal a operação em produção com honestidade. A falha persistente na tecnologia em saúde é celebrar a entrada em produção, dissolver a equipe e tratar o serviço em operação como "terminado". Um serviço em produção sem equipe permanente, sem monitoramento e sem cobertura de plantão não está economizando dinheiro — está acumulando risco clínico em silêncio até o dia em que falha com estardalhaço. A gestão de serviços é a disciplina que mantém seguro um serviço em produção e merece o mesmo rigor que a construção.

Conceitos centrais#

Gestão de serviços e a fase "Live" (produção). A gestão de serviços de TI (ITSM) é o conjunto de práticas para projetar, operar, apoiar e melhorar serviços de TI ao longo de toda a sua vida. No modelo de fases do GOV.UK e do NHS, Live (Produção) é a fase em que um serviço funciona em operação contínua — ainda iterando, ainda financiado, ainda com dono — até ser desativado (ver Tópico 3.5 — Ciclos de vida de entrega). A produção não é um estado de repouso; é a parte mais longa e mais cara do ciclo de vida.

ITIL 4. O ITIL é o arcabouço de ITSM mais usado. Sua edição atual, o ITIL 4, reformula as versões antigas, pesadas em processos, em torno de um "sistema de valor de serviço" e de práticas flexíveis, e foi concebido para conviver com o Agile, o DevOps e o Lean, e não para competir com eles. Trate o ITIL como um vocabulário e uma lista de verificação de práticas a adotar de forma proporcional — e não como uma burocracia a importar por atacado.

Gestão de incidentes, de problemas e de mudanças. A gestão de incidentes restaura o serviço normal o mais depressa possível após uma interrupção não planejada — a prioridade é a recuperação, e não o diagnóstico. A gestão de problemas investiga a causa subjacente de um ou muitos incidentes para evitar a recorrência e mantém um registro de erros conhecidos e de soluções alternativas. A gestão de mudanças (no sentido de ITSM) controla como as mudanças no parque em produção são avaliadas, aprovadas e liberadas, para que consertar uma coisa não quebre outra. Essas três práticas são o núcleo operacional e se entrelaçam: um incidente pode gerar um problema, cuja correção é entregue como uma mudança.

Gestão de incidentes graves e continuidade de negócios. Um incidente grave é um evento de alto impacto — um sistema clínico fora do ar em todo um hospital — que exige uma resposta declarada e coordenada, com um comandante de incidente definido, comunicações e liderança clínica. O planejamento de continuidade de negócios (BCP) é a capacidade mais ampla de continuar prestando cuidados em níveis aceitáveis durante a interrupção, incluindo procedimentos clínicos de contingência testados (o recurso seguro ao papel) e a recuperação de desastres. Na saúde e nos cuidados isso não é opcional: manter os pacientes seguros enquanto o sistema está fora do ar é todo o sentido.

Engenharia de confiabilidade de sites, SLIs, SLOs, SLAs e orçamentos de erro. A engenharia de confiabilidade de sites (SRE), originada no Google, aplica a disciplina da engenharia de software às operações. Mede a confiabilidade com um indicador de nível de serviço (SLI) — uma métrica como disponibilidade ou latência — frente a um objetivo de nível de serviço (SLO), uma meta interna para essa métrica. Um acordo de nível de serviço (SLA) é a promessa externa, muitas vezes contratual, geralmente definida de forma mais frouxa do que o SLO interno. A distância entre 100% e o seu SLO é o orçamento de erro: a quantidade de não confiabilidade que você pode gastar antes de ter de parar de entregar funcionalidades e estabilizar. Nos sistemas clínicos, os SLOs devem ser definidos com os clínicos, porque a indisponibilidade "aceitável" é um julgamento de segurança, e não só de engenharia.

Observabilidade e monitoramento. A observabilidade é a capacidade de entender o estado interno de um sistema a partir de suas saídas externas — registros, métricas e rastros — para detectar e diagnosticar problemas, idealmente antes dos usuários. O monitoramento e os alertas transformam esses dados em sinais oportunos para as pessoas de plantão. Não se pode operar com segurança um serviço que não se enxerga.

Plantão, escalas e a central de serviços. As escalas de plantão garantem que um humano competente possa responder a alertas 24 horas por dia; num ambiente de cuidados 24/7 elas são essenciais e precisam ser humanas e sustentáveis. Uma central de serviços (ou help desk) é o ponto único de contato para os usuários finais — o clínico que não consegue entrar, o recepcionista cuja tela de agendamento travou —, oferecendo suporte, registrando incidentes e encaminhando-os adiante.

DevOps, gestão de configuração e o CMDB. O DevOps e o princípio da SRE de "você constrói, você opera" colocam a equipe que constrói um serviço no comando de sua operação, fechando a distância entre desenvolvimento e operações. A gestão de configuração mantém um registro preciso dos componentes que compõem um serviço e de suas relações, muitas vezes num banco de dados de gestão de configuração (CMDB); sem ele, ninguém consegue responder com segurança "o que esta mudança afetará?" durante um incidente.

Operar versus construir e desativação. As organizações separam o financiamento de construção (criar nova capacidade) do de operação (operar o que existe). Subfinanciar a operação é a raiz estrutural da maioria das falhas operacionais. E todo serviço chega, afinal, à desativação — aposentadoria segura, com dados migrados ou arquivados sob a lei de retenção e usuários redirecionados —, que é uma disciplina operacional por si só.

Boas práticas#

1. Financie e dote de pessoal a "operação" como um compromisso de primeira ordem, e não como sobra. Orce a vida operacional do serviço — monitoramento, plantão, central de serviços, aplicação de correções de segurança e iteração contínua — antes da entrada em produção e proteja-a de saques pela próxima construção reluzente. A regra prática do setor de que operar um sistema custa muito mais ao longo da vida do que construí-lo vale também na saúde. Um serviço com financiamento de construção e sem financiamento de operação é um risco clínico com data de lançamento.

2. Evite o antipadrão de "jogar por cima do muro para as operações". Não deixe uma equipe de projeto construir um serviço e entregá-lo a uma equipe de operações separada que nunca viu como foi feito. Aplique "você constrói, você opera": mantenha a equipe que entende o serviço responsável pela sua confiabilidade ou, no mínimo, conduza uma transição de serviço deliberada e documentada, com plantão compartilhado e um período de garantia. O muro entre construir e operar é onde o conhecimento, a propriedade e a segurança escapam.

3. Defina os SLOs com os clínicos e gerencie um orçamento de erro. Defina o que significa "confiável o bastante" para cada serviço como SLIs e SLOs mensuráveis e fixe-os em conjunto com os clínicos que arcam com as consequências — as metas de disponibilidade de um sistema de pronto-socorro não são uma escolha puramente técnica. Use o orçamento de erro para arbitrar a eterna tensão entre entregar funcionalidades e permanecer estável: quando a confiabilidade é gasta, pare e estabilize. Mantenha os SLAs externos mais frouxos do que os SLOs internos para ter espaço de agir antes de quebrar uma promessa.

4. Torne o serviço observável antes de torná-lo maior. Instrumente registros, métricas e rastreamento e construa painéis e alertas que reflitam a experiência do usuário e do clínico, e não apenas a saúde do servidor. Alerte sobre os sintomas que importam (os pacientes não podem ser agendados) em vez de cada oscilação subjacente, para evitar a fadiga de alertas que ensina os respondentes a ignorar os chamados. Não se mantém seguro um serviço cujas falhas você descobre por clínicos irritados.

5. Conduza uma gestão disciplinada de incidentes, problemas e mudanças — de forma proporcional. Dê aos incidentes níveis claros de gravidade, metas de resposta, um comandante de incidente para os graves e uma fonte única da verdade durante a resposta. Alimente as revisões pós-incidente sem culpa e um processo de gestão de problemas com os incidentes graves, que corrija as causas-raiz em vez de reiniciar o servidor repetidamente. Controle as mudanças por um processo dimensionado — mudanças leves, padronizadas e pré-aprovadas para o trabalho rotineiro de baixo risco; uma revisão consultiva de mudanças apenas para as genuinamente arriscadas —, de modo que a governança proteja a segurança sem virar um gargalo que tenta as pessoas a contorná-la.

6. Ensaie os incidentes graves e a contingência clínica, e não apenas os documente. Escreva, teste e exercite regularmente os procedimentos de continuidade de negócios e de contingência clínica: como o cuidado continua em papel, como a equipe é informada de que o sistema está fora do ar, como os dados são reconciliados na recuperação e quem declara e comanda um incidente grave. Planos não testados falham no dia. Ligue isso explicitamente à sua gestão de riscos clínicos e ao registro de perigos (ver Tópico 1.6 — Segurança clínica e gestão de riscos), porque a indisponibilidade é um perigo clínico com uma mitigação que se pode ensaiar.

7. Trate o aprendizado pós-incidente como sem culpa e sistêmico. Após todo incidente significativo, conduza uma revisão que pergunte como o sistema permitiu a falha, e não quem culpar — porque a culpa empurra o relato para a clandestinidade e repete o dano. Registre as ações, atribua responsáveis e acompanhe-as até o fechamento; devolva os padrões à gestão de problemas e ao projeto. Uma cultura de aprendizado é um controle de segurança do paciente, espelhando a "cultura justa" do relato de incidentes clínicos.

8. Mantenha um registro de configuração preciso e gerencie todo o parque. Mantenha um CMDB ou inventário equivalente do que roda, do que depende de quê, de quais versões estão implantadas e de quem é dono de cada serviço, para que, durante um incidente, você consiga responder "o que isto afeta?" em minutos. Isso sustenta a mudança segura, a aplicação de correções de segurança e o licenciamento, e é onde a maioria dos grandes parques do NHS é mais fraca. Um sistema desconhecido e sem correções é, ao mesmo tempo, uma indisponibilidade e um incidente de cibersegurança à espera de acontecer (ver Tópico 1.7).

9. Torne o plantão sustentável e o suporte humano. Projete escalas de plantão adequadamente dotadas de pessoal, justamente remuneradas e humanas, com escalação clara e expectativas realistas — respondentes esgotados tomam decisões lentas e propensas a erro justamente nos momentos que mais importam. Dimensione a central de serviços para a demanda real de uma força de trabalho clínica 24/7 e dê à equipe da linha de frente uma via rápida e respeitada para relatar problemas. A qualidade do seu suporte é a qualidade do cuidado que a equipe vivencia a partir do seu serviço.

10. Planeje a desativação como uma operação controlada. Decida, enquanto o serviço está em produção, como ele será eventualmente desativado: migração ou arquivamento de dados sob a lei de retenção de registros, redirecionamento de usuários, notificação de clínicos e preservação do registro de perigos e da trilha de auditoria. Uma desativação não planejada deixa dados e usuários encalhados e pode violar deveres estatutários de retenção. Uma planejada é um projeto operacional auditável, e não uma correria quando o substituto chega.

Perguntas para discutir com a sua equipe#

1. Quando um sistema clínico crítico cai às 3 da manhã de um feriado, exatamente quem faz o quê — e alguma vez testamos isso? Esta pergunta força a diferença entre um plano documentado e uma capacidade real. Na saúde e nos cuidados, a indisponibilidade é um evento clínico: as perguntas práticas são quem é acionado, com que rapidez responde, quem tem autoridade para declarar um incidente grave, como a equipe clínica é orientada a passar aos procedimentos de contingência, como os pacientes permanecem seguros em papel e como os dados são reconciliados na recuperação. Debatam se a sua escala de plantão realmente tem cobertura competente em horários inconvenientes e feriados ou se afina até uma única pessoa exausta quando o risco é maior. Considerem se os clínicos conhecem o procedimento de contingência e já o ensaiaram ou se ele vive num fichário que ninguém abriu. Uma boa resposta, honesta, descreve uma resposta testada — com papéis nomeados, um exercício real no último ano e lições postas em prática —, e não um documento de política que nunca encontrou uma indisponibilidade. Onde a resposta honesta é "não sabemos de fato", esse é, em si, o achado mais importante a levar ao conselho.

2. Estamos genuinamente financiando e dotando de pessoal a "operação", ou celebramos a entrada em produção e fomos embora em silêncio? A maior parte do custo e do risco clínico de um serviço vive depois do lançamento, e, no entanto, os modelos de financiamento premiam a construção de coisas novas e esvaziam a operação das antigas. A tensão a debater é a atração estrutural do financiamento de construção versus o trabalho pouco glamoroso e essencial de monitorar, corrigir, apoiar e iterar um serviço em produção durante anos. Olhem com honestidade para o seu parque em produção: quantos serviços têm um responsável nomeado, uma equipe financiada, correções de segurança atuais e monitoramento funcionando — e quantos estão órfãos, rodando em software sem suporte, sem ninguém responsável? Considerem o padrão de "jogar por cima do muro para as operações" e se as pessoas que operam cada serviço entendem como ele foi construído. Uma boa resposta consegue apontar orçamentos de operação protegidos, responsáveis nomeados pelos serviços durante a vida operacional e uma transição de serviço deliberada, e não um abandono, e consegue nomear com honestidade os serviços órfãos para que possam ser adotados, substituídos ou desativados em vez de deixados falhar.

3. Como decidimos o que significa "confiável o bastante" — e quem tem voz? A confiabilidade não é grátis, e perseguir mais um "nove" de disponibilidade pode custar mais do que o dano que previne; mas, nos sistemas clínicos, a indisponibilidade "aceitável" é um julgamento de segurança que os engenheiros não podem fazer sozinhos. Esta pergunta indaga se vocês têm SLIs e SLOs explícitos, se foram definidos com os clínicos e líderes operacionais que arcam com as consequências e se usam algo como um orçamento de erro para equilibrar a entrega de melhorias com a manutenção da estabilidade. Debatam a diferença entre a meta interna que gerenciam e o SLA externo que prometem e se o seu monitoramento mede o que os clínicos de fato vivenciam ou apenas o que os servidores reportam. Considerem se "buscamos 99,9%" tem dentes — uma medição definida, uma consequência quando violada, um responsável que age. Uma boa resposta liga uma meta de confiabilidade a uma justificativa de segurança clínica, mostra que a métrica é medida e tem dono e descreve o que a equipe faz de diferente quando o orçamento é gasto, em vez de um número num slide a que ninguém administra.

4. Nós de fato sabemos o que operamos — e conseguiríamos responder "o que esta mudança afetará?" no meio de um incidente? A maioria dos grandes parques de saúde e cuidados é mais fraca justamente onde mais dói: ninguém detém um retrato preciso e atual do que roda, do que depende de quê, de quais versões estão implantadas e de quem é dono de cada serviço. Esta pergunta sonda se vocês mantêm um registro de configuração — um CMDB ou equivalente — ou se esse conhecimento vive na cabeça de um punhado de pessoas e em uma década de integrações não documentadas. Debatam as consequências reais: uma mudança que quebra silenciosamente um sistema a jusante, uma correção de segurança que não pode ser aplicada porque ninguém sabe o que ela tocará, um servidor sem suporte descoberto apenas quando falha ou é explorado. A tensão é que a gestão de configuração é pouco glamorosa, nunca termina e é fácil de adiar, e, no entanto, sustenta igualmente a mudança segura, a aplicação de correções, o licenciamento e a ciber-resiliência — o mesmo ponto cego que transformou o WannaCry numa crise. Uma resposta honesta descreve um inventário mantido, com responsáveis e dependências, em que as pessoas confiam e que usam durante os incidentes e nomeia as partes do parque que ainda estão no escuro, em vez de alegar uma completude que nenhuma grande organização realmente tem.

5. Quando algo dá errado, nós aprendemos ou procuramos alguém para culpar? A cultura das suas revisões de incidentes determina se o mesmo dano se repete. Esta pergunta indaga se os incidentes graves acionam uma revisão sem culpa e sistêmica, que pergunta como o sistema permitiu a falha — ou se caçam em silêncio um indivíduo a responsabilizar, o que empurra o relato para a clandestinidade e garante a repetição. Debatam se os quase-acidentes e as pequenas falhas chegam a ser trazidos à tona ou apenas as indisponibilidades grandes demais para esconder; se as ações das revisões recebem responsáveis e são acompanhadas até o fechamento ou são anotadas e esquecidas; e se os padrões alimentam a gestão de problemas e o projeto. Considerem o paralelo com o relato de incidentes clínicos e a "cultura justa": a mesma organização pode manter uma postura madura e sem culpa para incidentes de segurança do paciente e uma punitiva para falhas de TI, ou vice-versa. Uma boa resposta mostra uma cultura de aprendizado com evidências — revisões que mudaram o sistema, ações fechadas, recorrência caindo — e um reconhecimento honesto de onde o medo ainda suprime o relato, porque uma cultura de aprendizado é, em si, um controle de segurança do paciente, e não um extra brando.

6. Decidimos como este serviço será eventualmente desativado — enquanto ainda está vivo para planejá-lo? Todo serviço é, afinal, substituído ou desligado, e, no entanto, a desativação é quase sempre uma reflexão tardia, atropelada quando o sucessor chega e o sistema antigo já é um obstáculo. Esta pergunta indaga se, para cada serviço em produção, vocês têm um plano de desativação segura: dados migrados ou arquivados sob a lei de retenção de registros, usuários redirecionados, clínicos notificados e o registro de perigos e a trilha de auditoria preservados. Debatam os riscos específicos da saúde e dos cuidados de errar nisso — registros encalhados que violam deveres estatutários de retenção, dados órfãos a que ninguém tem acesso, um sistema legado "temporário" que permanece por anos sem correções porque ninguém é dono do seu fim. Considerem que, em parques nacionais e corporativos, décadas de prontuários clínicos podem estar dentro de um sistema que precisa ser desativado sem perder um único registro exigido por lei. Uma resposta honesta trata a desativação como uma operação nomeada, financiada e auditável, planejada desde a entrada em produção, e não um custo a descobrir depois, e consegue apontar ao menos um serviço cujo fim de vida já está decidido, e não adiado.

Na prática: um exemplo de saúde e cuidados#

Um sistema de cuidados integrados (ICS) opera um prontuário de cuidados compartilhado usado por clínicos de hospital, clínicos gerais, equipes comunitárias e serviços fora do horário em toda uma região. Entrou em produção há dois anos; o programa de construção foi encerrado e uma equipe permanente de produto e operações agora é responsável por ele. Essa equipe aprendeu a gestão de serviços do jeito difícil.

No início, o prontuário só tinha monitoramento da disponibilidade dos servidores. Numa noite de inverno, os servidores estavam "verdes" enquanto uma integração com falha interrompia em silêncio o fluxo das atualizações de medicação dos clínicos gerais — de modo que os clínicos do hospital viram listas de medicação desatualizadas por várias horas até que um farmacêutico percebeu e telefonou para a central de serviços. A revisão pós-incidente foi sem culpa e sistêmica: constatou que o verdadeiro problema era a ausência de um SLI que refletisse a experiência do clínico. A equipe acrescentou observabilidade de ponta a ponta, um SLO de atualidade dos dados acordado em conjunto com um responsável pela segurança clínica e um alerta que aciona o plantão quando as atualizações se atrasam além do limiar de segurança. Esse perigo foi acrescentado ao registro de perigos de riscos clínicos (Tópico 1.6).

Depois, ajustaram suas práticas. As atualizações de configuração rotineiras e de baixo risco viraram mudanças padrão pré-aprovadas, entregues por uma esteira automatizada com reversão rápida; apenas as mudanças genuinamente arriscadas vão a uma revisão semanal de mudanças com representação clínica. Uma escala de plantão humana cobre noites e feriados, amparada por uma central de serviços dimensionada para a demanda real 24/7. De forma decisiva, escreveram e agora ensaiam duas vezes por ano um procedimento de contingência clínica: uma cópia em cache, somente leitura, dos principais registros, um recurso ao papel, uma cascata de SMS para avisar os clínicos de que o sistema está degradado e uma etapa de reconciliação na recuperação. Quando uma falha de energia no data center derrubou o sistema primário por quarenta minutos na primavera passada, o cuidado continuou na contingência testada, o comandante de incidente conduziu uma resposta calma e coordenada, e nenhum paciente foi prejudicado. O conselho viu um relatório de confiabilidade ligado a medidas de segurança clínica, e não uma garantia vaga — e a propriedade do serviço até a eventual desativação está nomeada e financiada.

Perspectivas setoriais#

Startup#

Uma pequena empresa de tecnologia em saúde muitas vezes não tem função de operações separada; assim, "você constrói, você opera" é o padrão, e não uma aspiração — os mesmos engenheiros que escreveram o código carregam o pager. A vantagem é a retroalimentação rápida e a ausência de um muro por cima do qual jogar o trabalho; o perigo é uma escala de plantão de duas pessoas que não é nem sustentável nem segura e um monitoramento que para em "o servidor está no ar?". As startups devem adotar SLOs, observabilidade básica, revisões pós-incidente sem culpa e um procedimento escrito de contingência desde o primeiro cliente do NHS, porque uma indisponibilidade clínica pode acabar tanto com o contrato quanto com a empresa. Mesmo sem a cerimônia do ITIL, a intenção — enxergar o serviço, responder depressa, aprender de forma sistêmica, manter os pacientes seguros quando ele falha — é inegociável na saúde.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou uma clínica de unidade única — opera sistemas clínicos em produção todos os dias, mas geralmente não tem função de TI dedicada nem alguém cujo trabalho seja a gestão de serviços. Aqui a "operação" é espremida nas margens do trabalho clínico e administrativo, o plantão é, na verdade, "o celular do gerente do consultório" e o monitoramento é um clínico notando que a tela de agendamento travou. As prioridades pragmáticas são as poucas coisas que mantêm os pacientes seguros: um procedimento de contingência escrito e ensaiado (como o consultório atende em papel e reconcilia depois), uma via conhecida de escalação a cada fornecedor quando um sistema hospedado falha e clareza sobre quais SLAs esses fornecedores de fato devem. Um pequeno fornecedor independente de tecnologia em saúde que já passou da fase de startup enfrenta a imagem espelhada — clientes reais dependendo dele, mas cobertura operacional escassa — e precisa oferecer horários de suporte e resposta a incidentes críveis apesar do caixa apertado. O dever de cuidado é idêntico ao de um grande hospital; os recursos não são, de modo que a disciplina é priorizar sem concessões o básico crítico para a segurança em detrimento da completude do ITIL.

Grande organização#

Um hospital do NHS ou um grande fornecedor conduz a gestão de serviços em sua forma mais plena: uma central de serviços formal, práticas de incidente/problema/mudança alinhadas ao ITIL, conselhos consultivos de mudança, planos de incidente grave e de continuidade de negócios e, muitas vezes, um centro de operações 24/7. O desafio característico é um parque legado extenso, com registros de configuração fracos, sistemas sem correções e propriedade pouco clara — as condições que transformaram o WannaCry numa crise. As falhas clássicas são processos de mudança tão pesados que a equipe os contorna e a "operação" perpetuamente esvaziada para financiar a próxima construção. A grande organização tem os recursos para fazer bem a observabilidade, o plantão sustentável e a continuidade testada; a tarefa, portanto, é manter as práticas proporcionais e genuinamente de propriedade clínica, em vez de um ritual de papelada que dá falsa garantia.

Governo#

Um órgão nacional opera serviços que podem tocar milhões; assim, uma indisponibilidade é um incidente nacional, com consequências parlamentares e de confiança pública, e as metas de confiabilidade são matéria de responsabilização pública. A entrega governamental combina o ITSM com a expectativa do GOV.UK Service Manual de que os serviços em produção sejam adequadamente operados, monitorados e iterados — e não congelados no lançamento — e com deveres estatutários de retenção de registros e de cibersegurança (NCSC, DSPT). Os controles de gastos e os acordos de financiamento plurianuais moldam o que significa o financiamento de "operação", e a mera escala eleva o que está em jogo na continuidade de negócios, na resposta coordenada a incidentes graves e na desativação segura de sistemas nacionais legados com décadas de registros. A concessão é garantia e resiliência versus velocidade e custo, resolvida às claras sob escrutínio.

Modos de falha comuns#

• Jogar por cima do muro para as operações. Uma equipe de construção entrega um serviço a uma equipe de operações que nunca viu como foi feito; conhecimento, propriedade e segurança caem na lacuna. Antídoto: "você constrói, você opera" ou uma transição deliberada com período de garantia e plantão compartilhado.
• O serviço em produção órfão. O projeto fecha, a equipe se dissolve, o financiamento de operação evapora; o serviço apodrece, fica sem correções e acumula risco clínico e cibernético em silêncio. Antídoto: responsável nomeado pelo serviço e orçamento de operação protegido durante a vida operacional.
• Monitorar os servidores, e não o serviço. Tudo está "verde" enquanto os clínicos veem dados desatualizados ou ausentes. Antídoto: SLIs que reflitam a experiência do usuário e do clínico, com alertas sobre os sintomas que importam.
• Planos de continuidade não testados. Um procedimento de contingência clínica existe no papel, mas nunca foi ensaiado e falha no dia. Antídoto: exercitar regularmente os planos de incidente grave e de contingência e consertar o que quebra.
• Revisões de incidentes movidas pela culpa. A busca de culpados empurra o relato para a clandestinidade e repete o dano. Antídoto: aprendizado pós-incidente sem culpa e sistêmico, com ações acompanhadas.
• Teatro do processo de mudanças. Um conselho de mudanças tão pesado que as equipes o contornam, ou tão leve que mudanças arriscadas são entregues sem verificação. Antídoto: dimensionar — pré-aprovar mudanças padrão, reservar a revisão para as genuinamente arriscadas.
• Sem registro de configuração. Ninguém consegue responder "o que esta mudança afetará?" durante um incidente. Antídoto: manter um CMDB ou equivalente, com responsáveis e dependências.

Modelo de maturidade#

Lista de verificação#

• Todo serviço em produção tem um responsável nomeado e um orçamento de operação protegido durante a sua vida operacional.
• A equipe que opera cada serviço entende como ele foi construído (ou existe uma transição documentada, com garantia e plantão compartilhado).
• SLIs e SLOs estão definidos, e as metas dos sistemas clínicos foram fixadas com clínicos; os SLAs externos são mais frouxos do que os SLOs internos.
• A observabilidade (registros, métricas, rastros) e os alertas baseados em sintomas refletem a experiência do clínico e do usuário, e não apenas a saúde do servidor.
• A gestão de incidentes tem níveis de gravidade, metas de resposta, um papel de comandante de incidente e uma fonte única da verdade durante a resposta.
• A gestão de problemas corrige as causas-raiz; as revisões pós-incidente são sem culpa e suas ações são acompanhadas até o fechamento.
• A gestão de mudanças é dimensionada: mudanças padrão pré-aprovadas e automatizadas; apenas as arriscadas são revistas, com contribuição clínica.
• Os procedimentos de continuidade de negócios e de contingência clínica estão escritos, ligados ao registro de perigos e ensaiados ao menos uma vez por ano.
• As escalas de plantão são adequadamente dotadas de pessoal, humanas e justamente remuneradas; a central de serviços é dimensionada para a demanda real 24/7.
• Um registro de configuração (CMDB ou equivalente) lista componentes, dependências, versões e responsáveis e sustenta a aplicação de correções de segurança.
• Um plano de desativação cobre migração/arquivamento de dados sob a lei de retenção, redirecionamento de usuários e preservação dos registros de segurança e de auditoria.

Fontes-chave#

• ITIL 4 — o sistema de valor de serviço e as práticas de gestão (incidente, problema, mudança, central de serviços, gestão de níveis de serviço) — PeopleCert / AXELOS.
• Google — Site Reliability Engineering e The Site Reliability Workbook (SLIs, SLOs, orçamentos de erro, plantão, post-mortems sem culpa).
• GOV.UK Service Manual — operar e iterar um serviço em produção; monitorar o estado de um serviço; manter um serviço após o lançamento.
• NHS England — normas de gestão de riscos clínicos DCB0129/DCB0160 e o tratamento da indisponibilidade do sistema como perigo clínico (ver Tópico 1.6).
• NHS England / NCSC — operações de cibersegurança, o Data Security and Protection Toolkit (DSPT) e as lições do incidente WannaCry de 2017 (ver Tópico 1.7).
• ISO/IEC 20000 (gestão de serviços de TI) e ISO 22301 (sistemas de gestão de continuidade de negócios).
• DevOps Research and Assessment (DORA) — capacidades que ligam o desempenho de entrega e o operacional (monitoramento, mudança, confiabilidade).
• OKRs e KPIs para relatórios operacionais e de confiabilidade à liderança (ver Tópico 10.0 — Objetivos e resultados-chave (OKRs)).

Referências#

1. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. Incident management — Wikipedia — https://en.wikipedia.org/wiki/Incident_management
4. Change management (ITSM) — Wikipedia — https://en.wikipedia.org/wiki/Change_management_(ITSM)
5. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
6. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
7. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
8. Service-level objective — Wikipedia — https://en.wikipedia.org/wiki/Service-level_objective
9. Service level indicator — Wikipedia — https://en.wikipedia.org/wiki/Service_level_indicator
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
12. Configuration management database — Wikipedia — https://en.wikipedia.org/wiki/Configuration_management_database
13. Help desk — Wikipedia — https://en.wikipedia.org/wiki/Help_desk
14. Site Reliability Engineering (SRE book) — Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (eds.), Google — https://sre.google/books/
15. ITIL 4 Foundation and service management practices — PeopleCert / AXELOS — https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-foundation-2565
16. Service Manual: operating a service and monitoring its status — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/technology/monitoring-the-status-of-your-service
17. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
18. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
19. ISO/IEC 20000-1 — IT service management systems — International Organization for Standardization — https://www.iso.org/standard/70636.html
20. ISO 22301 — Security and resilience: business continuity management systems — International Organization for Standardization — https://www.iso.org/standard/75106.html
21. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/