I joined the IT group (again), but this time as a junior UNIX admin. I now had administrative access on the systems that my previous group was writing software for. This turned out to be quite useful for my former teammates. I was able to make sure their desktop workstations were aligned to the settings on the production systems they were programming for, which somehow is something that nobody else had thought to check for. Also, I was also working closely with the computer operations team again, often having to work in their space to fix problems that they found.
From the time I started here to the point when I rejoined the IT group the company had moved from North Miami Beach, FL to Plantation, FL. Part of that move to a significantly larger space included a larger size on-site data-center. The data center had a fire supression system that would be lethal to humans, thus required that two people be in the data-center at all times, for safety.
It turns out that the boss with the worst reputation had it because of how many people needed to be fired on the operations team, for taking extended breaks (longer than 30 minutes) outside or in the bathroom. He was actually pretty easy to work for. His major hot-button points were pretty straight forward, don't lie, don't steal. If you mess up, take responsibility and work on fixing it.
During this role, I eventually started mentoring some of the operations folks on UNIX Administration. Even then, I knew that mentoring and teaching others was a quick way learn things faster, myself, and I've used this several times over my career.
Business had been good, and call volumes were still rising, so in 1997, the company ordered a Sun Enterprise 10,000 Fully configured, they sold for a million USD, but ours has two CPU boards (out of a possible 16) with the maximum four CPUs on each board. It was really cool (looking), but a nightmare.
The intended purpose was to upgrade all the call handling from plain-text logging to use an Oracle database in the same way. Even with all 8 CPUs on the fastest computer available at the time, the Oracle database couldn't keep up with our call volume.
These things aren't refundable, so we then looked at porting our existing call logging systems onto it instead. That is when we started running into stability issues. Sun sent a number of technicians out to replace CPUs and CPU boards, but management had lost interest now that the machine couldn't be used for the original vision. Management had developers working on other things, and literally stopped calling Sun.
That is how I ended up as the administrator of a Sun Starfire. It's official use was to walk potential clients around it, and my official task for it was to make sure that it was on (so that the fans would be spinning). For the record, when it wasn't under any load, it was plenty stable. It was impressive looking anyway.
When I had the time, though, I absolutely learned all about how it worked. It is amazing how much can be learned from a system that isn't critical.