Construir un sistema y operarlo son oficios distintos. Hacemos los dos, y eso se nota en cómo construimos.
Operamos ADN Vortex todos los días del año. Sabemos lo que es recibir una alerta a las tres de la mañana y lo que cuesta no haber puesto el monitoreo correcto seis meses antes.
Ese conocimiento es el que aplicamos cuando nos encargamos de la infraestructura de un cliente: no diseñamos para la demo, diseñamos para el día en que algo falle.
Una alerta que no exige acción es ruido que entrena al equipo a ignorar el tablero. Configuramos pocas alertas, cada una con un procedimiento asociado.
Nada de servidores configurados a mano que nadie se atreve a tocar. Si no está en código, no existe: es la única forma de recuperar con rapidez.
Después de cada incidente, un análisis escrito de qué pasó y qué se cambia. El objetivo es que no se repita, no encontrar al responsable.
La mayoría de los proyectos que fracasan no fracasan por el código: fracasan porque nadie acordó qué problema se estaba resolviendo.
Ver →La mayoría de las iniciativas de datos mueren en el piloto. Normalmente no por el modelo, sino porque nadie resolvió de dónde salen los datos ni quién mantiene el resultado.
Ver →Construimos sistemas que otra gente va a mantener. Eso cambia cómo se escriben.
Ver →Diagnóstico inicial sin costo. Respondemos con un alcance concreto, con costo y fecha.