add feedback loops post

[edux]

Hay que pegarle una leida por las dudas que haya pifiado en algo.

Para leer el post https://github.com/sysarmy/blog/blob/call_the_developers/content/posts/crear-un-buen-feedback-loop-entre-ops-y-devs-usando-documentacion.md

[nicolas17]

Muy buen artículo para compartir!

• Creo que "I just asked a question" debería ser "Sólo hice una pregunta" en vez de "Acabo de hacer una pregunta" (maldito inglés, por qué "just" tiene tantos significados?)
• "Boy who cried wolf" se refiere a la fábula de "el pastor mentiroso" / "pedro y el lobo". "Creating a 'boy who cried wolf' situation" podría ser "crear una situación de 'niño que grita lobo'", o deshacerse de la metáfora y decir directamente "temor a dar falsa alarma".
• Algunas inconsistencias de tú vs usted cuando le habla al lector.

[Daniel-DZ]

Buen artículo! Coincido con nicolas17 en ambos puntos.

Y agrego: runbook podría convertirse en "instructivo"? Si bien no es la palabra que utilizan, es lo que conocemos como instructivo: sin ser un procedimiento, detalla los pasos a seguir para concretar una tarea.

[efsbl]

Excelente artículo la verdad. Dejo algunas notas/posibles correcciones (por supuesto que es subjetivo!). Saludos

Intro

Quien esté "de guardia" de operaciones debe manejar el problema o escalarlo a los desarrolladores, sin importar la hora del día o de la noche

Allí radica un potencial conflicto

Comienza con comentarios del tipo

Simplemente hice una pregunta y ya se ponen en idiotas

...es el ciclo de retroalimentación dinámico del runbook

Bucles de retroalimentación...

El objetivo del ciclo de retroalimentación es crear un mecanismo en el que los expertos en la materia creen runbooks, pero al mismo tiempo darle el poder y la confianza tanto a los desarrolladores como a quienes operan de mejorarlos, de manera tal que se reduzca el número de escalaciones y al mismo tiempo mejore la cooperación.

Esto contrasta notablemente con las organizaciones en las que los runbooks son creados por el "alto nivel" sin tener en cuenta la opinión de las personas que realmente están involucradas (o directamente involucradas?).

Escribirlo

Nuestro formato preferido es una lista de viñetas que la gente de operaciones puede utilizar para resolver alertas. Cuando llega un alerta, siguen las instrucciones del runbook. Si se llega al final de la lista y el problema sigue sin ser resuelto, se escala a los desarrolladores.

Los desarrolladores de una organización necesitan escribir los documentos, obviamente. Pero frecuentemente, a la tarea de documentar se le asigna una prioridad baja y se la deja en un segundo plano para enviar nuevos productos, actualizar funcionalidades y otros trabajos considerados como 'críticos'. Como consecuencia, nunca llegan a realizarla. Es necesario que la administración incluya la creación de Runbooks como parte del proyecto.

...deles una plantilla. Ni siquiera sentirán que les estás pidiendo que escriban un documento; simplemente llenar un formulario. Utilizando una plantilla con el formato de una lista de viñetas, donde cada uno de ellos es el procedimiento...

Canalizar....

...agregue lo que no estaba seguro, anote el caso de uso que desencadenó la escalada o el desarrollador aumente la lista de viñetas, el resultado final hace que (las?) operaciones...

En una empresa anterior, obtuve un runbook que era solo una única viñeta:

¡Resultó que sí! Estaban monitoreando una situación que nunca debería suceder, pero en el caso de que ocurra, querían saberlo...

...de abordar un problema en producción,...

Si un paso no funciona o no está seguro de qué es lo que hace...

El ciclo de retroalimentación permite a los desarrolladores controlar la frecuencia con la que se les escala...

_..."niño que lloraba como un lobo" => idem nicolas17, falsa alarma

Conocimiento fácilmente...

Instamos a todos nuestros desarrolladores a que utilicen este proceso de retroalimentación (feedback) con los documentos

...desde la depuración de un problema que aparece en producción

[edux]

Listo, ya salió los agregue al final. Gracias!