Texas Dept. Of Public Safety Issues Amber Alert For Victim Of Horror Doll Chucky
from the nightmare-fuel dept
There's a rule in IT: don't test on live systems in production. There's debate over this, of course, but the general idea is that testing on live systems is a great way to screw up something with the live system, rather than some test environment. The more important the system is, the more true that mantra becomes.
Which brings us to the Texas Amber Alert system. See, Texans subscribed to get Amber Alerts via email got one last week that seemed a little... off.
First... terrifying. As someone who absolutely hates horror movies because I'm a big scared wimp, getting this alert is pure nightmare fuel. But it's also sort of funny, except that this kind of testing on the live Amber Alert system is pretty dumb. The whole thing apparently happened due to a test being run on the system and it accidentally got sent out to email subscribers. Give the folks responsible for this high marks for going into detail on the joke, though.
The alert, which was sent by email on Friday, warned of a 16-pound suspect wearing “blue denim overalls” and “wielding a huge kitchen knife.” It included an image of Chucky, the killer doll introduced in the 1988 slasher film “Child’s Play,” the first of a series of Chucky films.
The Texas Department of Public Safety has since apologized, saying in a statement that the alert was sent as a “result of a test malfunction.”
“We apologize for the confusion this may have caused and are diligently working to ensure this does not happen again,” the department said.
Meanwhile, with the media asking the agency for more details on how all this happened and why, they aren't talking. Don Mancini, who created the Chucky character, is however.
PLEASE FIND THEM, @TiffnyMovieStar AND I ARE FRANTIC. PLEASE NOTE: THE KID IS NON-BINARY, THANKS. @BillyBoydActor @JenniferTilly https://t.co/Z3AatyConp
— Don Mancini (@RealDonMancini) January 29, 2021
Look, mistakes happen. But that's why you don't run these sorts of tests on a live system as important as the Amber Alert system.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: amber alert, chucky, texas
Reader Comments
Subscribe: RSS
View by: Time | Thread
Chucky, sans skin, plays a starring roll in Daft Punk's Technologic music video.
[ link to this | view in chronology ]
Re:
lmao
[ link to this | view in chronology ]
Re:
Daft Punk Bop It Bot
[ link to this | view in chronology ]
Re: Re:
bop it, un-bop it
[ link to this | view in chronology ]
Meh; they left out the full name: Charles Lee "Chucky" Ray.
[ link to this | view in chronology ]
Sometimes, though, the only place you can really run the final tests is in production. Nobody in software likes it, but sometimes that's the only place the networks and services you need to test with exist. You've got mock versions in the QA and staging environments, but they're not the real thing and may themselves have bugs in them so they don't behave the way the real thing would. Most often that would cause the system to fail null, and for something like the Amber Alert system you probably don't want to send out an alert and have it... fail to go out because the system sending out the alerts expected an all upper-case code (like the mocks all used) while the system raising the alert used lower-case.
That's why every system has a few test accounts in production for the express purpose of running tests and verifying things are working after deploying a new version of the system. They're usually set up the way this alert was, with blatantly obvious bogus data so if they accidentally get where they shouldn't've they're easily recognized and discarded.
[ link to this | view in chronology ]
Re:
Why not just create a back up copy and test it on that first - load handling? Lack of spare hardware for something of scale?
[ link to this | view in chronology ]
Re: Re:
Usually it's lack of outside systems. A vendor or outside agency that doesn't have a dedicated staging environment running the same software as production, for instance. Sometimes it's lack of hardware, for instance when I worked at Flying J our QA department had to buy real gas pumps and modify them for use in the lab for testing (and even then it wasn't really adequate, we couldn't replicate the variety of pump and controller firmware present at the actual stores).
[ link to this | view in chronology ]
Re: Re:
"Why not just create a back up copy and test it on that first - load handling? Lack of spare hardware for something of scale?"
Very few systems are standalone - meaning you now also need a test stack running every associated system as well, and those have to be populated and set up with the same data they have in production.
If what you need to test is whether a change in your SAP enterprise system will cause downstream issues after it's gone through two separate CRM systems, one mapping interface, and another sales or finance system then your tests in the developer stack isn't going to tell you much about the expected outcome. At most you can map the output from a few tests in that one origin system and verify it against your expectations.
[ link to this | view in chronology ]
Re:
"That's why every system has a few test accounts in production for the express purpose of running tests and verifying things are working after deploying a new version of the system."
Not every system.
[ link to this | view in chronology ]
Re: Re:
Every system I've ever dealt with. Nobody sane trusts that the deployment of a new version went flawlessly, there's always at least some smoke tests done after deployment to make sure the system's really working before it's opened back up for use. And nobody sane does those tests using real user's accounts because nobody wants to mess up real data with test transactions.
[ link to this | view in chronology ]
Re: Re: Re:
"Every system I've ever dealt with."
Yet, at some point you'll find yourself working in, or interacting with, some ancient dinosaur which hasn't been updated, patched or maintained since the early 2000's. And that'll be the frankenmonster serving data to your company's brand new mint-condition Salesforce CRM. "Testing" either means the superuser or admin of the creaky old database writes the changes in on the fly and tries to monitor the end result real-time or there'll be one whopper of a new budget required to set up the long-since-decommissioned old test environment and populate it. That budget will not be forthcoming.
[ link to this | view in chronology ]
Ah yes, the Oahu inbound ballistic missile alert
Instantly reminded me of how, as a brand new resident on Oahu in January 2018, my phone lit up with "BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL" alert on my phone. As did every resident. Which was, in fact, an unscheduled drill. With the wrong message sent by a deranged employee of the alert network. Now living back in California, I feel a little safer. But still...
[ link to this | view in chronology ]
Re: Ah yes, the Oahu inbound ballistic missile alert
Yup.
Lessons not learned results in repeat, again and again and .....
Gets a bit frustrating for the casual observer.
[ link to this | view in chronology ]
"But that's why you don't run these sorts of tests on a live system as important as the Amber Alert system."
Chance are, they didn't intend to, some developer was probably testing code and had his env set to PROD instead of DEV or QA, or merged the wrong branch. It happens, there should be better safeguards against that on a system as important and publicly visible as this, but it happens.
It's nice that Don Mancini got a laugh out of it, hopefully we'll get more Brad Dourif Chucky from him as planned in the near future and he hasn't been hobbled too much by the half-assed remake.
[ link to this | view in chronology ]
Re:
"some developer was probably testing code "
idk .. but many places of business dis-allow development access to production. It just does not happen.
[ link to this | view in chronology ]
Re: Re:
And yet many still do, even Fortune 500 companies. It may frighten you to see the state of code and development at some of the world's largest companies and even governments. Never trust that just because the whole world recognizes a company's name that they're doing things properly behind the scenes.
[ link to this | view in chronology ]
Re: Re: Re:
"And yet many still do"
Heh .. no way did I intend to imply that it does not happen.
Yes, there are many horror stories from business everywhere.
My prior comment however, was based upon experience.
[ link to this | view in chronology ]
Re: Re: Re: Re:
Ok, I see - my error.
I meant it does not happen at that particular business, did not intend the scope to be all inclusive.
[ link to this | view in chronology ]
Re: Re:
"many places of business dis-allow development access to production"
...and many more places don't. In my experience, especially smaller shops where the developers and production admins might be the same team. At the end of the day, someone has to have the ability to push to production, and someone forgetting to switch envs after fixing a production issue can be all it takes.
"It just does not happen."
Oh, believe me, it happens. Whether or not it should is another question, but it's certainly an issue in many companies, large and small. They usually only do it once before proper safeguards are put in place, but such things are usually considered optional until a mistake actually happens, and even then lessons are often forgotten once the team members involved leave.
I'd also say that this is the most preferable explanation. If this wasn't someone having a brain fart while running QA tests, then the next best explanation is that it common for this system to have tests run in the production environment, with the only safeguard in their explained setup being that they turn off alerting before uploading fake data (then presumably have to remember to turn it back on afterwards). That seems to me like an even worse violation of good practices than the above.
[ link to this | view in chronology ]
Re: Re: Re:
They need to SOD off..,Separation of Duties
[ link to this | view in chronology ]
Re: Re: Re:
"They usually only do it until business-critical disaster ensues before proper safeguards are put in place..."
Had to fix that for you. If the result of a bad run is "merely" widespread internal panic, nothing much will be done to fix things.
"...but such things are usually considered optional until a mistake actually happens, and even then lessons are often forgotten once the team members involved leave."
Or until the tech team in Calcutta or Burma have had yet another complete turnover of personnel and the guys who knew how to deal with your company's systems are all gone in favor of newly hired rookies. Anyone who relied on Satyam, the Indian IT Enron, up to 2009, knew that this could be often enough the superuser had to re-teach the tech team how to code in the system once every three months or so.
I swear, you only need to be told once "The data in the mirror repository must be correct, so if you please fix the data in the source(!) there will once again be parity" to realize your IT environment is in the hands of the winners of the lowest bid.
[ link to this | view in chronology ]
Re:
If, as seems likely, the system is a multi-agency system, then sometimes tests are required on the live system. In which case obvious test data is the way to go, and the data sent meets the bill. Not exposing test systems on the public Internet is a higher rule that do not test live systems.
[ link to this | view in chronology ]
Re: Re:
In that case one would assume the test would include some sort of informational announcement of the fact that is was just a test, you know .. just in case someone wanted to know.
[ link to this | view in chronology ]
Call 987-654-3210 to report information to Saturday Night Live?
[ link to this | view in chronology ]
You should be glad that they didn't use a photo from Bride of Chucky;
https://m.media-amazon.com/images/M/MV5BYjNlYzFiNDYtYmRmZS00MjkzLWJhMGMtNTlmYWJlMjY2OWEzXkEy XkFqcGdeQXVyNDg3MzYyNTU@._V1_.jpg
[ link to this | view in chronology ]
Can I just say how I love the fact that the creator of Chucky thought it important to mention that “the kid is non-binary”?
[ link to this | view in chronology ]
Re:
The kid is from Seed Of Chucky, the most deliberately off the wall comedic entry in the franchise, where Chucky and Tiffany's offspring (yes, they're dolls, yes they had sex and had a baby in the previous film) is openly battling gender identity in between cameos from Redman and John Waters.
It would almost be more surprising for him not to mention it when commenting on the profile.
[ link to this | view in chronology ]
not funny doll
[ link to this | view in chronology ]