Você já disse alguma coisa completamente normal para você, mas todo mundo está muito surpreso? Isso acontece comigo constantemente quando descrevo o que era considerado normal na empresa em que trabalhava. Por alguma razão, o rosto do interlocutor gradualmente se transforma de um sorriso agradável em uma careta de extremo espanto. Aqui estão alguns exemplos típicos.

Há uma empresa muito boa, um dos lugares mais agradáveis ​​que já trabalhei, uma combinação de todos os presentes da Valve e da Netflix. As pessoas aqui são incríveis e dão a você quase total liberdade para fazer o que quiser. Porém, como efeito colateral dessa cultura, aproximadamente 50% dos novos funcionários os deixam no primeiro ano, alguns voluntariamente e outros não. Absolutamente normal, não é?

Existe uma empresa que é incrivelmente secreta sobre sua infraestrutura. Por exemplo, tem medo de relatar erros ao fornecedor do equipamento, porque os erros serão corrigidos e os concorrentes poderão usar as correções. Isso não pode ser permitido. Solução: solicite firmware e corrija bugs você mesmo! Ok.

Mais recentemente, encontrei-me com especialistas que tentaram reproduzir o algoritmo publicado no artigo dessa empresa. Eles não puderam reproduzir o resultado. Além disso, o algoritmo do artigo levou a um nível incomumente alto de instabilidade. Quando um dos autores foi questionado sobre isso, ele respondeu: “Bem, sim, existem alguns truques que não apareceram no artigo” e se recusou a compartilhar esses truques. Ou seja, a empresa publicou intencionalmente um resultado improdutivo para não fornecer detalhes, como costumava ocorrer com bugs.

A empresa ameaça demitir instantaneamente qualquer funcionário que vazar informações. Isso é contado a cada novato com exemplos de pessoas demitidas pelo vazamento (por exemplo, um cara vazou informações de que o show acontecerá em um determinado escritório). Cada demissão é relatada em voz alta e comunicada a todos os funcionários. Como resultado dessa política, muitos têm medo de encaminhar emails, mesmo com informações inocentes, como a atualização de dados de seguros. Em vez disso, eles imprimem uma carta de outro computador - e a transmitem em papel. Ou tire fotos no telefone. Ok.

Em um escritório, certa vez perguntei por que dois funcionários específicos parecem estar se evitando. Disseram-me que a inimizade deles já dura dez anos. De fato, a situação melhorou recentemente. Por muitos anos, eles literalmente não puderam estar na mesma sala, caso contrário, um deles ficaria com muita raiva e faria algo infeliz. Mas agora os caras se acalmaram, e às vezes podem ser encontrados na mesma ala do escritório ou até na mesma sala. E estas não são apenas pessoas aleatórias. Esses são os gerentes das duas únicas equipes dessa empresa. OK!

Existe uma empresa com uma cultura tão estranha que você pode escrever um livrinho sobre isso. De fato, recentemente comecei a escrever um post sobre essa empresa e já escrevi mais de 100 mil palavras - mais do que todos os posts do meu blog juntos.

Essa empresa me explicou que é muito melhor tomar decisões não com base em dados, mas com base em relações políticas, e que a idéia de tomar decisões com base em dados é, de qualquer forma, um mito - ninguém faz isso.

Nesta empresa, recebi quatro razões para trabalhar com eles. Todos os quatro acabaram sendo uma mentira. Como resultado, minhas responsabilidades profissionais se resumiam ao fato de que, quando eu contratei, concordei em não fazer nada.

Quando entrei nesta empresa, minha equipe não tocou no sistema de controle de versão por vários meses. Eu tive que lutar para que todos usassem. Eu venci essa batalha. Mas ele não conseguiu convencer os funcionários a executar os testes primeiro. Portanto, a montagem é interrompida várias vezes ao dia.

Em uma conversa com a gerência, sugeri que considero isso um problema da produtividade de nosso departamento. Foi-me dito que isso é normal. Esta é a situação para todos os funcionários, para que todos estejam em pé de igualdade. Minha tarefa é classificá-los; portanto, se o problema afeta a todos igualmente, não há motivo para preocupação.

Outra empresa lançou muitas iniciativas em larga escala para atrair mulheres desenvolvedoras, mas as mulheres ainda estão sendo selecionadas para entrevistas com perguntas como "Você teve experiência com algoritmos ou apenas com codificação?" Eu pensei que meu candidato com uma recomendação muito boa passaria por essa barreira mas esqueceu como a empresa era normal.

Em outra empresa, trabalhei em uma equipe de quatro pessoas em um projeto com um orçamento de várias centenas de milhões de dólares e um efeito anual de um bilhão de dólares. Ao mesmo tempo, pedidos de itens no valor de centenas de dólares foram considerados por meses ou rejeitados.

Pode parecer que eu trabalhei apenas em empresas extraordinariamente ruins. Mas não, eles têm uma boa reputação e duas delas são consideradas uma das melhores empresas de emprego. E ouvi histórias semelhantes de funcionários de outras empresas, mesmo com uma excelente reputação de engenharia. A única diferença é que agora eu estava em choque e o interlocutor acreditava que estava tudo bem.

Muitas empresas usam a biblioteca Flaky , que adiciona anotações python a testes não confiáveis ​​que passam ou falham. Perguntei aos funcionários de três empresas diferentes o que o Flaky faz. Todos eles sugeriram que ela repetisse o teste e os relatórios em caso de falha. Perto, mas não exatamente. Tecnicamente, ele pode ser usado de qualquer maneira, mas, na prática, reinicia repetidamente o teste e relata a conclusão bem-sucedida. O Flaky foi desenvolvido por uma empresa que lida com a infraestrutura de armazenamento de dados, enquanto a biblioteca está usando ativamente seu maior concorrente. Marcar testes aprovados com possíveis erros é completamente normal .

Existe uma empresa conhecida por boas práticas de engenharia. Na última vez que verifiquei, ela tinha um tempo de atividade de 99,99%, o que é totalmente explicado pelas práticas de engenharia adotadas lá. Se uma startup se parece com o Twitter ou o Reddit, apenas um nove é suficiente, mas estamos falando de uma plataforma de infraestrutura que realmente precisa de duas. Muitas empresas que constroem a infraestrutura para dois noves consideram suas práticas que levam a essa confiabilidade completamente normais.

Até onde eu sei, muitas dessas empresas percorreram um longo caminho. A princípio, eles se concentraram apenas no crescimento do produto. Isso é absolutamente razoável, porque inicialmente o valor da empresa é aproximadamente zero. Ela não implementa administração de sistema competente ou segurança real, porque não tem nada a perder. Bem, com exceção dos dados do usuário, quando eles são inevitavelmente hackeados, e se você conversar com agentes de segurança em grandes empresas privadas (elas são chamadas de “unicórnios”, unicórnio), isso acontece o tempo todo.

O resultado é uma cultura excessivamente focada no crescimento sem risco. Essa cultura geralmente é preservada mesmo quando a empresa cresceu para um bilhão de dólares e já tem algo a perder. Se uma pessoa trabalhava para o Google, Amazon ou outra empresa com procedimentos sólidos, a situação o chocaria. Muitas vezes ele tenta consertar alguma coisa, mas não pode fazer nada e renuncia.

Provavelmente, o Google hoje possui as melhores práticas operacionais e métodos de segurança entre todas as empresas de TI do mundo. É fácil dizer que devemos dar um exemplo disso. Mas é instrutivo ver como eles conseguiram isso. E o que aconteceu antes. Se você olhar a base de código, verá muitos serviços cujos nomes terminam em z, além de um número surpreendentemente grande de variáveis. Um dos antigos funcionários disse que uma vez alguém queria adicionar monitoramento. Não era muito seguro definir google.com/somename para monitorar, então eles adicionaram z, que é google.com/somenamez , por segurança. Isso está na empresa, que agora é considerada a melhor do mundo em segurança.

Agora, ela se mudou tanto para a segurança que os novos funcionários negam veementemente essas práticas no passado. Ao mesmo tempo, são chamados motivos que realmente não fazem sentido (por exemplo, para evitar colisões de nomes).

O tremendo progresso do Google em segurança - de adicionar a letra z às melhores práticas de IB do mundo - não aconteceu porque alguém fez uma palestra animada ou escreveu um ensaio convincente. Tudo começou depois de vários "fakap". Somente então os guardas de segurança receberam autoridade para resolver problemas fundamentais. Para empresas boas e certas, as reformas quase sempre começam dessa maneira. A Microsoft foi ridicularizada por muitos anos, mas várias explorações catastróficas os forçaram a mudar de atitude em relação à segurança. Parece simples. Mas testemunhas oculares dizem que a mudança foi cruel. Apesar de ter sido indicada de cima, a inércia permaneceu muito forte. Por que mudar o que funcionou? Portanto, havia muita pressão das pessoas que estavam acostumadas a fazer tudo da maneira antiga.

Tais coisas podem ser vistas em qualquer setor. Um exemplo clássico frequentemente citado por técnicos é a lavagem das mãos por médicos e enfermeiros. É bem sabido que existem micróbios, e lavar as mãos com sabão reduz muito a probabilidade de transmissão microbiana e, portanto, reduz significativamente a taxa de mortalidade nos hospitais. Apesar disso, mesmo médicos e enfermeiros experientes ainda não o fazem. Intervenção necessária. Sinais remanescentes de lavar as mãos salvam vidas. E melhor ainda, que as pessoas vivas se levantaram e exigiram lavar as mãos: assim, mais vidas são salvas. As pessoas podem ignorar os sinais, mas não podem passar pela pessoa responsável.

Algo assim, as empresas de TI estão tentando implementar as melhores práticas. Se você diz aos funcionários o que fazer, isso ajuda um pouco. Se você implementar a verificação de código, o efeito será imediatamente aparente.

As estatísticas mostram claramente que as pessoas dominam muito mal hábitos de rotina que não produzem um efeito visível, mas reduzem irreversivelmente o risco de eventos raros, mas catastróficos. Parece a uma pessoa que abrir um caminho é o caminho certo e razoável. Existe um termo especial para isso: "normalização do desvio". Ele foi bem estudado em vários outros contextos, incluindo saúde, aviação, engenharia, engenharia aeroespacial e engenharia civil, mas ainda não foi discutido no contexto de software.

É possível aprender com os erros dos outros, e não com os seus? O estado da indústria não dá motivos para contar com isso, mas vamos tentar. John Banya escreveu um breve relatório sobre a normalização do desvio de assistência médica , cujas descobertas podem ser aplicadas ao desenvolvimento de software. Pode-se notar que o tratamento dos pacientes pode ser comparado com as ações dos devops. No entanto, a normalização do desvio também ocorre em um contexto cultural em que a analogia não é tão óbvia.

A primeira seção do artigo descreve detalhadamente várias situações catastróficas, tanto na área da saúde quanto em outras áreas. Aqui está um exemplo típico:

O caso de negligência catastrófica, que o autor observou como testemunha especialista, foi relacionado ao anestesiologista que desligava o aparelho de ventilação pulmonar artificial a pedido de um cirurgião que desejava fazer um raio-x da cavidade abdominal do paciente (Banya, 2005, pp. 87-101). O ventilador deveria desligar por apenas alguns segundos, mas o anestesiologista esqueceu de ligá-lo novamente ou pensou que ele estava ligado, mas não o ligou. A paciente ficou livre de oxigênio por tempo suficiente para começar a anoxia completa, o que a levou ao estado vegetativo. Ela nunca se recuperou. Após 9 dias, ela foi desconectada da ventilação mecânica e após 2 dias morreu. Mais tarde, foi descoberto que os alarmes de anestesia e o equipamento de monitoramento na sala de operações foram intencionalmente programados para “suspender indefinidamente”, de forma que o anestesiologista não recebesse um aviso sobre um problema com o ventilador. O alarme em si estava no lugar, mas foi desligado, talvez porque a equipe operacional tenha encontrado o dispositivo chiando irritantemente.

Desative ou ignore as notificações, porque há muitas e são muito irritantes? Agindo manualmente com o risco de cometer um erro? Sim, posso citar algumas empresas de uma só vez, onde a discussão após um desastre começa exatamente a partir desses pontos, a menos que no final ninguém morra, e apenas alguns milhões de dólares sejam perdidos. Se você ler muitas análises desses incidentes em TI , cada exemplo no artigo de Bunny lhe parecerá familiar, mesmo que os detalhes sejam diferentes.

A seção termina com esta conclusão :

Como regra, esses desastres são explicados por “uma longa violação das regras, eventos contraditórios que se acumularam sem serem detectados e uma idéia cultural incorreta dos perigos. Juntos, esses fatores impediram uma intervenção que poderia ter evitado os efeitos nocivos. ” É especialmente impressionante como inúmeras violações das regras e erros são combinadas para criar a oportunidade de um desastre.

Novamente, o texto parece ser de um artigo sobre falhas técnicas. Portanto, a próxima seção sobre as causas dessas falhas merece atenção. E as razões são as seguintes.

Regras tolas e ineficazes

O artigo fornece um exemplo da administração de medicamentos a recém-nascidos. Para evitar o "vazamento de drogas", a enfermeira deve digitar uma senha no computador. Ela obtém acesso à caixa de remédios e toma a quantidade certa de remédio. Para garantir que a primeira enfermeira não tenha roubado nada, a segunda enfermeira deve monitorar o processo. Em seguida, ela deve digitar sua senha no computador como confirmação de que seguiu o procedimento correto para manusear o medicamento.

Parece familiar. Muitos relatórios de incidentes começam com o fato de que "alguém pulou algumas etapas porque é ineficaz". Por exemplo, "um programador lançou uma configuração ou código incorreto porque tinha certeza disso e não queria gastar tempo preparando ou testando". O notório desligamento do Azure em novembro de 2014 ocorreu exatamente por esse motivo.

Na mesma época, um dos concorrentes do Azure, os desenvolvedores cancelaram uma regra que proíbe o envio de uma configuração que falha nos testes na filial do Canary. Os desenvolvedores tinham certeza de que a configuração estava em ordem. Quando o Canary começou a falhar, eles cancelaram a regra que proíbe a implantação do Canary para o Staging com um erro. Eles tinham certeza de que a configuração estava em ordem e que a falha foi causada por outra coisa. A análise subsequente mostrou que a configuração estava tecnicamente correta, mas com isso um bug se manifestou no software principal. É pura sorte que o bug oculto revelado pela configuração não tenha sido tão sério quanto o bug do Azure.

As pessoas têm um entendimento fraco de como os erros se sobrepõem. Portanto, aceitamos as regras para uma implantação segura. Mas pela mesma razão que as pessoas têm um entendimento fraco de como os erros se sobrepõem, essas regras parecem tolas e ineficazes!

O conhecimento é imperfeito e desigual

O conceito de norma não é inato. Quando novas pessoas chegam à empresa, elas absorvem facilmente os processos desviantes que se tornaram a norma.

Julia Evans me descreveu como isso acontece:

recém-chegado vem
Novato : WTF WTF WTF WTF WTF
Veterano : Sim, nós sabemos, estamos fazendo isso.
novato : WTF WTF wTF wtf wtf w ...
novato se acostuma
segundo iniciante vem
estreante n ° 2 : WTF WTF WTF WTF
iniciante : sim, nós sabemos, estamos fazendo isso.

A coisa mais insidiosa é que as pessoas realmente aceitam a idéia da WTF, e então elas podem se espalhar em outros lugares ao longo de sua carreira. Uma vez eu trabalhei com um projeto de código aberto que falhou regularmente. Disseram-me que isso é normal e que o produto deles é melhor que a média. Eu verifiquei e descobri que ele era o pior da classe em quase todos os aspectos. E ele esboçou a idéia de como liberar builds com relativamente pouco esforço, o que quase sempre passa nos testes. A resposta mais comum foi: “Uau, esse cara deve estar trabalhando com programadores de grandes estrelas. Mas seremos realistas. A assembléia de todos é interrompida pelo menos várias vezes por semana ". Como se executar testes (ou, até mesmo, tentar compilar) antes de verificar o código requer esforços sobre-humanos. Mas assim que as pessoas acreditam que algum tipo de desvio é normal, elas geralmente absorvem a ideia.

Eu quebro a regra para o bem do paciente

O artigo fornece um exemplo de médico que viola a regra de usar luvas ao procurar uma veia. Ele acredita que usar luvas dificulta a localização de uma veia; portanto, ele precisará cutucar uma criança com uma agulha várias vezes. É difícil argumentar com isso. Ninguém quer machucar uma criança!

O segundo maior fracasso de tudo que vi na minha vida aconteceu por esse motivo. Alguém notou uma lentidão no banco de dados. Eles escreveram rapidamente um patch e, para impedir que a degradação se espalhasse ainda mais, ignoraram a regra de uma implantação lenta e em fases. Em vez disso, eles rolaram o patch em todas as máquinas. É difícil argumentar com isso. Ninguém quer que os clientes experimentem degradação do serviço! Infelizmente, o patch detectou um erro que causou um desligamento global do serviço.

As regras não se aplicam a mim / Você pode confiar em mim

, . , , , .

, . , : « ? , X, Y Z?»

, Facebook . Facebook. , - , . , , . «» «», .

, , . . , - , . , .

, . , , , . , : . , , - . , . .

, . — , .

, . , - . , , . . , , .

, : , . , . ?

— , . , . , : , .

Mas se os incentivos forem direcionados contra você, serão necessários esforços constantes e irregulares para levar as pessoas a fazerem a coisa certa. Nesse caso, o problema é convencer alguém a alterar os incentivos e garantir que as alterações funcionem conforme o esperado. Como convencer a gerência a mudar os incentivos é o tópico de um artigo separado. Em relação à implementação das mudanças, vi muitos erros "óbvios" que são repetidos em diferentes empresas.

. , : (IC) -> (TL) -> (CEO). . , - , . , , , . - , . , , . , . .

. , . , , , , . , . .

, , . , . , . . , . . , .

É um pouco engraçado que, no final, tudo se reduz ao problema dos incentivos. Na indústria, pensamos muito em como incentivar os consumidores a fazer o que queremos. Mas dentro da empresa, criamos um sistema de incentivos que nos leva às coisas erradas. Uma espécie de mistura de telefone mimado e o culto à carga. Antigamente, a Microsoft era um modelo - copiamos seus métodos e perguntamos quebra-cabeças de entrevistas. Agora o Google se tornou um modelo - e fazemos perguntas sobre algoritmos . , Google, Google, . , Google , . , Google . , -. , Google .

. Stripe Mongo , Mongo ¹ . - ² .

, .

• .
  
• .
  
• .
  
• , .
  
• , .

, , “WTF WTF WTF”.

-, . . , - , . , , . , . , , , .

"Preste atenção a sinais fracos" parece bom, mas como fazer isso? Sinais fortes são poucos e raros, por isso é fácil prestar atenção. Existem muitos sinais fracos. Como filtrar o ruído? E como fazer com que toda a equipe ou organização faça isso? Não existe uma resposta simples para essas perguntas, é necessário prestar muita atenção a isso.

, . . , , . , . , . , , . , , . .

Em seguida, a empresa aceita novos funcionários e todos os terços não têm uma conta no sistema, nem um local no escritório ou um computador - e essa condição pode persistir por semanas ou meses. Os slides da análise competitiva dizem que você tem apenas uma chance de causar uma primeira impressão e, em seguida, os funcionários têm a impressão de que a empresa não é capaz de cuidar deles. E que interromper constantemente os processos de trabalho é normal.

A empresa não consegue nem entender o básico da integração, sem mencionar coisas realmente complexas como aculturação. As razões são claras. Indicadores externos, como crescimento ou diminuição da audiência, são mensuráveis, diferentemente da aculturação dos recém-chegados, para que eles não ignorem os sinais fracos. Mas isso não significa que o último seja menos importante. Eles dizem muito sobre como novas linguagens ou métodos, como TDD ou Agile, aumentam a produtividade, mas ter uma forte cultura de engenharia é um animador muito mais poderoso.

---

1. , , . mongodb message queue . « MongoDB ». , , , . . , . . , . , , Mongo, , , , . []

, . « 30 », « 10 , , » « , , », « , ». , , , , . . , , . , , .

2. , , . , , . , , , , , . . , - , , , , . , . . , . , - — . : - , . , . , , - , . []