Readit NewsLet's look at point 2.28: "Several factors made the identification and rectification of the failure more protracted than it might otherwise have been. These include:
• The Level 2 engineer was rostered on-call and therefore was not available on site at the time of the failure. Having exhausted remote intervention options, it took 1.5 hours for the individual to arrive on-site to perform the necessary full system re-start which was not possible remotely.
• The engineer team followed escalation protocols which resulted in the assistance of the Level 3 engineer not being sought for more than 3 hours after the initial event.
• The Level 3 engineer was unfamiliar with the specific fault message recorded in the FPRSA-R fault log and required the assistance of Frequentis Comsoft to interpret it.
• The assistance of Frequentis Comsoft, which had a unique level of knowledge of the AMS-UK and FPRSA-R interface, was not sought for more than 4 hours after the initial event.
• The joint decision-making model used by NERL for incident management meant there was no single post-holder with accountability for overall management of the incident, such as a senior Incident Manager.
• The status of the data within the AMS-UK during the period of the incident was not clearly understood.
• There was a lack of clear documentation identifying system connectivity.
• The password login details of the Level 2 engineer could not be readily verified due to the architecture of the system."
WHAT DOES "PASSWORD LOGIN DETAILS ... COULD NOT BE READILY VERIFIED" MEAN?
EDIT: Per NATS Major Incident Investigation Final Report - Flight Plan Reception Suite Automated (FPRSA-R) Sub-system Incident 28th August 2023 https://www.caa.co.uk/publication/download/23340 (PDF) ... "There was a 26-minute delay between the AMS-UK system being ready for use and FPRSA-R being enabled. This was in part caused by a password login issue for the Level 2 Engineer. At this point, the system was brought back up on one server, which did not contain the password database. When the engineer entered the correct password, it could not be verified by the server. "
Which shows that sometimes, remote isn't a viable option. If you have very critical infrastructure, it's advisable to have people physically very close to the data center so that they can access the servers if all other options fail. That's valid for aviation as well as for health care, banks, etc. Remote staff just isn't enough in these situations.
/* This should never happen */
if (waypoints.matchcount > 2) {I'm sure there'd be a better way to handle this, but it sounds to me like the system failed in a graceful way and acted as specified.
Is this some kind of marketing flex? "We are so recognizable, we can afford drop the only thing from our name that makes it make object level sense"?
Other examples: Transferwise -> Wise (despite them still doing transfers as their main business), WeWork -> We (ok, to be fair in my experience not so much work got done there at the best of times) etc.
These things also usually completely kill SEO. Like, how am I supposed to google for the nearest coworking space? "we near me" sounds ridiculous to type into a search engine.
It looks to me like ChatGPT Search hides links much more. Is there any incentive for website owners to allow access to ChatGPT?
Is there something about German electrical systems that let's this just work? I feel like everything I've read about solar for the US isn't this simple.
Germany has many rented apartments compared to eg the US. If you own a house, those systems make little sense. But for Germany, where many rent an apartment, it’s attractive for many. And the only way for many to ever profit from solar.