I run my home's infrastructure like production, rebuild machines from the firmware up, and write down what broke - including when it was me.
Each section below is a real system I built or maintain, written up the way I would hand it to a teammate: what the problem was, what I measured, what I ruled out, and what is still open. Every number on these pages came from the machine, not from memory.
Every case on this site started with a measurement, not a configuration change. Several of them ended up proving me wrong, and that is a result too.
A summary number hides its parts. Splitting defects by hours, or a bed error into tilt and residual, turned an expensive purchase into a free adjustment more than once.
An "ok" means a message was accepted. A kill switch is only tested by taking the tunnel down; a saved setting is only real once I read it back.
Disks by world-wide name and serial, firmware by the build timestamp the machine reports. A name that changes between reboots identifies nothing.
Routing, compute and storage live on different hardware on purpose. It is the principle that has most often kept one problem from becoming two.
Wrong hypotheses stay in the documentation next to the data that killed them. Those are the entries I actually re-read.
A shared trunk is a hydraulic bottleneck, RAID parity is spare thread on a bolt, a warped plate is not fixed by shimming. The analogy is how I decide between an adjustment and a replacement.
Each project ends with what is still open, ordered by what it costs if it fails - not by how easy it is to close.
I'm looking for a summer internship or co-op in IT infrastructure, networking or systems while I finish my degree. The resume below leaves out my phone number; the full version, and detailed operational documentation for any of these systems, are available on request.
imjoshuagarcia1212@gmail.com
Opero la infraestructura de mi casa como si fuera producción, reconstruyo máquinas desde el firmware y documento lo que se rompió, incluso cuando el error fue mío.
Cada sección es un sistema real que construí o mantengo, escrito como se lo entregaría a un compañero de equipo: cuál era el problema, qué medí, qué descarté y qué sigue abierto. Cada número de estas páginas salió de la máquina, no de la memoria.
Cada caso de este sitio empezó con una medición, no con un cambio de configuración. Varios terminaron demostrando que yo estaba equivocado, y eso también es un resultado.
Un número resumen esconde sus partes. Dividir defectos entre horas, o un error de cama en inclinación y residuo, convirtió más de una vez una compra cara en un ajuste gratis.
Un "ok" significa que el mensaje se aceptó. Un kill switch solo se prueba tumbando el túnel; un ajuste guardado solo es real cuando lo leo de vuelta.
Discos por su WWN y número de serie, firmware por la fecha de compilación que reporta la máquina. Un nombre que cambia entre reinicios no identifica nada.
Enrutamiento, cómputo y almacenamiento viven en hardware distinto a propósito. Es el principio que más veces ha evitado que un problema se convierta en dos.
Las hipótesis equivocadas se quedan en la documentación junto a los datos que las descartaron. Son las entradas que de verdad vuelvo a leer.
Un enlace troncal compartido es un cuello de botella hidráulico, la paridad de un arreglo son hilos de rosca de reserva, una placa pandeada no se arregla con cuñas. La analogía es cómo decido entre ajustar y reemplazar.
Cada proyecto termina con lo que sigue abierto, ordenado por lo que cuesta si falla, no por lo fácil que es cerrarlo.
Busco una práctica de verano o co-op en infraestructura de IT, redes o sistemas mientras termino mi bachillerato. El resumé de abajo no incluye mi teléfono; la versión completa y la documentación operativa detallada de cualquiera de estos sistemas están disponibles a solicitud.
imjoshuagarcia1212@gmail.com