#PATCHING
If you are responsible or involved in patching, I have probably been you. Helpdesk, syseng, packager, server operator, coordinator, policy maker, and chastened bringer of disaster.

Here are some thoughts on my outlook on this critical area of IT, and what I’ve learned.

There are several areas that complicate the practical teaching of patching policy to IT entrants by veterans

1) Radical improvements in update quality/vendor abilities
2) Network bandwidth
3) Cargo cult best practices
4) Once Bitten, Twice Shy
5) Lack of troubleshooting ability

1.) Update quality has gotten better over time through practice.
Vendor abilities to reliably apply updates has matured through practice.

I started professionally in 2007 and have spent all time since on-the-ground. Things are radically better in every way compared to the past.

2.) Business network connections have utterly exploded in bandwidth capability. Where in the past you needed to carefully manage and cache/distribute update files or risk saturation, this is essentially a non-issue except for Windows updates in some high-density use cases.

3.) Reoccurring operational requirements are always more expensive, more fragile, and more staff-dependent than they appear.
This is especially true for patching. You must START at automatic uncontrolled updates, and work back from there where control is physically unavoidable.

How it happens:
~~
1.) We should control patching
2.) Disable automatic updates
3.) Distribute updates
4.) Novelty fades
5.) We’ll do it quarterly
6.) I’m busy
7.) Staff moves to new job
8.) New staff inherits mindset but doesn’t have operational confidence
9.) 2 years no updates

You do not understand this until later. You are passionate and care. You want to do the right thing. You are better than the other people you read about online.

But you are naive. Few people are _actively_ deficient. Instead there are mostly people you don’t see yourself in yet.

You see people like me, who have by chance become hugely visible, complain about patches and Microsoft and blah blah blah.

From the view of an apprentice, that is operational advice. Wise words carefully selected.

But they are complaints from interruption of desired tedium.

And you have people with no operational IT experience taking stock of what to do. So they recommend controlling updates and being conservative.
I have nothing against them. But they are like you. Naive to what that means.

I spent 10 years at my previous org. I know what it means

Do you know what it means, to spend ten years at an organization? In essentially the same position?

It is to be privileged to the passage of time. To be subject to the consequences of your own choices.

To learn from what yourself in the past, did to yourself in the present.

Most importantly - it is to be subject to your failures across time, to correct them, and see the differential results without variables altered.

It was pain and despair and innumerable things I don’t wish on others. But it taught me: There is no plan without accounting for time

And this plan must account for time, without you.
I learned more from the last three weeks in my last job than the past year.
Because I had to tear down so much of what I had built, as someone complacent in being there forever.
Without me it would cause more problem than benefit.

I see IT as being a caretaker of an atrium. These plants are not solely yours, nor are they subject to your lifecycle, nor are they tethered to your delicate hand.
They are greater creations whose continuance isn’t solely a question of the judgement of you towards their master.

4.) Failure of a patch is often treated as unexpected mystery. Vendors sometimes total dicks, but if you read patch notes as someone interested in full architecture you _often_ quickly understand what went wrong and why. Not a programmer but can regularly diagnose fixes gone awry