5 ms·

As some have suggested, Nasdaq is confirming that this was test data that got propagated to third party aggregators. https://mobile.twitter.com/Nasdaq/status/8

by bbgm 9y ago

As some have suggested, Nasdaq is confirming that this was test data that got propagated to third party aggregators. https://mobile.twitter.com/Nasdaq/status/882054148413325313 https://mobile.twitter.com/Nasdaq/status/882054148413325313 http://www.nasdaqtrader.com/TraderNews.aspx?id=utp2017-05 http://www.nasdaqtrader.com/TraderNews.aspx?id=utp2017-05

cm2187 9y ago
Using production systems to run tests... What could go wrong?
- nickpeterson 9y ago
  No test like production.
- humanrebar 9y ago
  It's actually considered best practice in various categories of technology to run tests on the production systems. https://en.wikipedia.org/wiki/Built-in_self-test https://en.wikipedia.org/wiki/Built-in_self-test
  - noir_lord 9y ago
    When done intentionally. I've seen lots of tests 'escape' their environment for a bunch of reasons (tests got sent to production with a deploy, human was on the wrong machine and ran a manual test command etc etc). It's almost impossible not to screw up at some point, I try to focus on minimising the small mistakes (airline pilots have commented that it's not the first problem that kills you it's the second one).
    - ethbro 9y ago
      That's why artificially differentiated steps are critical. If the "deploy to test" procedure looks exactly like the "deploy to prod" procedure, except with different servers, then you're asking for human error. Ensure the test deploy procedure will always fail if run against prod targets when half-asleep. Whether it's something like requiring a different config setting or a reload or an account switch. Anything that breaks the process-as-usual.
  - johnbellone 9y ago
    I agree that there are a class of problems that you simply will not find on canary environments, but most of the places I have been will run their smoke suite independent of the actual service. A problem of this type, e.g. core to your SLA/SLO, shouldn't be tested on the live production deployment. An alternative would be creating a dummy ticker and playing fake data, but even that is dangerous on a live exchange.

by bbgm 9y ago

cm2187 9y ago

Using production systems to run tests... What could go wrong?

nickpeterson 9y ago
No test like production.
humanrebar 9y ago
It's actually considered best practice in various categories of technology to run tests on the production systems. https://en.wikipedia.org/wiki/Built-in_self-test https://en.wikipedia.org/wiki/Built-in_self-test
- noir_lord 9y ago
  When done intentionally. I've seen lots of tests 'escape' their environment for a bunch of reasons (tests got sent to production with a deploy, human was on the wrong machine and ran a manual test command etc etc). It's almost impossible not to screw up at some point, I try to focus on minimising the small mistakes (airline pilots have commented that it's not the first problem that kills you it's the second one).
  - ethbro 9y ago
    That's why artificially differentiated steps are critical. If the "deploy to test" procedure looks exactly like the "deploy to prod" procedure, except with different servers, then you're asking for human error. Ensure the test deploy procedure will always fail if run against prod targets when half-asleep. Whether it's something like requiring a different config setting or a reload or an account switch. Anything that breaks the process-as-usual.
- johnbellone 9y ago
  I agree that there are a class of problems that you simply will not find on canary environments, but most of the places I have been will run their smoke suite independent of the actual service. A problem of this type, e.g. core to your SLA/SLO, shouldn't be tested on the live production deployment. An alternative would be creating a dummy ticker and playing fake data, but even that is dangerous on a live exchange.