# Todo lo que necesitas saber de DevOps en 20 minutos

- Channel: [BettaTech](https://www.youtube.com/channel/UCSf6S_PAhXsqGMTPDiKgdRg)
- Published: 2026-04-12
- Source video: [Watch on YouTube](https://youtube.com/watch?v=UTNbLoZCOgM)
- Read on ReadTube: https://www.read.tube/p/videos/UTNbLoZCOgM
- Language: Original (source language)

## Summary

**Qué es DevOps y por qué no es un puesto**

DevOps no es un cargo laboral, sino una cultura enfocada en romper silos de responsabilidad y fomentar la colaboración mediante la automatización y la mejora continua de procesos. Para lograrlo, es fundamental implementar una cultura sin culpa, apoyarse en la infraestructura como código y utilizar herramientas avanzadas de monitoreo y observabilidad para garantizar la disponibilidad del sistema.

DevOps no es un rol, sino una cultura enfocada en eliminar silos de responsabilidad donde todo el equipo es responsable del ciclo de vida del software, desde la escritura hasta el despliegue. Para evitar la toxicidad al asumir esta responsabilidad, es indispensable adoptar una cultura sin culpa, que prioriza la mejora de los procesos y las salvaguardas técnicas sobre la señalización personal.

- Integración y despliegue continuo: Implementar procesos automáticos y seguros para integrar cambios y enviarlos a producción frecuentemente.
- Infraestructura como código: Definir y gestionar los recursos tecnológicos mediante código para permitir pruebas y despliegues automáticos.
- Shift Left: Mover las pruebas y el análisis de calidad al inicio del desarrollo para reducir costes y detectar errores tempranamente.
- Observabilidad vs Monitoreo: Utilizar monitoreo para métricas predecibles y observabilidad para diagnosticar problemas desconocidos mediante logs, métricas y trazas.
- Gestión de disponibilidad: Definir indicadores internos (SLI, SLO) y contratos de servicio externos (SLA) para equilibrar la fiabilidad técnica con el impacto económico.

## Article

Hay una idea que está completamente extendida en el mundo de la tecnología y es que DevOps es un puesto de trabajo, pero la realidad es que esta forma de pensar es la que está haciendo que muchos equipos tengan los mismos problemas una y otra vez. En este artículo te quiero explicar lo que es la cultura de DevOps de verdad, cómo funciona en equipos reales, por qué muchas empresas lo acaban aplicando mal y cómo algunos conceptos como, por ejemplo, observabilidad o monitoreo te pueden cambiar la forma en la que analizas y operas los sistemas en los que trabajas.

#### DevOps: Cultura, no puesto

He dicho que DevOps es una cultura, no un puesto. A pesar de que hay un montón de empresas que realmente están buscando gente con perfil de DevOps, esta no era la intención original cuando se presentó este cambio de paradigma. La intención original era que DevOps fuera una cultura que se aplicara al equipo al completo, no que hubiera un perfil específico que fuera el experto.

Esta cultura tiene una serie de objetivos. El principal es romper los hilos de responsabilidad. Si tienes dos equipos de desarrollo, uno dedicado al frontend y otro dedicado al backend, y tras lanzar algo nuevo a producción, de golpe hay usuarios que se quejan porque algo ha dejado de funcionar, el equipo de backend investiga, detecta que ha sido por un cambio del equipo de frontend, y el equipo de backend se lava las manos diciendo que no es su culpa, o viceversa. Ahí empiezan las discusiones, la toxicidad y el ver a tus propios compañeros como enemigos. Eso es lo que hace que la mayoría de equipos de tecnología acaben teniendo muchos problemas a nivel de velocidad y calidad en la entrega.

Lo que buscas precisamente con la cultura de DevOps es romper esta barrera y hacer que todos los equipos sean responsables desde inicio hasta fin de las cosas que realizan. Yo siempre uso la misma frase cuando intento explicar DevOps a la gente que entra a trabajar conmigo: **si tú escribes el código, tú te encargas de mantenerlo y desplegarlo.** Es responsabilidad nuestra cada una de las líneas de código que generamos.

##### Blameless Culture (Cultura sin culpa)

Si simplemente implementas DevOps con esta mentalidad, puedes acabar pecando de señalar con el dedo cuando algo falla. Si todos somos responsables de las líneas de código que hacemos, se puede generar toxicidad y juegos de poder. Es por ello que la cultura de DevOps no puede existir si no tienes también lo que se conoce como la *Blameless Culture* o la cultura sin culpa.

Lo que buscas en esta cultura no es ignorar las responsabilidades de los equipos, sino señalar otra parte. En vez de señalar a la persona, señalas al proceso:

* **No es:** ¿Por qué este desarrollador hizo ese `if` o por qué no testeó?
* **Es:** ¿Cómo es posible que el código que no estaba testeado haya llegado a producción? ¿En qué parte del sistema se nos ha colado este error?

Estás todo el rato culpando al proceso y queriéndolo hacer lo más robusto posible. Esas salvaguardas pueden ser 1000 cosas: *PR reviews* con tus compañeros, tests automatizados, controles de calidad. Buscas que el proceso sea el que proteja la calidad del código.

Para obtener todo esto, necesitas una serie de herramientas, una serie de inversión. Es por ello que DevOps también tiene como uno de sus pilares la automatización. Tener los despliegues automatizados y procesos sin depender de una persona humana es clave.

--- 

*Nota: La mayoría de perfiles que se contratan como "DevOps" son realmente perfiles de SRE (Site Reliability Engineers). Son parte del equipo tecnológico, pero su especialidad es, por ejemplo, instalar, gestionar y mantener herramientas de monitoreo. Eso no implica que esos perfiles sean los únicos que han de hacer DevOps; la cultura tiene que estar expandida a todo el equipo.*

--- 

#### Prácticas Clave

##### 1. Integración Continua (CI) y Despliegue Continuo (CD)

*   **Integración Continua:** Significa que yo pueda colocar código en el que he trabajado en la rama principal de una forma automática y segura. Implica tener tests de integración, tests automatizados y *pipelines* (como GitHub Actions) que aseguren que el código se integra con seguridad.
*   **Despliegue Continuo:** Es la parte que nos coloca ese código en manos de los usuarios. La aspiración es que sea tan continuo que ni siquiera te des cuenta de cuándo está ocurriendo, desplegando 10, 100 o 1000 veces al día.

##### 2. Infraestructura como Código (IaC)

En vez de entrar manualmente a un proveedor cloud para levantar un servidor, podemos definir la infraestructura mediante funciones en código (con TypeScript, Go o Terraform). Esto permite que la infraestructura sea testeable y automatizable dentro de la misma *pipeline*.

##### 3. Shift Left

Todo esto permite mover el análisis de calidad de mi producto lo más a la izquierda posible. Si detectas los errores más pronto, son mucho más baratos de arreglar.

#### Monitoreo vs. Observabilidad

*   **Monitoreo:** Es la capacidad que tiene tu sistema de responderte a preguntas que ya conoces (ej. ¿cuánta CPU está consumiendo un servidor?). Se gestiona con *dashboards* para métricas previstas.
*   **Observabilidad:** Necesitas contestar preguntas que no habías previsto cuando sucede un desastre. Necesitas poder interrogar a tu sistema de forma sencilla.

Para lograr una buena observabilidad necesitas tres pilares:

1.  **Logs:** Deben considerarse eventos inmutables contra los que hacer *queries*. Se recomienda usar *canonical logs*: cada petición escribe una sola línea estructurada (ej. JSON) que incluya usuario, función, *query* y tiempo de ejecución.
2.  **Métricas:** Datos cuantificables (ej. peticiones por segundo) que permiten enlazar causas con efectos.
3.  **Trazas:** En sistemas distribuidos, sirven para vincular el camino completo de una petición desde su origen hasta su final.

Herramientas comunes: `OpenTelemetry`, `Prometheus`, el stack ELK (`ElasticSearch`, `Kibana`, `Logstash`), o `Cloudwatch` si estás en AWS.

#### Disponibilidad y Negocio

La disponibilidad se mide en "nueves":

| Disponibilidad | Tiempo de caída permitido al año |
| :--- | :--- |
| 99% (2 nueves) | 3,65 días |
| 99,9% (3 nueves) | 8,7 horas |
| 99,99% (4 nueves) | 52 minutos |

Cada nueve extra requiere un esfuerzo técnico, redundancia y una inversión económica mayor. En las empresas, esto se gestiona mediante:

*   **SLI (Service Level Indicator):** Las métricas que monitorizas (latencia, errores).
*   **SLO (Service Level Objective):** Tus objetivos internos (a qué aspiras).
*   **SLA (Service Level Agreement):** El contrato con el cliente. Lo que prometes entregar (suele ser más conservador que el SLO para tener un margen de seguridad).

Para aprender más sobre esto, te recomiendo el libro *Site Reliability Engineering*, que es gratuito en su versión online.