Download
1 / 42
420 likes | 566 Views
Staff introduction to ALMA Helpdesk. J. Hibbard, NA ARC Manager A. Remijan, NAASC Helpdesk Manager NAASC “Train the Trainer” exercise 11/10/2010. Talk Organization. Part 1: Helpdesk international policies & deployment model: J. Hibbard (for Science Operations IPT)
E N D
Staff introduction to ALMA Helpdesk J. Hibbard, NA ARC Manager A. Remijan, NAASC Helpdesk Manager NAASC “Train the Trainer” exercise 11/10/2010
Talk Organization • Part 1: Helpdesk international policies & deployment model: J. Hibbard (for Science Operations IPT) • Part 2: NAASC Helpdesk implementation plan: A. Remijan • Part 3: Time to play
International Policies that impact helpdesk solution • "ALMA shall establish a helpdesk system through which users can submit questions or request help with ALMA products or procedures. These requests will be time-stamped, logged, and assigned a unique ID automatically. Users will access this helpdesk from the ALMA user portal." [AOPvE, Sec 4.7] • "The Head of Science Operations will work with the ARC Managers to set-up a helpdesk response process... The overall procedure must avoid bouncing the user back and forth and must aim at providing the user with a unique and consistent answer. All helpdesk questions and answers will be logged." [AOPvE, Sec 4.7] • "Users must be registered with a trusted system in order to submit helpdesk ticket." [Helpdesk Reqts, RQ-25] • "If the helpdesk is a distributed application, it must have a similar 'look and feel' and functionality (ticket characterization etc.) on all servers." [Helpdesk Reqts, RQ-26] • The helpdesk will have a category for users to submit urgent issues with the proposal submission process. This department will be staffed for extended hours in the period leading up to the proposal deadline. [SciOpsRR] • "The helpdesk must provide tools to allow some level of ticket tracking for all submitted tickets, regardless of where they are (re)directed. This should include which tickets are unresolved, how long they have been open, to which ARC they are assigned, and various statistics (e.g. the number open/closed tickets assigned to each ARC, associated with each subsystem, submitted by various types of users, etc.)." [Helpdesk Reqts, RQ-39]
International Policies that impact helpdesk service rules (1/2) • "The local ARCs shall be the primary interface between the user communities and the Joint ALMA Observatory. Most communication between users and the observatory will go through the ARCs." [AOPvD, Ch11] • "Support personnel at or under contract to the ARCs will provide the required staffing to respond to helpdesk tickets." [Helpdesk Reqts, RQ-03] • "The ARC to which a users helpdesk queries will be sent will be specified by an entry within their profile in the ALMA User Portal. It will be selected from among the users 'Eligible Affiliations'. User’s 'Eligible Affiliations' are automatically inferred from their institutional affiliations. In short, a user is eligible to be affiliated with any region in which they hold a professional post or appointment, or which they are associated with by means of a formal Memo of Understanding (MOU). The eligible affiliatons are EU (Europe), NA (North America), EA (East Asia), Chile, or else 'Non-ALMA member'. ... For users with more than one eligible affiliation, only a single ARC should be identified at any given time for providing users support." [Helpdesk Reqts, Sec 3.3]
International Policies that impact helpdesk service rules (2/2) • "Whenever possible, helpdesk tickets should be assigned to available User Support Specialists attached to the ARC to which the ticket was originally assigned. Only if the required technical expertise is not locally available should tickets be assigned outside the host ARC.” [Helpdesk Reqts RQ-35] “Transfer knowledge, not tickets” • Knowledgebase articles created from helpdesk solutions will be written in English. The ARC to which the helpdesk ticket is submitted will provide this translation. [rewritten from Helpdesk Reqts, RQ-44] • Knowledgebase articles must include all relevant data for understanding the solution, but be kept free from information that identifies the submitter or their institution. [rewritten from Helpdesk Reqts, RQ-46]
ALMA Helpdesk Selection • Requirements defined June 2009 • Systems considered: Remedy, JIRA, AIM & wreq (email based), Kayako • Visits to/with User Support groups at NRAO, ESO, STScI, Spitzer, Herschel to discuss “Lessons Learned” • https://safe.nrao.edu/wiki/bin/view/ALMA/HelpDesk • Chose Kayako SupportSuite for testing, “gap analysis” against requirements • Same system used by Herschel (& now Spitzer & NRAO) • Backend is MySQL database • Includes a self-help “Knowledgebase” feature – “published” answers to questions that are suggested to user as they type in their query • Adopted NRAO-wide and deployed since Feb 2010 (including CASA helpdesk). No major issues to date.
Result of Gap Analysis • All requirements met (some procedurally) • Lacks level of reporting we desire, but mysql queries can be custom built (and will be) • https://staff.nrao.edu/wiki/bin/view/Main/RevisedHelpDeskGap
Selected Centralized model, at least for Early Science Will be located at and maintained by NAASC
Service Model • Each ARC will provide staff to answer tickets from users that have their ARC assigned for support • “ARC for Support” is based on users’ institutional affiliation • Users from non-ALMA member regions can select from any of the ARCs • 5 days/week, regular workweek operations foreseen • Hours of Operation: • EA, EU: 8hrs/day, 9-5 local time • NA: 11 hrs/day, 9-5 ET by NAASC, additional 2-5 PT by HIA • Helpdesk is configured to allow tickets to be transferred between ARCs, although this should not be done lightly • Preference is to transfer knowledge, not tickets
Service Model (cont’d) • Workflow is left to the ARC, but general recommendation is a tiered level of support: • Triage: answer ticket if requires < ~15min; otherwise assign to support staff • Level 1: General support. Capable of providing answers to non-technical helpdesk queries, such as where to find documentation, how to download software or manuals, etc. • Level 2: Skilled support. General technical questions about radio astronomy techniques, etc. • Level 3: Expert support. Specific technical questions of a detailed nature generally requiring the help of a staff member who has specific expertise in radio/mm techniques (polarization, high frequency observing, etc.) or on a specific subsystem (CASA, pipeline, archive, etc). • ARCs will maintain shared wiki listing available expertise
Knowledgebase • Kayako tickets can be searched by staff or by submitter, but not by other users • “Knowledgebase” is a database of “published” articles written by any helpdesk staff and viewable by users worldwide • Published articles are “suggested” to users as they type in their helpdesk question • Therefore, we must make a concerted effort to make this database as comprehensive as possible • Articles can be constructed from actual helpdesk responses • If taken from helpdesk response, need to be generalized and have all identifying references removed • Existing knowledgebase articles can be quoted as replies to new queries • Goal: Any extensible tickets should become KB articles
Deployment Plan • Ready to be deployed; only depends on availability of User Portal • Plan is to deploy and staff when OT “pre-release” version is made available to external committees (R8.0 – December 2010) • Tests to be completed by CY2011Q1: • Capacity • Availability (worldwide) • Further Stress Tests • Disaster recovery
Helpdesk Part II NAASC Helpdesk – Implementation Anthony Remijan, NAASC Helpdesk Manager
NAASC Helpdesk Implementation • How the Helpdesk (HD) works • Impress the importance of the knowledgebase (KB) articles • How we are going to get things done • How people will expect to get their work, ie. How will tickets be assigned.
HD Ticket “Lifecycle” • GOAL: Answering HD tickets should be a transfer of “knowledge” not tickets. We will NOT reassign tickets among or across ARCs haphazardly. Instead, we should endeavor to find the answers to questions and transfer that knowledge to the KB. • In other words, don’t assign all CASA tickets to Crystal!
How the HD works – User viewCurrently, as a test, a username and password has been set up for the TTT session:Username: naasc-userPassword: naasc-user-11http://kayako-test.cv.nrao.edu/HOWEVER, must be on the NRAO internal (i.e. wired) network
How the HD works – User’s view Can search the KB without logging in...
KB Browsing • GOALS: • Use the KB as much as possible and many tickets should be added as KB articles. • The KB will be light on articles when we go “LIVE”. • The format of the KB article – both the title and article should be as descriptive as possible with key problems/features well defined!
Submitting Tickets and Departments • NOTE: ALL NAASC Staff must be able to answer a “Level 2” ticket submitted to ANY Department.
NOTE: Need to be careful on what we ask for each entry form for each department, BUT this needs to be agreed upon internationally (JHibbard).
How the HD works – Staff viewCurrently, as a test, a username and password has been set up for the TTT session:Username: naasc-staffPassword: naasc-staff-11http://kayako-test.cv.nrao.edu/staff/
Let’s change your “Preferences”... NOTE: Tabbing through the “grey” tabs will not update the frame!
The “Tickets” Taband the “Manage Tickets” view... NOTE: This is a USS view...from the workflow above, a USS can only re-assign to triage. A USS cannot pass a ticket to another ARC, for example.
The “Tickets” Taband the “Filters >>> Insert Filter” view...
The “Tickets” Taband the “Search” view... NOTE: USS feature...recall that users can search the KB but cannot search tickets. A staff member can do both...
The “Tickets” Taband the “Post Reply” view... NOTE: You can pull a “canned” KB article which will automatically be inserted into the text box. You would have hoped that the user would have found the article already but I am assuming this will be prevalent when the HD opens. There is also an area called “Predefined Replies” that can also be canned responses but these are not available to the community through the KB. A “Predefined Reply” could be “Thank you for reporting the bug, we have submitted a JIRA ticket and will update the ticket when we get an update.”
The “Tickets” Taband the “Post Reply” view...Part 2 NOTE: A USS “resolves” a ticket – the user actually “closes” the ticket. If the ticket is not closed by the user, it closes itself in 1 week (JHibbard section).
How are we going to get things done? Recall from John’s section, a USS should have sufficient technical background to address a range of user queries, although it is likely that there will be different levels of experience. Also, in the first year as we train up the Data Analysts (DAs), NAASC staff (including postdocs) will have to take on different roles. Triage – In the first year, a small group (including the Helpdesk Manager) will be responsible for assigning tickets to USS in triage. In addition, they will also try to answer Level 1 questions if the reply takes less than 15 mins. Level 1 questions may also be assigned to postdocs. There is still discussion about adding HIA and Taiwan USS into Triage
How are we going to get things done? • Level 2 – All NAASC scientists must be able to reply to level 2 tickets. Recall the definition of a Level 2 ticket: • Skilled support. General technical questions about radio astronomy techniques, interferometry, general correlator setup, molecular astrophysics, etc. Assignment of tickets to USS at the triage level will depend on the workload of any given USS based on what tickets they are currently assigned. Remijan and Sharp working on reports directly from the DB. Level 3 – The NAASC will provide to the project a list of detailed expertise for all staff members in the case of highly specific questions. These may take longer (in general) to answer and will also be taken into consideration in the assignment of tickets at the triage level.
The “Teamwork” Taband the “Manage Calendar >>> Month” view... NOTE: It was planned that Triage and USS UNavailablity would be coordinated through this interface. However, given this “bug” we are re-evaluating. May go to a Google Calendar...
The “Teamwork” Taband the “Manage Calendar >>> Insert Event” view... LIMITATIONS: Can set intent through “Status” and “Category” but the color, is not present in the “month view”. Same event is input on every day...not “blocked” over days like in Google Calendar.
What can you expect as a USS? • Triage will assign you a ticket. • If you have not set up an alert, you will need to sign in to Kayako and see if any tickets are assigned to you. • If you are assigned a ticket, assess how long it will take you to answer. • If the ticket will take longer than a day, you need to reply to the user that you are working on a ticket and will get back to them accordingly • NAASC staff should count on ~5 hours a week answering help desk tickets. (This includes the postdocs...)
What can you expect as a USS? • If you are working on ticket that will require more than a day, let Triage know so we know how to regulate the amount of tickets assigned to you. • Assess if the ticket requires a JIRA ticket • Let the user know of the status and file the appropriate ticket. Put the ticket status “on Hold” • Answer the ticket and set status to “Resolved”. • Search the KB! • Update the KB with your reply and be as descriptive as possible!
Homework • Using the naasc-staff account: • Look/change Preferences • Look/change Alerts • Go through the open (or closed) tickets in any department • Post a reply to a ticket • Add a note to an existing ticket • Forward a ticket of interest to another party • Reopen a ticket • Search the KB and try submitting a KB article!
