Gitlab. com are niste probleme in acest moment. Pe scurt, cineva a pus in fund clusterul de Postgres si recupararea din backup nu a functionat cum se asteptau. Sper ca nu sunt prea multi pe aici care sa fie afectati.
Mai multe detalii aici: https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
Haha, doar ce citeam asta si ma gandeam: “devops is not a real job”
EDIT:
live stream:
At 2017/01/31 11pm-ish UTC, team-member-1 thinks that perhaps pg_basebackup is refusing to work due to the PostgreSQL data directory being present (despite being empty), decides to remove the directory. After a second or two he notices he ran it on db1.cluster.gitlab.com, instead of db2.cluster.gitlab.com.
At 2017/01/31 11:27pm UTC, team-member-1 - terminates the removal, but it’s too late. Of around 300 GB only about 4.5 GB is left.
Brought to you by the same people who’ve decided to move out of the cloud and run their own hardware.
N-am urmărit decât tangențial toată treaba. Dar colegi mai știutori de devops/are/sysadmin etc. păreau destul de dezamăgiți de cum a fost stins focul ăsta. Kudos lor că au fost foarte deschiși in tot procesul, totuși.
Și s-au răzgândit ulterior… 
Nu mai eram la curent cu asta, dar zic că este alegerea înțeleapta.
Cloud, Hybrid-cloud sau bare metal e mai putin important in cazul asta. Human error loveste indiferent de infrastructura folosita. Acum ceva timp (pentru unii ani buni, altii mai recent), sysadmin am inteles ca RAID nu e backup, ca offsite backup e ideal. Unii au inteles deja ca testarea procedurilor de restore este indispensabila. Altii invata asta (sau vor invata asta) trecand prin momente de genul asta.
Yup. Mă refeream la faptul că sa îți rulezi datacenterul tau, in loc să folosești un provider de cloud, e o treaba care necesita expertiză și un nivel al echipei tehnice mai ridicat. Dacă back-up-ul la date extrem de prețioase n-a mers ok, e un indicator că echipa încă nu e “acolo”. Că sa nu mai zic că era cineva logat pe o mașină de producție, că Root/sudo.