Este post tiene como objetivo ayudar a implementar metodologías Devops o SRE a todos los que trabajan en un rol similar al de administrador de sistemas tradicional.

Cuando empecé a trabajar como system admin, muchas de las herramientas que usamos y nos facilitan el trabajo como DevOps, SRE o como este escrito en tu contrato, no existían. De eso hace mas de 10 años, y han habido muchos cambios en ese tiempo, en algunos casos por esas nuevas herramientas o por tecnologías disruptivas, como la nube, Docker o Puppet.

Gracias a todos estos avances técnicos, nuestro trabajo es mas sencillo y podemos hacer cosas en menos tiempo y con mas certeza. Pero nuestro objetivo, como profesionales, es usar esas tecnologías para implementar las 3 bases DevOps para el administrador de sistemas moderno:

Todo en código. Automatiza todas las cosas. Minimiza el tiempo para reparar.

1 - Todo en código

Infraestructura, configuración de servicios, scripts… Todo tiene que hacerse usando código versionado en repositorios usando git, Subversion o cualquier otra solución que lo permita.

El hacer cambios a mano representa serios problemas. Como ejercicio mental, si has hecho cambios manuales en tu trabajo en los últimos meses, imagina que por accidente alguien borrara tu infraestructura en la nube o en un datacenter. Teniendo copias de seguridad, cuanto tiempo y esfuerzo costaría recuperar todo a como estaba antes de este borrado, te acordarías de todo lo que has hecho cliqueando en una consola o corriendo comandos después de hacer ssh? Si trabajas con otros que tienen acceso a realizar cambios manuales, como puedes estar seguro que esos cambios son reproducibles o no crean on problema de seguridad como por ejemplo un bucket S3 abierto al publico por accidente con archivos confidenciales?

Este es el punto que mas se ha favorecido con la llegada de herramientas como Puppet, Chef, Ansible, AWS Cloudformation, Terraform y las nubes ofreciendo API’s para crear infraestructura y servicios, sin quitar protagonismo a herramientas como shell scripts que se han usado desde hace décadas para este propósito con gran éxito.

Hoy en dia es muy difícil justificar acciones manuales, y si son indispensables, deberían ser documentadas de una manera clara para hacerlas fácilmente reproducibles por cualquier miembro del equipo.

2 - Automatiza todas las cosas

Todos los procesos manuales deben ser automatizados si posible. Y como dice el punto 1 de esta lista, toda la automatización tiene que usar código versionado.

Hacer el deploy de una version nueva de software, cambios en la base de datos de producción, invalidar caches, parchear servicios y sistemas operativos, revisar unos archivos para confirmar que todo funciona bien.. Todos hemos tenido que sufrir tareas repetitivas que consumen tiempo que podría ser empleado en mejores cosas, como automatizar estos procesos. No solo eso, el realizar tareas manualmente aumenta el factor error humano.

Si escribes un script que borra copias de seguridad mas antiguas que tres semanas, lo pruebas con éxito antes de ejecutarlo en producción, lo versionas en git y lo ejecutas desde Jenkins u otra herramienta CI/CD, tendrás menos posibilidades de borrar por accidente algo que no deberías que si por ejemplo, no te has tomado el segundo cafe de la mañana y seleccionas a mano los archivos equivocados.

Lo mismo se puede decir de las releases de software. Si eres responsable de hacer deployments, insiste que el proceso tiene que ser totalmente automatizado. No pares hasta que te den los recursos necesarios para esto o hasta encontrar otro trabajo donde entiendan lo importante que es la automatización.

3 - Minimiza el tiempo para reparar

Definiendo tiempo para reparar como el tiempo medio que ser tarda en recuperar de un fallo. Este punto es la consecuencia natural de los dos primeros.

Me explico: Si todo esta en código y esta automatizado, el tiempo para reparar fallos se reduce considerablemente.

Por ejemplo, imagina que por un descuido o acción malintencionada, tus servidores EC2 en producción y tu cluster de Redis en Elasticache se han borrado. Si tienes todo el código necesario para automatizar la creación y configuración los servidores y Redis en Terraform, puedes recrear tu infrastructura con un simple comando: terraform apply

Una parte extremadamente importante de este punto es al automatizar el rollback de un deployment que introduce fallos. Si nadie quiere hacer deployments en producción un viernes, seguro que se debe a la dificultad de devolver el sistema a una version anterior que funcione. Y como podemos saber qué funcionaba? Correcto, teniendo la configuración en código versionado.

Teniendo los dos puntos anteriores cubiertos, un deployment de una version nueva de cualquier aplicación debería ser un proceso versionado y documentado. Hoy en dia existen tecnologías que implementan estos conceptos de manera natural, como Kubernetes, pero en un mundo mas tradicional, aun se encuentran casos que requieren entrar a servidores, descargar archivos, cambiar configuración, etc.. Si este es tu caso, piensa como automatizar el deployment y el rollback a una version previa y escribe codigo para automatizarlo.

No tiene por que ser perfecto desde el dia uno, pero si planteate que sea incremental, y que el objetivo final es automatización completa.