Capítulo 17 — Gestión de cambios y documentación

Mapa de la lección

Lección 17 publicada. Mapa, ejemplo, EX065.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["17.1 Por qué el control de cambios es seguridad"]
  N2["17.2 Una solicitud de cambio"]
  N3["17.3 Vuelta atrás"]
  N4["17.4 Mantener los documentos al día"]
  N5["17.5 Revisores"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX065"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["17.1 Por qué el control de cambios es seguridad"]
  N2["17.2 Una solicitud de cambio"]
  N3["17.3 Vuelta atrás"]
  N4["17.4 Mantener los documentos al día"]
  N5["17.5 Revisores"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX065"]

[Resultados de aprendizaje]
    |
    v
[17.1 Por qué el control de cambios es seguridad]
    |
    v
[17.2 Una solicitud de cambio]
    |
    v
[17.3 Vuelta atrás]
    |
    v
[17.4 Mantener los documentos al día]
    |
    v
[17.5 Revisores]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX065]

Resultados de aprendizaje

Usted podrá (1) explicar por qué cada cambio en la línea necesita un ticket; (2) redactar una solicitud de cambio con un plan de vuelta atrás; y (3) mantener los planos y los registros al día con la realidad.

17.1 Por qué el control de cambios es seguridad

La mayoría de los problemas en las plantas vienen de cambios que nadie registró: una regla de cortafuegos añadida con prisas, un programa editado durante una avería, una cámara atornillada por un contratista. El control de cambios significa que cada cambio se solicita, se revisa, se aprueba, se ejecuta y se registra. También facilita advertir un cambio no registrado, que puede ser la primera señal de un ataque. En HPFL varios problemas de este libro empezaron como cambios no registrados: el programa de la envolvedora editado del capítulo 11, la regla de cortafuegos temporal del capítulo 12 y el puerto de escritorio remoto del capítulo 16. Con un ticket, cada uno habría sido visible antes.

17.2 Una solicitud de cambio

Indica qué cambiará, por qué, en qué dispositivos, quién lo hace, cuándo, el riesgo para el proceso, cómo se comprueba el éxito y cómo deshacerlo. Los cambios de emergencia durante una avería están permitidos, pero se registran después, dentro del mismo turno. En HPFL la solicitud de Tomás para la actualización de VIS-CAM cubría todo esto en pocas líneas. Mantenga el formulario breve para que la gente lo use de verdad. Quien aprueba comprueba que la prueba de éxito y la vuelta atrás son realistas antes de dar su acuerdo.

17.3 Vuelta atrás

Antes del cambio, guarde el programa o la configuración actual y su hash. Si la comprobación falla, restáurelo. Un cambio sin vuelta atrás es una apuesta. En HPFL la vuelta atrás para VIS-CAM consistía en reinstalar el firmware 1.0.7 desde un archivo guardado con su hash anotado. Compruebe que el archivo guardado está completo antes de empezar el cambio. Si la propia vuelta atrás falla, deténgase y llame al ingeniero de control. En HPFL los hashes de los archivos guardados se anotaban en el ticket de cambio, de modo que un archivo restaurado podía comprobarse antes de cargarlo. Sin eso, una vuelta atrás podría cargar una copia corrupta o editada sin que nadie lo advirtiera.

17.4 Mantener los documentos al día

Actualice el registro de activos, el plano de red y la tabla de reglas en el mismo ticket. Marque los planos con un número de revisión y una fecha. En HPFL el plano de red seguía en la revisión 3 mientras que la VLAN IoT solo aparecía en los borradores de la revisión 4, algo que encontró el recorrido del proyecto final. Actualizar los documentos en el mismo ticket evita que se abra ese hueco. Cuando cambia un plano, marque la revisión antigua como superada y consérvela, para que las decisiones pasadas sigan pudiendo entenderse. Compruebe los números de revisión en cada recorrido; un plano cuya revisión va por detrás de la realidad es en sí mismo un hallazgo, como comprobó HPFL.

17.5 Revisores

La persona que hace un cambio no debería ser la única que lo aprueba. En HPFL el ingeniero de control revisa los cambios de programa, el responsable de la red revisa los cambios del cortafuegos y de los conmutadores, y el supervisor confirma la ventana de producción. Un segundo par de ojos detecta errores de tecleo en direcciones y valores antes de que lleguen a la línea. Anote el nombre del revisor en el ticket. Si la única persona que puede revisar no está disponible, espere a la siguiente ventana salvo que el cambio sea de emergencia.

Ejemplo resuelto (HPFL sintética)

El proveedor de la cámara de visión necesita instalar el firmware 1.1.0 en VIS-CAM. Tomás escribe: «Cambio 512: actualizar VIS-CAM de 1.0.7 a 1.1.0 para corregir la precisión de los rechazos; lo hace el técnico de calidad; martes a las 06:00, parada planificada; riesgo: los rechazos dejan de funcionar; comprobación: 20 paquetes de prueba, incluidos 5 con sellado defectuoso, rechazados; vuelta atrás: reinstalar 1.0.7 desde el archivo guardado, con el hash anotado». La actualización supera la comprobación y el registro muestra 1.1.0.

Caso sintético — HPFL. El cambio y la corrección del proveedor son inventados.

Errores y límites

El control de cambios puede convertirse en puro papeleo; mantenga los formularios breves y exija los campos clave. Los cambios de emergencia no deben convertirse en la vía normal.

Ejercicios — capítulo 17

• EX065 — Campos de una solicitud. Enumere seis campos de una solicitud de cambio.
  Mostrar criterios de evaluación

  Rúbrica: 3 = qué, por qué, dispositivos, quién, cuándo, riesgo, comprobación, vuelta atrás (seis cualesquiera); 2 = cuatro; 1 = dos; 0 = nada.
• EX066 — Edición durante una avería. El ingeniero edita PLC-FILL durante una avería a las 2 de la madrugada. ¿Qué debe ocurrir después?
  Mostrar criterios de evaluación

  Rúbrica: 3 = se registra como cambio de emergencia dentro del turno, nueva copia y hash, registro actualizado; 2 = solo registrarlo; 1 = nada; 0 = nada.
• EX067 — Comprobación fallida. La prueba de VIS-CAM deja pasar 2 de 5 sellados defectuosos. ¿Qué ocurre a continuación?
  Mostrar criterios de evaluación

  Rúbrica: 3 = vuelta atrás a 1.0.7, verificar, registrar el fallo, contactar con el proveedor; 2 = vuelta atrás; 1 = funcionar igualmente; 0 = nada.
• EX068 — Cambio no registrado. ¿Por qué merece notificarse un cambio no registrado aunque parezca inofensivo?
  Mostrar criterios de evaluación

  Rúbrica: 3 = puede ser no autorizado o señal de ataque; rompe la línea base y las copias; 2 = uno; 1 = ignorarlo; 0 = nada.

Síntesis del capítulo

Los cambios solicitados, revisados, reversibles y registrados mantienen la línea conocida; los no registrados son señales de alerta.

Siga estudiando — capítulo 17 de 18

← Capítulo 16 (borrador) · Índice de capítulos del curso · Capítulo 18 (borrador) →