Am kommenden Dienstag wird der Unix Timestamp „17“ – der Counter springt am Dienstagabend, 23:13 Uhr und 20 Sekunden auf 1700000000. Der Sprung auf 1600000000 erfolgte zuletzt am 13. September 2020.
Im Podcast war diese Woche Justine Weiss von LAMA LIVING zu Gast, einem Shop für nachhaltige Heimtextilien. Habe wieder einiges gelernt, beispielsweise was „Cradle to Cradle“ ist und wie man E-Commerce nachhaltiger machen kann.
In den USA war die KubeCon angesagt, dazu habe ich nächste Woche den ein oder anderen Bericht.
allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:
20 Jahre SRE bei Google: Lessons Learned
Während für die einen SRE noch Neuland ist, feiert Google 20 Jahre Site Reliability Engineering mit 11 Learnings im SRE Blog.
Der Artikel startet mit einem kleinen Vergleich: Die Compute Power der Infrastruktur von Google ist heute 1000-mal größer als vor 20 Jahren, die Netzwerk-Infrastruktur sogar 10.000 mal so groß. Früher wurde alles mit einer „Collection of python scripts“ organisiert, das geht heute natürlich nicht mehr.
- „The riskiness of a mitigation should scale with the severity of the outage“ – Während eines YouTube Incidents im Jahr 2016 habe man einen „Mitigation“ Path gewählt, der ein größeres Risiko hatte als der Incident selbst – so etwas sollte man in der Praxis nicht tun und genau abwägen, damit es nicht zu einem „Cascading failure“, einem Schneeballeffekt kommt – was in 2016 bei YouTube dann leider passiert ist.
- „Recovery mechanisms should be fully tested before an emergency“ – Man soll Recovery Prozesse regelmäßig trainieren, sodass man sie im Ernstfall nicht das erste mal in der Praxis anwendet. Im Deutschen kennt man auch den Spruch „Alle wollen Backup, keiner will Restore“ – kleiner Seitenhieb, da man eigentlich den Restore Prozess testen sollte und nicht unbedingt das Backup.
- „Canary all changes“ – Changes sollte man in Häppchen ausrollen – im Beispiel hatte ein einfache Cache Configuration Change YouTube für 13 Minuten komplett offline genommen. Im SRE Book gibt es hierzu ebenfalls einen Artikel.
- Have a „Big Red Button“ – Ein „Big Red Button“ erlaubt das Abschalten eines Features oder mehrere Features komplett, oder auch den Rollback auf den Zustand vor einem Deployment. In dem Beispiel hat ein Mitarbeiter seinen Desktop einfach hart deaktiviert, der einen Ausfall verursachenden Change ausgerollt hätte.
- „Unit tests alone are not enough – integration testing is also needed“ – Bedarf keiner Erklärung – im Silo mag etwas funktionieren, im Zusammenspiel mit anderen Komponenten aber nicht – deshalb muss man dies testen.
- „Communication Chanels need backup“ – Google hatte selbst einen Ausfall und man wollte sich über Hangouts und Google Meet organisieren, leider waren aufgrund des Ausfalls alle ausgeloggt. Google empfiehlt daher unabhängige Backup Channels und dafür auch nochmals Backup-Channels zu haben.
- „Intentionally degrade performance modes“ – Performance von Komponenten sollte man absichtlich verringern können, um die Auswirkungen auf andere Komponenten frühzeitig zu merken.
- „Test for Disaster resilience“ – Überlebt dein System einen kompletten Neustart? Das kann schon der Neustart eines Servers sein, oder mehrerer Komponenten, die eine Abhängigkeit haben – muss eine bestimmte Reihenfolge eingehalten werden?
- „Automate your mitigations“ – Kennt man seine Problemkinder, so kann man automatisiert Mitigationen ausrollen, dafür habe ich weiter unten auch noch einen Tool-Tipp.
- „Reduce the time between rollouts, to decrease the likelihood of the rollout going wrong“ – auch bekannt als „Release often, release early“ – je kleiner das Änderungsvolumen desto geringer das Risiko – gilt auch für das Einspielen von Patches oder OS Upgrades.
- „A single global hardware version is a single point of failure“ – man sollte nicht nur eine Hardware Revision von wichtiger Hardware haben – es muss nicht gleich ne Dual Vendor Strategie sein, es reicht vielleicht auch schon, verschiedene Versionen zu betreiben. Google hat das Ganze während eines zero-day bugs im März 2020 gemerkt, zum Glück waren hier mehrere Versionen der Netzwerk-Hardware live.
Trotz allen Empfehlungen sollte man aber auch immer bedenken, dass man selbst in der Regel nicht auf „Google Scale“ unterwegs ist. Was für google gilt, nicht für einen selber. Die aktuell 3 Bücher zum Thema SRE kann man bei Google kostenlos online lesen.
Lessons Learned from Twenty Years of Site Reliability Engineering
Kritik an Cloudflare Postmortem
In der letzten Woche hatte ich ausführlich über den (Strom-)Ausfall bei Cloudflare berichtet. In meiner Darstellung habe ich ein wichtiges Detail übersehen: Cloudflare hat seinen Dienstleister ordentlich an den Pranger gestellt – Dafür gab es in der vergangenen Woche teilweise massive Kritik am öffentlichen Postmortem. Teilweise auf Twitter, vor allem aber im verlinkten Hacker News Thread.
Dazu kommt, dass Cloudflare als „classified“ deklarierte Dokumente auf sein Blog stellt. Vermutlich war dies eine Stresssituation und man wollte zeigen, dass man nicht schuld war – ein „blameless“ Postmortem ist es aber nicht.
Hier ein Zitat eines Kommentars:
Interesting choice to spend the bulk of the article publicly shifting blame to a vendor by name and speculating on their root cause. Also an interesting choice to publicly call out that you’re a whale in the facility and include an electrical diagram clearly marked Confidential by your vendor in the postmortem.
Honestly, this is rather unprofessional. I understand and support explaining what triggered the event and giving a bit of context, but the focus on your postmortem needs to be on your incident, not your vendor’s.
Andere schreiben dann einfach „An upstream provider is having issues“… schließlich ist es das Verschulden von Cloudflare, dass noch nicht GA – Services oder erst produktiv gegangene Services bisher nicht auf das ebenfalls ausführlich beschriebene „Active-Active“ Cluster umgezogen sind.
Ein User berichtet hier zudem aus der Sicht eines Enterprise Customers, dass die Kommunikation während des Ausfalls nur über die Status Page erfolgte:
Also one aspect I am missing here is the lack of communication – especially to Enterprise customers. Cloudflare support was basically radio silent during this outage except for the status page. Realistically, they couldn’t do much anyway. But at least any attempt at communication would be appreciated – especially for Enterprise customers, and even more especially after the post-mortem blames Flexential for a lack of communication.
Das ist jetzt auch nicht nachvollziehbar, hat das Cloudflare Team doch eine entsprechende Größe, um 1,2 Menschen abzustellen, die Enterprise Customer zusätzlich via E-Mail über den aktuellen Stand und weitere Vorgehensweise direkt mitzuteilen. Klar, kann man denen auch sagen: „Subscribe einfach zur Status-Page“ – aber die Erwartung aufseiten eines zahlenden Enterprise Customers ist hier verständlicherweise eine andere.
Interessanterweise hatte der Cloudflare Co-CEO Matthew Prince den Artikel selbst bei Hacker-News gepostet, ist dann aber auf die Kritik nirgends eingegangen. Er beantwortet hier nur eine Rückfrage zum Investoren-Call für die „Q3 Earnings“, der am gleichen Tag stattfand. Die Analysen hatten auch keine Rückfrage zum Ausfall, vermutlich hatten die Twitter parallel nicht offen?
Ich hatte vor einiger Zeit mal den „Handling third-party provider outages“ Arikel im Incident.io Blog empfohlen – ggf. kannst du ihn dir in dem Zuge nochmal durchlesen und überlegen, welche Auswirkungen ein Ausfall bei einem deiner Dienstleiter auf euer Geschäft hat.
Update: Cloudflare hat mittlerweile einige Details zu Flexential aus dem Blog entfernt, unter anderem die Confidential Schaubilder.
HN: Post Mortem on Cloudflare Control Plane and Analytics Outage
Sponsored
8gears Container Registry
Container Images unterscheiden sich deutlich von anderen Artefakten hinsichtlich ihrer ständigen Verfügbarkeit.
Im Gegensatz zu NPM oder JAR Artefakte müssen Container Images für den operativen Betrieb der Anwendung durchgehend verfügbar sein. Auch sollte die Registry nicht auf den gleichen Clustern laufen wie die Anwendungen, um den MTTR (mean time to recovery) möglichst kurzzuhalten. Selbstverständlich sollte die Registry hochverfügbar ausgelegt werden, mit ansprechenden Datenbanken und Buckets.
Wenn es bloss jemanden gäbe, der das Ganze für einen übernehmen könnte?
Die 8gears Container Registry ist ein Harbor-basierte Container-Registry Service. Angeboten und betrieben von Harbor Projektbetreuern und Mitwirkenden.
Hochverfügbar in verschiedenen EU Datenzentren ganz in deiner Nähe.
RTO bei Volkswagen und Office-Bar bei Expensify
Der neue VW Vorstand hat eine große Änderung beim Thema Home-Office für Führungskräfte angekündigt. Statt wie bisher 1-mal die Woche sollen die Führungskräfte ab Anfang November 4-mal pro Woche ins Büro kommen. Die Änderungen betrifft mehrere tausend Mitarbeiter an sämtlichen Entwicklungs- und Produktionsstandorten in Deutschland.
VW hatte bisher eine großzügige Regelung mit „einmal Büro pro Woche“, die man aber auch als 4-Tage Block im Monat absolvieren konnte. Für diverse Tätigkeiten finde ich solch ein Modell viel geschickter, als eine stupide „einmal pro Woche“ Regelung. Klar, es gehört ein organisatorischer Aufwand dazu, dass es sich auch richtig lohnt, wenn man sich sieht – aber so kann man kreativ/Workshop Part im Office vom „reinen arbeiten“ zu Hause trennen und, wie ich finde, das besser strukturieren.
Laut dem Artikel fliegt VW-Markenchef Thomas Schäfer jede Woche von Irland per Flugzeug nach Wolfsburg, um dort zu arbeiten – ob das in der heutigen Zeit das richtige Signal ist? Eher nicht.
Einen andren Weg geht die amerikanische Firma Expensify, die eine SaaS Lösung für Spesenmanagement betreibt. Expensify hat nun eine Zeit lag eine Firmen-Bar betrieben, um Mitarbeiter, aber auch Kunden, für Begegnungen und Gespräche ins Büro zu bekommen. Alleine die Schanklizenz habe das Unternehmen 250.000 $ gekostet. Das Experiment sei nun vorbei, habe sich aber gelohnt, vor allem für Gespräche mit Kunden und zur Einführung neuer Produkte gelohnt. Weitere Details zur Firmen-Bar findest du im Blog-Artikel von Expensify CEO David Barrett.
VW führt neue Homeoffice-Regel ein – tausende Mitarbeiter betroffen
Amazon bestellt Office365 Lizenzen für 1 Milliarde US Dollar
Ja, das ist kein Scherz – anscheinend hat Amazon eine 5 Jahres Order für eine Million Office 365 Lizenzen bei Microsoft eingekippt – Insgesamt soll die Order um die 1 Milliarde US-Dollar wert sein. TheRegister hatte bei beiden für einen Kommentar dazu angefragt, aber bisher nichts erhalten.
Interessant, da Amazon ja eigene Produkte in AWS dafür anbietet – Amazon WorkMail und WorkDocs – scheinbar klappt das mit dem Dogfooding da nicht so gut wie mit den AWS Infrastruktur und Cloud-Diensten selbst. Gut, ich kenne auch niemanden, der WorkMail oder Docs nutzt, du?
Laut dem Artikel hat Amazon bisher die „hosted“ Version von Office (und Exchange?) genutzt und möchte nun auf die SaaS Variante umstellen.
Amazon to drop a cool $1B on Microsoft 365 cloud suite
Langsame Integration Tests nach MySQL 8.0 Migration
Mein Bruder Michi hatte in den letzten Wochen ein wenig Spaß mit der Migration einer Datenbank von MariaDB nach MySQL 8.0.
Die Migration selbst war hierbei nicht das Problem – aber mit den Integrationstests vor dem Deployment – diese waren nämlich 25 Minuten langsamer geworden. Nach ein wenig Debugging hat Michi herausgefunden, dass nicht nur die Dump-Erstellung langsamer lief, sondern vor allem die Recreation der Datenbank und der Tabellen ansich.
Dies machen seine Kollegen und er für 500 Tests in der Suite, die natürlich voneinander unabhängig laufen sollen – daher wird der DB Stand resettet – bisher war dies auch kein Problem. Bei 500 Tests, die dann alle 1-5 Sekunden langsamer laufen, kommen in Summe dann schon ein paar Minuten zustande.
Er konnte den Prozess wieder beschleunigen, indem er TRUNCATE anstatt DROP/CREATE nutzt – dies halbierte die Bearbeitungszeit wieder. Zusätzlich hat er die Daten auf ein TempFS gelegt, da sie ja sowieso gleich wieder gelöscht werden. Es gäbe auch noch MEMORY als DB Engine, dann könnten allerdings wieder Nebenwirkungen im Vergleich zu InnoDB auftreten, weshalb hier die Verwendung eines tempfs im Docker Container einfacher ist.
Zur Performance von „Create Table“ in MySQL 8.0 gibt es einen Bug von 2018, der zwar verified, aber nicht fixed ist. Auch ein anderer User berichtet von einer 4-fachen Verlangsamung von „Create Table“ nach der Migration von MySQL 5.7 auf 8.0.
Reduce Integration Test Runtime while using MySQL
Black Friday Tools und SaaS Angebote
Tony Dinh ist ein bekannter und erfolgreicher Indie Hacker. Er hat diverse erfolgreiche SaaS & AI Projekte gestartet, aber auch ein Mac Tool namens DevUtils im Portfolio, welches ich sehr gerne nutze und dass es nun schon für 50 % im Black Friday Angebot gibt.
Um den Verkauf seiner Produkte anzukurbeln, hat er eine interessante Marketing-Strategie – er kuratiert eine Liste mit „Black Friday“ und „Cyber Monday“ Dealz auf GitHub, in die sich die Projekte per Pull-Request eintragen können. Die Liste wird viel geteilt (auch hier) und einen kleinen Teil bekommen seine Produkte ab.
Aktuell findest du 180 verschiedene Tools, Kurse, Subskriptionen und Bücher auf der Liste, teils mit über 50 % Rabatt. Bei den macOS Apps ist beispielsweise DevUtils mit 50 % Rabatt dabei (und oben in der Liste prominent gelistet). Zudem gibt es Productivity Tools, Marketing Tools, Social Media Tools wie das beliebte Hypefury für Twitter, diverse Bücher in verschiedenen Kategorien und auch ein Haufen Online-Kurse.
FOMO getriggert? Oder nichts für dich dabei?
Viel Spaß beim Shoppen.
Awesome Black Friday / Cyber Monday Deals – 2023
Kein Deployment am Freitag?
Charity Majors, CTO und Co-Founder von Honeycomb, beschreibt im verlinkten Tweet, warum sie Deployments am Freitag für keine gute Idee hält.
Grundsätzlich sollte es keine technischen Gründe geben, freitags nicht zu deployen – sondern eher soziale! Der Freitagnachmittag sollte dafür genutzt werden, die Woche Revue passieren zu lassen, sich zu unterhalten und auszutauschen, wie die Woche gelaufen ist und was nächste Woche so ansteht. Bei mir wäre das ja das „Bier um Vier“, aber gut.
Was für freitags ansonsten gelte, gelte auch für andere Tage – niemals deployen und in den Feierabend verschwinden. Charity wirbt auch dafür, anstatt dem Deploy eher den „Merge“ als den kritischen Prozess zu sehen – zudem sollte der Merge und der Deploy zeitlich nicht sehr weit auseinander stattfinden.
Charity Majors @mipsytipsy „no deploy on friday myth“
Analytics Code per CSS anstatt JS
Bear ist eine „privacy-first“ und „super-fast“ Blogging Plattform. Im Blog von Bear zeigt Bear Gründer Herman Martinus, wie man Analytics Code per CSS übermitteln kann, anstatt ihn per JS zu laden. Aus Performance und Privacy Gründen wollte er keine JS basierte Lösung verwenden und hat sich daher überlegt, bei jedem body:hover event ein „Border-image“ zu laden, welches den HTTP_REFERER an einen Hit Counter übermittelt. IP und Referer werden gehased und pro Tag dann wieder geleert.
Er ist jedenfalls überzeugt, dass diese Art der Zählung mehr als ausreichend sei, und vermutlich sogar genauer ist, als Lösungen, die von Ad-Blockern und co. nicht ausgeführt werden. Den kompletten CSS Code findest du hier.
Natürlich muss er den CSS Code auf jeder Seite einbauen, ist aber für ihn kein Problem.
How Bear does analytics with CSS
Schmunzelecke
Gut, wenn sich wenigstens der Hausmeister um Cybersecurity kümmert .
💡 Link Tipps aus der Open Source Welt
sshx – SSH Terminal Live Sharing
Irgendwie finde ich hier immer noch neue Sachen, die mich überraschen – in diesem Fall das Tool „sshx“ – damit kannst du deine Shell übers Web für Demo oder Screensharing Zwecke schnell mit mehreren Zuschauern teilen. Das ist wirklich eine coole Sache, denn du kannst auch mehrere Shells in einem Screen sharen.
Alle Features findest du hier auf GitHub oder auf der Landingpage.
Du installierst sshx einfach übers Terminal mit curl -sSf https://sshx.io/get | sh und bekommst dann direkt einen Link zum Sharen und dann geht es auch schon los.
Im Screenshot kannst du dann sehen, wie das aussieht – echt eine coole Sache.
https://github.com/ekzhang/sshx
KubeLinter – Statische YAML File analyse & Best Practices
Mit KubeLinter kannst du deine Kuberentes YAML Files analysieren und auf die Einhaltung von Best Practices abgleichen. Kube-linter kannst du via brew oder go installieren (brew install kube-linter) und dann direkt loslegen, beispielsweise so: kube-linter lint /path/to/your/yaml.yaml.
Im Beispiel wird das Thema klarer – hat ein Pod keine CPU oder Memory Limits, so gibt es die Empfehlung, diese einfach zu setzen. Das Thema geht in eine ähnliche Richtung wie k8sgpt – nutzt du eines der beiden? Was findest du besser?
https://github.com/stackrox/kube-linter
❓ Feedback & Newsletter Abo
Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.
Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: