ITEK 1. Fokus Sitzung , SOX C18.1

Transkript

1 ITEK 1. Fokus Sitzung , SOX C18.1 Trouble Ticket Bugtracking Helpdesk Zusammenfassung Diskussion ITEK 29.Informell 1/14

2 Teilnehmer, Systeme (1/2) 11 Teilnehmer, 7 vorgestellte Systeme (6 Open Source, 1 kommerziell): Hanspeter Scherbel D-MATH (Protokoll), Marc Petitmermet D-MATL Karel Zeman D-MATL Evaluationskriterien des D-MATL (1) Eventum ( Manuel Oetiker D-ITET, Luca Previtali D-INFK, Marc Smitt D-INFK (2) Request Tracker RT ( Thomas Piendl LZ-NET (3) Open Ticket Request System OTRS ( Reinhard Hess ID-TIM (4) Rounddup Issue Tracker ( ITEK 29.Informell 2/14

3 Teilnehmer, Systeme (2/2) 11 Teilnehmer, 7 vorgestellte Systeme (6 Open Source, 1 kommerziell): Jean-Claude Eischen D-AGRL (5) Eigenentwicklung Elmar Heeb D-PHYS, Sitzungsleitung (6) Jitterbug ( Franz Kuster ID-Helpdesk (7) ServiceCenter (kommerzielles Produkt) Abwesend: Giorgio Broggi ID-BI (8) Bugzilla ( wurde nicht vorgestellt ITEK 29.Informell 3/14

4 (1) Evaluationskriterien D-MATL 1/2 A. Benutzer Einfache Bedienung (via Browser) Status meines Auftrages ( meiner Aufträge) voraussichtliches Datum der Erledigung Bearbeitende Person(en): Name(n), Tel., , Erreichbarkeit... Suche nach Stichwörtern und/oder Auftragsgeber (= nethz loginname) Geschichte des (der) erledigten Auftrags (Aufträge) Keine Tickets (Moeglichkeit von vertraulichen Tickets) B. Gruppenleiter (Professoren) Uebersicht der Gruppen-Issues Detailauskunft über die einzelnen Issues: Dauer, Kosten, Abläufe, Involvierte Stellen Statistiken: - Anzahl Issues/Zeiteinheit - Materialkosten/Issue und Gesamthaft ITEK 29.Informell 4/14

5 (1) Evaluationskriterien D-MATL, Eventum 2/2 C. IT-Personal (System-Admins, IT-Betreuer) Open Source Plattform-Unabhängikeit (Bedienung via Browser) Integrierbarkeit in WCMS-Umgebung (Redhat, ZOPE, Silva, MySQL) Zutrittsberechtigungen (Group-tool nethz) Integration - User- und Support-mails inkl. attachements automatisch unter Issue gespeichert - Automatisches replaying an User mit Info an Supporter Integration des Doku-Wesen (Dokumentationszwang beim Schliessen des Issue, Übersicht der Dokumentation/Issue) Kategorisierung der der Issues??? Statistiken (zusätzlich zu Statistiken unter B.)??? Eventum : + Geeignet fuer den Gruppenleiter, Auswertungen etc. (Aussagekraeftikeit der Auswertungen ist immer fraglich) - Nachteil: PHP ITEK 29.Informell 5/14

6 (2) Request Tracker RT 1/2 D-ITET: Version 1 (aktuell 1.08), command-line D-INFK: Version 3.4, Web-basierend D-ITET (Manuel Oetiker) Major upgrades (z.b. Version 1.x -> 2.x) sind problematisch Verwendet : mysql, perl, apache, procmail Version 3.x wird dieses Jahr evaluiert (bis anhin war die commandline Version von 3.x schlecht) Fuer jeden Kunden wird eine queue eingerichtet - geht direkt ueber den RT (replays) Auswertungen werden nicht im RT vorgenommen, sondern mit einem anderen management Zeittool erledigt. Problem Umlauten: gelöst Sortiert wird nach Kunden - es gibt ca. 200 requests pro Woche (mit Arbeitsstunden) inkl. ISG-interner Support. Im System sind z.z. ca Tickets vorhanden ; ca sind jeweils offen ITEK 29.Informell 6/14

7 D-INFK (Marc Schmitt / Luca Previtali) (2) Request Tracker RT 2/2 Upgrade von auf vorgenommen Eine support-adresse (support@inf.ethz.ch) Alle Anfragen landen zuerst im incoming Sortiertung nach technischen Aspekten Tickets koennen zusammengefuehrt werden und Abhängigkeiten können eingesetzt werden Suche ist nach verschiedenen Kriterien möglich und sehr flexibel Viele Sprachen werden unterstützt Technische Voraussetzungen : Webserver (apache), DB (z.b. mysql), Perl Problem Umlauten: noch nicht getestet Die requests können verschieden klassifiziert werden, z.b. nach Kunde (Institut, Professoren, etc.) Die Zeitabrechnung läuft über den RT Benutzt seit Ende 2000, z.z. ca Tickets Braucht viel HW-Ressoucen (RAM) Im Einsatz: 2.8 GHz Xeon und 1 GB RAM, RHEL-4 AS, 59 Perl-Module ITEK 29.Informell 7/14

8 (3) Open Ticket Request System OTRS 1/2 LZ-NET (Thomas Piendl) Seit ca. 1 Jahr im Einsatz Support-Ablauf : 1. (separate Adressen fuer die verschiedenen Lernplattformen) 2. Telefon-Support 3. Telefon & Timbuktu (screen-sharing) 4. Benutzer kommen zum NET Primaer unterstützte Systeme : Windows 2000 Server, Linux (RedHat und SuSe), Mac (???) Kein eigener -server (ID-Exchange wird benutzt). Falls ORTS ausfällt, kann immer noch auf die s zugegriffen werden. Wichtige Anforderung: Umlaute müssen unterstützt werden (ein k.o.- Kriterium fuer den Request Tracker bei der Evaluation) Zugriff via Web-browser Sehr gute Suchmöglichkeiten, Suchprofile können abgespeichert werden. Gearbeitet wird mit postgres-db ITEK 29.Informell 8/14

9 (3) Open Ticket Request System OTRS 2/2 LZ-NET (Thomas Piendl) s werden alle 10 Minuten via POP vom mailserver geholt und in der DB abgespeichert Viele Auswertungen möglich (auch speziell anpassbar) Der Inhalt des auto-replying kann definiert werden Die s koennen automatisch an die Spezialisten weitergeleitet werden (am NET nicht verwendet) History ist vorhanden Konfiguration vom Interface für den Admin via HTML-Interface Release-Politik ist konservativ (z.z. Version 1.3) Verbesserungswürdig : Update, Firmen-Support, Konfiguration des Statistik-Moduls Pro Tag ca. 25 Tickets. Offene : wenig Telefon-Tickets können eingespiesen werden Innerhalb OTRS können Web-Formulare erstellt werden FAQ-Seiten (Web) aus ORTS heraus möglich ITEK 29.Informell 9/14

10 ID-TIM (Reinhard Hess) (4) Roundup IssueTracker Die -Unterstützung ist nicht so weit ausgearbeitet Web-Interface Gut konfigurierbar Basierend auf Python und eine DB (z.b. postgres) Intergrierter oder externer Webserver (Apache) oder als CGI-Script Plattformen: Windows, Linux, Mac, einfach zu installieren Gute search-möglichkeiten (field-search, text-search etc.) Customizable (templates sind einfach änderbar) Ueber das "nosy-field" kann eine kleine mailing-liste fuer ein issue aufgesetzt werden Wird aktiv weiterentwickelt ca issues / Tag Ab 20 issues ist es eher schwierig, den Ueberblick zu behalten ITEK 29.Informell 10/14

11 Jean-Claude Eischen (5) D-AGRL Eigenentwicklung Anforderung: sehr einfaches System Entwicklungszeit ca. 2 Wochen Plattform: basiert auf Perl (2-3 Module), mysql, php, apache Der Status einer (request) kann nicht abgefragt werden Die Benutzer-Daten werden aus dem NIS herausgelesen Web-Interface; daraus werden s versendet (mit Cc: an das System), Notizen (fuer Kunden einsehbar) Farben für die Unterscheidung von mails Keine search-möglichkeit Anwender : ca. 700 Kunden, 40 IT-Betreuer (davon 6 ISG-Mitarbeiter) requests pro Tag ToDo : Handling von -attachments ITEK 29.Informell 11/14

12 D-PHYS Elmar Heeb (6) Jitterbug Sehr einfaches System, entwickelt im Zusammenhang mit SAMBA-Projekt, keine Weiterentwicklung Das System besteht aus 2 binaries : - Benutzer - file (jeder issue ist ein directory) und CGI (Webinterface) Dieses bugtracking-system soll in erster Linie dafür sorgen, dass nichts vergessen geht Hat sich am D-PHYS sehr bewährt Autorisierung über Apache (z.b. mit LDAP) Kein Problem mit security-holes Kunden dürfen das System nicht benutzen (waere aber möglich ueber das Webinterface mit Trackingnummer Die Doku der Lösungen wird unabhängig von Jitterbug in einem Wiki erstellt (über Google suchbar) Seit ca. 2 Jahren im Einsatz; bis anhin ca issues (ca. 2/Tag), jeweils 80 bis 100 offene Fälle ITEK 29.Informell 12/14

13 ID Helpdesk Franz Kuster (7) ServiceCenter (kommerziell) Persönliche Erfahrung auf dem Gebiet seit ca. 20 Jahren (Rapporte) Benutzer: ETH-Mitarbeiter, Studenten, Sysadmins Suchmöglichkeiten nicht sehr komfortabel Tickets via Web-Interface anschaubar (von 800 Kunden benutzen diese Funktionalität etwa 20) Ungefähr 1/3 der Support-Zeit konnte über das Ticket-System ausgewiesen werden Keine Auswertung auf Basis der einzelnen Kunden. (Daten-Interpretation) Das GUI ist ca. auf dem Stand von W2K Die Ticket-Vertraulichkeit ist nicht wichtig, dafür bei den attachments (Kunden schicken z.t. vertrauliche Daten) Die ISGs sind in ServiceCenter des ID-Helpdesks eingebunden Eine Kunden-DB ist im System vorgesehen Volltextsuche ist nicht möglich, die Kombinationsmöglichkeiten beim Suchen sind schwach Integration mit anderen Systemen ist kein Thema (mit SAP nicht vorhanden) ITEK 29.Informell 13/14

14 Schlussbemerkungen Eine ausgiebige Sitzung, ergibt eine gute Uebersicht über die ETH-Landschaft auf diesem Gebiet Die vorgestellten Produkte sind im Hinblick auf verschiedene Benutzergruppen kreiert worden: Kunde draussen, IT-Personal (kleiner interner Kreis) Die meisten Installationen benutzen Nebensysteme für die Ablage: (WICKI, TWICKI, WCMS, Sharepoint, Messagetree, Webboard... ) ein Problem? Den Kunden ist es egal, wie die ISG ihre Arbeit erledigt Fuer Helpdesks ist es wichtig, dass die SLAs im System abgebildet werden koennen Möglichkeit einer Ueberwachung von Request-Verlauf wird kaum genutzt Dispatching ab 2 Personen nötig Klassierung der Issues: Zuteilung grob, Statistik fein Das System soll harmonisch in die Organisationsstruktur der OE eingebettet sein Meine persönliche Präferenz:??? Sollen die Resultate zu einer Empfehlung an die OEs verdichtet werden? ITEK 29.Informell 14/14