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:

507 Abonnenten sind schon dabei - Vielen Dank!

Please enter a valid email address

Diese E-Mail ist bereits registriert.

The security code entered was incorrect

Vielen Dank für Deine Anmeldung - bitte den Opt-In bestätigen.

Wochenlanger Incident bei der Atlassian Cloud

Seit dem 4. April gibt es einen Totalausfall für knapp 400 Kunden der Atlassian Cloud – betroffen sind sämtliche Cloud Produkte, Jira selbst, Confluence, Jira Service Management und sogar OpsGenie. Diese 400 Kunden sind 400 Firmen, die teilweise nur 150 User, aber auch bis zu 4000 User bei Atlassian lizenziert haben.
Was genau war passiert?
11 Tage später (!!) veröffentlicht der Atlassian CTO Sri Viswanath ein ausführliches Statement zum Ausfall.

Ursache des Ausfalls: Ein fehlerhaftes Skript:

The script we used provided both the „mark for deletion“ capability used in normal day-to-day operations (where recoverability is desirable), and the „permanently delete“ capability that is required to permanently remove data when required for compliance reasons. The script was executed with the wrong execution mode and the wrong list of IDs. The result was that sites for approximately 400 customers were improperly deleted.

Fehler passieren, überall wo Menschen im Spiel sind, oder Menschen, die Maschinen steuern.
Im aktuellen Fall bei Atlassian sticht besonders die schlechte Kommunikation des Vorfalls heraus, denn man hat nur sehr spät und zögerlich informiert. Hinzu kommt, das Atlassian parallel zum Incident ihr Event des Jahres, „Team 22“ in Las Vegas, durchgeführt haben.

Ein paar Kunden Statements zum Ausfall:

“We were not impressed with their comms either, they definitely botched it.” – engineering manager at a 2,000 person company which was impacted.

“Atlassian communication was poor. Atlassian was giving the same lame excuses to our internal support team as what was circulated online.” – software engineer at a 1,000 person company which was impacted.

Diese Statements stammen vom unten verlinkten Artikel bei pragmaticengineer.com – dort könnt ihr auch eine genaue Timeline zum Vorfall selbst nachlesen.
Besonders prekär im Zusammenhang mit Atlassian: Man wirbt damit, den Betrieb der selbst entwickelten Software in der Cloud besser zu machen, wie Firmen das mit der Self-Hosted Variante können. Beispielsweise garantiert man für Tier 1 Applikationen (Jira und Confluence Cloud) eine Recovery Zeit von Maximal 6 Stunden. Diese hat man nun leicht überschritten.
Hinzu kommt, dass man wie viele anderen börsennotierten Unternehmen, das SaaS Modell pusht und die Self Hosted Variante zunehmend unattraktiver und teurer macht – um die Kunden eben von der Zuverlässigkeit und weiteren Vorteilen der Cloud zu überzeugen *Zwinkersmiley*.

Was kann man in Summe daraus lernen?

1. Operations und Ausfälle haben immer Priorität – egal welche anderen Termine und Verbindlichkeiten bestehen – Incidents haben immer Vorfahrt.
2. Regel 1) muss vom oder bis zum C-Level mitgetragen werden – das man erst nach 9 bzw. 11 Tagen überhaupt darauf öffentlich reagiert, ist doch reichlich spät
3. Kommunikation ist das A und O. Wenn Kunden, die Support Wege zu einem nicht mehr nutzen können, so sollte man diese von sich aus kontaktieren
4. Vorbereitung: Was kann bei eurem Produkt alles schiefgehen? Seid ihr darauf vorbereitet? Hier kann man gerne mal sämtliche Fälle durchspielen, Reaktionen dokumentieren und trainieren – und sich wo nötig schon mal Vorab Freigaben vom entsprechenden C-Level einzuholen.

Einige weitere Tipps zur Vorbereitung und Vermeidung solcher Incidents findet ihr ebenfalls im unten verlinken Artikel.
Atlassian selbst hat ja auch ein Statuspage Produkt, hier könnt ihr den Ausfall – und die anfänglich doch recht vage Kommunikation – nachlesen. Stand heute (16. April 2022) seien die Systeme für 78% der betroffenen Kunden wiederhergestellt.

The Scoop: Inside the Longest Atlassian Outage of All Time

Perforce kauft Puppet

Das Automatisierungs-Urgestein Puppet wird an Perforce verkauft – Preis bisher unbekannt.
Puppet wurde 2005 von Luke Kanies gegründet und war jahrelang der Standard unter den Automatisierungswerkzeugen für Linux und Windows. Mit Luke hatte ich mal bei ein paar Bierchen bei den Freunden in Nürnberg das Vergnügen. Mit Investments von Cisco, VMWare und Kleiner Perkins hat Puppet nun eine spannende Reise hinter sich. Luke Kanies selbst ist 2016 schon ausgestiegen und hatte an Sanjay Mirchandanai als CEO übergeben – seit 2019 leitet Yvonne Wassenaar das Unternehmen – sie hat den Deal mit Perforce nun durchgeführt.
In einem offenen Brief im Puppet Blog erklärt Yvonne den Deal und was man sich hiervon verspricht.
Wie sieht es bei euch aus? Seid ihr noch mit Puppet unterwegs?
Auf Ansible oder andere Tools umgestiegen?

Perforce adds infrastructure automation tooling with Puppet acquisition

Cloudflare: DDoS Trends in 2022

Cloudflare hat im unten verlinkten Blog Post den ersten DDoS Report für 2022 veröffentlicht:

• Die Summe der DDoS Attacken auf Netzwerk Ebene ging zurück
• Die Summe der DDoS Attacken auf Applikations-Ebene hat sich stark erhöht
• In Russland und der Ukraine waren vor allem Medien und Broadcaster Ziele für Cyberangriffe

Viele russische Online Präsenzen wurden von der Ukraine und der USA, aber auch aus Russland selbst angegriffen.

Der Artikel ist diesmal sehr ausführlich und enthält viele Charts und Statistiken, am Besten ihr schaut direkt mal rein.

DDoS Attack Trends for 2022 Q1

Organisationsformen für DevOps Teams

Im GitLab Blog stellt Johanna Ambrosio 5 verschiedene Organisationsformen für die Zusammenarbeit mit und in DevOps Teams vor.

1. Dev und Ops sind separat, mit „DevOps“ Team dazwischen: Hier kann das „DevOps“ Team zwischen beiden Befindlichkeiten vermitteln und Kompromisse besser herausarbeiten. Die Form der Einführung wird generell nur für den Übergang in eine andere Phase empfohlen
2. Dev und Ops sind separat, haben gleiche Tools und Prozesse: Auch diese Form kann am Start hilfreich sein, vor allem wenn die Teams an unterschiedlichen Produkten und Services arbeiten. Kommunikation und Austausch sollte man trotzdem forcieren, damit keine Silos entstehen
3. „No Ops“ – Teams, die aufgrund Automatisierung und AI komplett ohne manuelle Tätigkeiten auskommen. Es stellt sich die Frage, ob sowas jemals Wirklichkeit werden kann – siehe Atlassian Vorfall oben oder auch den „What is NoOps?“ Artikel bei CIO.com
4. Ops als Infrastruktur Berater – Das kennen wir schon von der Einführung von SRE – meiner Meinung nach macht diese Art der Unterstützung von Dev Teams total Sinn. Nicht alle DEVs sind auch Ops Experten oder wollen dies werden. Auch in diesem Modell kann der Ops Berater von den DEVs lernen und somit optimal beraten
5. DevOps as a Service – Hat man selbst nur eine kleine Organisation oder nicht genug internes KnowHow, so kann man sich DevOps Mitarbeiter auch extern ins Boot holen. Dies hat den Vorteil, dass diese häufig schon viele Use-Cases, Tools und Prozesse kennen und somit schnell und zielführend helfen können. Natürlich muss man im Falle einer externen Unterstützung auch auf andere Themen schauen, beispielsweise Security und Co.

Welche der Formen für euch passt, hängt natürlich vom Anwendungsfall ab, wie immer ist nichts in Stein gemeißelt, ihr könnt mit 5) starten und das später in eine andere Variante umbauen.

5 key organizational models for DevOps teams

Hetzner Cloud: Snapshots sind kein Backup

Am 14. April dieser Woche gab es einen „partiellen Datenverlust“ in der Hetzner Cloud, der laut Angaben von Hetzner 1500 Snapshots betroffen hat. Aufgrund unglücklicher Umstände seien in einem Ceph basierten Storage erst 2 Platten, dann während des Rebuilds eine 3 Festplatte ausgefallen, was zum kompletten Datenverlust geführt hat.

Hetzner bietet in seinem Cloud Angebot Kunden die Möglichkeit, täglich automatisierte Snapshots der Maschinen zu erstellen. Diese Snapshots kosten einfach 20% des Serverpreises und ermöglichen einen „Full Restore“ einer Cloud Instanz. „Full Restore“ ist hierbei mit Vorsicht zu genießen, den je nach Anwendungsfall entsteht bei einem Snapshot kein konsistentes Backup – beispielsweise bei einer Datenbank.
Ein Snapshot kann zwar Teil einer Backup-Strategie sein, ersetzt eben jedoch nicht andere, zuverlässigere Backup Methoden.

Datenverlust bei 1.500 Snapshots von Hetzner Cloud

Grafana erhält weitere $240 Millionen Dollar in Finanzierungsrunde

Grafana Labs, die Firma hinter Grafana, Grafana Loki, Grafana Tempo und nun Grafana Mimir – erhält in einer vierten Finanzierungsrunde weitere $240 Millionen Dollar – unter anderem von J.P Morgan.
Damit sammelt Grafana nur 7 Monate nach der Series C weiteres Kapital ein. Mit GIC hat die Runde diesmal ein Investor aus Singapur angeführt.
GIC’s Chief Investment Officer hierzu:

We are enthusiastic to lead the round, particularly as we’ve witnessed Grafana Labs’ ability to translate a portion of their free adoption into consistent business results. We see significant global interest in Grafana Labs’ products and look forward to leveraging GIC’s network to support the company’s global growth ambitions and drive deeper relationships in APAC over the long term.

Man hat hier erkannt, dass man das freie OpenSource Modell auf breiter Fläche in ein Business umwandeln kann. Zudem möchte man Kontakte und Netzwerke nutzen, um die Präsenz und Umsätze von Grafana im APAC Raum auszubauen.

Grafana Labs announces $240 million Series D round led by GIC and welcomes new investor J.P. Morgan

Weitere Konferenzen für 2022

In Ausgabe #56 hatte ich schon auf einige Konferenzen hingewiesen, hier nun noch einige Tipps:

• 9-12. Mai 2022: SLOconf 2022, virtuell Konferenz zu Site Reliability Engineering und Service Level Objectives
• 17. Mai 2022: GitOpsCon 2022 – Findet im Umfeld der KubeCon + CloudNativeCon Europe in Valencia, Spanien statt.
• 19-21. September 2022: ArgoCon 2022, San Francisco – Konferenz zu Argo CD

Programming Bootcamp Humble Bundle

In diesem aktuellen Programming Bundle des Manning Verlags erhaltet ihr für mindestens 16,23€ 19 Bücher, beispielsweise:

• Web Design Playground
• Get Programming in Go
• Machine Learning Bookcamp
• React Nagice in Action
• iOS Development with Swift

Allein das Machine Learning Bookcamp kostet bei AMZN schon 27,18€ in der Kindle Edition – das Bundle ist also mal wieder ein gutes Angebot.

Programming Bootcamp: Python, Javascript & more

Schmunzelecke

OK, so, our build engineer has left for another company. The dude was literally living inside the terminal. You know, that type of a guy who loves Vim, creates diagrams in Dot and writes wiki-posts in Markdown… If something – anything – requires more than 90 seconds of his time, he writes a script to automate that.

smack-my-bitch-up.sh – sends a text message „late at work“ to his wife (apparently). Automatically picks reasons from an array of strings, randomly

kumar-asshole.sh – scans the inbox for emails from „Kumar“ (a DBA at our clients). Looks for keywords like „help“, „trouble“, „sorry“ etc. If keywords are found – the script SSHes into the clients server and rolls back the staging database to the latest backup. Then sends a reply „no worries mate, be careful next time“

hangover.sh – another cron-job that is set to specific dates. Sends automated emails like „not feeling well/gonna work from home“ etc. Adds a random „reason“ from another predefined array of strings

Dies Skripte und mehr findet ihr in sämtlichen Sprachen hier auf GitHub – danke Rico.

💡 Link Tipps aus der Open Source Welt

Docker Bench – Security Script für Docker

Mit docker-bench-security könnt ihr eure Docker Installationen gegen ein Set von Best-Practices überprüfen. Als Basis hierfür dient der CIS Docker Benchmark. Das Script prüft beispielsweise, ob eure Container

• als Root laufen
• konfigurierte Health Checks haben
• Limits für CPU/Memory aktiv sind
• SecurityOptions gesetzt sind

Probiert es gerne mal aus.

https://github.com/docker/docker-bench-security

OneDev – Self-hosted Git Server mit Kanban und CI/CD

OneDev ist ein mir bisher unbekannter Git Server mit integriertem Kanban und CI/CD Support. OneDev gibt es schon länger und ist aktuell in der Version 7.0.5 erhältlich.
Was kann OneDev alles?

• Suche nach Symbols und Navigation
• Code per RegEx durchsuchen
• Source/Diff mit statischer Analyse für CodeView
• CI/CD Engine ohne YAML.
• Einfacher Markdown Editor

Bei Interesse könnt ihr einfach das Demo Projekt selbst anschauen.

https://github.com/theonedev/onedev

Cloud-Nuke: AWS Account komplett löschen

Mit cloud-nuke könnt ihr einzelne Ressourcen einer AWS Region oder einen kompletten Account löschen. Installieren könnt ihr cloud-nuke einfach via Homebrew: brew install cloud-nuke.
Danach dann beispielsweise alle Ressourcen in eu-west-1 und eu-west-3 löschen:

cloud-nuke aws --region eu-west-1 --region eu-west-3

Ein Tutorial dazu findet ihr hier auf Medium.

https://github.com/gruntwork-io/cloud-nuke

❓ 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:

507 Abonnenten sind schon dabei - Vielen Dank!

Please enter a valid email address

Diese E-Mail ist bereits registriert.

The security code entered was incorrect

Vielen Dank für Deine Anmeldung - bitte den Opt-In bestätigen.