Greve de seguranças na big tech: como devs devem se preparar

Uma greve de seguranças na Califórnia pode fechar os escritórios de OpenAI, Google e outras big techs a partir de sexta-feira. Para quem trabalha com software, isso não é só notícia trabalhista — é um alerta sobre o quanto estamos vulneráveis quando a infraestrutura “invisível” para. E, na minha experiência, são justamente esses pontos cegos que derrubam produção quando ninguém esperava.

O que está acontecendo segundo o Olhardigital.com.br

O sindicato SEIU-UWWW, que representa cerca de 14 mil profissionais de segurança na Califórnia, entregou na terça-feira um aviso de greve com 72 horas de antecedência. Os trabalhadores exigem salários maiores, melhores planos de saúde e treinamento profissional mais completo. Se nada mudar, turnos iniciados a partir das 4h30 de sexta-feira serão paralisados — e isso afeta diretamente empresas como OpenAI, Google e outras gigantes da Bay Area.

A consequência prática é imediata: prédios sem seguranças não funcionam. E prédio sem funcionar significa trabalho remoto forçado. A Anthropic já passou por isso no fim de agosto, quando orientou funcionários de São Francisco a trabalhar de casa por dois dias depois que a Allied Universal avisou que suas equipes poderiam cruzar os braços.

Repare no contraste: estamos falando de empresas que treinam modelos de bilhões de dólares, rodam datacenters em escala planetária — mas dependem de seguranças humanos para abrir a porta. Essa é a ironia que pouca gente comenta.

Por que isso importa para quem programa

Na minha experiência, a maioria dos devs trabalha com a premissa de que “o escritório está lá, o Wi-Fi funciona, a badge abre a porta”. Quando esse pressuposto cai, surgem problemas que ninguém escreveu no runbook. Já passei por incidentes assim — e o que aprendi é que preparação para trabalho remoto é tão importante quanto qualquer feature de produção.

Para os engenheiros que atuam nessas big techs especificamente, três coisas mudam imediatamente:

• Acesso físico a servidores on-premise: se você precisa plugar um cabo, trocar um disco ou resetar um appliance, sem segurança você simplesmente não entra. E ninguém vai liberar acesso noturno sem policy clara.
• Onboarding de novos funcionários: novos hires que receberiam notebook presencialmente ficam travados até que a logística se resolva.
• Ambientes regulados: times que lidam com dados HIPAA, SOC 2 ou com workloads de IA que exigem hardware específico em salas trancadas ficam impedidos de operar.

Na Prática — Como se preparar para um “office lockdown” inesperado

Se você trabalha em qualquer empresa que tenha escritório físico, considere esse cenário um drill real. Aqui vai um checklist que aplico com meus clientes e na minha própria infraestrutura:

1. Tenha um jump host confiável com bastion: nada de expor SSH direto na internet. Use AWS SSM Session Manager ou um bastion hardened com MFA.
2. Configure SSO com fallback: se o IdP principal cair, ter um método alternativo (TOTP, chave física YubiKey) impede que você fique travado fora dos sistemas.
3. Documente acessos críticos fora do Notion/Confluence corporativo: mantenha um backup criptografado (KeePassXC, por exemplo) com IPs internos, usuários de banco e runbooks essenciais. Se a empresa bloquear o SSO, você ainda consegue operar.
4. Teste sua VPN pelo menos 1x por mês: VPNs não testadas quebram no pior momento. Eu uso um cronjob simples para validar túnel:

#!/bin/bash
# healthcheck-vpn.sh - roda via cron todo dia útil às 8h
VPN_ENDPOINT="vpn.empresa.com"
INTERNAL_HOST="10.0.1.50"

if ! ping -c 2 -W 3 "$VPN_ENDPOINT" &> /dev/null; then
  echo "[ALERTA] VPN endpoint inalcançável" | mail -s "VPN DOWN" sre@empresa.com
  exit 1
fi

if ! ssh -o ConnectTimeout=5 -o BatchMode=yes sre@$INTERNAL_HOST "echo ok" &> /dev/null; then
  echo "[ALERTA] SSH interno falhou via bastion" | mail -s "SSH DOWN" sre@empresa.com
  exit 2
fi

echo "[OK] Infraestrutura remota operacional"

5. Garanta que seu laptop tenha trabalho offline produtivo: isso inclui IDE com extensões locais, container runtime (Docker ou Podman), e uma stack reproduzível com devcontainer.json ou flake.nix.

Devcontainer: a melhor defesa contra escritório fechado

Se eu pudesse dar uma dica só para devs que dependem de GPUs, workstations ou qualquer hardware físico: containerize seu ambiente. Um devcontainer.json bem-feito permite que você suba seu stack completo em qualquer máquina, inclusive uma VM na nuvem.

{
  "name": "AI Workstation",
  "image": "mcr.microsoft.com/devcontainers/python:3.11",
  "features": {
    "ghcr.io/devcontainers/features/docker-in-docker:2": {},
    "ghcr.io/devcontainers/features/nvidia-cuda:1": {
      "version": "12.2"
    }
  },
  "postCreateCommand": "pip install -r requirements.txt",
  "customizations": {
    "vscode": {
      "extensions": ["ms-python.python", "ms-toolsai.jupyter"]
    }
  },
  "forwardPorts": [8888, 6006],
  "remoteUser": "dev"
}

Quando a Anthropic mandou todo mundo pra casa em agosto, engenheiros com ambientes containerizados provavelmente retomaram o trabalho em minutos. Quem dependia de setup local proprietário levou horas — ou dias.

Erros Comuns — O que evitar quando o “remote forçado” chega

Já vi times entrando em pânico em situações parecidas. Os deslizes mais frequentes:

• Ativar VPN pessoal para “resolver rápido”: usar uma VPN comercial não-gerenciada para acessar recursos da empresa é uma violação gravíssima de compliance. Eu já recusei pedidos assim de clientes — não negocie esse ponto.
• Compartilhar credenciais por Slack/WhatsApp: na pressa, gente sênior acaba mandando senha no chat. Use 1Password, Bitwarden ou Vault com auditoria.
• Esquecer que EDR precisa de internet: soluções de Endpoint Detection and Response perdem telemetria quando a máquina fica off-line muito tempo. Avise o time de segurança antes.
• Subir recursos na sua conta pessoal: abrir uma AWS pessoal “porque é mais rápido” gera nightmare de billing e governança depois.
• Não avisar compliance sobre mudança de jurisdição: se você está em SP e a empresa acha que você está na Bay Area, problemas regulatórios aparecem em auditoria.

Comparando os modelos de trabalho das big techs envolvidas

Vale olhar como cada uma lida (ou deveria lidar) com esse tipo de interrupção:

A tendência, na minha leitura, é que empresas de IA pura como Anthropic e OpenAI acabem migrando para modelos mais flexíveis justamente porque o produto delas não exige prédio. Já empresas com labs de hardware (Apple, Google X, Meta Reality Labs) têm amarras físicas reais.

O lado humano que devs esquecem

Antes de seguir, uma reflexão que raramente aparece em posts técnicos: os seguranças em greve não são NPCs. São pessoas protegendo edifícios onde engenheiros ganham 10x mais e recebem stock options. Quando você reclamar do Wi-Fi da cafeteria do escritório, lembre que tem gente que faz aquela cafeteria funcionar todos os dias.

Segundo o Olhardigital.com.br, os trabalhadores pedem salários maiores, melhores condições de saúde e treinamento. Em um estado onde o custo de vida explodiu — aluguel médio em São Francisco passa de US$ 3.000/mês — isso é mais do que justo. A categoria técnica tende a ser solidária com outros movimentos trabalhistas. Eu sou.

FAQ — Perguntas reais que devs fazem

1. Se eu trabalho remoto em uma big tech e a empresa fechar o escritório, isso me afeta diretamente?

Em geral não no curto prazo, mas afeta acesso a hardware específico, reuniões presenciais com stakeholders, e processos que dependem de assinatura física (contratos, shipments de equipamentos). Também pode acelerar políticas de RTO (Return to Office) caso a empresa queira “compensar” a percepção de baixa produtividade.

2. Como me preparar para um lockdown súbito do escritório?

Documente acessos críticos, tenha um device secundário funcional, valide sua VPN periodicamente, containerize seus ambientes de dev e mantenha um canal de comunicação independente do corporativo (Signal, por exemplo). Faça um drill real uma vez por trimestre.

3. Greve de seguranças pode mesmo fechar uma big tech?

Sim. Sem pessoal de segurança, prédios inteiros ficam sem autorização legal de operar — risco de incêndio, evacuação, compliance com OSHA e normas locais. Foi exatamente o que aconteceu com a Anthropic em agosto.

4. Isso vai acelerar ou frear o trabalho remoto no setor de tech?

Acelerar. Toda vez que um evento desse paralisa escritórios sem causar prejuízo massivo, a percepção de “precisamos mesmo de RTO?” enfraquece. Empresas com cultura flexível saem ganhando em atratividade de talentos.

5. Como posso apoiar os trabalhadores sem ficar de fora do trabalho?

Honre as decisões do sindicato local, não tente contornar piquetes, e se tiver voz política dentro da empresa, pressione por contratos justos com fornecedores. A Allied Universal, prestadora envolvida no caso da Anthropic, é a mesma megacorporação de segurança que atende dezenas de empresas de tech — pressão coletiva funciona.

O que ficar de olho nos próximos dias

Vale acompanhar se novas empresas seguem o exemplo da Anthropic e orientam trabalho remoto preventivo, mesmo sem greve confirmada. Também fico de olho em comunicados oficiais da SEIU-UWWW e na resposta da Allied Universal. Se você é dev em qualquer dessas empresas, considere essa semana um ótimo momento para revisar seus planos de contingência — antes que vire urgência.

E um lembrete final: qualquer infra que só funciona dentro de um prédio é uma infra frágil. Se sua stack de produção precisa de alguém fisicamente presente para se manter viva, você tem um problema de arquitetura — não de carreira, mas de resiliência.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.