[EMAIL PROTECTED] wrote: > 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 > At $WORK we have SLAs with most groups that have a four day SLA *for the first response*. Change requests for production systems (which include the network) have a 10 day mandatory minimum lead time (except for emergencies, system crashes and such - which must be signed off by a director), so a typical lead time for such changes (if we did them) would be 14 days or more. Anything relating to network security changes can take longer, as they must be reviewed by our InfoSec team. In the past when I've arranged for external network tunnels, 30 days was not an unusual lead time. There has to be a defined, real business need, supported by an executive, before tunnels will be created. (This is a great gating factor all by itself.)
We don't punch holes in our firewall for the outside world into our inside net - we have two arrangements that we use for external systems. For generally available applications (like our corporate web site) there is a 'dirty net' where the hosts that service the public reside. There are a few, very highly controlled paths between the dirty net and the inside net. For our partners (consulting sites, some business partners) we set up controlled tunnels between specific nets (and sometimes specific port ranges) between a subnet on our site and the partners' networks. An SLA is a Service Level *Agreement*. It must be negotiated between the parties, and both sides need to be aware (and respect!) the lead times that have been agreed to. With our own team, we get people who constantly try to get around the trouble ticketing system by contacting team members immediately after opening a ticket, or without opening a ticket at all. Our policy is to give these people a copy of the SLA information. We do have processes for opening a high priority case - we have an Operations team that manages all P1 and P2 cases (24x365). If someone has an issue that they believe is urgent enough to open a P1 or P2 case, they have to be able to show justification due to impact, or suffer the wrath of senior management afterwards if they were just crying 'wolf'. There are separate SLAs and processes for dealing with regular business issues relating to major releases of software (which we do quarterly) and the Release Managers have direct access to a member of our team, and we have direct access to specific members of other teams, to keep the software releases moving and on track. I'm giving this as an example - what works for us in a large, network-related company may not be an exact fit for your company, but the concepts of SLAs and the related business processes and exception management might help you. It pays to get all of these processes nailed down in your SLAs, and then require all parties to live up to them. You do need the exception management defined in the SLA, as there will always be real reasons to declare something urgent. By putting the escalation processes into the SLA, along with the consequences of misuse (a lack of planning on your part is not an emergency on my part :-), you have a much better chance of getting your case load under control. Without it, you have chaos (what you are experiencing now). The customers are probably going to kick and scream about their being 'forced into an SLA', but will be happier in the long term - they'll learn to ask sooner, and find that their requests are being serviced on time. You need executive backing to make these SLAs stick - it helps to have someone who is a common connection higher on the food chain to bless the SLA mechanism, even if he or she is not involved in the actual SLA negotiation. - Richard _______________________________________________ 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/
