Trying to cultivate a best practice plan for patching RHEL/SLES Environments

I am working a plan to create a best practice schedule for patching my environments. I know everyone has a different opinion on this but I am looking for a Positive way to move forward on this topic. I have 3 environments Test, dev test and Prod. Just looking for a push start if anyone has went through this some example schedules would be appreciated. Thanks
Raymond BarberSenior Linux Systems EngineerAsked:
Who is Participating?
tfewsterConnect With a Mentor Commented:
Ah, that little word "schedule". So easy to say, so hard to do!

I've attached 3 Word docs - written for patching HP-UX systems, but easily adapted.
- A Company policy for patching systems. That may seem like overkill, but if you get resistance from the business when you come to patch systems, it's useful to have an approved policy to point to, to back you up.
- A procedure for each patch cycle: Planning, preparation, patching test servers, QA'ing the change, then patching Production (=="the planning spreadsheet")
- A  detailed Work Instruction for patching - This is very specific to HP-UX, but the approach may be useful to you, as it covers backups, patching firmware and the OS. (=="script the patching routine with zypper").
Dmitri FarafontovConnect With a Mentor Linux Systems AdminCommented:
List all servers on an Excel sheet. Schedule / script the patching routine with zypper. Have fun :-)
The comments cover the extremes between patching approaches: JFDI versus extreme caution. The long-winded approach worked for me in a change-resistant organisation with mission critical systems, but can be cut down and/or accelerated as needed to adapt to your circumstances.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.