Kommentare 3

Rückblick meiner Reading Challenge 2017

Ende 2016, Anfang 2017 habe ich mir für 2017 5 „Challenges“ vorgenommen. Eine davon bestand darin 26 Bücher gelesen zu haben. Inhalt/Kontext egal. Bei mir in den Schrank oder auf den Kindle kommen meistens Sachbücher. Mit Blick auf die Challenge kann ich sagen, dass ich sie geschafft habe, knapp, aber geschafft. Die Weihnachtsfeiertage boten die Chance zum aufholen.
Unter den gelesenen Exemplaren befand sich die Spannbreite zwischen Wirtschaftszeug wie „The Four“, „The Upstarts“ „Transformationale Produkte“ und „Machen!“ (das Buch der MyMuesli Gründer) zu Psychologie Kram von Dan Ariely, der Kahnemann/Tversky Bio von Michael Lewis „Aus der Welt: Grenzen der Entscheidung“, aber auch unterhaltsames, wie Football Leaks.
Für 2018 finden sich auf dem Kindle aktuell ein paar Leseproben, die nach Prüfung ggf. in die 2018er Challenge aufgenommen werden, unter anderem

  • Narconomics
  • Generation Putin
  • The Culture Map
  • und noch zwei drei andere 🙂

Desweiteren habe ich mir vorgenommen das ein oder andere Buch auf diesem Blog zu kommentieren.

Kommentare 0

Lesenswert KW52

Kommentare 0

Intelligente Autos – wie wäre es mit besseren Boardsystemen

Die Zukunft des Autos ist autonome Mobilität. Soweit sind sich die Experten einig. Dazu müssen die Autos in der Lage sein die Verkehrssituation richtig einzuschätzen und die Daten der verbauten Sensoren in den richtigen Kontext zu bringen.
Aktuell fahre ich einen 2016er VW Passat Kombi („Variant“) – ja, mit Drecksschleuder Diesel Motor usw. Diesem Passat hatte ich seinerzeit einige Assistenzsysteme konfiguriert. Unter anderem eine Verkehrszeichenerkennung, eine automatische Distanzregelung, sowie eine standardisierte Regenerkennung.
Fährt man nun beispielsweise auf der Autobahn, so zeigt das Auto im Cockpit die aktuell erlaubte Höchstgeschwindigkeit. In Deutschland gibt es die Besonderheit, dass es auch Zeit- oder Wetterabhängige Geschwindigkeitsregelungen gibt. Dazu gehört eine reduzierte Geschwindigkeit bei Regen oder zwischen 22-6 Uhr.
Ein Beispiel warum etablierte Hersteller von Autos aktuell mit simplen „Verknüpfungen“ von vorhandenen Daten scheitern ist für mich das folgende:
Obwohl dem „Bordcomputer“ über die diversen Sensoren alle Eckdaten zur Verfügung stehen, ist das Auto in genau diesen unscharfen Situationen nicht in der Lage die passende Geschwindigkeit anzuzeigen.
Wo ist das Problem?
Eigentlich ginge es nur darum vorhande Daten zusammen zuführen. Der Regensensor erkennt regen, der Verkehrszeichensensor erkennt ein Zeichen mit Wetterabhängigkeit – zeige genau dieses Geschwindigkeit an. Es ist nach 22:00, zeige diese Geschwindigkeit an.
Doch anscheinend sind solche einfachen Zusammenhänge eine signifikante Herausforderung. Ich frage mich bei dem Blick auf die Zukunft der Mobilität, wie weit wir wirklich von autonom fahrenden Autos entfernt sind.
Bildquelle: https://pixabay.com/de/adeje-teneriffa-nacht-1575437/

Kommentare 0

Lesenswert KW50

Kommentare 0

Lesenswert KW35

Wie funktioniert Preisfindung im B2B-Sales? | The Art of Sales #7
Scaling, automatically and manually – The Isoblog.
Is an ‚oligopoly‘ of cloud vendors a risk to innovation? | Cloud Pro
The Actually Distributed Web | Linux Journal
deeplearning.ai
Karriere dank Blockchain: So könnte die Technologie Bewerbungen und Bildung aufmischen | ❤ t3n
When Government Rules by Software, Citizens Are Left in the Dark | WIRED
AI Programs Are Learning to Exclude Some African-American Voices – MIT Technology Review
Google DeepDream art: If an AI creates a work of art, who owns the rights to it? — Quartz
BT Exploring Open Data Center Switch Tech to Transform Its Network | Data Center Knowledge
Ambitious One-Gigawatt Data Center Planned in Norway | Data Center Knowledge
In nahezu Echtzeit nutzbar: Microsoft stellt neue KI-Plattform vor
Traditional Asset Tokenization – Hacker Noon
The Beginning of Uber – Garrett Camp – Medium
Inside Waymo’s Secret World for Training Self-Driving Cars – The Atlantic
Growing Up with Alexa – MIT Technology Review
Serverless Computing: Keine Server, einfach nur Code | ❤ t3n

Kommentare 2

Planung und Aufwandsschätzung in Projekten

Als „klassischer“ Projektleiter ist man heutzutage gefühlt von der alten Schule. Uncool, nicht „agile“, nicht state-of-the-art. Die wenigsten haben halbwegs Ahnung über agile Methoden, aber lassen wir das an der Stelle…
Eine klassische Disziplin die man von Projektleitern erwartet, ist die Planung. Planung von Aktivitäten, Arbeitspaketen, Aufgaben und was es sonst noch so alles gibt. Selten wird der Planungsvorgang als klassische „handwerkliche“ Tätigkeit gesehen, meistens ist die Erwartung das der Projektmanager durch Magie oder Zauberkunst einen Plan erstellt. Einen Plan, der passen muss. Die sachliche Betrachtung ist ein Stück weit einfacher. Projektpläne entstehen in der Regel nicht durch Eingebung sondern durch sachliche Analyse. Analyse des Projektendproduktes, Zerlegung dieses in seine Einzelteile und dann Abschätzung der Aktivitäten und deren zeitlichen Aufwände.
Kurzum, 99% Arbeit und maximal 1% „Kreativität“.
Nachdem man die diversen Aktivitäten ermittelt hat, in der Prince2 Welt wird das oftmals über die Zerlegung des Ergebnisprodukts in Teilprodukte (Produktbasierte Planungstechnik), gilt es deren Aufwände abzuschätzen. Hier haben sich diverse Methoden (“Best Practice“) zur Schätzung ergeben, die teilweise auch im Prince2 Workbook so aufgeführt werden:

  1. Top-Down-Schätzung: Man nähert sich von oben an den Planwert. Typischerweise hilft diese Methode in einer frühen Phase oder bei einer sehr allgemeinen Aussage. Als Beispiel kann die Verteiler der Ressourcen dienen, es werden 30% Engineering und 30% Testing basierend auf Erfahrungen benötigt. Geht schnell, ist aber unpräzise.
  2. Bottom-Up Schätzung: Jede einzelne Aktivität wird für sich geschätzt. Das kann durch ausführliche Diskussion mit Fachexperten, vorausgegangenen Projekten oder Erfahrungswerten stattfinden.
  3. Vergleichsbasiertes Schätzen: Für mich ein zu häufig vernachlässigter Ansatz, dabei wird systematisch auf bestehende Daten zurückgegriffen. Im Laufe der Zeit sollten Organisationen mit Projekterfahrung einen entsprechenden Fundus an Daten besitzen. Leider wird aber oftmals beim Projektabschluss auf eine entsprechende Dokumentation verzichtet. Oder die Daten sind zu unstrukturiert.1 Im Idealfall besitzt man für bestimmte Aktivitäten aber Vergleichs- oder Referenzwerte, die der Projektleiter auf diese neue Planung anwenden kann.
  4. Parametrische Schätzung: Die offizielle Beschreibung lautet Ermittlung von Schätzwerten, wo immer möglich anhand von Messdaten/empirischen Daten und Korrelationsanalysen(…)“. Kollegen von mir haben eine Metrik, an der sie die Aufwände einer Infrastruktur basierend auf der Anzahl und Typ der eingesetzten Infrastrukturkomponenten hochrechnen können. Beispielsweise, x Loadbalancer mit y Regeln bedeuten ein Engineering Aufwand von z.
  5. Ein-Punkt-Schätzung: Nutzung/Berechnung eines einzelnen Wertes als beste Schätzung.
  6. Delphi-Methode: Sehr aufwendige Methode, da mittels Fragebögen und unabhängiger Befragung von diversen Gruppen (Experten, Fachfremde, etc.) Fragerunden geführt werden, die mittels Rückkopplung verfeinert werden.
  7. Drei-Punkt-Schätzung: Mittels der Drei-Punkt-Schätzung oder PERT-Schätzung habe ich bislang die besten Erfahrungen gemacht. Dabei werden Fachexperten gebeten den besten Fall, den wahrscheinlichsten Fall und den schlechtesten Fall einer Aktivität zu schätzen. Damit wird dann der gewichtete Durchschnitt errechnet.2 Als Formel dient (BestCase + 4 x LikelyCase + Worstcase) / 6

Im Rahmen einer seriösen „klassischen“ Planung gilt es zudem noch ein paar Regeln zu beachten:

  • Ressourcen sollten niemals zu 100% verplant werden, aus den bekannten Gründen (Krankheit, Overhead, etc.) – maximal 80%!
  • Ressourcen, die an mehreren Projekte parallel arbeiten können noch weniger geplant werden, da der Overhead steigt und die „Umschaltzeiten“ merklich ansteigen.
  • Je nach Situation werden oftmals „Wunschwerte“ geplant. Wenn beispielsweise der Geschäftsführer am Planungsworkshop teilnimmt und dieser ein bestimmtes Interesse hat, werden die Teilnehmer oft opportunistisch schätzen. 3
  • Im Idealfall sollte ein übergreifendes Team bei der Schätzung teilnehmen, der jeweilig für die Erarbeitung des Produktes verantwortliche das letzte Wort bei der Schätzung haben.
  • Und der no-brainer zum Schluss, es sollten immer hinreichend Puffer, besser noch „Zeitreserven“ für sonstige Abstimmungen und unerwartete Ereignisse („Probleme im Projekt“) eingeplant werden.
  1. Hier bin ich seit längerem der Meinung, dass Spracherkennung und Maschinelles Lernen eine Lösung bieten können
  2. Ich habe hierzu ein nettes MS Project Template mit eingebauter PERT Funktion erstellt. Bei Interesse hinterlasse bitte einen Kommentar und ich sende es Dir zu.
  3. Schnell besteht hierbei die HiPPO (highest paid person’s opinion, highest paid person in the office) Gefahr
Kommentare 0

Lesenswert KW32

How will Brexit affect your cloud strategy? | Cloud Pro
Google Spent 2 Years Studying 180 Teams. The Most Successful Ones Shared These 5 Traits | Inc.com
Aussie brothers raise $9m for training startup A Cloud Guru after less than two years | afr.com
VW CEO pushes for electric cars but faces internal backlash from leadership | Electrek
Mazda exec presents bold ‘let’s pretend the EV future will never come’ strategy | Electrek
How to get ready for your cloud transformation | Cloud Pro
National Theatre moves to the cloud to prepare for GDPR | Cloud Pro
BP starts to move workloads into Microsoft Azure | Cloud Pro
Alphabet Wants To Fix Clean Energy’s Storage Problem — With Salt
Capitalism the Apple Way vs. Capitalism the Google Way – The Atlantic
Scientists Need to Move Fast and Break Things – Scientific American Blog Network
Chinese chatbots apparently re-educated after political faux pas
Managing Deep Learning Development Complexity
The same old historicism, now on AI | Terra Incognita
How Machine Learning Is Helping Morgan Stanley Better Understand Client Needs
Microsoft 2017 annual report lists AI as top priority

Kommentare 0

Chaos Engineering – das Impfen unter den Operations Modellen

Vor ein paar Wochen stellte ich fest, dass mein Impfschutz gegen Tetanus vor 21 Jahren abgelaufen war. Das war dann in der Tat notwendig. Wikipedia definiert den Begriff einer Impfung wie folgt:

Eine Impfung, auch Schutzimpfung oder Vakzination (ursprünglich die Infektion mit Kuhpockenmaterial; von lateinisch vacca, ‚Kuh‘) genannt, ist die Gabe eines Impfstoffes mit dem Ziel, vor einer (übertragbaren) Krankheit zu schützen. Sie dient der Aktivierung des Immunsystems gegen spezifische Stoffe. Impfungen wurden als vorbeugende Maßnahme gegen Infektionskrankheiten entwickelt.

Das past zu einer Analogie, die ich im Cloudcast #299 gehört hatte. Dort ging es um die Disziplin des Chaos Engineerings, einem Betriebsmodell bei dem es darum geht, dass (verteilte) IT-Systeme niemals perfekt sind. Vielmehr ist die These sogar, dass sie verwundbar sind und eher die Frage berechtigt ist, wem diese Verwundbarkeit zuerst auffällt. Dem dafür verantwortlichen Betreiber oder jemand externem.1
Der Begriff Chaos Engineering leitet sich am ehesten von einem Modell, dass bei Netflix angewandt wird ab. Dort wurde vor Jahren ein Tool namens Chaos Monkey genutzt (und für Jedermann veröffentlicht), welches zufällig bestimmte Komponenten eines Systems bewusst im laufenden Betrieb zum Absturz bringt. Damit kann dann validiert werden, on das System als Ganzes wirklich hinreichend ausfallsicher ausgelegt ist.
Die Denke ist, Fehler werden passieren, die Frage ist nur wann. Und wie sehr kann ich den „Impact“ durch diesen Fehler im Falle minimieren.
Hier kommt die Analogie zur Impfung ins Spiel. Damit mein Immunsystem zur Abwehr gegen bestimmte Stoffe aktiviert wird, muss ich es zunächst einer kleinen Menge eben dieses Stoffes aussetzen.

Was sind die Prinzipien des Chaos Engineerings?

Hierzu bietet die eigens von Afficionados angelegte Seite PRINCIPLES OF CHAOS ENGINEERING eine gute Definition:

Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.

Selbst wenn alle einzelnen Systeme einer verteilten Umgebung voll funktionstüchtig sind, kann es dennoch zu einer Nutzerbetreffenden Einschränkung kommen. Eben diese impliziten Abhängigkeiten sind in großen Systeme oftmals nur nach einer Störung herauszufinden (dran Denken, Lessons Learned nach einem Incident). Will man hier etwas „proaktiver“ Vorgehen, ist das Modell des Chaos Engineerings prädestiniert:

  1. Definiere den ‚steady state’, am besten in einer messbaren Form, aus dem das zu erwartende normale Verhalten Deines Systems hervorgeht. Wichtig ist hier meines Erachtens der Aspekt des messbaren. Das kann bei einer Webseite die Antwortzeit auf bestimmte Anfragen sein, am besten auf Anfragen, die eine Vielzahl von Backend-Services mit einbezieht.
  2. Stelle die Hypothese auf, dass sowohl die Kontrollgruppe, als auch die experimentelle Gruppe sich gleich verhalten werden.
  3. Definiere Variablen, die ein echtes Verhalten darstellen, wie denkbare Anzahl von abgestürzten Servern, reduzierter oder limitierter Netzwerkbandbreite, usw.
  4. Vergleiche die Experimentier und die Kontrollgruppe kontinuierlich. D.h. starte durchgängig Experimente, die durch die Veränderung der definierten Variablen geprägt sind.

Die Fortgeschrittenen führen die Experimente direkt in der Produktion aus. Naheliegend fängt man mit einem reduziertem Radius an und vergrößert diesen immer weiter. Im Idealfall ist das gesamte System eingebunden. Mir ist zudem immer wichtig, dass man die dennoch auftretenden Incidents und im wiederholten Falle Problems (nach ITIL Sprache) als Input für die Testfälle/Variablen hernimmt.

  1. Extern muss nicht limitiert sein auf einen externen „Angreifer“ im Security Sinne. Es kann sich dabei einfach um einen operationsfremden und zu spät erkannten Incident handeln.
Kommentare 0

Lesenswert KW31

7 Interesting Parallels Between the Invention of Tiny Satellites and Cloud Computing  – High Scalability –
ImageNet: the data that spawned the current AI boom — Quartz
Corporations in the Age of Inequality
How We Built a Virtual Scheduling Assistant at Microsoft
When Moore’s Law Met AI – Artificial Intelligence and the Future of Computing – Medium
Japan battles population decline with robots – CBS News
Facebook builds natural language processing into Messenger | VentureBeat | Bots | by Khari Johnson
Google launches its own AI Studio to foster machine intelligence startups | TechCrunch
A practical explanation of a Naive Bayes classifier | MonkeyLearn Blog
Hackers break into voting machines in minutes at hacking competition | TheHill
Unlock | The Daily | L2

Kommentare 0

Die Verfügbarkeits Pyramide – oder wie man zu hoch verfügbaren Services kommt – Teil 2

Im vorhergehenden Post zum Thema Verfügbarkeits Pyramide beschrieb ich die ersten drei Ebenen. Nun zu den weiteren.
Ebene vier, wenn man die ersten Drei „im Griff“ hat, ist ein ordentliches Testkonzept und gesetzte Release Verfahren. Ein gutes Zitat zur Frage wie weit man Testaufwände treiben sollte, geht wie folgt:

„If you haven’t tried it, assume it’s broken.“

(Autor unbekannt)
Dem folgend gilt also alles als kaputt, solange nicht das Gegenteil nachweisbar ist. Das ist eine vielerorts untypische Vorgehensweise. Ist es doch traditionell so, dass man in ein System eindringt, oder ein Fehlverhalten auftrat. Folgt man der oben angeführten Haltung, geht man davon aus, dass bis zum Bestehen eines negativen Tests ein System als unbekannt gilt.
In der Softwareentwicklung gebt es dazu den Ansatz der Testgetriebenen Entwicklung. Dabei werden die Testfälle vor der Entwicklung der eigentlichen funktionalen Komponenten geschrieben. Nach dem Paradigma des Site Reliability Engineerings https://landing.google.com/sre/book/chapters/testing-reliability.html wird davon ausgegangen, dass man durch fundiertes und professionelles Testing die MTTR (Mean-Time-To-Repair) reduzieren und damit die MTBF (Mean-Time-Between-Failures) steigern kann:

It’s possible for a testing system to identify a bug with zero MTTR. Zero MTTR occurs when a system-level test is applied to a subsystem, and that test detects the exact same problem that monitoring would detect. Such a test enables the push to be blocked so the bug never reaches production (though it still needs to be repaired in the source code). Repairing zero MTTR bugs by blocking a push is both quick and convenient. The more bugs you can find with zero MTTR, the higher the Mean Time Between Failures (MTBF) experienced by your users.

Klassisch gibt es drei Testtypen:

  • Unit Tests, zum Testing einzelner Komponenten
  • Integrationstests, zum Testen der Komponenten im Verbund
  • Systemtests, zum Testen ganzer Umgebungen unter Simulation bestimmter Thesen (wie z.B. „Kann 10.000 User Sessions standhalten“)

Als nächster Aspekt der Pyramide wird das Capacity Planning angesehen. Also der kontrollierte Umgang mit der vorhandenen und basierend auf Trends oder Annahmen benötigten Kapazität. Bei eigenen Installationen („On-Premise“) sind hier in der Regel auch Investitionsplanungen und Entscheidungen abhängig. Aber auch beim Einsatz von Cloud Service Providern gilt es diese Disziplin sachgerecht durchzuführen. Denn man möchte/muss die etwaigen Ressourcen bei Zeiten verfügbar haben (Spin-up, Konfiguration laden, Applikation ausrollen, etc.).
Die letzten beiden Punkte der Pyramide würde ich tendenziell zusammenfassen: Development und Product.
Es ist essentiell, dass die Produktentwicklung von vornherein Skalierung vorsieht. Dazu benötigt es die richtigen Komponenten, wie Analyse Tools. Aber auch einen passenden Produktstart, wie zum Beispiel eine Einführung in Phasen („Beta“, Closed User Group, usw.). Bei Google haben sie auch dafür eine eigene Rolle, die des Launch Coordination Engineers. Diese kümmern sich um die korrekte Bearbeitung der Lauch Coordination Checklist.