¡Hola, Habr! Presento a su atención la traducción del artículo. por Adib Daw.
Si ese titular no le provoca un ligero escalofrío, debe pasar al siguiente párrafo o visitar nuestra página dedicada a - nos gustaría hablar.
Quienes Somos
Somos un equipo de 4 pingüinos a los que les encanta escribir código y trabajar con hardware. En nuestro tiempo libre, somos responsables de implementar, mantener y operar una flota de más de 7000 servidores físicos que ejecutan Linux, distribuidos en 3 centros de datos diferentes en los Estados Unidos.
También tuvimos la oportunidad de hacerlo a 10 km de distancia de los sitios, desde la comodidad de nuestra propia oficina, que se encuentra a poca distancia en coche de la playa en el mar Mediterráneo.
Problemas de escala
Si bien tiene sentido que una startup comience alojando su infraestructura en la nube debido a la inversión inicial relativamente baja, en Outbrain decidimos utilizar nuestros propios servidores. Hicimos esto porque los costos de la infraestructura de la nube superan con creces los costos de operar nuestro propio equipo ubicado en los centros de datos después del desarrollo hasta cierto nivel. Además, su servidor proporciona el más alto grado de control y capacidades de resolución de problemas.
A medida que nos desarrollamos, los problemas siempre están cerca. Además, suelen venir en grupos. La gestión del ciclo de vida de los servidores requiere una mejora constante para poder funcionar correctamente en el contexto del rápido aumento del número de servidores. Los métodos de software para gestionar grupos de servidores en centros de datos rápidamente se vuelven difíciles de manejar. Detectar, solucionar problemas y mitigar fallas mientras se cumplen los estándares de QoS se convierte en una cuestión de hacer malabarismos con conjuntos de hardware extremadamente diversos, diferentes cargas de trabajo, plazos de actualización y otras cosas interesantes de las que nadie quiere preocuparse.
Domina tus dominios
Para resolver muchos de estos problemas, dividimos el ciclo de vida del servidor en Outbrain en sus componentes principales y los llamamos dominios. Por ejemplo, un dominio cubre los requisitos de equipo, otro cubre la logística relacionada con el ciclo de vida del inventario y un tercero cubre las comunicaciones con el personal de campo. Hay otro sobre la observabilidad del hardware, pero no describiremos todos los puntos. Nuestro objetivo era estudiar y definir dominios para que pudieran abstraerse mediante código. Una vez que se desarrolla una abstracción funcional, se transfiere a un proceso manual que se implementa, prueba y perfecciona. Finalmente, el dominio está configurado para integrarse con otros dominios a través de API, formando un sistema de ciclo de vida de hardware holístico, dinámico y en constante evolución que es implementable, comprobable y observable. Como todos nuestros otros sistemas de producción.
Adoptar este enfoque nos permitió resolver muchos problemas correctamente mediante la creación de herramientas y automatización.
Necesita dominio
Aunque el correo electrónico y las hojas de cálculo eran una forma viable de satisfacer la demanda en los primeros días, no fueron una solución exitosa, especialmente cuando la cantidad de servidores y el volumen de solicitudes entrantes alcanzaron un cierto nivel. Para organizar y priorizar mejor las solicitudes entrantes ante la rápida expansión, tuvimos que utilizar un sistema de emisión de tickets que pudiera ofrecer:
- Posibilidad de personalizar la vista solo de campos relevantes (simple)
- API abiertas (extensible)
- Conocido por nuestro equipo (entendido)
- Integración con nuestros flujos de trabajo existentes (unificados)
Dado que utilizamos Jira para gestionar nuestros sprints y tareas internas, decidimos crear otro proyecto que ayudaría a nuestros clientes a enviar tickets y realizar un seguimiento de sus resultados. Usar Jira para las solicitudes entrantes y para gestionar tareas internas nos permitió crear un único tablero Kanban que nos permitió ver todos los procesos en su conjunto. Nuestros "clientes" internos solo vieron solicitudes de equipos, sin profundizar en los detalles menos significativos de tareas adicionales (como mejorar herramientas, corregir errores).
Tablero Kanban en Jira
Como beneficio adicional, el hecho de que las colas y las prioridades ahora fueran visibles para todos hizo posible comprender “en qué parte de la cola” se encontraba una solicitud en particular y qué la precedía. Esto permitió a los propietarios cambiar la prioridad de sus propias solicitudes sin tener que contactarnos. Arrástralo y listo. También nos permitió monitorear y evaluar nuestros SLA según los tipos de solicitudes en función de las métricas generadas en Jira.
Dominio del ciclo de vida del equipo
Intente imaginar la complejidad de administrar el hardware utilizado en cada rack de servidores. Lo que es aún peor es que muchas piezas de hardware (RAM, ROM) pueden trasladarse desde el almacén a la sala de servidores y viceversa. También fallan o se cancelan y se reemplazan y se devuelven al proveedor para su reemplazo/reparación. Todo ello deberá ser comunicado a los empleados del servicio de colocación implicados en el mantenimiento físico del equipo. Para solucionar estos problemas, creamos una herramienta interna llamada Floppy. Su tarea es:
- Gestión de comunicaciones con personal de campo, agregación de toda la información;
- Actualizar los datos del “almacén” después de cada trabajo de mantenimiento de equipos completado y verificado.
El almacén, a su vez, se visualiza utilizando Grafana, que utilizamos para trazar todas nuestras métricas. Así, utilizamos la misma herramienta para la visualización del almacén y para otras necesidades de producción.
Panel de control de equipos de almacén en Grafana
Para los dispositivos de servidor que están en garantía, utilizamos otra herramienta que llamamos Dispatcher. Él:
- Recopila registros del sistema;
- Genera informes en el formato requerido por el proveedor;
- Crea una solicitud del proveedor a través de API;
- Recibe y almacena el identificador de la aplicación para un mayor seguimiento de su progreso.
Una vez que se acepta nuestro reclamo (generalmente dentro del horario comercial), la pieza de repuesto se envía al centro de datos correspondiente y el personal la acepta.
Salida de la consola Jenkins
Dominio de comunicación
Para mantenernos al día con el rápido crecimiento de nuestro negocio, que requiere una capacidad cada vez mayor, tuvimos que adaptar la forma en que trabajamos con especialistas técnicos en los centros de datos locales. Si al principio la ampliación significaba comprar nuevos servidores, luego de un proyecto de consolidación (basado en la transición a Kubernetes) se convirtió en algo completamente diferente. Nuestra evolución de “agregar racks” a “reutilizar servidores”.
Utilizar un nuevo enfoque también requería nuevas herramientas que permitieran interactuar más cómodamente con el personal del centro de datos. Estas herramientas eran necesarias para:
- Sencillez;
- autonomía;
- Eficiencia;
- Fiabilidad
Tuvimos que excluirnos de la cadena y estructurar el trabajo para que los técnicos pudieran trabajar directamente con los equipos del servidor. Sin nuestra intervención y sin plantear periódicamente todas estas cuestiones relativas a la carga de trabajo, los horarios de trabajo, la disponibilidad de equipos, etc.
Para lograrlo, instalamos iPads en cada centro de datos. Después de conectarse al servidor, sucederá lo siguiente:
- El dispositivo confirma que este servidor efectivamente requiere algo de trabajo;
- Las aplicaciones que se ejecutan en el servidor se cierran (si es necesario);
- Se publica un conjunto de instrucciones de trabajo en un canal de Slack que explica los pasos necesarios;
- Al finalizar el trabajo, el dispositivo verifica la exactitud del estado final del servidor;
- Reinicia las aplicaciones si es necesario.
Además, también preparamos un bot de Slack para ayudar al técnico. Gracias a una amplia gama de capacidades (ampliábamos constantemente la funcionalidad), el bot facilitó su trabajo y nos hizo la vida mucho más fácil. De esta manera optimizamos la mayor parte del proceso de reutilización y mantenimiento de servidores, eliminándonos del flujo de trabajo.
iPad en uno de nuestros centros de datos
Dominio de hardware
Escalar de manera confiable la infraestructura de nuestro centro de datos requiere una buena visibilidad de cada componente, por ejemplo:
- Detección de fallos de hardware
- Estados del servidor (activo, alojado, zombie, etc.)
- Consumo de energía
- Versión de firmware
- Análisis para todo este negocio
Nuestras soluciones nos permiten tomar decisiones sobre cómo, dónde y cuándo comprar equipos, a veces incluso antes de que sean realmente necesarios. Además, al determinar el nivel de carga en diferentes equipos, pudimos lograr una mejor asignación de recursos. En particular, el consumo de energía. Ahora podemos tomar decisiones informadas sobre la ubicación de un servidor antes de instalarlo en el bastidor y conectarlo a una fuente de alimentación, durante todo su ciclo de vida y hasta su eventual retiro.
Panel de energía en Grafana
Y entonces apareció el COVID-19...
Nuestro equipo crea tecnologías que permiten a las empresas de medios y editores en línea ayudar a los visitantes a encontrar contenido, productos y servicios relevantes que puedan ser de su interés. Nuestra infraestructura está diseñada para atender el tráfico generado cuando se publican noticias interesantes.
La intensa cobertura mediática en torno a la COVID-19, junto con el aumento del tráfico, significaba que necesitábamos urgentemente aprender a afrontar estas presiones. Además, todo esto tuvo que hacerse durante una crisis global, cuando las cadenas de suministro se interrumpieron y la mayor parte del personal se quedó en casa.
Pero, como dijimos, nuestro modelo ya supone que:
- El equipo de nuestros centros de datos es, en su mayor parte, físicamente inaccesible para nosotros;
- Hacemos casi todo el trabajo físico de forma remota;
- El trabajo se realiza de forma asincrónica, autónoma y a gran escala;
- Satisfacemos la demanda de equipos utilizando el método de "construcción a partir de piezas" en lugar de comprar equipos nuevos;
- Disponemos de un almacén que nos permite crear algo nuevo y no solo realizar reparaciones rutinarias.
Así, las restricciones globales que impedían a muchas empresas tener acceso físico a sus centros de datos tuvieron poco impacto en nosotros, y en cuanto a repuestos y servidores, sí, intentamos asegurar el funcionamiento estable de los equipos. Pero esto se hizo con el objetivo de prevenir posibles incidencias cuando de repente resulta que algún hardware no está disponible. Nos aseguramos de que nuestras reservas se llenaran sin pretender satisfacer la demanda actual.
En resumen, me gustaría decir que nuestro enfoque para trabajar en la industria de los centros de datos demuestra que es posible aplicar los principios de un buen diseño de código a la gestión física de un centro de datos. Y quizás te resulte interesante.
Original:
Fuente: habr.com