On Tue, Nov 18, 2008 at 4:50 PM, <[EMAIL PROTECTED]> wrote: > On Tue, 18 Nov 2008, Tom Limoncelli wrote: > >> On Tue, Nov 18, 2008 at 12:36 PM, <[EMAIL PROTECTED]> wrote: >>> >>> my security team is currently recieving ~500 change tickets a month (not >>> counting patching, upgrades, etc) with a 2 business day SLA to complete >>> them. we are getting a lot of people screaming that we should be more >>> responsive and implement the changes faster. >>> >>> I'd like to hear from other folks as to what sort of change rate and >>> schedule is considered reasonable for large orginizations. I'm especially >>> interested in hearing from anyone in the financial sector. >> >> Can the tickets be categorized into 5-15 different "types" so that you >> can assign different SLAs to different requests types? > > we've done a little of this (seperating out 'research this' 'write a new > script to do that' from 'make a new firewall hole for this other thing'), > but we are trying to find out what is considered 'reasonable' SLAs for > different types of things
Have you interviewed customers about what they'd want in an SLA? They probably have a model of what they consider small, medium, and large requests. If you can match the perceived amount of time that something should take to the actual time, people will be happy. Typically it looks something like: 1. small tasks that are blocking them from doing another task (add 1 machine to a pre-existing ruleset, resetting a password so that a person can get her work done, etc.): Expectation: immediate 2. medium tasks: same day 3. new services: consulting time plus implementation. 4. emergencies: drop everything and get working on it. The problem is that sometimes there is a mismatch between what customers and sysadmins think a task is. For example, one a customer asked for a calendar system to be set up and thought it could happen that day. The mismatch was that she thought we already had such a system and was just asking for an account (should be quick) but the sysadmins didn't know that and thought she wanted the entire eval-procure-install cycle to happen in 24 hours. A little communication resolved the issue: once she understood we didn't already have a calendar system she herself pointed out that this wasn't a Category 1, but was a category 3. >> Is there any way to make the process more self-service? For example, >> could the customers be given a dashboard that lets them control the >> more simple requests (add/change a single machine)? > > we are working on this, but the volume I listed is what's left (there's a > team of a dozen people working these 500 requests/month in addition to > projects, it's not a small company) > >> If the requests currently come in via email, could they instead use a >> web-form that would sanity check the request, possibly run it through >> a regression test suite, then just simply ask for a human to approve >> it? > > there is a web ticketing system. > >> Could you delegate some of the control? For example, if these >> requests come from all over the company, maybe each division could >> have an "approver" that is able to aprove the common requests, leaving >> you to only have to deal with the special cases? >> >> Is there a class of request that the helpdesk could be empowered to >> handle on their own? For example, if some of these requests are >> password resets, you could permit helpdesk people to follow a very >> spelled-out procedure to do resets for, say, accounts of non-managers >> and non-executives. >> >> These are just the thoughts that come to mind without understanding >> who the customers are or what constitutes a "security request". If >> you are allowed to be more specific (I understand if you can't) please >> do. > > the bulk of these are firewall changes. As such we are not comfortable with > the self-service approach. There aren't specific categories of changes that can be self-service? If a pre-existing subnet has a new host that needs to be able to talk on a port, couldn't that be a matter of automatic approval with proper logging and notification? If this is a sox issue, logging and notification are often sufficient... one doesn't need human intervention. It's just a thought. Some ways to inspire creative solutions: - Take the 100 most recent tickets and categorize them on a whiteboard (or spreadsheet). I always learn *something*. - Figure out how many tickets each customer generated in the last year. It is likely that a small subset generated 10% of all tickets. Look at their tickets and see if there are patterns. I once had a boss that did this to discover that 3 people were generating 10% of all tickets. After looking at their tickets he found: (1) one person was having sysadmin do his job; solved that problem by talking to management. (2) one person was requiring extra support because they hadn't upgraded to the latest release; solved that problem by being stricter about not supporting legacy apps. (3) one person was generating ignorant tickets and was sent for training. Hope some of that is helpful, Tom _______________________________________________ Discuss mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
