Site Support Team - Documentation
Ticketing Policies

Savannah tickets

Monitoring

  • Use this page as a starting point
    • This is generated with a script that can be found in CVS, and is run from the relval account on lxplus: /afs/cern.ch/user/r/relval/www/webpage/savannah/.scripts
    • It runs once a day as a cron job:
      • 0 5 * * * lxplus.cern.ch . $HOME/www/webpage/savannah/.scripts/parseSavannah.sh

  • Go through all the tickets once or twice a week
    • Categories to keep a look on (in order of priority):
      • Facilities
      • New sites
      • SAM
      • CMS HC
      • Data
  • Any direct question from anyone on a ticket should be answered in a few business days
  • Sites should acknowledge new tickets within a day or so
  • No ticket should go un-updated for more than 7-10 days
    • Only real exception: if the last update to a ticket gives a concrete timescale for when it'll be solved (eg, "Admin is on vacation, will look into this when they return March 7")
  • If these timescales are exceeded, either respond in the ticket or mail the person/people directly asking if there's an update
  • To find folks' contact info
    • look in carbon copy list on savannah ticket
    • look in sitedb
  • For extended non-response escalate to GGUS: like this

Categorizing

  • Use the Facilities category as a catch-all for facilities tickets, eg if you're unsure who to assign it to

Miscellany

  • Don't leave tickets open for more than 1 business day to check if the problem is really solved.
  • Don't reopen tickets if the same problem occurs, open a new ticket and refer to the old ticket in the comments.

Available statistics (updated daily)

Measures

Following measures can be taken by central operations for sites that don't hold up a reasonable quick response time to site issues.

  • If tickets are not answered or updated for more than 3 business days
    • Bridge to GGUS or if already bridge use the escalate button in GGUS
  • If tickets are not answered or updated for more than 7 business days
    • Reduce ESP credit by 1/52
    • Reduce credit for every ticket that exceeds 7 business days

Special cases

  • user opens savannah ticket to site, site solves the problem but cannot assign the ticket back to user because he is not member of the compinfrasup savannah group
    • site should either keep the ticket or assign to compinfrasup-anaops
  • site filled up the disk (data manager oversubscribed or local users went out of bounds)
    • immediately deactivate all links
  • others?

Old

Intend is to better organize the support of T2 sites through savannah tickets and clarify the roles the sites and also central operations have in finding solutions. The goal is to have all T2 sites functional 100% of the time and quick turn around in solving issues and problems. Most common areas of support:

  • HammerCloud (replaced the JobRobot) issues
  • Transfer issues
  • Data consistency issues (files on disk vs. catalogues)
Most common central operations savannah squads:

  • cmscompinfrasup-dataops
  • cmscompinfrasup-datatransfer
  • cmscompinfrasup-hammercloud
  • cmscompinfrasup-sam
  • and others


This topic: CMSPublic > FacilitiesServices > CompOpsSiteSupportTeam > SiteSupportDocumentation > CompOpsPoliciesSiteSupportTickets
Topic revision: r3 - 2013-05-30 - DuncanRalph
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback