Runbooks, ¿qué son y por qué los necesito?

En resumen, un runbook es un conjunto detallado de instrucciones que pueden ayudar a guiar a los administradores de TI, administradores de sistemas, ingenieros e ingenieros de DevOps (y muchos otros según el contenido del runbook) a través de los procedimientos rutinarios y críticos necesarios para administrar o solucionar problemas de sistemas, aplicaciones o infraestructura.

El valor de tener sus Runbooks en su lugar y ampliamente distribuidos puede ahorrarle tiempo de respuesta en un momento crítico y, en general, mantener bajos los retrasos.

¿Tiene algún problema con el pod de microservicios?

Tal vez revise el Runbook para ver si ese problema se ha resuelto antes. ¿Necesita dar acceso a un usuario a un sistema o herramienta, pero no sabe quién administra dicho elemento?

¿Cómo obtiene esos recursos para los miembros de su equipo?

Un Runbook, bien documentado y bien distribuido, ayudará en estos casos.

Así es como desarrollé Runbooks para el proyecto actual en el que he estado trabajando. Llegó un momento y un espacio en el que no se estaba satisfaciendo una necesidad. Hubo muchas preguntas sobre cómo realizar una variedad de tareas, con respuestas dispersas en muchos departamentos entre varios miembros del equipo.

La información está ahí, simplemente no está documentada y, lo que es más importante, no se comparte, lo que deja grandes puntos ciegos dentro de una organización para administrarse de manera efectiva a través de esfuerzos de bajo gasto y alto rendimiento.

Impulsar la creación de runbooks a través de la identificación de preguntas

El proceso comenzó con la identificación de las peticiones:

• ¿Qué aplicaciones, sistemas, herramientas están disponibles dentro de la organización?

  • Sauce labs, Bitrise, DataDog, AWS, Human, Lucid, Figma, etc.

• ¿Quién es el propietario/patrocinador de las herramientas y sistemas individuales?

  • Administradores

• ¿Quién dentro de la Org. tiene acceso y a qué sistemas, y deberían tener acceso?

  • Sistemas administrados / permisos

Identificar las preguntas anteriores ayudó a diseñar el trabajo que se necesitaba desde mi propia perspectiva. Comenzó con solo rastrear quién sabía lo que teníamos a nuestra disposición para usar dentro de la organización. Yo personalmente, tenía acceso a algunos sistemas y herramientas que se necesitaban, pero no tenía idea de cuántos existían.

Encontrar al propietario dentro de la organización que tenía más acceso a la mayoría de los sistemas y herramientas aceleró enormemente el proceso. Después de comprender qué recursos necesitaba investigar, pude averiguar quién tenía acceso realmente y qué niveles de permisos tenían para ciertas herramientas. También pude identificar a las personas que tal vez deberían tener ese acceso y no lo hicieron.

Con este proceso también vino una revisión y el deseo de establecer un nivel que se les dio a los usuarios para sus permisos cuando se agregaron a un sistema. El tamaño correcto también ayudó a garantizar que se reforzaran los problemas de seguridad. Las personas que anteriormente tenían habilitado el modo "Dios" o los derechos de administrador se colocaron en roles más relacionados que se adaptaban a sus necesidades de permisos.

Sin duda, esto también creará cierto malestar dentro de una organización, debido a que los derechos se atenuan para los usuarios. El objetivo es tener el menor nivel de privilegios asignados, con el alcance correcto a las necesidades de los usuarios finales. Más allá de eso, es un deseo y no una necesidad.

Mantener los sistemas bien aprovisionados, con roles y permisos claramente definidos, junto con los runbooks asociados, mejorará en gran medida muchos aspectos de las operaciones diarias y las preocupaciones a largo plazo.

¿Te gusta lo que escuchaste? ¿Tiene preguntas sobre lo que es adecuado para usted? ¡Nos encantaría hablar! Contáctenos

Episodios de podcast y publicaciones de blog