Uma greve de profissionais de segurança pode travar o acesso físico aos escritórios da OpenAI, Google e outras big techs na Califórnia a partir desta sexta-feira. E, antes que você pense “isso não me afeta porque estou no Brasil”, deixa eu te mostrar por que a sua próxima sprint pode depender diretamente do que acontece do outro lado do mundo.
Segundo o Olhardigital.com.br, o sindicato SEIU-UWWW entregou aviso de greve com 72 horas de antecedência, e a interrupção está prevista para começar às 4h30 da sexta-feira (horário local). São cerca de 14 mil profissionais de segurança que protegem instalações de gigantes da tecnologia. Quando esse tipo de paralisação acontece, o efeito cascata atinge engenharia, produto, operações e até a cadeia de fornecedores.
O que está em jogo além do portão
A Anthropic já tinha saído na frente: no fim de agosto, mandou funcionários de São Francisco trabalharem de casa por dois dias depois que a Allied Universal — a mesma contratada — ameaçou greve. Isso mostra que o impacto não é teórico, já aconteceu.
Na prática, quando seguranças cruzam os braços, três coisas quebram ao mesmo tempo:
- Acesso físico a data centers e labs: eng de hardware, SREs e equipes de infraestrutura perdem entrada.
- Acesso a hardware dedicado: GPUs, rigs de teste, devices em bancada que não estão no home office.
- Continuidade de experimentos críticos: training jobs longos, simulações físicas e deployments on-prem podem ser interrompidos no meio.
E tem um quarto ponto que pouca gente comenta: a paralisação expõe o quanto a operação das big techs depende de trabalhadores terceirizados. Os seguranças não são funcionários da OpenAI ou do Google — são da Allied Universal e congêneres. É o mesmo modelo que conhecemos no Brasil com limpeza, portaria e facilities.
Por que isso deveria estar no seu radar como dev
Três motivos.
1. Você depende da cadeia, mesmo remoto. Se um data center da AWS US-West fica sem equipe de segurança, sua região EC2 pode sofrer latência, throttling ou failover. Já vi deploys quebrarem por causa de incidente físico a milhares de quilômetros do meu laptop.
2. Modelos de IA têm janelas de treinamento curtas. Um job de fine-tuning de LLM que leva 72 horas pode ser interrompido por falta de acesso ao cluster. Os custos vão de dezenas a centenas de milhares de dólares por hora, dependendo do hardware.
3. Trabalho remoto só funciona com preparo. Quando a empresa te avisa em cima da hora que “amanhã é home office”, você descobre que sua VPN travou, seu MFA não está configurado no celular pessoal e seu ambiente de dev estava em uma máquina do escritório.
Na Prática: seu “kit de sobrevivência” para escritório fechado
Na minha experiência, devs que passam por isso duas vezes se preparam. Quem passa pela primeira vez aprende na marra. Vou te poupar do sofrimento.
- Mantenha um ambiente reprodutível em casa. Não é só clonar o repo — é ter Docker, Node, Python, banco de dados e secrets sincronizados. Eu uso um
docker-compose.ymlversionado que sobe tudo com um comando. - Tenha um backup de acesso. Yubikey + autenticação TOTP no celular + um token de backup guardado em local seguro. Nada de depender de um único fator.
- Sincronize dotfiles. Seu
.zshrc, aliases, scripts de setup. Eu mantenho tudo em um repositório privado no GitHub chamadodotfiles. - Documente dependências de hardware. Se algum serviço depende de um device que só existe no escritório, anote. Vai chegar o dia em que esse device vai sumir e você vai receber um ticket às 23h.
- Tenha um canal assíncrono funcionando. Slack/Teams com notificações push ativas, status claros, e uma cultura de documentar decisões por escrito.
Agora, um script que eu uso para auditar minha prontidão remota. Salvei como bin/remote-readiness:
#!/usr/bin/env bash
# remote-readiness - verifica se seu setup remoto está completo
set -e
echo "🔍 Auditando prontidão para trabalho remoto..."
echo ""
# 1. Verifica VPN
if ping -c 1 -W 2 vpn.empresa.com &> /dev/null; then
echo "✅ VPN acessível"
else
echo "❌ VPN inacessível - configure um fallback"
fi
# 2. Verifica Docker
if command -v docker &> /dev/null; then
echo "✅ Docker instalado: $(docker --version)"
else
echo "❌ Docker não encontrado"
fi
# 3. Verifica dotfiles versionados
if [ -d "$HOME/.dotfiles" ] || [ -d "$HOME/dotfiles" ]; then
echo "✅ Dotfiles encontrados"
else
echo "⚠️ Dotfiles não versionados - crie um repo"
fi
# 4. Verifica autenticação configurada
if command -v gpg &> /dev/null && gpg --list-secret-keys &> /dev/null; then
echo "✅ Chaves GPG disponíveis para assinatura de commits"
else
echo "⚠️ Sem chave GPG configurada"
fi
# 5. Verifica MFA no dispositivo móvel
if command -v oathtool &> /dev/null || command -v google-authenticator &> /dev/null; then
echo "✅ Ferramenta TOTP disponível"
else
echo "⚠️ Configure um app autenticador (Authy, 1Password, etc.)"
fi
echo ""
echo "📋 Próximos passos: documente um runbook de 'escritório fechado' no Notion/Confluence"Roda isso uma vez por mês. Vai te poupar de descobrir na sexta às 9h que seu setup está quebrado.
Erros comuns que devs cometem quando o escritório fecha
Erro 1: achar que “remoto” significa “qualquer lugar”. Trabalho remoto bem feito precisa de ergonomia, internet cabeada, monitor decente e iluminação. Não é só abrir o notebook na mesa da cozinha.
Erro 2: depender de Wi-Fi compartilhado. Em 2024, durante um apagão no Sul do Brasil, vi gente perdendo deadlines porque o roteador do vizinho caiu. Tenha um plano B: chip 4G/5G com dados suficientes ou Starlink.
Erro 3: misturar dispositivos pessoais e profissionais. Quando o escritório fecha, a empresa pode liberar acesso via laptop pessoal. Cuidado: isso aumenta a superfície de ataque. Use profiles separados no navegador, não reuse senhas, e mantenha o SO atualizado.
Erro 4: ignorar a parte humana. Greve não é só um evento logístico. Tem gente lutando por salário, saúde e dignidade. Como profissional de tech, vale entender o contexto: o SEIU-UWWW representa trabalhadores que protegem as instalações onde o seu código roda. Eles não são abstratos.
Erro 5: não testar o plano de contingência. Um plano de continuidade que nunca foi testado não é um plano, é wishful thinking. Faça simulado trimestral: “se amanhã o escritório fechar, o que quebra?”.
O contexto maior: sindicalização em tech
Esse movimento na Califórnia não é isolado. Em 2022, engenheiros da Activision Blizzard formaram sindicato. Em 2023, foram osQA testers da Microsoft. Em 2024, parte do Google Cloud se sindicalizou. O setor de segurança terceirizada é só mais uma frente.
O ponto é: o modelo de terceirização em tech tem limite. Quando a empresa lucra bilhões enquanto o trabalhador que protege o prédio ganha salário mínimo, a tensão explode. E a primeira coisa que explode é o acesso físico — que, ironicamente, depende desses mesmos trabalhadores.
FAQ — perguntas que devs estão fazendo
1. Uma greve de seguranças pode realmente afetar produtos como ChatGPT e Gemini?
Indiretamente, sim. Se data centers ficarem sem equipe, jobs de treinamento e inferência podem degradar. Para o usuário final, o impacto tende a ser latência e instabilidade, não indisponibilidade total — as big techs têm redundância geográfica.
2. Como dev remoto no Brasil, isso me afeta?
Se você usa serviços hospedados nos EUA (AWS, GCP, Azure US), pode sentir instabilidade durante o período. Se a empresa que você trabalha tem escritório nos EUA e depende de times presenciais por lá, decisões de produto podem atrasar.
3. Qual a chance real da greve acontecer?
Historicamente, avisos de greve nos EUA funcionam como pressão em negociação. A paralisação confirmada depende de acordo até quinta-feira. Se houver acordo, a greve é suspensa. Se não houver, começa sexta às 4h30 (horário local).
4. Como me preparar se minha empresa também tiver escritório nos EUA?
Tenha um plano documentado de trabalho remoto, teste sua stack de casa, confirme que VPN/MFA funcionam, e mantenha comunicação aberta com seu gestor sobre prioridades da semana.
5. Vale a pena investir em Starlink ou 5G como backup?
Depende do seu cenário. Se sua internet residencial é o único link de produção, sim. Em São Paulo e capitais do Sudeste, uma combinação de fibra + chip 5G empresarial cobre 99% dos casos. Para quem mora em região remota, Starlink virou padrão.
Considerações finais
Eu acompanho o noticiário de tech há mais de uma década e uma coisa é certa: eventos que parecem distantes viram incidente local em 48 horas. A greve dos seguranças californianos pode virar seu deploy quebrado, sua sprint atrasada ou seu ticket sem dono.
Por isso, a lição que fica não é sobre política americana nem sobre trabalho remoto. É sobre resiliência operacional: quem tem documentação, ambiente reprodutível, comunicação clara e plano testado, atravessa esses momentos sem perder o sono. Quem não tem, aprende na marra — e o custo é alto.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Se quiser, posso publicar uma versão expandida desse script de auditoria remota com integração a Slack para avisar a equipe quando algo quebra.