Back when I was a systems engineer, I built a couple of systems that come as close as I'm ever likely to see to zero-maintenance. One of them is a piece of aut

Back when I was a systems engineer, I built a couple of systems that come as close as I'm ever likely to see to zero-maintenance. One of them is a piece of automation that looks for Active Directory accounts that are "inactive" based on a variety of criteria (including correlation with data not stored in AD). If they're considered "inactive", then they're disabled and their description is updated to indicate when they were disabled and why. I originally wrote it as a 6-12 month stopgap until it was replaced by a fancy commercial account lifecycle product. I believe it's now 7 years later and it's still in use by the team I used to be on when I wrote it. This may sound like a relatively simple task, but it actually wasn't, which is why (IMO) almost no one ever succeeds in building low/zero-maintenance systems. Some of the challenges I ran into: - Some users only use their accounts in ways that don't update the last logon timestamp in Active Directory. I can't remember all of the specifics offhand, but one was that at the time, there were still BlackBerry users, and if they only ever used their AD account for email, and only read email on their BlackBerry, the timestamp wouldn't be updated, so the automation had to query the BES database to look at their last usage their too and use the most recent of that vs. AD. I think there were 3-4 things like this, and the automation used the most recent of them all. - Employees go on maternity and military leave, and disabling/deleting their account would make for them being really unhappy when they got back. So the automation also has to check the HR system to see if their record is flagged as being on some sort of extended leave. - The government requirement that spurred the development of the automation only applies to accounts for people. There are plenty of service accounts that log on infrequently enough that they would be disabled, so the automation also has to differentiate between those accounts and accounts that represent people. In addition to the basic functionality, I also felt that it had to have significant safety features in place, because if something goes wrong and all accounts get disabled, then no one can log on to fix the problem. Among some of the other safety features: - With each iteration, the automation calculates how many accounts will be disabled during the next iteration as well. If that number exceeds one threshold, warning emails are sent to the account administration team. If it exceeds a larger threshold, it will refuse to operate altogether. - If no information was obtained from one of the data sources that it uses (e.g. a database was moved to a different server and the connection string wasn't updated in the account automation config), it will refuse to operate and generate warning emails. - I don't remember the details, but there are special conditions for things like "too much time elapsed between iterations" and "the last iteration took place after the current iteration" to catch edge cases where there are problems with time synchronization. I was able to build the automation in a way that made maintenance as close to zero as possible. In the ~7 years it's been running, AFAIK the only thing that's needed to be changed were the thresholds for number of accounts disabled in a single iteration, because the company expanded its use of AD and suddenly it became normal to operate against a thousand or more accounts at once instead of e.g. 200. A database connection string might have been updated when a DB got moved to another server as well. Anyway, trying to predict all of the things that can go wrong even for such a simple system turned out to be a lot of work. My experience is that it gets dramatically worse as the system itself becomes more complicated (e.g. complicated enough to be a commercial product as opposed to an engineering maintenance task). I don't think it's really practical to do it with significantly more complex systems - modern computing involves too many changing variables. For an analogy, consider trying to build a zero-maintenance system that waters and fertilizes a garden in a way that keeps the plants healthy. It wouldn't be that hard to build one that would handle the current garden. Imagine trying to build one that would handle literally any plant that someone could put in the garden. It's not impossible, but you'd need all kinds of wacky sensors and logic to figure out what each plant was and how frequently to water/fertilize it. It's much easier and less error-prone to just require that the gardener update a table that lists what types of plant are in which part of the grid, and maybe generate an alert if something changes that indicates that the table may no longer be up to date.