En un momento dado, ocupé un puesto en una pequeña empresa como ingeniero de operaciones de sistemas Linux, o mejor dicho, simplemente como un “servidor”. La compañía tenía unas 200 personas con un tráfico significativo. Aquí hay una lista de cosas en las que trabajaría.
Normalmente me asignarían a un (a veces más) problema relacionado con la interrupción crítica. Estos fueron problemas en los que la llamada se resolvió de cualquier manera, pero la causa raíz subyacente no se había determinado o (si se había determinado) no se había solucionado. El trabajo normal en estos tickets puede incluir la depuración del código de la aplicación, escribir pruebas, revisar registros, analizar servidores fuera de rotación, etc. Cuando se haya determinado la causa raíz, puedo rediseñar / modificar la infraestructura del servidor para ayudar a asegurar que el problema no vuelva a aparecer, reescriba el código o abra tickets con otros equipos cuando sea necesario. A veces no se pudo identificar la causa raíz y escribiría nuevos monitores, registraría cosas adicionales en el sistema de gráficos o introduciría nuevos registros para ayudarnos a ver el problema en el futuro.
El sistema de administración de infraestructura de clúster fue algo en lo que trabajé mucho. Esto era principalmente una aplicación Django con algo de salsa mágica pxe / kickstart / puppet detrás de las cortinas. Pasaría tiempo reparando errores con el panel de control o trabajando en la API del sistema. Cuando sea necesario, usaría el sistema para “hacer girar” nuevos grupos de sistemas, como un nuevo grupo de servidores web que se encuentran detrás de uno de los SLB.
Los roles de servidor se implementaron principalmente como un gran conjunto de módulos de títeres. Estos módulos estaban cambiando constantemente por cualquier razón. Escribir rutinariamente nuevos módulos de títeres o ampliar / modificar los módulos existentes era una tarea que realizaba habitualmente. Ocasionalmente, los equipos de productos se encargarían de escribir su propio código de títeres. Fui revisor de este código.
Por razones históricas, había un conjunto de servidores de “copos de nieve únicos”. Estos fueron sistemas que los desarrolladores piratearon en un estado funcional y luego señalaron el tráfico de producción. El trabajo continuo me requería diseñar roles aprovisionables para reemplazar estos irritantes servidores únicos. Ocasionalmente, ninguna persona sabía todo de lo que algunos de estos sistemas eran responsables y tuve que hacer un poco de análisis sobre lo que la caja estaba haciendo. Por lo general, esto me llevó a descomponer el sistema en su agrupación lógica de funciones y mover esa funcionalidad a los clústeres existentes. Esta siempre fue una tarea de mediana a gran escala.
Participaría en una rotación de llamadas. Como oncall, fui el encargado de CUALQUIER tema relacionado con producciones. Tenía la máxima autoridad de delegación, y hasta que firmé un problema, era mi decisión qué hacer. Durante una “interrupción importante”, todos los recursos de la empresa están a disposición inmediata de la llamada. Afortunadamente, nosotros (esp) éramos bastante buenos en lo que hicimos y un problema importante era raro. La mayor parte del tiempo en la llamada en vivo implicaba responder a fallas de hardware simples en los diversos centros de datos en todo el país. Una vez que alcanza una escala particular, se esperan fallas constantes y continuas de hardware. Esperemos que cuando llegue a esa escala no esté confiando en que los sistemas individuales siempre estén activos. Estos discos duros explosivos o servidores de tanques individuales implican solo cambiar un poco el tráfico y programar un ticket de descomposición / reemplazo.
Trabajaría en el sistema de monitoreo. Entre otras cosas, utilizamos nagios para el monitoreo. Autorizaría nuevos monitores de servicio nagios para nuevos productos o características del producto. Ocasionalmente, escribiría nuevos complementos nagios que se ajustaran a los detalles de algunos de nuestros productos.
Por razones históricas, se utilizaron algunos sistemas de lanzamiento diferentes. No sería raro verme escribir una nueva especificación de rpm para algo aleatorio. Tuvimos algunos espejos de repositorio diferentes que mi equipo manejó. Teníamos un conjunto de repositorios para el código interno, así como un conjunto de repositorios que reflejaban el código aguas arriba de la distribución. Pasaría tiempo organizando paquetes en nuestros repositorios desde arriba. Por razones históricas, ocasionalmente tuvimos un conflicto de paquetes entre nuestras bases de códigos internas y externas (generalmente lo hacen para cambios ascendentes). Yo era una de las personas que lidiaría con estos conflictos irritantes.
Pasaría tiempo creando nuevas herramientas para trabajar con los diversos sistemas que teníamos.
La configuración del servidor era propiedad de mi equipo y revisamos cualquier cambio de servidor solicitado.
La tecnología de sistemas siempre está cambiando. Siempre estaba investigando nuevos sistemas / servicios para ver si podíamos usarlos.
Incorporaríamos bastidores preconstruidos a nuestros centros de datos. Supervisaría la construcción de estos bastidores por nuestro proveedor. Un bastidor podría tener aproximadamente 85 sistemas físicos y había una cantidad considerable de tiempo de preparación cuando se instalaba en un nuevo bastidor (como agregar todos los sistemas al sistema de administración del clúster y preparar la red). Haría mucho de este trabajo.
Así que solo hay una muestra de cosas en las que trabajaría. Básicamente, soy dueño de la producción. Todo y cualquier cosa que toque la producción pasa por nosotros. Si bien nuestra principal responsabilidad no es el desarrollo de productos, debemos comprender cómo funciona el software para depurarlo ante un desastre. No somos simplemente monos terminales y pasamos mucho tiempo escribiendo software.
