Standard Dienstleistungsvereinbarung (Service based SLA) für "Mail und Groupware" - Informatikdienste Direktion - ETH Zürich
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Informatikdienste
Direktion
ETH Zürich
Binzmühlestrasse 130
8092 Zürich
www.id.ethz.ch
Informatikdienste
Standard Dienstleistungsvereinbarung (Service
based SLA) für „Mail und Groupware“Informatikdienste
Direktion
ETH Zürich
Binzmühlestrasse 130
8092 Zürich
www.id.ethz.ch
Informatikdienste
Inhaltsverzeichnis
1. Servicebeschreibung ............................................................................................................... 4
2. Nutzen für den Kunden ............................................................................................................ 4
3. Qualitätsmerkmale ................................................................................................................... 9
4. Qualitätsmessung .................................................................................................................. 14
5. Konditionen und Optionen (Preise) ........................................................................................ 15
6. Administratives....................................................................................................................... 16
7. Allgemeine Richtlinien............................................................................................................ 18
Tabelle 1: Versionskontrolle........................................................................................................... 3
Tabelle 2: Performance.................................................................................................................. 9
Tabelle 5: Wartungsfenster – geplant/ungeplant ......................................................................... 12
Tabelle 6: Systemgrenzwerte ...................................................................................................... 12
Tabelle 7: Störungsarten.............................................................................................................. 13
Tabelle 8: Backupsysteme ........................................................................................................... 14
Tabelle 9: Kennzahlen Reporting................................................................................................. 15
Tabelle 10: Austritt aus der ETH .................................................... Error! Bookmark not defined.
Tabelle 11: Support und Supportzeiten ....................................................................................... 16Informatikdienste
Direktion
ETH Zürich
Binzmühlestrasse 130
8092 Zürich
www.id.ethz.ch
Informatikdienste
Versionskontrolle
Version Historie / Status Datum Autor/in
0.1 Aufbau, technisches Grundgerüst 29.5.2013 F. Consani
0.5 Erste Inhalte 10.07.2015 Dr. D. Koch
0.6 Interne Revision 1 19.01.2016 Dr. D. Koch
0.7 Input PSI 06.06.2016 Dr. D.Koch
0.8 Interne Revision 2 21.07.2016 Dr. D. Koch, D. von Allmen, G. Klemm
0.9 Interne Revision 3 27.07.2016 M. Corti, D. Arrangeh, G. Klemm
0.91 Interne Revision 4 30.08.2016 Dr. M. Corti, G. Klemm
0.92 Neue Kategorisierung, PSI Kommentare 10.11.2016 Dr. M. Corti
und neue URLs
0.93 Review durch D-MATH und D-USYS 7.3.2017 Dr. M. Corti, Dr. D. Koch, Dr. H. Hirter,
M. Marcionelli
1.0 Finalisierung 18.5.2017 Dr. M. Corti
1.1 Minimale Zeit der Archivierung 3.7.2017 Dr. M. Corti
1.2 Keine Archivierung für Studierende 5.7.2018 Dr. M. Corti
1.4 Zugriff nach Austritt 1.7.2020 Dr. M. Corti
1.4.1 Keine Wiederherstellung der Mailbox nach 16.3.2021 Dr. M. Corti
der Löschung
1.5 Austritt 2021-07-19 Dr. M. Corti
Tabelle 1: Versionskontrolle1. Servicebeschreibung
Der IT-Service Mail und Groupware setzt sich aus den Komponenten Mail, Kalender, Kontakte
und Aufgaben zusammen. Als geschäftskritische Dienstleistung verfügt er über die dafür an der
ETH vorgesehenen Kontroll- und Hochverfügbarkeitsmechanismen. Er ist weltweit über alle
gängigen Clients und Protokolle verfügbar und zeichnet sich je nach Client durch zusätzliche
Kollaborationsfeatures aus.
2. Nutzen für den Kunden
Dieser IT-Service dient dem asynchronen, von Zeit und Distanz unabhängigen, schriftlichen
Austausch von elektronischen Informationen zwischen einzelnen Personen oder Gruppen. Die
heutigen Mailsysteme gehen immer mehr über die reine Nachrichtenübermittlung hinaus und
bieten auch zusätzliche Features in den Bereichen Funktionalität, Komfort und Sicherheit.
2.1. Unterstützte Prozesse
Neben dem reinen Austausch von Mails, bietet dieser IT-Service eine Terminverwaltung, die es
neben dem Führen einer eigenen Agenda möglich macht, Meetings mit anderen Personen zu
organisieren und zu koordinieren. Kalender können auch als Reservationssystem für Räume und
Gerätschaften genutzt werden. Ein globales Adressbuch vereinfacht die Adressierung von Mails
und Terminanfragen innerhalb einer grossen Organisation. Natürlich ist es auch möglich eigene
Kontakte und Adresslisten zu verwalten. Das globale Adressbuch bietet eine zentral verwaltete
Liste aller Personen, Gruppen und organisatorischen Strukturen innerhalb der ETH und kann
entsprechend den Möglichkeiten des verwendeten Mailclients gezielt durchsucht werden.
2.2. Funktionalität und Features
Für den asynchronen, elektronischen Austausch schriftlicher Informationen via diesen IT-Service
stellt die ETH folgende Dienstleistungen zur Verfügung:
• Authentisierter und/oder nicht authentisierter (ETH-interner) Versand von Mails zwischen
einzelnen Personen oder Gruppen
• Verschlüsselung der Mailkommunikation innerhalb der Mailorganisation der ETH. „Best
Effort“-Verschlüsselung (opportunistic TLS) für externe Mailkommunikation
• Terminverwaltung für Einzelpersonen sowie Meetings und Einladungen zwischen
mehreren Personen
• Delegationen und Zugriffsteuerung für andere Personen („Nicht-Mailbox-Owner“) auf Mail-
und Kalender-Ressourcen
• Firmenweites Adressbuch zur einfacheren Adressierung
• Verwaltung von Kontaktlisten (eigene und „gesharte“)
• Erfassung, Verwaltung und Zuweisung von Aufgaben (Tasks)
• Automatische Weiterleitung (Forwards, Kontakte)
• Reservationssystem für Räume und Geräte
• Telefonanrufbeantworter (Unified Messaging)Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
• Spam- und Malware-Filtering
• Mailarchiv
• „Mail to SMS“
• Web-Interface unterstützt alle gängigen Web-Browser
• Unterstützte (Mail)-Protokolle: HTTP, IMAP4, POP3 und SMTP. Die Mail- und Kalender-
Schnittstellen MAPI, EWS, ActiveSync und iCal werden ebenfalls unterstützt und
verwenden HTTPS als Trägerprotokoll. Es werden nur verschlüsselte Kommunikationen
zugelassen.
2.3. Wert
Zentralisierung von Commodities Der Aufbau und Betrieb einer Mailinfrastruktur stellt einen
nicht unbeträchtlichen organisatorischen und finanziellen Aufwand dar, der in der Vergangenheit
von vielen Instituten und Departementen selbständig bestritten wurde. Dadurch, dass die ETH
diesen zentralen IT-Service zur Verfügung stellt, werden dort finanzielle Mittel und Ressourcen
frei, welche nun wieder vermehrt für das Kerngeschäft der ETH eingesetzt werden können.
ETH-weites Adressbuch Durch den Zugriff der Informatikdienste auf die zentrale
Personendatenbank der ETH, kann auf dem Mailserver ein Adressbuch zur Verfügung gestellt
werden, das alle Personen an der ETH Zürich umfasst. Unabhängig davon, auf welchem der an
der ETH bestehenden Mailsysteme sich deren Mailbox befindet. Das ermöglicht das direkte
Auffinden und Adressieren aller Personen mit einer Beziehung zur ETH aus einem einzigen
Adressbuch heraus.
Einsicht in und Verwaltung von fremden Mailboxressourcen Der IT-Service deckt eine Reihe
von Kollaborationsszenarien ab. So kann beispielsweise anderen Personen Zugriff auf fremde
Mailbox- oder Kalender-Ressourcen gewährt werden. Es können auch Verwaltungsaufgaben
innerhalb einer Mailbox oder eines Kalenders an andere Personen delegiert werden.
Terminverwaltung und Einladungen Neben der klassischen Terminverwaltung im eigenen
Kalender bietet dieser IT-Service die Möglichkeit, Einladungen mit anderen Personen oder ganzen
Gruppen zu koordinieren. Dies wird vor allem dadurch erreicht, dass alle Termine in einer
vereinfachten „frei/gebucht“ Ansicht, standardmässig für alle Teilnehmer des IT-Service sichtbar
sind. Dadurch wird das Auffinden und Koordinieren von möglichen freien Terminen massiv
vereinfacht.
Automatisierung durch Regeln Die Organisation der Mailbox lässt sich mit Hilfe von Regeln
automatisieren. Aufgrund bestimmter Kriterien, lassen sich bestimmte Aktionen hinterlegen, die
auf jede eingehende Mail angewendet werden. So können Mails gelöscht, in andere Ordner
verschoben, oder andere spezifische Aktionen ausgelöst werden.
Unified Messaging Das in diesem IT-Service integrierte Voice-Mail-System kann als
Anrufbeantworter, für Hinweise, Ankündigungen sowie Abwesenheiten benutzt werden. Auch ist
es möglich, von jedem beliebigen Telefon aus, auf Ihren Terminkalender zuzugreifen, oder Ihre
E-Mails zu prüfen. Folgende Leistungen sind im Voice-Mail Service enthalten:
- Anrufbeantworter
- Lieferung von Sprachnachrichten als MP3-Dateien direkt in Ihr Postfach
Seite 5 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
- Benachrichtigung über verpasste Anrufe direkt in Ihr Postfach
- Voice-Zugriff auf Ihren Kalender und Ihre E-Mails
Beschreibung „Unified Messaging“: https://www.ethz.ch/services/de/it-services/katalog/email-
kalender/mailbox.html
Mailarchiv Das Mailarchiv erstellt eine Kopie aller Mailitems im Archiv-Store, welche gelesen sind,
nicht im System Mailordner „gelöschte Objekte“ liegen, und deren Modifikations- oder Ablauf-
Datum älter als 30 Tage ist. Der Archiv-Store ist ein separates Speichersystem, welches keine
Änderung der archivierten Mailitems mehr zulässt. Der Store kann über ein Webinterface
durchsucht und archivierte Items in der eigenen Mailbox wieder hergestellt werden.
Das Mailarchiv übernimmt die auf der Mailbox liegenden Berechtigungen. Wenn also andere
Personen Zugriffsrechte auf eine Mailbox haben, so haben diese auch Zugriff auf das Archiv
dieser Mailbox. Die Objekte werden im Archiv mindestens 10 Jahre aufbewahrt.
Das Mailarchiv steht für alle Postfächer zur Verfügung ausser bei den Postfächer der
Studierende1.
Beschreibung Mailarchiv: https://www.ethz.ch/services/de/it-services/katalog/email-
kalender/mailarchiv.html
Spam-Filter Der Spam-Filter unterzieht alle von ETH-extern eingehenden Mails verschiedenen
Tests, welche sicherstellen, dass nur unbedenkliche und legitime Mails die Mailboxen der
Benutzer erreichen. Grundsätzlich lassen sich drei verschiedene Arten von Schad-Mails
unterscheiden:
- Spam: Häufig in grossen Massen verschickte Mails, welche meist zu Käufen oder
finanzieller Unterstützung unterschiedlichster Art auffordern.
Massnahme auf dem Spam-Filter: Die Annahme der Mails wird verweigert.
- Phishing: Diese Mails täuschen oft einen offiziellen Charakter vor, mit welchem die
Empfänger zu verschiedenen Aktionen aufgefordert werden. Letzten Endes haben diese
Aktionen fast immer das Ziel, Username und Passwort oder auch Kreditkarten- sowie
Bankverbindungs-Informationen des Mailempfängers zu erhalten.
Massnahme auf dem Spam-Filter: Ist die Identifikation eindeutig, wird die Annahme des
Phishing-Mails verweigert. In unklaren Fällen kommen die Mails in eine Quarantäne-
Queue und werden manuell überprüft. Alle negativen Mails werden den Mailboxen nach
der Überprüfung zugestellt, die positiven Mails werden gelöscht.
- Viren/Malware: In diesen Mails ist meist via Attachment ein spezieller Code enthalten,
welcher beim Öffnen des Mails/Attachments ausgeführt wird. Je nach Art des Codes,
können unterschiedliche Effekte erzielt werden, bis hin zur kompletten Übernahme des
Clientsystems auf dem der Code ausgeführt wurde.
Massnahmen auf dem Spam-Filter: Die Annahme des Mails wird verweigert. In unklaren
Fällen kommen die Mails in eine Quarantäne-Queue und werden manuell überprüft.
Die Konfiguration des Spam-Filters kann vom User beeinflusst werden (Löschen oder Markieren).
1
Postfächer von Studierenden mit mehrere ETH-Beziehungen (z.B. die auch Mitarbeiter oder
Dozenten sind) werden normal archiviert.
Seite 6 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
Via nethz2 kann jeder Benutzer seine eigene White- und Black-List definieren. Die persönliche
White- und Black-List beeinflusst jedoch nur das Verhalten des Filtersystems für Spam. Das
Filtering von Phishing und Viren/Malware ist dadurch nicht beeinflussbar.
Beschreibung Spam-Filter: https://www.ethz.ch/services/de/it-services/katalog/email-
kalender/mailfilterung.html
Virenscanner Zusätzlich zum Viren- und Malware-Scanner auf dem Spam-Filter gibt es einen
weiteren Viren/Malware-Scanner auf der nachgelagerten Mailinfrastruktur. Dieser zweite Scanner
ist explizit von einem anderen Hersteller als derjenige des Spam-Filters. Dies soll einerseits die
Erkennungsrate bei Viren und Malware verbessern und anderseits auch vor intern
eingeschleppter Schadsoftware schützen. Dieser Virenscanner untersucht nur Attachments. Es
gibt keinen „Content-Scan“. Zuerst wird immer versucht, das Mail von einem entdeckten Virus zu
säubern. Ist dies nicht erfolgreich wird das Mail als Ganzes gelöscht. Zusätzlich überprüft der
Virenscanner alle Mailattachments auf die folgenden Faktoren:
- Attachmentgrösse: Die Gesamtgrösse der Mailattachments darf 20 MB nicht
überschreiten, ansonsten wird das Attachment geblockt.
- Dateierweiterung: Attachments mit bestimmten Dateierweiterungen werden geblockt.
- Archive: Überschreitet ein Archiv eine bestimmte Kompressionsrate oder sind zu viele
Archive ineinander verschachtelt, wird das Attachment geblockt.
Ein geblocktes Attachment wird im Mail durch eine Textdatei ersetzt, welche über die getroffene
Massnahme informiert. Darüber hinaus wird eine Kopie des Originalmails in eine Quarantäne
verschoben. Bei Bedarf kann während 30 Tagen, das Mail aus dieser Quarantäne dem Empfänger
inkl. aller Attachments erneut zugestellt werden.
Die internen Mailuser (Sender und/oder Empfänger) werden über alle Eingriffe des Virenscanners
via Mail oder Info-Text in einem ersetzten Attachment informiert.
2.4. Beispielanwendungen
Als klassisches Mailsystem dient dieser IT-Service in erster Linie dem asynchronen Austausch
elektronischer Informationen. Dazu gehört auch die Verwaltung eigener Kontakt- und
Verteilerlisten zur einfacheren Adressierung der Mails. Darüber hinaus jedoch bietet das System
die Möglichkeit Termine und Aufgaben für sich selbst aber auch im Zusammenhang mit anderen
zu koordinieren. Ein paar der sich daraus ergebenden „use cases“ sind hier aufgeführt:
Stellvertretung / Delegation Alle Mailboxressourcen verfügen über eine granulare
Rechteverwaltung. So können anderen Personen Zugriffsrechte oder ganze Funktionen auf die
eigenen Ressourcentypen (Mail, Kalender, Kontakte, Aufgaben) oder deren Substrukturen
vergeben werden. Damit lassen sich klassische Stellvertretungs- oder
Vorgesetzter/Untergebener-Szenarien abbilden. So kann beispielsweise ein Untergeber die
Termine seines Vorgesetzten verwalten, oder auf dessen Mails antworten, ohne dabei extern in
Erscheinung zu treten.
2
http://passwort.ethz.ch/
Seite 7 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
„Frei/Gebucht“ Um die Koordination von Terminen zwischen verschiedenen Personengruppen
zu erleichtern, erstellt das System standardmässig eine sogenannte „frei/gebucht“-Ansicht jedes
Kalenders, welche von allen Benutzern dieses IT-Service eingesehen werden kann. Diese Ansicht
zeigt an, wann eine Person bereits Termine eingetragen hat, und wann sie noch frei ist. Dadurch
lassen sich Termine viel einfacher vereinbaren. Falls gewünscht, kann diese Ansicht von jedem
Mailbox-Benutzer auch abgestellt werden.
„Shared“ Mailbox Häufig werden Mailboxen nicht für dezidierte Personen, sondern für Projekte
oder Funktionen erstellt, welche über eine ganz bestimmte Mailadresse zentral erreichbar sein
müssen. Diese Mailboxen wiederum müssen von anderen Personen eingesehen und deren Inhalt
verwaltet werden können. Diese sogenannten „shared Mailboxen“ sind primär ganz normale
Mailboxen, auf welche andere Personen Zugriffsrechte erhalten haben. Diese Personen binden
die „shared Mailbox“ in ihr eigenes Mailboxprofil ein, und können dann entsprechend den
vergebenen Rechten, alle notwendigen Funktionen übernehmen. Falls gewünscht, können
ausgehende Mails mit dem Absender der „shared Mailbox“ verschickt werden.
Ressourcenverwaltung von Sitzungsräumen und/oder Geräten Eine weitere Verwendungsart
von unpersönlichen Mailboxen sind die sogenannten Ressourcenmailboxen. Diese Mailboxen
dienen der Reservation von Räumen und/oder Geräten. So kann beispielsweise einem
Sitzungsraum oder einem Mikroskop ein Kalender zugewiesen werden, der sich dann Buchen
lässt. Diese Buchungen lassen sich durch spezielle Regeln ergänzen und werden vom System
dementsprechend automatisch oder durch einen Dispatcher verwaltet. Buchungen sind
beispielsweise nur zu bestimmten Zeiten möglich, müssen von einer oder mehreren Personen
bestätigt werden, oder lassen sich durch andere Personen übersteuern.
Abwesenheitsmeldungen Bei längeren Abwesenheiten, kann es sehr nützlich sein, den
Absender einer Mail darüber zu informieren. Dies lässt sich über sogenannte Abwesenheits- oder
„Out-of-Office“-Meldungen erreichen. Ist diese spezielle Regel aktiv, wird ein zuvor frei
definierbarer Text, als Antwort auf eingehende Mails geschickt (nur einmal pro
Abwesenheitsperiode und Absender). Die Meldung kann zwischen internen und externen
Absendern unterscheiden. Ausserdem lässt sich Anfang und Ende der Abwesenheit im Voraus
bestimmen.
2.5. Abgrenzung
- Das System akzeptiert Mails bis zu einer maximalen Grösse von 20 MB.
- Die Standardmailboxquota für Studenten und Mitarbeiter beträgt 0.2 beziehungsweise 5.0
GB. In begründeten Fällen kann diese Grenze auch angehoben werden.
- Der Mail-Virenscanner prüft die Attachments der eingehenden Mails nicht nur auf Viren,
sondern blockiert zusätzlich Attachments aufgrund einiger vordefinierter Kriterien zum
Beispiel aufgrund ihrer Dateierweiterung oder dem Kompressionsgrad.
- Der Empfang und Versand von Mails über den Mailserver verlangt eine authentisierte und
verschlüsselte Verbindung.
Seite 8 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
- Es werden keine Blackberry Geräte unterstützt.
- Als Absenderadressen können nur Mailadressen verwendet werden, welche auf dem
absendenden Account als Alias eingetragen sind.
- Pro Tag und Mailkonto können maximal 500 Mailadressen angeschrieben werden. Ein
Mail an eine Mailverteilerliste auf dem Server zählt dabei nur einmal. Ausnahmen von
dieser Regel (z.B. für Massenmails) können beim Service-Desk angefragt werden.
- Alle Benutzenden haben Zugriff auf ihre Mailboxen und ihre Mailarchive, solange sie über
die dafür nötigen Benutzungskonten verfügen. Nach Austritt aus der ETH Zürich werden
die Benutzerkonten gesperrt. Die Inhalte von Mailboxen und Mail-Archiven werden den
ehemaligen Benutzenden danach nicht mehr zur Verfügung gestellt.
3. Qualitätsmerkmale
3.1. Definitionen
Erreichbarkeit Dieser IT-Service ist mit allen Protokollen (siehe 2.2) weltweit erreichbar. Wir
unterstützen die meisten Mailclients unter Berücksichtigung der bestehenden RFCs. Auch das
Webinterface (OWA) kann mit allen gängigen Webbrowsern (Chrome, Firefox, IE, Safari) genutzt
werden.
Performance Die Performance lässt sich aufgrund der vielen verschiedenen Mailclients nur
schwer zu messen. Die meisten Mailclients verfügen über interne Cache- und Polling-
Mechanismen, welche die effektive Performance des Mailservers zum grössten Teil überdecken.
Auch können wir nur Aussagen zum internen Mailverkehr machen. Mails, welche zwischen
verschiedenen Mailsystemen hin und her geschickt werden, entziehen sich zumindest teilweise
unserer Kontrolle. Aus diesem Grund wird folgender Prozess für HTTPS, IMAP und POP3 ETH-
intern gemessen und ausgewiesen.
Aktion Maximale Antwortzeit in Sekunden über
gesamten Prozess3
Login in Mailbox 2 Sekunde
E-Mail Fetch 5 Sekunde
Logout 2 Sekunde
Gesamter Prozess 9 Sekunde
Tabelle 2: Performance
Abhängig von der Grösse der Mailbox, der Verbindungs- und der Client-Performance kann in der
Regel aus Sicht Kunde von einer Erhöhung der Antwortzeit von einer Sekunde, ggü. der ETH-
Messung ausgegangen werden.
3
ETH Netzwerk
Seite 9 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
3.2. Verfügbarkeit
Dieser IT-Service ist als „kritischer Service“ (Blau) eingestuft. Das bedeutet:
- Überwachung: 7*24
- Servicezeit: 7*16h (06:00-22:00)
Während dieser Zeit wird alarmiert und die Alarme aktiv bearbeitet. Die Verfügbarkeit
ausserhalb der Servicezeit ist nicht garantiert und ein allfälliger Unterbruch fliesst nicht in
die Verfügbarkeitsmessung ein (keine Auswirkungen auf die Ausfallzeit.
- Garantierte Verfügbarkeit pro Jahr: 99.95 %.
Die Verfügbarkeit wird gemessen innerhalb der Servicezeit und ausserhalb von
vereinbarten Wartungsfenstern und ist gemittelt über ein Kalenderjahr. Als Ausfallzeit
wird die Zeit gewertet, aus der der Service aus Sicht des Kunden (ausgenommen
anderslautende Regelungen unter den Mess- und Bewertungskriterien zu den
Wartungsfenstern) nicht verfügbar ist.
- Wartungsfenster
Unterbrüche während der Servicezeit nur nach n (n=2 bis 6) Wochen Vorankündigung
möglich.
Unterbrüche ausserhalb der Servicezeit nach 1 Woche Vorankündigung, möglich.
- Erste, qualifizierte Information an Kunden nach Auslösung Alarm: £1h innerhalb
Servicezeit
Erste Information an den Kunden nach einer ersten Analyse durch einen Mitarbeitenden
der ID.
- Maximaler Verfügbarkeitsunterbruch (Recovery Time Objective RTO): 4h
Maximaler Zeitraum bis zur Wiederherstellung des Service nach einem Unterbruch.
Gemessen innerhalb der Servicezeit.
- Maximaler Datenverlust (Recovery Point Objective RPO): 24h
Maximal anzunehmender Verlust von durchgeführten Transaktionen nach einem Ausfall.
Wiederherstellungszeiten nach einem Datenverlust können nicht garantiert werden.
Schematische Darstellung der Service-Verfügbarkeit
Seite 10 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
Tageszeit (Uhrzeit)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Überwachung Überwachung
Alarmierung Servicezeit 7 * 6:00 - 22:00 Uhr
Service Desk Officezeit Mo - Do
erreichbar
Officezeit Fr
Wartungsfenster Wartungsfenster nach 1 Woche
Wartungsfenster nach 2 - 6 Wochen vorheriger Ankündigung 1 Woche
Ankündigung notwendig vorheriger Ankündigung
Reaktion bei best effort
Es wi rd a l a rmi ert und di e Al a rme werden a ktiv bea rbei tet.
Ers te Informa tionen a n den KundenStandard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
Wartungsfenster Zeit Ausfallzeit Info Admins Info betroffene User
Ungeplante Downtime n.a. n.a. 1 h nach Ausfall via 1 h nach Ausfall via Web /
Web / 24 h nach 24 h nach Ereignis via Mail
Ereignis via Mail / / gemäss „Blockzeit“ an
gemäss „Blockzeit“ an Arbeitstagen
Arbeitstagen
Tabelle 3: Wartungsfenster – geplant/ungeplant
3.4. Kapazitäten
Dieser IT-Service ist darauf ausgelegt, tausende Benutzer und deren Anfragen gleichzeitig zu
verarbeiten. In vielen Bereichen gibt es keine exakten Grenzwerte bezüglich der Belastbarkeit des
Systems. Bei zunehmender Last kommt es zu einer sukzessiven Erhöhung der Antwortzeiten,
welche immer auch von den Verfügbaren Ressourcen (CPU, Arbeitsspeicher, Disk I/Os,
Netzwerkdurchsatz) abhängig sind. Es existieren aber auch hart definierte Grenzwerte im System.
Die wichtigsten davon sind unten aufgeführt:
Ressource Grenzwert
Max. garantierte Grösse eines Mails 20 MB
Anzahl adressierte Empfänger pro Tag und Mailbox 500
Unterstützte SMTP Ports 25 und 587
Max. gleichzeitig akzeptierte SMTP Verbindungen 5’000
Max. gleichzeitig akzeptierte SMTP Verbindungen pro IP-Adresse 20
Max. Hop Count (SMTP) 30
Max. Empfänger pro Mail (SMTP) 200
Max. Anzahl gleichzeitiger EWS Sessions pro User 10
Max. Anzahl gleichzeitiger OWA Sessions pro User 5
Max. Anzahl gleichzeitiger POP Sessions pro User 16
Max. Anzahl gleichzeitiger IMAP Sessions pro User 64
Max. Anzahl gelichzeitiger ActiveSync Sessions pro User 10
Max. Anzahl gelichzeitiger RPC Verbindungen pro User 20
Max. gleichzeitiger IMAP Verbindungen 10’000
Max. gleichzeitiger IMAP Verbindungen pro IP-Adresse 2’000
Max. gleichzeitiger POP Verbindungen 2’000
Max. gleichzeitiger POP Verbindungen pro IP-Adresse 2’000
ActiveSync min. Device Passwortlänge 4
Tabelle 4: Systemgrenzwerte
3.5. Service Continuity
Um die Wahrscheinlichkeit von Ausfällen zu minimieren, kommen verschiedene
„Hochverfügbarkeits-Technologien“ zum Einsatz, die auch beim Versagen einzelner
Komponenten in der Lage sind, ein funktionierendes Gesamtsystem aufrechtzuerhalten. Im
Wesentlichen besteht der IT-Service aus einem georedundanten Verbund von geclusterten
Servern, welche zwischen dem Hönggerberg und dem ETH-Zentrum verteilt sind. Jede
Mailboxdatenbank besteht dabei aus zwei identischen Kopien, welche im regulären Betrieb
Seite 12 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
synchron gehalten werden. Beim Ausfall einer Kopie kann die andere nach ein paar Sekunden
die Arbeit übernehmen. Die meisten Mailclients, werden den kurzen Unterbruch kaum bemerken.
Vorgehen bei Störungen
Bei Störungen wird gemäss den unter Verfügbarkeit (siehe 3.2) angegebenen Definitionen für
einen „blauen Service“ vorgegangen. Die Alarmierung folgt gemäss den dort angegebenen
Richtlinien, wobei die Verfügbarkeit der technisch zuständigen Personen lediglich auf der Basis
von „best effort“ gewährleistet ist. Da es sich bei Mail um einen geschäftskritischen IT-Service
handelt, unterhalten wir mit dem Hersteller der Software einen Supportvertrag, der es uns
gestattet, Supportanfragen 7*24 zu eröffnen und auch eine unmittelbare Verfügbarkeit von
technisch qualifizierten Ressourcen garantiert. Diese Ressourcen bleiben bis zur Lösung des
Problems verfügbar.
Störungsarten
Grundsätzlich können zwei Arten von Ausfällen unterschieden werden:
Störungsart
Eingeschränkte oder keine Verbindung (IMAP) zum Server RTO (Recovery Time Objective): 4 Stunden
Logische Korruption der Maildatenbank(en) RTO (Recovery Time Objective): ein Tag bis zu einer Woche
Physische Korruption einer Maildatenbank(en) RPO: eventuelle während dem Unterbruch nicht
abgeschlossene Transaktionen.
Zeit bis zur vollständigen Wiederherstellung: eine Minute
Tabelle 5: Störungsarten
Im ersten Fall handelt es sich um ein reines Verbindungsproblem. Die Mailboxdaten sind nicht
betroffen. Neue, an das System geschickte Mails werden mit einer entsprechenden
Unzustellbarkeitsmeldung an den Absender beantwortet. Da der Absender über die
Zustellprobleme informiert ist, wird dies nicht als Mailverlust gewertet. Diese Art von Problemen
kann eine Vielzahl von Ursachen haben.
Im zweiten Fall, bei einer Korruption der Maildatenbank(en), muss je nach dem Zeitpunkt der
Korruption und der Menge der betroffenen Datenbanken mit wesentlich längeren Ausfällen
gerechnet werden. In diesen Fällen stellen wir den betroffenen Benutzern nach Möglichkeit eine
leere Mailbox zur Verfügung, deren Daten nach einem erfolgreichen Datenbankrestore mit der
alten Mailbox wieder zusammen geführt werden. Aufgrund des Datenbankdesigns dieses IT-
Service ist Datenverlust auch in diesem Fall sehr unwahrscheinlich, kann aber niemals
grundsätzlich ausgeschlossen werden.
Ausfall eines Data-Centers
Bei einem teilweisen oder totalen Ausfall der Infrastruktur im Hönggerberg kann das ETH-Zentrum
automatisch übernehmen. Genauso automatisch übernimmt der Hönggerberg bei einem
teilweisen Ausfall im ETH-Zentrum. Der Serviceunterbruch beträgt jeweils max. 5 Minuten. Bei
einem Totalausfall im ETH-Zentrum muss die Aktivierung der Redundanz im Hönggerberg jedoch
manuell erfolgen. In diesem zweiten Fall ist eine gewisse Downtime unvermeidlich.
Ausfall beider Data-Centers
Der Ausfall beider Data-Centers liegt ausserhalb der Betrachtung dieses SLAs. Je nach Art und
Seite 13 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
Ausmass des Vorfalls muss jedoch mit einem massiven Unterbruch gerechnet werden (Tage bis
Wochen). Auch gibt es in diesem Szenario keine Garantie für den Erhalt der Maildaten.
Backup
Der Schutz der Maildaten erfolgt auf drei Ebenen:
• Mailboxdumpster
• Mailarchiv
• Systemsicherung
Backup- Was wird gesichert? Welcher Zeitraum Was wird Restorezeit Wer kann restoren?
System wird gesichert? restored?
Mailbox- Hart gelöschte Die letzten 30 Tage Einzelne Minuten Mailboxbesitzer /
Dumpster Mailobjekte Mailobjekte Mailadmin
Mailarchiv Mails, Kontakte und Alles älter als 30 Einzelne Mails, Minuten für Mailboxbesitzer
abgelaufene Tage Termine, einzelne Mails / einzelne Objekte /
Termine/Terminserien Kontakte, Ein Tag für eine Mailarchivadmin die
Achtung: keine Aufgaben oder die Mailbox (PST ganze Mailbox
„Gelöschte Objekte“! ganze Mailbox File)
(PST-File)
System- alles Die letzten 21 Tage Einzelnes Zwei Tage bis Mailadmin
Sicherung5 Mailobjekt oder eine Woche
die ganze Mailbox
(PST-File)
Tabelle 6: Backupsysteme
3.6. Sicherheit
Die gesamte Mailserver-Infrastruktur wird gemäss „best practices“ des Herstellers installiert und
betrieben. Alle in dem Bereich eingesetzte Software befindet sich jederzeit auf einem offiziell
unterstützten Niveau. Um dies zu gewährleisten, werden monatlich alle veröffentlichten
Sicherheitsupdates für das System und die Mailapplikation eingespielt. Dabei werden auch
Ausfälle einzelner Funktionen innerhalb des Mailboxservice in Kauf genommen.
Alle Client-Verbindungen zum Mailserver verlangen eine Authentifizierung und sind durch
Verschlüsselung (TLS) geschützt.
4. Qualitätsmessung
Der IT-Service wird 7*24 Stunden auf seine Performance und Verfügbarkeit hin überwacht. Dafür
werden zwei getrennte Überwachungssysteme eingesetzt, von denen eines die Verfügbarkeit für
die Benutzer und das andere die generelle System-Verfügbarkeit und Performance kontrolliert.
4.1. Verfügbarkeitsberichte
Die einzelnen Komponenten des Systems werden kontinuierlich auf deren Verfügbarkeit
5
Restore-Aufwand sehr gross. Restore wird nur in absoluten Notfällen gemacht.
Seite 14 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
überwacht. Die Unterschreitung von zuvor gesetzten Grenzwerten führt dabei automatisch zu
Alarmen, welche per Mail und/oder Statusanzeige auf einer Überwachungswebseite den
zuständigen Personen übermittelt werden. Die daraus entstehenden Folgeaktivitäten werden
durch die Informatikdienste der ETH Zürich ausgelöst und koordiniert, ohne aktive Einflussnahme
des Kunden.
4.2. Kapazitätsnachweise
Alle Systemkomponenten werden laufend bezüglich ihrer Performance und der Auslastung ihrer
Kapazitätsgrenzen überwacht. Es existiert dafür eine Reihe von internen Prozessen, welche beim
Erreichen verschiedener Grenzwerte automatisch Gegenmassnahmen einleiten. So werden
beispielsweise beim Überschreiten einer gewissen Datenbankgrösse (Diskkapazität) Mailboxen
auf andere Datenbanken verschoben, welche noch über entsprechend grosse Diskreserven
verfügen.
4.3. Reporting
Monatlich wird ein Reporting über folgende Kennzahlen erstellt:
Kennzahl Gemäss Definition Ziffer im SLA
Performance auf HTTP-, IMAP-, und POP3-Ebene 3.1
Verfügbarkeiten: 3.2
- Garantierte Verfügbarkeit 7*16h
- Zielverfügbarkeit 7*24h
Antwortzeit für die erste, qualifizierte Antwort auf 6.2
Meldung von Incidents während Bürozeiten
Tabelle 7: Kennzahlen Reporting
5. Konditionen und Optionen (Preise)
5.1. Preismodell
Dieser IT-Service wird allen Personen mit einer Beziehung (Mitarbeitende, Studierende und
Dozierende) zur ETH Zürich kostenlos zur Verfügung gestellt.
5.2. Bestellbare Optionen (standard changes)
Die meisten Optionen sind durch den Mailboxbenutzer frei konfigurierbar, entweder durch das
zentrale Service-Administrationstool der Informatikdienste („password.ethz.ch“ – „Meine Services“
– „Mailbox“) oder direkt durch den verwendeten Mailclient. Zu beachten ist dabei, dass zur
Verfügung stehende Feature-Set immer auch vom verwendeten Mailclient und Mailprotokoll
abhängig ist.
Andere Optionen müssen zuerst auf der Serverseite frei geschaltet werden. Dafür ist ein Ticket
beim Service Desk zu eröffnen.
Seite 15 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
5.3. Auszuhandelnde Optionen (change request)
Die Schnittstellen von diesem IT-Service bieten immer auch Raum für Wünsche, welche nicht
direkt „out of the box“ vom Produkt zur Verfügung stehen. Erste Anlaufstelle für Anliegen dieser
Art ist immer der Service Desk. Eine Entscheidung darüber, ob dem Wunsch entsprochen werden
kann, muss in jedem Fall einzeln erfolgen und ist abhängig vom zu erwartenden Aufwand für die
Umsetzung und den späteren Unterhalt der angestrebten Erweiterung. Direkte Eingriffe in den
Code der Mailapplikation sind jedoch aus ressourcen- wie auch lizenz-technischen Gründen nicht
möglich.
5.4. Kündigung von Mitgliedern der ETH
Mit dem Austritt (respektive wie bisher 180 Tagen danach bei Studierenden, Dozierenden und
wis- senschaftlichem Personal) laufen die letzten ETH-Dienste ab. Das ETH Userkonto und
Mailbox werden inaktiv und die Daten werden gelöscht.
6. Administratives
6.1. Bestellung und Fristen
Je nach Anstellung oder Beziehung zur ETH Zürich wird dieser IT-Service dem Benutzer beim
Eintritt automatisch oder durch einen zuständigen E-Mail-Admin zur Verfügung gestellt.
6.2. Support und Supportzeiten
Sämtliche Supportanfragen, Störungsmeldungen, Incidents und Bestellungen laufen über
unseren zentralen Service Desk. Anfragen werden entgegengenommen und sofort an die
richtigen Stellen weitergeleitet oder allenfalls eskaliert. Der gesamte Kommunikationsverkehr wird
überwacht und auf Einhalten unserer internen Qualitätsvorgaben hin geprüft.
Support Stelle Service Desk
Support E-Mailadresse servicedesk@id.ethz.ch
Support Telefonnummer +41 44 632 7777
Support Zeiten Mo – Do: 08:00 – 18:00 Uhr
Fr: 08:00 – 17:00 Uhr
Antwortzeit6 für die erste, qualifizierte Antwort 4h
auf Meldung von Incidents während Bürozeiten Es wird keine maximale "Time to Repair" zugesichert.
Bei techn. Störungen an der überwachten Siehe 3.2 (Error! Reference source not found.)
Infrastruktur ausserhalb Bürozeiten
Tabelle 8: Support und Supportzeiten
Allenfalls notwendige Wiederherstellung ("Restore") von einzelnen Datenbanken erfolgt durch die
Informatikdienste, und wird ebenfalls über das Service Desk bestellt. Müssen Daten mehrmals
wegen Fehlmanipulationen wiederhergestellt werden, kann der Aufwand speziell verrechnet
6
Unter "Antwortzeit" wird die Zeit vom Eingang der Meldung bis zum Beginn der Diagnose verstanden.
Seite 16 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
werden.
6.3. Eskalation
Störungsmeldungen und Probleme, welche vom Service Desk (1st Level Support) nicht gelöst
werden können, werden an die technischen Betreiber des IT-Service (2nd Level Support)
eskaliert. Falls notwendig wird bei Problemfällen auch der Support vom Hersteller (3rd Level
Support) in Anspruch genommen.
6.4. Dokumentationen / Schulung
Die Informatikdienste bieten verschiedene Informationen zum Umgang mit der Mailinfrastruktur
auf folgender Webseite: https://www.ethz.ch/services/de/it-services/katalog/email-kalender.html
6.5. Zugangsdefinitionen
Dieser IT-Service steht allen gängigen Mailclients zur Verfügung. Allerdings kann es je nach Client
zu Unterschieden im Feature-Set kommen. Beispielsweise kann ein reiner IMAP Client nicht auf
die Kalenderfunktionen zugreifen. Erreichbar ist der Service über die unter 2.2 angegebenen
Protokolle. Es werden nur verschlüsselte Kommunikationen zugelassen.
6.6. Pflichten Betreiber
Der Leistungserbringer ist verantwortlich für den reibungslosen Betrieb, den Unterhalt und eine
stetige Weiterentwicklung dieses IT-Services. Dies beinhaltet das Management der Daten, die
Architektur der Infrastruktur, die Unterstützung und Erweiterung der bestehenden
Softwarefunktionalität sowie die Security.
Bei Nichteinhaltung der in diesem SLA unter Ziffer 4.3 zusammenfassend beschriebenen
Messwerte, über den Zeitraum eines Kalenderjahres betrachtet, wird die ETH rechtzeitig
geeignete Massnahmen einleiten, um die festgestellte Abweichung innerhalb der nächsten
Messperiode (ein Kalenderjahr) zu korrigieren.
6.7. Pflichten Kunde
6.7.1. Schulung
Um den grössten möglichen Nutzen aus dem Service zu ziehen, müssen folgende
Voraussetzungen erfüllt werden:
• Der Kunde muss im Umgang mit dem verwendeten Mailclient vertraut sein. Die
Informatikdienste bieten keine ausgewiesenen Kompetenzzentren im Umgang mit den
verschiedenen Clients an. Bei Bedarf ist es Aufgabe des Kunden, sich das notwendige
Knowhow anzueignen.
• Die Informatikdienste übernehmen keine Verantwortung bei Nichterfüllung des SLAs,
welche aus einem Schulungsdefizit des Kunden hervorgeht.
Seite 17 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
6.7.2. Datenhoheit
Die Daten gehören prinzipiell dem Kunden, und der Kunde hat somit die Verantwortung für deren
Benutzung. Er ist demensprechend verpflichtet alle lokalen und nationalen Gesetzgebungen,
sowie die internen ETH Richtlinien im Umgang mit Telematik Ressourcen (7.3 BOT
(Benutzungsordnung für Telematik)) einzuhalten.
Dementsprechend unterliegt es auch dem Mailboxbesitzer, Dritten den Zugriff auf seine Daten zu
erlauben oder diesen zu verweigern. Administrative, vom Besitzer nicht autorisierte Zugriffe auf
seine Mailboxdaten werden nur aufgrund einer richterlichen Anweisung oder im Auftrag des
zuständigen Sicherheitsbeauftragten vorgenommen.
6.8. Serviceentwicklung (life cycle management)
Die Informatikdienste behalten sich vor, die Serviceinfrastruktur laufend neuen Entwicklungen
anzupassen. Dies schliesst die regelmässige Installation von Updates ebenso ein wie die
Installation, Konfiguration einzelner Services, sowie deren Abbau oder den Ersatz der gesamten
Dienstleistung durch eine alternative Lösung.
Kleinere Serviceunterbrüche werden innerhalb der definierten Wartungsfenster durchgeführt. Bei
grösseren Unterbrüchen oder Änderungen im Grundangebot dieses SLAs wird vorgängig über
verschiedenste Informationskanäle informiert werden (ITEK, Verteilerliste für Mailadministratoren,
Informationsveranstaltungen, etc.).
7. Allgemeine Richtlinien
7.1. Haftungsauschluss
Die Informatikdienste können nicht für Schäden verantwortlich gemacht werden, welche direkt
oder indirekt durch den Betrieb oder den Ausfall eines Dienstes oder Servers verursacht werden.
7.2. Generelle AGB’s
Bei Unregelmässigkeiten, speziell bei Verdacht auf Hackeraktivitäten (passiv und aktiv) oder
anderen Auffälligkeiten, welche die Mailinfrastruktur in Teilen oder als Ganzes gefährden, haben
die Informatikdienste das Recht, die betroffenen Servicekomponenten jederzeit und ohne
Vorankündigung vom Netz zu nehmen, sowie weitere für die Sicherheit des ETH Netzwerkes und
den Ruf der ETH Zürich notwendige Massnahmen zu ergreifen.
7.3. BOT (Benutzungsordnung für Telematik)
https://rechtssammlung.sp.ethz.ch/Dokumente/203.21.pdf
https://rechtssammlung.sp.ethz.ch/Dokumente/203.21en.pdf
Seite 18 / 19Standard Dienstleistungsvereinbarung (Service based SLA) für
„Mail und Groupware“
Seite 19 / 19Sie können auch lesen
