Limited space and facilities
Many moons ago, I was "sysadmin" for a mini-computer system - a CMC reality (this was the late 70s). In those days, system upgrades were performed by the manufacturer, so that wasn't an issue.
However, we were handling large databases (by 1978 standards - tens of thousands of records, I think) and writing software to manipulate these databases in ad-hoc ways almost every day. But what a lot of people here are forgetting is that in those days, system resources were tiny, disc (yes, we had a disc) space was extremely limited and backup was a 1600bpi reel-reel magnetic tape. Indeed disc space was so limited that you often had to save a file to tape to be able to load another one. However, several databases had to be on-line - we ran an online query system for a few clients (no internet - this was via modems and hunting groups). Remember, too, that in those days even the concept of a file or a record varied from machine to machine - the ubiquitous Unix style bit-stream model of a file wasn't by any means universal. The CMC, for example, regarded a file as a collection of records whose location was allocated according to a hashing function derived from key fields - a record was a collection of fields. So even if you had a backup, it wasn't an image of what was on the disc, it was the output of a command to convert the disc version to a sequential format.
Anyway, the point I'm working round to is that very often we had no choice but to work on a live and running database - there wasn't space or resources to do anything else. And equally, the safeguard was to ensure you were working on a very well-defined small set of records when carrying out tests so that you knew what you were going to have to fix if it went pear-shaped. But of course, it was far more error-prone than anything a modern DBA or sysadmin would allow. today! And equally, of course, we were often manipulating data input by bored keyboard operators, so incorrectly formatted data were fairly common (we did apply validation on entry, but again, it was limited by the resources available). Very often, we'd run a command to reformat a field according to new customer requirements and find that it fell over when it hit a condition that we hadn't anticipated because an operator had put in something the client had told us didn't happen!
Whatever the rights and wrongs of what we were doing, it didn't half teach you to bench-check your code VERY carefully!