- O SRE do Google começou com pequenos data centers e operações baseadas em scripts Python, e reuniu experiências de como aumentou a confiabilidade em um ambiente que cresceu para uma escala de computação mais de 1.000 vezes maior e uma escala de rede mais de 10.000 vezes maior
- Na resposta a incidentes, antes de agir rápido vem a segurança da mitigação; procedimentos de recuperação incorretos podem ampliar falhas em cascata em vez de reduzir a interrupção
- Os casos do YouTube e do Google Calendar mostram a necessidade de deploy canário para limitar mudanças globais, de um Big Red Button que permita reversão imediata e de testes de integração que validem o caminho real
- Quando uma dependência central falha, como no incidente de tokens OAuth de 2017, não só os usuários como também a estrutura interna de resposta é abalada; por isso são necessários canais de comunicação de backup e degradação gradual
- Rollouts frequentes, mitigação automatizada, exercícios de recuperação de desastres e diversidade de hardware são princípios práticos para reduzir o MTTR e evitar pontos únicos de falha em sistemas distribuídos complexos
Mudanças de escala vividas pelo Google SRE em 20 anos
- Há 20 anos, o Google operava dois pequenos data centers, cada um com milhares de servidores, e dois links de rede de 2.4G conectados em forma de anel
- Na época, a operação dependia fortemente de scripts Python como
Assigner,AutoreplacereBabysitter, além de arquivos de configuração com nomes individuais de servidores - Um pequeno banco de dados de máquinas chamado MDB era usado para organizar e manter continuamente as informações de cada servidor
- Hoje, o poder de computação é mais de 1.000 vezes maior e a rede é mais de 10.000 vezes maior, mas o esforço operacional por servidor caiu e a confiabilidade da pilha de serviços melhorou
- As ferramentas operacionais evoluíram de um conjunto de scripts para um ecossistema de serviços e, depois, para uma plataforma integrada que fornece confiabilidade básica
Princípios de resposta extraídos de uma falha no YouTube
- Em 2016, o YouTube sofreu uma falha global de 15 minutos por causa de um bug em um sistema distribuído de cache em memória, interrompendo a capacidade de entregar vídeos
- As medidas de mitigação precisam ser proporcionais à gravidade do incidente
- Durante a falha do YouTube, um procedimento arriscado de load shedding não corrigiu o problema e criou falhas em cascata
- Uma mitigação arriscada pode, no melhor caso, resolver a interrupção, mas no pior caso pode falhar e aumentar a duração do incidente
- Mesmo em situações que pareçam exigir desviar do procedimento padrão, a escolha deve vir depois de observar e avaliar a gravidade
- Mecanismos de recuperação devem ser amplamente testados antes de uma emergência real
- Executar pela primeira vez um procedimento arriscado de mitigação durante um incidente é como usar uma escada pela primeira vez ao evacuar um incêndio em um prédio alto
- É preciso verificar antes se o procedimento de recuperação realmente faz o que precisa fazer e se os responsáveis sabem executá-lo
- O próprio teste também ajuda a reduzir o risco ao aplicar essa medida
- Toda mudança deve limitar o raio de impacto com deploy canário
- Uma mudança na configuração de cache prejudicou gravemente o serviço do YouTube por 13 minutos como consequência não intencional
- Se a mudança global tivesse sido liberada gradualmente com uma estratégia canário, o incidente poderia ter sido contido antes de atingir todo o ambiente
- Materiais relacionados incluem o artigo sobre estratégia canário e o vídeo da apresentação na SREcon
Rollback e testes: lições da falha no Calendar
- Mudanças arriscadas precisam de um Big Red Button predefinido
- O Big Red Button é uma proteção simples e fácil de acionar para reverter a causa de um estado indesejado
- Houve um caso em que um engenheiro conseguiu evitar por pouco uma grande falha ao desligar da tomada um computador desktop antes que o problema se propagasse
- Ao planejar um rollout importante, é preciso pensar: “qual é o meu Big Red Button?”; toda dependência de serviço deve ter algum mecanismo acionável em emergência
- Um texto relacionado é Generic Mitigations
- Testes unitários não bastam; são necessários testes de integração
- Testes unitários verificam se componentes individuais funcionam como esperado, mas não reproduzem completamente o ambiente de execução nem as exigências de produção
- Testes de integração servem para validar se jobs e tasks conseguem fazer cold start e se os componentes, juntos, formam o sistema desejado
- Na falha do Calendar, o caminho de teste era diferente do caminho real de uso, então, apesar de haver muitos testes, eles não ajudaram a avaliar como a mudança se comportaria na prática
A falha de tokens OAuth de 2017 e a continuidade operacional
- Em fevereiro de 2017, tokens OAuth indisponíveis fizeram milhões de usuários serem desconectados de dispositivos e serviços, e 32.000 dispositivos OnHub e Google WiFi realizaram reset de fábrica
- As falhas de login aumentaram em 10 vezes os pedidos manuais de recuperação de conta, e o Google levou cerca de 12 horas para se recuperar totalmente do incidente
- A resposta a incidentes precisa de um canal de backup separado do canal principal de comunicação
- Na época, as equipes esperavam conseguir gerenciar o incidente com Google Hangouts e Google Meet
- Mas, em uma situação em que 350 milhões de usuários haviam sido desconectados de dispositivos e serviços, depender de serviços do próprio Google não era adequado
- É necessário preparar e testar um canal de comunicação de backup com dependências separadas
- Os serviços devem continuar funcionando com degradação gradual (graceful degradation) mesmo em situações excepcionais
- Não basta dividir disponibilidade apenas em “totalmente normal” ou “totalmente fora do ar”
- Manter funcionalidades mínimas durante o modo degradado pode oferecer uma experiência mais consistente ao usuário
- A degradação pode até não ser visível para o usuário, e os serviços devem ser projetados para continuar operando mesmo em condições excepcionais
Desastres, automação, rollouts e diversidade de hardware
- Resiliência a desastres e testes de recuperação são elementos centrais de uma estratégia de continuidade de negócios
- Testes de resiliência validam se serviços ou sistemas conseguem suportar falhas, latência e interrupções
- Testes de recuperação verificam se, após uma parada total, o serviço consegue voltar ao estado normal
- Devem ser considerados também cenários extremos, como desastres naturais ou ataques cibernéticos, como em Weathering the Unexpected
- Também é útil que a equipe revise cenários em formato de exercício de mesa, como “o que acontece se parte da conectividade de rede cair inesperadamente?”
- Para incidentes com sinais claros, a automação da mitigação é um meio de reduzir o MTTR
- Em março de 2023, vários equipamentos de rede falharam quase ao mesmo tempo em diversos data centers, causando perda generalizada de pacotes
- Durante esse incidente de 6 dias, cerca de 70% dos serviços sofreram diferentes níveis de impacto conforme a localização, a carga do serviço e a configuração no momento da falha da rede
- Proporção de serviços impactados: {p:70}
- Se o sinal de que uma falha específica ocorreu for claro, é possível iniciar automaticamente as ações de mitigação manual para reduzir o MTTR
- Em alguns casos, é melhor evitar primeiro o impacto ao usuário e só depois analisar a causa raiz
- Quanto maior o intervalo entre rollouts, mais difícil fica avaliar a segurança de uma mudança
- Em março de 2022, uma falha no sistema de pagamentos impediu a conclusão de transações de clientes, e o Community Day de Pokémon GO foi adiado
- A causa foi a remoção de um único campo do banco de dados, uma mudança que parecia segura porque o código já não usava mais esse campo
- No entanto, por causa do ciclo lento de rollout em partes do sistema, o ambiente em produção ainda usava esse campo
- Em sistemas complexos com múltiplos componentes, atrasos longos de rollout tornam muito difícil avaliar a segurança real de certas mudanças
- Com testes adequados, rollouts frequentes podem reduzir esse tipo de falha inesperada
- Uma versão global única de hardware pode se tornar um ponto único de falha
- Concentrar uma função importante em equipamentos de um único modelo pode simplificar a operação e a manutenção
- Mas, se esse modelo tiver um problema, essa função importante deixa de ser executada
- Em março de 2020, um equipamento de rede com um bug zero-day não detectado expôs o problema após uma mudança no padrão de tráfego, e como o mesmo modelo e versão eram usados em grande parte da rede, ocorreu uma interrupção regional significativa
- Como havia vários backbones de rede, foi possível enviar o tráfego de alta prioridade por caminhos alternativos que ainda funcionavam, evitando uma falha total
- Bugs potenciais em infraestrutura crítica podem ficar ocultos até que um evento aparentemente inofensivo os revele, e manter uma infraestrutura diversa pode ser a diferença entre uma falha problemática e uma interrupção total
1 comentários
Opiniões no Hacker News
O texto é excelente e parece amplamente aplicável. Não há exatamente partes do tipo “isso só funciona no Google”
Canais de comunicação, canais de reserva e até reservas para esses canais de reserva são realmente importantes. Na Netflix, ao escolher um fornecedor para um sistema usado durante incidentes, sempre verificávamos se ele não estava em cima da AWS; no reddit, tínhamos um IRC de reserva em um servidor do escritório para o caso de o IRC usado normalmente não funcionar
Ouvi dizer que o Google também tem um servidor IRC de reserva na AWS, mas isso pode ser só lenda. O ponto central é garantir um canal de contato auxiliar o mais independente possível da sua própria infraestrutura
Como aquela equipe estava no caminho crítico, se o chamado fosse causado pelo nosso sistema, não era nem um pouco improvável que não só o Google Meet, mas também o Google.com tivesse caído. Por causa do Gmail, e-mail também não funcionaria; por causa do Google Fi, o celular corporativo também não; e meu ISP em casa era Google Fiber/Webpass, então precisávamos de mais uma camada de contingência
Por isso, o Google de fato tem um servidor IRC de reserva para comunicação. Não vou dizer onde fica, mas ele foi colocado explicitamente fora da infraestrutura do Google exatamente por esse motivo
No sentido de ser “amplamente aplicável e não algo que só funciona no Google”, algo que quase nunca vi em outros lugares foi uma sala de pânico operacional. Refiro-me a uma sala segura com uma VPN de reserva para o ambiente de produção
Um dia, a SAN de produção ficou estranha, o data center on-premises caiu e, junto com ele, a Atlassian também morreu. Sem Jira, sem Confluence, provavelmente sem CI/CD, sem procedimentos de recuperação organizados, restando apenas conhecimento tribal
As pessoas ficaram furiosas, e com razão. Colocar sistemas voltados ao cliente e sistemas relacionados à infraestrutura no mesmo cesto é realmente perigoso
Pelo menos era assim há 2 anos, quando eu ainda trabalhava lá
Um dia eu gostaria de ouvir uma solução para o problema de partida totalmente a frio. Empresas com stacks internos enormes têm dependências circulares na infraestrutura central
Em redes definidas por software, algum software precisa estar rodando para reiniciar o roteamento de pacotes; máquinas sem disco precisam de armazenamento para inicializar; e serviços de autenticação precisam de acesso ao armazenamento para fazer o bootstrap da autorização de segurança
Hoje isso é tratado operando várias regiões independentes, de modo que um data center totalmente desligado é inicializado a partir da infraestrutura existente. Mas nunca ouvi falar de alguém que tenha levantado todo o stack novamente a partir de um estado de energia totalmente cortada
Alguns anos atrás, quando o Facebook danificou completamente a rede de produção, as máquinas ainda estavam ligadas e parte da conectividade interna permaneceu. Se algo como uma grande tempestade solar derrubar a rede elétrica no mundo todo por tempo suficiente para esgotar até os geradores, não há garantia de que nuvens como AWS ou GCP necessariamente voltem à vida
Imagino que existam pequenos data centers dedicados com excelente energia de reserva e capacidade de isolamento total contra surtos da rede elétrica
No topo do stack, isso era útil para rastrear dependências adicionadas silenciosamente por autores de bibliotecas; na base, ajudava a garantir que as coisas que deveriam estar no fundo realmente estivessem no fundo
Também fazíamos inicialização e desligamento automáticos de clusters virtuais para que os procedimentos documentados não ficassem obsoletos, e, nos 6 anos em que fui SRE, vi esse procedimento cair de 90 dias para menos de 1 hora
Também treinávamos regularmente a reinicialização do zero de coisas como gerenciamento global de chaves de criptografia que exigem objetos físicos, e os exercícios anuais DiRT tentavam garantir que nenhuma pessoa, equipe ou escritório fosse requisito indispensável para manter os sistemas operando
Se você começar tarde, é muito doloroso; mas, se fizer isso desde o início, logo vira algo familiar e você consegue detectar cedo mudanças que quebram coisas ou dependências estranhas
Isso também se aplica ao hardware. A arquitetura muda para suportar situações em que algo é desconectado ou reinicializado. Passa a exigir mais automação, controle de versão e gestão de mudanças, e, graças a isso, além de prevenir falhas e acelerar a recuperação, todo o trabalho também fica mais rápido e simples. É uma grande mudança cultural
Pelo que me lembro, parte da abordagem é considerada informação sensível, então não vou entrar em mais detalhes
Também seria interessante saber qual rede elétrica já fez mais partidas a frio. Idealmente, um lugar assim já deveria ser bom nisso. Imagino que seja em algum ponto do Caribe ou da África
Dito isso, a partida a frio de uma rede elétrica pequena, por exemplo uma ilha remota com um gerador a diesel e energia solar, pode ser fácil demais para ser um bom estudo de caso
É claro que a própria internet não pode passar por uma partida a frio como uma rede elétrica de corrente alternada. Há ASs demais. Se você pensar por um momento no que AS significa, fica claro por que uma partida a frio coordenada e ensaiada é impossível
Para se aprofundar mais nesse tema, estou quase terminando de ler Building Secure and Reliable Systems, do Google, e não é uma leitura leve; está mais para um livro-texto de verdade
É um livro bem interessante e muito do conteúdo parece senso comum, mas, como dizem que a própria expressão “senso comum” é contraditória, foi útil para dar uma atualizada geral no conhecimento de uma só vez
Ouvi recentemente que algumas empresas encerraram suas organizações de SRE e transferiram seus integrantes para times de SWE. Há rumores de que LinkedIn, Adobe e Robinhood fizeram isso
Isso me fez pensar se SRE é um subproduto de uma economia de bolha em que havia muito dinheiro fácil. Será que não dá para operar sem manter um time separado de SRE a um custo alto?
Assim como administradores de sistemas ou testers de QA praticamente desapareceram e muitas funções passaram para os times de desenvolvimento de software, fico curioso se SRE ainda existirá daqui a 10 anos
Mas, no momento, com as demissões continuando, não há muitas empresas se importando com isso. A tendência de jogar desenvolvedores em problemas mesmo que não sejam sua área de especialidade não vai desaparecer do setor, e deve ficar ainda mais evidente em períodos de recessão
Desenvolvedores full-stack são um bom exemplo de juntar dois papéis sem pagar o dobro
Dito isso, o restante do argumento ainda me parece correto. Hoje, por causa de DevOps, o conjunto de competências exigido de desenvolvedores se ampliou e se sobrepõe bastante ao de SRE. As empresas provavelmente vão reduzir times de SRE e distribuir a responsabilidade entre desenvolvedores
Outro grande motivo é a automação. Ao ler o site linkado por um bom tempo, dá para perceber que, nos primeiros dias do Google, SREs faziam muito trabalho manual, como observar gráficos manualmente durante implantações
Na época, nem mesmo o Google tinha automação de sistemas suficiente, então SRE era essencial. A história de Sisyphus https://www.usenix.org/sites/default/files/conference/protec... ajuda a entender, em certa medida, como a estabilidade no emprego dos SREs foi garantida quando o Google fracassou na primeira tentativa de introduzir uma automação padronizada
Não faz sentido lógico entregar a operação do software que você escreveu para outra pessoa. Basta colocar SWEs de plantão. Se acham que trabalho manual é a melhor opção, que façam eles mesmos; e, se esse é o nível, deveriam ser demitidos como engenheiros ruins
É estranho que as entrevistas sejam tão rigorosas e, ao mesmo tempo, a pessoa não saiba como funciona o computador em que programa. Coisas como funcionamento de sistemas operacionais fazem parte até de cursos de graduação, então também é estranho empurrar isso para funções e cargos em que há muitos ex-administradores de sistemas que aprenderam principalmente por conta própria
Todos os bons SWEs que conheço entendiam como sistemas operacionais, computadores e redes funcionavam
O trabalho que SREs fazem hoje, como automação geral, fornecimento de ferramentas de desenvolvimento e melhoria da experiência do desenvolvedor, está migrando para times de plataforma. Acho que o papel vai mudar bastante daqui para frente
Um único time de SRE pode apoiar vários times de desenvolvimento, e muitas vezes os times de desenvolvimento gastam pouquíssimo tempo com aspectos de infraestrutura complexa ou sistemas distribuídos, porque não é algo com que se preocupem no dia a dia
Por isso faz sentido existir uma organização de infraestrutura que opere como uma unidade diferente dos times de desenvolvimento especializados. Chame isso de SRE, de time de SRE SWE ou simplesmente de infraestrutura; a partir de certo porte, surgem muitos interesses transversais entre times, e separá-los assim fica mais barato
Com SREs dedicados, você tem especialistas de verdade em operação e nos sistemas, ferramentas e alertas relacionados, além de uma responsabilidade clara pelos resultados. Mas, como eles não possuem completamente os sistemas que mantêm, podem surgir problemas organizacionais
Pode aparecer algo como “queremos lançar X, mas SRE é contra”, ou o inverso, e pessoas que não são SRE podem acabar não se responsabilizando por código difícil de dar suporte
Por outro lado, uma equipe de engenharia sem SRE pode reduzir esses problemas organizacionais e sociais, mas a confiabilidade operacional passa a ser apenas uma entre muitas prioridades
Na prática, acho que muitas empresas estão decidindo que confiabilidade como resultado de negócio não é tão importante assim. Especialmente quando o custo de oportunidade de desenvolver funcionalidades aumenta
Mitigação automática é algo em que é preciso pensar por muito tempo. Ao longo de 30 anos de carreira, vi várias vezes a mitigação automática piorar o problema. Por isso, é preciso avaliar com cuidado se a autocorreção é realmente necessária
Em 2014, criei uma solução interna de relatórios de crashes mobile, e parte do backend rodava em um único servidor que tinha o Redis como ponto único de falha. O processo de failover era semiautomático: uma pessoa precisava confirmar que o alerta era válido antes de iniciá-lo
Mesmo se caísse, não havia perda financeira real; no pior caso, os desenvolvedores dos apps mobile ficariam temporariamente incomodados. Em 10 anos de operação, as vezes em que foi necessário fazer failover davam para contar nos dedos de uma mão
Mesmo sendo um sistema sem SLA, ele teve uptime melhor do que sistemas internos muito mais importantes
Em contraste, basta olhar os casos do GitHub: https://github.blog/2023-05-16-addressing-githubs-recent-ava..., https://github.blog/2018-10-30-oct21-post-incident-analysis/, https://www.datacenterknowledge.com/archives/2012/12/27/gith...
Claro que o GitHub opera em uma escala muito maior. O ponto é que redundância e mitigação automática acrescentam complexidade e, por definição, entram em ação em situações imprevistas, quase nunca testadas
Portanto, é preciso considerar o SLA e o custo das falhas, e equilibrar isso com a complexidade que será adicionada para evitá-las. Por volta de 1998, conectei dois NetApps em uma configuração de alta disponibilidade; uma unidade falhou e acabou estragando todos os discos da outra. Essa foi minha primeira lição
Na mesma época, aconteceu algo parecido com dois firewalls Cisco PIX, e desde então passei a ser sempre cauteloso com alta disponibilidade e failover/mitigação automáticos
Tenho curiosidade sobre como botões vermelhos gigantes e degradação gradual intencional de desempenho são tratados na prática. Em especial, como garantir que eles continuem funcionando enquanto o sistema está com problemas
Por exemplo, vocês usam feature flags baseadas em banco de dados? Se sim, o que fazem quando o próprio banco de dados ou a API de acesso estão sobrecarregados?
Ou usam flags estáticas de inicialização, como variáveis de ambiente? Nesse caso, como garantem que sejam implantadas rápido o suficiente? Ou existe uma abordagem completamente diferente?
Mesmo sem usar redundância em partes do caminho crítico, se o sistema for simples o bastante para caber na cabeça de todos os mantenedores e puder ser reiniciado ou revertido facilmente, isso pode ser melhor
Mas, quando a empresa começa a prometer coisas como “cinco noves de uptime”, passa a ser necessária alguma complexidade para projetar sistemas que consigam manter essa garantia enquanto o desenvolvimento e as melhorias continuam
No Google, quando se julgava que um cluster específico não estava saudável, era comum fazer “drenagem de backend”, e havia um sistema na camada de API/load balancer para lidar com isso rapidamente
Em outros lugares, também vi isso ser tratado com flags no nível da aplicação. Era algo como fazer
kubectl edit, então claramente não era o ideal, mas funcionavaPrimeiro, mantenha simples. O ideal é algo como uma verificação simples de flag, sem lógica sofisticada nem armazenamentos de dados complexos
Segundo, coloque o mais perto possível da origem, mas não confie demais nos clientes. Pode haver versões antigas, atrasos de propagação e bugs; portanto, é melhor que tanto cliente quanto servidor possam escolher o modo degradado, e, se só um lado puder fazer isso, é melhor que seja o servidor
Terceiro, teste com tráfego real com frequência. Não confie no ambiente de teste; faça testes periódicos em pequena escala, como 0,1%, e testes grandes agendados. Se você não testou, não vai funcionar quando precisar; se funcionava há um ano, há uma boa chance de não funcionar agora. Um mecanismo não testado pode causar mais dano do que solução
Por exemplo, suponha que o Hacker News tenha adicionado um novo recurso que mostra uma foto de perfil ao lado dos comentários. Como, obviamente, tudo foi feito com microserviços, vamos assumir uma arquitetura em que o gerador de páginas do frontend chama o serviço de perfil, e o serviço de perfil faz a consulta e devolve a localização da imagem
Como parte do plano de lançamento, é documentado o procedimento do botão vermelho gigante a ser seguido se o novo componente sobrecarregar o serviço de perfil ou o armazenamento de imagens. Ou seja, executar um comando na camada de rede para limitar a taxa de requisições externas do meu serviço — e, em uma emergência, provavelmente colocá-la em 0
As consultas falhariam, mas o gerador de páginas foi projetado para degradar gradualmente e continuar renderizando o texto dos comentários sem a foto de perfil
Isto não é um documento de design real nem um conselho sobre como construir algo; é apenas um desenho de giz de cera para explicar o ponto
Já vi isso ser feito com o CDB (constant database) do djb, com arquivos de configuração JSON consultados por polling via API, e também com dbm/gdbm/Berkeleydb/leveldb
Essa abordagem pode ser estendida a outros botões vermelhos gigantes. Não é elegante, mas já operei várias vezes serviços que verificavam a existência de um arquivo para decidir se deveriam oferecer health checks. Tirar um nó da rotação do load balancer era tão fácil quanto criar um arquivo
O ponto principal é que, se o banco de dados falhar, o sistema deve usar como padrão a última configuração comprovadamente saudável
Quero realmente enfatizar a frase “os mecanismos de recuperação devem ser completamente testados antes de uma emergência”. Como alguém que virou SRE no Google por acidente e ficou conhecido na empresa inteira por usar mal uma dupla negação, isso é algo muito importante que precisa ser feito direito logo de cara
Se algum Googler curioso procurar meu nome de usuário internamente, poderá encontrar como criei um impacto grande demais para ser medido
A forma mais barata de evitar incidentes é detectá-los no início do ciclo de vida. Bugs de software são parecidos com insetos de verdade. No começo são ovos, ou seja, a ideia de uma mudança; a ninfa que sai do ovo é o primeiro POC. Quando chega ao ambiente de produção, já é um adulto
Não existem estágios antes de virar adulto? Sim. Uma aplicação precisa passar por várias etapas antes de amadurecer. É muito mais barato encontrar um bug antes que ele cresça e ponha ovos
Se o deploy canário é difícil e o rollback também é problemático, é preciso colocar mais testes antes do deploy em produção. É preciso encontrar bugs cedo por tantos meios quanto possível: linters, testes unitários, testes de ponta a ponta, profilers, monitores sintéticos, réplicas somente leitura de produção, testes de performance etc.
Feature flags, compatibilidade retroativa e afins também são úteis, mas nada supera o Shift Left
Se você tiver interesse em uma lista semelhante do ponto de vista de alguém que trabalhou 15 anos como SRE em FinTech, bancos, hedge funds e criptomoedas, recomendo este texto: https://x.com/alexpotato/status/1432302823383998471?s=20
Uma amostra: “25. Se você tem um motor de regras em que é mais fácil criar uma nova regra do que encontrar uma regra existente por condições de filtro, no fim você acaba com um monte de regras duplicadas”
“Um engenheiro que submeteu uma mudança que quase causou um incidente evitou por pouco um grande incidente ao desligar o computador desktop da tomada antes que a mudança se propagasse” — afinal, o que isso quer dizer?
Como resultado, os SWEs de infraestrutura passavam o dia escrevendo CLIs idiotas em vez de criar botões de verdade. Quando saí, isso já estava mudando bastante
Acho que o Google deveria divulgar mais seus incidentes internos. Esse incidente, em especial, era muito famoso internamente
Mesmo em uma escala enorme, ferramentas de shell e CLIs de clientes RPC conseguem tocar em todas as máquinas do mundo com bastante rapidez
psshFoi há 10 anos, então não sei se ainda fazem isso assim, mas aquele método era surpreendentemente rápido. Pode ter sido algo desse tipo
Mas 20 anos atrás isso deve ter sido mais comum, e ainda hoje pode acontecer em organizações pequenas