Business details
Registered company no. 11869849
VAT number 317720513
As per the introduction, these stories are in a vaguely chronological order, hence this first story involves the DEC VAX. If you don’t know what a DEC VAX is, don’t worry, neither did I at the time. But let’s have a little context…
We are early 1990s here, I am on call for a remote access system that lets home based engineers use their Windows for Workgroups laptops to support various systems. These include some IBM mainframes (which I didn’t know anything about) some Windows servers (which I knew little about) and the DEC VAX thing (which I knew less than nothing about).
In good news, I don’t need to know anything about the IBM mainframe. I am only supporting the remote access system which comprises of numerous modems, many, many RS232 cables, Digi adapters, Microsoft Remote Access Service, Windows NT 3.51, SNA server, the DEC VAX box thingy and a Cisco terminal server thing. Simple.
I am not one to be uninformed, so I wanted to be fully briefed just in case of a callout. It was simple enough to handle the modems, they would lock up and need rebooting/reseating occasionally. The Cisco thing was a bit of a mystery but I was assured it needed no help. The only piece of useful insight I was to be given was regarding the DEC VAX. This was in my eyes a good thing, a whole session on the intricacies of the DEC VAX. This should be good.
Highly respected expert: “If anything happens just connect a console and type “b” then press return”
Me: “OK, so what does that do?”
Highly respected expert: “It reboots it.”
Me: “That’s not really diagnosing the problem though, surely we should investigate and fix it”
Mildly respected expert: “It’s quicker to reboot it.”
Oddly, the vaguely respected expert was technically correct, it was quicker but it didn’t really do what I wanted, which was no callouts, no interruption to my life and rock solid service. Ultimately quality in what I do and provide. That said, it was a DEC VAX and it only happened to me once.
Learning point for everyone:
Turning it off and on again is (sometimes) unfortunately an accepted thing in IT. Ideally it is a last resort and we fix the root cause. However, today I see and build different architectures that assume failure. That is a great thing. In the cloud world I see architecture that copes with failure by default, across the OSI stack in multiple ways. That to me is brilliant – we have finally learnt that IT fails in ways we don’t expect. The complexity we engineer in at this point is however such that it does by it’s own nature cause failure, so ultimate, complete failure needs to be planned for.
Assume disaster, plan for it and keep the business running as a result. Assume if it says completely resilient that it isn’t and plan your business to cope when that fails. When your architecture is bulletproof, it will fail.Just assume complete failure and you will help prevent the next IT version of the Titanic.
Registered company no. 11869849
VAT number 317720513