Der Chip stürzt nicht ab – er wird einfach ausgeschaltet. Beim WLAN-Start fängt der Mikrocontroller den Neustart-Loop an, obwohl die Firmware korrekt ist.

Einsteiger begegnen dem Problem beim ersten Flashen: Die Firmware wird über USB in den Flash-Speicher geschrieben, und genau dann, wenn in setup() das WLAN gestartet wird, startet das Gerät endlos neu. Wer den Brownout-Reset nicht kennt, sucht wochenlang nach Softwarefehlern.

Ein Brownout-Reset ist das kontrollierte Abschalten des Mikrocontrollers, wenn die Versorgungsspannung kurz unter eine festgelegte Abschalt-Schwelle fällt. Der Chip startet dann bewusst neu, um Datenfehler zu vermeiden. Das Hochfahren des Funkmoduls zieht für Millisekunden deutlich mehr Strom als im Ruhezustand.

Das ohmsche Gesetz erklärt den Zusammenbruch: Jede Spannungsquelle hat einen Innenwiderstand. Steigt der Strom, sinkt die Spannung um Widerstand mal Strom, und der Chip fällt unter die Schwelle.

Klassisches Bild: Ein ESP32 an einem schwachen Netzteil. Serial.begin() im setup() läuft, der serielle Monitor zeigt Meldungen – bis die WLAN-Verbindung startet. Dann Neustart, wieder WLAN, wieder Neustart. Die Baudrate, also die Übertragungsgeschwindigkeit der seriellen Schnittstelle, ist bei Firmware und Monitor gleich, die Firmware auch. Nur die Versorgung bricht zusammen.

Der Unterschied: Der Chip startet nicht neu, weil das Programm fehlschlägt, sondern weil die Spannung fehlt. Auch ein zu dünnes USB-Kabel oder ein schlechter Breadboard-Kontakt verursacht denselben Reset.

Brownout ist kein Softwarefehler, sondern ein Symptom zusammenbrechender Versorgung. Abhilfe: ein ausreichend dimensioniertes Netzteil, kurze dicke Leitungen und ein Abblockkondensator, also ein Kondensator von der Versorgung nach Masse nahe am Chip, der Stromspitzen abfängt.

📌 Brownout-Reset · Innenwiderstand · Abblockkondensator

📚 IoT von Grund auf · Tag 6 von 30
#esp32 #Mikrocontroller #firmware

Der Mikrocontroller stürzt genau beim Senden ab. Dabei fehlt meist nur ein winziger Kondensator direkt am Pin.

Viele Einsteiger glauben, die Stromversorgung sei gut genug, wenn der Spannungsregler (das Bauteil, das die Betriebsspannung bereitstellt) die richtige Spannung liefert. Klingt plausibel: Der Chip läuft ja stabil, solange er nur rechnet.

Tatsächlich zieht ein Mikrocontroller kurzzeitig deutlich mehr Strom, etwa beim Aktivieren des Funkmoduls. Der Entkopplungskondensator ist ein kleiner Ladungsspeicher direkt am Versorgungspin, der solche Spitzen ausgleicht. Jede Leitung zur Stromquelle hat einen kleinen Innenwiderstand und eine Induktivität (Trägheit gegen plötzliche Stromänderungen). Deshalb reagiert eine lange Leitung zu träge, und die Spannung am Pin bricht kurz ein.

Der Irrtum entsteht, weil das Messgerät nur Durchschnittswerte zeigt. Ein Spannungseinbruch von Mikrosekunden bleibt unsichtbar, führt aber zum Neustart.

Espressif empfiehlt für den ESP32 eine Versorgung, die mindestens 500 mA liefern kann, weil das Senden kurze Stromspitzen verursacht. Ein USB-2.0-Port liefert nach Spezifikation höchstens 500 mA; Entwicklungsboards mit weiteren Verbrauchern erreichen diese Grenze schnell. Praxisregel: 100 nF je Versorgungspin direkt daneben, plus ein größerer Puffer im Mikrofarad-Bereich nahe am Regler.

Woran man es erkennt: Der Controller startet sich genau beim Senden neu oder friert ein. Ein Brownout-Reset (Schutzmechanismus, der bei zu niedriger Spannung geordnet neu startet) bei WLAN-Aktivität deutet auf lange Leitungen, schwache Regler oder fehlende Pufferkondensatoren hin.

Entkopplung heißt nicht verschwendeter Platz auf der Platine, sondern ein lokaler Energiespeicher, der Stromspitzen am Pin abfängt, bevor sie den Chip abschalten.

📌 100 nF am Versorgungspin · Stromspitzen abfangen · Brownout-Reset beim Senden

📚 IoT von Grund auf · Tag 6 von 30
#esp32 #Mikrocontroller

Terraform apply läuft, und plötzlich legt es eine zweite EC2-Instanz neben der bestehenden an. Das Symptom kennen viele bei ihren ersten Cloud-Projekten.

Trotz unveränderter Konfiguration entstehen doppelte Ressourcen in der Cloud. Die alten Instanzen laufen weiter und verursachen weiterhin Kosten.

Terraform hält in einer State-Datei fest, welche echten Cloud-Ressourcen zu welchem Konfigurationseintrag gehören. Dieser State ist Terraforms Gedächtnis: Er speichert den Zustand, den Terraform beim letzten apply beobachtet hat. Bei jedem Lauf vergleicht Terraform den Soll-Zustand aus den .tf-Dateien, den Ist-Zustand aus dem State und die reale Cloud.

In der Konfiguration steht eine EC2-Instanz namens web-server. Nach dem apply liegt die Instanz-ID der erzeugten Cloud-Instanz im State. Genau diese ID erlaubt Terraform bei einer späteren Änderung, dieselbe Instanz zu aktualisieren statt eine neue zu bauen. Ohne State entsteht beim nächsten apply eine doppelte Instanz.

So prüft man es: Nach terraform apply die Ausgabe darauf prüfen, ob sie nur beabsichtigte Änderungen zeigt. Erscheinen Ressourcen als komplett neu, fehlt vermutlich die Zuordnung im State.

Der State ist kein Protokoll, sondern ein Abbuchungsregister: Er entscheidet, welche echte Ressource beim Abbau entfernt wird. Deshalb gehört er geschützt in ein Remote-Backend, ein zentraler Ablageort für den State, etwa ein S3-Bucket; dort verhindert State-Locking, dass zwei Läufe gleichzeitig denselben State überschreiben. Weil der State Klartext wie Passwörter enthalten kann, hat er nichts in Git verloren.

Ein verlorener State lässt sich über Import-Werkzeuge teilweise zurückholen. Einfacher ist es, ihn nie zu verlieren.

State heißt nicht Nebenprodukt, sondern Gedächtnis ohne Rückversicherung.

📌 State-Datei · Remote-Backend · State-Locking

📚 Cloud von Grund auf · Tag 6 von 30
#Terraform #iac #devops

Die meisten Elektronikprojekte scheitern nicht am Code, sondern an der Versorgung. Dabei reicht ein kleines Bauteil, damit ein Mikrocontroller stabil läuft.

Ein Spannungsregler ist ein Bauteil, das an seinem Ausgang eine feste, nahezu konstante Spannung hält, obwohl die Eingangsspannung schwankt. Er sitzt in fast jedem USB-Netzteil und auf jedem Entwicklungsboard.

Zuerst kommt die Schwankung am Eingang an. Eine Akkuzelle, ein Netzteil oder USB liefert keine exakt konstante Spannung. Ohne Regler läge diese Schwankung direkt am Chip.

Dann vergleicht der Regler fortlaufend seine Ausgangsspannung mit einem internen Sollwert. Ein Linearregler arbeitet dabei wie ein ständig nachgeregeltes Vorwiderstands-Bauteil. Er hält die 3,3 V stabil, indem er die überschüssige Spannung selbst abbaut.

Danach fällt die überschüssige Energie als Wärme ab. Die Verlustleistung ergibt sich aus der Spannungsdifferenz zwischen Ein- und Ausgang mal dem Strom. Bei 9 V Eingang und 3,3 V Ausgang wird so mehr als die Hälfte der Energie zu Wärme. Typisch ist ein 5-V-USB-Netzteil, das über einen Linearregler einen ESP32 versorgt. Der Regler wandelt die Differenz von 1,7 V in Wärme um. Bei hohem Strom und großer Differenz ist ein Schaltregler effizienter, der durch schnelles Ein- und Ausschalten arbeitet, aber mehr Störungen verursacht.

Zuletzt versorgt der geregelte Ausgang den Mikrocontroller. Der ESP32 arbeitet mit 3,3-V-Logik und braucht beim Senden kurze Stromspitzen. Deshalb gehören Entkopplungskondensatoren – kleine Kondensatoren, die Stromspitzen kurzzeitig abpuffern –, typisch 100 nF, so nah wie möglich an jeden Versorgungspin.

Ein ESP32 gehört also nie direkt an eine höhere Versorgungsspannung. Der Regler heißt nicht „unnötiges Bauteil“, sondern er ist der Grund, warum der Chip stabile 3,3 V bekommt – und überlebt.

📌 Spannungsregler · Linearregler · Verlustleistung

📚 IoT von Grund auf · Tag 6 von 30
#esp32 #iot

Bei jedem Ausfall stellen alle dieselben vier Fragen – immer in derselben Reihenfolge. Wer sie vorher aufschreibt, ist im Störfall sofort handlungsfähig.

Einsteiger begegnen dem Runbook meist erst, wenn eine Automation nachts ausfällt und niemand weiß, wer sie neu starten darf. Ohne dieses Wissen bleibt der Fehler liegen, bis jemand das System mühsam versteht.

Ein Runbook ist eine kurze, schriftliche Anleitung für den Störfall, die neben der Automation liegt. Es sagt im Ernstfall Schritt für Schritt, was zu prüfen und zu tun ist. Es ist keine Bauanleitung, sondern eine Notfallkarte.

Die Fragen bei einem Ausfall entstehen in fester Reihenfolge: Was macht diese Automation eigentlich? Läuft sie gerade noch? Wen muss man informieren? Wer darf sie neu starten oder abschalten? Das Google SRE Book empfiehlt deshalb Playbooks, die zu jedem Alarm die ersten Handgriffe nennen – so kann auch eine Vertretung handeln. Das Runbook braucht nur Zweck, beteiligte Systeme, Fehlerzeichen, Handgriffe und Zuständigkeit.

Ein Beispiel: Ein Workflow versendet jede Nacht Rechnungen per Zeitplan. Als Besitzerin ist die Sachbearbeiterin im Buchhaltungsteam eingetragen; sie erhält die Fehlermeldungen und hält das Runbook aktuell. Zum Besitz gehören drei schriftliche Angaben: wer Meldungen bearbeitet, wer Änderungen freigibt, wer vertritt.

Das Runbook wird oft mit der Erinnerung an die Automation verwechselt, die als Dokumentation gilt. Nach Monaten fehlt dann genau das, was der Störfall verlangt. Ein Bus-Faktor von eins – wie viele Personen ausfallen dürfen, bevor Wissen verloren geht – ist ein Betriebsrisiko.

Testen Sie das Runbook nicht im Leerlauf, sondern beim nächsten Fehler: Jede unklare Stelle sofort ergänzen.

Ein Runbook ist nicht die Erinnerung an den Bau, sondern die Antwort auf den Ausfall.

📌 Zweck · Fehlerzeichen · Zuständigkeit

📚 Automatisierung von Grund auf · Tag 6 von 30
#Automatisierung #workflow #effizienz

Der erste Docker-Build dauert Minuten, der zweite nur Sekunden – solange niemand die Anweisungsreihenfolge ändert. Dabei entscheidet oft allein die Reihenfolge im Dockerfile, ob der Cache greift oder nicht.

Das kennt jeder, der einmal ein Dockerfile (das Baurezept für ein Container-Image) geschrieben hat. Wer die Reihenfolge nicht versteht, wartet bei jeder kleinen Änderung wieder so lange wie beim ersten Mal.

Der Build-Cache ist ein Speicher für fertige Schichten. Ein Docker-Image besteht aus Schichten: Jede Anweisung wie FROM, RUN oder COPY erzeugt genau eine, die auf der vorherigen aufbaut. Beim Neubau prüft Docker jede Anweisung von oben nach unten und übernimmt unveränderte Schichten unverändert. Sobald sich eine Anweisung ändert, sind alle folgenden Schichten ungültig und werden neu gebaut – auch wenn sie selbst gleich geblieben sind.

Ein typisches Dockerfile für eine Node-Anwendung kopiert zuerst nur package.json, führt npm install aus und kopiert danach erst den Quellcode. Der Cache-Schlüssel einer Anweisung umfasst den Anweisungstext und den Inhalt kopierter Dateien: Ein geändertes package.json macht die Installations-Schicht ungültig, ein geänderter Quelltext nur die Kopier-Schicht. Eine reine Codeänderung baut also nur die letzte Schicht neu.

Verwechselt wird der Cache gern mit einem bloßen Zeitmesser. Er prüft keine Ähnlichkeit, sondern exakte Schlüssel. Steht COPY ganz oben, macht jede kleine Codeänderung die teure Installations-Schicht ungültig – und der Build dauert jedes Mal wie beim ersten Mal. Deshalb gilt: selten Geändertes wie das Basis-Image (das Image, auf dem das eigene aufbaut, etwa in der FROM-Anweisung) an den Anfang, häufig Geändertes wie den Quellcode an das Ende.

Der Build-Cache belohnt keine schönen Dockerfiles, sondern stabile Anweisungsreihen.

📌 Schichten · Cache-Schlüssel · Reihenfolge

📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting

Ein Kommentarfeld sieht aus wie ein Feld für Text. Für den Browser ist jede Ausgabe aber erst einmal Teil der Seite, den er liest, nicht reiner Text.

Genau hier werden Eingabe und Ausgabe verwechselt. Viele prüfen, was hereinkommt, und halten die Seite dann für sicher. Ob Cross-Site Scripting (XSS) entsteht, entscheidet sich aber erst bei der Ausgabe.

Eingabefilterung prüft Daten, bevor der Server sie annimmt. Sie blockt etwa HTML-Zeichen im Kommentarfeld oder lehnt verdächtige Werte ab. Das Problem: Ein Filter kann nie alle Fälle kennen. Gibt jemand statt eines Kommentars ein script-Element mit JavaScript ein, entscheidet nicht der Filter, sondern erst die Ausgabe, ob es läuft.

Ausgabekodierung, auch Escaping genannt, greift dort, wo der Schaden entsteht. Sie ersetzt Zeichen mit Sonderbedeutung durch ungefährliche Kürzel. So wird < zu &lt;, und der Browser zeigt spitze Klammern als Text an, statt sie als Tag zu lesen.

Filterung schätzt die Eingabe ein, Kodierung entschärft die Ausgabe. Weil dieselbe Eingabe in HTML-Text, Attribut, URL oder JavaScript-String je eigene Kodierungsregeln braucht, schützt nur kontextgerechtes Escaping an jedem Ausgabeort.

„Faustregel:" Eingaben validieren, um fehlerhafte Daten abzuweisen; für Sicherheit aber jede Ausgabe im passenden Kontext kodieren. Eine Content Security Policy, die vorgibt, von wo Skripte geladen dürfen, ergänzt das als zweite Verteidigungslinie.

XSS heißt nicht, dass jemand den Server knackt, sondern dass fremdes Skript im Browser der Opfer läuft – etwa mit deren Sitzungs-Cookies. Geschlossen wird die Lücke durch Kodierung am Ausgabeort, nicht durchs Filtern allein.

📌 Eingabe prüfen · Ausgabe kodieren · Kontext beachten

📚 Webentwicklung von Grund auf · Tag 5 von 30
#WebSecurity #webdev #javascript

Ein Tippfehler im Programm, eine Auszahlung an der falschen Adresse – und niemand kann zurückspulen. Genau das ist bei Smart Contracts Alltag.

Hier geht es um Programme, die auf einer Blockchain laufen und selbstständig handeln, wenn ihre Bedingungen erfüllt sind. Das Prinzip kennt man von Treuhandsystemen: Geld wird digital verwahrt, bis die Lieferung bestätigt ist.

Zuerst liegt der Smart Contract als Code auf der Kette. Die Blockchain ist dabei ein verteiltes, manipulationsresistentes Register, das Transaktionen ohne zentrale Instanz festhält. Der Code ist technisch eine Wenn-dann-Regel: Er prüft Bedingungen und führt dann eine hinterlegte Aktion aus.

Dann trifft eine Transaktion ein, etwa die Meldung „Ware geliefert“. Ein Konsensverfahren, also die Regel, wie sich Teilnehmer auf den nächsten Block einigen, nimmt die Meldung auf. Der Contract wertet sie nach seiner programmierten Logik aus.

Danach führt die Regel die Aktion aus. Bei einer Escrow-Regelung, bei der Käufer und Verkäufer Zahlung und Ware hinterlegen, gibt der Contract die Zahlung erst frei, wenn die Lieferung gemeldet wurde. Das geschieht ohne Prüfung durch einen Menschen.

Zuletzt bleibt alles unveränderlich auf der Kette. Wird ein Block nachträglich verändert, ändert sich sein Hash, also sein digitaler Fingerabdruck, und die Verkettung bricht erkennbar auf. Eine rückgängig gemachte Ausführung wäre also eine sichtbare Manipulation.

Der Name „Contract“ täuscht: Es ist juristisch kein automatisch gültiger Vertrag, sondern exakt ausgeführter Code – samt Fehler. Deshalb gilt: Logik vorher durch Tests und Code-Prüfung absichern, denn die Ausführung lässt sich nicht zurücknehmen.

📌 Wenn-dann-Regel · Unveränderlichkeit · Prüfung vor Veröffentlichung

📚 Zukunftstechnologien verstehen · Tag 5 von 30
#Innovation #architektur #Cybersicherheit

Viele Einsteiger warten bei jeder kleinen Codeänderung erneut auf die komplette Paketinstallation. Dabei reicht eine andere Reihenfolge der Befehle, damit fast alles aus dem Cache kommt.

Nach dem Ändern einer einzigen Quellcodezeile läuft der komplette Build von vorn. Pakete werden wieder heruntergeladen, obwohl sie schon im vorherigen Build steckten.

Ein Dockerfile ist eine Schritt-für-Schritt-Anleitung, wie ein Image gebaut wird. Jeder Befehl erzeugt eine Schicht, also einen festen Layer im Image. Docker nutzt einen Build-Cache: Eine Schicht wird nur neu gebaut, wenn sich ihr Befehl oder die hineinkopierten Dateien geändert haben. Der Cache wird von oben nach unten geprüft – ab der ersten veränderten Schicht muss alles Folgende neu gebaut werden, auch wenn die Befehle gleich bleiben.

Ein typisches Dockerfile beginnt mit COPY des kompletten Quellcodes und installiert danach erst die Pakete mit RUN apt-get install. Jede noch so kleine Codeänderung trifft die erste Schicht und invalidiert alle folgenden. Die Paketinstallation läuft bei jedem Build erneut. Dreht man die Reihenfolge um – erst Pakete installieren, dann den Code kopieren – bleibt die teure Installation im Cache, wenn nur eine Codezeile geändert wird.

So prüft man es: Beim zweiten Build ohne Änderungen sollte Docker jeden Schritt aus dem Cache beantworten. Nach einer Codezeilen-Änderung dürfen nur die Schichten ab dem COPY neu laufen.

Erst das Seltene, dann das Häufige gehört ins Dockerfile. Häufig Geändertes gehört ans Ende des Dockerfiles, nicht an den Anfang.

📌 Build-Cache · Schichten · Befehlsreihenfolge

📚 Cloud von Grund auf · Tag 5 von 30
#docker #devops #CloudHosting

Viele zeichnen einen Prozess als Kastenreihe mit Pfeilen und halten ihn für fertig. Dabei zeigt ein solches Bild nicht, wer arbeitet und wo die Arbeit wartet.

Viele nehmen an, ein Ablaufdiagramm genüge, wenn alle Schritte und ihre Reihenfolge stimmen. Das klingt plausibel, weil Reihenfolge das Sichtbarste an einem Ablauf ist.

Tatsächlich liegt der Wert im Besitzerwechsel. Swimlanes, auf Deutsch Bahnen, gliedern ein Prozessdiagramm in waagerechte Streifen: eine Bahn pro Rolle wie Sachbearbeitung, Freigabe oder Buchhaltung, plus eine Bahn pro beteiligtem System wie E-Mail oder Buchungssystem. Jeder Schritt wird in die Bahn seines Ausführenden gesetzt, von links nach rechts in Ablaufrichtung. Eine Verbindung zwischen zwei Bahnen zeigt genau eine Übergabe – die Stelle, an der die Arbeit den Träger wechselt.

Der Irrtum entsteht, weil ein Diagramm ohne Bahnen ordentlich aussieht und schnell gezeichnet ist. Es verdeckt aber, welche Person zuständig ist und wo Arbeit liegen bleibt.

Ein Beispiel ist die Eingangsrechnung: Sie kommt per E-Mail-Anhang an, wird von einer Person geprüft, per Mail zur Freigabe weitergereicht und danach ins Buchungssystem übertragen. Das sind drei Übergaben, und jede einzelne kann die Rechnung aufhalten, etwa wenn das Postfach nur einmal täglich geleert wird.

Woran man es erkennt: Jede Pfeilspitze zwischen zwei Bahnen markiert einen Besitzerwechsel. Bewährt hat sich, an jeder dieser Stelle drei Fragen zu prüfen: Wer empfängt die Arbeit, in welchem Format erwartet er sie, und wer ist zuständig, wenn etwas unklar ist?

Swimlane heißt nicht hübsches Prozessbild, sondern Landkarte der Übergaben. Wer die Bahnen liest, findet die Wartezeiten, bevor ein Werkzeug sie beheben soll.

📌 Bahnen nach Rolle oder System · Übergaben als Wartepunkte · Pfeilspitzen zwischen Bahnen

📚 Automatisierung von Grund auf · Tag 5 von 30
#Prozessoptimierung #Automatisierung #workflow #Lean

Viele Teams wollen eine Blockchain, weil sie „manipulationssicher“ klingt. Dann wundern sie sich, warum Schreibvorgänge langsamer sind als in ihrer gewohnten Datenbank.

Das Register schreibt träger als geplant, und der Betrieb kostet mehr. Zudem fehlt eine zentrale Stelle, die bei Streit einfach entscheidet.

Eine Blockchain ist ein verteiltes, manipulationsresistentes Register: Transaktionen werden in verketteten Blöcken ohne zentrale Instanz festgehalten. Viele Teilnehmer halten identische Kopien vor, und die Mehrheit muss jede Änderung anerkennen. Ein Konsensverfahren legt fest, wie die Teilnehmer sich auf den nächsten Block einigen, etwa Proof of Work oder Proof of Stake. Genau diese Verteilung macht Schreiben langsamer, nicht schneller.

Jeder Block enthält einen Hash, also eine kryptografische Prüfsumme, des vorherigen Blocks. Ein Hash ist ein digitaler Fingerabdruck fester Länge, der sich bei kleinster Änderung komplett ändert. Wird ein früherer Block verändert, bricht die Verkettung zu allen Folgeblöcken erkennbar auf.

Mehrere Parteien ohne gegenseitiges Vertrauen führen so ein gemeinsames Register. Hyperledger Fabric ist ein solches geschlossenes Netz mit bekannten Teilnehmern, Zugriffskontrolle und ohne eigene Kryptowährung; die Konsensverfahren sind dort abstimmungsbasiert. Gibt es eine vertrauenswürdige Instanz oder nur eine schreibende Partei, ist eine klassische Datenbank mit Protokollierung einfacher, schneller und günstiger.

So prüft man es: Vor jedem Einsatz klären, wer schreibt, wer liest und warum keine zentrale Stelle gewünscht ist. Lässt sich das nicht begründen, fällt die Entscheidung auf eine Datenbank.

Eine Blockchain heißt nicht schnell, sondern gemeinsam geführt und kaum nachträglich änderbar. Ihre Stärke ist Manipulationssicherheit ohne zentrale Instanz.

📌 Blockchain · Hash · Konsens

📚 Zukunftstechnologien verstehen · Tag 5 von 30
#architektur #DigitaleTransformation

Die Rechnung ist längst bezahlt – nur gebucht ist sie nicht. Das Warten passiert fast nie während der Arbeit, sondern zwischen den Arbeiten.

Eine Übergabe ist jede Stelle, an der Arbeit den Träger wechselt: von Person zu Person, von System zu System oder von Person zu System. Sie tritt überall auf, etwa wenn eine Eingangsrechnung per E-Mail ankommt, zur Freigabe weitergereicht und danach ins Buchungssystem übertragen wird.

Zuerst landet die Rechnung als Anhang im Postfach. Dort wartet sie, bis jemand sie sichtet; wird das Postfach nur einmal täglich geleert, entsteht Wartezeit ohne jede Arbeit. Der Empfänger ruft die Arbeit schlicht nicht sofort ab.

Dann geht die Rechnung per Mail zur Freigabe an eine zweite Person. Hier entscheidet sich, ob sie liegen bleibt: Wer empfängt sie, in welchem Format erwartet er sie, und wer ist zuständig, wenn etwas unklar ist? Fehlt eine Antwort, wartet die Rechnung oder geht verloren.

Ein typischer Fehler ist das Format: Der Absender übergibt den Betrag als Text mit Komma, das System erwartet eine Zahl mit Punkt, und die Buchung bricht mit einer Fehlermeldung ab. Solche Ausnahmen gehören vorher gezählt und beschrieben.

Zuletzt lohnt der Blick auf das Ganze. Eine Prozessaufnahme in einem Swimlane-Diagramm, das Schritte den Rollen und Systemen zuordnet, zeigt jede Übergabe auf einen Blick. Vor jeder Änderung Durchlaufzeit und Fehlerquote messen.

Übergaben glätten heißt nicht, sie wegzulassen: Zuständigkeit benennen, das Format am Empfänger ausrichten (Mapping) und den Transport so wählen, dass der Empfänger sofort erfährt, dass etwas angekommen ist, etwa per Webhook, einer automatischen Benachrichtigung, statt Polling, dem wiederholten Abfragen. Übergaben sind keine Nebensache, sondern typisch der Ort, an dem Arbeit wartet.

📌 Übergaben · Wartezeit · Formatprüfung

📚 Automatisierung von Grund auf · Tag 5 von 30
#Prozessoptimierung #Automatisierung #Lean #workflow

Viele geben beiden Sonden denselben Endpunkt und glauben, gut gerüstet zu sein. Dabei verursacht genau das die Neustartschleifen, die eine Anwendung in den Ausfall treiben.

Viele denken, Kubernetes brauche eine einzige Gesundheitsprüfung, denn gesund ist gesund. Plausibel klingt das, weil beide Sonden denselben HTTP-Aufruf machen, etwa GET /healthz mit Antwortcode 200 bis 399 als Erfolg.

Tatsächlich stellen die Sonden zwei verschiedene Fragen. Die Liveness-Probe (Lebenssonde) prüft, ob der Container überhaupt noch funktionsfähig ist oder durch einen Neustart repariert werden kann. Die Readiness-Probe (Bereitschaftsonde) prüft, ob er gerade Verkehr annehmen darf. Schlägt Readiness fehl, nimmt der Kubelet – der Agent auf jedem Knoten, der Container startet und überwacht – den Pod (die kleinste Einheit in Kubernetes) aus den Endpoints des Service; der Container läuft weiter, es kommt nur kein Verkehr mehr an.

Der Irrtum entsteht, weil beide Prüfungen technisch identisch aussehen. Was fehlt, ist die Frage nach der Folge: Neustart oder Pause.

Eine Anwendung lädt beim Start große Datenmengen und antwortet noch nicht. Wer hier Liveness mit Readiness gleichschaltet, startet den Container neu, obwohl er nur Zeit bräuchte. Noch schlimmer: Eine Liveness-Probe, die die externe Datenbank mitprüft, löst bei deren Ausfall eine Neustartschleife aus, die nichts behebt. Abhängigkeiten gehören deshalb in die Readiness-Probe.

Woran man es erkennt: Mit den Standardwerten gilt ein Container nach drei aufeinanderfolgenden Fehlversuchen im Abstand von zehn Sekunden als nicht gesund. Wer Container im Kreis drehen sieht, obwohl sie nur langsam starten, hat Liveness zu scharf gestellt.

Liveness heißt nicht „alles prüfen, was wichtig ist“, sondern „nur prüfen, was ein Neustart reparieren kann“.

📌 Liveness vs. Readiness · Kubelet · failureThreshold 3

📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #sre

Projekt oder Prozess? Beide haben Schritte, ein Ziel und ein Ende – nur bei einem davon lohnt sich Automatisierung.

Verwechselt werden sie, weil beide als Kasten mit Pfeilen gezeichnet werden. Genau solche Diagramme sehen ordentlich aus, verraten aber nichts über Rollen, Übergaben zwischen Personen oder Systemen und Wartezeiten.

Ein Projekt ist einmalig: Ein Team plant, arbeitet und übergibt das Ergebnis, dann ist Schluss. Es läuft nie wieder nach denselben Regeln ab. Ein Bürogebäude einziehen ist ein Projekt. Deshalb lässt sich ein Projekt nicht sinnvoll automatisieren, es gibt keinen zweiten Durchlauf.

Ein Prozess ist eine wiederholte Folge von Tätigkeiten, die eine definierte Eingabe in ein definiertes Ergebnis überführt. Er läuft nach denselben Regeln immer wieder ab. An einer Eingangsrechnung sieht man die drei Bausteine: Eingabe ist der PDF-Anhang per E-Mail, die Schritte sind Prüfung, Freigabe und Buchung, das Ergebnis ist die gebuchte Rechnung im System.

Der entscheidende Unterschied liegt in der Wiederholung. Die ISO 9001 beschreibt den prozessorientierten Ansatz: Prozesse mit Eingaben, Ausgaben, Verantwortlichen und Kennzahlen definieren und nach dem PDCA-Zyklus (Plan, Do, Check, Act) verbessern. Eine Automation, die nur den Normalfall kennt, erzeugt bei jedem Sonderfall manuelle Nacharbeit.

Faustregel: Prozesse aufnehmen, bevor automatisiert wird – mit Rollen, Übergaben und Kennzahlen wie Durchlaufzeit und Fehlerquote. Ein Schritt eignet sich zur Automatisierung, wenn er nach festen Regeln wiederholbar ist, ohne menschliche Entscheidung.

Ein Prozess heißt nicht „irgendwo passiert etwas“, sondern wiederholte Schritte von einer definierten Eingabe zu einem definierten Ergebnis.

📌 Eingabe · Schritte mit Übergaben · Ergebnis

📚 Automatisierung von Grund auf · Tag 4 von 30
#Automatisierung #Prozessoptimierung #workflow #Lean

Ein Deployment funktioniert wie ein Vorarbeiter, der eine Personalplanung im Kopf hat. Er weiß, wie viele Leute arbeiten sollen, und meldet sofort, wenn jemand fehlt.

Der Vorarbeiter hat einen Plan: Drei Arbeiter an einer Station. Kommt einer nicht, schickt er einen Ersatz. Der Ersatz übernimmt dieselbe Aufgabe, ohne dass jemand nachfragen muss. Der Vorarbeiter prüft dabei nicht die Stimmung oder die Leistung. Er zählt nur: Sind noch drei da? Solange die Zahl stimmt, greift er nicht ein.

In Kubernetes ist der Vorarbeiter das Deployment, eine Verwaltungseinheit für gleichartige Pods. Der Pod ist die kleinste betreibbare Einheit und umhüllt einen oder mehrere Container, also Anwendungen samt Abhängigkeiten. Der Plan steckt im Feld replicas: Dort steht die Soll-Stärke, etwa die Zahl drei. Fällt ein Pod aus, startet das Deployment automatisch einen neuen. Kubernetes verteilt die Pods dabei auf die Knoten, die Arbeitsrechner des Clusters.

Ein Deployment für eine Webanwendung mit replicas: 3 erzeugt drei gleiche Pods. Stürzt einer ab, läuft die Zahl ohne Eingriff auf drei zurück. Die Container eines Pods teilen sich eine IP-Adresse und reden über localhost miteinander.

Das Bild hat eine Grenze: Ein Arbeiter bleibt derselbe Mensch, ein ersetzter Pod ist eine neue Instanz mit neuer IP-Adresse. Der Vorarbeiter delegiert auch aktiv, das Deployment vergleicht nur Ist und Soll. Stabile Adressen für Anfragen liefert deshalb ein Kubernetes-Service.

Pods also nie von Hand starten: Wer replicas selbst überwacht, ersetzt keine ausgefallenen Pods. Deployment heißt nicht Pod, sondern Soll-Stärke, die Kubernetes von selbst hält.

📌 Pod · Deployment · replicas

📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #docker

Heute schützen RSA und elliptische Kurven die Verbindungen im Netz. Morgen könnten Quantenrechner genau diese Schutzmechanismen aushebeln.

Beide Begriffe beschreiben asymmetrische Kryptografie, also Verfahren mit einem öffentlichen und einem privaten Schlüssel. Die Verwechslung entsteht, weil beide dieselben Aufgaben lösen: Schlüsselaustausch und digitale Signaturen.

RSA beruht auf der Schwierigkeit, große Zahlen in ihre Primfaktoren zu zerlegen. Klassische Rechner brauchen dafür praktisch untragbar lange, daher gilt RSA als sicher.

Post-Quanten-Kryptografie umfasst Verfahren, die auf mathematischen Problemen beruhen, für die keine effiziente Lösung bekannt ist – auch nicht für Quantencomputer. Statt Primfaktoren setzt sie auf andere Strukturen, etwa Gitter, bei denen Quantenrechner keine bekannte Abkürzung haben. Im August 2024 veröffentlichte das US-Normungsinstitut NIST die ersten drei Standards: FIPS 203 standardisiert ML-KEM für den Schlüsselaustausch, FIPS 204 ML-DSA für Signaturen.

Der entscheidende Unterschied liegt in der Bedrohungsannahme. Heutige Verfahren werden durch einen ausreichend großen Quantencomputer mit Shors Algorithmus gebrochen; hinzu kommt „Harvest now, decrypt later“: heute aufgezeichneter Datenverkehr wird später entschlüsselt.

Faustregel: Wer langlebige Geheimnisse schützt, zum Beispiel Patientendaten einer Klinik, plant den Umstieg jetzt, nicht erst mit dem Quantenrechner. Der erste Schritt ist Krypto-Agilität: ein Inventar aller Verfahren, Schlüssel und Zertifikate, damit der Austausch ohne Neubau von Anwendungen gelingt.

Post-Quanten-Kryptografie heißt also nicht mehr Verschlüsselung, sondern verschärfte Mathematik gegen eine Maschine, die es noch nicht gibt.

📌 Gitter statt Primfaktoren · Harvest now, decrypt later · Krypto-Agilität

📚 Zukunftstechnologien verstehen · Tag 4 von 30
#Quantencomputing #postquantum #Cybersicherheit

Die meisten Docker-Neulinge wundern sich, warum jeder Build Minuten dauert. Dabei entscheidet oft weniger die Größe des Projekts über die Bauzeit, sondern die Reihenfolge der Zeilen im Dockerfile.

Ein Dockerfile ist eine Textdatei mit Anweisungen wie FROM, COPY und RUN, aus denen docker build ein Image erzeugt – eine portable, gepackte Umgebung für eine Anwendung. Wer die Schichten versteht, baut deutlich schneller.

📦 Jede Dockerfile-Anweisung erzeugt ihre eigene Schicht.
Eine Schicht (Layer) ist das Dateisystem-Änderungsprotokoll genau einer Anweisung; das fertige Image entsteht als Stapel dieser Schichten übereinander. Die Anweisungen werden von oben nach unten abgearbeitet. Beispiel: erst FROM, dann COPY der Paketliste, dann RUN zur Installation der Abhängigkeiten, erst danach COPY des Quellcodes.

🔑 Der Build-Cache prüft jede Anweisung von oben nach unten.
Der Build-Cache ist ein Zwischenspeicher früherer Schichten; Docker vergleicht Anweisung und Eingaben mit der gecachten Version. Ist eine Schicht unverändert, wird sie samt aller darunterliegenden wiederverwendet. Ab der ersten geänderten Anweisung wird alles Folgende neu gebaut.

📈 Häufig Geändertes gehört ans Ende des Dockerfiles.
Klassischer Einsteigerirrtum: Quellcode früh per COPY übernehmen. Dann läuft bei jeder Codeänderung auch die teure Abhängigkeitsinstallation erneut, obwohl sich nichts daran geändert hat. Steht die COPY-Zeile für den Code dagegen ganz unten, bleibt der Cache für die Installation intakt.

Die Reihenfolge heißt nicht Geschmackssache, sondern Cache-Strategie: selten Geändertes zuerst, häufig Geändertes zuletzt – Basis-Image und Abhängigkeiten vor dem eigenen Quellcode.

📌 Schichten · Build-Cache · Anweisungsreihenfolge

📚 Cloud von Grund auf · Tag 4 von 30
#docker #devops #CloudHosting

Die meisten denken, ein Sprachmodell verstehe Wörter nacheinander, wie ein Mensch beim Lesen. Dabei sieht es in Self-Attention alle Wörter eines Satzes gleichzeitig und entscheidet bei jedem, welche anderen ihm gerade wichtig sind.

Deshalb zählt sie: Self-Attention ist der Kernbaustein des Transformer, des Modellaufbaus hinter heutigen Sprachmodellen. Wer sie versteht, versteht, warum Modelle Bezüge über ganze Sätze hinweg herstellen können.

🧠 Jedes Token fragt alle anderen um Gewicht. Ein Token ist je nach Tokenizer ein Wort, ein Wortteil oder ein Zeichen. Bei der Verarbeitung rechnet jedes Token aus, wie stark es jedes andere Token seiner Umgebung berücksichtigen soll. Das Ergebnis ist eine Zahl zwischen 0 und 1, und alle Gewichte ergeben zusammen 1.

📊 Hohe Gewichte fließen stärker ein als niedrige. Ein Token mit hohem Gewicht geht stärker in die weitere Verarbeitung des betrachteten Tokens ein als eines mit niedrigem. Im Satz „Anna erzählt Lena, weil sie gut zuhört“ muss „sie“ stark auf „Lena“ achten und nicht auf „Anna“ – der Satzbau entscheidet mit, nicht allein die Wortähnlichkeit.

🔍 Attention reicht bis an den Rand des Kontextfensters. Das Kontextfenster ist die maximale Anzahl Tokens, die ein Modell in einem Durchgang berücksichtigen kann. Innerhalb dessen verbindet Attention auch weit auseinanderliegende Wörter direkt. Der Preis: Der Rechenaufwand wächst quadratisch mit der Sequenzlänge.

Self-Attention heißt nicht Bedeutungsähnlichkeit messen, sondern ausrechnen, welche Tokens für die Verarbeitung eines Tokens im gegebenen Kontext nützlich sind. Wer das verwechselt, übersieht die Rolle von Stellung und Satzbau.

📌 Self-Attention · Gewichte · Kontextfenster

📚 KI von Grund auf · Tag 4 von 30
#machinelearning #llm #Transformers #ki

Viele halten den Quantencomputer für einen Turbo-PC. Dabei rechnet er alltägliche Aufgaben nicht schneller, sondern nur wenige, ganz bestimmte Problemtypen.

Nach den ersten Experimenten fällt auf, dass einfache Rechenaufgaben auf einem Quantenrechner nicht schneller laufen. Ergebnisse sind statistisch und brauchen viele Wiederholungen, sogenannte Shots, um verlässlich zu werden.

Ein Quantencomputer arbeitet nicht mit klassischen Bits, sondern mit Qubits, deren Überlagerung (Superposition) erst bei der Messung zu einem konkreten Wert kollabiert. Der Nutzen liegt nicht darin, alle Lösungen parallel auszuprobieren, sondern darin, dass Interferenz die Wahrscheinlichkeit der richtigen Antwort verstärkt und falsche unterdrückt. Das muss der Algorithmus gezielt ausnutzen – sonst misst man nur zufällige Einzelwerte.

Shors Algorithmus faktorisiert große Zahlen und löst diskrete Logarithmen (eine weitere mathematische Kernoperation heutiger Verschlüsselung) effizient, aber nur auf einem ausreichend großen, fehlerkorrigierten Quantenrechner – das bedroht RSA und elliptische Kurven. Grovers Algorithmus beschleunigt unstrukturierte Suche quadratisch; bei AES entspricht das grob einer Halbierung der effektiven Schlüssellänge, weshalb längere Schlüssel empfohlen werden. Heutige Geräte sind NISQ-Systeme (Noisy Intermediate-Scale Quantum, von Preskill 2018 geprägt): Dekohärenz (der Verlust der Qubit-Eigenschaften durch Störung) und Gatterfehler begrenzen die zuverlässige Operationszahl.

So prüft man es: Man fragt, ob für das konkrete Problem ein nachweisbarer Quantenvorteil existiert. Ohne einen solchen Nachweis bleibt die Aufgabe auf klassischer Hardware besser aufgehoben.

Ein Quantencomputer ist kein schnellerer Allzweckrechner, sondern ein Beschleuniger für umrissene Problemklassen.

📌 Quantenvorteil · Shor & Grover · NISQ-Grenzen

📚 Zukunftstechnologien verstehen · Tag 4 von 30
#Quantencomputing #postquantum #strategie

Halluzinationen sind kein Bug, sondern eine Eigenschaft von Sprachmodellen. Ein flüssiger Satz ist deshalb noch lange kein wahrer Satz.

Einsteiger begegnen Halluzinationen überall dort, wo ein Sprachmodell Fakten liefern soll: eine Jahreszahl, ein Zitat, ein Name. Wer den Begriff nicht kennt, vertraut der glatten Formulierung und gibt Fehler weiter.

Sie entsteht, weil das Modell keine geprüften Fakten abfragt, sondern Text als Wahrscheinlichkeitsfortsetzung erzeugt. Ein Token ist je nach Tokenizer, dem Programm, das Text in Tokens zerlegt, ein Wort, ein Wortteil oder ein Zeichen. Das Modell plant keinen Satz und kennt kein Ziel am Ende: Es sieht nur die bisher vorhandenen Tokens und wählt ein wahrscheinliches Folge-Token aus.

Ein Beispiel: Das Modell soll ein Zitat einer berühmten Person belegen. Es erzeugt klingende Worte, die die Person so nie gesagt hat, und nennt dazu Fundort und Jahr. Alles wirkt korrekt, nichts ist geprüft. Das Verfahren liefert bei dieser Ausgabe genau das, wofür es gebaut ist.

Verwechselt wird das mit einem technischen Fehler, den ein Update behebt. Im Unterschied dazu funktioniert die Wahrscheinlichkeitsfortsetzung auch einwandfrei, nur eben ohne Wahrheitsfilter. Auch eine höhere Temperatur hilft nicht: Sie erhöht nur die Streuung und kann falsche Ausgaben häufiger machen.

Wer mit Quellen arbeitet, kann die Kontrolle verbessern. Beim Retrieval werden Dokumente mitgeliefert, denen die Antwort entnommen wird. Der Text außerhalb der Belege bleibt auch dann Wahrscheinlichkeitsfortsetzung. Praxisregel: Fundstelle und Datum selbst prüfen, bevor eine Aussage weitergegeben wird.

Halluzination heißt nicht, dass das Modell kaputt ist, sondern dass es plausible statt geprüfte Aussagen liefert.

📌 Wahrscheinlichkeitsfortsetzung statt Faktenabfrage · Flüssigkeit ist kein Wahrheitsbeweis · Fundstelle selbst prüfen

📚 KI von Grund auf · Tag 4 von 30
#llm #machinelearning #ki

Zwei Sensoren im selben Raum, und keiner zeigt denselben Wert. Beide Displays zeigen einen Wert mit Dezimalstelle, und die Differenz wächst statt zu schrumpfen.

Das Symptom kennen viele beim ersten Vergleich. Der DHT22 liefert feine Werte, wirkt aber trotzdem unzuverlässig, und schnell gilt ein Sensor als kaputt. Meist sind beide in Ordnung, und die Differenz hat eine saubere Erklärung.

Dahinter stehen zwei Angaben, die das Datenblatt getrennt nennt. Auflösung ist der kleinste Schritt, den ein Sensor überhaupt ausgeben kann. Genauigkeit ist die maximal zulässige Abweichung vom wahren Wert, die der Hersteller zusichert; sie gilt meist nur in einem begrenzten Messbereich. Ein Wert mit zwei Nachkommastellen kann trotzdem um mehrere Grad danebenliegen.

Der DHT22 ist mit etwa 0,5 °C Temperaturgenauigkeit und 2 bis 5 % relativer Luftfeuchte (rF) spezifiziert, der DHT11 dagegen mit etwa 2 °C und 5 % rF; er misst nur ganze Grad und Prozent. Zwei Geräte dürfen also ruhig auseinanderliegen, ohne defekt zu sein. Dazu misst jeder nur die Luft unmittelbar an seinem Gehäuse; Wärme von Spannungsregler und Funkmodul macht einen Sensor direkt daneben zu warm.

So prüft man es: Erst beide Datenblätter auf Genauigkeit, Messbereich und Wiederholgenauigkeit vergleichen. Dann den Sensor neben ein als genauer bekanntes Referenzgerät legen und beide Werte über einige Stunden vergleichen.

Genauigkeit heißt nicht, wie fein der Sensor zählt, sondern wie nah er am wahren Wert bleibt. Die Nachkommastellen der Anzeige sagen darüber nichts aus.

📌 Auflösung vs. Genauigkeit · Datenblatt lesen · Referenzvergleich

📚 IoT von Grund auf · Tag 4 von 30
#iot #sensorik #Mikrocontroller #embedded

Die meisten Anfänger tippen los und wundern sich über langsame Builds. Dabei ist ein Dockerfile ein Rezept mit fester Anweisungsreihenfolge.

Ein Dockerfile beschreibt Schritt für Schritt, wie ein Container-Image entsteht. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden.

Zuerst steht die FROM-Anweisung: Sie legt ein Basis-Image fest, etwa eine schlanke Linux-Distribution mit Python. Jede Anweisung erzeugt dabei eine Schicht, und die Reihenfolge entscheidet über den Build-Cache. Selten geänderte Schritte wie Abhängigkeiten gehören deshalb vor häufig geänderten wie dem Quellcode.

Dann folgt COPY. Es kopiert Dateien aus dem Build-Kontext in das Image, also aus dem Verzeichnis, das dem Build mitgegeben wird. Ein häufiger Irrtum: Dateien außerhalb dieses Kontexts sind schlicht nicht verfügbar. Bewährt hat sich, zuerst nur die Datei mit den Abhängigkeiten zu kopieren und zu installieren, dann erst den Quellcode.

Danach kommen RUN für Installationsbefehle sowie USER. Ohne USER läuft der Prozess im Container als root, also mit vollen Rechten. Die Anweisung USER setzt einen unprivilegierten Benutzer und senkt das Risiko, falls der Container kompromittiert wird.

Zuletzt legen CMD den Startbefehl und EXPOSE den Port fest. EXPOSE dokumentiert nur, welchen Port die Anwendung im Container erreicht; geöffnet wird er erst beim Start mit docker run. Der Befehl docker build arbeitet das Dockerfile ab und erzeugt das Image, versehen mit einem Tag wie 1.2. Solche Tags sind beweglich; ein Digest wie sha256:… identifiziert dagegen genau einen Inhalt.

Ein Dockerfile ist also kein Skript, sondern ein Rezept: Jede Anweisung baut eine Schicht, und deren Reihenfolge bestimmt Tempo und Sicherheit des Images.

📌 Schichten und Build-Cache · COPY und Build-Kontext · USER statt root

📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #CloudSecurity

Viele drehen die Temperatur hoch, weil sie ein kreativeres Modell erwarten. Tatsächlich wird das Modell dadurch nicht klüger – nur seine Auswahl zufälliger.

Viele Einsteiger glauben, eine Temperatur über 0 schalte kreatives Denken frei. Das klingt plausibel, weil höhere Werte oft abwechslungsreichere Antworten liefern.

Tatsächlich berechnet ein Sprachmodell für jedes nächste Token – ein Wort, Wortteil oder Zeichen – eine Wahrscheinlichkeitsverteilung über sein gesamtes Vokabular. Die Temperatur skaliert nur diese Verteilung: Werte unter 1 machen wahrscheinliche Tokens noch wahrscheinlicher, Werte über 1 flachen sie ab. Bei Temperatur 0 wird stets das wahrscheinlichste Token gewählt, die gierige Wahl. Der Regler verändert weder das Modell noch seine Berechnung, sondern nur den Zufall bei der Auswahl.

Der Irrtum entsteht, weil Abwechslung wie Klugheit aussieht. Eine flachere Verteilung erlaubt seltenen, unerwarteten Tokens mehr Chancen – das wirkt kreativ, bleibt aber reiner Zufall aus derselben Rechnung.

Nach dem Satzanfang „Die Sonne scheint am“ vergibt das Modell hohe Wahrscheinlichkeiten an Tokens wie „Himmel“ oder „Morgen“ und sehr niedrige an „Kartoffel“. Bei Temperatur 0 und gleicher Eingabe kann dieselbe Fortsetzung immer wieder erscheinen. Erhöht man die Temperatur, rückt „Kartoffel“ näher heran – mitunter überraschend, aber selten korrekt.

Woran man es erkennt: Wenn bei einer Frage mehrfach unterschiedliche Antworten auftauchen, wirkt der Zufall mit, nicht mehr Verstand. Faustregel: niedrige Temperatur für Zusammenfassen, Übersetzen oder Code, höhere für Ideen und Brainstorming.

Temperatur heißt nicht mehr Intelligenz, sondern mehr Streuung bei der Auswahl. Höhere Werte erhöhen nicht die Richtigkeit – Halluzinationen können sogar häufiger auftreten.

📌 Wahrscheinlichkeitsverteilung · Temperatur · Sampling

📚 KI von Grund auf · Tag 3 von 30
#llm #machinelearning #ki

Der DHT22 und der BME280 stehen in fast jedem Einsteigerkit fürs IoT. Dabei messen sie nicht dasselbe – und nicht gleich genau.

Beide heißen umgangssprachlich „Klimasensor“, weil sie Temperatur und relative Luftfeuchte liefern. Relative Luftfeuchte (rF) vergleicht den Wasserdampf in der Luft mit der maximal möglichen Menge bei derselben Temperatur; warme Luft nimmt mehr auf als kalte.

Der DHT22 (auch AM2302 genannt) ist ein günstiges Kombibauteil für Temperatur und Feuchte. Er schickt seine Werte über eine einzige Datenleitung an den Mikrocontroller und darf höchstens alle 2 Sekunden einen Wert liefern. Laut Spezifikation erreicht er etwa 0,5 °C und 2 bis 5 % rF; ein ESP32 liest ihn per Bibliothek aus und erhält zwei Werte pro Messung.

Der BME280 von Bosch misst zusätzlich den Luftdruck, also das Gewicht der Luftsäule über dem Sensor. Er hängt an einem Bus wie I2C, bei dem mehrere Geräte zwei gemeinsame Leitungen teilen und über Adressen (0x76 oder 0x77) unterschieden werden. Seine Genauigkeit liegt bei etwa 1 °C, 3 % rF und 1 hPa.

Der BME280 liefert drei physikalische Größen und spricht flexible Busse. Der DHT22 liefert zwei Größen über seine eine Datenleitung und ist träger, dafür einfacher anzubinden.

Zwei Sensoren im selben Raum zeigen oft verschiedene Werte, weil jeder nur die Luft an seinem Gehäuse misst; Zugluft, Heizung oder Außenwand verfälschen zusätzlich. Spannungsregler, Funkmodul und Prozessor erwärmen die Platine; ein Temperatursensor gehört deshalb mit Abstand an einen kühleren Ort oder auf ein eigenes Modul.

Faustregel: Für Feuchte und Druck ist der BME280 erste Wahl; wer nur Temperatur und Feuchte nebenbei braucht, nimmt den DHT22.

Die Nachkommastellen der Anzeige sind keine Genauigkeit, sondern Auflösung – wie fein der Sensor zählt, nicht wie exakt er misst.

📌 DHT22 · BME280 · Luftfeuchte

📚 IoT von Grund auf · Tag 3 von 30
#iot #sensorik #embedded

Eine Anwendung läuft dreifach ausfallsicher – und eine Stromversorgung legt sie komplett still. Solche Stellen heißen Single Points of Failure, und fast jede Architektur hat mindestens einen.

Wer nicht systematisch danach sucht, merkt den Ausfall erst, wenn Nutzer eine Fehlerseite sehen. Betroffen ist jede Cloud-Anwendung, die ohne Ausfallschutz betrieben wird.

Ein Single Point of Failure ist eine Komponente, deren Ausfall das ganze System stoppt. Hochverfügbarkeit entsteht, indem genau solche Komponenten mehrfach vorhanden sind. Erst wenn eine zweite Instanz die Arbeit übernehmen kann, ist der Ausfall abgefangen.

Man geht den Weg einer Anfrage von vorne nach hinten durch – DNS (übersetzt Domainnamen in IP-Adressen), Load Balancer (ein Verkehrsverteiler vor den Servern), Anwendungsserver, Datenbank, Speicher. Eine Anwendung, die nur in einer einzigen Availability Zone (einem Rechenzentrumverbund mit eigener Stromversorgung und Netzanbindung) läuft, hat daher einen Single Point of Failure: Fällt diese Zone aus, ist die Anwendung weg. Der Ausfallschutz entsteht erst durch das Betreiben in mindestens zwei Zonen. Auch vorne droht eine Falle: Ein Load Balancer, der alleinstehend vor der Anwendung sitzt, ist selbst ein Single Point of Failure. In Kubernetes fängt ein Deployment mit mehreren Pods (kleinste Einheit in Kubernetes mit einem oder mehreren Containern) den Ausfall einzelner Pods ab; ein Service gibt ihnen eine stabile Adresse und verteilt Anfragen, auch wenn Pods neu starten.

Verwechselt wird der Single Point of Failure oft mit Redundanz an nur einer Stelle. Die nützt nichts, wenn dahinter alles über genau eine Instanz läuft.

Ein Single Point of Failure ist also nicht „ein kaputtes Teil“, sondern die einzige Instanz, an der alles hängt.

📌 Anfrage-Weg abgehen · einzige Instanz prüfen · zweite Zone einplanen

📚 Cloud von Grund auf · Tag 3 von 30
#aws #sre

Ein Server fällt aus, und die Anwendung läuft einfach weiter. Viele Einsteiger halten das für Zufall oder Glück – dahinter steckt ein Baustein, der ständig mitprüft.

Viele denken, ein Load Balancer verteile Anfragen einfach stur reihum auf mehrere Server. Das klingt plausibel, weil Verteilen ja der Name des Bausteins ist. Wenn aber ein Server kaputt ist, landen weiter Anfragen bei ihm – und die Nutzer sehen Fehler.

Tatsächlich verteilt ein Load Balancer nur an Server, die gesund sind. Gesundheitsprüfungen (Health Checks) sind regelmäßige automatische Anfragen, etwa alle paar Sekunden an einen Prüfpfad wie /health. Erst nach mehreren erfolgreichen Prüfungen gilt ein Server als gesund. Ein Server, dessen Prüfungen fehlschlagen, wird automatisch aus der Verteilung genommen.

Der Irrtum entsteht, weil das Verteilen sichtbar ist, das Prüfen nicht. Von außen sieht man nur einen einzigen Ansprechpunkt, der Anfragen weiterreicht.

Ein Beispiel: Drei Server hinter einem Load Balancer, Verteilung per Round Robin – die Anfragen wandern reihum, jeder Server erhält etwa gleich viele. Ein Server antwortet auf /health nicht mehr; nach mehreren Fehlversuchen fliegt er aus der Verteilung. Die Nutzer merken nichts, solange mindestens ein gesunder Server bleibt.

Woran man es erkennt: Der Load Balancer leitet Verkehr nur an gesunde Instanzen weiter. Health-Check-Pfad und Schwellen müssen dabei zum Dienst passen, sonst gelten kaputte Server zu spät als krank.

Ein Load Balancer heißt nicht „Anfragenverteiler nach festem Schema“, sondern „Verteiler mit Gesundheitsprüfung“. Er entscheidet bei jeder Anfrage neu, wer sie bekommen darf.

📌 Load Balancer · Health Checks · Round Robin

📚 Cloud von Grund auf · Tag 3 von 30
#CloudHosting #devops #sre

Eine neue Regel in der Security Group setzen, und trotzdem kommt kein Traffic durch. Meistens fehlt nicht die Regel, sondern sie zeigt auf die falsche Quelle.

Eine Security Group ist eine Firewall, die direkt an der Netzwerkschnittstelle einer Instanz hängt und jeden ein- und ausgehenden Datenverkehr prüft. Sie entscheidet in der Cloud, ob ein Server überhaupt erreichbar ist.

Zuerst denkt man an die Quelle einer Regel, also an die Frage, wer sich verbinden darf. Dort muss keine einzelne IP-Adresse stehen: Wenn die Anwendungsschicht eine eigene Security Group hat, kann genau diese Gruppe als Quelle eingetragen werden. So erhalten nur diese Instanzen Zugriff auf die Datenbank.

Dann wird die Richtung festgelegt. Regeln sind nur Erlaubnisse, nie Verbote. Wer HTTPS von überall erlaubt, lässt genau dieses herein; alles andere bleibt draußen. Die Gruppe gilt je Netzwerkschnittstelle, und Instanzen können mehrere Gruppen haben, deren Regeln sich addieren.

Danach folgt der Punkt, der Einsteiger verwirrt: Security Groups sind zustandsbehaftet. Ruft der Server eine Außenstelle auf, wird die Antwort automatisch eingelassen. Eine zusätzliche Regel für die Rückrichtung ist unnötig und ein häufiger Irrtum.

Zuletzt die Grenze: Öffentlich heißt nicht ungefiltert. Auch in einem öffentlichen Subnetz entscheidet die Security Group, was durchgeht. Eine Adresse gezielt blocken kann sie nicht; dafür braucht es die zustandslose Network ACL auf Subnetzebene.

Security Groups sperren niemanden aus, sondern lassen gewolltes herein. Die Antwort auf eine erlaubte Anfrage läuft immer mit.

📌 Zustandsbehaftet · Nur Erlaubnisregeln · Quelle kann Gruppe sein

📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops

Viele vergeben Administratorrechte, weil es schnell geht. Dabei macht genau das einen Angriff zum Totalausfall.

Viele Einsteiger denken: Volle Rechte sparen Nachfragen und Fehlermeldungen. Wer alles darf, muss nie darauf warten, dass jemand ein fehlendes Recht nachreicht – das klingt vernünftig.

Tatsächlich gilt das Gegenteil. Das Prinzip der geringsten Rechte (Least Privilege) besagt: Jedes Benutzerkonto, jeder Dienst und jede Programmierschnittstelle (API, also eine definierte Stelle, über die Software Daten austauscht) erhält nur die Rechte, die seine Aufgabe erfordert. Wird ein Konto kompromittiert (also von Angreifern übernommen), kann der Angreifer nur das tun, was das Konto darf. Der Schaden bleibt auf diese Rechte begrenzt.

Der Irrtum entsteht, weil Bequemlichkeit sofort spürbar ist, der Schadensfall nicht. Einmal großzügig vergebene Rechte verschwinden außerdem selten von selbst.

Als Beispiel dient ein Skript, das jede Nacht eine Datensicherung kopieren soll. Es braucht nur Leserechte auf den Quellordner und Schreibrechte auf das Backup-Ziel. Die Administratorenrolle des ganzen Systems ist dafür nicht nötig – sie verwandelt einen kleinen Fehlgriff in eine Katastrophe.

Woran man es erkennt: Rechtevergabe ist kein einmaliger Vorgang, sondern wird regelmäßig geprüft. Jede Rolle muss sich durch eine konkrete, beschriebene Aufgabe begründen lassen; Rechte ohne Begründung werden weggenommen.

Least Privilege heißt nicht, Angriffe zu verhindern. Es heißt, die Schadenshöhe im Ernstfall zu begrenzen – und damit das Risiko zu senken, bevor etwas passiert.

📌 Zugriffsrechte · Rollen · Schadensbegrenzung

📚 Zukunftstechnologien verstehen · Tag 2 von 30
#zerotrust #Cybersicherheit #architektur

Die meisten Anfänger denken, ein Bucket sei ein Ordner wie auf dem Desktop. Dabei ist er der zentrale Sicherheitspunkt des gesamten Cloud-Speichers.

Ein offen stehender Bucket gibt Daten an das ganze Internet frei. Ein einziger falsch gesetzter Haken genügt dafür.

📦 Ein Bucket ist der oberste Speichercontainer in einem Objektspeicher, nicht ein Laufwerk. Objektspeicher wie S3 legt Daten als Objekte mit Schlüssel und Metadaten, also beschreibenden Angaben zum Objekt, ab, nicht als Dateien auf einem Datenträger. Jeder Bucket hat einen weltweit einmaligen Namen und enthält beliebig viele Objekte.

🔑 Jedes Objekt liegt unter einem Schlüssel, der wie ein Dateipfad aufgebaut ist. Ein Beispiel ist „backup/2026/db.sql“. Der Schlüssel adressiert das Objekt eindeutig, ganz ohne Ordnerstruktur. Zugriffsrechte steuert man nicht über Betriebssystemrechte, sondern über Richtlinien, die den Zugriff pro Bucket und Objekt erlauben oder verweigern.

📈 Block Public Access gehört auf jeden Bucket, vom ersten Tag an. Diese Schutzebene sperrt alle vier Arten öffentlichen Zugriffs und überstimmt öffentliche Bucket-Policies und ACLs. Seit April 2023 ist sie für neue Buckets standardmäßig aktiviert; ACLs, ältere Zugriffslisten, sind dabei sogar deaktiviert. Ein öffentlicher Bucket erlaubt jedem Internetnutzer, Objekte aufzulisten oder herunterzuladen. Wer Dateien wirklich verteilen will, nutzt dafür gezielter einen CDN-Dienst, ein Content-Delivery-Netzwerk für Dateien aus Rechenzentren nahe beim Nutzer, oder vorsignierte URLs.

Ein Bucket heißt nicht „öffentlicher Ordner“, sondern ein weltweit einmaliger Speichercontainer, den man standardmäßig verschlossen hält.

📌 Bucket · Objektspeicher · Block Public Access

📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudSecurity #Backup

Ein toter Link im Browser – meist zeigt er „404 Not Found“. Dabei sagt diese Zahl weniger, als man denkt.

Jede Serverantwort im Web beginnt mit einem Statuscode, einer dreistelligen Nummer. Sie tritt überall auf: beim Aufruf einer Seite, beim Bookmark im Browser, beim Newsletter-Feed. Die erste Ziffer gibt die Klasse an, hier 4 für einen Fehler des Clients.

Zuerst sendet der Client eine Anfrage an eine URL, also eine Adresse im Web. Der Server sucht die angeforderte Ressource – eine Seite, ein Bild, einen Datensatz. Findet er sie nicht, antwortet er mit 404 Not Found.

Dann entscheidet der Client, was das bedeutet. Die erste Ziffer der Nummer nennt nur die Richtung: Bei 4xx liegt der Fehler meist in der eigenen Anfrage, etwa in einer falschen URL oder fehlender Berechtigung. Der Haken bei 404: Die Nummer sagt nichts über die Zukunft. Die Adresse kann nie existiert haben, vertippt sein oder erst morgen wieder erreichbar sein. Für den Client ist eine Löschung ununterscheidbar von einem Tippfehler in der URL.

Danach gibt es für den Fall der bewussten Löschung eine klarere Antwort: 410 Gone. Sie bedeutet, die Ressource existierte einst, wurde aber absichtlich und dauerhaft entfernt. Der Server weiß das und teilt es ausdrücklich mit.

Zuletzt kann der Client auf 410 höflicher reagieren: Ein Feed-Leser darf den Link als endgültig tot markieren und seine Wiederholungen einstellen. Bei 404 bleibt dagegen nur: immer wieder probieren. Praxisregel für eigene Backends: Nach dem Löschen einer Ressource 410 senden; 404 bleibt für unbekannte oder nie existierte Adressen.

404 heißt also nicht „gelöscht“, sondern „gerade nicht gefunden“ – erst 410 spricht von dauerhaft weg.

📌 Statuscode · 404 Not Found · 410 Gone

📚 Webentwicklung von Grund auf · Tag 2 von 30
#webdev #HTTP #backend