Introducción Muchas empresas de TI han adoptado la práctica del servicio de guardia. Un ingeniero está de servicio, y su deber dura un turno. Por lo general, el turno dura un día o una semana. Hay casos de aumento o disminución de este período, pero esto es raro. Los deberes del ingeniero en este rol varían de una compañía a otra, pero hay algunos puntos en común. Tienes que responder a las preguntas que entran en el equipo. Es necesario monitorear el desempeño de los servicios de los cuales el equipo es responsable. Para hacer frente a incendios e incidentes. Escala el incidente aún más si no puedes resolverlo. Hablaremos sobre cómo estar bien preparado para el trabajo como ingeniero en este artículo. Definición de ingeniero de servicio perfecto. Si ocurren incidentes o incendios en su turno en un entorno de combate, no significa que sea un ingeniero terrible. Para ser un buen ingeniero de servicio, si surgen problemas, debe resolverlos de la manera más rápida y rentable posible. Un ingeniero bien capacitado comprende dónde puede manejarse y dónde vale la pena escalar aún más la situación. Debe saber cuándo ya quién llamar para pedir ayuda. No debe permitir, si es posible, que se repitan los mismos problemas. Experiencia Es útil aprovechar la experiencia propia y del equipo para prepararse mejor para el deber. Es una buena idea comenzar mirando qué documentación ya existe para el manejo de incidentes. ¿Existe documentación a nivel de empresa o equipo? Es fundamental saber dónde está y estar familiarizado con él. Si no existe, ¿podría intentar iniciar el proceso de creación de uno? Luego, vale la pena verificar qué incidentes ya han ocurrido y cómo se registran en el almacén de conocimiento. ¿Hay autopsias y tareas que arreglar? ¿Sabes si estas tareas se están haciendo? Si se crean tareas para arreglar la situación, pero no se implementan, esta es una razón para discutirlo en una reunión con su gerente. ¿Sabe si se registran las funciones del ingeniero de turno? ¿De qué son responsables y de qué no? Si no existe tal documentación o entendimiento, sería útil para todo el equipo tener uno. Instrumentos El conjunto de herramientas para el ingeniero en servicio es específico y algo diferente del conjunto de herramientas cotidiano del desarrollador. Las principales tareas que surgen durante la extinción de incendios son aquellas que no pueden ser resueltas por las consultas existentes Veamos estas herramientas con más detalle: La principal herramienta técnica para el deber, con la ayuda de la cual puede resolver muchos problemas, es bash. Si el conocimiento de esta hermosa herramienta aún no está en su arsenal, use uno de los cursos intensivos ( A menudo, en el modo de disparo, debe realizar algunas operaciones con la base de datos del producto. La habilidad de trabajar con la base de datos a través de la terminal: psql para PostgreSQL o mongosh para MongoDB ayudará . Estas herramientas se dan como ejemplos, puede buscar su propia base de datos. Para muchas bases de datos, existen herramientas visuales con las que trabajar, pero el terminal está disponible en todas partes, requiere un mínimo de Internet y es muy flexible. Para el modo fuego, puede ser muy útil. https://www.postgresguide.com/utilities/psql/ https://www.mongodb.com/docs/mongodb-shell/ curl es una herramienta que te permitirá realizar un número considerable de consultas, y al combinarlo con conocimientos de bash, te volverás casi omnipotente. Será muy útil si tiene a mano un conjunto de guiones preparados en el momento del incendio. Deben ser tan simples y directos como sea posible. Sí, probablemente puedas escribirlos muy rápido, pero cuando tienes un tiempo limitado, es genial tener un conjunto listo que te permita pensar solo en el bloqueo y no en cómo implementar la misma vinculación. Los scripts a continuación son solo una representación de la estructura potencial de dichos scripts. Por supuesto, su código debe probarse antes del incidente y ser lo más simple y directo posible. Es útil tener los siguientes scripts: Un script que genera un archivo a partir de los datos proporcionados. Estos se pueden obtener de otros comandos o haciendo una solicitud independiente. A continuación se muestra un ejemplo de un script de este tipo en Python. import csv def modify(filename): tmpFile = "tmp.csv" # Reading file with data and creation of output file with open(filename, "r") as file, open(tmpFile, "w") as outFile: # Create reader for initial file reader = csv.reader(file, delimiter=',') # Create writer for output file writer = csv.writer(outFile, delimiter=',') # Read header line header = next(reader) # Write header line writer.writerow(header) # Process initial file line by line for row in reader: colValues = [] # Process each column of each line for col in row: # Let for example transform all columns to lowercase colValues.append(col.lower()) # Write modified line to final file writer.writerow(colValues) filename = 'sample_data.csv' modify(filename) Un script que llamará a los puntos finales requeridos con el paralelismo especificado. No tiene que ser nada complicado. A continuación se muestra un ejemplo de un código JavaScript simple que generará un archivo sh con el paralelismo especificado que puede ayudarlo con eso. Sí, no tenemos manejo de resultados aquí, pero no siempre es necesario, y puede modificar su conjunto de herramientas con una versión de manejo de resultados si es necesario. Por ejemplo, tenemos un archivo que lee y escribe todos los datos, pero puede crear secuencias de comandos para archivos grandes. const fs = require('fs'); const initialFilePath = 'sample_data.csv'; const outputFilePath = 'sample_script.sh'; const amountOfParallelRequests = 5; // Remember about the throughput and the bandwidth of your services const delimiterForCSV = ','; // Read the initial file and split it by lines // You could transform it to an object if it's relevant to your situation let initialFile = fs.readFileSync(initialFilePath).toString().split('\n'); // Prepare boilerplate for sh script let outputString = '#!/bin/bash\n\n'; // Write data with parallel execution // Skip header for CSV // The code for parallel requests was received from https://serverfault.com/questions/456490/execute-curl-requests-in-parallel-in-bash // and you could implement your version instead for (let i = 1; i < initialFile.length; i++){ let line = initialFile[i]; if (!line) { continue; } let processedLine = line.split(delimiterForCSV); // We don't implement processing of errors here // Let's suggest that the necessary for request value lies in second column let desiredValue = processedLine[1]; if (desiredValue === undefined) { console.error('We have a trouble ' + line); } outputString += `curl -s -o foo http://example.com/file${desiredValue} && echo "done with ${desiredValue}" &\n`; if (i % amountOfParallelRequests === 0 || i === initialFile.length - 1) { outputString += '\nwait\n\n'; } } fs.writeFileSync(outputFilePath, outputString); // Indicate the success console.log('Success'); Un script que obtiene algo de una base de datos o servicio y devuelve el resultado convertido o tal vez llama a otro punto final. Sugiero implementarlo usted mismo, sin olvidar la autorización y los escenarios de uso apropiados. Conocimiento Además de las herramientas y la experiencia, una cierta cantidad de conocimiento es útil cuando estás de servicio. Me gustaría saber sobre los registros y métricas de sus servicios. ¿Adónde van y cómo llegas allí? ¿Sabrías cómo usar estas herramientas? Cuando recibe una llamada por la noche de un servicio de guardia que le informa que su servicio no funciona, lo mejor para usted es descubrir rápidamente qué es lo que está fallando. Para hacer eso, necesita saber con precisión dónde se almacenan sus métricas y registros y qué mirar primero. ¿Cómo posponer alertas? Después de analizar el incidente, a menudo resulta que el accidente actual puede estar esperando para la mañana, por lo que es bueno entender cómo posponer la alerta. No para cerrar, porque en el caso de algunas operaciones se te volverá a avisar, sino precisamente para posponer. Debe recordar tratar y corregir la situación o alerta tan pronto como comience su día de trabajo típico. ¿Dónde están los contactos o cómo te pones en contacto con compañeros o miembros de otros equipos? Debe haber una herramienta o conocimiento claro en tu cabeza: quién entiende/debe saber acerca de la situación cuando sucedió. Los expertos pueden ayudarlo a resolver el incidente y las partes interesadas deben saber que algo anda mal. Debe tener acceso a sus contactos, idealmente a su teléfono, porque muchas personas desactivan las notificaciones de los chats de la oficina fuera del horario comercial. ¿Cómo obtiene acceso a la producción/base de datos y aumenta el acceso si existen niveles de acceso? Si no tiene acceso, necesita saber a quién acudir o qué hacer para obtener el acceso que desea. ¿Cómo se pone el código en producción rápidamente? A veces, los problemas requieren un cambio rápido en el código de servicio en producción. En general, esto se considera correctamente una mala práctica, pero a menudo en una emergencia, este no es el caso. A veces, no desea esperar largas pruebas E2E, sino que necesita obtener rápidamente el código en el entorno de producción. Me gustaría que entiendas cómo hacer esto. ¿Qué datos se almacenan en la base de datos? ¿Existen esquemas de movimiento de datos dentro del producto y entre servicios? Si necesita interactuar con la base de datos, es bueno saber cómo se organizan los datos en un servicio en particular, de dónde provienen y quién los usa. Esto le permitirá hacer frente a los problemas, si los hay, antes. Además de las herramientas y la experiencia, una cierta cantidad de conocimiento es útil cuando estás de servicio. Me gustaría saber sobre los registros y métricas de sus servicios. ¿Adónde van y cómo llegas allí? ¿Sabes cómo usar estas herramientas? Cuando recibe una llamada por la noche de un servicio de guardia que le informa que su servicio no funciona, lo mejor para usted es descubrir rápidamente qué es lo que está fallando. Para hacer eso, necesita saber con precisión dónde se almacenan sus métricas y registros y qué mirar primero. ¿Cómo posponer alertas? Después de analizar el incidente, a menudo resulta que el accidente reciente puede estar esperando para la mañana, por lo que es bueno entender cómo posponer la alerta. No para cerrar, porque, en el caso de algunas operaciones, se le volverá a avisar, sino precisamente para posponer. Sería mejor si recordara tratar y corregir la situación o alertar tan pronto como comience su día de trabajo típico. ¿Dónde están los contactos o cómo se pone en contacto con colegas o miembros de otros equipos? Debe haber una herramienta o conocimiento preciso en tu cabeza: quién entiende/debe saber acerca de la situación cuando sucedió. Los expertos pueden ayudarlo a resolver el incidente y las partes interesadas deben saber que algo anda mal. Debe tener acceso a sus contactos, idealmente a su teléfono, porque muchas personas desactivan las notificaciones de los chats de la oficina fuera del horario comercial. ¿Cómo obtiene acceso a la producción/base de datos y aumenta el acceso si existen niveles de acceso? Si necesita acceso, necesita saber a quién acudir o qué hacer para obtener el acceso que desea. ¿Cómo se pone el código en producción rápidamente? A veces, los problemas requieren un cambio rápido en el código de servicio en producción. En general, esto se considera correctamente una mala práctica, pero a menudo en una emergencia, este no es el caso. A veces, desea obtener rápidamente el código en el entorno de producción antes de largas pruebas E2E. Me gustaría que entiendas cómo hacer esto. ¿Qué datos se almacenan en la base de datos? ¿Existen esquemas de movimiento de datos dentro del producto y entre servicios? Si necesita interactuar con la base de datos, es bueno saber cómo se organizan los datos en un servicio en particular, de dónde provienen y quién los usa. Esto le permitirá hacer frente a los problemas, si los hay, antes. Conclusión Incluso en empresas y equipos con una excelente cultura de ingeniería, ocurren accidentes e incendios en el trabajo. Para evitar esto, el equipo debe hacer todo lo posible para mejorar los procesos y productos actuales. Aún así, cada ingeniero también debe estar preparado para que ocurra un accidente y tenga que lidiar con él con urgencia. Para ello, vale la pena utilizar toda la experiencia personal y de equipo acumulada. Vale la pena conocer la organización y los servicios y tener confianza en su conjunto de herramientas. Enlaces útiles https://zach-gollwitzer.medium.com/the-ultimate-bash-crash-course-cb598141ad03 https://www.youtube.com/watch?v=oxuRxtrO2Ag https://www.postgresguide.com/utilities/psql/ https://www.mongodb.com/docs/mongodb-shell/

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Making security fun one episode at a time

Ingeniero de servicio perfecto

Demasiado Largo; Para Leer

Alexey Sutyagin

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

Ingeniero de servicio perfecto

Demasiado Largo; Para Leer

Alexey Sutyagin

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS