Lo que sigue debajo es todo lo que mi mamá me inculcó desde muy chiquito, o lo que me gusta llamar: las 20 leyes del sysadmineo que mi vieja me inculcó desde pequeño y me trajeron hasta acá.
- El método noseasunpelotudo de estimación de tiempo.
Cuando alguien pregunta cuánto tiempo tomará algo, no seas un pelotudo, siempre dobla tu estimación. Esto te da espacio para respirar y corregir errores sin presión, porque, como todos sabemos, en la informática, las cosas rara vez salen según lo planeado y lo que parece el atajo suele ser en realidad el camino más largo entre dos puntos. - Viernes de sólo lectura.
Los viernes son sagrados. Read-Only hasta la muerte. Evita cualquier cambio que pueda afectar tu entorno de producción en absoluto. La gente está menos disponible para ayudarte si surge un problema, y podrías terminar trabajando el fin de semana, como todos tus putos fines de semana, pero a diferencia de estos últimos, en algo que no tenías previsto atender. - Nombres con significado.
Jamás nombres un archivo o servidor con ‘test’, ‘tmp’, ‘dev’ o ‘borrar’ a menos que realmente esté destinado para pruebas y podría ser eliminado sin consecuencias. Todos tienen un «entorno de pruebas», pero solo algunos pocos elegidos tienen un «entorno de producción».
O como dice la ley de Murpy: si se podía borrar, alguien te lo va a borrar, y vas a cagar fuego y del bueno. - No es por los DNS; No puede ser por los DNS; Eran los DNS.
La regla infalible del sysadmin: cuando algo sale mal, revisá siempre primero los DNS. Por inverosímil que parezca. Por improbable que parezca. Por mucho que creas entender cómo funcionan los DNS. - Cuidado con las POCs que se convierten en producción.
Si algo comienza como una prueba de concepto (POC) y de repente se convierte en producción, asegúrate de gestionar las expectativas. Una POC siempre debe ser solo eso, una POC. - Establece Límites.
No seas elpelotudotécnico de aplicaciones para personas que no tienen ni idea de las tecnologías subyacentes que las hacen funcionar. Cada chancho para su rancho. Si algo te excede que lo arregle otro. Que escale hasta el que entiende realmente y que se sepa que te excedió. - Buscá a los que parecen pero no son.
Si hay alguien pasa todo el puto el día hablando con usuarios, pero no hace el trabajo real de solucionar problemas: te está cagando. Documentá todo su accionar. Vas a necesitar pruebas. - Nunca confíes del todo en lo que dice el usuario.
Cuando un usuario dice que «todo el sistema está caído y nadie puede trabajar, no anda nada, es urgente», verificá antes de correr. Por lo general es que solamente no le anda internet, MS Word, o la calculadora de Windows. - Siempre tenés que tener un plan de respaldo.
Si una implementación, un upgrade, un downgrade o una migración comienza a desmoronarse, asegúrate de tener un plan para volver al sistema anterior. Siempre tenés que tener claro cómo volver al estado original cuando algo que no se suponía que salga mal, salga mal.
Si no tenés un plan para hacer rollback y vas a dar el salto de fé: noseasunpelotudo, posponelo hasta que se te ocurra cómo tener un plan. - Numerá los pasos para esos usuarios que necesitan instrucciones.
Si estás brindando soporte a alguien que necesita seguir instrucciones, numerá los pasos. Cuando inevitablemente no sigan las instrucciones porque ni te leyeron en el mail original que les enviaste, preguntales en qué paso se quedaron atascados. El 90% del tiempo nunca más volverás a escuchar de ellos y podrás cerrar el ticket por inactividad.
- Antes del cambio, preparación.
Si vas a cambiar algo en un sistema, tenés que tener una imagen CLARÍSIMA de lo que ocurrirá antes de tocarlo. También debes saber, no adivinar, SABER EN SERIO: cuál será el impacto en los usuarios y clientes del sistema.
Si no podés anticipar los efectos colaterales directos e indirectos: no sos la persona adecuada para realizarlo. - Documentá todo.
Armate de un conocimiento centralizado coherente en una base de datos de cualquier índole. El primer artículo debe ser sobre cómo formatear todos los futuros artículos para mantener la consistencia. - La regla del y si mañana sos pollo.
Ninguna persona debe tener conocimiento exclusivo sobre un sistema o mecanismo. La matriz de reemplazo debe contener siempre a gente capaz de hacer lo mismo que ese que mañana no va a poder venir, porque lo pisó un tren. Clave para la continuidad. - Sobre la vitamina D.
Ser sysadmin es como montar en bicicleta… excepto que la bicicleta está en llamas, tú estás en llamas, todo está en llamas y estás en el infierno.
De esas llamas es que los que amamos la profesión obtenemos nuestra vitamina D. No nos bronceamos, nos rostizamos en problemas todos de misión crítica. - Confiá, pero verificá.
Trata a todos con respeto y dignidad, pero siempre verifica la información. El mundo está lleno de idiotas bienintencionados. - ¿Reiniciaste? ¿Seguro? ¿Seguro seguro? ¿Seguro seguro seguro?.
Odio profundamente a fast-boot. Mi vida sería infinitamente mejor sin fast boot. - Revisá los logs
Si. Flor de paja. Está todo ahí, a tu alcance, en los logs. Nada más tenés que esforzarte un poco. - Configurá y ajustá las alertas
Configura las alertas según tus necesidades. Todo tiene la capacidad de enviarte alertas. No siempre necesitás alertas y por lo general menos es más. Cuidado con la fatiga de alertas. Menos alertas enfocadas mata ametralladora de notificaciones. - No serruches la rama en la que estás sentado.
Siempre que hagas una actualización o cambio, tenés que estar del lado del tronco y no del lado de la rama. Si algo sale mal, tenés que tener un sistema o método para no quedarte fuera. Un método que me dió buenos resultados siempre por ejemplo: programar para dentro de dos minutos un reboot de todo el servidor o restart de un servicio específico justo antes de ejecutar un comando que testeará un cambio de configuración no persistente pero que podría dejarme sin acceso.
Si llegaste hasta acá habrás notado que puse 20 leyes pero son 19.
La número 20 es: no creas todo lo que está en internet. No siempre es verdad.
Y por último: con esta concluyo la serie. Este post es mi tercer experimento, tomé un borrador pendiente de publicar y se lo pasé a CHAT GPT. Arriba pueden apreciar el resultado. Llegó el futuro, damas y caballeros.
