No dude en plantear un incidente

Mi primer incidente -incident.io ocurrió en mi segunda semana aquí, cuando arruiné el proceso para solicitar permisos adicionales de Slack, lo que hizo imposible instalar nuestra aplicación durante unos minutos. Esto fue un poco vergonzoso, pero también fácil de resolver para alguien más familiarizado con el proceso, y declarar un incidente significaba que llegábamos allí en solo unos minutos.

Declarar el primer incidente cuando comienza un nuevo trabajo puede ser intimidante, pero en realidad no debería serlo. Veamos algunos temores comunes y veamos cómo abordarlos.

"¿No será un montón de trabajo?"

La mayoría de las organizaciones tienen algún tipo de procedimiento de respuesta a incidentes que generará una lista de cosas que debe hacer, como determinar cuántos clientes se vieron afectados, decidir cómo arreglar las cosas con ellos y tomar medidas proactivas para evitar que esto vuelva a suceder.

Eso puede parecer una perspectiva desalentadora. Usted podría preguntarse ¿Este problema realmente vale todo eso ?

Un valor predeterminado seguro debería ser "sí". Si resulta que este problema no fue tan grave después de todo, debería poder cerrar la respuesta con bastante rapidez. Pero si se intensifica aún más, te alegrarás de que ya tienes el proceso en marcha.

Puede obtener más información sobre cómo automatizar su proceso de incidentes en nuestro artículo anterior.

Si termina siendo mucho trabajo, eso no es necesariamente algo malo. Como individuo, es probable que aprenda mucho al abordar su primer gran incidente. Como equipo o empresa, han abordado un problema grave de manera proactiva.

"¿Esto me traerá problemas a mí o a mi equipo?"

Si la respuesta es "sí", probablemente debería estar buscando otro trabajo.

Como dijo Chris antes, tener más incidentes no es algo malo --- no está en los intereses a largo plazo de ninguna organización esconder pequeños incidentes debajo de la alfombra, porque nunca se puede saber cuáles podrían convertirse en grandes problemas más adelante.

¡La misma lógica se aplica aquí también! La mayoría de los equipos que no tienen ningún incidente no se arriesgan y ralentizan la entrega u ocultan sus problemas. Ninguno de esos es un signo de un equipo saludable.

Eso no quiere decir que los gerentes deban establecer una cantidad objetivo de incidentes por equipo por trimestre, pero sí significa que los gerentes deben buscar equipos atípicos que tienen muy pocos incidentes, así como aquellos que tienen más de lo que les corresponde.

¿Tienen miedo de ser culpados? ¿Pasan tanto tiempo asegurándose de que todo lo que entregan sea perfectamente sólido que se olvidan de sus clientes? ¿Tuvieron dificultades para responder a un incidente anterior de manera efectiva y necesitaron ayuda adicional para aprender cómo se hace bien?

"Nunca he hecho esto antes"

Siempre habrá una primera vez, y probablemente sea mejor si el primer incidente que ejecuta no es uno crítico "todo está mal". Un incidente importante es lo suficientemente estresante sin tener que aprender sobre los procesos de respuesta de su organización al mismo tiempo.

Los días de juego, en los que ejecuta un incidente simulado en un entorno que no es de producción, son excelentes para aprender su proceso de respuesta a incidentes (¡y perfeccionar sus habilidades de depuración!), pero tarde o temprano debe aplicar ese conocimiento a algo real.

Incluso con autopsias intachables y procesos de respuesta a incidentes muy bien administrados, he visto equipos que deciden que el tiempo de inactividad de un producto clave no es un incidente porque no ha estado inactivo durante tanto tiempo y probablemente nadie lo haya notado.

Cuando se une a un equipo, especialmente como ingeniero con más experiencia, parte de la experiencia que aporta es sobre las diferentes culturas en las que ha trabajado, incluida la forma en que responde cuando las cosas van mal. Esto puede parecer incómodo, cambiar la cultura de un equipo siempre lo hace, pero la recompensa vale la pena.

También publicado aquí.