<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"><channel><title>Blog | 208.fi</title><link>https://208.fi/de/blog/</link><description>Beiträge über die digitale Sicherheit durch alle Schichten im Internet</description><generator>Hugo</generator><language>de-DE</language><copyright>Project Organisation Helsinki</copyright><creativeCommons:license>https://creativecommons.org/licenses/by/4.0/</creativeCommons:license><lastBuildDate>Sat, 19 Sep 2026 16:45:00 +0300</lastBuildDate><atom:link href="https://208.fi/de/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>Hochverfügbarkeit durch eine verteilte Architektur</title><link>https://208.fi/de/blog/hochverf%C3%BCgbarkeit/</link><pubDate>Sat, 19 Sep 2026 16:45:00 +0300</pubDate><guid>https://208.fi/de/blog/hochverf%C3%BCgbarkeit/</guid><description>&lt;p&gt;Hochverfügbarkeit bezeichnet Dienste, die den Betrieb mit einer hohen&#10;Wahrscheinlichkeit gewährleisten. Wenn der Dienst auf mehrere&#10;unabhängige Geräte ausgerollt wird, sollte ein einzelnes Gerät auf&#10;weniger Anfragen reagieren. Dies sorgt nicht nur für bessere Leistung&#10;oder Latenz, sondern auch für eine bessere Fehlertoleranz. Wenn einer&#10;unserer &lt;a href="https://208.fi/de/begriff/dns/"&gt;Nameserver&lt;/a&gt; langsamer oder blockiert wird, würde&#10;der Dienst dank eines anderen Nameservers weiterlaufen.&lt;/p&gt;&#10;&lt;p&gt;Theoretisch spielt die Ursache des Ausfalls eines Geräts keine Rolle.&#10;Die häufigste &lt;q&gt;Störung&lt;/q&gt; unserer Nameserver ist wohl das&#10;regelmäßige Aktualisieren von Service-Containern und Inhalten, wodurch&#10;ein Server nach dem anderen für kurze Zeit deaktiviert wird. Da die&#10;Funktionalität des aktualisierten Geräts vor der Aktualisierung des&#10;nächsten überprüft wird, kann maximal ein Gerät zerstört werden. Falls&#10;nötig, kann es auf die Lage vor der Aktualisierung zurückgesetzt&#10;werden. Während dieser Zeit halten die anderen Server den Dienst&#10;verfügbar. Bei uns geschieht all dies automatisch in &lt;a href="https://208.fi/de/blog/eigenes-gitlab-erp/"&gt;unserem auf&#10;GitLab basierenden ERP-System&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>So wurde unser souveränes GitLab-ERP-System implementiert</title><link>https://208.fi/de/blog/eigenes-gitlab-erp/</link><pubDate>Sat, 12 Sep 2026 13:00:00 +0300</pubDate><guid>https://208.fi/de/blog/eigenes-gitlab-erp/</guid><description>&lt;p&gt;&lt;a href="https://projectorganisationhelsinki.fi/en/continuity/"&gt;Betriebliches&#10;Kontinuitätsmanagement&lt;/a&gt;&#10;ist eines unserer Geschäftsfelder. Wie wird es bei uns eingesetzt? Das&#10;&lt;q&gt;Gehirn&lt;/q&gt; des Unternehmens ist ein ERP-System, wodurch die&#10;Einsatzplanung der vorhandenen Ressourcen stattfindet. Eigentlich wird&#10;dadurch alles verwaltet, was etwas mit dem Geschäft zu tun hat, auch&#10;die Veröffentlichung dieses Schreibens.&lt;/p&gt;&#10;&lt;p&gt;Aus Erfahrung haben wir GitLab gewählt. Damit meinen wir nicht die&#10;Dienstleistung &lt;a href="https://gitlab.com"&gt;gitlab.com&lt;/a&gt; sondern die&#10;&lt;a href="https://docs.gitlab.com/install/"&gt;Einrichtung&lt;/a&gt; der quelloffenen&#10;Software in unserem eigenen privaten Netzwerk.&lt;/p&gt;&#10;&lt;p&gt;Wegen der Datensicherheit setzen wir einen eigenen geschlossenen&#10;LDAP-Verzeichnisdienst und eine private Infrastruktur für digitale&#10;Zertifikate ein. Die sämtlichen Container unserer Dienste werden&#10;mithilfe von GitLab-Pipelines in geschlossenen&#10;&lt;code&gt;gitlab-runner&lt;/code&gt;-Containern in einer isolierten Umgebung aufgebaut.&#10;Dank einer zentralen Logbuchverwaltung haben wir stets ein Überblick&#10;über das verteilte System. Auf einer ähnlichen Weise funktioniert auch&#10;der &lt;a href="https://208.fi/de/produkte/gitlab/"&gt;GitLab-Dienst&lt;/a&gt;, den wir unseren Kunden anbieten.&lt;/p&gt;</description></item></channel></rss>