Porque ahora no se puede usar para apagar un incendio
Deformación profesional: cuando el trabajo forma malos hábitos
Ya escribí que en el ámbito IT, con cientos de cambios diarios, no son los hábitos domésticos los que determinan el enfoque al trabajo, sino lo contrario: el trabajo nos forma el hábito de resolver problemas de inmediato, a menudo sin un análisis adecuado de las consecuencias.
He encontrado para usted varios ejemplos de cómo las personas caen en la tentación del resultado inmediato, como en el caso de compras impulsivas. ¡Desgraciados! En el momento del pedido, pensaron que comprar con un solo clic era el único paso para resolver el problema.
¿Quién lo hizo?Imagina que los CTO y PM de grandes empresas actúan de la misma manera. Encargan a las equipos DevOps “soluciones de emergencia”. Al recibir la esperada “caja” con las últimas tecnologías (Apache Kafka, almacenamiento objeto S3, base de datos particionada, búsqueda semántica), ni siquiera descubren la desagradable verdad: el producto no viene con instrucciones de instalación, configuración y operación. No hay scripts de despliegue, ni posibilidad de escalabilidad, monitoreo de rendimiento. Y lo más importante: nadie advirtió al equipo DevOps de que estas tecnologías incluso se implementarían.
Transcurridos tres meses desde el pedido, en lugar de alivio esperado, el líder se enfrenta a un nuevo círculo de problemas. Su decepción puede expresarse así: «Ha llegado la caja… pero tras tres meses de entrega, olvidé por qué la había pedido». La búsqueda de victorias rápidas se convierte en caos operativo, y la falta de planificación estratégica convierte a las tecnologías en fuentes de problemas interminables.## Necesitamos Kafka para el próximo lanzamiento
Alguien de los tech leads leyó un artículo en Habr sobre «transmisión de eventos en tiempo real», asintió y dijo que necesitamos Kafka. Sin solicitar propuestas. Sin revisar la arquitectura. Sin participación de DevOps. ¿Familiar?
Sí, Kafka con código abierto. Sí, se escala. Pero pregunte a cualquier equipo que la haya operado en clusters: la madurez de Kafka no es lineal — es una función escalonada.
- 0–6 meses: «¡Todo funciona!» — Desbalance oculto de particiones, carga desigual en los brokers, demora no controlada
- 6–12 meses: «¿Por qué aumentan las demoras?» — Rebalanceo manual, apagado de incendios, responsabilidad fragmentada
- 12+ meses: «¿Quién se encarga de esto? ¿Cómo lo apagamos incluso?» — «Nacimiento de zombis» con costos no considerados de soporte externo
Sin automatización, observabilidad y gestión del ciclo de vida de toda la ecosistema Kafka, no obtenemos flujos de datos, sino flujos de alertas en Telegram.## Almacenamiento compatible con S3? Genial. ¡Protejalo ahora!
El equipo de Ozon dedicó meses a reestructurar Lusca sobre un almacenamiento compatible con S3 — no porque S3 sea complicado, sino porque implementar consistencia fuerte sobre una arquitectura basada en eventos, gestionar procesos en segundo plano de la base de datos y recuperar terabytes de datos son tareas que requieren profundidad técnica y tiempo.
Peor aún: si desplegáis esto dentro de contenedores sin higiene DevSecOps — sin escaneo de imágenes, sin almacenamiento de secretos, sin políticas de red L7 — no crearéis un almacenamiento. Crearéis un vector de vulnerabilidad y un \u003cdel\u003edesafío técnico\u003c/del\u003e.Incendio.
Fragmentación de la base de datos: punto de no retorno
Solo fragmentamos después de haber agotado el escalado vertical, la optimización de consultas, los niveles de caché y las réplicas para lectura. Este es el último recurso.
Hacerlo mal —obtendremos “shards calientes”, retrasos en la replicación y fallos en las consultas entre shards. Sobre todo si se elige incorrectamente la clave de fragmentación. Hacerlo sin herramientas DevOps para respaldo, monitoreo y redistribución —intercambiamos escalabilidad por resiliencia.
La cuestión es que no podremos “desfragmentar”. Una vez implementado este enfoque, no podremos retroceder sin un doloroso proceso de reingeniería.
Ahora viene el verdadero problema: no técnico, sino organizacional
Ningún benchmark dirá que el punto más débil en la moderna práctica DevOps no es la capacidad mental, la memoria o la velocidad de ejecución. Porque ese punto débil es la demora en la toma de decisiones debido a problemas con la roadmap.En algunas empresas no existe un roadmap de DevOps, y en otras ni siquiera existe. Porque la estrategia se entrega a las ventas demostrativas de soluciones de rodillas.
¿A qué lleva la cultura del ejecución reactiva?
- Después de que el CTO firme el pedido de desarrollo, los ingenieros en lugar de especificaciones reciben un empujón: “Automatiza esto en 100 servidores” — sin documentación, sin arquitectura clara, sin cobertura de pruebas.
- Y tres meses después: “¿Por qué es tan lento? ¿Y por qué lo construimos en primer lugar?”
Esto no es liderazgo. Es evasión de la responsabilidad.
Las equipos DevOps en organizaciones reactivas consumen buena voluntad, corriendo tras fantasmas en los logs y gráficos, corrigiendo lo que nunca diseñaron y defendiendo lo que nunca poseyeron.¿Y cuando algo falla? La culpa recae en las personas, no en los procesos. Esto no es DevOps, sino una “YasnoOps” de adivinos. Una cultura madura de DevOps no pregunta quién cometió el error. Pregunta qué provocó el fallo y corrige el sistema, no busca al culpable. En su caso, el sistema es la ausencia de una roadmap y la falta de involucramiento de DevOps en la fase de toma de decisiones.
Contexto ruso: velocidad frente a estabilidad
En los años 2023-2024, el mercado SaaS en Rusia creció hasta varios billones de rublos, pero no se trata de un mercado estable y predecible, sino de una sartén rápida. La carrera por parecer moderno destruye las bases necesarias para realmente ser moderno.Deberíamos movernos en la dirección establecida por GosTech: hacia el registro estandarizado, APIs certificadas, monitoreo, cumplimiento de los requisitos de la FSTEC y integridad de la cadena de suministro. Pero ¿cómo integrar estándares en una arquitectura construida con urgencia y decisiones impulsivas? ¿Cómo garantizar la seguridad si las equipos DevOps no estuvieron involucrados en el diseño?
Una empresa así aún considera la infraestructura como un tema secundario. Esto no es un fracaso de ingeniería. Es un fracaso en la gestión de expectativas.
¿Cómo cambiar esta situación?
La solución radica en cambiar la perspectiva:
- De “Construyamos esto ahora para venderlo” → “¿Estamos preparados para poseer esto en el corto plazo?”
- De velocidad en la implementación de funciones → a estabilidad de la plataforma
- De DevOps como equipo de emergencia → a DevOps como co-arquitectoLas grandes empresas han transitado este camino. Publican sus roadmaps. Postergan lanzamientos en aras de la estabilidad. Miden la operación lista, no solo las fechas de lanzamiento.
Entienden la sencilla verdad: la velocidad sin control no es flexibilidad. Es deriva. Y es especialmente inaceptable en el software corporativo, donde están en juego secretos estatales.
Para salir de la crisis, se requiere un cambio
- De la gestión reactiva al planificación proactiva — desarrollo de un roadmap DevOps, involucrar a todas las partes interesadas desde etapas tempranas.
- De ejecutores a socios estratégicos — reconocer al DevOps como parte esencial del desarrollo de productos.
- De implementaciones caóticas a transformación planificada — implementación gradual de tecnologías con pilotaje y descubrimiento iterativo de brechas.
- Y entonces, el botón “Comprar” dejará de ser presionado automáticamente
Porque en los entornos actuales, especialmente bajo condiciones de Gostech, ignorar la madurez operativa no es solo un riesgo, sino un error estratégico.