OPERATIONAL CONCERNS
It’s important to monitor at the level of detail that will let you know with
condence that if the site is down that you will be notied there is a
problem. You can do this by pinging the server, checking the status of
services, testing health-check pages, etc. Failure of the system to respond
in the expected way may be a reason to alert administrators or take
automated actions to take the server out of the load balancer. Dening
what the monitoring policies are, including who will be notied when
there is a problem with the server, or with an individual site will eliminate
confusion as to who owns the resolution of server problems – including
problems with specic sites.
The fundamental building block of disaster recovery plans are backups.
Backups of the data, failover hardware, and redundant connectivity. The
way that backups are performed is essential to the SharePoint governance
process because it establishes expectations on what is recoverable or not.
Dening the process for requesting recovery and the timeline for that
recovery further establishes the kind of expectations from SharePoint
that improve adoption. Be sure to consider a variety of disasters: natural
(ood, re, tornado, earthquake), server (ofine, dead), user accidents (le
deletion, saving issues, crashes), and site (failure, corruption, error).
Centralized SharePoint platforms must be concerned about total storage.
SharePoint can rapidly become the new le storage platform within an
organization – and as a result consume massive amounts of storage very
quickly. One of the ways to combat this problem is to establish quotas for
sites as they are created. Each site is given a small amount of storage and
they’re allowed to request more as they need it. The governance process
should include the amount of space initially allocated by type of site
being provisioned as well as the process for requesting more space.
monitoring
disaster recovery and backup
storage and quotas