This general process for an upgrading can be used for security updates to Drupal core, upgrading contributed or customer modules, or migrating theming and other changes from a development or test environment to a production environment.

An upgrade should be performed in off-hours, a site used mostly during regular business hours a Friday evening may be ideal as you would have all weekend to recover from a disaster without a major service interruption. Another option that I like is to upgrade in the early morning hours on a weekday, with customer representatives available to QA the site after the upgrade, made possible by their planning an early arrival to work. Importantly you should warn the stakeholder/customer and give them outage periods, that should that be estimated and communicated in a timely manner and it is critical to have a fall-back plan in place in case of unforeseen problems.

If you are updating modules read the help text files the developer has created to follow recommended upgrades. Look at the module issue queue for issues that could happen when you update. If you are doing a number of module updates create a document of likey SQL changes and group into small sections with dependencies together. This should give you a path to follow and highlight likely issues that you may encounter in more problematic updates.

• Run the Cron and Cache, turn off all caching.
• Create a script to dump the data base, this is to be sure we have a dump readily available with no reliance the internal Drupal System backup processes. Create a script to import the data base. This would only be used in the event is was necessary to abort the upgrade and perform a roll-back. If you use phpMyadmin you can create a SQL export dump file from here and import the file in case the core system has locked up.
• Do a full SVN (Version Control) Checkout into a new directory at the same level as the current production directory or download and install a fresh copy of Drupal into a new directory, deleting the /sites directory. Copy any directories needed from the current production directory into the new directory, e.g. /files /sites etc. Be sure to set the file permissions (chmod) and file owner (chown) if running the site on a Linux based server.
• Put the site in off-line mode. 6. Rename the production directory, this is better than making a tar because a roll-back of the file system can be made by simply renaming the directory back to its original name. 
• Rename the SVN Checkout / Drupal New Install directory to the production directory name.
• Run update.php.
• Implement any settings required by the upgrade, for example updating views or other module configuration settings using the Drupal interface.
• As a precaution you may want to use an internal backup like back up and migrate.
• Turn caching back on.
• Run Status Report - check for exceptions.
• Return site to on-line mode.

If you leave the core files alone most updates from core will run with out a hitch. These days the updates are well tested from the community, however I believe in being cautious in updating especially when you working with large complex sites were there are a lot of variations to the system.