On Tue, 18 Nov 2008, Tom Limoncelli wrote: > 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
this is where most of the tickets fall. individually they will take about 5 min to do (plus another 5+ min with the ticketing system, but that's a seperate problem). one issue is that these tickets (which are usually holding things up) are usually submitted at the end of a 3-6 month project, when there is not a good reason why they could not have been submitted weeks prior. another issue is that while one ticket may take 5 min to do, 10 similar tickets will take about 7 min to do. so there is a huge gain in efficiancy possible if we can have a longer SLA for these routine, long-lead-time (or at least they should be) tickets. however to do this we need to be able to show that other similar orginizations don't work this way. I know that many of our customers don't work this way, becouse when we need to coordinate changes to their firewalls we get told SLAs along the lines of firewall changes are done one day a week to one day a month, with all changes needing to be submitted at least a week prior to the implementation date. David Lang _______________________________________________ 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/
