Fehlerkultur – Das Fundament für Innovation

Wer ab und an mal einen DevOpsDays-Event besucht oder einigen Galionsfiguren bei Twitter folgt, ist vermutlich schon über den Begriff Fehlerkultur gestolpert. Der Begriff ist im Grunde nicht neu und bereits seit den 70ern beschäftigt man sich mit der positiven Auswirkung einer vorhanden Fehlerkultur.

Was bedeutet Fehlerkultur

Etwas hemdsärmelig betrachtet würde ich sagen, dass es die Art und Weise beschreibt wie ein Gruppe bzw. Firma mit gemachten Fehlern, deren Kommunikation und möglichen Konsequenzen umgeht. Sprich die Reaktion auf Fehler, unabhängig davon ob die Mitarbeiter hierarchisch darüber, daneben oder darunter stehen. Das der Umgang mit Fehlern darüber hinaus auch abhängig von realen “Kulturen”, also Europäern oder bspw. Asiaten ist, ist ein Sachverhalt auf den ich nicht eingehe. Bei einer globalen Zusammenarbeit (haben wir kaum), ist er jedoch von großer Bedeutung und findet bei großen Unternehmen und deren HR-Abteilungen auch Beachtung.

Keiner macht gerne Fehler!

Fehler zu machen und dann auch noch zuzugeben schadet unserem Selbstwertgefühl. Somit ist es erstmal vollkommen “natürlich”, dass man sich mit einem “Sorry, ich habe es verkackt!” nicht wirklich wohl fühlt. Menschen mit einem sowieso schon geringen Selbstwertgefühlt fällt es umso schwererer eigene Unzulänglichkeiten zuzugeben und es verlangt ihnen viel Überwindung und Energie ab.

Das “hochhalten” des eigenen Selbstwertgefühls ist auch Basis für eine ganz bekannte kognitive Befangenheit, der Selbstwertdienlichen Verzerrung. So projizieren wir Misserfolge nahezu automatisch auf DIE ANDEREN und Erfolge auf uns selber. Jeder wird sich bei eigenem Scheitern schon mal dabei erwischt haben den Fehler, Ursache, oder besser die Wurzel allen Übels beim Kollegen oder Chef zu suchen. Für den Perfektionisten ist es dabei besonders schwierig Fehler zuzugeben. Da er im Vergleich zu anderen viel mehr Energie in Überlegung und Umsetzung s(eines) Projekts investiert hat, trifft ihn ein Scheitern und die eigene Einsicht darüber besonders hart.

Wie man man Menschen zur Fehlerkommunikation ertüchtigen?

Mit Sicherheit gibt es kein einfaches Erfolgsrezept um Menschen zur Kommunikation von Fehlern zu motivieren, aber es gibt durchaus einiges was mit im Team und Unternehmen dafür tun kann:

  • Gebt selbst Fehler zu
    Das bedeutet natürlich erstmal sich selbst zu überwinden und sich eigene Schwächen zuzugestehen. Persönlich ist mir dass vor vielen Jahren unglaublich schwer gefallen und ich war eher motiviert in tagelanger Nachtarbeit die gemachten Fehler zu “verschleiern”. Heute fällt es mir wesentlich leichter vor Kollegen und Mitarbeitern die eigenen Unzulänglichkeiten zuzugeben. Die Menschen um uns rum haben darüber hinaus meist eh ein besseres Gefühl darüber, als wir Ihnen zutrauen und die klassische Schuldverschiebung schwächt einen über die Zeit mehr als sie einem guttut. Vor einigen Tagen wurde ich bei einem Vortrag in Amsterdam gefragt “Gibt es Ding die Du heute anders machen würdest?”. Meine Antwort darauf: “Kann ich Dir eine Excel-Liste schicken?”
  • Versucht Probleme in der Gruppe zu analysieren
    Einer einzelnen Person fällt es aus genannten Gründen immer schwer die eigenen Unzulänglichkeiten zuzugeben. In der Gruppe verschwindet die Angst häufig und das Empfinden die Fehlerkonsequenz auch gemeinsam zu schultern nimmt dem Einzelnen den Druck. Klar ist, dass auch in der Gruppe jemand den Anfang machen muss, aber hat sich so ein Vorgehen einmal etabliert findet sich der- oder diejenige immer leichter.
  • Entwickeln sie Empathie und zeigen sie diese auch
    Das klingt jetzt natürlich einfacher als es ist, aber einige Denkmuster kann man sich schon zurechtlegen. Es ist wichtig anderen das Gefühl zu geben, das Fehler unabdingbar sind. Ist ein Fehler Resultat eines neuen Ansatzes oder des Versuchs Dinge zu verbessern, sollte man natürlich trotzdem kritisch über den Fehler sprechen. Umso mehr dann aber auch das Bestreben nach dem nächsten Versuch unterstützen und die Angst vor Fehlern nehmen.
    Aus der eigenen Perspektive ist es darüber hinaus wichtig, die eigene Unzufriedenheit über eine Situation zu äußern. Auch wenn Fehler gemacht werden und gemacht werden sollen, haben mögliche Fehlerauswirkungen auch Konsequenzen. Diese müssen den Beteiligen Personen dann aber auch klar sein und kommuniziert werden. Der Grat zwischen “Mach nichts falsch, denn sonst kostet es viel Geld” und “Versuch doch mal was Neues” ist definitiv schwierig, aber sonst könnte es ja jeder

Was bringt das alles?

Ich denke es ist wichtig sich selbst und auch allen anderen immer wieder klar zu machen, dass es ohne Fehler keine Innovation gibt. Wenn Menschen Angst vor dem Eingeständnis haben, sich in der Gruppe unwohl fühlen und der Chef sie im Meeting zusammenfaltet werden sie in der Regel alles tun um Fehler zu vermeiden. Ergo machen sie es wie “immer” und so bleibt eben dann auch alles wie es ist. Ich bezweifle stark, dass man eine solche Kultur einfach nur ein Meeting erzeugen kann, aber daran zu arbeiten und sich mögliche Konsequenzen vor Augen zu halten ist eine wichtige Selbstreflektion.

An mir selbst merke ich immer wieder, dass ich kein Problem mit einem Fehlerzugeständnis oder der Tatsache das etwas nicht funktioniert hat, habe.  Grantig macht es mich aber, wenn ich das unter den Teppich gekehrte dann doch herausbekomme ohne das es mir gesagt wird.

Und ich gehe gleich noch mit gutem Beispiel voran, der Blogpost sollte eigentlich um 11:00 raus. Ich habs verkackt! 🙂

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

Wie politisch darf, soll oder muss eine Firma sein?

Das ist eine Frage die mich seit einigen Wochen beschäftigt und mich nicht mehr loslässt. Der politische Umbruch den wir derzeit erleben, ist auch bei uns jeden Tag Gegenstand von Diskussionen und dafür bin ich auch dankbar. Bereits zweimal habe ich deshalb versucht meine Gedanken in Worte zu fassen, den Entwurf aber dann jedes Mal wieder verworfen.

Natürlich verzichten Firmen in der Regel nicht ohne Grund auf jede Art von politischer Positionierung. Geht es doch bei jeglicher Außendarstellung grundsätzlich darum, das Produkt, die Marke oder schlicht sich selbst in das richtige Licht zu setzen. Die Angst, dass jede noch so feine politische Nuance oder Aussage einen potentiellen Käufer vergrault ist viel zu groß. Und einen Kunden zu verlieren ist das Letzte was ein Unternehmen im Schilde führen kann. Wäre es dann eigentlich nicht viel einfacher und schlauer das Thema auszublenden, wenn es viel zu verlieren, aber kaum etwas zu gewinnen gibt?

Vielleicht. Aber jetzt wird es dennoch politisch. Warum?

Eigentlich kann ich es auf einen bestimmten Artikel von Sascha Lobo zurückführen, der mich vor einigen Wochen, aufgrund des nachfolgenden Gedankenexperiments, fasziniert hat. Er schreibt:

Wenn sich einhundert Menschen versammeln, und ein paar sind darunter, die murmeln Nazi-Zeug – das macht die restlichen 95 nicht zu Nazis. Aber wenn diese paar zum Beispiel anfangen würden, sichtbar Hakenkreuz-Fahnen zu hissen, dann kommt ein essenzieller Moment: Wie gehen die 95 mit den fünfen um? Akzeptiert die große Mehrheit diese Symbole unwidersprochen? Bleiben die fünf Teil der Gruppe? Ab einem bestimmten Punkt steht eine gehisste Fahne nicht mehr nur für die fünf, sondern kann oder muss als Absichtserklärung der gesamten Gruppe verstanden werden. So funktioniert politische Gruppendynamik: über Zustimmung, Schweigen und Abgrenzung. Und es gibt einen Moment, da wird Schweigen zur Zustimmung. Als würde man ohne Protest einer Fahne hinterherlaufen.

Genau die angesprochenen 95 Prozent machen mich nachdenklich und beantworten die anfangs des Kapitels gestellte Frage. Daß ein Schweigen in einer so wichtigen Angelegenheit zur Zustimmung wird, kann nicht in meinem, aber auch nicht unserem (NETWAYS) Interesse sein. Unsere Wertevorstellung zu verteidigen ist es mit Sicherheit wert, und somit sind wir letztendlich mindestens uns selbst schuldig die Komfortzone zu verlassen.

Eine Meinung haben reicht nicht aus

Jetzt nehmen wir digitalen Menschen ja immer für uns in Anspruch bestens aufgeklärt zu sein und natürlich beteiligen wir uns auch rege an der politischen Diskussion. Auch die Annahme, dass wir alle politikfaul geworden sind, stimmt nachgewiesenermaßen nicht.

Aber ist ein “Like“, “Fav“, “Retweet“ oder “Comment“ wirklich genug? Natürlich nicht, aber es ist eben unglaublich bequem. Warum auch nicht seinen politischen Gerechtigkeitssinn mit einem Facebook-Kommentar beruhigen. Macht schließlich nicht viel Arbeit, das eigene Gewissen ist beruhigt und die Zustimmung meiner Freunde tut letztendlich auch gut.

Problem dabei ist nur, dass wir uns in einer digitalen Blase befinden. Rekapituliere ich meine eigene Twitter-und Facebook-Timeline bin ich von Sozis, Freunden und ausschließlich lieben Menschen umgeben. Logisch eigentlich, denn alles was mich nicht interessiert blende ich bewußt oder unterbewußt aus und dann wird es in Summe eigentlich ganz erträglich. Und mal ehrlich, von Zustimmung umgeben zu sein ist einfach schlichtweg angenehmer als im Kreise permanenter Konfrontation.

Habt ihr Euch schon einmal dabei erwischt, wir ihr einen, sagen wir mal streitbaren Kommentar eines Bekannten oder Freundes gelesen habt? Der innere moralische Kompass fordert einen eigentlich wieder dazu auf, eine bestimmte Aussage nicht stehen zu lassen. Die Furcht, dass Fakten sowieso ignoriert werden und am Ende eine Partei beleidigt zurück bleibt hält uns dann am Ende von der eigenen Meinungsäußerung ab. Fazit: Eine wirkliche Auseinandersetzung findet kaum noch statt.

Orte wie einen Stammtisch, der Plattform für Streit und am Ende des Abends vielleicht sogar Konsens war, gibt es heute so kaum mehr. So schweigen wir, schalten das Smartphone ab, klappen den Computer zu oder knipsen den Fernseher aus. Irgendjemand wird es schon richten. Bloß keinen Ärger heraufbeschwören.

Was hat das mit NETWAYS zu tun

Wir haben jeden Tag mit Kunden, Kollegen, Lieferanten und somit hunderten von Menschen zu tun. Das ist ein Privileg für das wir sehr dankbar sind und mit diesem Blog haben wir zudem einen Kanal der es möglich macht öffentlich Stellung zu nehmen. Auch wenn Schweigen sicher einfacher wäre, bin ich – genau wie Lobo – fest davon überzeugt, dass es nicht richtig ist.

Wenn ich sehe, dass eine Partei wie die AfD nur schwer in der Lage ist, Herrn Höcke nach seiner Rede in Dresden am 17.01.2017 aus der Partei zu werfen, jedoch bei der aktuellen Sonntagsfrage 9% der Wähler für sich verbuchen kann; ja dann haben die restlichen 91%, also wir alle, das erst möglich gemacht.

Genau dann wird Schweigen zur Zustimmung und das kann, will und darf ich nicht zulassen. Die Wahrscheinlichkeit, dass mir der Post negativ auf die Füße fällt ist zwar wesentlich größer als die Chance den Umsatz zu steigern, aber das ist es mir wert.

Denn ein menschenverachtendes Weltbild ist das, für das wir als NETWAYS nicht stehen können und wollen. Hier arbeiten Menschen unterschiedlichster Herkunft und Kultur jeden Tag zusammen und genau diese Unterschiede spielen in der täglichen Arbeit überhaupt keine Rolle. Wir arbeiten, feiern, trinken und manchmal streiten wir auch, aber die gemeinsame Leidenschaft für das was wir tun verbindet uns.

In kleinen und großen Gruppen sind wir auf der ganzen Welt und in unterschiedlichsten Kulturkreisen unterwegs. Die Vorbehaltlosigkeit und das Interesse, welches uns überall entgegengebracht wird, hat auch jeder andere verdient. Und dafür stehen wir als Open Source Company in besonderem Maße.

Was hat das mit Euch zu tun?

Ich möchte jeden animieren sich aktiv für das einzusetzen woran er glaubt und was ihm am Herzen liegt. Vielleicht ist es manchmal schwierig, aber wir müssen auch im realen Leben wieder mehr für das einstehen was uns wichtig ist. Genauso wichtig ist es uns, daß ihr wisst für was wir stehen und was uns wichtig ist. Vielleicht kann nicht jeder unsere Meinung teilen oder das Bedürfnis sie mitzuteilen nachvollziehen, aber wenn sie jemanden inspiriert, so freut uns das.

Fazit

Wir akzeptieren nahezu bei jeder Veranstaltung einen “Code of Conduct“ und widersprechen somit jeglicher Diffamierung, Ausgrenzung und Beleidigung. Das ist wichtig und richtig, muss aber auch außerhalb der heilen Konferenzwelt Bestand haben. Nur jammern zählt nicht und gerade deshalb liegt es an uns allen, die behagliche Ecke hinter dem Computer zu verlassen und auch im echten Leben wieder aktiver zu werden. Meinungen wie die von Herrn Höcke dürfen nicht toleriert und durch Schweigen salonfähig gemacht werden.

Gerade in Zeiten wie diesen ist es umso wichtiger dies auch klar zu stellen. Und darum muss auch eine Firma manchmal politisch sein.

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

Icinga, Nagios, Naemon, OMD, Check_MK, Op5 oder Shinken – Teil II

Einen Vergleich der oben genannten Tools hatte ich vor fast drei Jahren einmal gemacht. Seitdem ist viel passiert (SPOILER-ALARM: Nicht bei allen) und ich dachte es wäre mal wieder an der Zeit für ein heiteres Core-Bashing. Ich mache aber keinen Feature-Vergleich, um festzustellen, wer mehr Checks in der Minute ausführen kann. Es geht mir mehr um die Agilität und die strategische Ausrichtung des Projekts. Und in den nächsten Tagen folgt nochmal ein detaillierter Artikel zum Thema Metriken, also schon mal den Sekt kaltstellen.

Grundsätzlich versuche ich bei der Bewertung folgende Kriterien einzubeziehen:

  • Aktivität des Projekts aus Sicht der Code-Basis
  • Aktivität der Community
  • Aktuelle Roadmap und Features
  • Und last but not least, meine persönliche und rein subjektive Sicht

Da wir mit Op5 noch einen Neuen (nicht im Business, aber in der Vergleichsrunde) haben, starten wir gleich durch und fangen an mit… Shinken:

Shinken

Es mag an dem allgemeinen Trend zur veganen Ernährung liegen, aber um Shinken ist es in den letzten Monaten sehr ruhig geworden. Auf dem verlinkten GitHub-Repo ist seit Oktober letzten Jahres nichts mehr in den Master committed worden, was nicht wirklich einen guten Eindruck macht. Auch die Website ist vollkommen veraltet und das Forum scheint offline zu sein. Jetzt denkt man im ersten Moment, das Ding ist komplett tot, aber auf Shinken Enterprise hat man zumindest die Jahreszahl im Footer aktualisiert und es wird hier auch gearbeitet.

Eine Roadmap habe ich auch nach längerer Recherche nicht gefunden. Ich konnte lediglich entdecken, dass Jean Gabès an einem Discovery-Tool mit dem Namen Kunai arbeitet. Vor einigen Monaten ging es in der Community etwas rund und Shinken, eigentlich ja mal als Fork von Nagios gedacht, wurde selbst geforked. Das neue Projekt nennt sich Alignak und hat bereits den Preis für den kompliziertesten Namen einer Monitoring Software gewonnen.

In Frankreich ist Shinken noch immer eine Nummer, da es im Toolkatalog der Behörden als eine Art Standard für Monitoring definiert ist. Features, Roadmap und somit der verbunden Mehrwert sind nahezu nicht ersichtlich und die Website besteht eigentlich nur aus ganz viel heißer Luft.

Mein Fazit: Es tut mir leid, Jean, aber wie bei Austern die zu lange in der Sonne standen, würde ich die Finger von Shinken lassen.

Op5

Ehrlich gesagt habe ich die Kollegen in Schweden lange aus dem Auge verloren. Erst ein paar Gespräche auf der OSMC im letzten Jahr und die Info, dass Andreas Ericsson nicht mehr dort arbeitet, haben meine Aufmerksamkeit wieder mal auf die Freunde im Norden gelenkt. Auch wenn der verwendete Core Naemon, welcher als “unabhängiges” Projekt hier nochmal ein eigenes Kapitel spendiert bekommt, nicht im GitHub von Op5 zu finden ist, wird dort sonst viel gemacht. Sowohl bei Ninja (dem Webinterface) also auch bei Merlin (der Datenbank und HA-Komponente) wird viel fleißig gebohrt und geschraubt.

Der eigentlich verwendete Core spielt schon seit vielen Jahren für Op5 keine große Rolle, denn als Veredler geht es ihnen vielmehr um Integration und die Erweiterung mit eigenen Add-ons und Tools. Was Neuigkeiten angeht, wird man auch bei Op5 nicht richtig fündig. Das Tech-News-Archive hat seit einigen Monaten keine Neuerung mehr gesehen und eine richtige Roadmap findet man auch nicht.

Strategisch sehe ich Op5 heute da, wo wir vor 8 Jahren hin wollten. Alle möglichen System-Management-Disziplinen aus einem Guss zu kombinieren, sodass der User nichts mehr machen muss. Die Welt hat sich aber verändert und so würde man heute eher Graylog oder den ElasticStack favorisieren, bevor man den integrierten op5 Logger verwendet. Der Naemon-Core und alle anderen Add-ons sind in hoher Qualität miteinander verbunden und der User hat mit der eigentlichen Open-Source-Software nichts zu tun. Somit ist Op5 für mich auch kein Open-Source-Tool und will es vermutlich auch nicht wirklich sein. Die kostenlose Lizenz, die eine Verwendung von 20 Geräten erlaubt, ist in meinen Augen eher ein Marketinginstrument.

Mein Fazit: Op5 Monitor ist ein solides Produkt und wer alles aus einer Box haben möchte, fährt damit mit Sicherheit besser als mit NagiosXI. Der Vorteil der vollintegrierten Lösung ist an dieser Stelle aber auch der größte Nachteil des Werkzeugs. Gerade in den Bereichen Metriken und Loghandling wird es in den nächsten Jahren um seine Bedeutung kämpfen müssen.

Check_MK

Beginnen wir das ganze Thema sachlich: Files sind nicht die Lösung für jedes Problem, NEIN, NEIN, NEIN! Somit wäre das durch und mein strategischer Kampf für die Daseinsberechtigung einer Datenbank im Bereich Monitoring wäre erledigt. Im Bereich des Source-Codes waren die Kollegen aus München schon immer sehr aktiv und so geht es auf deren Git-Repo zu wie in der Münchner S-Bahn zur Rush-Hour. Trotzdem habe ich auch bei Check_MK vergeblich versucht, eine Roadmap zu finden und wurde lediglich im Bereich des Konferenz-Archivs in den vergangenen Jahren fündig. Sollte es eine Public-Roadmap geben, freue ich mich über einen Hinweis.

Nachdem ich mich ein bisschen auf dem Demo-System umgesehen haben, konnte ich dort keine wesentlichen Neuerungen finden. Bei der Durchsicht der letzten Commits wurde jedoch klar, dass sehr viel Energie in den Support der eigenen Check_MK-Checks geht. Die massive Anzahl der integrierten Checks sind für den User mit Sicherheit komfortabel, aber auch eine Bürde für die Entwickler. Wenn man die investierte Zeit hochrechnet, dürfte das mit Sicherheit zulasten von Investition gehen.

Mein Fazit: Vor drei Jahren hatte ich folgendes geschrieben “Ehrlich gesagt glaube ich aber auch, dass Check_mk in der Zwischenzeit eher mit geschlossenen Systemen Op5 Monitor oder OpsView zu vergleichen ist”. Ich würde sagen, die Annahme hat sich vollends bestätigt. Die Dokumentation auf der Website ist gut strukturiert und detailliert, aber ansonsten kann man über Strategie und Ausrichtung fast nichts finden. Persönlich war ich darüber hinaus nie ein Fan von Auto-Discovery, da es aus meiner Sicht alles das nicht ist, was “Infrastructure as Code” sein sollte. Das Check_mk trotzdem eine große Fangemeinde kann ich nachvollziehen, aber die ist einfach heute isolierter als in der Zeit des reinen Addon-ons.

OMD

Das eigentliche OMD-Projekt scheint es in der Form nicht mehr zu geben. Die Kollegen von Check_MK haben sich aus dem Projekt offensichtlich zurückgezogen und so idled die Website, deren Ownership bei Mathias liegt, eher vor sich hin. Tot ist das Thema jedoch nicht, da sich die Freunde von Consol dem Projekt angenommen haben. Die Weiterentwicklung erfolgt auf deren GitHub-Account und somit geht es mit dem Produkt ordentlich voran. Auf einer eigenen Seite wird der Unterschied zwischen OMD von Consol und dem Legacy-OMD – das sich aus meiner Sicht erledigt hat – detailliert erläutert.

Der eingeschlagene Weg von OMD gefällt mir. Wenn ich auch mit dem gebündelten Ansatz so meine Probleme habe, bietet es eine sehr einfache Möglichkeit ein Monitoringsystem hochzuziehen. Der User hat dann immer noch die Wahl zwischen Naemon und Icinga und es gibt reichlich Innovation hinsichtlich Metriksystemen wie Graphite und Prometheus. Auch LMD, was als schnelles Bindeglied zwischen unterschiedlichen Livestatus-Cores und dem Webinterface verstanden werden darf, ist bereits mit dabei.

Eine Roadmap im klassischen Sinn konnte ich auch hier nicht finden, aber Gerhard hat erst vor einigen Wochen einen kurzen Abriss über 6 Jahre OMD gegeben. Die 45 Minuten sind mit Sicherheit gut investiert.

Mein Fazit: Wer eine gebündelte Monitoringlösung sucht und auf Open Source wert legt, sollte sowohl von Check_MK als auch von Op5 die Finger lassen. Hier empfiehlt sich der Einsatz von OMD. Die Kollegen sind seit vielen Jahren im Bereich Monitoring aktiv, wissen worauf es ankommt und verweilen nicht auf dem Status Quo.

Naemon

Naemon ist letztendlich ja das Ergebnis eines frustrierten Andreas, der von den Nagios-Freunden kurz nachdem er Nagios 4 fertig gestellt hatte, aus dem Projekt gekegelt wurde. Warum genau Nagios Enterprises den Bruch mit Andreas vollzogen hat, habe ich erst von zwei Jahren auf der PuppetConf erfahren, hier wird es jedoch leider nicht landen.

Auf dem GitHub-Repo gibt es durchaus Aktivität und erst vor zwei Tagen ist mit Version 1.0.6 ein neues Release erschienen. Das Projekt wird in den letzten Jahren eigentlich ausschließlich von Sven Nierlein am Leben gehalten und ist laut meinem Kenntnisstand auch der bevorzugte Core in OMD. Laut Website gab es in den letzten Monaten keine großen Features sondern lediglich Bugfixes.

Für das Projekt wäre es mit Sicherheit schön, wenn es mehr Contributors hätte. Ich weiss wie anstrengend der “Betrieb” eines solchen Projekts ist und zolle hier Sven Respekt, dass er das Ding weiter in Bewegung hält. Um ehrlich zu sein, sieht es jedoch im Moment für mich nicht so aus, als ob da die Post abgeht.

Mein Fazit: Wer mit dem Funktionsumfang von Nagios zufrieden ist, aber a) mit “denen” nichts zu tun haben will und b) auch Livestatus gleich fertig mit dabei haben will, ist mit Naemon gut bedient. Auch wenn nicht viele Features dazu kommen, wird das Projekt am Leben gehalten und das reicht für ein “eingefrorenes” Featureset vollkommen aus.

Nagios

Mein Fazit: Wem Nagios reicht, soll bitte Naemon nehmen.

Icinga

Zugegeben bin ich nicht der Richtige, um Icinga objektiv zu beurteilen, da ich mit der Software und vor allem den Personen einfach zu viel zu tun habe. Aber die Aktivität des Projekts ist sicher mit Abstand konkurrenzlos. Erst vor einigen Tagen ist das Projekt weg vom privaten Redmine zu GitHub gezogen. Das in der Regel vier bis fünf Personen in Vollzeit an Icinga arbeiten ist natürlich ein Grund für die starke Aktivität.

Mit Icinga 2 haben wir mit Sicherheit die Kruste von Nagios abgelegt und gerade die Konfiguration bietet eine Vielzahl an Möglichkeiten, die es sonst in dem Bereich nicht gibt. Eine große Herausforderung stellt noch das geerbte Datenbankschema da, das in großen Umgebungen immer mal wieder Schwierigkeiten bereiten kann. Eine alternative Lösung dafür zu schaffen, welche sowohl Livedaten sehr schnell, aber auch historischen Daten sehr lange zur Verfügung stellt, ist unsere Aufgabe für 2017. Dies wird sowohl im Core als auch bei Icinga Web 2 zu einer Vielzahl von Änderungen führen und somit den Großteil unserer Zeit in Anspruch nehmen.

Strategisch positioniert sich Icinga eher gegen eine gebündelte Lösung. Das Projekt kümmert sich um Core und Web und hat im letzten Jahr seine Anstrengungen in Richtung Integrationen intensiviert. Dies schließt beispielsweise die fertige Integration für Chef und Puppet aber auch Themen wie IcingaBeats mit ein. Auch der Icinga Director, der unterschiedlichste Quellen für die Konfiguration zusammenfassen kann, erfreut sich sehr starker Beliebtheit.

Mein Fazit: Icinga ist dann das richtige Werkzeug, wenn man die am Markt befindlichen Lösungen für Metriken, Logmanagement, Konfigurationsmanagement usw. nach dem best-of-breed Ansatz kombinieren will. Der Anwender muss hier definitiv ein bisschen mehr Hand anlegen, um die unterschiedlichen Lösungen zusammenbauen, profitiert dann aber auch von der Flexibilität, die er sich damit erarbeitet hat. 

Feedback willkommen

Wie bereits angedeutet handelt es sich hierbei um eine subjektive Betrachtung und sie erhebt nicht den Anspruch auf Vollständigkeit. Sollte ich jemanden zu Unrecht falsch beurteilen oder eine Aussage nicht korrekt sein, bitte ich um einen Hinweis und werde den Post entsprechend korrigieren. Habe ich jemanden zurecht schlecht beurteilt, so muss er damit leben.

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

Warum wir uns immer zu viel vornehmen?!

Ich weiss nicht wie es euch geht, aber ich mache eigentlich täglich die Erfahrung, daß geplante Dinge nicht erledigt werden. Dies gilt sowohl für komplexe Softwareprojekte, aber auch für kleine Änderungen an bestehenden Systemen.

Klar, eine punktgenaue Zeitschätzung für größere Projekte ist nicht ganz einfach. Hat man sich im Laufe seines Arbeitslebens mal mit klassischen Methoden wie COCOMO oder Delphi-Methode beschäftigt, hat man zwar ein paar Werkzeuge die einen bei der Beschätzung und Bewertung unterstützen, trotzdem ist auch ganz viel Erfahrung, Fingerspitzengefühl und permanenter Review des Ist-Standes notwendig um den Fortschritt in einem Projekt zu messen.

An wie vielen Tagen hast Du in der letzten Woche genau das erreicht, was Du dir vorgenommen hast? (Natürlich setzt die Hypothese voraus, das Du überhaupt irgendwas zu tun hast, sonst ist es zugegeben etwas schwierig) Durchschnittlich gelingt es einem normalen Menschen nur alle 20 Tage genau das zu erreichen, was er sich vorgenommen hat. Jetzt sollte man denken das die gemachte Negativerfahrung automatisch zu einer besseren Bewertung von kommenden Aufgaben führt. Genau das ist aber häufig leider nicht der Fall.

Die Ursache, dass wir unser geplantes Tagespensum und somit auch die Gesamtaufgabe nicht in der geplanten Zeit erledigen, ist im Grunde jedoch wesentlich trivialer und spannender. Wir bewerten anstehende Aufgaben in der Regel eher nach unserem Wunschdenken und unter einer zu optimistischen Betrachtung.

Der Begriff des sogenannte  Planungsfehlschlusses (Planning Fallacy) wurde erstmals 1979 von Daniel Kahneman und Amos Tverksky in einer Veröffentlichung geprägt. Er beschreibt das wir unsere eigene Leistungsfähigkeit deutlich optimistischer und unrealistischer bewerten, als es uns nach eigenem Wissen und Erfahrung möglich wäre. Trotz besserem Wissen glauben wir letztendlich wirklich, eine acht Stunden benötigende Aufgaben an einem Tag zu erledigen. Den Fakt und Erfahrungswert, dass uns Meetings, Anrufe, Kollegen und Verwaltungstätigkeiten 20% des Tages ausradieren lassen wir dabei völlig außen vor. Jetzt sollte man denken das die gemachte Negativerfahrung automatisch zu einer besseren Bewertung von kommenden Aufgaben führt. Genau das ist aber häufig leider nicht der Fall. Ich mache es kurz:

Wir bescheissen uns täglich selbst aufs Neue

Aus diesem Muster auszubrechen ist also nicht besonders einfach, aber es gibt einige Tricks die einem das Leben leichter machen:

  • Versucht aus der Vergangenheit (Timesheets oder Zeiterfassung) zu ermitteln wieviel Nettoarbeitszeit ihr täglich zu Verfügung habt. Dies verhindert zwar nicht die gnadenlose Selbstüberschätzung, garantiert jedoch ein realistischeres Bild über das zeitlich erreichbare.
  • Reflektiert ähnliche Projekte, die bereits in der Vergangenheit zeitlich aus dem Ruder gelaufen sind. Dies erlaubt einen realistischeren Blick auf die realen Auswirkungen und Seiteneffekte in der täglichen Arbeit
  • Beschätzt Aufgaben anonym und nicht im persönlichen Gespräch. Wir haben das angeborene Bedürfnis einen guten Eindruck zu machen und das hindert uns oft an einer realistischen Betrachtung der zu erledigenden Aufgabe wenn wir dem Chef gegenüber sitzen
  • Mein persönlicher Favorit ist die Durchführung eines Pre-Mortem. Setzt Euch bei größeren Projekten einige Tage vor Beginn zusammen und stellt Euch vor, in einem Monat oder Jahr von den Scherben Eures Projektes zu sitzen, welches ihr gnadenlos an die Wand gefahren habt. Malt euch dabei aus wie es nur dazu kommen konnte und ihr werdet auf das ein oder andere Problem stoßen, dass ihr bisher nicht berücksichtigt habt.

Aus eigener Erfahrung weiss ich, dass auch das Wissen um die Planning Fallacy nicht zwingend zur Vermeidung führt. Sie führt jedoch zu Verständnis. Wie oft habt ihr schon über eine Kollegin oder Kollegen geflucht, weil er das Versprochene nicht gehalten hat oder Projekte über Monate nicht an Land gewinnen.

Vorausgesetzt sie oder er ist kein fauler Hund, lohnt es sich durchaus mal hinter die Fassade zu blicken und ein Gefühl dafür zu entwickeln, welche Einflüsse auf andere und deren Tätigkeit so einwirken. Manchmal dauert es eben. Übrigens habe ich gedacht ich schreibe diesen Blog in 30 Minuten. Hat nicht geklappt!

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

OSDC Workshops 2016

Nur noch ein paar Wochen bis zur nächsten Auflage der OSDC in Berlin. Wir freuen uns wie immer schon jetzt über das große Interesse und die spannenden Vorträge. Bereits seit einigen Jahren bieten wir sowohl vor der OSDC als auch OSMC fachspezifische Workshops an. Ziel davon ist es, in die entsprechenden Technologien etwas weiter einzusteigen. Zwar kann der eintägige Workshop keine vollwertige Schulung ersetzten, jedoch bietet er einen detaillierten Einblick. Für die diesjährigen OSDC-Workshops haben wir uns folgende Schwerpunkte gesetzt:

Advanced Graphing
Bei diesem Workshop geht es wie der Name bereits vermuten lässt um die Speicherung und Analyse von Metriken. Haben wir uns jahrelang mit RRD basierten Add-ons begnügen müssen, bieten moderne Frontends wie Grafana nun sehr flexible Anzeigemöglichkeiten. Der Hauptvorteil liegt vor allem in der Kombination unterschiedlicher Werte innerhalb eines Panels bzw. Dashboards, was sich mit RRD sehr schwierig gestaltet. Da Blerim sich seit vielen Jahren mit dem Thema beschäftigt, weiss er genau worauf es in der Praxis ankommt und der Besuch loht sich auf jeden Fall.

Docker
Zugegeben ist Docker schon ein Hype-Thema, aber nach dem anfänglichen “Das ist ja geil, ich finde bestimmt etwas was ich in einen Container stecken kann”, nimmt das Thema auch in der realen Welt immer mehr Fahrt auf. Ob bei uns im eigenen Managed-Service Betrieb oder auch beim Docker-Hosting für Kunden. Es ist auf jeden Fall eine Technologie mit der man sich beschäftigen sollte. Noch dazu scheinen die großen Mitstreiter sich langsam auch in Richtung einer gemeinsamen Spezifikation zu einigen. Das verschafft dem ganzen Thema nochmals zusätzliche Sicherheit. Sebastian, quasi unser Container-Beauftragter und Head of Managed Service, hält den Vortrag persönlich und freut sich auf Sie.

Elastic Stack
Das Thema haben wir in der Zwischenzeit schon einige male unter verschiedenen Namen angeboten. Natürlich entwickeln wir auch das Schulungsmaterial mit jedem Workshop weiter, aber das anfängliche Sammeln von Logs hat unter der Federführung von Elastic ordentlich an Fahrt aufgenommen. Gerade die angekündigten Neuerungen in Logstash 5 versprechen eine transparente Analyse des Informationsflusses und Kibana wird permanent mit neuen Auswerte-Möglichkeiten erweitert. David, der bereits im Bereich Managed Services mit Elastic Erfahrung sammeln durfte, gibt in diesem Workshop praktische Tips aus dem Consulting an sie weiter.

Ich fasse zusammen: Kaufen, Kaufen, Kaufen – Oder eben einfach anmelden. Es lohnt sich!

P.S. Sie haben sich schon für die OSDC, aber nicht für einen Workshop angemeldet? Ein verständlicher, jedoch nicht verzeihbarer Fehler. Wir biegen das wieder gerade 🙂

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.