Headerbild | Monitoring-, Deployment- und Qualitätssicherungsprozesse der dkd
datenschutzDeploymentdkdeploy
Autor: Alexander Degelmann

Monitoring-, Deployment- und Qualitätssicherungsprozesse der dkd

Anforderungen an die Systemsicherheit

Eine fehlerfreie Funktion sowie die Ausfall- und Systemsicherheit der zu entwickelnden Lösungen sind zentrale Erfolgsfaktoren von Webanwendungen.
Deshalb möchten wir diesmal darlegen, welche Monitoring-, Deployment- und Qualitätssicherungsprozesse bei uns eingesetzt werden, um ein hochverfügbares, sicheres und fehlerfreies System zu gewährleisten.

Einleitung

Bei den durch uns betreuten Websites konnten wir feststellen, dass wenn Störfälle überhaupt auftreten, diese zu 99 % auf Infrastrukturebene entstehen.

In diesem Beitrag beschreiben wir unser Standardvorgehen in der Entwicklung, beim Deployment sowie mögliche Maßnahmen, die Infrastruktur abzusichern und die Applikation und die Infrastruktur zu überwachen. Zuletzt stellen wir unser Vorgehen bei eventuell auftretenden Störungen dar.

Sicherheit in der Entwicklung

Der dkd-eigene Entwicklungsprozess

Entwickelte Features oder Änderungen werden grundsätzlich durch eine*n zweite*n Entwickler*in lokal geprüft (Code Review via GitLab und Testing). Durch das Peer-Review-Verfahren können grundlegende Fehler und Verstöße gegen Konventionen bereits vor einem Deployment erkannt und direkt behoben werden. Somit lassen sich große Feedback-Schleifen vermeiden. Die durch die Peer-Review lokal getesteten Code-Änderungen werden nach Freigabe durch den oder die zweite*n Entwickler*in in der Develop-Pipeline auf die Integration- und Testing-Stage weitergegeben. Auf der Integration-Stage wird durch den oder die Quality Manager*in nach dem featurespezifischen Testplan (Positiv- und Negativtests) und der Definition of Done getestet. Auf der Testing Stage testet ein*e Kundenmitarbeiter*in. Erst dann werden Änderungen und Features auf die Liveumgebung deployed.

Deploymentprozess mit dkdeploy

Beim Deployment mit dkdeploy verwenden wir zwei Pipelines (Develop und Master) für die Weitergabe der Änderungen auf die Server mit Kopien der Webseite (Stages). Die Develop-Pipeline umfasst die Integration- und Testing-Stage. Die Master-Pipeline umfasst zusätzlich zur Integration- und Testing-Stage noch die Production-Stage (Live-Seite). Das Deployment wird zum Projektbeginn konfiguriert und läuft automatisiert ab. Bei jedem Deployment werden die PHP-, JS- und CSS-Syntax sowie die Funktionen der Webseite auf Fehler geprüft.

Für den Funktionstest der Seite werden UAT (User Acceptance Tests) eingesetzt. Hierfür arbeiten wir mit dem Framework Cypress. Cypress ist ein JavaScript Framework zum Testen des Frontends.

Hierzu veröffentlichen wir in den nächsten Tagen einen weiteren Blogbeitrag.

Diese Tests lassen sich übrigens auch ohne Programmierkenntnisse erstellen, wodurch das Testing wesentlich vereinfacht wird. Mithilfe der Stages lassen sich die Änderungen auf einer Umgebung testen, die der Live-Seite entspricht. Dadurch ist eine frühzeitige Fehlererkennung und -behebung möglich. Im Fall eines Hotfixes kommt es aufgrund der zwei Pipelines zu keinen Blockaden im Entwicklungsprozess, da Hotfixes über die Master-Pipline entwickelt und deployed werden.

Für das automatisierte Deployment mit dkdeploy wird das webbasierte Softwaresystem Jenkins eingesetzt. Dies bietet unter anderem die Möglichkeit, bei einem fehlerhaften Deployment einen automatischen Rollback auszuführen und die Seite auf den vorherigen Stand zurückzusetzen. Das automatisierte Deployment erleichtert die Arbeit der Entwickler, indem es bei kontinuierlichen Änderungen des Codes diesen auf Fehler überprüft und Fehler vor der Veröffentlichung feststellt, lokalisiert und somit nachvollziehbar macht. Dadurch ist zum einen eine gezielte Fehlerbehebung möglich und zum anderen werden aufgrund der Wiederholbarkeit und Genauigkeit der automatisierten Tests langfristig Kosten und Zeit gespart.

Sicherheit für die Infrastruktur

Absicherung der Infrastruktur

Um einen Ausfall eines Servers am effektivsten zu verhindern, empfehlen wir ein HA-Setup (High Availability Setup). Bei diesem Setup werden zwei identische Server betrieben. Im Falle eines Ausfalles oder eines Problems wird der Traffic innerhalb weniger Sekunden auf den Hot-Standby-Server umgeleitet. Diverse technische Lösungen wie DRBD und mySQL-Replikation sind dafür verantwortlich, dass die produktiven Daten ständig konsistent und synchron bleiben. Die Cluster Ressource Manager Software "Pacemacer" sorgt dafür, dass die Dienste, gepaart mit den zugewiesenen Daten, zwischen den aktiven und Hotstandby-Nodes bei einem Ausfall automatisch umgeschaltet werden und somit erreichbar bleiben. Die Grafik erläutert das grundsätzliche Setup und die Serverkonfiguration.

Bei unseren Kunden stehen die Server in physisch getrennten Rechenzentren, somit ist eine Nichterreichbarkeit der Webseite nahezu ausgeschlossen.

Monitoring der Infrastruktur


Beim Infrastruktur-Monitoring setzen wir Nagios und Munin ein.
Damit können folgende Komponenten und Verbindungen effektiv überwacht werden:
 

  • Erreichbarkeit des Webservers
  • Korrekte Antwort des Webservers
  • Check der SSL-Zertifikate hinsichtlich des Ablaufdatums
  • Überwachung spezifischer Serverkomponenten
    • CPU Last
    • RAM und SWAP Speicher Nutzung
    • Anzahl der aktiven Prozesse
    • Freier Festplattenspeicherplatz
    • MySQL-Status
    • Anzahl der Verbindungen zu MySQL
  • Überwachung des Apache-Status
    • Fehlerfreie Apache-Konfiguration
    • Anzahl der Apache-Prozesse
    • Anzahl der aktiven Verbindungen zu Apache
  • Performance Werte im zeitlichen Verlauf via Munin
    • Apache: Mehrere Metriken wie
      • Nutzung der Bandbreite einzelner Vhosts,
      • Anzahl der Verbindungen zu einzelnen Vhosts, usw.
    • MySQL: mehrere Metriken wie
      • Anzahl der Transaktionen,
      • Indexes,
      • Cache,
      • Netzwerktraffic, usw.
    • Netzwerk: mehrere Metriken wie Traffic, Netztest, usw.
    • HDD: mehrere Metriken wie
      • Latenz,
      • IO,
      • Speichernutzung, usw.
    • Arbeitsspeicher: mehrere Metriken wie
      • Nutzung,
      • Cache,
      • SWAP, usw.
    • System: mehrere Metriken wie
      • CPU-Last,
      • Interrupts,
      • Index-Nutzung, usw.

Gegenmaßnahmen und Prozesse

Vom Monitoringsystem erkannte Störungen werden innerhalb weniger Minuten an die festgelegten, verantwortlichen interdisziplinären Teams (Administrator*innen und Entwickler*innen bzw. DevOps) gemeldet. Bei länger bestehenden Störungen der Klasse „Warnung“ und bei Störungen der Klasse „Kritisch“ können individuelle Eskalationen aktiviert werden. Somit können die zuständigen Personen oder Teams zeitnah die Störung beseitigen.
Die gemeldeten Störungen werden automatisiert an unser Ticketsystem weitergeleitet und von den Verantwortlichen bearbeitet:

  1. Eine Ursachenanalyse wird durchgeführt.
  2. Entwicklung einer Lösungsmöglichkeit.
  3. Abstimmen mit zuständigen Personen/Teams, die für die Lösung benötigt werden.
  4. Beseitigung der Ursache.
  5. Manuelle Verifizierung der Fehlerbehebung.
  6. Verifizierung der Fehlerbehebung im Monitoringsytem.
  7. Ergreifung von Maßnahmen, um die Fehlerursache zukünftig zu beseitigen.

Sicherheit auf Applikationsebene

Zentrales Logging-System für die Früherkennung von Fehlermeldungen

Um die Applikation zu überwachen, verwenden wir ein zentrales Logging-System. Hier setzen wir im Wesentlichen auf Sentry oder Graylog. Mithilfe dieser Systeme identifizieren wir systemische Fehler und analysieren deren Ursachen, um diese beheben zu können.

Security-Monitoring TYPO3

Mit Hilfe der Extension Caretaker, deren Maintenance wir inzwischen übernommen haben, lassen sich TYPO3 und viele Extensions hinsichtlich Sicherheitsproblemen überwachen. Sobald eine Warnung des TYPO3 Security Teams für TYPO3 oder eine Extension veröffentlicht wurde, wird von Caretaker überprüft, ob die TYPO3-Instanz von dieser Meldung betroffen ist. Sollte eine überwachte Instanz betroffen sein, sendet Caretaker eine Mitteilung in unsere Chatsoftware. Außerdem versendet Caretaker eine projektspezifische Mail, die in unserer Projektmanagement-Software ein Ticket erzeugt. Diese Tickets und Chatmitteilungen erzeugen widerum entsprechende Nachrichten für unsere Supportmitarbeiter*innen. Die Supportabteilung kümmert sich dann zeitnah darum, dass die Sicherheitslücken umgehend geschlossen werden.


Über den Autor

Alexander Degelmann

Alexander Degelmann is a jack of all trades belonging to digital and agile topics at dkd Internet Service GmbH. In private his heart beats for his family, handball and wakeboarding.

Mehr Beiträge von diesem Autor

Kommentar schreiben

Ich willige in die Speicherung meiner Daten ein.*

Hinweise und weitere Informationen zu der von Ihnen gegebenen Einwilligung zur Speicherung der oben eingegebenen Daten zum Zweck der Kontaktaufnahme und Ihrem Widerrufsrecht erhalten Sie in den Datenschutzhinweisen.

* Diese Felder sind Pflichtfelder