5 pilares del SRE/DevOps

‍

La división de responsabilidades entre un SRE y un DevOps es muy borrosa, si bien hay muchos que defienden que DevOps no es un cargo, es una cultura, o una metodología de trabajo, cada vez vemos más anuncios de “Se Solicita DevOps”. Cargo que termina ocupando alguien que viene de ser SysAdmin, Desarrollador, Redes o hasta un implementador de Telecomunicaciones.

Tan novedoso es que se confunde la responsabilidad a tomar, por eso paso por acá a resaltar los principios básicos de un SRE/DevOps, reflejándolo en 5 pilares:

1.Reducir Silos Organizacionales:

El concepto de “silos” en las empresas y organizaciones se entiende como la incapacidad para trabajar eficientemente entre las áreas o unidades de negocio que las integran. La ausencia de una buena comunicación, el feedback, orientación por parte del líder y del equipo puede traer no sólo un mal ambiente laboral sino que los procesos no sean eficientes. Podemos reducir estos silos rompiendo barreras entre los equipos y resaltar la colaboración de unos con los otros.

No somos competencia entre nosotros, somos un equipo, si a ti te va bien, a mi también. Pues tanto el departamento de Infra como los desarrolladores compartimos el éxito del producto final.Todos debemos tener la misma visión y enfoque al trabajar en producción.

2. Aceptar accidentes y fallas como normales:

Las computadoras son poco confiables, no puedes esperar la perfección. Y cuando introducimos humanos en el sistema debemos esperar más imperfección aún. Cuando hay fallas (que siempre las hay) en vez de culpar a la persona que presionó el botón, se deben revisar los procesos, si la persona siguió el procedimiento que tenía en mano entonces el error no es de la persona, es del procedimiento.

Independientemente de lo que descubramos, entendemos y verdaderamente creemos que todos hicieron el mejor trabajo posible con base en lo que se sabía en el momento, los recursos disponibles y la situación dada.

Podemos hacer un análisis RCA o post mortem sin señalar culpables. Sino que nos aseguramos que los accidentes o fallas no pasen de la misma manera exacta más de una vez. Y se hay fallas que se toman como normales pues se maneja un presupuesto de error dentro del cual es aceptable una caída del sistema.

3. Implementar Cambios Gradualmente:

‍No son sólo cambios pequeños e incrementales que serían más fáciles de revisar, sino además en caso de que cause un bug en producción, nos tomará menos tiempo recuperar el servicio y hacer un rollback simple.

Evitar el “BigBang deployment” y preferir implementaciones graduales como Canary o Blue-Green deployment.

4.Usar herramientas y automatizar:

Tratamos de eliminar el trabajo manual y repetitivo lo más posible. Revisamos cuento trabajo en emergencia (toil) tenemos y tratamos de automatizar estas tareas con scripts de Bash, Ansible, Gitlab CI,Jenkins, o cualquier otra herramienta.

5. Medir Todo:

‍las métricas del sistema y del talento humano son un indicador fundamental para el éxito, de nada sirve tomar las métricas y no evaluarlas. Sin una manera de medir la evolución de los cuatro pilares anteriores no vamos a tener manera de saber como va. Debemos medir el tiempo de falla, la escalabilidad, la cantidad de trabajo del personal y salud de los sistemas.

Si pensamos en DevOps como una filosofía, el objetivo del SRE es llevar a cabo esa filosofía, El SRE implementa DevOps y no necesariamente se implementan las cosas de la misma manera exacta de como lo hacen en otras empresas

El objetivo común es derribar barreras organizacionales y entregar un mejor Software más rápido.