|
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] Simple steps to create a backup SLA
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
Creating service-level agreements (SLAs) can be a nightmare, especially when it comes to backup. Follow this simple recipe and you won't go wrong:
- Organize backup as a service, focusing on standard offerings that will meet the needs of the majority of the business.
- Declare that you'll be responsible for determining how to meet your customers' requirements and won't interfere with what they need.
- Document your service offerings in concrete, relevant terms and avoid technical jargon.
- Suggest a service level for each business area, discuss its merits and costs, and accept your customer's decision.
- Proactively report on your compliance with the SLA.
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE]
Speeds and feeds mindset
One of the greatest failings in IT is its focus on technology. Too often, we get so wrapped up in "speeds and feeds" that we lose sight of what the expensive technology is supposed to do for the business. This mindset is common in service negotiations: IT-written SLAs become ultra-technical, losing their relevance to the business. When developing an SLA, be sure to write the service requirements in terms that are less technical so more business-focused people will understand them.
Two terms always emerge when tryi...
To continue reading for free, register below or login
To read more you must become a member of SearchStorage.com
ng to rephrase data protection as business-speak: recovery point objective (RPO) and recovery time objective (RTO). The former refers to the amount of data that can be lost before a recovery, while the latter is the amount of time required to restore data. But these terms are inadequate for the SLA discussion with business units. Instead of relying on imprecise jargon like RPO and RTO, it's much more beneficial to bring the data protection discussion down to earth (see "Simple steps to create a backup SLA," at right).
The primary purpose of backup is to recover data after an outage, while its secondary purpose is to recover archived historical data after an extended time. Your discussion of service levels should focus on the following questions without veering into the realm of jargon--simply talk about the data.
- What applications do you use?
- Are there any parts of the day, week, quarter or year when these applications are unused or particularly busy?
- How important are these applications to your job and to the company as a whole?
- What impact would there be if a moment, minute, hour, day or week of this data was lost?
- How long could you or the company wait for this data to be restored in the event of a serious computer problem?
- Is there any benefit in having an historical copy of the data from a day, week, month, quarter or year ago?
- How much money can the company realistically afford to spend to achieve these goals?
It's best to have your own ideas about the answers to each point before having this conversation. You could even phrase these questions in the form of a statement, such as "I understand that e-mail and the CRM database are particularly important to your department." Just make sure you don't pre-empt an honest dialog or let your own notions of the answers interfere with the progression of this negotiation.
Once this discussion takes place, most of the elements of your SLA will have fallen into place. Take your notes from the meeting and fill in the SLA form yourself. Then return with the completed SLA and verify the elements in plain language such as, "We decided that a week's worth of content in the recruiting database could be re-entered if needed."
|
 |
|
