Todo lo que sé de sysadminear lo aprendí de mi mamá

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á.



  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. Establece Límites.
    No seas el pelotudo té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ó.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

  13. 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.

  14. 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.

  15. Confiá, pero verificá.
    Trata a todos con respeto y dignidad, pero siempre verifica la información. El mundo está lleno de idiotas bienintencionados.

  16. ¿Reiniciaste? ¿Seguro? ¿Seguro seguro? ¿Seguro seguro seguro?.
    Odio profundamente a fast-boot. Mi vida sería infinitamente mejor sin fast boot.

  17. 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.

  18. 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.

  19. 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.

Puto el que sysadminea y puto el que hace trampa.

 

Cheatsheet: como convertirte en el seasoned sysadmin que siempre soñaste.

 

Ese, el que gana poco trabajando para una multinacional de medio pelo para arriba y únicamente produce vitamina D cuando la luz de su display le pega en la palma de las manos. Ese que nunca una mujer podría encontrar atractivo y que prefiere un servidor a un partido de fútbol.

Como convertirte en ese sysadmin al que los demás sysadmincitos junior miran desde abajo. Ese veterano de mil guerras con el rostro desfigurado por cicatrices, ese Rambo del Bash que te hace indestructible ahora, pero que cuando te jubiles te habrá dejado el cerebro a la miseria. Ese que no necesita recurrir nunca a stackoverflow por que se sabe el comando de memoria.

 

Ese.

 

La que sigue es únicamente una lista orientativa. Es esperable que todo aquel que busque iniciarse en el milenario y mal apreciado arte del sysadmineo linuxero de mierda se las apañe solo y no venga a este post a preguntar pelotudeces. Es decir: si querés ver hasta donde te la bancás, que tan grande la tenés, que tanto más que tus pares sabés o que tan mejor sos tomá, seguí esta lista al pié de la letra. No avances al paso siguiente hasta no haber completado el inmediato anterior por que es una guía que se sigue de forma secuencial.
Cuando hayas terminado, el sysadmineo será tu Kung Fu y podrás salir airoso de prácticamente cualquier situación en la que te encuentres indistintamente el grado de dificultad. Si te la bancás, seguí leyendo.

 

Algo así vas a poder hacer cuando termines de seguir mi guía de 20 sencillos pasos.

Sigue leyendo

De la futilidad del contenido que generamos para internet los que escribimos cuando estamos al pedo, de cuando nos morimos y de como la tecnología de blockchains podría la solución al puto problema.

Una cuestión no menor que me aqueja desde que empecé a querer este pedacito de papel virtual en el cual fuí plasmando mis divagues a lo largo de todos estos años es: Qué va a pasar con toda esta cantidad de información cuando ya no esté mas para administrarla? Léase: cuando me haya muerto o alguna cosa peor, tipo quedar parapléjico o ciego y manco a la misma vez. Todas cosas altamente probables si las comparamos con las chances que uno tiene de –por ejemplo-, ganarse la lotería o tropezar y quebrarse el tabique nasal contra las tetas de miss mundo.

 

BlockChain: la tecnología que va a permitir que este blog algún día, exista para siempre.

 

Mentiría si dijera que me llena de orgullo. Posiblemente todo lo contrario. Uno no se enorgullece de lo pelotudo que era cuando era un pendejo pelotudo y con el hilachento me pasa algo parecido. De vez en cuando leo algún post viejo que escribí hace años y se me cae la cara de vergüenza, pero es así: El fin último de la vida es no morirse y en el medio crecer y mejorarnos para morirnos mas tarde que los que no crecieron ni se mejoraron y junto con mi crecimiento como persona este blog ha ido creciendo y mejorando de igual manera en lo que a mis estándares concierne y planeo que no se muera.

 

Entonces, como que le fuí tomando cariño. No sabía por qué ni para qué, ni todavía lo tengo demasiado claro o decidido. Solo quisiera que perdure.

 

 

Nada es gratis. Las diversas tecnologías que hacen funcionar a este blog me cuestan dinero real (El servidor, el nombre de dominio, etc) y otras que no me cuestan dinero real podrían y sin duda van a dejar de existir en algún momento. Cloudflare por ejemplo, sin el cual la pequeñísima instancia de Amazon que hace funcionar este blog no aguantaría parada mas de dos días consecutivos o el mismo WordPress, podría y estoy seguro va algún día a convertirse en obsoleto, y si no me creen acuerdense de Geocities. Sigue leyendo