R1: Also, Ziel des Interviews: Wir wollen herausfinden, wie Software, aber auch einschließlich Infrastructure as Code, konfiguriert wird, welche Probleme dabei auftreten, wie diese behoben werden und wo bei diesen ganzen Prozessen noch Verbesserungsbedarf besteht. Im akademischen Bereich ist halt oft nicht so klar, welche Rolle da die Konfiguration spielt, ob das irgendwie nebensächlich ist oder in der täglichen Arbeit doch ständig Probleme verursacht und es ist nämlich tatsächlich so, dass man eher in der Akademiewelt sagt, man nimmt jetzt Open-Source-Projekte—also GitHub schaut man sich da an—und so guckt man halt die Issues nach Konfigurationsproblemen oder so, aber das ist halt eventuell nicht sehr aussagekräftig. Also weil das ja (?) der Entwickler (?) zu tun hat und so weiter. Und deswegen wollen wir direkt Entwickler, Tester, DevOps und so weiter fragen, was wir (?) machen. Am Ende wollen wir noch so ein bisschen was über Teamstruktur fragen, also damit wir das so ein bisschen einordnen können. (?) Hierarchien und so weiter und (?) also Manager werden wahrscheinlich weniger mit der Konfiguration zu tun haben als Tester oder (?). Genau, dann habe ich glaube ich über den Nutzen und so weiter was gesagt und was wir damit machen, also Ziel der Forschung, ist glaube ich auch klar und dann fangen wir erstmal so ganz grob mit allgemeinen Fragen an.
In welcher Domäne arbeitest du denn hauptsächlich?
I5: Domäne ist jetzt was gemeint? Also Kundendomäne oder?
R1: Nein, also als Entwickler, also ob du jetzt Webentwicklung, Frontendentwicklung, Microservices, Backend, DevOps, Security… Testing
I5: Dann eher auf jeden Fall eher Backend aktuell. Das ist halt (?) immer ein bisschen schwierig sage ich mal, weil du da auch so Visualforce Pages und sowas machen musst. Das ist dann quasi auch Frontend. Und so ein bisschen Microservices nebendran, also auch in die Richtung DevOps und ja. Privat gucke ich mir auch mal ein bisschen Frontend an, aber das ist halt eher so… weiß ich nicht. 10 % von meiner Freizeit. Naja, also wirklich mehr in Backend und DevOps würde ich jetzt mal sagen.
R1: Okay, dann was für eine Rolle hast du in der Software-Entwicklung?
I5: Senior-Softwareentwickler wäre das.
R1: Okay, Senior-Softwareentwickler.
I5: Du meinst die Position?
R1: Genau. Richtig, ja. Projektleiter, Unterprojektleiter oder hast du auch ein Team, was du?
I5: Aktuell nicht. Hatte ich mal. Aktuell nicht. Bin ich einfach nur Teammitglied und dann.
R1: Okay. Welchen Anteil deiner täglichen Arbeit hast du mit der Softwareentwicklung oder direkt Programmierung? Was macht (?) aus?
I5: Softwareentwicklung/Programmierung ist quasi 100 % meiner Zeit. Ungefähr.
R1: Okay, dann frage ich immer so, wie ist denn die—die Frage danach ob das stimmt—wie oft bist du denn in Meetings von deiner täglichen Zeit? Scrum und so weiter gibt es ja auch noch alles.
I5: Ja, also relativ selten. Das sind, also wir sind im Scrum. Davon ist ein Meeting, wir haben ein Review und ein Planning, die sind direkt nacheinander und da geht ein Montag in zwei Wochen, also ein halber Montag in zwei Wochen drauf. Das ist so die Zeit, die man auf jeden Fall definitiv in einem Meeting sind. Ansonsten solche ad-hoc-Meetings, wenn man mal irgendwie einen Prototypen gebaut hat und man lässt die anderen da mal mit draufgucken und so. Dass mein Wissen weitergeben muss oder—JavaLand jetzt oder sowas, irgendwelche Konferenzen. Aber die reine Arbeitszeit ist aber schon, also bis auf diesen Montag in zwei Wochen, diesen halben Montag, ist es schon 100 % eigentlich Entwicklung.
R1: Wie viele Jahre Erfahrung hast du denn in der Software-Entwicklung?
I5: Naja, 11 Jahre und einen Monat oder so müssten es sein. Ungefähr.
R1: Naja, das ist schon ziemlich genau.
I5: Wenn man das Studium mitzählt, weiß ich nicht ob ihr das mitrechnen wollt oder nicht.
R1: Ja, wahrscheinlich eher professionell.
I5: Ja ja, also seit Studium, dann sind es ungefähr elf Jahre.
R1: Und wie lange arbeitest du schon in deiner Organisation?
I5: In der jetzigen Organisation ein Jahr und zwei Monate genau.
R1: Und seit wann bist du so Senior. Damit wir das so einordnen können, Senior-Softwaredeveloper.
I5: Zwei, drei Jahren würde ich sagen. Ungefähr.
R1: Okay, also letzte Frage für den allgemeinen Teil: Mit welchen Frameworks und Tools arbeitest du denn gewöhnlich?
I5: Ja, Docker definitiv. Dann Docker-Compose hauptsächlich. Ansonsten Frameworks… Ruby on Rails machen wir, habe ich viele UI-Microservices viel gemacht. Ja und ansonsten—also das ist jetzt wirklich hauptsächlich Arbeit—und ansonsten auf Arbeit noch, also das ist jetzt kein Framework, aber Heroku. Also wenn ihr denn auch solche Cloudanwendungen anspielt. Genau, wäre jetzt Heroku, Hetzner, AWS und sowas halt alles. Ansonsten Tools auch? (I: Ja) IntelliJ, Visual Studio Code und Mercurial. Datenbanken und sowas auch? (R1: Ja, (?)) Ok, MongoDB, Postgres, NGINX und ich glaube das war es schon so langsam. Also das sind jetzt so die, die mir auf Anhieb einfallen würde. Dann ANT noch. Das ist hauptsächlich Deployment von Salesforce. Ja.
R1: Ja okay, super. Dann haben wir jetzt so einen Eindruck, praktisch einen generellen. Und jetzt können wir zu den Konfigurationen übergehen. Und die erste Frage ist dann immer: Was verstehst du denn direkt unter dem Begriff Konfiguration?
I5: Naja, Konfiguration ist für mich einen Zustand in deiner Software herzustellen. Also du steuerst eigentlich durch Konfiguration steuerst du Zustände in deiner Software, ja? Also wie sie sich verhält. Ja, das war es eigentlich quasi schon. Das ist eigentlich zie—meine Definition ist eigentlich relativ kurz. Also idealerweise hast du halt ein Konfigurationsfile, du startest die Software damit und änderst diese Konfiguration eigentlich nicht wieder. Also sowas zur Laufzeit würde ich quasi nicht darunter verstehen, das wäre dann eher, weiß ich nicht, da steuert sich die Anwendung selbst und Konfiguration ist für mich immer dieser Teil, den man beim Anwerfen der Software einfach definiert und damit definiert man den Zustand der Software und wie sie sich verhalten soll und dann tut sie einfach. Und dann fasst man so eine Konfiguration quasi im laufenden Betrieb eigentlich nicht mehr an, ja? Man macht das dann halt, man konfiguriert dann halt nur wieder wenn man die Software wieder runterfährt und dann quasi wieder hochfährt. Also so in der Art würde ich es umschreiben. Also was es für mich bedeutet.
R1: Okay, in wie weit spielt denn für dich fachliche und technische Konfiguration in deiner täglichen Arbeit eine Rolle? Also kannst du das unterscheiden, was wir damit meinen fachlich und technisch?
I5: Nicht direkt. Fachlich konfiguriert… ja weiß ich jetzt nicht. Also für mich spielt halt die technische Konfiguration die maßgebliche Rolle. Dadrunter ist das bei mir halt alles auch quasi abgelegt, weil wir müssen halt ganz viele Softwarekomponenten konfigurieren. Aber was mit fachlicher Konfiguration gemeint ist.
R1: Was der Endanwender praktisch, wenn der ein Tool hat, dass du entwickelst oder dein (?) konfigurieren kann. Also ein Webshop kann halt vielleicht das Aussehen konfigurieren, Sprache und so weiter. (?) in der Fachwelt der Anwendung praktisch die Konfiguration. Und technisch wäre dann im DevOps-Bereich zum Beispiel Dockerfile.
I5: Ja, das spielt bei uns sogar eine Rolle. Also unsere Software, die wir zum Beispiel jetzt mit Salesforce bauen, die muss auch relativ stark angepasst werden durch die Nutzer. Oder halt durch ein Consulting-Team, was halt die Geschäftsprozesse des Unternehmens halt durchgeht und die müssen dann im Endeffekt, also der Endkunde muss bei uns auch recht viel konfigurieren sage ich mal, ne? Um dann die Software auch so anzupassen, dass es für ihn dann halt auch das bringt, was er möchte.
R1: (?) mit solchen Konfigurationsoptionen, die irgendwie eingebaut werden müssen in das Programm oder doch eher (?)
I5: (?) also man versucht sowas halt extrem zu vermeiden. Na also du willst halt die Software nicht sehr customizable lassen, weil du halt einen Standard willst und den willst du halt—jede Konfigurationmöglichkeit, die du einbaust bietet auch immer die Gefahr, das musst du auch alles abtesten. Das ist halt ein riesen Problem und deswegen willst du sowas eigentlich vermeiden und willst das auf jeden Fall zurückfahren, aber damit müssen wir uns auch schon ab und an auseinandersetzen. Wir müssen die Software halt so bauen, dass sie sich dann für den Endanwender leicht konfigurieren lässt und dass es halt auch Sinn ergibt, dass er da überhaupt was einstellt. Und das auch nur wenn er es muss.
R1: Okay also dann aber auch bei dir doch ist meistens die technische Konfiguration (?)
I5: Großteil doch die technischen Konfigurationen. Also diese fachliche Konfiguration betrifft uns dann erst wenn wir gewisse Sachen testen müssen, ne? Also dann müssen wir halt unsere Doku durchgehen, müssen halt gucken, was kann er einstellen, ich muss jetzt den und den Stand der Software herstellen, dann müssen wir die… auch machen. Und da betrifft es uns dann auch wieder. Fälle, wo man viel testen muss, ist dann halt auch schlecht, also wo man viel einstellen muss sage ich mal so. Das ist nicht so günstig.
R1: Wie lange denkst du denn, arbeitest du prozentual pro Woche an einer Konfiguration? Dass du da (?) Konfigurationsfiles ändern musst, Build File, das ist ja alles Konfiguration.
I5: Technisch relativ wenig. Also wenn man zum Beispiel seine Microservices hinstellt oder sowas, dann macht das halt im Idealfall ein mal und dann läuft das halt. Also da will man eher so ein stabiles System herstellen, dass man dann, dass es halt einfach läuft und dann ist es gut. Aber bei der fachlichen, also wenn man es so definiert, ist es so, dass uns das doch schon recht häufig über den Weg läuft, weil wir müssen ja die Fälle, die wir jetzt sozusagen einstellen oder ändern die Features, dann müssen wir das ja auch nachtesten. Und dann betrifft uns das schon dann auch ein bisschen, ne? Also wir müssen halt das durchtesten, was der Kunde halt auch konfigurieren kann, das müssen wir auch öfters mal machen, also das ist schon nicht zu verachten die Zeit, die du dafür verwendest.
R2: Kannst du das irgendwie abschätzen?
I5: Bauchgefühl… also ich würde mal sagen bei uns ist es mehr so, wenn du jetzt wirklich einen Fall hast, den du testest, dann, dann… weiß ich nicht, würde ich mal so 30 % der Zeit, also wenn du, jetzt also jetzt mal grob, grob gepeilt über die ganze Testzeit sage ich mal, sind da jetzt vielleicht so 30 % dabei, die—aber das ist jetzt wirklich ein ganz grobes, geschätztes Bauchgefühl—wo man halt auch wirklich Sachen einstellen muss und konfigurieren muss und so. Aber es ist schon gefühlt recht viel und es ist auch lästig sowas per Hand machen zu müssen. Es wäre halt schöner wenn man auch gleich Automatismen dabei hätte um das zu machen, aber… Jetzt würde halt noch dazu kommen, wie testet man überhaupt, und da würde ich schätzen, weiß ich nicht, so 50 % der Zeit testen wir halt auch selbst. Wir sind mehr dann so DevOps-QA-Engineer. Also wir entwickeln nicht nur, sondern wir testen das, was wir entwickelt haben, testen wir auch selber im Team. Finde ich auch wesentlich besser als wenn man halt nur entwickelt und lässt irgendwie wen anderes testen. Das ist halt immer noch… ein Beigeschmack sage ich mal. Da entsteht auch keine gute Softwarequalität meines Erachtens. Ja, aber ansonsten, ich würde mal so sagen wir testen 50 % und von den 50 % würde ich mal so sagen sind 30 % von denen ist dann, schleicht sich das konfigurieren halt mit ein. So in der Dreh.
R1: Hast du dann typischerweise mit Konfiguration von monolithischen Systemen zu tun oder eher so von Frameworks, Tools, Libraries, Infrastruktur?
I5: Das ist bei uns oft zwiegespalten. Also wir bauen halt eine neue Software-Architektur auf und da haben wir viel mit Frameworks konfigurieren, mit Container, die untereinander sich unterhalten und sowas. Das müssen wir konfigurieren. Das ist aber nur wieder, das macht man ein mal. Das ist halt relativ gering sage ich mal im Vergleich zu den ganzen anderen Sachen. Und ansonsten, was wir so testen an Fällen, das ist halt wirklich alles in so einem eher monolithischen System, wobei unsere App noch relativ klein ist. Aber du hast halt diesen Salesforce-Monolithen hast du mit dabei und dadran musst du halt quasi auch testen.
R1: Wie würdest du denn den Stellenwert oder die Wichtigkeit von Konfiguration in Software Engineering oder Softwareentwicklung sehen?
I5: Also das hat einen sehr hohen Stellenwert. Also im Prinzip, wenn du jetzt guckst, wenn du jetzt Integration Tests schreibst, dann müssen die rein theoretisch alle Kombinationen von einer möglichen Konfiguration müssten die eigentlich abbilden. Jetzt auch wenn du testest, du musst halt gucken, ja ich gehe jetzt alle Kombinationen durch. Das heißt je mehr du konfigurieren kannst, desto mehr exponentiert sich im Prinzip der Testaufwand dann auch dadran. Und das ist schon wichtig. Weil du willst ja nicht, also die zehn Kombinationen durchtesten und bei dem nächsten 210 knallt es dann einfach. Das will man nicht haben, also jetzt im Extremfall. Ja und deswegen ist das eigentlich recht wichtig, das alles mal durchkonfiguriert zu haben und auch zu testen.
R1: Also bei euch praktisch in der, wenn wir jetzt die Software nehmen, (?) ist es bei euch eher (?) Testing-Konfiguration wichtig und weniger bei der Implementierung, oder? (?)
I5: Zweigeteilt. Also bei uns ist es halt so, wir haben 100 % Testabdeckung, das heißt wir müssen eigentlich auch gucken, also das macht man halt meistens durch, erreicht man das durch Unit-Tests und versucht aber auch recht viele Entwickler Tests schreiben und da guckst du halt auch, dass du halt jeden Fall im Code, also immer wenn da eine if-Bedingung ist oder sowas, versucht du irgendwie das so hinzukriegen, dass dann immer auch die Testabdeckung da ist. Also du willst halt keine Stellen im Code haben, wo irgendwelche if-Bedingungen einfach mal nicht durchlaufen werden mit den Testfällen, die du geschrieben hast. Und deswegen, das betrifft uns in der Implementierung, sowie im Testen auch.
17:09
R1: Okay, das ist so dieser allgemeine Konfigurationsteil gewesen. Jetzt wollen wir mal so, wie man so täglich jetzt damit arbeitet und jetzt ist so die erste Frage, habt ihr wenn ihr Konfiguration von irgendwelchen Tools nehmt oder von der Infrastruktur, meinetwegen Cloud-Konfiguration oder so, habt ihr da spezielle Probleme, die das verursacht, also die Konfigurierbarkeit verursacht?
I5: Spezielle Probleme? Ja, ich würde mal sagen wenn du so ein neues Framework hinzunimmst, dann musst du erstmal gucken, was musst du überhaupt konfigurieren. Also meistens hast du das Problem, wenn jetzt irgendwas spezielles erreichen willst in dem Framework drin, musst du erstmal reingucken, musst gucken welcher Wert ist überhaupt für was verantwortlich und es müsste eigentlich irgendwo mal dokumentiert oder besser dokumentiert sein, wie man das Ding überhaupt steuern kann. Das heißt, was kannst du alles reinreichen. Wenn du zum Beispiel gute Dockerfiles hast, die funktionieren halt immer sehr abgekapselt, da ist es halt so, die listen meistens, also wenn du wirklich eine gute Dokumentation hast, listen die immer auf was kannst du für Environment-Variablen, meistens in dem Fall beschränkt sich das immer dadrauf, was kannst du reinreichen und was bewirken die. Und wenn man du halt eine schlechte Dokumentation hast, dann hast du irgendein Framework, was das halt nicht so gut auflistet, dann fehlt das halt einfach und da muss man sich dann immer reinlesen. Das macht es ein bisschen schwierig das dann zu konfigurieren. Und was auch schwierig ist, haben wir meist nicht, so ein AWS-Umfeld arbeitet oder sowas, da hast du halt auch das Problem manchmal, dass es dich einfach erschlägt von den ganzen Sachen, die da quasi möglich sind. Ich sage nur mal das Rechte-System von AWS zum Beispiel, das halt doch recht komplex ist mit diesem AEM-Modell. Und da ist es halt auch schon so, dass man sich denkt „Oh naja mein Gott, das ist halt auch dann wahrscheinlich gut dokumentiert, ne?”, aber es ist halt einfach die schiere Masse, die dich dann einfach quasi erschlägt. Da kannst du einfach zu viel einstellen sage ich mal, also das ist dann halt nicht mehr nice to use.
R1: Hast du so auch spezielle Tools oder Frameworks, wo du jetzt weißt „Oh, wenn ich das anfasse jetzt, dann gibt es Probleme”?
I5: Das weiß ich nicht. Also wenn ich jetzt, weiß ich nicht. Keine Ahnung. Also wenn du in irgendeiner Datenbank irgendwas zerfriemelst, da gibt es natürlich Kandidaten, die darfst du nicht ändern sage ich mal oder ein RAID, da gibt es auch ein paar Variablen, die sollte man nicht anfassen, aber jetzt so speziell hätte ich da jetzt nicht so große Bedenken. Es ist halt eher die Frage, was weiß man nicht. Also was mich da eher so umtreibt ist immer meistens, naja könnte ich noch irgendwas einstellen, was dann das ganze performanter macht oder so. Also ich finde es eher so problematisch die Sachen, die man eigentlich nicht weiß, was man noch eventuell tun könnte um Probleme zu lösen. Das finde ich halt immer schade eigentlich.
R1: Man hat also keinen, man weiß praktisch nicht, was der Einfluss der Konfigurationsoption auf Performance und sowas hat?
I5: Ja genau. Man weiß halt nicht, ob man noch irgendwas optimieren könnte sage ich mal. Ob es da noch irgendwelche cleveren Best-Practices gibt oder sowas. Wenn das halt besser dokumentiert wäre, dann wäre das schon schön.
R1: Was denkst du, stellt die Kombination aus mehreren Tools, wenn die zusammen (?) oder mehrere Frameworks (?) Probleme dar? Also entweder wirklich Konfigurationsfehlerfreiheit oder Probleme beim Deployen oder Testen. Also dann speziell die Kombination.
I5: Naja, grundsätzlich ist es so, je mehr du einstellen kannst, desto mehr kannst du auch kaputtmachen. Also wenn du jetzt falsche Kombination reinbringst und je mehr Konfigurationsmöglichkeiten du hast, desto höher ist auch die Kombination derer, die falsch sein könnten. Normalerweise ist es so, dass du nur wenige Kombinationen hast, wo das System dann, weiß ich nicht, fehlerfrei funktioniert. Die Wahrscheinlichkeit irgendwas fehlzukonfigurieren ist natürlich recht hoch. Und deswegen, je mehr man eigentlich so ein Tool konfigurieren kann, desto höher ist eigentlich auch die Wahrscheinlichkeit, dass du irgendwie was falsch machst. Desto höher wird eigentlich auch der Aufwand dann einzusetzen. So würde ich es grob umschreiben.22:16 Aber wenn man mal eine Konfiguration gefunden hat, dann kann das Tool durch seine Konfigurationsvielfalt natürlich auch dann genau das Problem lösen, was man eigentlich vielleicht auch lösen will und das ist vielleicht besser als so ein Tool, wo man eigentlich quasi nichts einstellen kann. Das kann man halt so irgendwie glaube ich gar nicht pauschalisieren.
R1: Hast du in deiner täglichen Arbeit durch die Kombination von Sachen (?22:40 ) Probleme direkt gehabt?
I5: Ja, also beim initialen Hochfahren von irgendwelchen Service-Architekturen klar. Also wenn man da irgendwas fehlkonfiguriert oder weiß ich nicht, wenn man einen Nginx irgendwie irgendwas falsch macht, klar das ist dann ein Problem, das muss man dann lösen. Also irgendwas funktioniert nicht, weiß ich nicht, der reicht SSL nicht weiter oder der macht das Redirect dann an der Stelle nicht. Das ist meistens dann so eine Nginx-Config-Geschichte und die muss man dann fixen, die muss man lösen und das ist schon dann quasi ein Problem, aber das ist halt auch wieder so ein initiales Problem. Wenn man das einmal gefunden hat und das läuft, dann läuft es. Dann guckt man es sich auch quasi nicht wieder an.
R1: Gibt es noch weitere—ihr habt ja jetzt nun auch viel Konfiguration hier bei euch denke ich mal, Deployment-Konfiguration, meinetwegen CI-Konfiguration und so. Wie verwaltet ihr denn die ganzen Konfigurationen? Dokumentiert ihr das? Und vielleicht auch andere (? 23:45 )
I5: Also wir haben so eine, also für die technische Konfiguration gibt es, wenn man wirklich ein Deployment macht, also man muss ja auch immer unterscheiden, ob es jetzt im Development-Mode ist, da hat man irgendwelche Passwörter drin stehen, die dann einfach im Code drinstehen oder muss dann halt gewählt werden. Also die verwaltet man nicht extra, aber für Deployments haben wir so ein Passwort-Manager-Tool, das wird dann verwendet. Da haben dann gewisse Personen einfach auch Zugriff drauf und können dann sich die Passwörter dann da rausziehen, also diese Konfigurationsenvironmentvariablen. Also die müssen dann quasi alle dort mit drin stehen. Und die sind dann halt auch auf den Servern, aber wenn das mal wegraucht, weil das ja nur Docker-Container sind, dann wäre es halt schade. Ich meine das ist dann auch ein Filesystem und so, aber man muss ja auch irgendwie dann in die Web-UI reinkommen ohne, dass man halt direkt auf den Server muss, in den Container oder halt auf dem Server auf dem Filesystem und da die ganzen Env-Dateien durchgucken muss. Also das ist dann halt schon in einem Tool drin bei uns. Ansonsten die fachliche Dokumentation, die müssen halt unsere Kunden übernehmen und da weiß ich nicht wie das bei uns im Support und Customer-Success-Team halt geregelt ist. Ob die sich dann sozusagen auch merken, was die für die Kunden eingerichtet haben, also ob es da irgendwo, das kann ich jetzt nicht sagen. Also nicht so detailliert… wie das da vonstatten geht. Aber es ist natürlich sinnvoll das zu machen, sich das irgendwo zentral zu merken und auch wenn da Änderungen passieren und so, das weiß man ja halt auch immer nicht.
R1: Jetzt hast du ja von dem Passwortmanager-Tool geredet, aber wo habt ihr denn eure, ich sage mal Dockerfiles oder (? 25:36 ) Travis, da gibt es ja gewisse Konfiguration Files, habt da ihr da irgendwie zentral oder projektweise oder
I5: Momentan ist es, bauen wir die einfach immer noch ad-hoc und wir haben eins, haben wir auch Docker Hub liegen, das ist auch private. Das ist aber, das hat nur den Grund, damit wir das in der Pipeline schneller runterladen können. Sodass wir das nicht noch mal irgendwie kompliziert bauen müssen.
R1: Also habt ihr eher das auf euren Entwicklerrechnern drauf die Configuration Files?
I5: Naja, die Configuration Files… naja, das ist halt so eine Sache. Wenn sich das ein Entwickler hochziehen will klar, dann hat er die auf… also vom Git, das ist aber nicht GitHub sondern ist Bitbucket, dann hat er die klar erstmal, aber da sind nur Dummy-Werte drin. 26:24 Das sind Werte, die kann jeder nehmen. Dann zieht man sich das lokal hoch, das wirfst du auch wieder weg. Also da ist die ganze Configuration-Geschichte ist da eigentlich quasi nicht zu beachten. Das liegt halt neben dem Docker-Compose-File und dann ist gut. Nur sobald das dann auf irgendeinen Server kommt, dann muss man sich die Konfiguration eigentlich sichern, weil die dann auch wert wird, gesichert zu werden. Und unsere Dockerfiles, die liegen auch nicht nur auf Docker Hub eins, sondern es gibt auch welche, die zum Beispiel in AWS in dieser… ACR heißt die? Ist das die ACR? Die Amazon Container Registry, ich glaube die heißt ACR, musst du mal gucken. Oder ECR glaube ich heißt die: Elastic Container Registry. Irgendwie sowas. Auf jeden Fall haben die ihre eigene Registry, das ist aber quasi auch nur ein Docker Hub. Und da liegen die eben bei uns auch Dockerfiles rum. Also die Images zu den Files.
R1: Was denkst du denn ist der größte Vorteil und der größte Nachteil an dieser Art von Verwaltung?
I5: Naja, der größte Vorteil ist, dass man erstmal überhaupt Zugriff auf die Passwörter hat und sowas. Was halt ein kleiner Nachteil ist, rein theoretisch müsste man die Passwörter automatisch auch resetten nach einer bestimmten Zeit und müsste die dann halt auch den ganzen Containern quasi zugänglich machen. Das ist noch ein bisschen Nachteil. Das müsste man halt irgendwie in die Infrastruktur halt irgendwo mit einbauen. Aber normalerweise willst du es halt auch so haben—das hat halt so einen Security-Aspekt—normalerweise willst du Konfigurationen nicht ändern. Aber du willst jetzt auch nicht, du willst die Konfiguration an dem Punkt nur ändern, weil du diesen Sicherheitsaspekt hast. Also dein Passwort womit du auf die UI kommst oder zur Datenbank, das soll ab und an einfach mal neu generiert werden. Falls es halt vielleicht doch mal irgendwie erraten wird oder so. Oder falls mal ein Mitarbeiter das Unternehmen verlassen hat und sowas. Die könnten das rein theoretisch sich abschreiben und könnten dann halt weiß ich nicht was damit machen. Und das ist schon so ein Nachteil, das müsste man halt eigentlich irgendwie mal dann in Angriff nehmen. Aber bei uns, das betrifft uns eigentlich eher so was jetzt diesen Service-Architekturgedanken angeht, noch nicht so, weil die sind quasi noch nicht live. Also da müsste man dann auch noch einen Prozess dahinterschalten, der das dann automatisch tut, aber das wäre halt auch extremer Aufwand. Also da sehe ich schon einen riesen Nachteil, das so zu machen. Den Aufwand hast du dann halt einfach, die Passwörter neu zu generieren. Das heißt du müsstest rein theoretisch, die Schwierigkeit ist, du müsstest dein Passwortverwaltungstool müsstest du mit deiner Infrastruktur dann eigentlich vernetzen, dass das automatisch passiert. Weil keiner will 100 Server durchgehen und da überall die Passwörter ändern und das dann alles in das Passwort-Tool eintragen. Das müsste man noch mal irgendwie lösen.
R1: Ja und sind bei euch jetzt wirklich nur die Passwörter wichtig, weil da gibt es ja auch IP und so, Port und all sowas… ist das für euch nicht auch wichtig, die irgendwo zu setzen richtig und zu speichern.
I5: Was gibt es noch? Ich habe das erste—
R1: Ja, IPs und Ports und so weiter von den—
I5: Achso, jajaja. Das zählt da alles mit rein. Also das ist genau das gleiche Ding, wenn du mal irgendwie so eine wechselnde IP hast für irgendeinen Service, das kann natürlich sein, gerade im Cloud-Business und so und da (? 30:08 ) mal eben ganz schnell die IP. Die ist ja dann auch dort auch mit abgespeichert bei uns.
R1: Okay, also habt ihr alles in einem Tool. Ich weiß ja nicht, ob du das, wenn du das nicht sagen darfst oder kannst,(? 30:27 ) Konfiguration speichern können… ist das ein kommerzielles Tool (? 30:31 )?
I5: Ja, das ist ein kommerzielles Tool. Das ist 1Password ist das einfach. Ist auch glaube ich ziemlich populär.
R1: Okay, ja wie kommuniziert ihr denn Konfiguration im Team, also jetzt beispielsweise ändert jetzt jemand eine IP von einem Service oder so, wie wird denn das kommuniziert?
I5: Erstmal muss der das aktualisieren in dem Tool und das ist dann in irgendeinem Vault drin und da haben verschiedene Personen drauf Zugriff, also man sollte zum Beispiel immer dann auch nur ein begrenztes Operations-Team haben, was dann—Support braucht zum Beispiel nicht Zugänge zu Servern, die weiß ich nicht, wo irgendeine Infrastruktur drauf läuft oder sowas. Das ist halt, da schränkt man halt den Personenkreis ein und derjenige, der es aktualisiert muss dann halt auch dafür Sorge tragen, dass das dann in dem Passwort-Manager sozusagen aktuell ist, dass das passt und dann ist es für alle anderen, die Zugriff dadrauf haben, ist das auch sichtbar. Das betrifft uns zum Beispiel auch, wir haben solche Developer-Orgs, das ist halt so eine richtige Salesforce-Instanz sage ich mal. Und da gibt es auch Zugriffsrechte und die sind auch in dem Tool mit drin und alle Developer haben halt Zugriff auf irgendeine Org rein theoretisch. Und die sich da auch einloggen können, da was nachtesten können und sowas. Also das wird auch hin- und hergeschickt quasi. 32:05 Das ist ja auch—das hatte ich vergessen—das ist ja auch ein riesen Konfigurationsaufwand, also das ist schon nicht ohne. Ja und das muss man halt auch aktuell halten. Also wenn du da dein Passwort änderst von deiner Org—die ist dann halt immer für ein Release gedacht—dann musst du das dann auch aktualisieren in diesem Tool. Damit andere dann auch Zugriff haben. Manche vergessen das dann einzutragen und so, dann ist es dann immer schwierig, da muss man dann immer im Source Code nochmal nachgucken im jeweiligen Branch und es sich dann da die Credentials halt rausholen, das ist dann (?32:40 ) die stehen an diversen Stellen. Das ist aber auch nichts kritisches, da kann eigentlich quasi jeder drauf. Da geht es nur darum, dass man überhaupt drauf kommt und das nutzen kann.
R1: Was denkst du denn, also im Grunde genommen kommuniziert ihr über ein Tool dann, dass ich mit Konfigurationsoptionen länger fahre(?) sozusagen. Ihr sagt denen jetzt nicht direkt Bescheid?
I5: Ne, brauchst du auch nicht. Du guckst halt immer in das Tool rein, da ist immer der aktuelle Wert drin und dann kannst du dich halt verbinden da wo du es brauchst. Oder kannst, also erreichst den Server, den du brauchst oder erhältst Zugriff auf irgendeinen—habe ich auch vergessen—wir haben noch ganz viele so Payment-Provider Testaccounts sage ich mal. Oder zu Drittanbietern, da gibt es auch etliche Accounts. Und immer wenn man sowas braucht, geht man in das Tool rein und dann sollte der aktuell sein der Wert. Also da braucht man quasi null zu kommunizieren. Man macht das dann halt einfach, man setzt das auf den aktuellen Wert oder jeder andere, der sie dann braucht, hat dann den aktuellen Wert… wenn er da reingeht und sich das rauszieht.
R1: Wie ist denn so der größte Vor- und Nachteil davon?
I5: Na, der größte Vorteil ist, man hat halt immer die aktuelle Version sage ich mal. Also von dem was man braucht. Das ist immer topaktuell. Der Nachteil ist halt, man muss halt auch wieder händisch dafür Sorge tragen, dass man das aktuelle dort einträgt. Das ist sehr wichtig. Also du musst diesen manuellen Abgleich von dieser Welt vom Passwortmanager mit der Realität, den muss mal halt irgendwie selbst prüfen. Da gibt es auch wieder keinen Automatismus oder sowas. Aber das ist auch glaube ich gewollt so, dass im Endeffekt der Mensch dann dafür verantwortlich ist, wenn du irgendwie das Passwort irgendwo änderst… reinschreibst, rausholst.
R1: Vielleicht noch, was ihr da… also ihr speichert ja vermutlich gar nicht euere Konfiguration eurer Datenbank (?34:40 ), sondern…
I5: Naja, doch. Also für so einige Server kannst du das auch direkt machen. Da gibt es auch extra Rubriken in diesen Passwortmanager-Tools, wo du sagst du willst jetzt hier einfach mal die Zugangsdaten für einen Server willst du speichern. Und ich meine, wo willst du sie sonst speichern? Also wenn du die irgendwo aufschreibst ist es unsicher, weil da sind halt—
R1: Ich meine vielleicht jetzt nicht nur Zugangsdaten, sondern auch die Datenbank an sich jetzt, bezüglich wenn ihr jetzt Konfigurationsoptionen, die die Datenbank jetzt mitbringt, die müssen ja auch irgendwo gespeichert werden.
I5: Naja, wenn du—also ich habe das meistens so gehandhabt, wenn du irgendwelche Konfiguratiosdateien änderst oder sowas, dann trägst du die ja ein. Aber weil es grundsätzlich alles welche gibt, das… glaube ich nicht. Also sonst müsste man halt die Defaults nehmen oder so. Also wenn du es nicht geändert hast, dann ist es meistens auch nicht bekannt, was da die Defaults sind. Die müsste man halt dann da eintragen. Also wirklich (?35:40 ) nur die Werte rein, die wir auch angepasst haben, wo wir auch wissen, die sind customized sozusagen.
R1: Gut, gehen wir mal zu den Fehlern, den Konfigurationsfehlern (?35:57 ) auftreten. Hast du schon selber Konfigurationsfehler erlebt und was war so der schwierigste oder schwerwiegendste Fehler, den du so erlebt hast?
I5: Naja, der schwierwiegendste Fehler, also wie gesagt, so ein Nginx oder sowas mal misskonfiguriert, das war aber alles noch in der Entwicklungsphase. Weil normalerweise wird das so sein, die Fehler die du am Anfang machst, die kommen dann irgendwann nicht durch die Pipeline und im Release sollte quasi nichts landen, was da irgendwie schlecht konfiguriert ist. Und da hast du halt gerade bei diesem Structure-as-Code, hast du halt den Vorteil, dass du was du am Ende ausrollst, hast du vorher genau so getestet. Das heißt wenn du jetzt einen Konfigurationsfehler machst und das kommt durch die Pipeline durch und ist schlecht konfiguriert, dann ist deine Pipeline schlecht. Und dann musst du an der arbeiten sozusagen. Dann hast du die falsch konfiguriert oder sowas. Auf jeden Fall ist der schwerwiegendste Fehler wirklich in der Entwicklung, dass man da irgendwas falsch gemacht hat und das hält sich im Rahmen. Das begrenzt dann halt nur deine Entwicklungszeit oder sowas wenn du dich lange mit so einem Fehler aufhältst und da gibt es schon manche, wo man sich einfach mal länger aufhält wenn das halt irgendwie schlecht dokumentiert ist oder man hat das halt noch nicht oft gemacht. Oder man findet halt keine Beispiele dazu oder sowas. Und das ist dann schon extrem nervig, aber so jetzt in der Produktion und so quasi nichts.
R1: Kann das irgendwie schon mal länger aufhalten, kannst du auch mal sagen, könnten das auch ein paar Tage sein oder?
I5: Jaja, also wenn du einen richtig doofen Konfigurationsfehler hast und findest es echt nicht raus, dann kann das schon sein, dass dich das zwei, drei Tage auch einfach mal aufhält. Wenn du das Problem wirklich findest. Und das wäre dann aber schon das Maximum, also wenn du so lange Zeit da rumgurkst, dann sollte man sich dann wahrscheinlich auch irgendwie Hilfe holen oder sowas. Aber das kann schon mal vorkommen. Also gerade bei diesen Microservices, wenn du die halt aufbaust und die funktionieren halt irgendwie nicht richtig miteinander und es hat halt einen bestimmten Grund und du findest die Ursache nicht. Klar, das kann—da auf Fehlersuche zu gehen und es ist schlecht dokumentiert—das kann einfach schon mal richtig aufhalten. Aber das ist eher die Seltenheit. Meistens kriegt man sowas hin und es ist auch dann begrenzt, das ist halt in O(1) anstatt, dass das ewig auftritt sage ich mal. (?38:24 ) nur immer am Anfang der Entwicklung und dann siehst du eigentlich so eine Sachen eigentlich nie wieder. Deswegen ist der Schmerz auch nicht so groß auf so ein Problem zu treffen.
R1: Und fachliche Konfigurationsfehler?
I5: Ohja, ja. Da gibt es viele. Also es gibt schon öfters Probleme, das sind halt auch die ganzen Sachen, die so im Support aufschlagen, wenn die Kunden ihr Programm halt schlecht konfigurieren. Oder konfigurieren es halt aus bestem Wissen und Gewissen und dann funktioniert es halt nicht so wie es soll, das kommt schon recht häufig vor und das beschäftigt dann auch die Leute im Support, das geht dann bis zu den Entwicklern. Also das ist schon so Daily Business. Das liegt aber auch dadran, weil es wirklich hochkonfigurierbar ist und die Kunden dann auch meistens irgendwelche Geschäftsprozesse ändern oder irgendwas anders haben wollen oder genau ihr Problem sozusagen abbilden wollen und dann passiert es halt einfach, dass da fehlkonfiguriert wird. 39:31 Viele lesen sich quasi auch die Doku nicht genau durch, das kann man eigentlich auch viel verhindern und dann kommt das eins zu eins zusammen und dann passiert sowas einfach.
R1: Wenn du so eine Projekthistorie hast, ja dann startet irgendwie das Projekt initial so einrichten bis zur Maintenance-Phase. Wann treten denn typischerweise Konfigurationsfehler auf?
I5: Aber da kann ich gar nich so viel zu sagen, weil das ist quasi gar nicht so meine Abteilung. Wie häufig das passiert, man hört es halt immer nur, aber das ist dann halt, also das kann ich nicht mit konkreten Zahlen quasi hinterlegen. Aber gefühlt ist es halt schon recht häufig, weil man kriegt dann halt meistens immer Anfragen, wo dann die Abteilung, die vor uns geschaltet sind, das dann halt auch nicht rauskriegen, aber die wirkliche Dunkelziffer ist dann halt eher unbekannt. Das kann schon weit drüberliegen die Zahl. Oder vielleicht ist es auch genau die Zahl, die wir jetzt halt mitkriegen, dann kommen sie halt mit allen Problemen zu uns, aber meistens ist so, dass die schon viele viele Sachen auch abfangen, weil die die dann auch von der Häufigkeit her schon kennen, sage ich mal, im Support und die Consultants. Und ja, das weiß ich nicht, aber gefühlt ist die Ziffer doch recht hoch.
R1: Wenn du jetzt so einen Konfigurationsfehler hast, wie gehst du da typischerweise vor um den zu finden und zu beheben?
I5: Technische Konfiguration oder fachliche Konfiguration?
R1: Beides. (?).
I5: Also fachliche Konfiguration ist so Doku lesen. Ganz klar. In dem Fall unsere eigene und versuchen das Problem halt herauszufinden. Dann muss man halt schauen, steht das nicht in der Doku oder ist das halt ein echter Bug. Ansonsten bei der technischen Konfiguration auch ganz klar, versuchen das Ding mit der Doku herauszufinden und/oder ein Beispiel zu finden und im schlimmsten Fall wenn man jetzt halt gar nichts findet, also du hast kein Beispiel, du hast kein Tutorial und du hast die Dokumentation nicht, dann ist es dann am Ende einfach auch ein bisschen ausprobieren. Dass du halt sagst ich setze jetzt mal den Wert dies, das, hier und jenes oder vielleicht ist eine Kombination mit einem anderen Konfigurationsvalue, den man eventuell noch gar nicht ausprobiert hat und versucht da dann irgendwie was zu reißen, aber das wäre dann sozusagen die Notlösung.
R1: Kannst du da ein Beispiel geben, wie versuchst du Beispiele zu finden?
I5: Ja, weiß ich nicht. Irgendwas, zum Beispiel so ein Elastic Search oder so, weiß ich nicht, wenn du da irgendeine Größe einstellen musst, also das hatte ich mal das Problem, dass die Instanz auf dem man das hochgefahren hat, dass die einfach zu wenig RAM hatte und da irgendwie weiß ich nicht. Da musstest du irgendeine Environment-Variable einstellen und das beschränken und dann musstest du auch noch irgendeinen Sicherheitsmechanismus aushebeln und so. Ich meine sowas findet man dann immer meistens. Aber das kann auch sein, dass du da an Größen und so ein bisschen was umherschrauben musst auch. Oder wenn wir unsere eigene Software haben, dass du dann halt sagst du hast jetzt irgendwelche REST-Pakete, da sind halt, weiß ich nicht, tausend Objekte drin, dann konfiguriert man ein bisschen rum und versucht das zu optimieren, dass man halt im Endeffekt mehr Objekte sozusagen pro Zeit dann halt dadurch kriegt oder sowas, durch die REST-Anfragen. Ja, sowas. Oder wo es auch so ganz krude Beispiele gibt, zum Beispiel wenn du Lambda-Funktionen in AWS hast, da kannst du halt auch gucken. Gibst du dem Ding mehr RAM und machst die Pakete kleiner, dann funktioniert das vielleicht im Endeffekt mit weniger Kosten oder versuchst du da halt was einzustellen. Das ist halt auch reines probieren und da gibt es halt auch nicht so die Lösung. Da kann man halt immer noch mal so ein paar Stellschrauben irgendwie drehen und optimiert dann halt für sich sein Ergebnis so ein bisschen. Oder fixed dann halt ein Problem. Aber das ist dann halt meistens wirklich so das allerletzte, was man noch versuchen kann, weil man wirklich gar nichts dazu findet.
R1: Okay, neben Doku lesen, (?43:50 )
I5: Sonst gibt es ja nicht mehr viel würde ich jetzt mal so sagen. Also wenn du keine
R1: Google oder StackOverflow oder so?
I5: Jaja, also das zähle ich ja mit dazu—
R1: Das ist für dich Doku, oder?
I5: Nene, Doku oder du suchst dir halt ein Beispiel wie es jemand anderes gemacht hat. Also da zähle ich solche Sachen mit dazu, weiß ich nicht, StackOverflow und all sowas natürlich. Also das ist ganz klar. Da zählt für mich halt nach so einer Recherche, da ist immer das Netz mit dabei. Also einfach googeln und gucken hatte das Problem schon jemand und ja, da findet man eigentlich immer meistens was. Und ansonsten wenn das jetzt halt alles nicht hilft—das meinte ich jetzt eigentlich damit im Vorfeld—dann müsste man halt einfach rumprobieren.
R1: Kollegen… wird da irgendwie bei Kollegen gefragt, oder?
I5: Natürlich, klar. Also wenn man jetzt gar nicht weiterkommt, dann fragt man natürlich auch einen Kollegen. Das ist halt immer so sein, erstens Doku lesen, zweitens nach dem Problem googeln, drittens Kollegen fragen und ansonsten halt rumprobieren wenn es gar nicht geht. Vielleicht drittens, viertens würde ich vielleicht auch noch mal tauschen, also vielleicht kann man vorher auch noch mal ein bisschen rumprobieren und dann vielleicht einen Kollegen fragen, aber ja… ansonsten, genau.
R1: Welche Strategien hast du denn um solchen Konfigurationsfehlern vorzubeugen?
I5: Vorzubeugen? Ja, man guckt sich halt, wenn du jetzt zum Beispiel ein neues Docker-Image dir ziehst und willst halt irgendwas ausprobieren, dann gucke ich mir meistens immer schon mal so eine Readme an wenn es die gibt. Und ich entscheide auch welches Dockerfile ich nehme, ist es immer, ich will es von der Firma am liebsten direkt haben, also nicht irgendwie von so einem privaten Repo oder sowas, keine Ahnung. Und gucke einfach, ist das gut dokumentiert, steht alles drin, schaue mir mal halt so ein bisschen an, was kann man alles einstellen und was kann man eventuell auch nicht einstellen, versuche dann auch mal auf GitHub sozusagen mir dann dazu noch was anzugucken, da stehen auch immer noch mal ein paar interessante Sachen drin. Und ja, versuche das eigentlich dann im Vorfeld schon mal ungefähr abzutaxieren(?46:06 ), was mich da erwartet. Und dann liest man sich halt, weiß ich nicht, ein paar Tutorials noch durch, da sieht man auch immer noch mal, was die Leute für Probleme hatten, also das ist immer ganz interessant, wenn man die Kommentare zum Beispiel unter einem Tutorial durchliest, wo dann einfach nur steht „Ja schön, dass du das gemacht hast, aber bei mir funktioniert es einfach nicht. Und dies und das und jenes und das sind die Probleme.” und da kann man auch schon mal sehen, was könnte einen erwarten und dann kann man sich auf ein bestimmtes Problem auch schon mal ein bisschen einschießen und guckt dann schon mal nach was es da schon dann auch an Lösungen gibt, die da halt auftreten.
R1: Okay, also Kommentarsektion auch wichtig (? 46:45 )
I5: Ja, auch. Also wenn du halt ein Tutorial findest, was gar nicht funktioniert, dann programmierst du es halt nach, kommst selber zu dem Fehler und dann kannst du sowieso schon mal da nach gucken. Das kannst du halt auch schon im Vorfeld machen. Und suchst dir dann eventuell ein anderes Dockerfile aus oder sowas. Also Dockerimage. Was das Problem dann halt vielleicht besser löst. Ja.
R1: Okay. Dann… welche Verbesserungen würdest du dir denn wünschen? Also wenn du jetzt irgendwie dir was wünschen würdest hinsichtlich Konfiguration von Softwaresystemen, Frameworks und Infrakstruktur und so weiter. Was könntest du dir da vorstellen?
I5: Naja, cool wäre—also ich glaube Docker Swarm fehlt das so ein bisschen—es gibt diese Docker Secrets, also es wäre halt richtig cool wenn man die—das geht in Kubernetes glaube ich auch—wenn man die zentral verwalten könnte, die ganzen Secrets. Du hast halt irgendeine Service-Architektur, die fährst du hoch und dann hast du halt irgendwo eine Sektion oder irgendein Tool, was diese ganzen Secrets verwaltet und die in dein System bringt. Die dann auch dafür sorgst, wenn du die mal updaten willst, dass die das einfach macht. Du willst nicht jeden einzelnen Part deiner Anwendung halt ändern musst. 48:06 Die auch vielleicht ein bisschen guckt, wann müsste ich ein Secret einfach mal ändern. Wie lange gibt es dieses Secret schon und muss das eventuell mal neu gemacht werden oder so was. Welche dürfen nicht geändert werden? Das ist ja auch noch mal so ein Punkt, ne? Also wenn du irgendwie was in deiner Datenbank encryptest und hast dann—so in RAIDs gibt es das zum Beispiel, da hast du so einen Secret Key und auf Basis dessen encryptest du irgendwelche Sachen in der Datenbank, dann darfst du den auch nicht ändern, weil dann kannst du das nicht wieder decrypten und so Geschichten. Also das sollte so ein Tool dann halt auch können. Und dann wäre es halt cool, wenn man eigentlich die Möglichkeit hätte das irgendwie quasi einheitlich zu verwalten und wenn man da irgendwelche Alarme hätte und sowas in der Art.
R1: Und was würde dir jetzt vielleicht helfen um schneller Konfigurationsfehler zu bemerken oder zu identifizieren oder zu beheben?
I5: Na, die kriegst du eigentlich immer relativ schnell mit. Also wenn es nicht funktioniert, dann funktioniert es nicht. Das sollte eigentlich deine Pipeline abfangen. Also wenn du irgendwas falsch konfigurierst, also selbst wenn es bei der technischen Konfiguration so, dann wird dir das deine Pipeline abfangen. Bei der fachlichen Konfiguration sieht es natürlich ganz anders aus. Also da müsste es mehr Prüfmechanismen geben, also die irgendwie, wenn eine Konfiguration zum Beispiel keinen Sinn ergibt. Du hast halt, weiß ich nicht, du willst halt zwei Sachen gleichzeitig abrechnen oder du hast irgendwelche Abrechnungszeiträume, die sich überlappen oder irgendsowas. Also es gibt garantiert irgendwelche Kombination, die fachlich in deiner Anwendung gar keinen Sinn ergeben, die zum Fehler führen. Und das wäre natürlich cool, wenn man die ausfiltern würde. Aber dazu bedarf es halt Integration Tests. Also die sollten eigentlich durch gute Tester im Vorfeld halt auch abgefackelt(?) werden. Das es halt gar nicht dazu kommen kann. Aber das wäre schon cool, wenn man das auch irgendwie abprüfen könnte. Also wenn so eine Möglichkeit auftritt, dass man halt eine Fehlkonfiguration gemacht hat, dass das irgendwie dem Nutzer auch sichtbar gemacht wird, dass es keinen Sinn ergibt, was jetzt getan hat oder so. Dass es halt irgendwie überprüft. Oder dass es überhaupt erstmal ein Tool gibt, also das betrifft uns jetzt halt auch, dass man sieht was hat man an Einstellungen vorgenommen überhaupt, das das irgendwie erstmal auflistet. Wie unterscheidet sich das vom Standard? Solche Sachen halt.
R1: Okay, super. Dann haben wir eigentlich bloß noch hier ein paar Fragen zu dem Team… ja, Hierarchie kann man ja so—Hierarchieebenen in Organisationen. Und zwar, habt ihr, also ist eure Organisation in Hierarchieebenen aufgeteilt? Und auf welcher Ebene würdest du dich da sehen?
I5: Eher nicht. Ich glaube wir haben nur zwei Hierarchien, das ist der Chef und der Rest sage ich mal. Und das ist eigentlich nicht so aufgeteilt, dass mal da irgendwie einer über dem anderen ist. Das ist mehr so alles eine Ebene. Es gibt halt so eine Art Teamlead und den Chef und das war es halt, glaube ich.
R1: Was sind da für dich die Vor- und Nachteile davon?
I5: In Bezug auf Konfiguration, oder?
R1: (? 51:37 ) für dich persönlich für diese Hierarchieweise.
I5: Naja, Vorteil an einem Teamlead ist halt, wenn man halt ein Problem hat, entscheidet der das am Schluss. Weil was ziemlich gefährlich ist, wenn du so ein flaches Team hast und jeder hat halt eine andere Meinung, dann kommt man nie zu einem Ergebnis. Wenn dann irgendwie alle anderer Meinung sind. Das ist dann an einem Teamlead schon ganz gut. Wo so ein Teamlead einen halt ein bisschen ausbremsen kann, wenn es um neue Ideen geht oder sowas. Also wenn der Teamlead halt irgendeine Meinung hat, die er vorgibt, dann ist es manchmal auch schlecht da andere Wege zu finden, andere Lösungsansätze. Das ist immer so ein bisschen Nachteil für mich und ja, ansonsten ist eine flache Hierarchie eigentlich recht cool. Macht das Arbeiten halt schon leicht.
R1: Wenn du jetzt eine inhaltliche Frage hast, gehst du dann eher zum Teamlead oder zu deinen Kollegen? Und warum zu denen?
I5: Das ist halt ein bisschen die Gefahr. Der Teamlead wird dann halt immer so als derjenige angesehen, der alles weiß und der sowieso dann halt entscheidet. Da ist dann halt immer die Gefahr, dass man seine Teamkameraden dann einfach quasi gar nicht fragt, weil im Endeffekt, weil im Endeffekt entscheidet das sowieso dann der Teamlead. Ja, das ist schon ein bisschen Thema denke ich. Aber ansonsten könnte man ja trotzdem jeden anderen auch fragen. Also das ist schon—
R1: Also gehst du nicht wirklich nach (?)-Wissen, sondern eher wer macht am Ende die Entscheidung?
I5: Ja, so in der Art. Wenn man die Entscheidung trifft, dann hat man halt auch quasi das Wissen. Das ist immer so ein bisschen miteinander verkoppelt sage ich mal. Also zumindest vom Gedanken her. Also oder vom Empfinden her sage ich mal.
R1: Gibt es denn für verschiedene Themen, die ihr habt, verschiedene Ansprechpartner bei euch?
I5: Also wir sind ein relativ kleines Team, es sind vier Entwickler und… eher nicht, also kannst du jeden alles fragen. Das ist eigentlich relativ offen.
R1: Wenn dann aber im Team irgendwas nicht beantwortet werden kann geht ihr dann auch zu anderen Teams bei euch?
I5: Das trifft bei uns eher nicht zu, sondern wir sind immer eher so die letzte Instanz sage ich mal. Wenn bei uns was nicht beantwortet werden kann, dann kann das quasi keiner beantworten, dann müssen wir irgendwie anders eine Lösung finden oder es wird halt das Problem untersucht und es wird ein Bug draus gemacht, keine Ahnung oder sowas. Von daher fragen wir dann auch niemand anderes, weil wir müssen es beantworten im Endeffekt.