Today, the Tokyo Stock Exchange system is down.

I'm not sure what caused this, but as a systems engineer, if I could offer something to you, it would be

"It is essential to assume that the system will be shut down on the first and last day of each term, consecutive holidays, etc."

This is because system maintenance and system replacement may take place at the end of the period, and its launch may take place on the first day of the period.

No matter how much you check in advance, there is a difference between a "test environment" and an "operational environment".

Testing for all situations is just a dream.

Any system is essentially doomed to go "down".

And that "down" potential is maximized on the first and last day of each period, holiday, etc.

-----

By the way, the person responsible for finding weaknesses in a product by attacking the system in various scenarios is called a "tester".

While I was stationed in the U.S., I wrote a program for our testers that kept launching all sorts of attacks.

"Somehow, I was getting a bad look from my team members"

In particular, the developers seemed to get that "that Japanese guy is here again" look on their faces when I just showed up at the partition.

It's reasonable.

That's because the code they just created is their own creation and their own child.

It can't be pleasant because they are suddenly "tortured".

-----

On the other hand, there have been times when I've been attacked by other testers on developments I've made -- and I've been uncomfortable, too.

Even though I know it's just a work.

On a day like that, I said that "spec out the conditions for reproducing down" and I was drinking with complaining about such things.

Well, I can say that works are unreasonable things

-----

Anyway, as a systems engineer,

"Any system goes down"

I would like to say that.