Hallo zusammen, (PM&Support fühlt sich mal bitte in cc) Danke an alle für das Meeting gestern. So konnten wir zunächst erst einmal alle abholen, - die Admins, die den Dienst mehr oder weniger lange schon machen - die Entwickler, die teilweise auch schon betroffen sind Mir hat neben dem Konsens, wie wir weitermachen wollen, vor allem sehr gut gefallen, das so viele Ansätze existierten, wie wir diese Leistung organisieren und professionalisieren können. Wobei auch gleich hier betont werden soll: :=> Das Hauptaugenmerk liegt auf der Vermeidung der Einsätze Aber auch dazu hatten wir ja viele Ansätze. Damit das gesprochene nicht untergeht, fasse ich mal ein paar Punkte zusammen: 1. Zeiten - Überlegung von 3 "Schichten" o 08:00 – 16:30 o 11:30 – 20:00 o 20:00 – 08:00 - Reaktionszeiten o 08:00 – 20:00 innerhalb von max. 15 Min. § Meetings / Pausen / etc. werden abgebrochen … o 20:00 – 24:00 innerhalb von max. 1 STD § Man geht nach Hause, startet den Rechner etc. o 24:00 – 08:00 Reaktion vor 7:00 Uhr 2. Bereitschaftsplan - Tilo hat ein Tool, was sehr einfach eine Planung darstellen würde o Dieses Tool enthält dann die geplanten Schichten mit den jeweiligen Personen o Personen, die die Planung ändern wollen, weil sie keine Zeit mehr haben, müssen Vertreter finden und eintragen o Toll stellt mit einer gewissen Übersicht die Verteilung pro Person da. o Tilo macht Lösung fertig und präsentiert diese o Termin: offen - Bis zur Fertigstellung o Details bis Fr. 3. Benachrichtigungen - Notfälle werden folgendermaßen angekündigt o Nagiosmeldung, § die Fehler ankündigt (Platte wird immer weniger) § die Fehler anzeigt (Downmeldung) o notfall@traso.de :=> SMS § Kunden melden Notfälle so § HGE wird Notfälle so melden § TT schickt während Bürozeiten Mails auch an diese Adresse o Telefon – Notfallnummer § Wird weitergeleitet auf „Einsatz-Handy“ ToDo: - Nagiosmeldungen zusätzlich weiterleiten an o SRK, SPE, SWI o Zielsetzung Prüfung der Meldung im Hinblick auf Verbesserungspotential Und Möglichkeit schaffen auf die Meldungen zu reagieren - Routing Notfall SMS o Aufnahme von SRK, SPE, SWI in Liste 4. Übernahme der Aktivität - ACK Mail an notfall@traso.de - Chat System wird aufgebaut o Solange dies nicht bei HGE auf Iphone und Laptop läuft o Skype Bereit - Fertigmeldung wenn erledigt - Hat es eine Kundenmail gegeben, so wird übernahme und Fertigstellung auch an Kunde gemeldet o „Vielen Dank für den Hinweis, wir prüfen die Situation und melden uns“ o „Die Situation ist behoben, eine genauere Fehlerbeschreibung kommt über den Support“ 5. Ausstattung - Notebook o Teilweise vorhanden / ansonsten Bereitschaftsnotebook - Notfalltelefon o Teilweise vorhanden / HGE klärt individuell mit jedem - VPN Tunnel auf Telefon o Tilo erarbeitet Lösung (schon sehr weit) o Termin offen - Chat – Lösung s.o. 6. Einsatzscope - xRes Livesysteme (Service01, DB01, STADIS, Cache, Mongocluster) o Admin und Entwickler o Sofortiger Einsatz siehe Zeiten - xRes sonstige Systeme (Data01, Replikation, Testsysteme) o Admin und Entwickler o Einsatz während der Bürozeiten - Sonstige Systeme (Netzinfrastruktur, Mail, OTRS, LTS Server) o Admin o Sofortiger Einsatz siehe Zeiten 7. Arbeitszeiten - Findet ein Einsatz statt, so ist das natürlich Arbeitszeit - Diese wird mit entsprechenden Aufschlägen (Nacht und Wochenende etc.) erfasst - Die genaue Aufstellung suche ich noch raus und verteile diese - Die Erfassung in unserer Arbeitszeit ist aktuell noch schwierig o Hier überlegen wir mal, ob wir nicht ein neues Tool finden o Bis dahin müssen die Zeiten nachgetragen werden 8. Nagiosmeldungen - Wie schon erwähnt ist die Qualität ausbaubar - SLS hat sich verraten, dass er dort einige Erfahrungen mitbringt - Als kontinuierlichen Prozess wollen wir: o Von Seiten der Entwickler und Admins Ursache für Fehler erkennen und durch System oder Applikationsanpassungen dauerhaft vermeiden o Von Seiten der Entwickler Ereignisse aufnehmen, die im Monitoring fehlen Bsp. Mongo Prozesse o Von Seiten der Entwickler und Admins bestehende Meldungen optimieren o Von den Admins die Integration der Nagios Meldungen in Chef Rezepte aufnehmen, um sie bei neuen Servern sofort wieder aufgesetzt zu haben o Zielsetzung: § Es gibt keine Meldung, auf die nicht reagiert wird (zumindest als Warnung, dass dort innerhalb der nächsten Tage Handlungsbedarf ist) § Fehlerfälle der Produktivsysteme werden alle im Monitoring erfasst § Es gibt unterschiedliche Empfänger für die verschiedenen Meldungen § Und vor allem · Es gibt weniger Bereitschaftseinsätze · Die Auswirkungen für die Kunden werden geringer 9. Folgetermin - Letzte Woche im November KW 44 - Kleinere Runde - Aktueller Stand - Einladung HGE Wir hatten noch mehr besprochen, dies waren nur die wichtigsten Punkte Allen noch eine schöne Restwoche Mit freundlichen Grüßen Haiko Gerdes - Geschäftsführer - ___________________________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 / Leipzig Tel.: +49 341 90 98 7 418 // Fax: +49 341 90 98 749 Mobil: +49 172 610 2849 Internet: http://traso.de E-Mail: h.gerdes@traso.de ___________________________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 -----Ursprüngliche Nachricht----- Von: Haiko Gerdes [mailto:h.gerdes@traso.de] Gesendet: Montag, 10. November 2014 15:53 An: 'Marcus Puchalla'; 'team@lists.traso.de' Betreff: AW: [Team] Vorschlag / Empfehlungen für gemeinsame Notfall-Dienst-Regelungen Hallo zusammen, zunächst einmal danke an Stefan und Thomas für die ersten Vorbereitungen und Marcus für seine Kommentare. Ich möchte das Thema dann morgen von 11:30 - max. 13:00 im Besprechungsraum mit Euch gemeinsam angehen. Zusätzlich zu den Punkten aus den beiden anderen Mails haben wir dann insgesamt folgende Themen, die wir morgen besprechen wollen: 1. Zeiten - Wie schnell muss wann reagiert werden 2. Notfallmitarbeiter - Wer kann und sollte in Bereitschaft sein 3. Knowhow - Welche Informationen müssen dafür vorhanden sein 4. Berechtigungen - Welche Berechtigungen sind erforderlich 5. Ausstattung - Was wird benötigt und was ist vorhanden / pro Mitarbeiter 6. Wo und wie erfolgt die Planung - Wer hat wann Einsatz - Wie wird es dokumentiert 7. Wie erfolgt die Benachrichtigung - Wir haben heute bereits die <mailto:notfall@traso.de> notfall@traso.de Eingehend per Mail Verteilung per SMS - Wer bekommt die in Zukunft - Wie gehen wir mit den Nagios Meldungen um 8. Übernahme der Bearbeitung - Wie wird kommuniziert - "Bin dran" - Wie kommunizieren wir während der Bearbeitung - Oft sind mehrere involviert - Skype Online 9. Abschluss - Wer informiert wen, wenn fertig - Fehlerbericht - Downtime von bis 10. Notfalleinsatz ist Arbeitszeit - Wie dokumentieren wir das als Arbeitszeit - Berechnung der Arbeitszeiten nach Notfalleinsätzen - Wieder im Büro nach Einsätzen Mit freundlichen Grüßen Haiko Gerdes - Geschäftsführer - ___________________________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 / Leipzig Tel.: +49 341 90 98 7 418 // Fax: +49 341 90 98 749 Mobil: +49 172 610 2849 Internet: <http://traso.de> http://traso.de E-Mail: <mailto:h.gerdes@traso.de> h.gerdes@traso.de ___________________________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 -----Ursprüngliche Nachricht----- Von: team [ <mailto:team-bounces@lists.traso.de> mailto:team-bounces@lists.traso.de] Im Auftrag von Marcus Puchalla Gesendet: Montag, 10. November 2014 12:31 An: <mailto:team@lists.traso.de> team@lists.traso.de Betreff: Re: [Team] Vorschlag / Empfehlungen für gemeinsame Notfall-Dienst-Regelungen Hallo Team, vielen Dank an Stefan und Thomas für die initiale Ideengebung. Ich wäre generell bei einer solchen Notfall-Regelung dabei. Denn es macht uns allen das Leben leichter. 1. Generell bin ich technisch soweit ausgestattet das ich keine weiteren Gadgets benötige. Ein Laptop habe ich und ein "privates" Handy ja auch. Ich bin also im Notfall (wenn zuständig) zu erreichen. Es ist aber auch zu bedenken, dass evtl. auch längere Telefonate zw. den Programmieren/Admins/Support anfallen. Dies Kosten dafür hat der Mitarbeiter bisher selbst gezahlt. Aus diesem Grund würde ich mind. 1 zusätzliches Handy für den an diesem Tag zuständigen Mitarbeiter anschaffen. 2. Die Nutzung vom Confluence Kalender finde ich gut. Zur Abstimmung würde ich den "Teams" mit einem Monat Vorlauf die Planung selbst in die Hand geben. So das z.B. aktuell jedes Teams bis spätestens 25.11 die Planung für Dezember festlegen. Das dann feststeht wer jedes WE verantwortlich ist. Sollte jemandem dann spontan in der Woche auffallen das er an einem WE doch nicht kann, dann muss intern eine Vertretung gefunden werden und dies in einer Hotfix-Vertretungs Mail kommuniziert werden. Generell schlage ich zur gerechten Verteilung entweder einen Round Robin Algorithmus vor, oder eine wöchtentliche Runde Mensch ärger die nicht :) Da ich ab und an in Regionen unterwegs bin, in denen es keine Internet, Handyempfang, UMTS, 3G ... oder sonstiges gibt, sollten auch solche Situationen in den Terminkalender aufgenommen werden. Da ich an solchen Terminen auch im Falle einer Nicht-Bereitschaft, für Nachfragen nicht zu erreichen wäre. 3. Die Liste welche Thomas erstellt sollte dann jeder auch für seinen Services pflegen. (Wiki Seite??) Ich selbst könnte dies z.B. für [LB]olek, AIF Nodes und Mongo machen. D.h. was gibt es an Monitoring und was sollte es noch geben bzw. was sollte es nicht mehr geben. 4. Hier würde ich für meinen Teil im laufe der Woche mit der Dokumentation beginnen. Und dann gern innerhalb der nächsten Wochen einen Vortrag halten. VG Marcus Am 10.11.2014 um 11:14 schrieb Stefan Rank Kunitz:
Hallo Team,
Thomas Koelzow und ich haben uns zum Thema Notdienste etwas Gedanken
gemacht und machen hiermit einige Verschläge zur Schaffung einer
Regelung. Wir lassen dabei die Themen Vergütung und
Arbeitszeitregelungen bewusst außen vor, da diese Themen im Rahmen
einer individuellen Abstimmung zwischen Mitarbeiter und
Geschäftsleitung besprochen werden sollten.
Grundsätzlich sollte es so sein, dass die Entwicklung in Zukunft die
Notfalldienste unterstützt. Wir halten es daher für sinnvoll, wenn
jeweils ein Admin und ein Entwickler _gemeinsam_ einen Notdienst
übernehmen. Nach einem zuvor abgestimmten Dienstplan landen Notfälle
bei diesen beiden Mitarbeitern und werden von ihnen gemeinsam bearbeitet.
Beide Kollegen stellen selbstständig sicher, mit Handy, Laptop und
Internetzugang erreichbar und einsatzfähig zu sein.
In der Gruppe der Admins bitten wir diese Kollegen, sich für einen
Notfall-Dienstplan zur Verfügung zu stellen:
* Thomas Koelzow ( Laptop vorhanden, Diensthandy vorhanden)
* Tilo Werner ( Laptop vorhanden, Diensthandy vorhanden)
* Jan Zacharias ( Laptop vorhanden, Diensthandy vorhanden)
* Stefan Ludwig-Schindler (Laptop vorhanden, Diensthandy ist
bestellt)
Bei den Entwicklern bitten wir diese Leute, die Notfalldienste zu
unterstützen:
* Sören Pestner ( Laptop vorhanden, Diensthandy benötigt?)
* Stefan Wieden ( Laptop vorhanden, Diensthandy benötigt?)
* Marcus Puchalla ( Laptop vorhanden, Diensthandy benötigt?)
* Stefan Rank-Kunitz ( Laptop vorhanden, Diensthandy benötigt?)
* Viktoras Bezaras ( Laptop vorhanden, Diensthandy benötigt?)
* Oliver Horn ( gemeinsamer Notfall-Laptop vorhanden?, Diensthandy
benötigt?)
* Dave Derbis ( gemeinsamer Notfall-Laptop vorhanden?, Diensthandy
benötigt?)
* ggf. Sven Georgi ( gemeinsamer Notfall-Laptop vorhanden?,
Diensthandy benötigt?)
Ich bitte um eine Rückmeldung dazu, ob die Kollegen an einer
Notfall-Dienst-Lösung teilnehmen möchten und welche technische
Ausstattung dafür benötigt wird.
Zur Vorbereitung einer Notfall-Regelung haben wir diese Anmerkungen bzw.
abzustimmende Fragen:
1. technische Umsetzung - Teil 1: Welche technische Infrastruktur
benötigen die einzelnen Mitarbeiter für ihre Teilnahme? Müssen
Handys, Laptops oder anderes bestellt werden? Können Notfall-Handys
und Notfall-Laptops "weitergegeben" und so gemeinsam verwendet werden?
2. technische Umsetzung - Teil 2: Kann für die Umsetzung des
Dienstplanes ein neuer Confluence-Kalender genutzt werden? Dieser
wäre bereits einsetzbar (kein Aufwand erforderlich) und kann sehr
einfach in Thunderbird/Lightning eingebunden werden. Ist es ggf.
erforderlich, diesen von außen (ohne VPN, z.B. auf dem Handy) nutzen
zu können?
Wer wird die Abstimmung des Dienstplanes inhaltlich dauerhaft
vornehmen und eintragen?
3. Das aktuelle Management der Notfall-Meldungen sollte durchgesprochen
und ggf. optimiert werden. Gegenwärtig bekommen wir Meldungen
- per SMS und/oder E-Mail von extern (Travel-IT, TravelTainment,...?),
- unsere Nagios-Meldungen und
- als E-Mail an notfall@.
Wir sollten eine Lösung erarbeiten, bei der immer genau die
diensthabenden Kollegen diese Nachrichten mit sehr hoher Prio (z.B.
per SMS) bekommen, andere Kollegen aber ebenfalls darauf zugreifen
KÖNNEN (z.B. per E-Mail).
In diesem Schritt scheint es auch sinnvoll zu sein, die Menge der
Nagios-Meldung zu prüfen und ggf. anzupassen: Gibt es Nachrichten,
die momentan verschickt werden, die aber eigentlich niemand lesen
will? Thomas wird dazu eine Liste der Meldungen erstellen, die
Nagios aktuell verschickt.
Gibt es Systembereiche, die aktuell zu wenig oder gar nicht im
Nagios Monitoring enthalten sind und deren Verfügbarkeit wir in
Zukunft prüfen sollten? Wir konnten dazu diese Punkte bereits
identifizieren:
- RabbitMQ (OHO und SRK erstellen ein Monitoring-Skript für Nagios),
- Mongo-DB (MPU hat dazu Test-Skripte),
- Buchbarkeit / Antwortzeiten des Buchungskerns (OHO und SRK
arbeiten auch hier an einem Test-Skript)
- alte und neue (Lingenauber) Stadis-Struktur (Erreichbarkeit der
Stadis-Gateways)
4. Schulungen: Die Kollegen (Admins wie Entwickler) sind aktuell sehr
wenig in der Lage, evtl. auftretende Probleme im Arbeitsbereich
anderer Entwickler zu lösen. Es sollte daher in naher Zukunft einige
Schulungen geben, bei denen die Kollegen sich gegenseitig einen
Einblick in technische Grundstrukturen geben, dabei häufig
auftretende Probleme ansprechen und Hilfswerkzeuge vorstellen. Jeder
Vortrag sollte in einem kurzen Wiki-Eintrag (Übersichtsgrafiken,
Syntax wichtiger Befehle, URLs wichtiger Websites, ...) festgehalten
werden.
Wir würden uns freuen, wenn wir einen Beitrag zum Aufbau einer für
Kunden und Mitarbeiter hilfreichen Lösung beitragen können!
VG SRK
--
Mit freundlichen Grüßen
Stefan Rank-Kunitz
- Lead Developer -
________________________________________________________
TraSo GmbH
Georg-Schumann-Str. 294
D-04159 Leipzig
Tel.: +49 341 909 87 45
E-Mail: <mailto:s.rank-kunitz@traso.de> s.rank-kunitz@traso.de
Internet: <http://www.traso.de> http://www.traso.de
________________________________________________________
Geschäftsführer: Haiko Gerdes
Handelsregister: Amtsgericht Leipzig, HRB 21850
_______________________________________________
team mailing list
<mailto:team@lists.traso.de> team@lists.traso.de
<https://lists.traso.de/listinfo/team> https://lists.traso.de/listinfo/team
-- Mit freundlichen Grüßen Marcus Puchalla - Entwicklung - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 909 87 45 / Fax: +49 341 909 87 49 E-Mail: <mailto:m.puchalla@traso.de> m.puchalla@traso.de Internet: <http://www.traso.de> http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850