Seite wählen

NETWAYS Blog

How To NWS: MyEngineer

von | Jul 19, 2021 |

MyEngineer

Heute möchte ich die Übersicht über unser NWS-Portfolio abschließen.

In den letzten Blogs habe ich all unsere technischen NWS-Dienste und deren Möglichkeiten vorgestellt. Du kannst Dir Deine passende App auf unserer Selfservice SaaS-Plattform raussuchen und direkt starten. Diese fährt automatisch hoch und ist innerhalb von weniger als fünf Minuten einsatzfähig. Auf unserer Netways Cloud based on OpenStack kannst Du Dir für Deine Projekte alle nötigen Compute-, Netzwerk und Storage-Ressourcen zusammenstellen, ohne dafür in eigene Hardware investieren zu müssen.  Und mit Kubernetes bekommen all unsere Kunden, die containerbasierte Apps einsetzten wollen, ein extrem performantes und voll gemanagtes Orchestrierungstool.

Komplettiert wird dieses ganze Angebot nun mit der letzten Säule: unserem MyEngineer Support Service.

Wer das nötige Knowhow und die Zeit hat, kann all die vorher genannten Dienste selbst über unser Portal https://my.nws.netways.de/ starten und komplett eigenständig betreiben. Eine Interaktion mit uns ist im Prinzip nicht notwendig. Es gibt aber diverse Situationen, in denen unsere Kunden gerne auf unseren MyEngineer Service zurückgreifen.

  1. Fokus auf die Kernaufgaben

Zum einen gibt es Unternehmen, die sich von der Last der Betreuung Ihrer Infrastruktur befreien wollen. Denn auch wenn man seine Dienste bei einem Hoster betreibt, müssen diese Anwendungen und die Infrastruktur drumherum ja gepflegt werden. Wer also den Kopf frei bekommen möchte, von den Problemen rund um Betrieb und Support und einfach nur eine stets einsatzfähige Anwendung nutzen möchte, der gibt die unliebsamen Arbeiten an den MyEngineer ab. Liegen für den Dienst beispielsweise Updates vor, melden sich die technischen Kollegen, sprechen die gewünschten Time-Slots ab und führen die Arbeiten dann so aus, dass der Arbeitsflow des Kunden möglichst wenig von dem Update-Prozess betroffen ist.

  1. Fehlendes Fachwissen

Der zweite Fall betrifft das umfangreiche Fachwissen, das für den Betrieb von OpenStack oder rund um die Anwendung von Kubernetes nötig ist. Beides sind hoch komplexe Themengebiete und nicht jedes Unternehmen hat die Ressourcen sich in diese tiefgreifend einzuarbeiten. Denn das bedeutet Zeit zu investieren, die die Mitarbeiter dann nicht mehr zur Verfügung haben, um sich um die Belange ihrer Kunden kümmern zu können. Das heißt aber nicht, dass diese Unternehmen die Vorteile von OpenStack und Kubernetes deswegen nicht nutzen können. Denn diese Lücken werden durch unseren MyEngineer-Service gefüllt. Wir haben in unserem Team für jeden Dienst unseres Portfolios diverse Spezialisten, die jahrelange Erfahrung gesammelt und bislang noch für jedes Problem die richtige Lösung gefunden haben. Unsere System Engineers stehen jederzeit (auch 24/7) für alle Probleme und Anliegen mit Rat und Tat zur Seite.

  1. Realisierung individueller Vorstellungen

Und zu guter Letzt kann es vorkommen, dass Du innerhalb Deiner Anwendung ein bestimmtes Feature brauchst, das bislang aber noch nicht realisiert wurde. In enger Absprache schauen wir auf Wunsch gerne, wie wir dieses Feature integrieren können. Einem unserer Kunden war es beispielsweise sehr wichtig, dass sich Mitarbeiter und Kunden auch telefonisch in ihre Jitsi-Videomeetings einwählen können. Dieses Feature gab es in Jitsi noch nicht und so machten wir uns auf die Suche. Innerhalb von kurzer Zeit konnten wir zusammen mit einen Partner die Telefoneinwahl via SIP Trunking bei unserem Kunden erfolgreich integrieren. Da unser Kunde so happy und zufrieden war, haben wir zu diesem Projekt noch eine Success Story machen können. Die gibt es hier:

https://www.netways.de/netways/kunden/thueringer-aufbaubank/

Funktionsweise

Generell funktioniert der MyEngineer folgendermaßen: Du klickst im NWS-Portal auf MyEngineer und schon bekommen wir die Info, dass Du gerne unsere Unterstützung in Anspruch nehmen möchtest. Hierbei buchst Du keine Pauschale, die dann monatlich abgerechnet wird – egal, ob Hilfe geleistet wurde oder nicht.  Nein, wir arbeiten hier auf Zuruf und nach Absprache. Du sagst uns, wo welche Unterstützung nötig ist, und wir setzen diese dann um. Das geht von der voll gemanagten Jitsi Cloud Umgebung (basierend auf OpenStack; inkl. Einrichtung, Wartung und Betrieb) bis hin zum Consulting für beispielsweise die Konzeption einer notwendigen CI-CD-Pipeline für den optimalen Einsatz von Kubernetes. Abgerechnet wird dabei stets nur die Zeit, die in Anspruch genommen wurde. Das Abrechnungsintervall beträgt 15 Minuten. Dabei kannst Du die geleisteten Stunden und die Tickets, mit den jeweiligen Absprachen, jederzeit über unser NWS-Dashboard einsehen. Das sorgt für Kostenübersicht, Transparenz und letztendlich für rundum zufriedene Kunden.  Die MyEngineers bilden somit also den wichtigsten Baustein für unser Rundum-Sorglos-Paket.

Für alle, die sich noch mal ein genaues Bild machen möchten, geht es hier zur MyEngineer-Übersicht: https://nws.netways.de/de/myengineer/

Stefan Schneider
Stefan Schneider
Account Manager
Vor seiner Zeit bei NETWAYS hat Stefan als Projektmanager in einer Nürnberger Agentur dabei geholfen, Werbeprojekte auf die Straße zu bringen. Seit Juni 2017 ist er nun stolzes Mitglied der NETWAYS-Crew. Hier war er zuerst der Ansprechpartner für unserer Schulungen und kümmert sich aktuell um alle Anfragen rund um unser Hostingangebot. Die Freizeit vertreibt sich Stefan am liebsten mit Sport. Vom Joggen über Slacklining bis zum PennyBoard fahren ist er für alles zu haben.
Lies mehr von Stefan und triff unser Team

Icinga 2 Best Practice Teil 7: "Friss oder stirb" der Variablen-Scope

von | Feb 9, 2018 |

Aus der Dokumentation kann man entnehmen das Objekte und Funktionen ihren eigene Variablen-Scope besitzen und nicht ohne weiteres auf Variablen eines „übergelagerten Scopes“ zu greifen dürfen. Sollen z.B. Objekte über eine Schleife erzeugt werden, die sich nur maginal voneinander unterscheiden, können Variablen an diese bzw. dessen Scope via use gegeben werden.

template CheckCommand "by_ssh_base" {
  import "by_ssh"
  vars.by_ssh_plugindir = PluginDir
}
var cmdlist = [ "load", ""ntp_time", "yum" ]
for (cmd in cmdlist) {
  object CheckCommand "by_ssh_" + cmd use(cmd) {
    import cmd
    vars.by_ssh_arguments = arguments
    arguments = null
    vars.by_ssh_command = "$by_ssh_plugindir$/check_" + cmd
    import "by_ssh_base"
  }
}

Gleiches Verfahren lässt sich auch für das Erzeugen von Services über eine Schleife anwenden. Hier soll sich nun jedoch die Service-Bezeichnung vom verwendenten Check-Command unterscheiden und es kommt kein Array zum Einsatz, sondern ein Dictionary. Das folgende Beispiel ist allerdings für Commands, die via command_endpoint auf einer anderen Icinga-2-Instanz aufgerufen werden.

var srvlist = {
        "load" = "load"
        "time" = "ntp_time"
        "updates" = "yum"
}
for (srv => cmd in srvlist) {
  apply Service srv use(cmd) {
    import "generic-service"
    check_command = cmd
    command_endpoint = host.name
    assign where host.vars.os == "Linux"
    ignore where host.vars.noagent
  }
}

Werden im apply-Block mehrere Variablen, z.B. im obigen Beispiel auch srv, kann use durch Komma getrennt mehrere Variablen „weiter reichen“.

Lennart Betz
Lennart Betz
Senior Consultant
Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.
Lies mehr von Lennart und triff unser Team

NETWAYS Web Services: Request Tracker

von | Sep 6, 2017 | , , , , ,

Unsere NWS-Produktfamilie ist um ein weiteres Mitglied gewachsen: Den BestPractical Request Tracker. Dies wird vor allem Kunden freuen, die zwar ein stabiles und zuverlässiges Ticketsystem nutzen möchten, sich aber nicht um die Bereitstellung von Ressourcen, die Installation sowie die Wartung kümmern möchten – denn all dies wird von unserer NETWAYS Web Services Plattform übernommen. Der Kunde selbst muss sich nur um eine Hand voll Voreinstellungen kümmern, die jedoch direkt über Webformulare an die App übergeben werden.

Diese Voreinstellungen umfassen folgende Aspekte, die der Kunde bereitstellen muss:

  • ein IMAP oder POP3 Postfach, von dem der Request Tracker Kundenmails abholt und daraus ein Ticket generiert. Dies stellt vor allem sicher, dass bestehende Mail-Adressen weiter genutzt werden können.
  • einen SMTP-Server, der den Versand der Mails aus dem Request Tracker steuert.

Des Weiteren bietet unsere App viele Möglichkeiten, den Request Tracker nach Belieben anzupassen. Kunden können nicht nur den Namen Ihres Request Trackers und Ihrer Organisation festlegen, sondern auch eine Zeitzone und eine eigene Absender-Mail-Adresse eintragen:

Auch innerhalb der App kann der Request Tracker hervorragend an Ihr Unternehmen angepasst werden. Es können nicht nur im administrativen Bereich User-Gruppen und Ticket-Queues erstellt werden, sondern auch das Erscheinungsbild des Tools individualisiert werden.
Wichtiger Hinweis: Alle Angebote bei den NETWAYS Web Services können Sie 30 Tage kostenfrei testen!

STARFACE Services – heute: STARFACE Wartungsvertrag

von | Jul 24, 2017 |

Probleme bei der Einrichtung Ihrer STARFACE Appliance? Wir helfen gerne weiter! Im NETWAYS Online Store bieten wir nun zusätzlich zu den STARFACE Telefonanlagen, STARFACE Lizenzen, STARFACE Modulen und STARFACE Updateverträgen auch die STARFACE Services an!Die Firma sysob aus Schorndorf unterstützt uns dabei. Gemeinsam haben wir einen ganzen Strauß aus Dienstleistungen gebunden: Die STARFACE Einrichtung (remote), der STARFACE Service vor Ort, die STARFACE Wartungsverträge und der STARFACE Emergency Support. Heute stelle ich den Service STARFACE Wartungsverträge vor.
STARFACE Wartungsverträge  – Hilfe, auf die Sie zählen können! 
Sie wünschen sich Unterstützung beim Betrieb Ihrer STARFACE Appliance? Es gibt Ihnen ein sicheres Gefühl zu wissen, da ist jemand, den ich im Fehlerfall erreichen kann? Prima! Unser Servicepartner wird dies gemeinsam mit Ihnen und uns angehen. Wie das geht? Ganz einfach! Erfragen Sie bitte zu Ihrer STARFACE Compact Appliance mit bis zu 20 Usern ein Angebot für den Wartungsvertrag von uns. Wir beraten Sie gerne.
 
Was ist ein Wartungsvertrag?
Der jeweilige Wartungsvertrag wird mit unserem Dienstleister auf 12 Monate abgeschlossen und ist mit einer Frist von 3 Monaten zum Vertragsende kündbar. Die Abrechnung erfolgt quartalsweise. Die angegeben AEs beziehen sich jeweils auf einen Monat. Nutzen Sie diese ganz individuell z.B. für Updates durch den Dienstleister, mögliche Fehlerbehandlungen oder Hilfe bei neuen Implementierungen. Soll heißen: Sie kaufen monatliches Kontingent ein, das Sie individuell für Ihre Bedürfnisse nutzen können. Bitte sprechen Sie uns an, falls Sie ganz konkrete To dos haben, die abgedeckt werden sollen, denn möglicherweise sind für Sie dann auch unsere weiteren STARFACE Services, wie die STARFACE Einrichtung (remote) oder der STARFACE Service vor Ort interessant.
Sie möchten sich nicht binden, aber dennoch ein ruhiges Gefühl haben? Dann sollten Sie auf folgenden STARFACE Service ein Auge werfen.
Unsere Wartungsverträge und Supportleistungen im Überblick

STARFACE Wartungsvertrag Modalitäten
STARFACE Wartungsvertrag Compact bis 20 User Laufzeit: 12 Monate; 4 AE* zu den Servicezeiten** inklusive
STARFACE Wartungsvertrag Pro bis 40 User Laufzeit: 12 Monate; 7 AE zu den Servicezeiten inklusive
STARFACE Wartungsvertrag Advanced bis 80 User Laufzeit: 12 Monate; 10 AE zu den Servicezeiten inklusive
STARFACE Emergency Support individuell; Anfrage senden

Die Eckdaten des STARFACE Emergency Support auf einen Blick:

  • STARFACE Support auf Zuruf
  • Abrechnung erfolgt im AE*-Takt
  • initiale Reaktionszeit mindestens 4 Stunden innerhalb unserer Servicezeiten**
  • individuelle Hilfe durch unseren Servicepartner
  • Jetzt Anfrage versenden!

*AE= Arbeitseinheit à 15 Minuten
**Servicezeiten:  9/5 : Mo-Fr 8-17 Uhr;  4 Std. Reaktionszeit

Icinga 2 Best Practice Teil 4: Host Templates und Services

von | Feb 24, 2017 | , , ,

Heute soll es um die Strukturierung von Services und deren Zuordnungen zu Gruppen von Hosts gehen. Ein Host Template kann zur Zusammenfassung von Informationen einer Gruppe von Hosts dienen und damit mehrere unterschiedliche Services für den jeweiligen Host anziehen. Wir wollen in den folgenden Beispielen Linux Hosts überwachen. Dort neben, wie schon in Teil 3 beschrieben, der Belegung der Dateisysteme auch in Abhängigkeit in welchem Netzsegment der Host angeschlossen ist, ob die Zeit synchron zum Zeitserver läuft.

template Host "linux-host" {
  import "generic-host"
  vars.os = "Linux"
  vars.disks["disk /"] = {
    disk_partition = "/"
  }
}
apply Service "time" {
  import "generic-service"
  check_command = "ntp_time"
  command_endpoint = host_name
  assign where host.vars.os == "Linux"
}

Es gibt zwei Netze mit je eigenem Zeitserver. Um dieses abzubilden, definieren wir für jedes Netz ein eigenes Host-Template:

template Host "dmz-net" {
  vars.ntp_address = "172.16.2.99"
}
template Host "lan-net" {
  vars.ntp_address = "172.16.1.99"
}

Diese beiden Templates enthalten nur netzspezifische Informationen, in unserem Beispiel auch nur den jeweilig zuständigen Zeitserver. Der Service-Check time mit dem Plugin check_ntp_time ermittelt die Differenz zwischen der lokalen Zeit des Hosts und der Zeit des NTP-Servers, der in ntp_address angegeben ist. Nun müssen wir für einen Host im internen Netzwerk lan-net nur noch beide Templates zusammen bringen:

object Host "host.example.org" {
  import "linux-host"
  import "lan-net"
  import "postgres-dbms"
  address = "172.16.1.11"
}

Habe wir weitere Services, die abhängig vom Netzsegment unterschiedlich zu konfigurieren sind, können diese Informationen den Netz-Templates hinzugefügt werden. Ein weiteres Beispiel wäre hier die Überwachung unterschiedlicher Domain Name Services. Diese Konzept der Stapelung von Host templates kann natürlich noch weitergeführt werden, z.B. auf Applikationen wie einen Postgresql basierendes Datenbank-Management-Systems bezogen. Ggf. muss jedoch auf die Reihenfolge der Importe geachtet werden, wenn Werte überschrieben werden sollen.

Lennart Betz
Lennart Betz
Senior Consultant
Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.
Lies mehr von Lennart und triff unser Team

Trainings

Web Services

Events