4 ms·

Wait, let me get this straight. 1. there's no monitoring in place 2. fail over is manual 3. there are no standby servers 4. nothing auto scales 5. ba

Wait, let me get this straight. 1. there's no monitoring in place 2. fail over is manual 3. there are no standby servers 4. nothing auto scales 5. backups are not tested 6. they lack sufficient manpower 7. there are no clusters 8. the service is one error away from an outage It sounds like they completely ignored the operations side of running a service, and finally defaulted on technical debt. Yikes! I hope the best for them, but they have to start taking operations seriously.

amelius 9y ago
Makes you wonder: if failure handling is so low on the budget/priority list, where does security stand?
- katastic 9y ago
  Even lower, if my experience with clients is any clue. Most people I've seen running companies are either clueless in general in IT matters (business or engineering people), or, "older" gents who grew up long before IT security and robust backups were "the norm" and stressed in every class and conference. If there's no direct money to be made, it doesn't matter. Only in the last 3 years or so have I seen ANYONE of my clients care about potential hackers and breaches. And one of them only cared... because they were hacked by the Chinese.
jasonlotito 9y ago
You are making a lot of assumptions based on that blog post. Unless you have other information, I'm confident you don't have it straight and that you are wrong.
viraptor 9y ago
None of those points are confirmed by the post. Maybe apart from the sufficient manpower to handle support during emergencies. (But who has that, honestly?) Some of your points are almost dangerous. Not automatically failing over something handling large number of financial transactions may be a good decision, unless you can guarantee consistency between environments. Same goes for autoscaling databases (if you can even autoscale them in that environment - I'd expect them to be write-heavy and transactional, which is a good reason for scaling up, not out (or sharding or other things, not the point))
andrewguenther 9y ago
I don't know if you can make a single one of those assertions based on the content of the post.

amelius 9y ago

Makes you wonder: if failure handling is so low on the budget/priority list, where does security stand?

katastic 9y ago
Even lower, if my experience with clients is any clue. Most people I've seen running companies are either clueless in general in IT matters (business or engineering people), or, "older" gents who grew up long before IT security and robust backups were "the norm" and stressed in every class and conference. If there's no direct money to be made, it doesn't matter. Only in the last 3 years or so have I seen ANYONE of my clients care about potential hackers and breaches. And one of them only cared... because they were hacked by the Chinese.

jasonlotito 9y ago

You are making a lot of assumptions based on that blog post. Unless you have other information, I'm confident you don't have it straight and that you are wrong.

viraptor 9y ago

None of those points are confirmed by the post. Maybe apart from the sufficient manpower to handle support during emergencies. (But who has that, honestly?) Some of your points are almost dangerous. Not automatically failing over something handling large number of financial transactions may be a good decision, unless you can guarantee consistency between environments. Same goes for autoscaling databases (if you can even autoscale them in that environment - I'd expect them to be write-heavy and transactional, which is a good reason for scaling up, not out (or sharding or other things, not the point))

andrewguenther 9y ago

I don't know if you can make a single one of those assertions based on the content of the post.