Capítulo 25 — Taller de proyecto en equipo
Mapa de la lección
Lección 25 publicada. Mapa, ejemplo, EX073.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["25.1 El equipo y sus roles"]
N2["25.2 Elementos de trabajo con criterios de aceptació"]
N3["25.3 La revisión como control"]
N4["25.4 Ritmo"]
N5["25.5 Revisiones sin culpables"]
N6["25.7 Actividad práctica: cartera de trabajo del proy"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX073"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["25.1 El equipo y sus roles"]
N2["25.2 Elementos de trabajo con criterios de aceptació"]
N3["25.3 La revisión como control"]
N4["25.4 Ritmo"]
N5["25.5 Revisiones sin culpables"]
N6["25.7 Actividad práctica: cartera de trabajo del proy"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]
[Resultados de aprendizaje y conexión]
|
v
[25.1 El equipo y sus roles]
|
v
[25.2 Elementos de trabajo con criterios de aceptació]
|
v
[25.3 La revisión como control]
|
v
[25.4 Ritmo]
|
v
[25.5 Revisiones sin culpables]
|
v
[25.7 Actividad práctica: cartera de trabajo del proy]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX073]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted debería ser capaz de:
- trabajar como parte de un pequeño equipo de entrega que construye y opera un servicio compartido;
- dividir el proyecto de integración de LANTERN en elementos de trabajo con criterios de aceptación y evidencia;
- usar la revisión (de código, configuración y documentos) como control de seguridad;
- llevar a cabo revisiones breves y sin culpables de lo que fue bien y mal, y convertirlas en cambios.
A partir del capítulo 26, el libro pasa al traspaso, el despliegue y el proyecto final. Los servicios reales los construyen equipos, y muchos fallos de seguridad son fallos de equipo: una suposición que nadie comprobó porque cada persona creía que otra lo había hecho, un cambio fusionado sin revisión porque el revisor estaba ocupado. Este capítulo es un taller: le da una estructura para el trabajo en equipo que necesita el proyecto final.
25.1 El equipo y sus roles
Un equipo de entrega de LANTERN en FSTS tiene cuatro o cinco personas: un responsable del servicio (prioriza y habla en nombre de los clientes), dos o tres tecnólogos (construyen y operan), un revisor de seguridad (puede ser uno de los tecnólogos, por rotación) y un representante del cliente de operaciones de Agua que asiste a las revisiones y acepta el trabajo que afecta al proceso. Los roles rotan cuando es posible para que el conocimiento se comparta; ninguna persona debería ser la única que entiende el retransmisor o que tiene sus claves (la independencia del capítulo 8).
25.2 Elementos de trabajo con criterios de aceptación
Cada elemento de trabajo indica qué significa «terminado» mediante criterios de aceptación que producen evidencia. «Añadir alertas de silencio de estación» es un deseo. «La regla C alerta en los 20 minutos siguientes a que se detenga el latido de una estación, verificado con tres silencios de prueba inyectados en dos estaciones; primera acción redactada y acordada con la sala de control de Agua; ficha de control actualizada» es un elemento de trabajo. La evidencia pasa a formar parte del registro del proyecto final.
La fusión de NTP de este capítulo muestra el coste de un criterio débil: «actualizar los servidores NTP» se cumplió mientras todos los retransmisores perdían su segunda fuente de hora. El criterio reescrito, «desfase < 1 s en todos los retransmisores durante 24 h», habría fallado el primer día.
25.3 La revisión como control
La revisión por pares del código, los archivos de estado deseado, los cambios del cortafuegos y los manuales de operación detecta errores, difunde el conocimiento y dificulta que una sola cuenta comprometida o descuidada cambie el servicio por su cuenta. Haga que la revisión sea obligatoria para todo lo que cambie el servicio (ramas protegidas, capítulo 22), específica (el revisor comprueba los criterios de aceptación y las propiedades de diseño del capítulo 8, no solo el estilo) y registrada. Rote a los revisores para que la revisión no se convierta en el sello automático de un aprobador habitual.
La fusión de NTP se revisó, pero en cuanto a la sintaxis; el revisor nunca comprobó que el nuevo servidor existiera.
25.4 Ritmo
A los equipos operativos les conviene un ritmo breve y regular: una conversación semanal de planificación (qué se hará, quién lo hará y con qué evidencia), una breve comprobación diaria (qué está bloqueado) y una revisión al final de cada ciclo (qué se entregó, mostrado con su evidencia al representante del cliente). El trabajo operativo (incidentes, averías) interrumpe el trabajo del proyecto; planifique contando con ello en lugar de fingir que no ocurrirá. El silencio de PS-09 y la avería del disco del servidor de salto son las interrupciones que hay que prever.
En Fallowmere, la comprobación diaria es donde se planteó el silencio de PS-09 la mañana siguiente a que saltara la regla C.
25.5 Revisiones sin culpables
Cuando algo sale mal (un cambio fallido, una alerta no detectada, un cuasiincidente), celebre una breve revisión sin culpables: qué ocurrió, qué sabían las personas en cada momento, por qué sus acciones tenían sentido para ellas entonces, qué condiciones permitieron el problema y qué cambiará. El material de SRE de Google describe el valor de los análisis posteriores sin culpables para aprender de los incidentes sin desalentar la notificación honesta (Google SRE book, postmortem culture); el trabajo de Reason sobre el error humano distingue entre culpar a las personas y corregir las condiciones del sistema que hacen probables los errores (Reason, 2000). El resultado son cambios, cada uno con un responsable, no una persona a la que culpar.
25.6 Ejemplo resuelto: una fusión que no debería haber ocurrido (sintético)
Durante el proyecto, un tecnólogo fusionó un cambio de estado deseado que eliminaba 10.30.0.2 de los servidores NTP de los retransmisores, con la intención de sustituirlo por un servidor nuevo que aún no se había construido. La automatización lo aplicó; los retransmisores se quedaron con una sola fuente de hora; cuando esa fuente se reinició por mantenimiento dos días después, los retransmisores derivaron y los mensajes de las estaciones empezaron a no superar la ventana de 120 segundos. La revisión sin culpables encontró que: el cambio se revisó, pero el revisor comprobó la sintaxis, no si el nuevo servidor existía; los criterios de aceptación decían solo «actualizar los servidores NTP»; la monitorización de deriva comprobaba que los ajustes coincidían con el estado deseado, y coincidían; y no había ninguna alerta por desfase del reloj. Cambios: la lista de comprobación de la revisión incluye «¿existe y responde cada sistema referenciado?»; los criterios de aceptación de los cambios de hora incluyen «desfase < 1 s en todos los retransmisores durante 24 h»; nueva alerta por desfase del reloj del retransmisor > 2 s. No se culpó a nadie; se corrigieron tres condiciones.
25.7 Actividad práctica: cartera de trabajo del proyecto
Redacte la cartera de trabajo del proyecto final (capítulo 29): al menos diez elementos de trabajo que cubran el retransmisor, la validación, la autenticación, el historiador, el registro, las reglas de monitorización, el acceso, las copias de seguridad y la restauración, la automatización, los manuales de operación y la evidencia. Cada uno necesita criterios de aceptación que produzcan evidencia y un rol responsable. Un elemento completo como modelo: «Alerta de desfase del reloj del retransmisor: alertar cuando el desfase de cualquier retransmisor supere 2 s; aceptación: un desfase inyectado en un retransmisor de prueba genera la alerta en un ciclo de evaluación y la primera acción está redactada; responsable: monitorización de FSTS». Sale directamente de la revisión de NTP. Incluya al menos un elemento que exista solo para cerrar una carencia detectada antes, como la mediana de 1.440 minutos del tiempo de detección de la FIM.
25.8 Errores frecuentes y límites
- Elementos de trabajo sin criterios de aceptación.
- Revisión que comprueba el estilo, no el fondo; o un único revisor habitual.
- Un solo miembro del equipo como única persona que entiende un componente.
- Planes que ignoran las interrupciones operativas.
- Revisiones de fallos que terminan con «tener más cuidado».
La revisión de NTP de este capítulo terminó con tres condiciones cambiadas, no con «tener más cuidado».
La fusión de NTP muestra los dos primeros errores: un criterio de aceptación vago y una revisión solo de la sintaxis. Una sola persona que entiende el almacén de claves es el tercero, que el traspaso del capítulo 26 puso de manifiesto cuando el equipo receptor no pudo encontrarlo.
Ejercicios — capítulo 25
EX073 — Criterios de aceptación. Objetivo: redactar criterios que produzcan evidencia. Entradas: elementos de trabajo: (a) «asegurar SSH en los retransmisores»; (b) «copias de seguridad del historiador»; (c) «proceso de acceso de proveedores». Restricciones: cada criterio debe poder comprobarlo otra persona. Pasos: reformule cada uno con al menos tres criterios. Evidencia esperada: lista. Rúbrica: 3 = por ejemplo, (a) autenticación por contraseña desactivada y servicio a la escucha en la interfaz de gestión en todos los retransmisores (salida de la comprobación de deriva), conexión desde la zona corporativa rechazada (registro de prueba), MFA en el servidor de salto; (b) copia nocturna con una copia inmutable, prueba de restauración dentro del RTO registrada; (c) habilitación limitada en el tiempo probada de extremo a extremo, caducidad verificada, conformidad de Kell; 2 = criterios comprobables en parte; 1 = deseos reformulados; 0 = nada.
EX074 — Lista de comprobación de la revisión. Objetivo: hacer que la revisión sea sustantiva. Entradas: el caso del capítulo 25 («Ejemplo resuelto: una fusión que no debería haber ocurrido») y las propiedades de diseño del capítulo 8. Restricciones: ocho puntos. Pasos: redacte una lista de comprobación para revisar un cambio de estado deseado. Evidencia esperada: lista de comprobación. Rúbrica: 3 = incluye la existencia y la accesibilidad de los sistemas referenciados, el sentido de la confianza preservado, ningún servicio nuevo a la escucha en todas las interfaces, ningún secreto en el cambio, reversión definida, criterios de aceptación y verificación, clientes afectados informados, despliegue escalonado; 2 = seis; 1 = puntos solo de estilo; 0 = nada.
EX075 — Revisión sin culpables. Objetivo: llevar a cabo una revisión que produzca cambios. Entradas: incidente: un tecnólogo de guardia silenció la regla B durante 24 horas en una noche ruidosa y olvidó reactivarla; un flujo real no declarado pasó sin alerta durante tres días. Restricciones: sin culpables; condiciones, no personas. Pasos: redacte la revisión: cronología, qué tenía sentido en el momento, condiciones, cambios con responsables. Evidencia esperada: una página. Rúbrica: 3 = reconoce como causa el ruido por evento de la regla B (capítulo 19), la falta de caducidad automática de los silenciamientos y la falta de visibilidad de las reglas silenciadas; cambios como alertas por episodio, silenciamientos que caducan y se muestran en el panel y un punto en la lista de comprobación del traspaso; 2 = cambios parciales; 1 = culpa al tecnólogo; 0 = nada.
Síntesis del capítulo
Los servicios los construyen equipos. Asigne a los roles responsabilidades claras y rótelos para que el conocimiento y el control no se concentren en una persona. Redacte elementos de trabajo con criterios de aceptación que produzcan evidencia. Haga que la revisión sea obligatoria, específica y registrada, para que actúe como control de seguridad. Planifique contando con las interrupciones operativas y aprenda de los fallos con revisiones sin culpables que cambien las condiciones en lugar de culpar a las personas.
Siga estudiando — capítulo 25 de 30
← Capítulo 24 · Índice de capítulos del curso · Capítulo 26 →
Continúe con la siguiente lección escrita.