Knightmare: A DevOps Cautionary Tale (2014)
dougseven.com
Knightmare: A DevOps Cautionary Tale (2014)
1–10 of 294 posts
Re: Knightmare: A DevOps Cautionary Tale (2014)
#2They were missing any kind of risk mitigation steps, in their deployment practice.
Re: Knightmare: A DevOps Cautionary Tale (2014)
#3Needs (2014) in the title.
Re: Knightmare: A DevOps Cautionary Tale (2014)
#4[deleted]
Re: Knightmare: A DevOps Cautionary Tale (2014)
#5They were missing any kind of risk mitigation steps, in their deployment practice.
There’s no money for that.
Re: Knightmare: A DevOps Cautionary Tale (2014)
#6[flagged]
Re: Knightmare: A DevOps Cautionary Tale (2014)
#7[flagged]
And remove easy/quick liquidity for the rest of the market?
Edit: downvotes, any reason why? Or just HFT == Bad?
Re: Knightmare: A DevOps Cautionary Tale (2014)
#8They were missing any kind of risk mitigation steps, in their deployment practice.
There’s no money for that.
It is funny, but in one company I was working for, the more people they added the more they neglected all basics, such as backups. There were heavy processes for many things and they were followed very well, but for whatever reasons some really basic things went unnoticed for many years.
Re: Knightmare: A DevOps Cautionary Tale (2014)
#9Re: Knightmare: A DevOps Cautionary Tale (2014)
#10No continuous deployment system I have worked with would have blocked this particular bug.
They were in a situation where they were incrementally rolling out, but the code had a logic bug where the failure of one install within an incremental rollout step bankrupted the company.
I’d guard against this with runtime checks that the software version (e.g. git sha) matches, and also add fault injection into tests that invoke the software rollout infrastructure.