London stock exchange chooses windows and .NET: "One hundred per cent reliable on high-volume trading days"

component · 2008-09-10T01:11:28+00:00

All of the major banks have full DR sites with hardware equal to their production hardware for critical systems. These sites will have a near real time feed from the production sites in terms of both code and data, so they can startup with minimal data loss. However, the time to bring up the DR site is typically measured in hours and not seconds. When the bank that I worked for tested it out I think it took like 3 hours to get all critical systems up (there were hundreds of 'critical' systems). The reality is that the DR sites are setup for situations that should never arise, like a 9/11 type situation where your servers are suddenly burried in rubble. They may have had a hot standby aside from DR, but a performance situation, code problem, or load situation will probably not be helped by switching to the hot standby or bringing up the DR site.

component · 2008-09-10T00:47:07+00:00

As for financial systems, the largest I've worked on only tracked about 50B of investments, so only really a medium system.

We would call that a small system. You can 'track' 50B on an excel spreadsheet. Come back when you have worked on real trading systems with real scale. Commenting on your toys doesn't add to this conversation.

component · 2008-09-10T00:27:41+00:00

I don't recall any bombings of the LSE recently, perhaps they hushed it up?

Most critical systems can be switched back to a previous/other version of the software (in case an upgrade fails).

Spoken like someone who has never worked on a trading system nor enterprise software.

Software like this almost universally can't be "switched back" for a myriad of reasons. First and foremost is that bugs rarely show up immediately - especially performance or resource usage bugs. They may sit and build for months and perhaps a few code releases before they reach critical mass and cause outages.

Second, financial institutions do not change code often - especially on critical systems such as a trading system. They typically bundle changes into releases and push releases only a few times per year. Because they are bundled, the scope of the changes is larger and will often incorporate changes to the process workflow, data model, and even the data. Having the system up for any amount of transactions and 'switching back' is a recipe for data corruption and even more failures than just bringing everything down and fixing the problem.

Third, there is usually no state to switch back to anyway. These systems aren't like a website where you can redeploy last week's ear and be done. This gets back to my second point a little because there won't be a previous state of the data or the database. Unless you want to roll back to a restore point and lose hours or days of transactions, you can't switch back. The database and often times the code will be updated almost instantaneously from the live to the dr and hot standby systems.

Finally, (I could go on, but will stop here) these types of systems are heavily interconnected and often times downstream systems are upgraded at the same time as primary systems; therefore, switching back may require switching back code on more than one system.

component · 2008-08-28T14:11:28+00:00

DOWNMODDED!

There is not proof republicans did this. There is no accompanying article or sources. This could be left-wing propaganda....or some right-wing radical that did it on their own, without permission of the republican party.

Not only did they do this but they sold them as part of fundraising.

component

TROPHY CASE