Saúde Mental em DevOps e SRE: O Estresse de Manter Tudo Funcionando
SRE (Site Reliability Engineer) e DevOps carregam algo que outros engenheiros não têm: quando tudo funciona, você é invisível. Quando algo falha, você é o centro de atenção, sob pressão, com stakeholders ansiosos, frequentemente às 3h da manhã. Sou Deivison Mendes (CRP-04/65709), psicólogo especializado em saúde mental de profissionais de TI. Agende uma conversa.
O ciclo de on-call e saúde mental
On-call é documentado como um dos maiores estressores em engenharia de software. A antecipação de incidentes, a interrupção do sono, a pressão durante incidentes ativos, e o debriefing posterior acumulam como estresse crônico. Pesquisa da Google SRE team mostra que on-call com mais de um alerta/semana noturno já é associado a níveis elevados de estresse.
A culpa do incidente: blame culture vs. blameless postmortems
Em culturas de blame, o SRE que fez o deploy que causou o incidente é responsabilizado individualmente. Isso cria hipervigilância, medo de deployar e reluctância em admitir erros, o que paradoxalmente aumenta o risco de incidentes futuros. Postmortems blameless (sem atribuição de culpa individual) são práticas baseadas em evidências de segurança psicológica.
DevOps como 'firefighter crônico'
Quando a dívida técnica é alta e os incidentes são frequentes, DevOps e SREs vivem em modo de apagar incêndio permanente. Essa hiperativação crônica do sistema de resposta a ameaças é o mecanismo central do burnout em on-call engineers.
Referências
- Beyer B et al. (2016). Site Reliability Engineering: How Google Runs Production Systems. O'Reilly. Disponível em: https://sre.google/sre-book/table-of-contents/
- Dekker S. (2014). The Field Guide to Understanding 'Human Error'. Ashgate.
- Graziotin D et al. (2018). What happens when software developers are unhappy. J Syst Softw. Disponível em: https://doi.org/10.1016/j.jss.2018.02.041