Dummy Title http://example.com en-gb TYPO3 News Tue, 24 Nov 2020 20:38:56 +0000 Tue, 24 Nov 2020 20:38:56 +0000 TYPO3 EXT:news news-24 Wed, 11 Nov 2020 12:54:13 +0000 Apptio stellt neue Funktionen für Cloudability vor https://www.amasol.de/blog/detail-page/apptio-stellt-neue-funktionen-fuer-cloudability-vor Ende September hat Apptio für Cloudability eine neue Funktion vorgestellt, die es ermöglicht, Kubernetes-Container in den Cloud-Financial-Management-Prozess zu integrieren. Nun hat das Unternehmen die Cloudability-Funktionalität weiter ausgebaut. Vorschläge zur Amazon-S3-Storage-Optimierung

Neu ist die Funktion Rightsizing Recommendations for Amazon S3 (Simple Storage Service). Damit erhalten Cloudability-Kunden einen Einblick in detaillierte Messgrößen auf Bucket-Ebene wie z. B. Größe, Objektanzahl, Gesamtoperationen sowie Empfehlungen zum Surface Rightsizing. Sie sind damit in der Lage, Kosteneinsparungspotenziale bei ihren S3-Ausgaben aufzudecken.
 
Kubernetes Summary

Apptio-Cloudability-Kunden können ab sofort Daten zu ihren Kubernetes-Container-Kosten gemeinsam mit Daten zu ihren Nicht-Container-Cloud-Kosten direkt in ihren Cloudability-Berichten und Dashboards dokumentieren. Apptio Cloudability ist damit die bisher erste und einzige Lösung auf dem Markt, die es Unternehmen ermöglicht, vollständige Cloud-Financial-Management-Praktiken auf Container anzuwenden. Damit können sie Kosten den Teams zuordnen, die diese Container betreiben. Außerdem können sie umfassende Berichte, Dashboards, Budgetberechnungen und Forecasts erstellen.
Bei Containern handelt es sich um eine Technologie, die ein einzelnes Betriebssystem virtualisiert und es so ermöglicht, viele unterschiedliche Prozesse konkurrierend und voneinander isoliert ablaufen zu lassen. Traditionelle Virtualisierungstechnologien sorgen für eine Abstraktion von Hardware, Container sorgen für dasselbe beim Betriebssystem. 
Container haben in jüngster Vergangenheit gerade im Bereich Rapid Application Development and Deployment an Popularität gewonnen. Apptio Cloudability ist die bisher erste und einzige Lösung am Markt, die es Unternehmen ermöglicht, die dabei auftretenden Herausforderungen im Kosten- und Finanzmanagement zu meistern.
Für Fragen und weitere Informationen zu Apptio Cloudability wenden Sie sich bitte an Ihren Ansprechpartner bei amasol.
 

]]>
news-21 Mon, 09 Nov 2020 14:53:49 +0000 Agile Operations: Fünf Erfolgsfaktoren für höhere Agilität in der IT https://www.amasol.de/blog/detail-page/agile-operations-fuenf-erfolgsfaktoren-fuer-hoehere-agilitaet-in-der-it Agilität ist mittlerweile weit mehr als ein reines „Buzzword“. Experten gehen davon aus, dass Unternehmen, denen es nicht gelingt, für höhere Agilität in ihrer IT-Abteilung zu sorgen, zukünftig im Wettbewerb zurückfallen werden. Denn die rasch zunehmende Digitalisierung vieler Vertriebs- und Geschäftsmodelle erfordert eine IT, der es gelingt, sich rasch und flexibel auf die sich kontinuierlich verändernden Marktgegebenheiten einzustellen. Dabei muss sie in der Lage sein, trotz dieser Veränderungen „on time“ die für ein erfolgreiches Business erforderliche IT-Umgebung zu schaffen und zu betreiben. „Time to market“ wird zum kritischen Erfolgsfaktor.
Fünf Erfolgsfaktoren für mehr IT-Agilität Unternehmen, die sich mit dem Thema Agilität auseinandersetzen, stellen rasch fest, dass es dabei nicht nur um den Einsatz innovativer IT-Technologien geht, sondern auch darum, einen organisatorischen Unterbau zu schaffen, der das Verständnis und Denken in der IT-Abteilung auf dieses Thema fokussiert. Bei bisherigen Projekten im Bereich Agile Operations haben wir die folgenden fünf Erfolgsfaktoren erkannt:

1.    Definition und Implementieren einer Agile-Operations-Kultur durch das Management

Nur wenn die Führungsriege selbst davon überzeugt ist, dass es nur ein Ziel gibt, nämlich für mehr Agilität in der IT zu sorgen, wird es gelingen, dies auch in der gesamten IT-Organisation zu verankern. Dazu muss es klare Zielvorgaben und eine offene, ergebnisorientierte Kommunikation sowie ein Teamwork geben, dass jeden Einzelnen in die agile Arbeitsweise des gesamten Teams einbettet.

2.    Agilität kann man lernen, man kann es aber auch einfach können

Wie sich in Projekten immer wieder zeigt, ist es wichtig, Mitarbeiter in agilen Methoden zu schulen und weiterzubilden, um eine entsprechende Kompetenz in diesen Bereichen aufzubauen. Allerdings zeigt sich in vielen Projekten auch, dass das Verständnis von Mitarbeitern für Agilität häufig auf entsprechenden Erfahrungen aus der Vergangenheit beruht. Aus diesem Grund ist es wichtig, diese Erfahrungen in Form von Best Practices zu dokumentieren bzw. – sofern man im Unternehmen (noch) nicht über derartige Erfahrungen verfügt – sich unter Umständen mit Mitarbeitern verstärken, die über diese Erfahrungen verfügen.

3.    Zusammenspiel zwischen IT-Infrastruktur, Anwendungen und Daten

Agilität entsteht nur, wenn Infrastruktur, Anwendungen und damit verarbeitete Daten nahtlos ineinander integriert sind. Ein wichtiges Augenmerk muss dabei auf die Schnittstellen gelegt werden, da es hier erfahrungsgemäß zu den größten „Reibungsverlusten“ kommt.

4.    IT und Fachabteilungen: miteinander statt gegeneinander

Der klassische „Clash of Cultures“ zwischen IT und Fachabteilungen muss überwunden werden, wenn es darum geht, für mehr Agilität in der IT zu sorgen. Traditionelle „Plan, build, run“-Konzepte werden schon heute immer häufiger durch moderne DevOps-Konzepte ersetzt, bei denen die IT die volle Verantwortung für Entwicklung UND Betrieb einer Anwendung oder eines Service übernimmt. Ziel muss es nun sein, auch die Fachabteilungen in diese Wertschöpfungskette zu integrieren.

5.    Vom Vorgesetzten zum Coach

Mit dem Streben nach mehr Agilität ändern sich auch die Hierarchien und die Rolle vieler Mitarbeiter insbesondere im Management. Statt zu führen geht es nun darum, auf Augenhöhe anzuleiten und gemeinsam neue Projekte anzustoßen. Dies bedeutet auf der einen Seite, dass es ein neues Bewertungssystem für die Leistung dieser Mitarbeiter geben muss. Auf der anderen Seite müssen sich IT- und Geschäftsleitung darüber Gedanken machen, wie sie diesen Mitarbeitern ihre neue Funktion und Arbeitsweise „schmackhaft“ machen. Denn eines ist klar: Eine höhere Agilität in der IT wird nur erreicht, wenn alle in der IT-Organisation dies auch wirklich verinnerlicht haben und „an einem Strang“ ziehen.

]]>
ITIM
news-27 Tue, 13 Oct 2020 14:45:00 +0000 TLS 1.3 – wird das Monitoring blind? https://www.amasol.de/blog/detail-page/tls-13-wird-das-monitoring-blind Das Thema des zweiten Teils dieser Beitragsreihe zu meiner Bachelorarbeit „Das Verschlüsselungsprotokoll TLS 1.3 und seine Auswirkungen auf das Netzwerk-Monitoring“ war der Aufbau und die Funktionsweise des TLS 1.3-Protokolls sowie die Neuerungen, die mit der Einführung der neuen Version TLS 1.3 im Vergleich zu TLS 1.2 einhergehen. In diesem letzten Teil möchte ich nun die Auswirkungen auf das Monitoring von Anwendungen aufzeigen.

Statische vs. ephemere Schlüssel

Bisher galt, dass volle Sichtbarkeit im Monitoring nur dann besteht, wenn die Daten unverschlüsselt übertragen werden. Verschlüsselte Daten stellten das Monitoring vor eine Herausforderung, die bislang aber gut zu bewältigen war. Es wurden nämlich größtenteils Verschlüsselungsverfahren eingesetzt, die statische Schlüssel nutzen. Statische Schlüssel werden für die Verschlüsselung mehrerer Sitzungen verwendet, ehe sie ausgetauscht werden. Damit war die Hinterlegung dieser Schlüssel im jeweiligen Monitoringtool möglich, und so konnte die Kommunikation dechiffriert sowie die benötigten Parameter überwacht werden.   
Mit dem verpflichtenden Einsatz flüchtiger Schlüssel ist diese Vorgehensweise nicht mehr praktikabel, da jede Sitzung mit einem neuen Schlüssel chiffriert wird. Damit wird das bisherige Verfahren beim Einsatz des TLS 1.3-Protokolls obsolet. Erschwerend kommt hinzu, dass die Verschlüsselung in TLS 1.3 nun auch früher – nämlich bereits nach dem ServerHello – als in früheren Versionen einsetzt. Informationen, die dabei verloren gehen, betreffen unter anderem den Austausch des Schlüssels und der Zertifikate.

Wie viel Sichtbarkeit wird tatsächlich benötigt?

Mit dem Ausbleiben des Schlüssels ist die Sichtbarkeit des kommunizierten Inhalts nur noch sehr gering. Ohne eine Entschlüsselung sind nur noch Metriken wie SSL Connection Setup Time, SSL Handshake Errors sowie allgemeine Metriken zur Netzwerkperformance, die TLS-Version und die verhandelte Cipher Suite sichtbar. 
Detailliertere Informationen, wie beispielsweise einzelne User oder aufgerufene URLs, sind dabei nicht verfügbar. Damit lässt sich Monitoring nicht mehr im gewohnten Umfang realisieren und eine Entschlüsselung wird benötigt.
Gleichzeitig ist abzuwägen, wie viele der aus sämtlichen Netzwerk-Metriken gewonnenen Informationen wirklich erforderlich für ein funktionierendes Monitoring sind. Wann reichen allgemeine Netzwerk-Metriken aus, die auch mit (bzw. trotz) Verschlüsselung verfügbar sind, und wann werden detailliertere Informationen benötigt? 

Lösungen

Einerseits kann man versuchen mit dem geringeren Informationsgehalt auszukommen, welchen allgemeine Netzwerk-Metriken des netzwerkbasierten Monitorings – wie zum Beispiel Dynatrace NAM - bieten. In Kombination mit anderen Informationsquellen – beispielsweise Verhalten von Hosts  oder Datenflussmerkmale – können dabei durch Korrelation aufschlussreiche Muster sichtbar werden.  Der erhaltene Detailgrad hängt vom Anteil der verschlüsselten Daten ab. Möglicherweise wird dies jedoch keine zufriedenstellende Lösung darstellen, insbesondere wenn das Monitoring auch der Gewährleistung der Sicherheit dienen soll.
Abhilfe bietet in diesem Fall der Einsatz von Agenten, die entweder den jeweils aktuellen Schlüssel an das Monitoring-Tool weiterleiten (ExtraHop Reveal(x)) oder das Monitoring direkt an den Kommunikationsendpunkten durchführen (Dynatrace). Eine Ergänzung dazu bietet Ixia mit ihren Visibility Appliances als Proxy, welche die Verschlüsselung unterbrechen, um die Datenpakete zur Analyse an ein Monitoring-Tool zu senden. Anschließend werden die Daten wieder verschlüsselt und an den eigentlichen Empfänger zugestellt.

Fazit

Auch wenn die Veröffentlichung der Spezifikation für TLS 1.3 mittlerweile schon ein Jahr zurückliegt, ist dieses Protokoll noch nicht weit verbreitet. Obwohl der Einsatz von TLS 1.3 empfohlen wird, werden mit Sicherheit noch einige Monate – wenn nicht Jahre – vergehen, bis TLS 1.3 das vorherrschende Verschlüsselungsprotokoll ist. Damit sind die Problematik der geringeren Sichtbarkeit durch TLS 1.3 und die daraus resultierenden Folgen zwar wichtig, drohen aber nicht unmittelbar. 

Dies hat den Vorteil, dass für jeden Betreiber einer Monitoring-Umgebung nun genug Zeit bleibt, um eine optimale Lösung für diese Herausforderung zu finden.

Die amasol AG arbeitet bereits jetzt mit ihren Herstellerpartnern im Bereich des Anwendungsmonitorings Dynatrace, ExtraHop und Ixia an Lösungen, um Sie bei der Umstellung bestmöglich zu unterstützen. 

Damit endet die Beitragsreihe zu meiner Bachelorarbeit „Das Verschlüsselungsprotokoll TLS 1.3 und seine Auswirkungen auf das Netzwerk-Monitoring“.

Wenn Sie sich mit mir über die Inhalte meiner Arbeit austauschen möchten, erreichen Sie mich unter olga.wall(at)amasol.de. 

 

<< Zurück zu Teil II: Was ist TLS 1.3?

]]>
news-12 Tue, 29 Sep 2020 14:10:02 +0000 Apptio Digital Fuel IT Business Management 9.4. verfügbar https://www.amasol.de/blog/detail-page/apptio-digital-fuel-it-business-management-94-verfuegbar Apptio hat die neue Version 9.4 von Digital Fuel IT Business Management vorgestellt. Das neue Release ist ein weiterer Schritt von Apptio bei der mehrstufigen Modernisierung seiner IT-Business-Management-Plattform. Der Schwerpunkt liegt dieses Mal auf Qualitätsverbesserungen. Apptio hat die neue Version 9.4 von Digital Fuel IT Business Management vorgestellt. Das neue Release ist ein weiterer Schritt von Apptio bei der mehrstufigen Modernisierung seiner IT-Business-Management-Plattform. Der Schwerpunkt liegt dieses Mal auf Qualitätsverbesserungen.

Zu den wichtigsten Neuerungen gehören unter anderem die modernisierten Service-Level-Management-Module Compliance sowie Credits and Bonuses, ein modernisiertes Erstellen und Verwalten von Berichten sowie Support für Oracle 19c.

 

Modernisierte Berichtsverwaltung

Die Version v9.4 von Apptio-Digital Fuel ITBM ermöglicht ein schnelleres und einfacheres Erstellen und Verwalten von Berichten. Die Aufgaben wurden dazu aus dem Designer ausgelagert. Damit sind sie zukünftig leichter zugänglich und weniger komplex. Die Anzahl der erforderlichen Klicks zum Erledigen allgemeiner Aufgaben wird dadurch deutlich verringert.

Die Funktionen können nun über das Report-Administration-Modul im Abschnitt Berichte ausgeführt werden und stehen für die folgenden Berichtsarten zur Verfügung:

  • Tortendiagramme
  • Gauge-Berichte
  • Liniendiagramme
  • Balkendiagramme
  • Timelines
  • Tabellen
  • Zusammengesetzte Berichte

Das geht inhaltlich aber nur, wenn diese Bericht jeweils nur aus den Darstellungsformen bestehen, ohne weitere Elemente.

Die neue Funktion steht für Benutzer zur Verfügung, die über die Zugangsberechtigung zum Designer-Modul in ITBM verfügen. Zum Verständnis der Funktionsweise wird auf den Abschnitt „Nicht modernisierte Funktionen“ verwiesen, da dieser für die Berichtsverwaltung noch implementiert werden muss.

 

Neue UI-Funktionen

Die Version 9.4 bietet Support für die folgenden Funktionen im Modul Reports and Dashboards: Berichte:

  • Berichte: Drilldown zum Business-Rule-Template, Breach Adjustment, Upload File Adapter
  • Dashboards: Mehrere Notizen-Widgets können bei einem Dashboard ergänzt werden.
  • Dashboards: Mehrere Quick-Link-Widgets können bei einem Dashboard ergänzt werden.
  • Neue Funktion „Generate Shareable Link“. Damit können Report- und Dashboard-Links mit anderen Benutzern geteilt werden.

 

Shareable Links auf Berichte

Benutzer möchten von Zeit zu Zeit Links auf ITBM-Berichte mit anderen Benutzern teilen. Um dies zu erleichtern, wurde eine „Generate Shareable Link“-Funktion in die Menüleiste von Reports and Dashboards integriert. Ein Klick darauf kopiert den Link in die Zwischenablage des Systems. Der Anwender kann ihn dann in eine E-Mail oder andere Kommunikationsanwendung einfügen.

 

Compliance, Credits, Bonus

Die Module Compliance View, Adjust and Approve sowie Credits and Bonuses wurden modernisiert, stehen aber nur mit der neuen Benutzeroberfläche zur Verfügung. Die Module Personalized View und Adjust Reports können in den allgemeinen Einstelllungen konfiguriert werden, um anstelle von Out-of-the-Box-Berichten angezeigt zu werden.

Weitere Funktionen, die modernisiert wurden, sind Filtern Speicher (Favoriten erstellen), Veröffentlichen und Tools.

 

Support für Oracle 19c

Neu in der Version 9.4 ist der Support für Oracle Database19c. Der Support für Oracle Database 12c Release 2 endet am 30. November, wenn auch Oracle seinen Support einstellt.

Version 9.4. integriert den ojdbc8-Oracle-Database-Treiber anstelle des älteren ojdbc6-Treibers in älteren Versionen. Mit diesem Wechsel auf den neuen Oracle-Database-Treiber endet der Support für Oracle Database 12c Release 1 und ältere Versionen.

 

Support für AdoptOpenJDK8

Die Version 9.4 unterstützt ab sofort sowohl Oracle JDK8 als auch die Open-Source-AdoptOpenJDK8-Distributionen. Bitte beachten Sie, dass ITBM nur Java-1.8-Versionen von AdoptOpenJDK und Oracle JDK unterstützt. Konfigurationshinweise für Java finden Sie im ITBM Installation Guide.

 

Erweiterung für Sommerzeit

Versionen vor Version 9.3 unterstützen die Sommerzeit (Daylight Savings Time, DST) bis März 2021. Bei der Verwendung der koordinierten Weltzeit (UTC) hat dies keine Auswirkungen. Version 9.4 erweitert den Support für Sommerzeit bis 2027.

Mit Digital Fuel Version 9.4. plant Apptio, amasol als Partner exklusiv REST-APIs zur Ansteuerung von SLM-Funktionen zur Verfügung zu stellen. Diese APIs werden von amasol zukünftig in Projekten zur Anbindung von Funktionen der Vertragsverwaltung verwendet. Aktuell arbeitet unser amasol-Team an ersten Prototypen mit unseren Kunden. Auch sind wir dabei, die technischen Schnittstellen mittels eines API-Gateways zu veredeln, sodass wir zentrale Use Cases unserer Kunden einfacher abbilden können.

Über die SLM-Schnittstelle wird es dann möglich sein, die bislang nur manuell über das UI zu pflegenden Verträgen nun auch zu automatisieren. Hier stehen wir eine Vielzahl an möglichen Anwendungsfällen von zusätzlichen Listen und Suchfunktionen über Massenänderungen bis hin zum vereinfachten Onboarding neuer Kunden oder der Integration in Bestellprozess. 

+++ UPDATE 30.09.2020 +++

Neues Release 9.4.1: Update auf Apache Tomcat 7.0.105

Apptio hat mittlerweile die Version 9.4.1 von Digital Fuel ITBM veröffentlicht. Grund dafür war eine Sicherheitslücke in Apache Tomcat, die ein amasol-Kunde entdeckt und an uns gemeldet hatte. Diese Lücke wurde mit einem Upgrade auf die Tomcat Version 7.0.105 geschlossen.

Für Fragen zur neuen Version und zum Upgrade wenden Sie sich bitte gerne an mich.

]]>
news-11 Tue, 29 Sep 2020 14:07:00 +0000 Als Sozialwissenschaftlerin unter vielen ITler*innen https://www.amasol.de/blog/detail-page/als-sozialwissenschaftlerin-unter-vielen-itlerinnen Nach 18 Monaten endet am 31. Dezember meine Zeit hier bei amasol. Es war eine spannende Zeit, in der ich viel gelernt habe – auch über IT – und die wie im Flug vergangen ist. Mit einem Sprung ins kalte Wasser im März 2018 – die Vorbereitungen für das Anwenderforum liefen auf Hochtouren – begann ich mein Praktikum. Von ersten Tag an war ich in die Vorbereitungen für das Kundenevent eingebunden. Ich übersetzte Unternehmensbeschreibungen vom Englische ins Deutsche, aktualisierte die Inhalte in der Veranstaltungsapp und übernahm weitere Aufgaben, die bei der Vorbereitung einer großen Veranstaltung so anfallen. Ende April stieg ich schließlich mit den anderen Kolleginnen und Kollegen ins Flugzeug nach Köln, um selbst am Anwenderforum dabei zu sein. Aber nicht nur das Anwenderforum sondern auch die Umstellung auf ein neues Corporate Design prägten die ersten Woche meines Praktikums. Viele meiner Aufgaben waren kreativ. So hab ich zum Beispiel in der Adventszeit die Lose für unsere Tombola gestaltet.

Nach und nach übernahm ich zu den Aufgaben im Marketing auch Aufgaben im Recruiting. Ich war angefixt und wollte mehr lernen. Weil es bei amasol immer etwas Neues zu lernen gibt und die Arbeit nie ausgeht, wechselte ich dann auf die andere Seite des langen Flures – in den sogenannten „Teppich-Trakt“.

Von nun an widmete ich mich nicht nur dem Schalten von Stellenanzeigen in den Jobbörsen und dem Personalmarketing in den Sozialen Medien , sondern lernte auch den kompletten Recruiting-Prozess kennen. Ich erstellte Stellenanzeigen, sichtete Lebensläufe, kontaktierte passende Bewerber*innen, führte Telefoninterviews und schrieb auch Absagen an zwar qualifizierte, aber für die Positionen ungeeignete Personen. Interviews führen gehört in meinem Studium zur Methodenausbildung. Doch die Perspektive zu wechseln und nicht mehr die Bewerberin zu sein, sondern die Person, die für das Unternehmen geeignete KandidatInnen sucht, ist dann doch eine ganz andere Nummer. Es war spannend, aber auch mit Nervosität verbunden. Der Interviewleitfaden und Silke als Coach, die mir nach jedem Interview wertvolles Feedback gegeben hat, waren eine unglaubliche Unterstützung.

Recruiting war aber nicht alles, was ich lernen durfte. Ich habe mich mit Onboarding-Prozessen beschäftigt, um neuen Kolleginnen und Kollegen das Ankommen und die Einarbeitung möglichst angenehm zu machen. Sie sollen sich auch von Anfang an genauso wohl fühlen wie wir.

Datenschutz, Arbeitssicherheit und Zeugnisse verfassen standen ebenfalls auf dem Stundenplan. Zu guter Letzt ein Thema, wodurch ich weiterhin mit amasol verbunden bleiben werde, war das Alumni Netzwerk. Denn ab Januar bin ich selbst eine Alumna.

Ich habe hier unglaublich viel gelernt. Ich durfte mit hilfsbereiten und netten Menschen zusammenarbeiten, die jede Frage gerne beantworteten, und mit denen es auch viel zu lachen gab. Hier sitze ich also ein letztes Mal mit Blick auf die Berge und einem weinenden Auge, weil ich die Menschen und die Arbeit hier unglaublich vermissen werde, und einem lachenden Auge, das sich auf die neuen Herausforderungen, die mich erwarten werden, freut.

]]>
amasol Insight
news-10 Mon, 21 Sep 2020 14:58:20 +0000 Autonomous Cloud journey at amasol with Keptn https://www.amasol.de/blog/detail-page/autonomous-cloud-journey-at-amasol-with-keptn About two years ago we launched the amasol Managed Cloud offering Dynatrace as a Managed Service hosted in Germany, so we could offer our customer the comfort of a SaaS solution while still allowing them to follow strict data protection regulations. Video – Webinar Autonomous Cloud at amasol with Keptn, GitLab, JMeter & Dynatrace on AKS

 

About two years ago we launched the amasol Managed Cloud offering Dynatrace as a Managed Service hosted in Germany, so we could offer our customer the comfort of a SaaS solution while still allowing them to follow strict data protection regulations. 

Since then we have been extending the platform and adding more features like our aMC Synthetic App, aMC Config Management or a central User Management Portal for all aMC services. 

Because we started on a green field, we were able to pick a modern technology stack and decided to deploy everything on Kubernetes. 

When looking for a Continuous Delivery Solution we quickly settled on Keptn as the control plane. Keptn comes with out-of-the-box integrations of several tools we already had in place for our Continuous Integration setup like GitLab, JMeter or Dynatrace. Thanks to its event-driven architecture we can easily extend it to other tools we may need in the future. 

Keptn also supports us on the way to an Autonomous Cloud by enabling an easy start with SLO-based Quality Gates to improve the quality and continue to other topics like different deployment strategies and auto remediation. 

Current Setup  

We use GitLab CI with a simple pipeline to build and unit-test new versions of our applications. If the build is successful a new image is created and pushed to our container registry. 

 

From there we trigger the deployment (currently manual) with a simple Keptn CLI call, telling it to deploy our new artifact: 

We trigger the deployments through the CLI because we still want manual approval for production deployments. In the next Keptn Version (0.7.0) it will be possible to do manual approvals between stages with Keptn’s new Delivery Assistant, which will allow us to trigger the deployment directly from our CI pipeline and still maintain control when a version should be promoted to production. 

Let me explain what happens behind the scenes when sending the new-artifact event. 

Continuous Delivery 

Once the event is sent Keptn takes the rudder and deploys our new artifact to the first stage. In our case that is the development environment.  

The different stages are defined in a simple YAML file called shipyard: 

For every stage Keptn allows us to specify the deployment strategy, e.g. direct, blue/green or canary and the testing strategy, e.g.: functional, performance. This gives us declarative control about what should happen in each stage as an artifact gets pushed through the delivery process. 

After Keptn deployed an artifact and then triggered the tests it automatically enforces a quality gate. This is done through Keptn’s Lighthouse service which verifies metrics from a monitoring system as Service Level Indicators (SLIs) against defined Service Level Objectives (SLOs).  

In our case, after the deployment is finished Keptn starts the test through Keptn’s JMeter service that is already shipped with Keptn. It does a short functional test to check if the environment is operational and then starts a load test. 

The SLOs are defined in a YAML file and following the GitOps approach are stored along with the other files (SLIs, JMeter Scripts and Helm Charts) in a git repository. 

For every SLO the passing criteria can be specified as an absolute and/or relative value. The relative values are compared against the last X number of builds allowing for automatic regression detection, e.g.: do not allow an increase in response time by more than 10% to the previous build. The absolute allows us to enforce strict thresholds that we may have, e.g.: do not allow a failure rate of more than 1% 

Every SLO has a weight which influences the calculation of the total score. The total score section allows us to specify what score we consider as a successful or failed build: 

With the bridge, Keptn has a great built-in Web UI to get an overview of all your Keptn workflows. 

Keptn follows an event-based approach and each event is listed in the bridge. Staring at the configuration changed event triggered by our keptn CLI call, all subsequent steps are listed in the bridge: 

 

In this case the tests are executed but the thresholds defined in our SLOs are not met because the error rate is to high: 

Because our Total Score is below the defined passing mark Keptn stops the workflow here and does not deploy to our production stage. That is immediate feedback delivered back to engineering so they can start fixing newly introduced issues right away. 

So, once we fix the problem, we run a new deployment and Keptn validates if we are now meeting our SLOs. Looks fine now :

With the successful evaluation Keptn goes ahead an deploys the new artifact automatically to production. 

Summary 

Keptn enabled us to quickly onboard multiple projects and services to a robust Continuous Delivery process, without the overhead of managing multiple Pipelines. 

The SLO-based Quality Gates help us in providing a good experience to our End Users and give our engineers immediate feedback for their deployed changes. 

With Keptn 0.7 we will link our Continuous Integration Flow to Keptn for automatic deployments while still retaining manual approval for production with Keptn’s Delivery Assistant. After that we are looking forward to advanced use cases like auto remediation.  

]]>
APM
news-9 Mon, 21 Sep 2020 14:57:01 +0000 KI-basierte Netzwerk-Monitoring- und Analyse-Lösung: Broadcom stellt DX NetOps vor https://www.amasol.de/blog/detail-page/ki-basierte-netzwerk-monitoring-und-analyse-loesung-broadcom-stellt-dx-netops-vor Broadcom hat die neue Netzwerk-Monitoring–Lösung DX NetOps vorgestellt. Sie basiert auf Broadcom Silicon, der KI-basierten Lösung für hoch skalierbares Operations–Monitoring und -Analyse. Broadcom hat die neue Netzwerk-Monitoring–Lösung DX NetOps vorgestellt. Sie basiert auf Broadcom Silicon, der KI-basierten Lösung für hoch skalierbares Operations–Monitoring und -Analyse. Ziel ist es, auf der Grundlage fortschrittlicher KI-Funktionen einen einheitlichen Überblick über die User Experience in modernen IT-Architekturen zu vermitteln.

DX NetOps konvertiert dazu Inventory- und Topologie-Daten, Device-Metriken, Fehler-, Datenfluss- und Datenpaket-Analysedaten zu einer zentralen Informationsplattform, mit der Network-Operations-Teams sofort Optimierungsmaßnahmen ergreifen können.

In Kombination mit der AIOPs-Lösung von Broadcom versetzt DX NetOPs IT-Teams in die Lage, proaktive und autonome Verfahren zur Fehlerbehebung für die IT-Infrastruktur sowie für alle Anwendungen und Netzwerksysteme zu etablieren. Damit liefern sie die Grundlage für eine noch bessere User Experience.

DX NetOps Powered by Broadcom Silicon adressiert die aktuellen Ursachen von Netzwerk-engpässen

Broadcom ermöglicht mit der neuen Lösung ein hoch skalierbares Operations-Monitoring für den Einsatz in 5G-, IoT-, Cloud- und SD-WAN-Umgebungen und setzt dabei auf moderne KI- und Machine-Learning-Technologien. Damit können umfangreiche Daten auf Chip-Level erfasst werden. Broadcom trägt damit der Erkenntnis Rechnung, dass eine Monitoringlösung, die Paket- und Datenflussdaten in Echtzeit direkt auf den Broadcom-Chips und anderen Endgeräten erfasst, ein wichtiges Differenzierungsmerkmal am Markt und entscheidend für eine verbesserte „Digital Experience“ ist.

DX NetOps baut auf AIOps von Broadcom auf und agiert als „trusted proof point“ für die IT-Operations-Analyse von Broadcom BizOps. AIOps von Broadcom enthält neue intelligente Funktionen zur zum Teil automatischen Problembehebung, die IT-Abteilungen dabei unterstützen, Probleme zu prognostizieren und zu beheben, bevor sie die User Experience beeinträchtigen.

Erweitertes SD-WAN-Monitoring durch strategische Partnerschaften

Broadcom hat die Analysefunktionen in der DX-NetOps-Plattform so erweitert, dass diese Network-Operation-Teams in die Lage versetzt, zuverlässige Daten über die Anwendungserfahrung über SD-WAN-Technologien auf Basis von Silver Peak, VMware (VeloCloud) und 128 Technology zu liefern.

Eine erweiterte anwendungsorientierte Optimierungstechnologie ermöglicht es Unternehmen, das Anwendungs-Monitoring in Echtzeit über ihre SD-WAN-Implementierungen verschiedener Anbieter zu einer zentralen Übersicht zu zentralisieren, in der eingesetzte Netzwerk-Devices unterschiedlicher Hersteller, Infrastrukturschichten und Anwendungen enthalten sind.

Je mehr moderne Architekturen für den Support digitaler Business-Initiativen entstehen, desto zwingend notwendiger ist es für Unternehmen, über einen vollständigen Überblick zu verfügen. In Kombination mit KI- und Machine–Learning-Funktionen sind sie dann nämlich in der Lage, das Anwendungsverhalten wirklich zu verstehen und damit ihre Investitionen im SD-WAN-Bereich zu optimieren.

]]>
news-8 Mon, 21 Sep 2020 14:49:00 +0000 Apptio Cloudability ermöglicht integriertes Kubernetes Financial Management https://www.amasol.de/blog/detail-page/apptio-cloudability-ermoeglicht-integriertes-kubernetes-financial-management Apptio hat mit Cloudability eine neue Funktion vorgestellt, die es ermöglicht, Kubernetes-Container in den Cloud-Financial-Management-Prozess zu integrieren. Apptio hat mit Cloudability eine neue Funktion vorgestellt, die es ermöglicht, Kubernetes-Container in den Cloud-Financial-Management-Prozess zu integrieren. In einem Blog-Beitrag geht Apptio Product Management Consultant Stephen Whinston näher auf die Hintergründe und Vorteile von Cloudability ein.

Unternehmen arbeiten immer häufiger mit Public-Cloud-Anbietern zusammen, um die Skalierbarkeit und Flexibilität ihrer IT-Systeme zu optimieren und dabei gleichzeitig die Kosten im Griff zu haben. Der Einsatz von Containern als Mechanismus für das Deployment von Services in einer Public Cloud wächst derzeit fast doppelt so schnell wie die Cloud-Computing-Nutzung allgemein. Integriertes Finanzmanagement für Container wurde damit in den letzten Jahren zum sprichwörtlichen Mount Everest für die IT-Branche. Mit Cloudability bietet Apptio ab sofort eine Lösung, diesen „höchsten Berg“ zu bezwingen und Kubernetes-Container vollständig in den Cloud-Financial-Management-Prozess zu integrieren.

Das „Black Box“-Problem bei Containern

Das rasante Wachstum der Container-Nutzung wird insbesondere von Unternehmen vorangetrieben, die neue Ansätze bei der Anwendungsarchitektur sowie beim Einsatz und Betrieb von Applikationen verfolgen. Mit Containern ist es möglich, ein Betriebssystem zu virtualisieren und damit unterschiedliche Prozesse voneinander isoliert auf demselben Kernel ablaufen zu lassen. Kubernetes als Container Orchestration Layer bietet ein riesiges Potenzial bei der Anwendungsentwicklung, stellt aber auch riesige neue Herausforderungen in Bezug auf die Kostenallokation, -analyse, -planung und -dokumentation.

Die Herausforderung besteht dabei insbesondere darin, zuverlässig die Kosten für jedes Kubernetes-Cluster zu bestimmen. Diese können jeden Monat für Tausende kurzlebige Cloud-Ressourcen auftreten. Eine weitere Herausforderung besteht darin, diese Kosten dann individuellen Delivery–Teams zuzuordnen. Da jede virtuelle Maschine in einem Cluster tatsächlich multi-tenant ist, d.h. darauf mehrere Applikationen über unabhängige Container laufen, ist es nicht möglich, sich auf Standard-Abrechnungsattribute zu verlassen, um die Kosten abzubilden. Kurzum: Weder die Gesamtkosten eines jeden Clusters noch der Betrag, der den darin enthaltenen Anwendungen zugewiesen werden kann, können von den Cloud-Service-Providern präzise dokumentiert werden. Die Folge: Ein immer schneller ansteigender Teil der Cloud-Rechnung, die eine „Black Box“ ist, wenn es darum geht, die einzelnen Kosten genau auf die entsprechenden Kostenstellen eines Unternehmens umzulegen.

Cloudability-Container öffnet die „Black Box“

Apptio-Kunden können ab sofort die  Kosten eines jeden eingesetzten Kubernetes-Clusters präzise belegen und erhalten so die erforderliche Transparenz, um die Ausgaben auf die entsprechenden Services, Apps und Teams zu verteilen, die dafür verantwortlich sind.

Dies gelingt mit einem schlanken, speziell für diesen Zweck erstellten Cloudability-Container in jedem Cluster, der alle Kosten intelligent abbilden und aufteilen kann. Grundlage dafür sind fortschrittliche Algorithmen, die vier relevante Messgrößen zur Ressourcen-Nutzung an jedem Knoten analysieren – CPU, Speicher, Netzwerk und Festplatte – und Quality-of-Service-Einstellungen auf Pod-Ebene evaluieren. Damit können die Ressourcen-Kosten in Bezug auf native Kubernetes-Systeme aufgebrochen werden. Der Anwender kann diese Informationen dann über die entsprechenden Kubernetes-Konstrukte (wie z.B. Cluster, Namespace oder Label) im Container „Cost Allocation Report“ visualisieren.

Der Launch der neuen Funktion geht jedoch darüber hinaus, einfach nur die Ressourcen eines jeden Kubernetes-Clusters detailliert aufzuführen und zu zeigen, welche Teams darauf Container nutzen. Es geht dabei auch darum, diese ganzen Informationen in den gesamten Cloud-Financial-Management-Prozess zu integrieren. Ein Gesamtüberblick über alle Cloud-Computing-Ausgaben wird damit möglich. Apptio-Cloudability-Kunden können ihre Kubernetes-Kosten gemeinsam mit ihren anderen Cloud-Computing-Kosten in Kostenberichten, Dashboard-Widgets und dem TrueCost Explorer aufrufen.

Auf der Grundlage der unternehmensspezifischen Kubernetes-Labels können Anwender Business Mappings erstellen und optimieren, um Kostenstrukturen und Geschäftseinheiten zu definieren, die widerspiegeln, wie das Unternehmen Chargebacks mit Kostenstellen abwickelt.

Weitere Informationen zu Cloudability finden Sie auf der Apptio–Webseite.

Für Fragen zu Cloudability wenden Sie sich bitte gerne an mich. 

]]>
TBM
news-3 Mon, 21 Sep 2020 11:15:00 +0000 User Behavior Analytics: übergeordneter Nutzen für neue Geschäftsmodelle https://www.amasol.de/blog/detail-page/user-behavior-analytics-uebergeordneter-nutzen-fuer-neue-geschaeftsmodelle Es ist ein immerwährender Kreislauf: Innovationen und neue Geschäftsmodelle führen zu Veränderungen im Kundenverhalten und erzeugen neue Kundenbedürfnisse... Es ist ein immerwährender Kreislauf: Innovationen und neue Geschäftsmodelle führen zu Veränderungen im Kundenverhalten und erzeugen neue Kundenbedürfnisse – was wiederum Anpassungen in Geschäftsmodellen bedingt und Innovationen in eine vom Kunden bestimmte Richtung vorantreibt. Mal dauert der Wandel länger, mal erfordern äußere Umstände eine schnelle Adaptation. Was aber immer bleibt, sind der Nutzer sowie die Art und Weise seines IT-Konsums.

Jeder Klick zählt: für eine positive User Experience …

An dieser Stelle setzt User Behavior Analytics an und stellt den Nutzer in den Mittelpunkt – egal, ob On-Premise oder in der Cloud. Dabei können nicht nur Daten über das Nutzerverhalten, sondern gleichzeitig auch Performancedaten der verwendeten Applikationen gesammelt werden. Auf dieser Grundlage sind dann Optimierungen der benutzerfreundlichen Bedienbarkeit und der Performance der Applikation möglich – für eine positive User Experience.

… und mehr Sicherheit

Darüber hinaus trägt User Behavior Analytics auch zur Sicherung wertvoller Unternehmensdaten bei, indem es untypische bzw. unerwünschte Verhaltensmuster erkennt und isoliert, beispielsweise bei einem untypischen Zugriff auf eine Datenbank zu einer ungewohnten Uhrzeit. Unterstützt wird die Anomalieerkennung durch Machine-Learning-Algorithmen, die jede Abweichung von der Norm aufzeigen. Auch wenn die Traffic-Analyse durch Weiterentwicklungen wie TLS 1.3 erschwert wird, ermöglicht User Behavior Analytics den übergeordneten Blick auf das Netzwerk hinsichtlich Verfügbarkeit und Sicherheit.

NetOps + SecOps = Mehrwerte für BizOps

Die Nutzung von User Behavior Analytics in den Bereichen Performance und Security schafft nicht nur eine größere Produktivität in NetOps und SecOps durch eine gemeinsame Datenbasis, sondern bietet auch konkrete BizOps-Mehrwerte:

  • Kosteneinsparungen durch Reduktion von Datensilos und weniger Tools
  • Besseres Verständnis darüber, wie IT genutzt wird, um Umsätze zu generieren
  • Abgeleitete Kennzahlen aus Netzwerkmetriken wie Packet Loss und Downtime zur Darstellung des Wertbeitrags zum Umsatz und Produktivitätsverlust in kundennahen Abteilungen
  • Wirtschaftliche Bewertung der technischen Umsetzung von kundengetriebenen Anforderungen

Sie wollen mehr zu diesem Thema wissen? Dann sprechen Sie uns gerne an: Fabian Fink, Account Manager, oder Olga Wall, Consultant für Application Performance Management.

]]>
APM
news-20 Sun, 20 Sep 2020 14:49:00 +0000 What’s new at Dynatrace? https://www.amasol.de/blog/detail-page/whats-new-at-dynatrace In den letzten Wochen hat es einige Neuerungen bei unserem Herstellerpartner Dynatrace gegeben. Die Highlights haben wir im Folgenden für Sie zusammengefasst. Operative Einblicke in Kubernetes Pods – mit dem neuen Cloud Application View

Für alle Early Adopter gibt es einen neuen Cloud Application View für tiefe Einblicke in Container und Prozesse. Damit sollen folgende Fragestellungen beantwortet werden:

  • Welche Applikationen und Workloads laufen in meinen Kubernetes-Umgebungen?
  • Sind diese Applikationen und Workloads performant?

Dynatrace gibt einen Überblick über das gesamte Kubernetes Cluster, die Anzahl der gewünschten sowie der tatsächlich laufenden Pods und informiert darüber, wieviele Cluster-Ressourcen die Workloads aktuell verbrauchen. Zusätzlich können Countainer-Ressourcen überwacht und deren Limits angezeigt werden.
Darüber hinaus wurde ab Dynatrace Version 1.196 der Full-Stack Kubernetes-Workload und die Infrastruktur-Beobachtbarkeit mit Schwerpunkt auf Pods und die Verwendung von Namespaces ausgeweitet. Damit kann nun festgestellt werden, ob Kubernetes die Workloads und die Ressourcen optimal verwaltet.

Enhanced User Action Naming Rules

Dynatrace erkennt, wie Benutzer mit einer Webseite oder Anwendung interagieren und bildet diese Interaktionen als User-Actions ab. Diese User-Actions werden automatisch nach vordefinierten Standard-Regeln benannt. Um die Analyse der User-Actions zu vereinfachen, ist es möglich eigene Regeln zur Benennung und Gruppierung zu definieren. Da Web-Anwendungen jedoch immer dynamischer werden, kann die Erstellung effektiver Regeln für die Benennung von User-Actions eine Herausforderung darstellen.
Durch die verbesserten Regeln ist es seit Dynatrace Version 1.192 nun noch einfacher, diese nach eigenen Wünschen umzubenennen und zu gruppieren. Folgende Verbesserungen wurden eingeführt:

  • Placeholders – ermöglichen eine flexiblere Benennung und Analyse von User-Actions
  • Delimiters – vereinfachen das Extrahieren und Ersetzen von Informationen
  • API support – Benennung von User-Actions über die REST-API

Neue RUM Performance Metriken und Verbesserungen bei „Visually complete“

Dynatrace hat mit der Managed-Version 1.194 den „Visually complete“-Algorithmus überarbeitet, um den Nutzern mehr Kontrolle über die Berechnung von „Visually complete“ zu geben. Die Optimierung dieses Bereichs ist oft sinnvoll, da er eine direkte Auswirkung auf die User Experience hat. Außerdem wurden neue Performance Metriken wie „first input delay“, „first contentful paint“ und „largest contentful paint“ hinzugefügt, die bei der Analyse unterstützen sollen. Neben zusätzlichen Möglichkeiten zur Darstellung von Metriken in Dashboards sind damit Analysen von Performanceproblemen über mehrere Dimensionen hinweg in der Multidimensional Analysis View, Analysen der User Action Performance sowie die Detailanalyse in aggregierten Waterfall Charts möglich.

Verbesserungen der API

Einige der Neuerungen in Dynatrace betreffen die API. Die Extension API ermöglicht Early Adoptern die Verwaltung integrierter sowie benutzerdefinierter Erweiterungen für den OneAgent, ActiveGate oder JMX/PMI. Für alle Nutzer sind mittlerweile die Dynatrace v2 APIs verfügbar. Durch den standardisierten Zugang zu Ressourcen, standardisierte Fehlermeldungen und paginierte Endpunkte ist es einfacher, Monitoring-Prozesse zu automatisieren und die Developer Experience mit Konsistenz und Skalierbarkeit zu erleichtern. Ein Preview Program (ab Dynatrace Managed 1.194) bietet ein schnelleres OneAgent Lifecycle Management durch eine verbesserte REST API. Damit können Integrationen schnell und einfach erfolgen sowie hunderte von OneAgents mit nur einem Befehl verwaltet werden. Die aktualisierten REST API Methoden befinden sich im Bereich „OneAgent on a host“ der Environment API sowie in der Configuration API, wo sie auch ausprobiert werden können. Die aktuellste Neuerung betrifft die Monitored entities API. Mit der zweiten Version können nun Kontextinformationen aus Dynatrace an Integrationen von Drittanbietern sowie an weitgehend automatisierte businesskritische Prozesse wie Deployment Pipelines, CI Toolchains und Projekte zur Cloud Migration übermittelt werden.

Premium High Availability

Auch wenn Dynatrace bei einem Ausfall von bis zu zwei Cluster Nodes funktionsfähig bleibt, kann es passieren, dass ein komplettes Rechenzentrum ausfällt. Dieses Problem löst die Premium High Availability von Dynatrace ohne jegliches externes Load Balancing oder Replikationstechnologien. Im Gegensatz zur bereits existierenden High Availability werden dabei zwei Rechenzentren von der Cluster Management Console unterstützt. Neben einem aktiven Deployment-Modell für optimale Hardware-Nutzung sind damit eine automatische Wiederherstellung nach Ausfällen von bis zu 72 Stunden sowie kontinuierliches Monitoring ohne Datenverlust in Failover-Szenarien möglich. Zusätzlich bietet die eigenständige, schlüsselfertige Lösung einen minimierten Netzwerktraffic zwischen den Rechenzentren.

Verfügbarkeit von Premium High Availability

Premium High Availability benötigt eine separate Lizenz und ist für Umgebungen mit 1000+ Host Units vorgesehen. Für das Setup ist die Zusammenarbeit mit Dynatrace R&D erforderlich. Das ab Version 196 verfügbare Early Adopter Release ist nicht für Produktions- oder Offline-Cluster zu empfehlen. In dem im August 2020 folgenden Release soll Premium High Availability GA sein.

Netzwerkzonen für große Umgebungen

Dynatrace führt aktuell Netzwerkzonen ein, die von Early Adoptern ab Dynatrace SaaS Version 1.195 bzw. Managed Version 1.196 getestet werden können. Hintergrund für diese Neuerung ist, dass große globale Unternehmen in der Regel Rechenzentren überall auf der Welt nutzen. Bisher war dabei der Datenverkehr zwischen den Rechenzentren und Dynatrace ineffizient, was bisweilen zu Ressourcenverschwendung oder unvorhersehbaren Ausfällen führen konnte. Dynatrace hat sich das Ziel gesetzt, die Bandbreite und unnötigen Traffic zwischen Rechenzentren zu minimieren. In Kombination mit entsprechend positionierten ActiveGates wird OneAgent-Traffic gemäß definierten Prioritäten geroutet, idealerweise an ein ActiveGate in der eigenen Netzwerkzone. Erst bei einem Ausfall wird ein anderes, nahe gelegenes ActiveGate genutzt. Zusätzlich wird dieser Traffic vor dem Senden an das Dynatrace Cluster komprimiert. Damit kommen die Daten schneller und ohne Umwege im Cluster an. Auf diese Weise können auch große Deployments nach der Lage der Rechenzentren und deren geographischen Lage gruppiert werden. Sie wollen zeitnah über Neuerungen informiert werden? Kunden mit erweitertem Support (Systemservice) durch amasol erhalten wöchentliche Updates über Neuerungen und Verbesserungen an ihrer Dynatrace Plattform. Für weitere Informationen steht Ihnen Ihr APM Consultant gerne zur Verfügung.

]]>
news-26 Tue, 15 Sep 2020 14:31:00 +0000 Was ist TLS 1.3? https://www.amasol.de/blog/detail-page/was-ist-tls-13 Nachdem im ersten Teil der Beitragsreihe zu meiner Bachelorarbeit „Das Verschlüsselungsprotokoll TLS 1.3 und seine Auswirkungen auf das Netzwerk-Monitoring“ geklärt wurde, was Monitoring ist und wie Verschlüsselung im Allgemeinen funktioniert, geht es in diesem Teil nun um die Struktur und Funktionsweise des Verschlüsselungsprotokolls TLS sowie um die Neuerungen, die TLS 1.3 mit sich bringt.

Das Funktionsprinzip von TLS

Oft ist sowohl von SSL (Secure Socket Layer) als auch von TLS (Transport Security Layer) die Rede. Beide Begriffe werden synonym verwendet, bezeichnen aber unterschiedliche Versionen desselben Verschlüsselungsprotokolls, das sich zwischenzeitlich so sehr weiterentwickelt hat, dass damit eine Namensänderung von SSL zu TLS einhergegangen ist.
Das TLS-Protokoll läuft auf dem verbindungsorientiertem TCP-Protokoll, das für die zuverlässige Übermittlung von Datenpaketen zwischen Client und Server zuständig ist. Gleichzeitig ist TLS unabhängig von einem Anwendungsprotokoll, das heißt, jede Anwendung, die sicher kommunizieren möchte, kann TLS nutzen. Ein Vorteil von TLS liegt darin, dass es aus zwei Schichten und mehreren Subprotokollen besteht, die beliebig erweiterbar sind. Damit muss bei Veränderungen nicht jedesmal ein komplett neues Protokoll implementiert werden. 

Das bekannteste und womöglich wichtigste Subprotokoll von TLS ist das Handshake-Protokoll. Dabei wird eine Verbindung zwischen Client und Server aufgebaut und die Vereinbarungen für die folgende Sitzung getroffen. Diese beinhalten die Protokollversion, die zu verwendende Cipher Suite und eine optionale gegenseitige Authentifizierung. 

[Quelle: nach RFC 5246, Fig. 1]


Anschließend kann der Datenaustausch verschlüsselt über das Application Data-Subprotokoll erfolgen. Sofern es sich nicht um die erste Verbindung zwischen Client und Server handelt, sondern eine Sitzung wiederaufgenommen werden soll, kann der Handshake auch verkürzt werden.

Unterschiede zwischen TLS 1.2 und TLS 1.3

Die aktuell noch am weitesten verbreitete Version ist TLS 1.2. Die Vorgängerversionen TLS 1.0 und TLS 1.1 sind zwar auch noch oft im Einsatz, werden aber als unsicher bewertet. Dennoch werden sie aus Gründen der Rückwärtskompatibilität noch unterstützt. Sie werden jetzt aber offiziell als veraltet deklariert und von deren Verwendung wird dringend abgeraten.
TLS 1.2 gibt es seit 2008 und 10 Jahre lang war es die aktuellste Protokollversion. Seit August 2018 wird aber die Umstellung auf TLS 1.3 empfohlen. Die Entwickler von TLS 1.3 haben nämlich das Protokoll ordentlich aufgeräumt und die Bestandteile, die sich als Einfallstore für Angriffe erwiesen haben, entfernt oder zumindest umstrukturiert.

TLS 1.3 zeichnet sich durch folgende Punkte aus:
•    Die Anzahl der vom Protokoll unterstützten Cipher Suiten wurde auf fünf reduziert. Dabei sind nur noch solche mit aktuell als sicher geltenden Verschlüsselungsverfahren übrig geblieben. 
•    Es wird nun besonders viel Wert auf „Perfect Forward Secrecy“ gelegt. Dies bedeutet, dass im Fall der Kenntnis eine Schlüssels durch den Angreifer alle zukünftigen Kommunikationen dennoch sicher sind. Das ist möglich durch den Einsatz sogenannter ephemerer – flüchtiger – Schlüssel, die stets nur für die aktuelle Verbindung gültig sind.
•    Der aus TLS 1.2 und früheren Versionen bekannte Ticket-Mechanismus zur Sitzungswiederaufnahme wird durch ein Pre-Shared-Key (PSK)-Verfahren abgelöst. Damit soll verhindert werden, dass ein Unbefugter mit gestohlenen Sitzungstickets an eine bestehende Sitzung anknüpft.
•    Eine schnellere Wiederaufnahme bestehender Sitzungen wird durch eine weitere Verkürzung des Handshakes erreicht. Mit dem 0-RTT-Handshake können sogar „early data“ vom Client an den Server gesendet werden, noch bevor der Handshake abgeschlossen ist. Bei dieser Methode wird ein Umlauf (Round Trip) beim Verbindungsaufbau eingespart. Der Datenaustausch erfolgt somit noch schneller und effizienter. 
•    Die Verschlüsselung erfolgt in TLS 1.3 zu einem früheren Zeitpunkt. Während in TLS 1.2 erst nach Beendigung des Handshakes verschlüsselt wird, erfolgt in TLS 1.3 die Verschlüsselung der Daten bereits nach dem ServerHello.

Nachdem jetzt geklärt ist, wie TLS funktioniert und wie sich TLS 1.3 von seinem Vorgängerversionen unterscheidet, folgt im nächsten und letzten Beitrag, wie sich diese Änderungen nun tatsächlich auf das Monitoring auswirken.

Wenn Sie sich mit mir über die Inhalte meiner Arbeit austauschen möchten, erreichen Sie mich unter olga.wall(at)amasol.de. 

 

<< Zurück zu Teil I: TLS 1.3 und seine Auswirkungen auf das Netzwerk-Monitoring - Weiter zu Teil III: TLS 1.3 - wird das Monitoring blind?
 

]]>
news-1 Sun, 13 Sep 2020 11:15:00 +0000 Servicetrace APM/TestAutomation: neue Version 2020.1 vorgestellt https://www.amasol.de/blog/detail-page/servicetrace-apm/testautomation-neue-version-20201-vorgestellt Servicetrace hat Servicetrace APM/TestAutomation 2020.1 veröffentlicht. Servicetrace hat Servicetrace APM/TestAutomation 2020.1 veröffentlicht.
Die wichtigsten Highlights der neuen Version sind:

  • Neues Design des Workflows Studio: neue Farben und neue Icons für ein modernes Erscheinungsbild
  • Neue „Action Steps“
    • KI-unterstützte OCR: Erkennt Text auf eingescannten Bildern
    • Mail Operations: Ermöglichen den Abruf, die Bearbeitung und das Versenden von E-Mails aus Postfächern ohne vorinstalliertes Mail-Programm
    • REST Call: Spricht jede beliebige REST-Schnittstelle an durch Ausführen von REST Calls mit den Methoden Get, Post, Put, Patch, Delete, Head und Options

Zu den weiteren Neuerungen gehören:

  • Eine verbesserte Run Result Validation im Control Center
  • Neue Dashboard-Widgets
  • Passwort-Richtlinien für User-Management
  • Über 20 neue REST API-Calls (z.B. im Bereich Workflows oder Test Automation)

Ein Überblick über die neuen Funktionen von Servicetrace APM/TestAutomation 2020.1 steht unter https://www.servicetrace.de/was-ist-neu-apm-ta/ zur Verfügung.

Webcast zu Servicetrace APM/Testautomation 2020.1

Zum Update seiner Software-Robotic-Lösungen für automatisierte Softwaretests und Application Performance Monitoring bietet Servicetrace ab sofort einen Webcast-on-Demand an. Servicetrace Presales Consultant Helmut Apel stellt in diesem Webcast die neuen Funktionen und Optimierungen von APM und TestAutomation ausführlich vor und zeigt sie live in der Anwendungsumgebung.

Hier geht es zum Webcast >>

Für Fragen zur neuen Version von Servicetrace wenden Sie sich bitte an mich.

]]>
APM
news-5 Wed, 02 Sep 2020 11:15:00 +0000 Broadcom stellt Update für BSI vor https://www.amasol.de/blog/detail-page/broadcom-stellt-update-fuer-bsi-vor Broadcom hat CA Business Service Insight 8.3.5.5 vorgestellt. Die wichtigste Neuerung in der neuen Version besteht darin, dass der Adobe Flash Player ersetzt wurde. Damit ist sichergestellt, dass CA BSI nicht durch den zum 31.12.2020 angekündigten End of Support für Adobe Flash beeinträchtigt wird.

Weitere Neuerungen:

  • Windows Server 2019 Oracle-19c-Zertifizierung: Installieren Sie CA BSI 8.3.5.5, um CA BSI mit Oracle 19c Server/Client zu konfigurieren.
  • Windows-Server-2019-Zertifizierung: Um CA BSI App/WebServer auf Windows 2019 zu installieren, ohne den Datenbankserver zu ersetzen, können Sie CA BSI 8.3.5.4.0 installieren.

Darüber hinaus wurden einige Fehler aus dem Vorgänger-Update korrigiert.

Für weitere Informationen zur neuen CA-BSI-Version wenden Sie sich bitte an mich.

]]>
TBM
news-19 Tue, 01 Sep 2020 13:12:00 +0000 Das sollte ein SLM-Tool können: Anforderungen an SLM-Softwarelösungen https://www.amasol.de/blog/detail-page/das-sollte-ein-slm-tool-koennen-anforderungen-an-slm-softwareloesungen-1 Zum Abschluss der Beitragsreihe zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ möchte ich noch auf das Anforderungsprofil für ein Service-Level-Management-(SLM-) Tool eingehen und Ihnen einen kurzen Marktüberblick – natürlich ohne Anspruch auf Vollständigkeit – vermitteln. Zum Abschluss der Beitragsreihe zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ möchte ich noch auf das Anforderungsprofil für ein Service-Level-Management-(SLM-) Tool eingehen und Ihnen einen kurzen Marktüberblick – natürlich ohne Anspruch auf Vollständigkeit – vermitteln.

Zentrale Anforderung: Sammeln und Auswerten der definierten Metriken

Auf die Bedeutung von Kennzahlen und Metriken bin ich ja bereits im zweiten Beitrag der Beitragsserie eingegangen. Da in der Praxis die Anzahl und Vielzahl von Metriken schnell steigt, ist eine Software-Lösung erforderlich, die dieses Volumen auch bewältigt, d.h. automatisiert sammelt und auswertet.  Konkret bedeutet dies, dass die Metriken auf eine geeignete Art und Weise abgebildet und dann den definierten IT-Services zugeordnet werden. Um dann den Erfüllungsgrad der Service Level auswerten zu können, müssen Messpunkte der Services mit einem Messkonzept zuverlässig überwacht werden.

In meiner Arbeit habe ich versucht, eine Anforderungssammlung zu erstellen, die die Notwendigkeit eines integrierten Gesamtsystems verdeutlicht. An dieser Stelle nochmals herzlichen Dank an meine Kollegen bei amasol, die mir beim Erstellen des Anforderungskatalogs geholfen haben.

Als Grobschema wurden die folgenden Anforderungskategorien definiert:

  • Definition der SLM-Objekte
  • Servicekatalog und Leitungsstrukturen
  • Management von SLAs
  • Management von Dienstlieferanten
  • Management der Dienstqualität
  • Schnittstellen zu Prozessen und Datenquellen
  • Grundsätzliches Verwenden des Tools
  • Tool-Hersteller

Die einzelnen Kategorien wurden dann mit drei Prioritätsstufen gewichtet:

  • Prioritätsstufe 1: essenziell
  • Prioritätsstufe 2: erforderlich
  • Prioritätsstufe 3: optional

Die Darstellung des kompletten Anforderungskatalogs würde den Umfang dieses Beitrags sprengen, ich kann ihn aber bei Interesse gerne auf Anfrage zur Verfügung stellen.

Marktüberblick: Sammeln und Überwachen vs. Verarbeiten

Betrachtet man derzeit den Markt für SLM-Softwarelösungen, so muss generell zwischen Lösungen zum Sammeln und Überwachen der Metriken und Lösungen, die diese Metriken auch verarbeiten, unterschieden werden. Zum Messen der Applikations-Performance bietet der Markt eine Vielzahl von Produkten. Der „Peer Insights“ von Gartner in der Kategorie APM enthält allein ungefähr 25 Produkte.

Die Software-Lösungen sind dabei häufig in unterschiedliche Pakete unterteilt, die jeweils nur eine bestimmte Funktionalität abdecken. Darüber hinaus setzen die Hersteller auf verschiedene Messmethoden und -technologien. Um aber eine Gesamtlösung zu erhalten, müssen diese Einzelprodukte zu einem „Bundle“ zusammengefasst werden. Problem in der Praxis: Häufig arbeiten die Programme nur mit Systemen des gleichen Herstellers zusammen.

Auch für die Auswertung der erfassten Metriken gibt es auf dem Markt mittlerweile eine ganze Reihe von Lösungen.  Diese werden in der Regel unter der Kategorie IT-Servicemanagement (ITSM) geführt, ein direkter Vergleich dieser Lösungen istallerdings häufig nicht möglich. Der Grund: Die Lösungen sind aus einer Kombination aus Hard- und Softwareverwaltungsprogramme sowie Help-Desk-Tools entstanden und damit kaum vergleichbar. Darüber hinaus wird die Definition, was ITSM genau ist, von sehr differenzierten Begriffserklärungen und Sichtweisen beeinflusst.

Deshalb mein Tipp: Eine spezifische Marktevaluierung sollte immer auf der Grundlage eines individuellen Anwendungsfalles erfolgen.

Das SLM-Toolset der amasol AG

Als naheliegenden Anwendungsfall aus der Praxis möchte ich zum Abschluss kurz zwei SLM-Lösungen vorstellen, die bei der amasol AG im Portfolio sind und für meine Arbeit zu Einsatz kamen:

Dynatrace Managed diente als Monitoring- Lösung und zeichnete Messdaten der amasol -Anwenderaktionen durch Real User Monitoring auf. Zusätzlich wurden auch synthetische Messwerte von externen Messstationen des Herstellers einbezogen. So konnte ich die Kennzahlen „optische Vollständigkeit“ und „Verfügbarkeit“ eines amsaol-internen Service messen.

Apptio Digital Fuel ITBM wurde für die Abbildung der Metriken verwendet. Die Messdaten aus Dynatrace wurden über eine Schnittstelle an ITBM angebunden und anschließend systematisch verarbeitet und aufbereitet. Damit wurde exemplarisch die SLA-Tauglichkeit der Metriken nachgewiesen.

Falls Sie Fragen zu den hier vorgestellten Produkten haben oder weitere Informationen benötigen, stehen Ihnen meine Kollegen jederzeit gerne zur Verfügung.

Damit endet die Beitragsserie zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“. Ich hoffe, ich konnte Ihnen einige interessante Denkanstöße zum Thema Service Level Management vermitteln.

Wenn Sie sich mit mir über die Inhalte meiner Arbeit oder das Thema Service Level Management austauschen möchten, erreichen Sie mich unter dominik.hecker(at)amasol.de.

]]>
news-18 Sun, 23 Aug 2020 13:09:00 +0000 Von der Messzahl zur Beurteilung der Performance: Ansatz eines Konzepts zur Beurteilung der Anwendungs-Performance https://www.amasol.de/blog/detail-page/von-der-messzahl-zur-beurteilung-der-performance-ansatz-eines-konzepts-zur-beurteilung-der-anwendungs-performance-1 Im dritten Beitrag der Reihe zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ werde ich nun konkret auf einige zentrale Aspekte bei der Performance-Bewertung eingehen. Im dritten Beitrag der Reihe zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ werde ich nun konkret auf einige zentrale Aspekte bei der Performance-Bewertung eingehen.

Damit wird auch ein logischer nächster Schritt von einer rein theoretischen Betrachtung und Definition der Begriffe Kennzahlen und Metriken hin zu einem in der Praxis umsetzbaren Konzept zur Beurteilung der Anwendungs-Performance vollzogen.

Verfügbarkeit, optische Vollständigkeit und Geschwindigkeitsindex als zentrale Aspekte der Performance-Bewertung

Betrachtet man die Bewertung der Anwendungsperformance aus Anwendersicht, so spielen die Kennzahlen „Verfügbarkeit“ und „Antwortzeit“ in teilweise verschiedenen Ausprägungen eine zentrale Rolle. Aus diesem Grund standen diese  Kennzahlen und Metriken auch im Mittelpunkt meiner Arbeit. Im Rahmen dieses Beitrags möchte ich insbesondere auf die Kennzahlen „Verfügbarkeit“, „optische Vollständigkeit“ und „Geschwindigkeitsindex“ eingehen.

Verfügbarkeit

Die Verfügbarkeit eines IT-Services ist in der Regel die wichtigste Kennzahl, mit der sich die Leistungsfähigkeit einer Applikation bewerten lässt. Dies liegt schon allein daran, dass eine Anwendung dem Nutzer nur während dieser Zeit zur Verfügung steht. Darüber hinaus wirkt sich eine Nichtverfügbarkeit der Applikation auch automatisch negativ auf alle anderen Kennzahlen aus.
Um die Verfügbarkeit einer Anwendung zu bestimmen, wird das sogenannte Approximationsverfahren eingesetzt. Dieses Verfahren versucht, in sechs aufeinanderfolgenden Arbeitsschritten einen Näherungswert für die Verfügbarkeit zu ermitteln. Dazu werden die verfügbaren Rohdaten (unverarbeitete und nicht ausgewertete Daten) sequenziell analysiert und aufgearbeitet, bis der Kennzahl eine qualitativ hochwertige Beweiskraft attestiert werden kann.

Der Service-Provider ist mit diesem Verfahren in der Lage, die Verfügbarkeit von Anwendungen zur Bewertung im SLA unter Berücksichtigung technischer und organisatorischer Aspekte darzustellen.Einzige Einschränkung: Die Perspektive eines einzelnen Endanwenders kann nicht vollumfänglich berücksichtigt werden, denn die Messdaten basieren primär auf synthetischen Transaktionen, die von Applikationsrobotern ausgeführt werden. Allerdings fließen im Rahmen der Approximation Störungsmeldungen zur Nichtverfügbarkeit von Anwendern ein, sodass die Metrik als solide Bewertungsgrundlage für die Applikationsverfügbarkeit verwendet und deshalb auch in den SLAs im Geschäftsbetrieb berücksichtigt werden kann.

Optische Vollständigkeit

Die optische Vollständigkeit (OV) einer Web-Anwendung ist generell ein wichtiger Teilaspekt der Antwortzeit. Aufgrund ihrer hohen Relevanz für den Endanwender habe ich sie in meiner Bachelorarbeit aber als eigene Kennzahl behandelt.

Die optische Vollständigkeit ergibt sich genau dann, wenn der Bereich der Darstellung einer Anwendung im Web-Browser verarbeitet wurde, der im optischen Ausgabegerät des Anwenders komplett angezeigt wird (vgl. nachfolgende Abbildung, weißer Bereich).

 

Geschwindigkeitsindex

Der Geschwindigkeitsindex beschreibt wiederum, wie schnell die einzelnen Elemente einer Webanwendung (Grafiken, Texte, Tabellen etc.) angezeigt werden. In Bezug auf die oben erläuterte optische Vollständigkeit macht es Sinn, auch den Geschwindigkeitsindex nicht auf die vollständig geladene Webseite, sondern eben nur auf den Bereich der optischen Vollständigkeit zu beziehen. Angegeben wird er in der Regel mit einem Prozentsatz (0 % bis 100 %) und einem zeitlichen Parameter (Millisekunden). Letztendlich gibt der Index also an, zu welchem Zeitpunkt wie viel Prozent des für den Benutzer sichtbaren Bereichs dargestellt werden. Der Geschwindigkeitsindex eignet sich darüber hinaus zum Vergleich unterschiedlicher Webseiten, wenn diese beispielsweise über dieselbe optische 
Vollständigkeit verfügen. Eine Webseite mit kleinerem Geschwindigkeitsindex bietet dann nämlich die bessere Benutzererfahrung, denn die Inhalte sind für den Benutzer schneller sichtbar.

Die „Performance-Pyramide“

Meiner Meinung nach bilden die Service-Level-Metriken für die Kennzahlen Verfügbarkeit, optische Vollständigkeit und Geschwindigkeitsindex eine solide Grundlage für die Bewertung der Anwendungsperformance in einem SLA. Die Grundlage bildet dabei die Verfügbarkeit, von der – wie bereits eingangs erwähnt – alle anderen Kennzahlen abhängig sind. Auf diesem Fundament setzt die Antwortzeit in Form der optischen Vollständigkeit und des Geschwindigkeitsindex auf. Dabei verfeinert der Geschwindigkeitsindex die Werte der optischen Vollständigkeit und stellt damit den dritten Baustein der Performance-Bewertung dar.

Soweit der dritte Teil der Beitragsserie zu meiner Bachelorarbeit, in dem ich den Ansatz eines Konzepts zur Beurteilung der Anwendungs-Performance skizziert habe. Im Mittelpunkt des vierten und letzten Beitrags der Reihe stehen das Anforderungsprofil für ein SLM-Tool und die Vorgehensweise bei der Auswahl. Wenn Sie sich mit mir über die Inhalte meiner Arbeit oder das Thema Service Level Management austauschen möchten, erreichen Sie mich unter dominik.hecker(at)amasol.de.

]]>
news-17 Sun, 16 Aug 2020 12:59:00 +0000 Kennzahlen und Metriken: Konzept und richtige Anwendung https://www.amasol.de/blog/detail-page/test-beitrag Nachdem sich mein erster Beitrag der Beitragsserie zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ mit den Grundlagen von Service Level Management (SLM) beschäftigte, stehen im zweiten Beitrag Kennzahlen und Metriken als wichtige Kriterien für die Bewertung des Leistungsnachweises von IT-Services im Mittelpunkt. Nachdem sich mein erster Beitrag der Beitragsserie zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ mit den Grundlagen von Service Level Management (SLM) beschäftigte, stehen im zweiten Beitrag Kennzahlen und Metriken als wichtige Kriterien für die Bewertung des Leistungsnachweises von IT-Services im Mittelpunkt.

Anforderungen an Kennzahlen in Bezug auf deren Aussagekraft

Bereits im Einführungsbeitrag wurde kurz auf die Bedeutung von Kennzahlen und Metriken als Instrumentarium eingegangen, mit dem im Service Level Management ein Qualitätsnachweis für die vereinbarten SLAs erbracht werden kann.

Im Folgenden geht es nun um die Anforderungen, die Kennzahlen und Metriken erfüllen müssen, damit so ein Qualitätsnachweis überhaupt möglich ist. Um aber eine Kennzahl überhaupt erst einmal mit „Leben“ zu erfüllen, werden in der Regel die folgenden vier Beschreibungskriterien definiert:

Bezeichnung: ein klarer und eindeutiger Name (z. B. durchschnittliche Antwortzeit).
Bezugsobjekt: eindeutiger Bezug auf einen IT-Service (z. B. durchschnittliche Antwortzeit des ERP-Systems).
Bezugszeit: Dabei ist sowohl die Definition eines Zeitpunkts als auch eines Zeitraums möglich. In letzterem Fall muss dann aber auch ein eindeutiges Zeitintervall angegeben werden (z. B. durchschnittliche Antwortzeit des ERP-Systems während der Geschäftszeiten).
Berechnungsweg: z. B. durchschnittliche Antwortzeit des ERP-Systems während der Geschäftszeiten = Summe aller Antwortzeiten während der Geschäftszeiten/Anzahl der Messungen.


Die Eindeutigkeit spielt bei der Definition der Beschreibungskriterien eine ganz besondere Rolle. Nur wenn diese gewährleistet ist, können Verwechslungen und Missverständnisse bei der SLA-Gestaltung ausgeschlossen werden. Darüber hinaus wird so sichergestellt, dass alle Vertragsparteien jederzeit von denselben Bemessungs- und Bewertungsgrundlagen ausgehen.

Über das reine Definieren von Kennzahlen hinaus gibt es allerdings wichtige Anforderungen, die diese Kennzahlen erfüllen müssen, um überhaupt die von den Vertragsparteien benötigte Aussagekraft zu liefern:

  • Lückenlose Beschreibung: Den „Mut zur Lücke“ darf es bei einer Kennzahl nicht geben. Neben der Eindeutigkeit spielt nämlich die Vollständigkeit bei der Beschreibung einer Kennzahl eine zentrale Rolle, denn nur so wird eine Fehlinterpretation über die Aussage und Ermittlung der Kennzahl möglich.
  • Relevanz zum Dienstleistungsnutzen: Diese Relevanz ist nur dann gegeben, wenn die Kennzahl ein Attribut mit Bedeutung für den Kundennutzen des Service beschreibt. Dieser Nutzen wiederum wird in der Regel aus dem Wertbeitrag eines Dienstes zur Unterstützung der Geschäftsprozesse des Service-Kunden bestimmt. Der Kunde muss also in der Lage sein, aus der Kennzahl einen klaren Beitrag des Service zu seinem Nutzen ableiten können.
  • Funktionaler oder proportionaler Zusammenhang zum Sachverhalt: Dieser Zusammenhang ist wichtig, denn nur dann kann bei Veränderung der Kennzahl (steigen/fallen) auch eine direkte Aussage über die Veränderung (der Qualität) der Dienstleistung getroffen werden.
  • Aussagekraft für den Anwender: Dies ist unter Umständen gar nicht so einfach, insbesondere, wenn das technische Verständnis beim Anwender fehlt oder Begriffe gewählt werden, die er schlicht nicht versteht. Ziel muss es sein, eine Kennzahl mit höchstmöglicher Aussagekraft für den Anwender zu bestimmen. In der Regel ist es dabei notwendig, dass sich der IT-Dienstleister in die Situation des Anwenders vor seinem Endgerät versetzt.
  • Beherrschbarkeit durch den Dienstleister: Klingt banal, ist aber wichtig. Denn nur wenn der Dienstleister die Entwicklung der Kennzahl vollständig beherrschen kann, macht es Sinn, diese auch in ein SLA aufzunehmen.
  • Wirtschaftlichkeit: Das Kosten-Nutzen-Verhältnis spielt wie in vielen Bereichen auch hier eine zentrale Bedeutung. Eine Kennzahl wird generell dann als wirtschaftlich angesehen, wenn der damit gewonnene Nutzen die Kosten für deren Ermittlung zumindest ausgleicht. In der Praxis zeigt sich allerdings häufig, dass dieser Nutzen nur schwer kalkulatorisch bestimmt werden kann und deshalb eine subjektive Entscheidung erforderlich ist.

Von der Kennzahl zur Metrik

Bereits im letzten Beitrag bin ich kurz auf die Definition eingegangen, dass eine Metrik als Ermittlungsverfahren der Kennzahl zu verstehen ist. Genauer ausgedrückt ist die Metrik ein Schema, nach dem sich das Ergebnis einer Kennzahl, bezogen auf den korrespondierenden IT-Service, berechnen lässt.

Und auch in Bezug auf die inhaltlichen Anforderungen an eine Metrik gibt es eine klare Definition, die aus zwei Kernkomponenten besteht:

Generische Verwendbarkeit: Eine Metrik muss möglichst allgemeingültig sein, damit sie auf eine Vielzahl von Services anwendbar ist. Hierdurch ergibt sich für einen Serviceprovider ein hoher Grad der Wiederverwendung.
Mittels logischer Operatoren beschreibbar: Um eine Abbildung der Metriken im SLM-Tool zu ermöglichen, muss die Formulierung einer Metrik mit einer Menge an technischen Operatoren möglich sein. Hierzu zählen beispielsweise Operatoren von relationalen Datenbanken zur Datenmanipulation oder Filterung von Datensätzen nach gewissen Kriterien.
Damit endet Teil 2 der Beitragsserie zu meiner Bachelorarbeit mit dem Fokus auf die wichtigen Messgrößen Kennzahl und Metrik und deren Aussagekraft.

Der nächste Beitrag wird sich damit beschäftigen, wie auf Grundlage der definierten Kennzahlen und Metriken nun eine Beurteilung der Performance erfolgen kann. Als Beispiel aus der Praxis wird dabei ein Konzept zur Beurteilung der Anwendungsperformance beschrieben.

Wenn Sie sich mit mir über die Inhalte meiner Arbeit oder das Thema Service Level Management austauschen möchten, erreichen Sie mich unter dominik.hecker(at)amasol.de

]]>
news-25 Sun, 09 Aug 2020 14:12:00 +0000 TLS 1.3 und seine Auswirkungen auf das Netzwerk-Monitoring https://www.amasol.de/blog/detail-page/tls-13-und-seine-auswirkungen-auf-das-netzwerk-monitoring Angeregt durch die Veröffentlichung der Spezifikation für die neueste Version 1.3 des Transport Layer Security (TLS)-Protokolls (RFC 8446) im August 2018 stand schnell fest, dass das Thema meiner Bachelorarbeit „Das Verschlüsselungsprotokoll TLS 1.3 und seine Auswirkungen auf das Netzwerk-Monitoring“ lauten soll. Der Fokus liegt dabei primär auf dem netzwerkbasierten Monitoring von Anwendungen, da dieses von der Umstellung auf TLS 1.3 voraussichtlich am stärksten betroffen sein wird. 
Die Ergebnisse dieser Arbeit möchte ich nun in einer dreiteiligen Beitragsreihe vorstellen.

Monitoring – ein Überblick

Zunächst habe ich mich mit den verschiedenen Möglichkeiten des Monitorings von Applikationen beschäftigt. Anwendungen werden überwacht, damit stets ihre Verfügbarkeit, aber auch eine schnelle oder sogar proaktive Behebung von auftretenden Performance-Problemen gegeben ist. Dazu gibt es drei Verfahren: das synthetische, das agentenbasierte und das netzwerkbasierte Monitoring.
Während beim synthetischen Monitoring der Datenverkehr in einem Netzwerk simuliert wird, misst beim agentenbasierten Monitoring ein im System installierter Agent den „echten“ Datenverkehr. In beiden Fällen muss ein Zugang zu den zu überwachenden Systeme bestehen („aktives Monitoring“). Hingegen benötigt das netzwerkbasierte Monitoring keinen Zugriff auf die Endpunkte der Kommunikation, da es Informationen zur Performance aus den über das Netzwerk übertragenen Datenpaketen erhält, die durch die tatsächliche Nutzung der jeweiligen Anwendung erzeugt werden („passives Monitoring“). 
Darüber hinaus kann man unterscheiden, ob das Monitoring des Traffics innerhalb eines Rechenzentrums („intern“) oder über die Grenzen eines Rechenzentrums hinweg („extern“) erfolgt, sowie ob die Überprüfung der Datenpakete am Original („inline“) oder an deren Kopie („out-of-band“) durchgeführt wird.

Warum sollten Daten verschlüsselt werden?

Neben allgemeinen Netzwerk-Metriken werden beim Monitoring auch user-spezifische Interaktionen vermessen. Dabei ist jedoch nicht auszuschließen, dass personenbezogene Daten – zum Beispiel Login-Daten – aufgezeichnet und eingesehen werden. Aus diesem Grund ist es wichtig derartige sensible Daten zu schützen. Mögliche Vorkehrungen dazu sind die Einschränkung der Sichtbarkeitsrechte auf bestimmte Nutzergruppen des jeweiligen Monitoringtools. Darüber hinaus muss man die Übertragung von Daten in Netzwerken im Allgemeinen schützen. Dies erfolgt durch die Nutzung von Verschlüsselungsprotokollen, beispielsweise mit TLS. 
Es ist nämlich möglich, dass sich ein Angreifer – ein unbefugter Dritter – auf irgendeine Weise Zugang zur Kommunikation verschafft und an sensible Daten kommt. Diese Art, sich in die Verbindung zwischen zwei kommunizierenden Endpunkten einzuschalten, nennt man „Man-in-the-Middle“-Ansatz und nutzt sie, um unter anderem als Proxy verschlüsselte Kommunikation zu überprüfen.  
Im Fall eines nicht autorisierten Eingriffs handelt es sich jedoch um einen Man-in-the-Middle-Angriff. In den letzten Jahren sind einige dieser Angriffe erfolgt, bekannt unter den Namen „POODLE“, „ROBOT“ oder „Heartbleed“, um nur einige wenige zu nennen. Aus diesem Grund ist eine Ende-zu-Ende-Verschlüsselung von Kommunikation essentiell.

Wie verschlüsselt man Daten?

Eigentlich ist es ganz einfach Daten zu chiffrieren: man wählt einen Schlüssel und wendet ihn auf den zu schützenden Datensatz an, sodass aus der dadurch entstandenen Zeichenfolge nicht auf den ursprünglichen Inhalt geschlossen werden kann. Den Schlüssel kann man sich als eine mathematische Funktion y = f(x) vorstellen und den zu verschlüsselnden Text als „x“, den man in die Funktion einsetzt. Das Ergebnis – „y“ – ist der chiffrierte Text, der an den Empfänger übermittelt wird.
Dabei gibt es jedoch zwei Herausforderungen: Wie kann man sichergehen, dass der Schlüssel auch tatsächlich sicher ist, das heißt, die Verschlüsselung nicht ohne unverhältnismäßigen Aufwand gebrochen werden kann? Und wie erhält der Empfänger den Schlüssel, um die übermittelte Nachricht lesen zu können?

Die schlechte Nachricht vorneweg: Es gibt keine absolut sicheren Schlüssel, da es immer eine Möglichkeit für den Empfänger (die „Umkehrfunktion“) geben muss, die Nachricht wieder zu entschlüsseln. Es gibt aber Möglichkeiten, die Verschlüsselungsfunktion so zu wählen, dass diese nur mit unverhältnismäßigem Aufwand erraten und umgekehrt werden kann.
Die zweite Herausforderung ist die sichere Übermittlung des Schlüssels an den Empfänger, damit dieser die an ihn gerichteten, verschlüsselten Nachrichten dechiffrieren kann. Abhilfe schafft in diesem Fall die Tatsache, dass es zwei grundlegend verschiedene Arten der Verschlüsselung gibt: symmetrische und asymmetrische Verschlüsselung, die aber auch kombiniert werden können.

Verschlüsselung    Prinzip    Vorteil    Nachteil 
Symmetrisch

Selber Schlüssel für Ver- und Entschlüsselung 

Sehr schnell       Schlüsselaustausch ist angreifbar
Asymmetrisch
(„Public- Key-
Verfahren")

- Schlüsselpaar privatem und öffentlichem Schlüssel
- Absender verschlüsselt mit öffentlichem Schlüssel
- Empfänger entschlüsselt mit privatem Schlüssel   

Sicheres Verfahren    Langsam
Hybrid
(„Pre-Shared-Key-Verfahren")    
- Asymetrische Verschlüsselung für Austausch des symmetrischen Schlüssels    
- Symmetrische Verschlüsselung für Datenaustausch
Kombinierte Vorteile beider Verfahren: sichere Schlüsselübertragung bei schnellem Datenaustausch  

 

Da es viele verschiedene Verschlüsselungsalgorithmen gibt, werden die jeweiligen Kombinationen als Cipher Suiten bezeichnet. Eine Cipher Suite legt fest, mit welchem Algorithmus welcher Teil einer Kommunikation verschlüsselt wird, und wird zu Beginn einer verschlüsselten Verbindung – zum Beispiel gesichert mit TLS – ausgehandelt.  

Was genau TLS ist und wie es funktioniert wird das Hauptthema des zweiten Teils dieser Beitragsreihe sein.

Wenn Sie sich mit mir über die Inhalte meiner Arbeit austauschen möchten, erreichen Sie mich unter olga.wall(at)amasol.de. 

 

Weiter zu Teil II: Was ist TLS 1.3? >>

]]>
news-13 Sun, 02 Aug 2020 14:49:00 +0000 Service Level Management als Grundlage für den Leistungsnachweis von IT-Services https://www.amasol.de/blog/detail-page/service-level-management-als-grundlage-fuer-den-leistungsnachweis-von-it-services Im ersten Beitrag dieser Reihe geht es zuerst einmal grundsätzlich um die Definition von Service Level Management (SLM), Service Level Agreements (SLA) als vertragliche Grundlage für SLM sowie Kennzahlen und Metriken als Bewertungsgrundlage für SLAs und SLM. „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ – so lautete der Titel der Bachelorarbeit von amasol-Consultant Dominik Hecker im Rahmen seines Studiums der Wirtschaftsinformatik an der Hochschule München. Die Arbeit unterstreicht die Bedeutung, die die Kombination von Theorie und Praxis – Kollege Hecker ist bei amasol im Technology-Business-Management-Team tätig – heute für die moderne IT hat. Grund genug, die wichtigsten Aspekte der Arbeit in einer Beitragsserie zusammenzufassen und auch auf diese Weise den Bezug von Theorie und Praxis herzustellen.

Im ersten Beitrag dieser Reihe geht es zuerst einmal grundsätzlich um die Definition von Service Level Management (SLM), Service Level Agreements (SLA) als vertragliche Grundlage für SLM sowie Kennzahlen und Metriken als Bewertungsgrundlage für SLAs und SLM.

Service Level Management: Definition

Grundsätzlich versteht man unter Service Level Management (SLM) das Lenken und Gewährleisten von Service-Erbringungen in einer zuvor vereinbarten Qualität. Mit der Entwicklung moderner IT-Abteilungen weg vom Cost Center hin zum Profit-Center hat dieser Aspekt eine immer größere Bedeutung erlangt. Aufgabe der IT-Abteilung ist es heute, für den Endanwender als „internen Kunden“ bestimmte IT-Services zu leisten. Nun geht es im Vorfeld darum, diese Leistungen konkret festzulegen (Art, Umfang, Zeit, Kosten, Qualität). Ist dies geschehen, besteht die Herausforderung für die IT nun darin, zum einen diese Leistungen in der vereinbarten Qualität zu erbringen, zum anderen nachzuweisen, dass sie die vereinbarten Dienste in der vereinbarten Qualität wirklich erbracht hat. Genau dies geschieht im Rahmen des Service Level Managements. Denn erst wenn dieser Nachweis erbracht ist, können die Leistungen auch in Rechnung gestellt werden. Darüber hinaus liefern die SLM-Ergebnisse eine wichtige Grundlage zur Optimierung der IT-Services. Die wichtigsten Ziele dabei sind:

  • Verbesserung der Anwendererfahrung (die Anwenderfokussierung ist in den vergangenen Jahren
  • in den Mittelpunkt der Betrachtung der IT-Qualität gerückt)
  •  Optimieren bzw. Senken der IT-Kosten
  • Erfüllen der IT-Governance-Vorgaben

 

SLA: Vertragliche Grundlage für SLM

Als vertragliche Grundlage für das Service Level Management dienen die sogenannten Service Level Agreements (SLA). Dominik Hecker zitiert in seiner Arbeit die gängige ITIL-Definition: “An agreement between an IT service provider and a customer. The SLA describes the IT service, documents service level targets, and specifies the responsibilities of the IT service provider and the customer. A single SLA may cover multiple IT services or multiple customers.”

Generell geht es also um die eindeutige vertragliche Regelung über eine IT-Dienstleistung und die dadurch abgeleitete Beziehung zwischen IT-Dienstleister und Service-Kunde. Ein SLA wird in der Regel in Schriftform erstellt und für einen bestimmten Zeitraum geschlossen. Dabei ist es unerheblich, ob die Vertragspartner zum selben Unternehmen (interne Kunden) oder zu unterschiedlichen Firmen (externe Kunden) gehören. 

Die wichtigsten Bestandteile eines SLAs sind
•    die genau festgelegten Verantwortlichkeiten der beiden Vertragsseiten, 
•    die Art und Weise der Kommunikation bei Notfällen und Problemeskalationen,
•    finanzielle Bonus- und Malus-Regelungen für das Einhalten bzw. das Nicht-Einhalten der vereinbarten Service Levels

Genau an dieser Stelle kommt auch wieder der eingangs erwähnte „Nachweis“-Aspekt im Service Level Management zum Tragen, denn nur wenn dieser Nachweis erbracht wird, können auch die entsprechenden Bonus-/Malus-Vereinbarungen umgesetzt werden.

Kennzahlen und Metriken als Bewertungsgrundlage für SLA und SLM

Womit wir beim letzten Thema dieses Einführungsbeitrags wären: den Kennzahlen und Metriken. Sie liefern quasi das Instrumentarium für den im Service Level Management zentralen Aspekt des Qualitätsnachweises der im SLA vereinbarten IT-Services. Zuerst einmal ist es natürlich wichtig, die beiden Begriffe zu definieren und voneinander abzugrenzen bzw. in Beziehung zu setzen. In seiner Bachelorarbeit zitiert Dominik Hecker das Oxford English Dictionary mit der Definition des Begriffs Metrik als „a system or standard of measurement“. Das deutsche Synonym „Messgröße“ definiert itwissen.info als „Messverfahren von quantifizierbaren Werten im Kontext der Informationstechnologie“.

Beim Versuch, die beiden Begriffe in Relation zu bringen, kommt Dominik Hecker zu dem Schluss, dass eine Metrik als Ermittlungsverfahren der Kennzahl zu verstehen ist. Genauer ausgedrückt, ist die Metrik ein Schema, nach dem sich das Ergebnis einer Kennzahl, bezogen auf den korrespondierenden IT-Service, berechnen lässt. Bezugnehmend auf das Thema SLM bedeutet dies, dass beispielsweise der quantifizierbare Ergebniswert der Kennzahl „Verfügbarkeit“ durch die dazugehörige Metrik berechnet werden kann. Dies erfolgt durch eine definierte Verarbeitung und Aufbereitung der gemessenen Rohdaten aus dem Monitoring-Messsystem, bis schließlich ein numerischer Wert vorhanden ist, der den Sachverhalt der Kennzahl eindeutig bestimmt.

Soweit die Einführung in das Thema Service Level Management. Die besondere Bedeutung von Kennzahlen und Metriken und insbesondere deren richtige Anwendung wird Thema des nächsten Beitrags sein.

Wenn Sie sich mit Dominik Hecker über die Inhalte seiner Arbeit oder das Thema Service Level Management austauschen möchten, erreichen Sie ihn unter dominik.hecker(at)amasol.de

]]>
news-22 Wed, 01 Jul 2020 15:09:00 +0000 Machine Learning im Bereich AIOps: Teil 1 https://www.amasol.de/blog/detail-page/machine-learning-im-bereich-aiops-teil-1 Mehr als reine „Buzzwords“: künstliche Intelligenz (KI), Machine Learning und Deep Learning – und wie diese Bereiche miteinander in Beziehung stehen.
Algorithmic IT Operations (AIOps) ist eine neue Kategorie, die ursprünglich von Gartner ins Leben gerufen wurde. Sie steht für Lösungsmodelle, die das Ziel haben, vor allem die Herausforderungen zu bewältigen, die mit dem Betrieb von Infrastrukturen der nächsten Generation verbunden sind. Gartner schätzt sogar, dass die Hälfte aller globalen Unternehmen bis 2020 AIOps aktiv einsetzen wird.

Der Kernpunkt von AIOps ist die „Algorithmik“. Diese impliziert den Einsatz von maschinellem Lernen zur Automatisierung von Aufgaben und Prozessen, die bisher menschliches Eingreifen erforderten. Echtes maschinelles Lernen für das IT Incident Management ist heute leicht verfügbar, aber es existiert nicht in jeder Herstellerlösung, die für sich beansprucht, eine AIOps-Lösung zu sein.

In einer Reihe von Blogbeiträgen werden wir im Folgenden versuchen, das Thema maschinelles Lernen im Kontext von IT Incident Management zu „entmystifizieren“.

Was sich hinter den „Buzzwords“ verbirgt

Zwei der größten „Buzzwords“, die in den letzten Jahren aus der Welt der Informatik und der Technologie-Start-ups in die Mainstream-Medien übernommen wurden, sind „Machine Learning“ und „künstliche Intelligenz“ (KI). Nehmen wir nun noch „Deep Learning“ dazu und es beginnt ein großartiges „Buzzword-Bingo“. Die drei Begriffe sind generell eng miteinander verknüpft und werden deshalb oft synonym verwendet, aber sie meinen nicht dasselbe. Wo liegt also der Unterschied?

In vielen Bereichen sind Definitionen nicht immer so klar, wie wir sie gerne hätten – sie haben unscharfe Grenzen und können sich im Laufe der Zeit ändern, je nachdem, wie sich unser Verständnis des Bereichs und unsere Fähigkeiten in diesem Bereich entwickeln. KI fällt in diese Kategorie. Die Beziehung zwischen künstlicher Intelligenz, maschinellem Lernen und Deep Learning besteht darin, dass jeder der drei Begriffe eine Spezialisierung innerhalb des anderen bezeichnet. KI deckt das breiteste Spektrum an Technologien ab, das maschinelle Lernen bezeichnet eine Reihe von Technologien innerhalb der KI und Deep Learning wiederum ist eine Spezialisierung innerhalb des maschinellen Lernens.

KI: eher künstlich oder eher intelligent

Eine der allgemeinsten Definitionen von KI, die dem Merriam-Webster-Wörterbuch entnommen wurde, lautet „die Fähigkeit einer Maschine, intelligentes menschliches Verhalten nachzuahmen“. Der Begriff „Maschine“ ist dabei wichtig, da KI nicht auf Computer beschränkt sein muss.
Eine wirklich KI-fähige Maschine erfordert eine Vielzahl von Technologien aus den verschiedensten Bereichen, wie z. B. Spracherkennung und Natural Language Processing, Computer-Bildverarbeitung, Robotik, Sensorik und natürlich eines unserer anderen „Buzzwords“, „Machine Learning“. In vielen Fällen ist das maschinelle Lernen nämlich ein Werkzeug, das von diesen anderen Technologien genutzt wird.

Schon in den Anfängen der KI stützte sie sich auf präskriptive Expertensysteme, um herauszufinden, welche Maßnahmen zu ergreifen sind, also „Wenn dies geschieht, dann tue das“. Und obwohl in einigen Bereichen präskriptive Expertensysteme noch immer ihren Platz haben, hat ihr Einfluss stark nachgelassen, denn diese Funktion wurde mittlerweile weitgehend durch maschinelles Lernen ersetzt. Die meisten Beobachter sind sich einig, dass das maschinelle Lernen heute der wichtigste Wegbereiter für leistungsfähige KI-Systeme ist.

Ein Paradebeispiel für moderne KI sind autonome Fahrzeuge. Sie verlassen sich maßgeblich auf viele verschiedene Technologien, die harmonisch ineinandergreifen müssen. Einige davon wiederum verlassen sich maßgeblich auf maschinelles Lernen und zwar insbesondere diejenigen, die es dem Auto ermöglichen, seine Umgebung zu erfassen und zu verstehen. Die heute gängigen Sprachassistenten wie Siri, Cortana, Alexa etc. verwenden eine Vielzahl von Technologien, die es ihnen ermöglichen, eine menschliche Stimme zu „hören“, um zu verstehen, welche Klänge welchen Wörtern und Phrasen entsprechen, die Bedeutung aus der Reihe von Wörtern abzuleiten, die sie gehört haben, und eine Antwort zu formulieren und entsprechend zu reagieren: alles Systeme, die mehrere Technologien – einschließlich maschinelles Lernen – erfordern.

Was ist also nun maschinelles Lernen?

Maschinelles Lernen ist ein Bereich innerhalb der Computerwissenschaften für Anwendungsformen unter dem Oberbegriff KI. Eine sehr treffende Definition stammt aus einem Kurs für maschinelles Lernen der Stanford University: „Maschinelles Lernen ist die Wissenschaft, Computer zum Handeln zu bringen, ohne explizit programmiert zu werden. Anstatt ein System mit einem ‚Wenn dies, dann jenes‘-Ansatz zu programmieren, werden in der Welt des maschinellen Lernens die Entscheidungen, die das System trifft, aus den Daten abgeleitet, die ihm übermittelt wurden.“ Manche bezeichnen dies als „Learn by example“-Ansatz, aber es steckt noch mehr dahinter.

Maschinelles Lernen ist mittlerweile so weitverbreitet, dass es zahllose Anwendungen gibt, bei denen wir vielleicht gar nicht realisieren, dass es dabei eine Rolle spielt. Automatische Systeme zur Postsortierung oder zur Geschwindigkeitsüberwachung beruhen auf unglaublich präzisen Implementierungen einer Technologie, die als „Optical Character Recognition (OCR) bekannt ist, d. h. auf dem Erkennen von Text in Bildern. Diese Technologie ermöglicht es, Adressen auf Briefumschlägen und Paketen zu erkennen oder das Nummernschild eines Fahrzeugs, das eine rote Ampel überfährt oder vor einer Schule zu schnell fährt. OCR würde aber ohne maschinelles Lernen nicht existieren (Strafzettel leider schon).

Die „Meinten Sie vielleicht …?“ oder „Ähnliche suchen“-Funktion in Suchmaschinen sowie Spam-Filtern, Gesichtserkennungssysteme und Empfehlungssysteme im E-Commerce, Video- und Musik-Streaming-Dienste – die Liste ist endlos und nicht alle dieser Anwendungen schaffen es aufgrund ihrer Öffentlichkeitswirksamkeit in die Schlagzeilen.

Überwacht und nicht überwacht

Wie in den nächsten Beiträgen dieser Reihe noch detaillierter besprochen wird, enthält maschinelles Lernen eine Vielzahl unterschiedlicher Bereiche. Dies ergänzt unsere „Buzzword“-Sammlung um zwei weitere Einträge: „Supervised (überwachtes/betreutes) Machine Learning“ und „Unsupervised (nicht überwachtes/nicht betreutes) Machine Learning“. Obwohl die beiden Begriffe fast gleich sind, unterscheiden sich die zugrunde liegenden Algorithmen und deren Anwendung doch deutlich.
Unüberwachte Techniken sind im Allgemeinen einfacher und versuchen, Muster innerhalb einer Reihe von gegebenen Beobachtungen zu finden – Muster, von denen Sie bisher überhaupt nicht wussten, dass sie existierten. Empfehlungssysteme beruhen maßgeblich auf diesen Techniken.
Dagegen verfolgt überwachtes Lernen den „Learn by example“-Ansatz. Überwachte Lernsysteme benötigen Beispiele dafür, was „gut” ist und was „schlecht“ – diese E-Mail ist Spam, diese E-Mail nicht.
Im OCR-Bereich würde das System mehrere Bilder unterschiedlicher Buchstaben zusammen mit der Information erhalten, welchen Buchstaben das jeweilige Bild repräsentiert. Da das System immer mehr Beispiele erhält, „lernt“ es, wie es zwischen einer Spam-E-Mail und einer Nicht-Spam-E-Mail unterscheiden kann, es lernt die verschiedenen Anordnungen von Pixeln, die denselben Buchstaben und Zahlen entsprechen. Als Folge kann das System dann, wenn ihm ein neues Beispiel, insbesondere ein noch nicht bekanntes Beispiel, gezeigt wird, richtig erkennen, ob die E-Mail Spam ist oder nicht. Oder es erkennt die Adresse, an die der Brief geschickt werden muss, oder das Kennzeichen des zu schnell fahrenden Autos.

Neuronale Netze

Im Bereich des betreuten Lernens gibt es zahlreiche Techniken, darunter eine Technik namens „neuronale Netze“. Neuronale Netze sind Softwaresysteme, die versuchen, – wenn auch sehr grob – die Funktionsweise eines menschlichen Gehirns nachzuahmen. Das Konzept des neuronalen Netzes gibt es schon seit mehreren Jahrzehnten, seine wahre Stärke wurde aber erst vor relativ kurzer Zeit erkannt. Ein neuronales Netz besteht aus künstlichen Neuronen, die alle miteinander verbunden sind. Werden dem Netz verschiedene Trainingsbeispiele (z. B. ein Bild oder eine E-Mail) gemeinsam mit dem erwarteten Ergebnis des Systems (z. B. ein Buchstabe auf dem Bild oder ob es sich um eine Spam-E-Mail oder nicht handelt) gezeigt, ermittelt das Netzwerk, welche Neuronen es aktivieren muss, um unter verschiedenen Umständen die gewünschte Ausgabe zu erzielen. Das Netz weiß also, wie es sich konfigurieren muss, damit andere Neuronen aktiviert werden, wenn eine Spam-E-Mail gezeigt wird, im Gegensatz zum Fall, dass keine Spam-E-Mail gezeigt wird. Der Rest des Systems kann dann eine Entscheidung treffen, wie mit dieser E-Mail umzugehen ist.

Kommen wir nun zu unserem letzten „Buzzword“ (zumindest vorläufig) – dem „Deep Learning“. Deep Learning ist ein sehr spezifischer und äußerst spannender Bereich innerhalb neuronaler Netze.
Am einfachsten stellt man sich ein Deep-Learning-Netzwerk als ein größeres und komplexeres Netzwerk mit komplexeren und ausgeklügelteren Interaktionen zwischen den einzelnen Knoten vor. Der Begriff „Schichten“ wird häufig im Bereich der neuronalen Netze verwendet und erstaunliche Ergebnisse lassen sich bereits mit Netzwerken erzielen, die nur aus einer einzigen Schicht bestehen. Deep Learning verwendet mehrere „Schichten“ mit komplexen Wechselwirkungen innerhalb jeder Schicht und zwischen den Schichten. Folglich sind die Muster, die es identifizieren kann, und die Probleme, auf die es angewendet werden kann, auch komplexer.
Deep Learning steht an der Spitze der Forschung zum maschinellen Lernen und einige der Fortschritte in diesem Bereich haben zu Technologien wie automatischer Übersetzung, automatischer Generierung von Bildunterschriften und automatischer Textgenerierung (z. B. automatische Textgenerierung im Stil von Shakespeare) geführt. Und so wie das maschinelle Lernen der Hauptmotor der künstlichen Intelligenz ist, ist das Deep Learning im Moment der Hauptmotor für Fortschritte im maschinellen Lernen.

Coming up next …
Der nächste Beitrag liefert eine Einführung in die verschiedenen maschinellen Lerntechniken, APIs und Frameworks, die heute für das IT Incident Management verfügbar sind.
 

]]>
ITOA
news-23 Tue, 16 Jun 2020 15:17:00 +0000 Monitoring als strategische Entscheidung https://www.amasol.de/blog/detail-page/monitoring-als-strategische-entscheidung Dass es in einer Unternehmens-IT nicht nur „das eine“ Monitoring-Tool gibt, ist selbst einem Neuling bereits nach wenigen Tagen im Unternehmen bewusst. Da gibt es Alarmkonsolen, Infrastrukturüberwachung, OpenSource- und Herstellertools, Applikationsmonitoring, Log-Analysen u. v. a. m. Die meisten IT-Verantwortlichen haben längst den Überblick verloren, welche Tools in welchem Team vorhanden sind, wie und wie oft sie genutzt werden oder ob es irgendwo noch Lücken gibt. 

Bewusst wahrgenommen werden Defizite im Monitoring erst, wenn es zu Ausfällen oder Beeinträchtigungen kommt und große Task-Force-Gruppen gebildet werden, die die Experten zusammenbringen sollen, um das Problem möglichst zeitnah aus der Welt zu schaffen. Dann sitzen Tool-Spezialisten und Generalisten an einem (teilweise virtuellen) Tisch und rätseln über die Ursache des aktuellen Ausfalls: Ist die Fehlermeldung in Tool A wichtig oder nicht? Woher kommt die Antwortzeitverlängerung, die in Tool B dargestellt wird, wirklich? Was passiert eigentlich im Backend, wenn der Nutzer Funktion X, die gerade Probleme macht, ausführt? Jede Stunde, die eine solche Task-Force-Gruppe für die Analyse eines Problems benötigt, kostet mehrere Tausend Euro: Nicht nur die Arbeitszeit der Spezialisten, die eigentliche andere Aufgaben hätten, sondern auch jede Stunde, in der eine Anwendung oder Funktion nicht genutzt werden konnte, kostet Geld.

In einer Studie von 2015 bezifferte AppDynamics (https://devops.com/real-cost-downtime/) die Kosten für einen kritischen Ausfall einer Anwendung bei einem Fortune-1000-Unternehmen mit 500.000 bis 1.000.000 US-Dollar pro Stunde. Selbst wenn ein Unternehmen nicht zu diesem Unternehmenskreis gehört, sind die Kosten und Verluste durch einen Ausfall der wichtigsten Anwendungen nicht zu vernachlässigen. Und jetzt stellen Sie sich einmal vor, die Task Force stellt bei einem solchen Ausfall fest, dass die Ursache in den aktuellen Tools nicht herauszufinden ist? Das gar eine Lücke in der Monitoringlandschaft vorhanden ist?

Um dieses Risiko zu minimieren, ist es wichtig, regelmäßig die Monitoringstrategie der eigenen IT zu überprüfen und gegebenenfalls auf neue Herausforderungen oder geänderte Anforderungen anzupassen. Die Entwicklung einer Monitoringstrategie gliedert sich dabei in verschiedene Phasen, die im Folgenden kurz beleuchtet werden.

Status quo

Am Anfang steht immer die Ermittlung des Status quo: Welche Tools werden aktuell wofür eingesetzt? Viele Unternehmen bauen für sich eine sogenannte Tool-Landkarte. Diese kann ganz unterschiedlich aufgebaut sein. Wichtig ist, sich bei der Erstellung Zeit zu nehmen, eine gemeinsame Kategorisierung zu entwickeln und alle relevanten Stakeholder zu befragen. 
 

Eine solche Tool-Landkarte ist kein statisches Instrument, sondern sollte im Idealfall kontinuierlich angepasst werden.

Blick in die Zukunft

Wenn die aktuelle Situation erfasst wurde, lohnt sich ein Blick in die Zukunft: Gibt es strategische Veränderungen, die auch Auswirkungen auf das Monitoring haben? Sollen beispielsweise Teile der IT-Landschaft in die Cloud verlagert oder outgesourct werden? Stehen Modernisierungsmaßnahmen an, bei der Applikationen oder Infrastruktur umgebaut werden sollen?

Solche Maßnahmen führen auch immer zu einer Änderung im Monitoringbedarf. Wenn Anwendungen in der Cloud betrieben werden, dann sind andere Ansätze für Netzwerk-, Infrastruktur- und Applikationsmonitoring notwendig, als dies in einer klassischen Architektur der Fall ist, in der Netzwerk, Server und Anwendungen vom gleichen Unternehmen betreut werden. Die Änderungen, die sich möglicherweise im Laufe der nächsten Jahre im Monitoringbedarf ergeben werden, sollten für die Bewertung der Monitoringlandschaft herangezogen werden. 

Entwicklung einer Strategie

Wenn man nun den Status quo kennt und auch die künftigen Herausforderungen für das Monitoring definiert hat, dann kann man ermitteln, welche Lücken im Monitoring vorhanden sind oder sich durch künftige Änderungen ergeben werden. Mit dieser Gap-Analyse lässt sich eine priorisierte Strategie erarbeiten, welche Änderungen in welcher Reihenfolge am aktuellen Monitoring vorgenommen werden müssen.

Mithilfe eines Konzepts aus Workshops, Fragebögen, Interviews und Branchenwissen unterstützen wir von amasol diesen Prozess. Wenn Sie Fragen zu unserem Vorgehensmodell haben oder Unterstützung bei der Entwicklung Ihrer eigenen Monitoringstrategie benötigen, kontaktieren Sie mich gerne.

]]>