Máquina de pedidos, como parte de nossa BMaaS abordagem (que Bare Metal como um Serviço).

Quem somos nós?

Antes de mergulhar a nova ferramenta construímos, deixe-me apresentar a nossa equipe.

Somos uma equipe de 4 DevOps engenheiros baseados em Israel, o gerenciamento de um ambiente local de 7000 bare metal servidores através de 3 Centros de Dados NOS eua.

Mas há um pouco mais para ele. Quando dizemos 7000 servidores, que inclui:

cerca de 20 diferentes modelos de servidor

mais de 100 diferentes modelos de disco

...cartões de memória

...CPUs

...placas raid

..NICs

...PSUs

...e uma combinação de todas as anteriores

Portanto, há um monte de opções de configuração de hardware e um monte de valorização dos servidores.

Uma vez que estamos localizados no Brasil e em nossos Centros de Dados estão localizados na Europa, em cada Centro de Dados, há uma equipe de suporte 24/7 disponível para lidar com tudo no lado físico. Eles assumem o papel de nossa Remoto "Mãos e Olhos" com qualquer um no local de trabalho relacionadas. Eu vou tratá-los como "Remoto Mãos" neste post do blog.

O que fazer?

Nós dividimos o nosso trabalho em 3 principais tipos de tarefas:

As mudanças planejadas – Nossa alterações previstas são geridos no Jira e está principalmente relacionado com o hardware bilhetes aberto por nossos clientes – principalmente engenheiros da Plataforma em Nuvem do grupo. Costumamos dividir estes bilhetes em 3 tipos de tarefas:

atualizações de hardware

solicitações de serviço

máquina de pedidos (que vamos discutir em mais detalhes mais tarde)

Estes podem ser de atualizar os recursos de um servidor, trabalhando em uma suspeita de problema de hardware ou criação de um novo cluster completamente.

Alterações imprevistas , Tudo o que tem que ser feito Agora. Durante o horário de trabalho pode ser uma tarefa gerenciada no Jira como um bloqueio/crítica bilhete. Durante horas, ele pode ser um PagerDuty de alerta.

Projetos internos – Projetos que nossa equipe inicia e decide gerir. Estas são, geralmente, as tarefas que nossos clientes não conhece ou não gosta muito, mas essas tarefas são mais interessantes e fazer nossa a vida dos usuários e a nossa vida muito melhor. Em essência, nossos projetos internos impedir alterações imprevistas e faça as alterações previstas mais fácil de executar. A nova ferramenta vou discutir cai nesta categoria.

Se você gostaria de saber mais sobre quem somos e como fazemos as coisas, altamente recomendo que você siga nossa página no Avance Network

O desafio

Olhando para trás, há um ano que as nossas tarefas foram distribuídas assim:

As mudanças planejadas – 75%

Alterações imprevistas – 15%

Projetos internos – 10%

Isso significa que 90% do trabalho foi o trabalho manual e 10% foram projetos voltados para automação. O significado de ambos era relativamente lento na entrega, muito espaço para erros humanos e frustração, devido à elevada natureza repetitiva a maior parte do trabalho. Simplesmente coloque, ele apenas não escala.

A nossa solução para este problema foi a formulação de uma visão, e apresentá-lo para os nossos clientes a obter o seu buyin. Nossos clientes concordaram em tomar uma batida, os prazos de entrega de seus pedidos, para que pudéssemos foco em projetos internos categoria", com a intenção de investir em automação, e, portanto, a velocidade e robustez de nossa execução.

Nós decidimos dar para a construção de tantos processos automatizados quanto possível, a fim de minimizar a quantidade de tempo gasto nas alterações planejadas e não planejadas alterações, uma vez que muitas dessas tarefas apareceu para se prestam muito bem para a automação.

O "antes" da foto

Quando iniciamos nossa viagem em direção a automação, o processo de escolher o mais adequado de servidores para a máquina pedido nos levou um monte de tempo.

Que ficou assim:

Verificação de hardware disponíveis e verificar se temos livre suficiente de servidores para atender a solicitação

Escolha o mais adequado hardware com cuidado (e manualmente) assegurar a restrições de hardware são cumpridas (adequado servidor de fator de forma, o suporte para o número necessário de unidades, adaptador RAID, etc)

Reserva de servidores em caráter temporário alocação de pool de modo que ninguém mais vai usá-los para algo mais como eles estão sendo trabalhadas

Alocar as peças relevantes em nosso sistema de inventário

Enviar a configuração de destino nas Mãos Remotas sistema de gestão que tínhamos construído, para que o nosso técnico gostaria de ter a informação necessária para a tarefa (configuração de servidor de e peças necessárias)

Abra um ticket com as informações relevantes (localizações do servidor, número de série, etc) para o local Remoto Mãos da equipe, para começar a trabalhar sobre as alterações de configuração de hardware

Tudo isso tinha que ser feito antes de qualquer trabalho prático no hardware mesmo de começar.

Além disso, nós também teve de lidar com as falhas no fluxo:

erros de configuração

incompatibilidades de hardware

erros humanos

peças com defeito

O "depois" da imagem

O processo já havia trabalhado, mas levou muito tempo, às vezes, o máximo de horas por pedido, dependendo de quantos servidores foram solicitados e que mudanças eram necessárias para a sua configuração.

Enquanto nós tínhamos um conjunto de ferramentas que ajudaram a nos levar para esta fase, muito melhor que no processo anterior tivemos, o que poderia levar dias para a grande pedidos ele iria nos manter à tona, mas ainda são necessários para o trabalho manual que parecia totalmente desnecessário.

A nossa visão para esse processo foi a de simplificar, a aparência da seguinte maneira:

Submeta um pedido para o final de configuração do servidor, detalhando o número de servidores por datacenter e sua especificação final

Beber café enquanto Namaste manipula tudo, no fundo, incluindo a abertura de um ticket de Mãos Remotas

Seja notificado de que o pedido foi cumprido

Este processo simplificado que teria código de lidar com os metadados correspondentes, de alocação e reserva, e deixar-nos a lidar com o cumprimento rejeita, onde a intervenção humana é realmente necessário.

Por trás das cenas

O fluxo de máquinas de correspondência por uma máquina de pedido:

Aceitar a entrada do usuário – entramos requisitos do servidor, tais como a quantidade, a localização e especificação

Executar máquina de correspondência – Um motor construímos retorna todos os servidores correspondência com as exigências, algumas das quais podem ser uma correspondência parcial (falta uma unidade, menos memória RAM, etc.)

Priorizar a Priorizar, a partir de uma correspondência de lista do servidor, com base em:

Rack consciência

Servidor de fator de forma

Unidade de fator de forma

Número de núcleos mais próximo para o pedido de especificação

Alterações de Hardware necessários para trazer máquinas de pedido de spec

Reserva máquinas – Reserva priorizadas servidores em uma piscina temporária para evitar a dupla de alocação de

Executar peças de correspondência – Decidir quais peças usar para trazer o reservado servidores para a especificação solicitada, sempre que necessário

Reserva de peças de Reserva selecionado peças em nosso estoque para evitar a dupla de alocação de

Conjunto de máquinas de destino spec – Marque os servidores com as alterações necessárias, por isso, quando o nosso apoio a equipe começa a trabalhar no sentido de cumprir a ordem de trabalho, eles vão se conectar um iPad para cada servidor que irá dizer-lhes que mudanças precisam ser feitas.

Abra um ticket – Abra um ticket com todas as informações relevantes para o nosso equipe de suporte para o seu cumprimento.

Retorno do investimento

O mais óbvio ganho no desenvolvimento deste mecanismo é tempo de verão. Com as etapas de correspondência de hardware e reservar partes, sendo os principais pontos de atrito que foram removidos. Horário de verão reduz o tempo de espera por hardware cumprimento de requisição, de modo que tanto a equipe e os clientes a ganhar.

Automatizado de correspondência também reduz erros humanos, o que tem impacto na economia de tempo, bem como na experiência do cliente. Além disso, ele também permite-nos usar o melhor material, o que aumenta a eficiência através da atribuição que melhor corresponda recursos para atender a solicitação. Simplesmente coloque, não podemos atribuir a "primeira correspondência" ou "aleatório" servidores. Em vez disso, nós selecione a opção "mais adequado", como o algoritmo de correspondência de agora é explícito e passível de repetição.

Um "efeito colateral" de melhoria do processo de correspondência é que toda uma classe de problemas é totalmente evitado. Essas são questões em torno servidor - parte de incompatibilidade, o máximo de capacidade do servidor e, geralmente, tudo Remota Mãos pode vir transversalmente após o pedido já tinha sido despachado para eles. Esses tipos de problemas são mais caros em relação ao tempo, como eles exigem humanos para a comunicação humana através de fusos horários diferentes. Nós sabíamos que isso iria ajudar, mas o real impacto foi surpreendente.

Finalmente, a experiência do usuário dramaticamente melhorada com a introdução deste sistema:

Usuários pedido de hardware obter seus pedidos cumprido mais rápido

Mãos remotas vêm em menos problemas no campo

Nossa equipa lida com muito menos rejeições e o trabalho manual

Como você pode ver, existem 3 tipos de clientes aqui, e tudo sai por cima.

Um breve resumo

Há um ano iniciamos um caminho para construir a nossa BMaaS solução, onde Namaste é apenas uma parte da imagem completa. Enquanto este é ainda um trabalho em progresso e podemos esperar que continuem a desenvolver-se indefinidamente, agora é uma boa oportunidade para olhar para trás, o lugar onde começamos, especificamente no que nos levou para o caminho.

No início deste post, eu mencionei que o nosso trabalho de distribuição parecia antes decidimos mudar as coisas ao redor. Para lembrá-lo, foi algo assim:

As mudanças planejadas – 75%

Alterações imprevistas – 15%

Projetos internos – 10%

De um ano para o processo, a natureza do nosso trabalho mudou drasticamente, e a distribuição do trabalho é agora mais junto:

As mudanças planejadas – 15%

Alterações imprevistas – 0.1%

Projetos internos – 85%

É importante notar que o volume real de alterações não diminuiu. Na verdade, temos agora de lidar com mais de hardware cumprimento pedidos do que nunca antes. Mas a consciente atenção a essas alterações exigem de nós tem caído significativamente. Em vez disso, nós nos concentramos principalmente sobre a construção do sistema que faz com que o trabalho feito por todos nós, mudando-nos de "mover" o hardware para o software de gravação.

Qual é o próximo

APIs – por fazer do nosso BMaaS plataforma APIs abertas para os nossos utilizadores, nós podemos esperar que novas e imprevistas casos de uso para a superfície, onde os nossos usuários criar suas próprias soluções em cima da plataforma

INTERFACE do usuário da Web – muito do que fazemos atualmente é acessível através de ferramentas de linha de comando. Enquanto isso funciona, uma INTERFACE de usuário da web pode melhorar a experiência do usuário ainda mais e permitir a construção de vários pontos de vista que o sistema não suporta, ainda

Eventos e notificações – nossa equipe ainda serve como uma comunicação de pipeline em várias partes do processo, como estamos validando ideias diferentes e garantir que tudo funciona como o esperado. Pretendemos introduzir eventos e notificações de que iria retirar-nos inteiramente a partir do fluxo e permitir que os usuários para agir sobre determinados eventos, em pessoa ou através de seu próprio código de

Café – talvez mover para alguns descafeinado. Ou chá.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.