19
iAmNaN
6y

On chat today.
Dude: can you run a script for me? We don't have permission.
Me: what kind of script? Who wrote it?
Dude: posts screenshot of DML select/update statement he tried to run.
Me: I'm a DBA. We don't run DML for people.
Dude: Oh. Can you give me the password?
Me: examine script and notice he tried to run it on QA DB.
Me: No. We don't memorize passwords, and this is QA; you need to check the password out of the safe. You also need a change ticket to DevOps, and they will run it for you.

At that point I ended the discussion, because running anything in QA or Prod without a change ticket gets you fired. And I like my job. Really annoyed.

Comments
  • 2
    I've had the opposite problem: three requests I had to cancel, all from the same person, asking me to run a table creation script in his MySQL database. But since the database is running in our sandbox environment, he can run the script himself with his own root credentials. No change requests needed.

    He also asked us to "validate" his script. We're not DBAs; we're DevOps. We don't really do SQL at all. I definitely don't want to be the scapegoat if his script breaks his team's proof-of-concept.
  • 0
    I like that your QA is controlled via Change. I guess when you move to Prod you have to reference/relate the QA Change?
  • 1
    @bkwilliams yes. This is supposed to ensure that what is being implemented in prod was tested in QA and hasn't been modified in the interim. Works as long as they had all their test cases tested, and nothing was overlooked.
Add Comment