Históricamente ha habido una tensión natural entre las operaciones (OPS) y los desarrolladores. La misión de OPS es mantener los sistemas estables y funcionando. Para la mayoría de los sistemas, si nada cambia con el sistema, tenderá a comportarse como lo hizo en el pasado. Los desarrolladores, sin embargo, son generalmente incentivados para crecer el uso del sistema que significa, ya sea bueno o malo, más características. Las nuevas características resultan en cambios rápidos en el sistema y se introduce algún nivel de inestabilidad y riesgo en el sistema. Estos incentivos opuestos crean una inmensa cantidad de tensión entre los dos equipos. Esto resulta en operaciones que eliminan el acceso a las máquinas y por lo tanto la libertad de hacer cualquier operación relacionada. Esto pone fin a nuevas ideas como los micro-servicios dentro de la organización porque la infraestructura siempre es requerida para poner nuevos servicios y la nueva infraestructura requiere una colaboración profunda con otro equipo. Esta tensión no es buena y crea una división dentro de sus equipos de ingeniería que conducen a ningún progreso que se está haciendo porque los dos equipos se niegan a ayudarse mutuamente. Esto no sólo perjudica la productividad, sino que en última instancia la felicidad de sus empleados y van a empezar a salir. Si he aprendido algo como mi cargo como líder de ingeniería es esto: Si quieres mantener a tus empleados contentos tienes que asegurarte de que son productivos. Happy significa llevarse bien con otros equipos de ingeniería y unificar la cultura vs crear una división.

"con gran poder viene una gran responsabilidad"

Como equipo todos somos responsables por el software que ponemos en producción, no sólo OPS o desarrolladores. Esto significa que tenemos que crear una estructura incentivision en el lugar que da a tanto OPS y desarrolladores un objetivo común. DevOps tiene muchos significados a diversa gente, pero a nosotros en ShareThis significa que hay un alto-traslapo entre las áreas funcionales de operaciones, desarrollo y QA. Así que para que los desarrolladores obtengan el poder de hacer cambios en la producción tienen que ser responsables de sus acciones. Por eso creemos que es fundamental que los desarrolladores tengan una rotación de llamadas si algo va mal. Los desarrolladores deben experimentar lo que se siente al ser alertados cuando su código causa problemas inesperados. Esto comparte la carga de resolver problemas a horas de trabajo en todo el equipo y no sólo en los hombros de las operaciones o un solo equipo.

Asignación de SLA y SLA

Una de las actividades más importantes es definir un SLA para los servicios. Esto define las expectativas de estabilidad en un sistema para los clientes, desarrolladores y OPS. Pero el objetivo nunca debe ser tener 100% de tiempo de inmovilización, ya que podría significar que se está moviendo demasiado lento y no tomar los riesgos suficientes. Una startup se trata de tomar riesgos calculados y moverse rápido. En cuanto a ser más cuantificativo sobre el riesgo, usamos las asignaciones de SLA. Podemos calcular nuestra tolerancia al riesgo tomando el SLA y restando 1. Así que si usted tiene un 99,9% de tiempo de inducción SLA podemos calcular una asignación de SLA por el siguiente 1 – 0,999 = .001 que es nuestra asignación de SLA. Esto significa que el sitio puede tener 43m de downtime antes de que haya utilizado el tiempo de actividad acordado. Al usar esto, los desarrolladores pueden desplegar tan frecuentemente como deseen siempre y cuando no golpeen sus asignaciones de SLA. Una vez que lo hacen, no se pueden implementar nuevas características y en su lugar el equipo debe centrarse en la estabilidad. Esto pone énfasis en las pruebas automatizadas y el monitoreo para verificar que sus aplicaciones no causarán problemas en la producción. Esto también pone un equilibrio saludable entre la velocidad y la tolerancia al riesgo que se puede acordar de antemano. En toda la oficina estamos construyendo tableros de instrumentos que pueden mostrar rápidamente cualquier anomalía para que podamos revertir cualquier cambio antes de que cause violaciones de SLA.

Los resultados

Desde que hemos estado trabajando en la cultura "DevOps" hemos visto un aumento dramático de la colaboración entre los equipos y también un aumento de la productividad. La propiedad total de las aplicaciones desde el desarrollo hasta la producción se ha extendido por todo el equipo y ahora somos capaces de obtener servidores e infraestructuras en cuestión de segundos contra semanas. Para nuestros clientes esto significa nuevas características y estabilidad de servicio. Para nuestras partes interesadas internas esto significa plazos predecibles. Lo más importante, para nuestro equipo, estos cambios les dan un sentido de propiedad y productividad.

Si este tipo de ambiente de trabajo es algo que usted estaría interesado por favor visite nuestra página de oportunidades:
https://sharethis.com/careers/