ASM Updates planning

It depends what you mean by "update ASM." New release? Update attack signatures database? Deploy a new policy? Something else? I would think that most gents (and ladies) will agree that it is an industry best practice to perform any updates in a manner that minimizes the impact and visibility to your business (customers) and maximizes the opportunity for confirming success before committing the changes permanently. Obviously, this is more critical for changes that are complex with wide ranging business impact, as compared with changes that are relatively simple (and well-understood) with minimal business impact. It is really your choice how much risk of business disruption you are willing to accept as compared to the business need to make the change. That's just Change Management 101.

Updating ASM Attack Signatures is generally considered extremely low impact, enough so that automatic updates are actually recommended, even in a prod environment:

https://support.f5.com/csp/article/K8217

You will have sufficient time to analyze any possible false positives as new signatures are placed into staging.

However major updates to a policy should have their impact fully understood before committing. If a full dev environment is not available at least a dev VS with a test policy may be the best option.

When it comes to full OS upgrades though this will always result in at least a brief outage. Best practices with an HA pair is to upgrade the standby unit of the pair first and failover to it once it becomes available again. Upgrade the previously active unit and then fail back to test. This way you have only two very quick failover events and you are effectively testing both units in the pair.

The question is fairly wide though. One should always adhere to their company change policies and fully understand impact before any change is made.