Este artículo describe cómo GitHub abordó un problema crítico de fiabilidad: las dependencias circulares en sus sistemas de despliegue. La causa raíz subyacente de estos incidentes hipotéticos es la 'configuration drift' o la introducción inadvertida de nuevas dependencias en los scripts de despliegue que, en un escenario de fallo de GitHub.com, impedirían la recuperación. El problema se agrava por la naturaleza de GitHub como su propio cliente, donde la indisponibilidad de la plataforma bloquea el acceso al código fuente y las herramientas necesarias para repararla.
Las salvaguardas existentes, que dependían de la revisión manual de scripts, fallaron porque muchas dependencias no se identificaban hasta que ocurría un incidente, retrasando la recuperación. La solución obvia de bloquear github.com por completo en las máquinas de despliegue no era viable, ya que estos hosts también servían tráfico de clientes y necesitaban acceso a la red. Esto llevó a la búsqueda de una solución más granular y dinámica.
La solución implementada utiliza eBPF para crear un aislamiento de red a nivel de proceso para los scripts de despliegue. Mediante BPF_PROG_TYPE_CGROUP_SKB, se filtra el tráfico de red saliente de cGroups específicos, y con BPF_PROG_TYPE_CGROUP_SOCK_ADDR, se interceptan y redirigen las consultas DNS a un proxy en userspace. Este proxy evalúa los dominios solicitados contra una lista de bloqueo y utiliza eBPF Maps para comunicar las decisiones de permitir/denegar al kernel. Además, se correlacionan las solicitudes bloqueadas con el PID y la línea de comando del proceso, proporcionando una visibilidad crucial para la depuración y la prevención proactiva. Este enfoque permite detectar y prevenir dependencias problemáticas antes de que causen un impacto en la producción, mejorando la estabilidad y el MTTR.