Estábame preguntando se podería publicar a entrada desta semana. Por que? Que pasou? Nesta entrada vou contarvos o incidente que ocorreu no meu provedor cloud e como fixen para permanecer online. É por isto polo que as empresas deberían ter uns plans de Resposta a Incidentes e de Continuidade de Negocio!

Que pasou?

Se non o viches ata agora, OVH está que arde esta semana. Non é unha expresión ou algo así, quero dicir que en realidade tiveron un incendio que destruíu un dos seus edificios, onde tiñan un centro de datos. Isto é un incidente maior que afectou a moitos moitos clientes, incluíndo empresas. Por suposto OVH ten un plan para responder ao incidente, pero estalles levando un montón de tempo e esforzo xestionalo.

Resposta a incidentes: o plan B

A Resposta a Incidentes é un concepto moi familiar para os expertos en ciberseguridade. Xunto co Plan de Continuidade de Negocio (BCP), é a salvagarda para as empresas para ser capaces de ter un plan cando as cousas vaian mal. Isto é, teñen que pensar de antemán os procesos críticos que teñen que reiniciar, como deberían comunicarse cos seus clientes, a quen deberían chamar tan pronto como detecten o incidente, e un lote de cousas que deberían ter escritas.

Problema e solución

Imaxe: Cando as cousas van mal.

O meu plan B: dúas semanas de hosting gratuíto

Onde está a miña documentación de resposta a incidentes? Ben, non son unha empresa, así que non teño tal cousa! O que si teño que facer é o que a xente normalmente chama un plan B.

Asi que, sen acceso ao meu servidor, tiven que resolver como volver a publicar o meu sitio web. Por suposto, tiña unha copia da fonte que estaba usando para isto. Como expliquei nunha entrada anterior, estou usando o xerador de sitios estáticos Hugo para renderizar o meu sitio web asi que, todo o que tiña que facer era almacenar nalgún sitio o sitio web completo e apuntar o meu DNS aí.

Código HTML

Imaxe: Eu mirando ao meu sitio web increíble en localhost.

Github Pages

Unha das miñas opcións é contratar outro servizo de hosting web mentres tanto. Porén, despois dun tempo pensando e mirando a miña web (só en localhost, por suposto), recordei as Github Pages!

As Github Pages son un servizo gratuíto de Github que che da a oportunidade de ter o teu sitio web para ti e para os teus proxectos. Isto é, van almacenar e despregar a túa web a partir do teu código fonte nos teus repositorios. Asi que, mentres teñas unha conta de Github, podes montar o teu sitio web.

Hai dous tipos de sitios web nas Github Pages:

  • A túa páxina principal, normalmente producida por Jekyllrb: martinord.github.io.
  • Os teus sitios de proxectos: martinord.github.io/my-project

Asi que o que fixen foi configurar un novo repositorio de Github chamado martinord.github.io, e activei as Github Pages no menú de Configuración desta forma:

Github Pages settings

Imaxe: Configuración de Github para as Github Pages.

Configuración DNS

Como puideches ver na configuración anterior, especifiquei un nome de dominio personalizado. Este axuste é para que poidas apuntar os teus servidores DNS ás Github Pages e dicirlles onde tes o teu sitio web. Desta forma, agora podes crear unha nova entrada CNAME no teu provedor DNS desta forma:

DNS CNAME entry

Imaxe: A configuración DNS no meu Cloudflare.

Conclusión

Algúns incidentes que non esperas que ocorran, a veces, ben… simplemente ocorren. Por esta razón, se es unha empresa, deberías ter un plan de actuación, como unha Resposta a Incidentes ou un BCP. Estes son críticos para un negocio, xa que o tempo fóra de liña significa perdas económicas.

No meu caso, tiven o sitio web caído algúns días, pero ao final conseguín mantelo online. O importante aquí é nunca parar de aprender para que, cando as cousas vaian mal, te manteñas creativo/a e atopes unha solución.

Obri! Espero que vos parecese interesante, véxovos a semana que vén!