A los nuevos administradores de sistemas: cómo hacer orden del caos

Soy administrador del sistema de FirstVDS, y este es el texto de la primera lección introductoria de mi breve curso para ayudar a mis colegas principiantes. Los especialistas que han comenzado recientemente en la administración de sistemas enfrentan una serie de problemas similares. Para ofrecer soluciones, me he puesto a escribir este ciclo de lecciones. Algunas cosas en él son específicas del soporte técnico de alojamiento, pero en general, pueden ser útiles, si no para todos, para muchos. Por lo tanto, he adaptado el texto de la lección para compartirlo aquí.

No importa cómo se llame tu cargo, lo importante es que, de hecho, te dedicas a la administración. Así que comencemos con lo que debe hacer un administrador de sistemas. Su tarea principal es poner orden, mantener el orden y prepararse para futuros aumentos en el mismo. Sin un administrador de sistemas, el servidor se convierte en un caos. Los registros no se generan, o se generan incorrectamente, los recursos se distribuyen de manera ineficiente, el disco se llena de todo tipo de basura y el sistema comienza a falla lentamente debido a tal cantidad de desorden. ¡Calma! ¡Los administradores de sistemas, como tú, comienzan a resolver problemas y a eliminar el desorden!

Pilares de la administración de sistemas

Sin embargo, antes de comenzar a resolver problemas, es importante familiarizarse con los cuatro principales pilares de la administración:

1. Documentación
2. Plantillado
3. Optimización
4. Automatización

Estos son los fundamentos. Si no construyes tu proceso de trabajo sobre estos principios, será ineficaz, improductivo y en general, poco parecido a la verdadera administración. Vamos a analizar cada uno por separado.

La documentación

La documentación implica no solo leer documentaciones (aunque esto es imprescindible), sino también llevar un registro.

Cómo llevar la documentación:

• ¿Te has encontrado con un nuevo problema que nunca habías visto? Anota los síntomas principales, los métodos de diagnóstico y los principios de solución.
• ¿Has ideado una nueva solución elegante para un problema estándar? Anótala, para que no tengas que reinventarla dentro de un mes.
• ¿Te ayudaron a resolver una cuestión que no entendías en absoluto? Anota los puntos clave y las ideas, dibuja un esquema para ti mismo.

La idea principal: no debes confiar completamente en tu memoria al aprender y aplicar algo nuevo.

El formato en que lo hagas depende solo de ti: puede ser un sistema de notas, un blog personal, un archivo de texto o un cuaderno físico. Lo importante es que tus registros cumplan con los siguientes requisitos:

1. No ser excesivamente largos. Destaca las ideas principales, métodos y herramientas. Si entender el problema requiere profundizar en la mecánica de bajo nivel sobre la gestión de memoria en Linux, no reescribas el artículo del que aprendiste, simplemente proporciona un enlace.
2. Los registros deben ser comprensibles para ti. Si la línea race cond.lockup no te permite entender de inmediato lo que describiste con esa línea, aclara. En una buena documentación no hay que perder media hora tratando de desentrañarla.
3. La búsqueda es una característica muy útil. Si llevas un blog, añade etiquetas; si utilizas un cuaderno físico, pega pequeños post-it con descripciones. No tiene mucho sentido tener documentación si tardas tanto en buscar respuestas como lo harías resolviendo el problema desde cero.

Así podría lucir la documentación: desde anotaciones primitivas en un cuaderno (imagen arriba) hasta una base de conocimientos colaborativa completamente desarrollada, con etiquetas, búsqueda y todas las comodidades posibles (abajo).

No solo no tendrás que buscar las mismas respuestas dos veces: documentar será un gran apoyo en el aprendizaje de nuevos temas (¡apuntes!), potenciará tu instinto (la capacidad de diagnosticar un problema complejo con solo una mirada superficial), y añadirá organización a tus acciones. Si la documentación está disponible para tus colegas, les permitirá entender qué y cómo hiciste las cosas cuando no estés presente.

La plantificación

La plantificación consiste en crear y utilizar plantillas. Para la mayoría de las cuestiones típicas, vale la pena desarrollar un proceso estándar. Para diagnosticar la mayoría de los problemas, se debe seguir una secuencia de acciones estandarizada. Cuando arregles/instales/optimices algo, la funcionalidad de ese algo debería ser verificada a través de listas de verificación estandarizadas.

La plantificación es la mejor manera de organizar el flujo de trabajo. Al utilizar procedimientos estándar para resolver los problemas más comunes, obtienes muchas cosas buenas. Por ejemplo, el uso de listas de verificación te permitirá diagnosticar todas las funciones importantes para el trabajo y descartar el diagnóstico de funcionalidades menos relevantes. Los procedimientos estandarizados minimizarán las indecisiones innecesarias y reducirán la probabilidad de errores.

El primer punto importante es que los procedimientos y listas de verificación también deben ser documentados. Si solo confías en la memoria, puedes omitir una comprobación u operación realmente importante y arruinarlo todo. El segundo punto importante es que todas las prácticas estandarizadas pueden y deben ser modificadas si la situación lo requiere. No existen plantillas perfectas y absolutamente universales. Si hay un problema, y la verificación estándar no lo ha detectado, no significa que no exista. Sin embargo, antes de empezar a verificar problemas hipotéticos poco probables, siempre vale la pena realizar primero una rápida verificación estándar.

Optimización

Optimización habla por sí misma. El flujo de trabajo debe ser optimizado al máximo en términos de gasto de tiempo y esfuerzo. Existen innumerables opciones: aprende atajos de teclado, abreviaciones, expresiones regulares, y herramientas disponibles. Busca formas más prácticas de usar estas herramientas. Si ejecutas un comando 100 veces al día, asígnale un atajo de teclado. Si necesitas conectarte regularmente a los mismos servidores, escribe un alias en una sola palabra que te conecte a ellos:

Explora las diferentes opciones de herramientas disponibles; puede que haya un cliente de terminal, un entorno de escritorio, un gestor de portapapeles, un navegador, un cliente de correo electrónico, o un sistema operativo más conveniente. Infórmate sobre qué herramientas utilizan tus colegas y amigos; quizás las eligen por una razón. Una vez que selecciones las herramientas, aprende a utilizarlas: familiarízate con las claves, atajos, y trucos.

Utiliza de manera óptima las herramientas estándar: coreutils, vim, expresiones regulares y bash. Para las tres últimas, hay una gran cantidad de manuales y documentación maravillosos. Con su ayuda, puedes pasar rápidamente de estar en un estado en el que «me siento como un mono rompiendo nueces con un portátil» a «soy un mono que usa un portátil para pedir un cascanueces».

Automatización

Automatización trasladará operaciones pesadas de nuestras cansadas manos a las incansables manos de la automatización. Si algún procedimiento estándar se realiza en cinco comandos idénticos, ¿por qué no agrupar todos estos comandos en un solo archivo y llamar a un único comando que ejecute ese archivo?

La automatización consiste en un 80% en escribir y optimizar tus propias herramientas (y en un 20% en intentar hacerlas funcionar como deberían). Esto puede ser simplemente una línea de código avanzada o una enorme herramienta todopoderosa con una interfaz web y API. El criterio principal aquí es que la creación de la herramienta no debe llevar más tiempo y esfuerzo que el tiempo y esfuerzo que esta herramienta te ahorrará. Si pasas cinco horas escribiendo un script que no volverás a usar, para una tarea que te llevaría una o dos horas sin el script, esa es una muy mala optimización del flujo de trabajo. Puedes dedicar cinco horas a crear una herramienta solo si la cantidad, tipo de tareas y tiempo lo permiten, lo cual no sucede a menudo.

La automatización no necesariamente implica escribir scripts completos. Por ejemplo, para crear un montón de objetos similares a partir de una lista, solo se necesita una línea de código ágil que haga automáticamente lo que harías a mano, cambiando entre ventanas y haciendo montones de copypaste.

En realidad, si construyes el proceso de administración sobre estos cuatro pilares, puedes aumentar bastante rápido tu eficiencia, productividad y calificación. Sin embargo, esta lista debe complementarse con un punto más, sin el cual trabajar en IT es prácticamente imposible: la autoeducación.

Autoeducación del administrador de sistemas

Para tener un poco de competencia en este campo, es necesario estar en constante aprendizaje y descubrir cosas nuevas. Si no tienes el más mínimo interés en enfrentarte a lo desconocido y comprenderlo, te quedarás atrás muy rápidamente. En IT, constantemente surgen diversas soluciones, tecnologías y métodos, y si no los estudias al menos superficialmente, estarás en camino a perder. Muchas áreas de la tecnología de la información se basan en fundamentos bastante complejos y extensos. Por ejemplo, el funcionamiento de las redes. Las redes e Internet están en todas partes, te enfrentas a ellas a diario, pero si profundizas en las tecnologías que las sustentan, descubrirás una disciplina enorme y muy compleja, cuyo estudio no es un paseo en el parque.

No incluí este punto en la lista porque es fundamental para IT en general, y no solo para la administración de sistemas. Naturalmente, no podrás aprender todo de inmediato; simplemente no tienes tiempo físico para hacerlo. Por lo tanto, al autoeducarte, debes tener en mente los niveles de abstracción necesarios.

No es necesario que aprendas de inmediato cómo funciona la gestión interna de la memoria de cada herramienta específica y cómo interactúa con la gestión de memoria de Linux, pero es bueno saber, al menos de forma esquemática, qué es la memoria RAM y para qué sirve. No necesitas saber cómo se estructuran las cabeceras de TCP y UDP, pero sería beneficioso entender las principales diferencias en el funcionamiento de los protocolos. No es necesario estudiar la atenuación de la señal en la fibra óptica, pero sería útil saber por qué siempre hay pérdidas reales que se heredan a través de los nodos. No hay nada de malo en conocer cómo funcionan ciertos elementos a un nivel específico de abstracción y no es obligatorio desglosar todos los niveles cuando no hay abstracción en absoluto (te volverías loco).

Sin embargo, en su área, razonar a nivel de abstracción como ‘bueno, esto es una cosa que permite mostrar sitios web’ no es muy bueno. Las próximas conferencias estarán dedicadas a una revisión de las principales áreas con las que un administrador de sistemas debe lidiar en un trabajo a niveles más bajos de abstracción. Intentaré limitar la cantidad de conocimientos revisados al mínimo nivel de abstracción.

Los 10 mandamientos de la administración de sistemas

Así que hemos aprendido los cuatro pilares y la base. ¿Podemos empezar a resolver problemas? Aún no. Antes de eso, es recomendable familiarizarse con las llamadas "mejores prácticas" y las reglas de buena conducta. Sin ellas, hay una probabilidad de que causen más daño que beneficio. Empecemos:

1. Algunos de mis colegas creen que la primera regla es "no hacer daño". Pero yo tiendo a no estar de acuerdo. Cuando intentas no hacer daño, tampoco puedes hacer nada; hay demasiadas acciones que son potencialmente destructivas. Considero que la regla más importante es - "haz un respaldo". Incluso si causas daño, siempre podrás retroceder, y no todo será tan malo.

   Siempre debes hacer respaldos cuando el tiempo y el espacio lo permitan. Debes respaldar aquello que vas a modificar y lo que corres el riesgo de perder en una acción potencialmente destructiva. Es recomendable verificar la integridad del respaldo y la presencia de todos los datos necesarios. No debes eliminar el respaldo inmediatamente después de verificarlo, a menos que necesites liberar espacio en el disco. Si es necesario liberar espacio, respáldalo en tu servidor personal y elimínalo una semana después.

2. La segunda regla más importante (que a menudo yo mismo infrinjo) es - "no ocultes". Si hiciste un respaldo, anota dónde, para que tus colegas no tengan que buscarlo. Si realizaste alguna acción no obvia o complicada, escríbelo: te irás a casa y el problema podría repetirse o surgir en otra persona y tu solución se encontrará por palabras clave. Incluso si haces algo que conoces bien, es posible que tus colegas no lo sepan.
3. No hay necesidad de explicar la tercera regla: "nunca hagas algo cuyas consecuencias no conozcas, no imagines o no entiendas". No copies comandos de Internet si no sabes lo que hacen, llama a man y estudia primero. No apliques soluciones listas si no puedes entender qué hacen. Reduce al mínimo absoluto la ejecución de código ofuscado. Si no tienes tiempo para entenderlo, estás haciendo algo mal y deberías familiarizarte con el siguiente punto.
4. "Prueba". Los nuevos scripts, herramientas, comandos y one-liners deben probarse en un entorno controlado y no en la máquina del cliente, si existe al menos un mínimo potencial para acciones destructivas. Incluso si has hecho una copia de seguridad (y deberías hacerlo), el tiempo de inactividad no es algo agradable. Dedica un servidor/virtual o chroot para este propósito y prueba allí. ¿Nada se rompió? Entonces puedes lanzarlo en producción.

   
   

5. «Controla». Minimiza todas las operaciones que no controlas. Una dependencia problemática de un paquete puede arrastrar medio sistema, y el flag -y para yum remove te brinda la oportunidad de practicar tus habilidades de recuperación del sistema desde cero. Si no hay alternativas fuera de control para la acción, pasa al siguiente punto y asegúrate de tener una copia de seguridad lista.
6. «Verifica». Verifica las consecuencias de tus acciones y si es necesario volver a una copia de seguridad. Comprueba si realmente se resolvió el problema. Verifica si el error se reproduce y en qué condiciones. Asegúrate de saber qué puedes romper con tus acciones. Confiar en nuestro trabajo es excesivo, pero verificar nunca está de más.
7. «Comunica». Si no puedes resolver el problema, pregunta a tus compañeros si han enfrentado algo similar. Si quieres aplicar una solución controvertida, conoce la opinión de tus colegas. Quizás ellos ofrezcan una mejor solución. Si no estás seguro de tus acciones, discútelas con tus colegas. Incluso si es tu área de especialización, una perspectiva fresca puede aclarar mucho. No tengas miedo de lo que no sabes. Es mejor hacer una pregunta tonta, parecer un tonto y obtener una respuesta, que no hacer la pregunta, no recibir respuesta y quedarte en la ignorancia.
8. «No niegues ayuda sin fundamento». Este punto es el reverso del anterior. Si te hacen una pregunta tonta, aclara y explica. Si piden algo que no se puede lograr, explica por qué no es posible y ofrece alternativas. Si no tienes tiempo (realmente no tienes tiempo, no deseo) — di que tienes una tarea urgente, pero lo abordarás más tarde. Si tus colegas no tienen tareas urgentes, sugiere que se acerquen a ellos y delega la pregunta.
9. «Dame tu feedback». ¿Alguno de tus colegas ha empezado a aplicar una nueva metodología o un nuevo script, y tú te encuentras con las consecuencias negativas de esa decisión? Infórmalo. Quizás el problema se resuelva con tres líneas de código o cinco minutos de ajustes a la metodología. ¿Te has encontrado con un error en el software? Reporta el error. Si se puede reproducir o no es necesario reproducirlo, es probable que se solucione. Expresa deseos, sugerencias y críticas constructivas, somete cuestiones a discusión si consideras que son relevantes.
10. «Pide retroalimentación». Todos somos imperfectos, al igual que nuestras decisiones, y la mejor forma de verificar la validez de tu solución es llevarla a discusión. Si has optimizado algo para un cliente, pídeles que supervisen el funcionamiento; puede que el «cuello de botella» del sistema no esté donde buscabas. Si has escrito un script útil, muéstralo a tus colegas; puede que encuentren una forma de mejorarlo.

Si aplicas estas prácticas de manera constante en tu trabajo, gran parte de los problemas dejarán de serlo: no solo reducirás al mínimo tus errores y fracasos, sino que también tendrás la oportunidad de corregir errores (con copias de seguridad y colegas que te sugerirán hacer copias de seguridad). A partir de ahí, solo quedan detalles técnicos, en los cuales, como se sabe, está el verdadero desafío.

Las herramientas principales con las que tendrás que trabajar más del 50% del tiempo son grep y vim. ¿Qué puede ser más simple? Búsqueda de texto y edición de texto. Sin embargo, tanto grep como vim son potentes herramientas multifuncionales que permiten buscar y editar texto de manera eficiente. Si algún bloc de notas de Windows te permite simplemente escribir/eliminar una línea, en vim puedes hacer casi cualquier cosa con el texto. No lo crees, llama desde la terminal al comando vimtutor y comienza a aprender. En cuanto a grep, su principal fortaleza radica en las expresiones regulares. Sí, la herramienta permite establecer condiciones de búsqueda y datos de salida de forma bastante flexible, pero sin RegExp no tiene mucho sentido. ¡Y es necesario conocer expresiones regulares! Al menos a nivel básico. Para empezar, te recomendaría que mires esto. videos, se analizan los fundamentos de las expresiones regulares y su uso conjunto con grep. Ah, sí, al combinarlos con vim, obtienes el PODER MÁXIMO para hacer con el texto cosas que requieren etiquetas +18.

De los restantes 50%, el 40% corresponde al paquete de herramientas coreutils. Para coreutils, puedes ver la lista en Wikipedia, y el manual de toda la lista está en el sitio GNU. Lo que no está cubierto por este conjunto se encuentra en las utilidades POSIX. No es necesario memorizarlo con todas las claves de memoria, pero al menos es útil saber qué pueden hacer las herramientas principales. No tendrás que inventar la rueda con parches. Una vez, tuve que reemplazar saltos de línea por espacios en la salida de alguna utilidad, y mi cerebro enfermo creó la construcción sed ':a;N;$!ba;s/n/ /g', un colega que se acercó me alejó con una escoba de la consola, y luego resolvió la tarea escribiendo tr 'n' ' '.

Te aconsejaría recordar qué hace cada herramienta individual y las opciones para los comandos más utilizados; para todo lo demás, está man. No dudes en llamar a man si tienes alguna duda. Y asegúrate de leer man sobre el mismo man, ya que contiene información importante sobre lo que encontrarás.

Conociendo estas herramientas, podrás resolver de manera eficaz una gran parte de los problemas que enfrentes en la práctica. En las siguientes lecciones, abordaremos cuándo aplicar estas herramientas y las estructuras de los principales servicios y aplicaciones a los que se aplican.

Estuvo con ustedes el administrador de sistemas de FirstVDS, Kirill Tsvetkov.

Fuente: habr.com