it turns out we probably caused the downtime ourselves. I didn't know dropping 170 databases and deleting 80 entire projects at once could do that"

Gave me a hearty chuckle. Especially as the client adamantly refused to have SSDs installed for the DB to run on top.

Just imagining the poor read-write heads jerking back and forth in vain attempts to find all the data to delete... So yes, dropping 170 databases at once does in fact take a database server down to its knees, as deleting is all the drives will be doing for a while.

At least it wasn't my or my colleague's mistake this time.

  • 3
    Nope, still your fault. You let them be able to do it in the first place.
  • 2
    @C0D4 yeah. If you let them do it its your fault. If you don’t you lose the client. If you have them sign waivers you’re an asshole.
  • 0
    @molaram when the client isn't responsible for restoring everything when they destroy it all, then they don't get the ability in my books.
  • 1
    @C0D4 I'd love to agree or disagree, but I've been working here only for two years. This client has been with the company much longer, and the reason they have admin access to their DB is something I never found out.
  • 5
    @Aldar we never give our guys access to anything at all. Except a few specific templates using a non-evaling language. They still manage to fuck things up, for that we have some automation in place that restores the defaults when they break shit. They also use to post support tickets saying the shit don’t work, so we have other scripts in place that check the audit logs and give them the login and IP of the perpetrator, then close the ticket.
  • 1
    @molaram Epic automation right there! Good job!
Add Comment