SUCHRE: Podobných fuckup scénářů jsem zažil taky dost, např. výpadek CSMS systému obsluhujícího přes deset tisíc nabíječek a telefonáty naštvaných uvíznutých řidičů elektroaut nebo zpackaná DB migrace bez rollback skriptů, kdy jsme celou noc ručně opravovali data, aby ráno mohly otevřít pobočky banky.
Každopádně průsery nejvyššího kalibru všude, kde jsem působil, konzistentně způsobovali outsorcovaní kolegové z Indie, historek mám dost, naprosto top fail ze světa databází, co jsem kdy zažil: Při upgradu on-premise PCF CloudFoundry instalace přišli o všechna produkční data z MySQL databází VČETNĚ ZÁLOH, naštěstí billing data byla odsynchronizovaná i v SAPu, jinak by nešlo za tohle období vyfakturovat. V nové verzi PCF zmizely nenávratně databáze (asi chyba v konfiguraci) a vygenerovaly se nové s jinými přístupovými údaji. Samozřejmě si ničeho nevšimli a až po upozornění, že ElasticSearch přetéká logama "connection refused" a nefungují microservisy, se začli problémem zabývat. Zálohy databází byly zašifrované a při upgradu PCF se vygeneroval nový encryption key a ten starý k zálohám nebyl zálohovaný ani uložený v nějakém Password Vaultu, takže zůstaly db backupy, které nešly otevřít, naprosto bizarní situace :-) V průběhu projektu způsobil tento team expertů i nějaké další faily jako zálohovací skript, který ukládal backup do stejného adresáře jako produkční mysql data, takže jednoho dne produkční db spadla na nedostatek místa. Samozřejmě alert/warning na blížící se zaplnění partition nebyl implementovaný, Prometheus byl asi moc scifi. Po těchto incidentech a oprávněné kritice se urazili a prohlásili, že si máme databáze zálohovat sami, když se nám to nelíbí. Není nad to, spolupracovat s mistry oboru :-)