Einblicke in Planung, Produktivität und den Aufbau von Open-Source-Software

Sicherheitstests haben nicht Schritt gehalten mit der Art und Weise, wie Software entwickelt oder angegriffen wird. Während sich Entwicklungszyklen beschleunigt haben und KI-gestützte Angreifer Systeme kontinuierlich prüfen können, stützen sich die meisten Sicherheitspraktiken weiterhin auf periodische Bewertungen und langsame Behebung. Das Ergebnis ist eine immer größer werdende Lücke zwischen dem Zeitpunkt, an dem Schwachstellen eingeführt werden, und dem Zeitpunkt, an dem sie entdeckt oder behoben werden. In unserer jüngsten Analyse autonomer, KI-gesteuerter Pentests über Produktionssysteme hinweg wird diese Lücke unmöglich zu ignorieren: Moderne Anwendungen sind nicht nur verwundbar, sie sind kontinuierlich verwundbar.

Gastbeitrag von Huzaifa Ahmad, Gründer, Hex Security

On June 22, 2026, our primary asynchronous task and queue management partner, Trigger.dev, suffered a catastrophic, multi-region cascading failure. Because our core platform infrastructure relies heavily on their engine to process background jobs, webhooks, and critical workflows, this upstream failure immediately created a high-severity incident for our own application.

Trigger.dev has published their own transparent engineering breakdown here: Trigger.dev Incident Report (June 22, 2026). Below is the aligned breakdown of how their infrastructure failure directly mapped to our internal engineering timeline and how we engineered our way out of a total blackout.

Wir haben die Produktionscodebasis von Cal.com von einem öffentlichen Repository in ein privates verlegt. Das öffentliche Repository ist jetzt calcom/cal.diy, bekannt als Cal.diy, die Open-Source-, selbst hostbare, von der Community getragene Version von Cal.com.

Folgendes hat sich geändert.

Am Dienstag, dem 27. Januar, erlebten wir einen Produktionsvorfall, der zu beeinträchtigter Leistung auf der gesamten Plattform und zu einem vollständigen Ausfall für einige enterprise-Kunden mit Ereignistypen mit hohem Volumen führte.

Der Vorfall begann mit erhöhter Datenbanklast, schien behoben zu sein und offenbarte dann sekundäre Ausfälle in nachgelagerten Systemen. Dieser Beitrag erklärt, was passiert ist, wie wir es bestätigt haben und was wir infolgedessen geändert haben.

Langsame CI ist eine dieser Dinge, die die Zahnräder von Ingenieurteams verklemmen. Ingenieure warten länger auf Feedback, das Kontextwechseln nimmt zu, und die Versuchung, Änderungen zu bündeln, wächst, was die Situation nur verschlimmert. Wir haben einige Wochen damit verbracht, unsere GitHub Actions-Workflows zu optimieren und unsere PR-Überprüfungen von 30 Minuten auf 5 Minuten zu reduzieren. Das entspricht einer Reduzierung der Wartezeit um 83 %, ohne irgendetwas an Testabdeckung oder Qualitätssicherungsmaßnahmen einzubüßen.

Es gab keine einzige magische Lösung. Wir haben uns angeschaut, wo die Zeit tatsächlich verloren geht, und drei Prinzipien angewendet: intelligente Jobabhängigkeiten, aggressives Caching und Test-Sharding. Hier ist, was wir gelernt haben.

Am 14. November haben wir ein aktualisiertes Design für die Buchungsseite eingeführt, stießen jedoch schnell auf Benutzerfreundlichkeitsprobleme. In diesem Beitrag teilen wir, was wir aus dem Vorfall gelernt haben und welche Schritte wir unternehmen, um unseren Freigabeprozess zu verbessern.

Wir bauen Infrastrukturen, die fast nie ausfallen dürfen. Um dies zu erreichen, arbeiten wir schnell und liefern qualitativ hochwertige Software ohne Abkürzungen oder Kompromisse. Dieses Dokument beschreibt die ingenieurtechnischen Standards, die uns bis 2026 und darüber hinaus leiten werden.

Ein tiefer Einblick in die Art und Weise, wie wir schlecht funktionierende Algorithmen in einer realen Produktionscodebasis erkannt, analysiert und optimiert haben.