Site Reliability Engineering (SRE): principios

He querido resumir en un post, los principios que se explican en el libro «Site Reliability Engineer» de Google (gratis y online).

CAPITULO 1 & 2 – INTRO

Además de programar, a un SRE se le pide conocimientos avanzados de cómo funciona el sistema UNIX a nivel interno, y de networking (capas de la 1 a la 3)

La clave está en dedicar al menos un 50% del tiempo en automatizar las tareas de operaciones o a hacer tareas de ingeniería (mejorar la fiabilidad, el performance, etc.). De esta manera, evitas tener un equipo que crezca a la vez que crece la infraestructura (y por tanto, las tareas de operaciones si no estuvieran automatizadas).

También es clave dedicarle tiempo a los postmortem para aquellos incidentes relevantes. En caso contrario, no se estará aprovechando la oportunidad de mejorar nuestros sistemas.

El concepto de «error budget» es (1 – disponibilidad_acordada). Si se establece 99.99% de disponibilidad acordada, el error budget será de 0.01%. Este error budget se podrá usar para lo que se quiera, pero típicamente se usará para tomar riesgos deployando nuevas funcionalidades lo antes posible.

Aprox un 70% de las caídas son debidas a cambios en producción. Los SREs deben aplicar best practices para automatizar completamente los cambios (progresivos) en producción así como el rollback.

Las alertas del sistema de monitorización deberían interpretarse y solucionarse de forma automática, y a partir de ahí, únicamente deberían notificar a un humano cuando éstos necesiten tomar parte.

Continuar leyendo «Site Reliability Engineering (SRE): principios»

Resumen de Scrum desde las trincheras

scrumEste es mi resumen de la parte de Scrum (sin incluir XP) del libro «Scrum y XP desde las trincheras» de Henrik Kniberg. No es la biblia ni debe ser una referencia, pero sí que puede ayudar a refrescar algún concepto o a empezar con Scrum.

Scrum = marco de trabajo

1- Pilas de producto

Lista priorizada de requisitos/historias en jerga del cliente.

  • Id
  • Nombre: de 2 a 10 palabras
  • Importancia: más alto = más importante. La importancia la da el product owner.
  • Estimación inicial: la unidad son puntos de historia [PH en adelante] (días/persona ideales). Ojo, no es un contrato ni un compromiso. Las estimaciones absolutas no son importantes, lo son las relativas. P.ej. Una historia con 2 PH debería durar la mitad que una con 4 PH.
  • Cómo probarlo: descripción a alto nivel de cómo testearlo (descripciones simples).
  • Notas: otra info breve.

El product owner se encarga de los objetivos del negocio y no interviene en decisiones técnicas.

Debe existir la pila de producto, con las importancias, antes de empezar el sprint.

Continuar leyendo «Resumen de Scrum desde las trincheras»