Automatizando a substituição de disco com Ansible

Olá a todos. Trabalho como administrador de sistema líder na OK e sou responsável pela operação estável do portal. Quero falar sobre como construímos um processo para substituição automática de discos e, em seguida, como excluímos o administrador desse processo e o substituímos por um bot.

Este artigo é uma espécie de transliteração performances no HighLoad+ 2018

Construindo um processo de substituição de disco

Primeiro alguns números

OK é um serviço gigante usado por milhões de pessoas. É atendido por cerca de 7 mil servidores, que estão localizados em 4 data centers diferentes. Os servidores contêm mais de 70 mil discos. Se você empilhá-los uns sobre os outros, obterá uma torre com mais de 1 km de altura.

Os discos rígidos são o componente do servidor que falha com mais frequência. Com tais volumes, temos que trocar cerca de 30 discos por semana, e esse procedimento se tornou uma rotina não muito agradável.

Incidentes

Nossa empresa introduziu um gerenciamento completo de incidentes. Registramos cada incidente no Jira e depois resolvemos e resolvemos. Se um incidente afetou os usuários, então definitivamente nos reunimos e pensamos em como responder mais rapidamente nesses casos, como reduzir o efeito e, claro, como prevenir uma recorrência.

Os dispositivos de armazenamento não são exceção. Seu status é monitorado pelo Zabbix. Monitoramos mensagens no Syslog em busca de erros de gravação/leitura, analisamos o status de ataques de HW/SW, monitoramos SMART e calculamos o desgaste de SSDs.

Como os discos foram alterados antes

Quando ocorre um gatilho no Zabbix, um incidente é criado no Jira e atribuído automaticamente aos engenheiros apropriados nos data centers. Fazemos isso com todos os incidentes de HW, ou seja, aqueles que exigem algum trabalho físico com equipamentos do data center.
Um engenheiro de data center é uma pessoa que resolve problemas relacionados ao hardware e é responsável pela instalação, manutenção e desmontagem de servidores. Recebido o tíquete, o engenheiro começa a trabalhar. Nas prateleiras de discos ele troca os discos de forma independente. Mas se ele não tiver acesso ao dispositivo necessário, o engenheiro recorre aos administradores do sistema de plantão em busca de ajuda. Primeiro de tudo, você precisa remover o disco da rotação. Para fazer isso, você precisa fazer as alterações necessárias no servidor, interromper os aplicativos e desmontar o disco.

O administrador do sistema de plantão é responsável pelo funcionamento de todo o portal durante o turno de trabalho. Ele investiga incidentes, faz reparos e ajuda os desenvolvedores a concluir pequenas tarefas. Ele não lida apenas com discos rígidos.

Anteriormente, os engenheiros do data center se comunicavam com o administrador do sistema via chat. Os engenheiros enviaram links para tickets do Jira, o administrador os seguiu, manteve um registro do trabalho em algum bloco de notas. Mas os chats são inconvenientes para essas tarefas: as informações ali não são estruturadas e se perdem rapidamente. E o administrador poderia simplesmente se afastar do computador e não responder às solicitações por algum tempo, enquanto o engenheiro ficava no servidor com uma pilha de discos e esperava.

Mas o pior é que os administradores não viram o quadro completo: quais incidentes de disco existiam, onde um problema poderia surgir. Isto se deve ao fato de delegarmos todos os incidentes de HW aos engenheiros. Sim, foi possível visualizar todos os incidentes no painel do administrador. Mas há muitos deles, e o administrador esteve envolvido apenas em alguns deles.

Além disso, o engenheiro não conseguiu definir as prioridades corretamente, pois nada sabe sobre a finalidade de servidores específicos ou a distribuição das informações entre os drives.

Novo procedimento de substituição

A primeira coisa que fizemos foi mover todos os incidentes de disco para um tipo separado “disco HW” e adicionar os campos “nome do dispositivo de bloco”, “tamanho” e “tipo de disco” para que essas informações fossem armazenadas no ticket e fossem não precisa trocar constantemente no chat.

Também concordamos que durante um incidente trocaríamos apenas um disco. Isso simplificou significativamente o processo de automação, coleta de estatísticas e trabalho futuro.

Além disso, adicionamos o campo “administrador responsável”. O administrador do sistema de plantão é automaticamente inserido ali. Isso é muito conveniente, porque agora o engenheiro sempre vê quem é o responsável. Não há necessidade de ir ao calendário e pesquisar. Foi este campo que possibilitou a exibição no painel do administrador de tickets que pudessem necessitar de sua ajuda.

Para garantir que todos os participantes obtivessem o máximo benefício das inovações, criamos filtros e painéis e contamos à galera sobre eles. Quando as pessoas entendem as mudanças, não se distanciam delas como algo desnecessário. É importante que o engenheiro saiba o número do rack onde está localizado o servidor, o tamanho e o tipo do disco. O administrador precisa, antes de tudo, entender que tipo de grupo de servidores é esse e qual pode ser o efeito ao substituir um disco.

A presença de campos e sua exibição é conveniente, mas não nos livrou da necessidade de utilizar chats. Para fazer isso, tivemos que alterar o fluxo de trabalho.

Anteriormente era assim:

É assim que os engenheiros continuam a trabalhar hoje, quando não precisam da ajuda do administrador.

A primeira coisa que fizemos foi introduzir um novo status Investigar. O ticket fica neste status quando o engenheiro ainda não decidiu se precisará ou não de administrador. Através deste status, o engenheiro pode transferir o ticket para o administrador. Além disso, usamos esse status para marcar tickets quando um disco precisa ser substituído, mas o disco em si não está no local. Isso acontece no caso de CDNs e sites remotos.

Também adicionamos status Pronto. O ticket é transferido para ele após a substituição do disco. Ou seja, tudo já foi feito, mas o RAID HW/SW está sincronizado no servidor. Isso pode levar muito tempo.

Se um administrador estiver envolvido no trabalho, o esquema fica um pouco mais complicado.

Do status Abra O ticket pode ser traduzido tanto pelo administrador do sistema quanto pelo engenheiro. Em estado Em andamento o administrador remove o disco da rotação para que o engenheiro possa simplesmente retirá-lo: liga a luz de fundo, desmonta o disco, interrompe aplicativos, dependendo do grupo específico de servidores.

O bilhete é então transferido para Pronto para mudar: Este é um sinal para o engenheiro de que o disco pode ser retirado. Todos os campos do Jira já estão preenchidos, o engenheiro sabe qual tipo e tamanho do disco. Esses dados são inseridos automaticamente no status anterior ou pelo administrador.

Depois de substituir o disco, o status do ticket é alterado para Alterado. Ele verifica se o disco correto foi inserido, o particionamento foi feito, o aplicativo foi iniciado e algumas tarefas de recuperação de dados foram iniciadas. O ticket também pode ser transferido para o status Pronto, neste caso o administrador permanecerá responsável, pois colocou o disco em rotação. O diagrama completo é assim.

Adicionar novos campos tornou nossa vida muito mais fácil. A galera começou a trabalhar com informações estruturadas, ficou claro o que precisava ser feito e em que estágio. As prioridades tornaram-se muito mais relevantes, pois passaram a ser definidas pelo administrador.

Não há necessidade de bate-papos. Claro, o administrador pode escrever para o engenheiro “isso precisa ser substituído mais rápido” ou “já é noite, você terá tempo para substituí-lo?” Mas não nos comunicamos mais diariamente em chats sobre essas questões.

Os discos começaram a ser trocados em lotes. Se o administrador chegou um pouco mais cedo, tem tempo livre e nada aconteceu ainda, ele pode preparar uma série de servidores para substituição: preencher os campos, retirar os discos da rotação e transferir a tarefa para um engenheiro. O engenheiro chega ao data center um pouco mais tarde, vê a tarefa, retira os drives necessários do warehouse e os substitui imediatamente. Como resultado, a taxa de substituição aumentou.

Lições aprendidas ao construir o fluxo de trabalho

• Ao construir um procedimento, é necessário coletar informações de diferentes fontes.
  Alguns de nossos administradores não sabiam que o próprio engenheiro troca os discos. Algumas pessoas pensavam que a sincronização MD RAID era feita por engenheiros, embora alguns deles nem tivessem acesso para fazê-lo. Alguns engenheiros importantes fizeram isso, mas nem sempre porque o processo não foi descrito em lugar nenhum.
• O procedimento deve ser simples e compreensível.
  É difícil para uma pessoa manter muitos passos em mente. Os status vizinhos mais importantes em Jira devem ser colocados na tela principal. Você pode renomeá-los, por exemplo, chamamos Em andamento Pronto para mudar. E outros status podem ser ocultados em um menu suspenso para que não sejam desagradáveis. Mas é melhor não limitar as pessoas, dar-lhes a oportunidade de fazer a transição.
  Explique o valor da inovação. Quando as pessoas entendem, elas aceitam melhor o novo procedimento. Foi muito importante para nós que as pessoas não clicassem em todo o processo, mas o acompanhassem. Então construímos automação sobre isso.
• Espere, analise, descubra.
  Levamos cerca de um mês para construir o procedimento, implementação técnica, reuniões e discussões. E a implementação leva mais de três meses. Vi como as pessoas estão lentamente começando a usar a inovação. Houve muita negatividade nos estágios iniciais. Mas era completamente independente do próprio procedimento e da sua implementação técnica. Por exemplo, um administrador não usava o Jira, mas sim o plugin Jira no Confluence, e algumas coisas não estavam disponíveis para ele. Mostramos a ele o Jira e a produtividade do administrador aumentou tanto nas tarefas gerais quanto na substituição de discos.

Automação de substituição de disco

Abordamos a automação da substituição de disco várias vezes. Já tínhamos desenvolvimentos e scripts, mas todos funcionavam de forma interativa ou manual e exigiam lançamento. E só depois de introduzir o novo procedimento é que percebemos que era exactamente isso que nos faltava.

Como agora nosso processo de substituição está dividido em etapas, cada uma com um executor específico e uma lista de ações, podemos habilitar a automação em etapas, e não todas de uma vez. Por exemplo, o estágio mais simples - Pronto (verificar a sincronização de dados/RAID) pode ser facilmente delegado a um bot. Quando o bot tiver aprendido um pouco, você poderá atribuir a ele uma tarefa mais importante - colocar o disco em rotação, etc.

Configurações do zoológico

Antes de falarmos sobre o bot, vamos fazer uma pequena excursão pelo nosso zoológico de instalações. Em primeiro lugar, devido ao tamanho gigantesco da nossa infra-estrutura. Em segundo lugar, tentamos selecionar a configuração de hardware ideal para cada serviço. Temos cerca de 20 modelos de RAID de hardware, principalmente LSI e Adaptec, mas também existem HP e DELL de diferentes versões. Cada controlador RAID possui seu próprio utilitário de gerenciamento. O conjunto de comandos e sua emissão podem diferir de versão para versão de cada controlador RAID. Onde o HW-RAID não é usado, o mdraid pode ser usado.

Fazemos quase todas as novas instalações sem backup de disco. Tentamos não usar mais RAID de hardware e software, pois fazemos backup de nossos sistemas no nível do data center, não nos servidores. Mas é claro que existem muitos servidores legados que precisam de suporte.

Em algum lugar os discos nos controladores RAID são transferidos para dispositivos brutos, em algum lugar os JBODs são usados. Existem configurações com um disco de sistema no servidor, e caso precise ser substituído é necessário reinstalar o servidor com a instalação do SO e aplicativos, das mesmas versões, depois adicionar arquivos de configuração, iniciar aplicativos. Existem também muitos grupos de servidores onde o backup não é realizado no nível do subsistema de disco, mas diretamente nos próprios aplicativos.

No total, temos mais de 400 grupos de servidores exclusivos executando quase 100 aplicativos diferentes. Para abranger um número tão grande de opções, precisávamos de uma ferramenta de automação multifuncional. De preferência com uma DSL simples, para que não só quem a escreveu possa suportá-la.

Escolhemos o Ansible porque ele não tem agente: não houve necessidade de preparação de infraestrutura, um início rápido. Além disso, é escrito em Python, que é aceito como padrão pela equipe.

Esquema geral

Vejamos o esquema geral de automação usando um incidente como exemplo. O Zabbix detecta que o disco sdb falhou, o gatilho acende e um ticket é criado no Jira. O administrador olhou, percebeu que não era uma duplicata e nem um falso positivo, ou seja, o disco precisava ser trocado, e transferiu o ticket para Em andamento.

O aplicativo DiskoBot, escrito em Python, pesquisa periodicamente o Jira em busca de novos tickets. Ele percebe que apareceu um novo ticket Em andamento, o thread correspondente é acionado, o que inicia o playbook no Ansible (isso é feito para cada status no Jira). Neste caso, o Prepare2change é lançado.

O Ansible é enviado ao host, remove o disco da rotação e reporta o status ao aplicativo por meio de retornos de chamada.

Com base nos resultados, o bot transfere automaticamente o ticket para Pronto para alterar. O engenheiro recebe uma notificação e vai trocar o disco, após o que transfere o ticket para Alterado.

Seguindo o esquema descrito acima, o ticket volta para o bot, que lança outro playbook, vai até o host e coloca o disco em rotação. O bot fecha o ticket. Viva!

Agora vamos falar sobre alguns componentes do sistema.

Discobot

Este aplicativo foi escrito em Python. Ele seleciona tickets do Jira de acordo com JQL. Dependendo do status do ticket, este vai para o manipulador correspondente, que por sua vez lança o playbook Ansible correspondente ao status.

JQL e intervalos de pesquisa são definidos no arquivo de configuração do aplicativo.

jira_states:
  investigate:
    jql: '… status = Open and "Disk Size" is EMPTY'
    interval: 180

  inprogress:
    jql: '…  and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
 
  ready:
    jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
    interval: 7200

Por exemplo, entre tickets com status Em andamento, somente aqueles com os campos Tamanho do disco e Nome do dispositivo preenchidos são selecionados. Nome do dispositivo é o nome do dispositivo de bloco necessário para executar o playbook. O tamanho do disco é necessário para que o engenheiro saiba qual tamanho de disco é necessário.

E entre os tickets com status Pronto, os tickets com o rótulo dbot_ignore são filtrados. A propósito, usamos rótulos Jira tanto para essa filtragem quanto para marcar tickets duplicados e coletar estatísticas.

Se um playbook falhar, Jira atribuirá o rótulo dbot_failed para que possa ser resolvido posteriormente.

Interoperabilidade com Ansible

O aplicativo se comunica com o Ansible via API Python Ansible. Para playbook_executor passamos o nome do arquivo e um conjunto de variáveis. Isso permite manter o projeto Ansible na forma de arquivos yml regulares, em vez de descrevê-lo em código Python.

Também no Ansible, via *extra_vars*, o nome do dispositivo de bloco, o status do ticket, bem como o callback_url, que contém a chave do problema - é usado para retorno de chamada em HTTP.

Para cada lançamento é gerado um inventário temporário, composto por um host e o grupo ao qual esse host pertence, para que sejam aplicados group_vars.

Aqui está um exemplo de tarefa que implementa retorno de chamada HTTP.

Obtemos o resultado da execução de playbooks usando callaback(s). Eles são de dois tipos:

• Plug-in de retorno de chamada Ansible, ele fornece dados sobre os resultados da execução do playbook. Descreve as tarefas que foram iniciadas, concluídas com ou sem sucesso. Esse retorno de chamada é chamado quando o playbook termina de ser reproduzido.
• Retorno de chamada HTTP para receber informações durante a reprodução de um playbook. Na tarefa Ansible, executamos uma solicitação POST/GET para nossa aplicação.

As variáveis ​​são passadas por meio de retornos de chamada HTTP que foram definidos durante a execução do playbook e que queremos salvar e usar em execuções subsequentes. Escrevemos esses dados em sqlite.

Também deixamos comentários e alteramos o status do ticket via retorno de chamada HTTP.

Retorno de chamada HTTP

# Make callback to Diskobot App
# Variables:
#    callback_post_body: # A dict with follow keys. All keys are optional
#       msg: If exist it would be posted to Jira as comment
#       data: If exist it would be saved in Incident.variables
#       desire_state: Set desire_state for incident
#       status: If exist Proceed issue to that status

  - name: Callback to Diskobot app (jira comment/status)
    uri:
      url: "{{ callback_url }}/{{ devname }}"
      user: "{{ diskobot_user }}"
      password: "{{ diskobot_pass }}"
      force_basic_auth: True
      method: POST
      body: "{{ callback_post_body | to_json }}"
      body_format: json
    delegate_to: 127.0.0.1

Como muitas tarefas do mesmo tipo, nós a colocamos em um arquivo comum separado e a incluímos se necessário, para não repeti-la constantemente nos manuais. Isso inclui o callback_url, que contém a chave do problema e o nome do host. Quando o Ansible executa esta solicitação POST, o bot entende que ela ocorreu como parte de tal ou tal incidente.

E aqui está um exemplo do manual, no qual produzimos um disco de um dispositivo MD:

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

Esta tarefa transfere o ticket do Jira para o status “Pronto para alterar” e adiciona um comentário. Além disso, a variável mdam_data armazena uma lista de dispositivos md dos quais o disco foi removido e parted_info armazena um dump de partição do parted.

Quando o engenheiro insere um novo disco, podemos usar essas variáveis ​​para restaurar o dump da partição, bem como inserir o disco nos dispositivos MD dos quais ele foi removido.

Modo de verificação Ansible

Foi assustador ligar a automação. Portanto, decidimos executar todos os playbooks no modo
funcionamento a seco, em que o Ansible não realiza nenhuma ação nos servidores, apenas os emula.

Esse lançamento é executado por meio de um módulo de retorno de chamada separado, e o resultado da execução do playbook é salvo no Jira como um comentário.

Em primeiro lugar, isto permitiu validar o trabalho do bot e dos playbooks. Em segundo lugar, aumentou a confiança dos administradores no bot.

Quando passamos na validação e percebemos que você pode executar o Ansible não apenas no modo de simulação, criamos um botão Executar Diskobot no Jira para iniciar o mesmo playbook com as mesmas variáveis ​​no mesmo host, mas no modo normal.

Além disso, o botão é usado para reiniciar o playbook caso ele trave.

Estrutura dos manuais

Já mencionei que dependendo do status do ticket do Jira, o bot lança diferentes playbooks.

Em primeiro lugar, é muito mais fácil organizar a entrada.
Em segundo lugar, em alguns casos é simplesmente necessário.

Por exemplo, ao substituir um disco do sistema, primeiro você precisa ir ao sistema de implantação, criar uma tarefa e, após a implantação correta, o servidor ficará acessível via ssh e você poderá implementar o aplicativo nele. Se fizéssemos tudo isso em um manual, o Ansible não seria capaz de concluí-lo devido à indisponibilidade do host.

Usamos funções Ansible para cada grupo de servidores. Aqui você pode ver como o(s) playbook(s) estão organizados em um deles.

Isso é conveniente porque fica imediatamente claro onde as tarefas estão localizadas. Em main.yml, que é a entrada para a função Ansible, podemos simplesmente incluir por status do ticket ou tarefas gerais exigidas para todos, por exemplo, passar identificação ou receber um token.

investigação.yml

Execuções para tickets no status Investigação e Aberto. A coisa mais importante neste manual é o nome do dispositivo de bloco. Esta informação nem sempre está disponível.

Para obtê-lo, analisamos o resumo do Jira, último valor da trigger do Zabbix. Pode conter o nome do dispositivo de bloco - sorte. Ou pode conter um ponto de montagem, então você precisa ir ao servidor, analisá-lo e calcular o disco necessário. O gatilho também pode transmitir um endereço scsi ou alguma outra informação. Mas também acontece que não há pistas e é preciso analisar.

Tendo descoberto o nome do dispositivo de bloco, coletamos dele informações sobre o tipo e tamanho do disco para preencher os campos no Jira. Também removemos informações sobre fornecedor, modelo, firmware, ID, SMART e inserimos tudo isso em um comentário no ticket do Jira. O administrador e o engenheiro não precisam mais procurar esses dados. 🙂

prepare2change.yml

Removendo o disco da rotação, preparando-o para substituição. A etapa mais difícil e importante. É aqui que você pode interromper o aplicativo quando ele não deveria ser interrompido. Ou retire um disco que não tinha réplicas suficientes e, assim, afete os usuários, perdendo alguns dados. Aqui temos o maior número de verificações e notificações no chat.

No caso mais simples, estamos falando sobre a remoção de um disco de um HW/MD RAID.

Em situações mais complexas (em nossos sistemas de armazenamento), quando o backup é realizado em nível de aplicação, é necessário acessar a aplicação via API, reportar a saída do disco, desativá-lo e iniciar a recuperação.

Estamos agora migrando em massa para nuvem, e se o servidor for baseado em nuvem, o Diskobot chama a API da nuvem, diz que funcionará com esse minion - o servidor que executa contêineres - e pede “migrar todos os contêineres deste minion”. E ao mesmo tempo acende a luz de fundo do disco para que o engenheiro veja imediatamente qual deles precisa ser retirado.

alterado.yml

Após substituir um disco, primeiro verificamos sua disponibilidade.

Os engenheiros nem sempre instalam novas unidades, por isso adicionamos uma verificação dos valores SMART que nos satisfazem.

Que atributos estamos observando?Contagem de setores realocados (5) <100
Contagem atual de setores pendentes (107) == 0

Se o inversor falhar no teste, o engenheiro será notificado para substituí-lo novamente. Se tudo estiver em ordem, a retroiluminação apaga-se, as marcações são aplicadas e o disco é colocado em rotação.

pronto.yml

O caso mais simples: verificar a sincronização de raid HW/SW ou finalizar a sincronização de dados na aplicação.

API do aplicativo

Já mencionei diversas vezes que o bot acessa frequentemente APIs de aplicativos. É claro que nem todos os aplicativos tinham os métodos necessários, então tiveram que ser modificados. Aqui estão os métodos mais importantes que usamos:

• Status. Status de um cluster ou disco para entender se ele pode ser trabalhado;
• Iniciar/parar. Ativação/desativação de disco;
• Migrar/restaurar. Migração e recuperação de dados durante e após a substituição.

Lições aprendidas com Ansible

Eu realmente amo Ansible. Mas muitas vezes, quando olho para diferentes projetos de código aberto e vejo como as pessoas escrevem manuais, fico um pouco assustado. Entrelaçamentos lógicos complexos de quando/loop, falta de flexibilidade e idempotência devido ao uso frequente de shell/comando.

Decidimos simplificar tudo ao máximo, aproveitando a vantagem do Ansible - modularidade. No nível mais alto existem manuais; eles podem ser escritos por qualquer administrador, desenvolvedor terceirizado que conheça um pouco de Ansible.

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

Se alguma lógica for difícil de implementar em playbooks, nós a movemos para um módulo ou filtro Ansible. Os scripts podem ser escritos em Python ou qualquer outra linguagem.

Eles são fáceis e rápidos de escrever. Por exemplo, o módulo de luz de fundo do disco, cujo exemplo é mostrado acima, consiste em 265 linhas.

No nível mais baixo está a biblioteca. Para este projeto, escrevemos uma aplicação separada, uma espécie de abstração sobre RAIDs de hardware e software que executam as solicitações correspondentes.

Os maiores pontos fortes do Ansible são a simplicidade e os manuais claros. Eu acredito que você precisa usar isso e não gerar arquivos yaml assustadores e um grande número de condições, código shell e loops.

Se você quiser repetir nossa experiência com a API Ansible, tenha duas coisas em mente:

• Playbook_executor e playbooks em geral não podem ter tempo limite. Há um tempo limite na sessão ssh, mas não há tempo limite no manual. Se tentarmos desmontar um disco que não existe mais no sistema, o playbook será executado indefinidamente, então tivemos que embrulhar seu lançamento em um wrapper separado e encerrá-lo com um tempo limite.
• O Ansible é executado em processos bifurcados, portanto, sua API não é segura para threads. Executamos todos os nossos manuais em thread único.

Como resultado, conseguimos automatizar a substituição de cerca de 80% dos discos. No geral, a taxa de substituição duplicou. Hoje, o administrador apenas analisa o incidente e decide se o disco precisa ser trocado ou não, e então dá um clique.

Mas agora estamos começando a enfrentar outro problema: alguns novos administradores não sabem como trocar de unidade. 🙂

Fonte: habr.com