> Like other computer systems that are critical to operating flights, the FAA has imposed procedures to ensure data aren’t damaged by technicians working on them, said the person. The file or files were altered in spite of rules that prohibit those kind of changes on a live system.
> Agency officials are attempting to determine whether the two people made the changes accidentally or intentionally, and if there was any malicious intent, the person said.
It is clearly implied that had the rules been followed, the corruption wouldn't have occurred.
Your blame-the-FAA scenario where the rules were incomplete or flawed isn't ruled out, but I don't see value in asserting it without evidence. I think it's perfectly plausible that someone just cheated a bit. That's hardly a rare situation in any IT environment, and so it seems like Occam favors the article's interpretation.
It can be justified as "the instructions are out of date", "this is an urgent change", "just get it done!", etc.
Heck, sometimes following the written rules is derided as "working to rule" or "takes longer than others to complete the task".
I'm just saying that blame for these issues only sometimes belongs on the line workers.
In large org thinking, if something bad happens, and you add a rule, then it's fixed.
The problem is that this is not compatible with human psychology.
This leads to many rules, the rules are unstructured and impossible to learn, the rules probably also contradict each other.
In my experience, a rule without automatic enforcement should be the absolute last thing to depend on. If you do this, your org is broken.
The Toyota Production System with it's blame on process design instead of humans is still the best way to avoid these issues IMO.
Do 5-whys where human error is not allowed as a root cause. Design your process with poka yoke in mind. If somebody can forget something they will. Don't depend on it.
It explains that procedures were circumvented and something in production was edited - something that was not allowed.
You can put as many procedures in place as you want, but unless the humans follow these procedures (I.e. not circumvent them deliberately) then someone always has some level of access where they can cause mayhem.
Sure you can programmatically enforce this to a large extent, but ultimately there are always some humans with prod access, or BGP editing access, or firewall write access, or access to that validation logic itself! And it requires that the humans follow the organisational procedures in place.
From what the article says, it sounds like the humans deliberately circumvented procedures, in which case, it is the engineers fault, and they should be disciplined.