Una aplicación comienza siendo pequeña: un Droplet, un deploy manual, un dominio apuntando a la IP pública y esa agradable sensación de que “ya está en línea”. Algunas semanas después, llegan usuarios reales, alguien cambia una configuración directamente en el servidor, el disco empieza a llenarse, una clave SSH antigua sigue siendo válida y nadie sabe si el backup cubre los datos importantes.

Ese es el punto en el que la producción en DigitalOcean con Droplets deja de ser simplemente “crear una máquina” y pasa a convertirse en una operación continua. Poner un Droplet en línea es apenas el comienzo: los accesos, la exposición de red, las actualizaciones, la recuperación, el monitoreo y los costos deben convertirse en una rutina.

Esta guía es para quienes ya pueden crear un Droplet, pero quieren revisar una infraestructura existente con más seguridad, previsibilidad y control. El foco está en aplicaciones alojadas en Droplets. No profundizaremos en DigitalOcean Kubernetes, multicloud, migraciones entre proveedores ni en la configuración completa de frameworks específicos.

También es importante alinear una expectativa: un único Droplet puede estar bien protegido, monitoreado y ser recuperable. Sin embargo, continúa siendo un punto único de falla. El backup ayuda a recuperar; el firewall reduce la exposición; el monitoreo anticipa problemas. La alta disponibilidad exige decisiones arquitectónicas adicionales.

TL;DR

• Crear un Droplet es sencillo; operar producción exige una rutina.
• La simplicidad de DigitalOcean es una ventaja importante, pero no debe confundirse con ausencia de responsabilidad.
• DigitalOcean se encarga de la infraestructura física y de los servicios contratados; el sistema operativo, los accesos, la red, los datos, las actualizaciones y la aplicación continúan bajo responsabilidad del equipo.
• Comienza por lo básico que reduce riesgos: claves SSH individuales, usuario no root, mínimo privilegio, firewall restrictivo, backups probados y monitoreo.
• Los backups y los snapshots tienen objetivos diferentes: el backup forma parte de la recuperación recurrente; el snapshot es una captura puntual de un estado.
• Monitorea CPU, memoria, disco y red, pero complementa estas señales con logs y métricas de la aplicación.
• Organiza los recursos con nombres, tags y proyectos para evitar costos olvidados y dependencias invisibles.
• Automatiza gradualmente: los scripts sencillos, versionados y revisables ya son mejores que depender de la memoria de una persona.
• Usa el checklist del final como punto de partida, no como certificado de madurez.

---

Producción en DigitalOcean con Droplets: qué cambia después del primer deploy

Imagina una aplicación interna en un único Droplet: backend, base de datos local, archivos enviados por usuarios y deploy manual mediante SSH. Al principio, esto puede ser suficiente para validar la idea. Sin embargo, cuando la aplicación pasa a formar parte de la rutina de otras personas, algunos riesgos dejan de ser “detalles técnicos” y comienzan a afectar al servicio.

El cambio principal es mental: producción no es un estado, sino una práctica continua.

DigitalOcean simplifica la creación de infraestructura, pero eso no elimina el modelo de responsabilidad compartida. En la práctica:

• DigitalOcean opera la infraestructura física y los servicios contratados.
• El equipo usuario continúa siendo responsable del sistema operativo, los accesos, las reglas de red, las actualizaciones, los datos, el monitoreo y la configuración de la aplicación.

La documentación de DigitalOcean sobre la configuración recomendada de Droplets refuerza prácticas iniciales como el acceso seguro, el firewall y los usuarios no root. Usa esta documentación como referencia operativa, no solamente como un checklist de creación.

El error común es asumir que un Droplet recién creado ya está “listo para producción”. Está listo para recibir configuración. La diferencia parece pequeña, pero es como comprar un apartamento y creer que ya viene con una cerradura reforzada, un seguro, copias de llaves controladas y un plan de evacuación. Tal vez venga con paredes. El resto depende de ti.

Existe un trade-off importante: un único servidor es sencillo de operar, barato de entender y fácil de depurar. Por otro lado, ofrece menor tolerancia a fallas. Si el Droplet deja de estar disponible, si el disco se corrompe o si una actualización rompe el servicio, toda la aplicación puede detenerse.

Por lo tanto, protege bien ese Droplet, pero no confundas protección con alta disponibilidad.

---

Reducir la superficie de ataque: SSH, usuarios y actualizaciones

El acceso administrativo es una de las áreas donde pequeñas negligencias acumulan riesgos rápidamente. Si cualquier persona usa la misma clave, si el inicio de sesión mediante contraseña está abierto o si los usuarios antiguos permanecen activos, el equipo pierde trazabilidad y aumenta la posibilidad de un acceso indebido.

Una revisión práctica puede seguir este orden:

1. Revisar quién tiene acceso.
2. Eliminar las claves antiguas.
3. Garantizar usuarios nominales.
4. Evitar el inicio de sesión directo como root.
5. Desactivar el inicio de sesión mediante contraseña después de probar las claves.
6. Definir una rutina de actualización.

1. Usa claves SSH individuales

Riesgo: la autenticación mediante contraseña en SSH amplía la exposición a intentos automatizados de inicio de sesión. Las contraseñas compartidas o reutilizadas también dificultan saber quién accedió al servidor.

Recomendación: prioriza las claves SSH individuales, protegidas localmente, y evalúa desactivar la autenticación mediante contraseña. Siempre que sea posible, evita iniciar sesión directamente como root; usa usuarios nominales con sudo.

Por qué importa: las claves individuales permiten revocar el acceso de una persona sin afectar a todo el equipo. Los usuarios nominales mejoran la trazabilidad y reducen la dependencia de credenciales compartidas.

Un ejemplo mínimo para crear un usuario administrativo nominal:

bash sudo adduser ana sudo usermod -aG sudo ana

Después, agrega la clave pública de la persona al archivo authorized_keys:

bash sudo mkdir -p /home/ana/.ssh sudo nano /home/ana/.ssh/authorized_keys sudo chown -R ana:ana /home/ana/.ssh sudo chmod 700 /home/ana/.ssh sudo chmod 600 /home/ana/.ssh/authorized_keys

El nano anterior es solamente una forma sencilla de editar el archivo. En entornos más maduros, este paso debería automatizarse y versionarse para evitar cambios manuales sin revisión.

2. Desactiva la contraseña y el inicio de sesión directo como root con cuidado

Después de validar que el usuario puede acceder y utilizar sudo, revisa la configuración de SSH en /etc/ssh/sshd_config:

bash PasswordAuthentication no PermitRootLogin no

A continuación, reinicia el servicio SSH:

bash sudo systemctl restart ssh

Antes de cerrar la sesión actual, abre una nueva conexión y confirma que el acceso funciona. Esta comprobación evita una situación clásica: configurar la seguridad tan bien que ni siquiera tú puedes volver a entrar. La seguridad estilo “caja fuerte arrojada al mar” rara vez ayuda.

3. Revisa las cuentas y los privilegios

Riesgo: los usuarios antiguos, las claves olvidadas y los permisos excesivos crean puertas laterales. Aunque nadie tenga malas intenciones, las credenciales abandonadas pueden filtrarse o reutilizarse.

Recomendación: elimina los usuarios y las claves que ya no sean necesarios. Aplica el principio del mínimo privilegio: concede acceso administrativo solamente a quienes realmente lo necesiten.

Lista los usuarios del sistema:

bash cut -d: -f1 /etc/passwd

Este comando no decide por ti quién debe permanecer. El análisis debe considerar las cuentas de servicio, los usuarios del sistema operativo y los usuarios humanos.

Revisa también los archivos de claves autorizadas:

bash sudo find /home -name authorized_keys -print

Una rutina sencilla ayuda: en cada ciclo de mantenimiento, confirma quién todavía necesita acceso, qué claves siguen siendo válidas y quién tiene privilegios administrativos.

4. Define una frecuencia de actualización

En distribuciones basadas en Debian/Ubuntu, una actualización manual básica suele comenzar con:

bash sudo apt update sudo apt upgrade

El trade-off es real:

• Las actualizaciones automáticas reducen la ventana de exposición a vulnerabilidades conocidas.
• Las actualizaciones planificadas ofrecen más control y permiten realizar pruebas antes.
• Posponer indefinidamente las actualizaciones convierte la “estabilidad” en deuda operativa.

Para equipos pequeños, un enfoque intermedio suele funcionar bien: actualizaciones de seguridad frecuentes, una ventana de mantenimiento definida y un procedimiento de rollback cuando sea posible.

---

Red y firewall: permitir únicamente el tráfico necesario

El firewall no debe tratarse como un adorno del panel. Es una regla explícita de exposición: quién puede acceder a qué, mediante qué puerto y desde qué origen.

En producción, la pregunta habitual no debería ser “¿por qué bloquear?”, sino “¿por qué permitir?”.

1. Revisa los puertos públicos

Riesgo: los puertos abiertos innecesariamente exponen servicios internos, paneles administrativos, bases de datos, colas e interfaces de debug. Muchas veces esto ocurre durante una prueba rápida: alguien permite el acceso “temporalmente” y lo olvida.

Recomendación: mantén públicos solamente los puertos necesarios. Para las aplicaciones web, normalmente HTTP y HTTPS deben estar accesibles al público. SSH debe restringirse a IP conocidas, una VPN o un bastion host cuando la realidad del equipo lo permita.

Una aplicación web sencilla podría tener:

• 80/tcp y 443/tcp abiertos al público.
• 22/tcp restringido a IP administrativas o a una red confiable.
• La base de datos aceptando conexiones únicamente desde la red privada.
• Los paneles administrativos detrás de una autenticación adicional o de una red restringida.

La documentación de DigitalOcean sobre la configuración recomendada de Droplets también aborda la importancia del firewall en la configuración inicial. Si tu infraestructura creció de forma orgánica, vale la pena comparar el estado actual con estas recomendaciones.

Si usas doctl, comienza inventariando los Droplets y firewalls existentes:

bash doctl compute droplet list --format ID,Name,PublicIPv4,PrivateIPv4,Tags doctl compute firewall list

Para inspeccionar un firewall específico:

bash doctl compute firewall get <firewall-id>

Usa estos comandos como una revisión inicial. El cambio de reglas debe hacerse con cuidado, especialmente si estás conectado mediante SSH al propio servidor que será restringido.

Un riesgo común es permitir todos los puertos para “probar rápidamente” y olvidarlo. La prueba funciona, la aplicación se inicia, se celebra el deploy y el firewall se convierte en un colador bien documentado, pero por accidente.

2. Usa una VPC para el tráfico interno cuando tenga sentido

Riesgo: los componentes internos que se comunican mediante la IP pública aumentan la exposición y dificultan las reglas del firewall. Las bases de datos, las colas y los servicios auxiliares pueden terminar aceptando tráfico desde orígenes que no deberían.

Recomendación: usa una VPC para la comunicación entre recursos que no necesitan ser accesibles públicamente, como Droplets, bases de datos y servicios internos de la misma región cuando corresponda.

Valida:

1. Qué recursos necesitan comunicarse entre sí.
2. En qué región están.
3. A qué VPC pertenecen.
4. Si la aplicación utiliza la IP privada cuando corresponde.
5. Si las reglas del firewall permiten únicamente los orígenes necesarios.

La documentación sobre las buenas prácticas de VPC en DigitalOcean es una buena referencia para revisar este diseño.

El trade-off: una red privada mejora el aislamiento, pero no sustituye la autenticación, el cifrado adecuado ni las reglas de acceso de la aplicación y de la base de datos. Una VPC no es un permiso universal; es solamente un camino de red más controlado.

---

Recuperabilidad y disponibilidad: backups, restauración y límites de un único Droplet

Cuando todo funciona, el backup parece un costo. Cuando algo falla, el backup se convierte en la diferencia entre un incidente administrable y una reconstrucción improvisada.

Pero existe una confusión frecuente: un backup y un snapshot no son lo mismo.

1. Enumera lo que debe recuperarse

Riesgo: creer que el repositorio Git es un backup suficiente. Protege el código, pero no protege la base de datos local, los archivos enviados por usuarios, los secretos, las configuraciones manuales ni el estado del servidor.

Antes de elegir una herramienta, enumera:

• Los datos persistentes de la aplicación.
• Las configuraciones de infraestructura y deploy.
• Los archivos enviados por usuarios.
• Los datos de las bases de datos ejecutadas en el propio Droplet.
• Los secretos y las variables necesarias para restaurar el servicio, almacenados de forma segura.
• Las dependencias externas necesarias para que la aplicación vuelva a funcionar.

Esta lista evita una trampa común: tener un backup del servidor, pero olvidar que una parte crítica de los datos estaba en un volumen, directorio, bucket, base de datos local o configuración manual.

2. Distingue backup de snapshot

Recomendación: ten una estrategia explícita para recuperar los datos persistentes, la configuración y la aplicación. Usa backups administrados cuando tenga sentido y entiende el objetivo de los snapshots.

Los backups administrados ayudan a reducir el riesgo de pérdida después de fallas o errores humanos, pero debes entender su cobertura, retención y comportamiento. Consulta la documentación de DigitalOcean sobre los recursos y el comportamiento de los backups antes de depender de ellos en producción.

Los snapshots suelen ser útiles como una imagen puntual del estado de un Droplet. Por ejemplo, antes de realizar un cambio importante, puedes crear un snapshot para tener una referencia de ese momento. Sin embargo, esto no sustituye una rutina de backup con una retención adecuada, especialmente para datos que cambian con frecuencia.

Una forma práctica de pensarlo:

• Backup: protección recurrente para la recuperación.
• Snapshot: captura puntual para un cambio, una migración o una referencia de estado.

Ambos pueden formar parte de la estrategia, pero atienden necesidades diferentes.

3. Prueba la restauración antes del incidente

Riesgo: tener un backup, pero no haberlo restaurado nunca. Esto crea una falsa sensación de seguridad. Durante el incidente, el equipo descubre que falta una configuración, que el backup no incluía ciertos archivos o que el tiempo de recuperación es mayor de lo aceptable.

Haz un ejercicio sencillo:

1. Elige un backup reciente.
2. Restáuralo en un entorno separado.
3. Inicia la aplicación sin afectar producción.
4. Comprueba que los datos, archivos y configuraciones esenciales estén presentes.
5. Registra el tiempo empleado.
6. Anota los pasos manuales que deberían automatizarse o documentarse.

Dos preguntas ayudan a convertir el backup en una expectativa del negocio:

• RPO: ¿cuántos datos acepta perder el equipo?
• RTO: ¿cuánto tiempo acepta el equipo permanecer fuera de servicio?

No es necesario convertir esto en una disertación académica. Para una aplicación administrativa interna, quizá perder algunos minutos de datos sea aceptable; para un sistema crítico, quizá no lo sea. Lo importante es discutirlo de antemano.

El trade-off es directo: los backups más frecuentes y una retención mayor aumentan la capacidad de recuperación, pero también impactan en los costos. Por otro lado, ahorrar eliminando backups puede salir caro exactamente cuando el equipo menos tiempo tiene para improvisar.

Y vale la pena repetirlo: el backup mejora la recuperación, pero no impide la indisponibilidad durante una falla de un único Droplet. Si ese Droplet se detiene, la aplicación se detendrá con él hasta que algo sea restaurado, reemplazado o redirigido.

---

Observabilidad operativa: saber que existe un problema antes que el usuario

El monitoreo no sirve únicamente para saber si el servidor está “encendido”. Un Droplet puede responder al ping y, aun así, la aplicación estar lenta, sin espacio en disco o ser incapaz de procesar tareas.

La observabilidad práctica comienza con señales sencillas y accionables.

1. Monitorea señales útiles

Riesgo: percibir los problemas únicamente cuando los usuarios se quejan. Esto aumenta el tiempo de respuesta y suele llevar a diagnósticos apresurados.

Recomendación: monitorea CPU, memoria, disco y tráfico de red. Además, complementa las métricas de infraestructura con logs y métricas de la aplicación.

Un panel mínimo puede acompañar:

• Uso de CPU.
• Memoria disponible.
• Espacio en disco.
• Tráfico de red.
• Estado de los procesos principales.
• Logs de la aplicación y del servidor web.
• Métricas específicas de la aplicación, cuando existan.

Un ejemplo: el crecimiento continuo del disco puede indicar una retención excesiva de logs, una falla en la rotación o una acumulación de archivos temporales. Si nadie monitorea el disco, el equipo solo lo descubre cuando la base de datos deja de escribir o el deploy falla.

Los comandos locales ayudan en investigaciones puntuales:

bash df -h free -m top

No sustituyen el monitoreo continuo, pero ayudan a confirmar hipótesis durante un incidente.

2. Configura alertas accionables

Riesgo: demasiadas alertas se convierten en ruido. Muy pocas avisan demasiado tarde. En ambos casos, el equipo se acostumbra a operar a ciegas.

Recomendación: configura alertas con umbrales coherentes, canales supervisados y una acción inicial asociada.

Para cada alerta, registra:

• ¿Qué la activó?
• ¿Quién la recibe?
• ¿Cuál es la primera comprobación?
• ¿Cuándo escalar?
• ¿Cuándo silenciarla o ajustar el umbral?

La documentación de DigitalOcean sobre la gestión de alertas de monitoreo puede orientar la configuración de alertas dentro de la plataforma.

Ejemplos de alertas accionables:

• Disco por encima de un límite definido → revisar logs, archivos temporales y crecimiento de uploads.
• CPU alta durante un periodo sostenido → identificar el proceso, revisar el tráfico y evaluar una regresión reciente.
• Memoria baja → investigar un proceso con consumo anormal, una fuga o la necesidad de ajustar la capacidad.
• Tráfico inesperado → comprobar si se trata de un pico real, abuso, un crawler agresivo o una configuración incorrecta.

El trade-off está en los umbrales:

• Los umbrales muy sensibles detectan antes, pero generan ruido.
• Los umbrales permisivos reducen el ruido, pero pueden avisar demasiado tarde.
• Los umbrales sin una persona responsable no son alertas: son mensajes perdidos en un canal.

Para los incidentes recurrentes, escribe procedimientos breves. Un documento de media página que explique “qué hacer cuando el disco se llena” ya reduce bastante la improvisación.

---

Organización, automatización y costos: operar sin depender de la memoria del equipo

La producción se vuelve frágil cuando la infraestructura solo existe en la cabeza de una persona. Esto se aplica a los nombres de los recursos, los puertos abiertos, los scripts de deploy, los backups, los dominios y los costos.

El objetivo no es burocratizarlo todo. Es hacer visibles las decisiones.

1. Estandariza los recursos

Riesgo: los Droplets sin nombres claros, los tags inconsistentes y los proyectos mezclados dificultan la revisión, la respuesta a incidentes y el control de costos.

Recomendación: adopta nombres, tags, proyectos y entornos consistentes. Diferencia producción, staging y desarrollo.

Un patrón sencillo podría ser:

• Nombre del Droplet: prod-api-agendamentos-01
• Tags: env:prod, system:agendamentos, owner:plataforma
• Proyecto: aplicación o área responsable
• Documentación: dominio, puertos abiertos, estrategia de backup, responsables y procedimiento de recuperación

El objetivo es responder rápidamente:

• ¿De quién es este Droplet?
• ¿Está en producción?
• ¿Se puede apagar?
• ¿Tiene backup?
• ¿Qué sistema depende de él?
• ¿A quién se debe avisar en caso de incidente?

Los tags para entorno, sistema y centro de costos ayudan a revisar los recursos que deberían haberse apagado o eliminado. El beneficio aparece principalmente en dos momentos: cuando llega la factura y cuando algo falla.

Además, si tu equipo está madurando sus prácticas de ingeniería y quiere complementar la parte operativa con un estudio estructurado, puede ser útil conocer el material de Arandu en portugués como lectura complementaria. Usa este tipo de recurso para apoyar la formación continua, no como sustituto de la revisión práctica de tu propia infraestructura.

2. Automatiza lo que debe ser repetible

Riesgo: los deploys, las reglas del firewall, la creación de usuarios y la configuración de servicios realizados manualmente tienden a variar. Durante un incidente, esta variación dificulta reconstruir el entorno.

Recomendación: versiona la infraestructura y la configuración siempre que sea posible. Comienza de forma pequeña: los scripts revisables y documentados ya reducen bastante el riesgo.

Identifica las tareas recurrentes:

• Creación de recursos.
• Configuración del firewall.
• Aprovisionamiento inicial.
• Instalación de dependencias.
• Deploy.
• Rollback.
• Rutinas de backup y restauración.

No necesitas comenzar con una plataforma compleja. Un script corto, versionado y revisado puede ser el primer paso:

bash

!/usr/bin/env bash

set -euo pipefail

sudo apt update sudo apt upgrade -y sudo systemctl restart nginx

Este ejemplo es deliberadamente sencillo. En producción, tendrías que evaluar la ventana de mantenimiento, el impacto del reinicio, las pruebas posteriores al deploy y el rollback. El punto es que incluso un script pequeño hace explícito lo que antes estaba disperso en comandos escritos de memoria.

El trade-off también es claro:

• Automatizar exige una inversión inicial y mantenimiento.
• Hacer todo manualmente parece más rápido el primer día.
• Sin embargo, cuando sea necesario reproducir o recuperar el entorno, lo manual “que está en la cabeza de alguien” tiende a fallar.

La alta disponibilidad, una automatización más robusta y los servicios administrados pueden tener sentido según la criticidad, el costo, el RPO, el RTO y la capacidad operativa del equipo. No es necesario tratarlos como una obligación para cualquier proyecto, pero tampoco deberían descartarse por inercia.

3. Revisa los costos con contexto

Riesgo: los costos crecen debido a recursos olvidados, capacidad sobredimensionada, snapshots antiguos, discos adjuntos y entornos temporales que se volvieron permanentes.

Recomendación: revisa los costos periódicamente como parte de la operación, no solo cuando la factura asusta.

Una rutina sencilla puede comprobar:

• Recursos sin uso.
• Entornos temporales activos.
• Capacidad sobredimensionada.
• Backups conservados más allá de la necesidad.
• Snapshots antiguos.
• Volúmenes sin utilizar.
• Recursos sin tags o responsables.

Evita realizar recortes que reduzcan la recuperabilidad o la seguridad sin analizar el riesgo. Desactivar el backup para ahorrar puede ser una decisión técnicamente mala si la aplicación almacena datos importantes. Del mismo modo, eliminar el monitoreo porque “casi nunca se activa” puede simplemente ocultar los problemas.

Una buena revisión de costos no consiste en perseguir centavos a ciegas. Consiste en entender qué recursos sostienen el valor, la seguridad y la recuperación, y cuáles están ahí únicamente porque nadie se acordó de eliminarlos.

---

Checklist de revisión para una infraestructura existente en Droplets

Usa este checklist como punto de partida para priorizar. No es un certificado de madurez, un sello de seniority ni una garantía de disponibilidad. Es una forma práctica de encontrar fragilidades y decidir los próximos pasos.

Acceso y sistema operativo

• [ ] Cada persona usa su propia clave SSH; no hay claves compartidas sin una persona responsable.
• [ ] Se revisó el inicio de sesión directo como root.
• [ ] El acceso administrativo sigue el principio del mínimo privilegio.
• [ ] Se eliminaron los usuarios, las claves y los permisos antiguos.
• [ ] Existe una rutina definida para las actualizaciones de seguridad.
• [ ] El equipo sabe cómo revocar el acceso cuando alguien cambia de proyecto o deja la organización.
• [ ] Los cambios administrativos relevantes se registran o automatizan.

Red y exposición

• [ ] El firewall permite únicamente los puertos y orígenes necesarios.
• [ ] SSH no está abierto de forma irrestricta sin una justificación explícita.
• [ ] Los servicios internos no están expuestos públicamente sin necesidad.
• [ ] Las bases de datos, las colas y los paneles administrativos tienen reglas de acceso restringidas.
• [ ] Los recursos que se comunican internamente usan una VPC cuando corresponde.
• [ ] El equipo validó la región y la VPC de los recursos que necesitan comunicarse entre sí.

Recuperación y continuidad

• [ ] Los backups están habilitados y su cobertura fue validada.
• [ ] El equipo sabe qué datos son persistentes y dónde están almacenados.
• [ ] Los backups y los snapshots se utilizan con objetivos diferentes y comprendidos.
• [ ] La restauración ya se probó o existe una prueba programada.
• [ ] Se discutieron el tiempo de inactividad y la pérdida de datos aceptables para la aplicación.
• [ ] Las configuraciones necesarias para la restauración están documentadas o versionadas.
• [ ] El equipo reconoce que un único Droplet continúa siendo un punto único de falla.

Monitoreo y operación

• [ ] Se monitorean CPU, memoria, disco y red.
• [ ] Las alertas relevantes llegan a un canal supervisado.
• [ ] Las alertas tienen una acción inicial documentada.
• [ ] Los logs y las métricas de la aplicación complementan el monitoreo de la infraestructura.
• [ ] Existen procedimientos breves para los incidentes recurrentes.
• [ ] El equipo revisa las alertas ruidosas o inútiles en lugar de simplemente ignorarlas.

Organización, automatización y costos

• [ ] Los Droplets, los proyectos y los tags identifican el entorno, el sistema y la persona responsable.
• [ ] Las configuraciones críticas pueden reproducirse sin depender de la memoria de una persona.
• [ ] Los scripts y las automatizaciones importantes están versionados.
• [ ] Los recursos y los costos se revisan periódicamente.
• [ ] Los entornos temporales, los snapshots y los recursos sin utilizar se eliminan cuando ya no son necesarios.
• [ ] Los recortes de costos se evalúan considerando su impacto en la seguridad y la recuperación.

---

Próximos pasos

Si estás revisando una infraestructura existente, no intentes resolverlo todo el mismo día. Comienza por lo que reduzca más riesgos con la menor ambigüedad:

1. Revisa los accesos SSH y los usuarios. Elimina las claves antiguas, evita compartir credenciales y reduce los privilegios.
2. Cierra la exposición innecesaria. Ajusta el firewall y restringe los servicios internos.
3. Valida los backups. Confirma qué está cubierto y prueba una restauración.
4. Configura alertas útiles. Comienza por disco, CPU, memoria y disponibilidad percibida por la aplicación.
5. Documenta las decisiones esenciales. Responsables, puertos, dominios, backup, restore y deploy.
6. Automatiza lo repetible. Primero, scripts sencillos; después, herramientas más robustas si tiene sentido.
7. Revisa los costos con contexto. Elimina desperdicios sin sacrificar la seguridad ni la recuperación.

La producción confiable nace de mejoras incrementales. Un único Droplet puede ser una buena etapa inicial, siempre que el equipo conozca sus límites y trate la operación como parte del producto.

Para intercambiar experiencias sobre la operación de software en producción, participa en la comunidad SCCB.