7 trampas de la gestión de incidentes: Capítulo 6, Una vez que reemplacemos nuestra automatización actual

El fracaso es inevitable. Los sistemas se rompen. Se cometen errores. Todos hacemos nuestro mejor esfuerzo para evitar incidentes, pero los incidentes van a suceder. La rapidez y eficacia con la que diagnosticamos el problema y reparamos el servicio es la medida de nuestras capacidades operativas.

Exploremos los siete antipatrones dolorosos que pueden obstaculizar su respuesta y la de sus colegas a los incidentes.

  1. Podría arreglarlo, si pudiera hacerlo
  2. El Dogpile
  3. Soy un experto, no reviso la wiki
  4. Hazlo otra vez. Entonces hazlo de nuevo
  5. Solución alternativa conocida. Error cerrado
  6. Una vez que reemplacemos nuestra automatización actual….
  7. ¡Incidente! Llamen a todos
    Nuestro objetivo: incidencias más breves. Menos escaladas.

    El dolor

    Negocio:  Capacidad disminuida. Se hace menos.

    Equipo:  ineficiencia. “Bikeshedding”.

    Ingenieros: retrabajo. Conflicto.

    Todos hemos escuchado algo en este sentido: “Este nuevo lenguaje de automatización será el que resuelva nuestros problemas. Ahora, si podemos lograr que todos lo aprendan y reemplacen lo que ya tienen, ¡cosecharemos los beneficios! ”

    Dejemos a un lado el argumento de que un nuevo lenguaje o herramienta es significativamente mejor que el anterior. El reentrenamiento y el reemplazo al por mayor nunca parecen suceder. En cambio, estamos atrapados con algunos de los nuevos y algunos de los viejos.

     

    A medida que este ciclo se repite, terminamos con un poco de todo: Bash, Puppet, Chef, Ansible, Python, Ruby, Powershell y más.

    Se puede argumentar que una falla significativa de los esfuerzos de automatización anteriores fue que creíamos que “un idioma para gobernarlos a todos” era incluso posible.

    Las “islas de automatización” son comunes en las empresas

    En cambio, deberíamos aceptar que, en cualquier organización lo suficientemente grande, los diferentes equipos tendrán diferentes requisitos y preferencias que conducirán a diferentes opciones de automatización.

    En lugar de luchar contra la automatización heterogénea y la inevitabilidad de las herramientas, ¿cómo podemos aprovecharla y aprovecharla al máximo?

    Cruzar los límites del equipo y del sistema es donde los entornos mixtos se convierten en un problema. Los procedimientos operativos (comprobaciones de estado, reinicios, actualizaciones, etc.) deben funcionar en todos los componentes de un entorno, y las decisiones que los diferentes equipos tomaron en diferentes momentos sobre esos componentes.

    Rundeck está diseñado para crear fácilmente flujos de trabajo que abarcan diferentes herramientas de automatización, comandos del sistema y llamadas a API. Cualquiera que necesite ejecutar estos procedimientos puede hacerlo a través de Rundeck, independientemente de la combinación de automatización subyacente.

    “Rundeck une su automatización existente”

    Uso de Rundeck para mitigar el dolor de los problemas repetitivos

    1. Cree trabajos de Rundeck (flujos de trabajo) donde cada paso llame a sus scripts existentes, comandos del sistema (es decir, lo que escribiría en la línea de comandos) o llamadas API.
    2. Utilice el control de acceso detallado de Rundeck para brindar acceso a cualquier persona que necesite ejecutar esos trabajos.
    3. Los equipos que son responsables de los componentes individuales del sistema pueden refactorizar o reemplazar la automatización de nivel inferior y actualizar los trabajos de Rundeck como mejor les parezca (sin afectar a quienes usan los trabajos).

    Referencia:

    Damon Edwards, Rundeck. 7 Pitfalls of Incident Management: Chapter 6, Once We Replace Our Current Automation https://resources.rundeck.com/learning/7-pitfalls-of-incident-management-chapter-6-once-we-replace-our-current-automation/

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Top