konkretor schrieb:
Es gibt da halt einen SLA der definiert wie lange der Kunde warten muss, bis er etwas bekommt. Je nachdem, wie der SLA ist, sieht es halt auch preislich aus.
Definieren aber mal bitte SLAs für nen Cluster....
Das ist extrem umfangreich bzw schwierig. Im wesentlichen. Gibt es da mehrere Punkte
1. Es existiert Problem XY das muss behoben werden. Hierfür muss Z getan werden
2. Es gibt Problem Q und niemand weiß was die Ursache ist. Muss also Debugged und dann behoben werden. Wenn Möglich Workaround W testen und bereitstellen damit die User arbeiten können. Da kannst du auch SLAs definieren.
3. Es gibt Software K die muss mit einer neuen Version bereitgestellt werden, also installieren, Workarounds/Patches P L und G noch anwenden und dann das ganze novh in den bestehenden Frameworks verdrahten damit die User es einfach nutzen können ohne selbst etwas zu machen. Dabei schauen ob noch neue Probleme auftauchen und das es keine Regression Ä und Ö gibt wenn ja Debuggen und fixen.
1. Ist einfach und kannst du auslagern 3. Wird schon deutlich schwieriger weil eben der Weg zum Ziel nicht klar und teils ja noch nicht mal das Ziel klar definiert sondern ergibt sich aus den Randbedingungen einfach auf natürliche weiße. Hier wird es schon ziemlich ekelhaft...
2. Vergiss es dafür SLAs zu definieren. Genau das macht aber einen großen Teil der Arbeit aus.
konkretor schrieb:
Beispiel Kunde fragt an, ob er den Druckerdienst selber neu starten könnte. Kein großes Problem, das ist keine große Aufgabe. Nur durfte ich ihm es nicht einrichten, da kein Budget für so etwas bei ihm vorhanden war. Ich hätte ihm 15 Minuten verrechnen müssen. Also musste er bei Problemen weiter Tickets aufmachen. Im SLA war der Drucker nicht definiert, also nicht das Problem vom Dienstleister. Falsch verhandelter Vertrag.
Ein anderer Kunde wollte auf zwei RHEL VM gewisse Pakete haben, dafür hat der Kunde 1 Woche gewartet, da der SLA das so vorsah. Ich hab das Ticket 5 Tage herumliegen gehabt, bis ich es umsetzen durfte.
Ich hab das nicht lange gemacht, es ging mir so gegen den Strich.
der Punkt ist aber, inwieweit kannst du bei komplexen Systemen überhaupt sinnvolle SLAs definieren. Das fängt doch schon bei HW Handling an.
der Tausch von nem kaputten DIMM Riegel sollte in der Regel in 24h erledigt sein. Wenns mal ne Woche ist ist das auch egal. Wenn es aber immer ne Woche+ ist dann ist das einfach Mist. Richtig schlimm wird es aber wenn es "repariert" wird das Problem danach aber noch besteht oder etwas anderes nicht tut. Zum Beispiel beim Tausch der CPU danach Temp Probleme wegen schlecht sitzendem Kühler oder WLP. Da bekommst du nur noch das Kotzen.
In dem Bereich ist es einfach essenziell das Probleme behoben werden ohne neue zu erzeugen. Und bei der Arbeit mit HW ist das schon für sehr viele Anbieter echt eine Herausforderung aber mit Software wird es echt übel.
Ich trete zum Beispiel seit mehr als einem Jahr einem Softwarehersteller in den Arsch weil er seine Software nicht soweit im Griff hat um reibungslos auf Clustern zu laufen. Du willst nicht wissen wie erbärmlich das ist obwohl das eine Firma mit Milliardenumsätzen ist...
und da bekommen wir die richtigen Probleme. Die Cluster laufen 24/7 und Wartung gibt es nur alle 3 Monate. Ganz viel muss also im laufenden Betrieb gemacht werden. Da darfst du dir keinen Fehler erlauben, denn im Schnitt hast du weniger als 1 Minute bevor jemand ein Problem sieht. Eher sogar weniger als 1 Sekunde. Du kannst also davon ausgehen, das jede Fehlkonfiguration auch bemerkt wird. Zumindest solltest du es. Klar gibt es auch Dinge die nur alle paar Tage benutzt werden oder far nur alle paar Wochen, aber ganz viel ist halt Baisfunktionalität.
Und um nochmals auf HW zurück zu kommen. Wenn da nen lead Switch ausfällt und du 40+ Server verlierst dann muss das schnellstmöglich gefixed werden genau wie zum Beispiel GPU Server. Aber selbst mit SLA dauert es teils Wochen oder gar Monate bis die wieder sauber laufen...
SLAs machen da halt nur bedingt Sinn. Wrnn du für die SLA mehr zahlst als für nen.weiteres System macht es keinen Sinn dich gegen den Ausfall des Systems abzusichern. Ich hoffe du weißt was ich meine. Das ist halt der Ritt auf der Rasierklinge den man immer machen muss. Das erfordert auf der einen Seite ne gute Auswahl am Anfang mit wem man überhaupt zusammenarbeiten will auf der andere Seite dann aber auch knallhartes handeln wenn es Probleme gibt. Sprich man darf sich nicht verschaukeln lassen und gut einschätzen können was wirklich ein Problem ist und wann man verarscht wird. Und ich lann dir sagen das ich da sehr unangenehm werden kann wenn ich das Gefühl habe verarscht zu werden. Das kann durchaus auch jemanden den Job kosten. Da bin ich absolut schmerzbefreit.
konkretor schrieb:
So einen HPC Cluster kannst du ja auch mit einem SLA belegen.
Und wie soll die aussehen?
Es gibt ja wie ich vorher versucht habe zu erklären Dinge die dürfen keine Sekunde falsch sein und Dinge die werden Wochen lang Probleme machen.
Im Prinzip kannst du sagen, das sobald du auch nur daran denkst welche SLA man hat das Kind eigentlich schon in den Brunnen gefallen ist, weil der Zulieferer nicht das leistet was man erwartet und SLAs helfen dir da nicht. Denn die Schäden sind viel höher als alles was du über realistische SLAs abdecken kannst. Du bist da schnell bei 5 oder 6 stelligen Zahlen pro Tag. Nehmen wir mal mit rein ein User würde wegen Problemen ein Projekt nicht fertig bekommen bist du im Zweifel auch bei Mimlionenstrafen weil du Termine gerissen hast. Das ist halt das Problem. Damit sich HPC lohnt muss es möglichst günstig sein. Wenn es dann aber mal nicht tut kann es auch Millionen kosten...
konkretor schrieb:
Dann wird das ausgeschrieben und einer deiner genannten Dienstleister wird sich dem dann annehmen. Das dies für die MA die diesen HPC Cluster nutzen, totaler abfuck werden wird. Darüber brauchen wir uns nicht weiter auszulassen.
So funktioniert die Branche aber nicht. Die Preise die benötigt werden sind nur haltbar weil man keine harten SLAs definiert weil man weiß, das zu 99% man damit einfach nur Unmengen an Geld verbrennt und so lange der Zulieferer mitzieht es auch absolut nichts bringt. Denn die SLA sorgt nicht zwingend dafür dass das Problem schneller gelöst wird. Also gerade bei Software. Es erzeugt einfach nur Mehrkosten am Ende.
Und genau deswegen wird es wie du sagst auch ein Ubfuck denn die Preise werden deutlich steigen auch beim jetzigen Anbieter wenn alles köeinteilig mit SLAs behandelt wird.
konkretor schrieb:
Die Frage ist doch, was passiert mit dir, wenn sie das ganze Thema outsourcen? Die wollen ja Personal einsparen. Wirst du gekündigt, bekommst du einen Aufhebungsvertrag? Sieht so aus, als ob du mal deine Unterlagen auf den aktuellen Stand bringen musst. Sehr unschöne Geschichte.
Es wird nicht das gesamte Thema geoutsourced sondern es steht nur im Raum ein bereits Extern vergebenes Themenfeld anderweitig zu vergeben. An sich ist das durchaus möglich, aber wegen der Komplexität und dem dauerhaften Betrieb halt mit viel Parallelbetrieb und Risiken verbunden.
Ich rechne mit 1-2 Jahren um solch einen Wechsel sauber über sie Bühne zu bekommen ohne den Betrieb zu gefährden...
_killy_ schrieb:
Zuallererst haben die Jungs in Indien wirklich für jeden Scheiß ein Zertifikat - wirklich, alles. Du brauchst 100 Leute mit NASA Zertifikat für die Mondlandung -> TCS hat die! Ich arbeite bspw. mit Full-Stack C# .NET Entwickler zusammen ... und darf ihnen einfach SQL Select Statements erklären.
Also rein auf dem Papier sind dass extreme Überflieger - zu einem günstigen Preis. Weiterhin verstehen sie es extrem gut - wenn du dort Support einkaufst - wie sie die SLAs einhalten. Da kommt ein Prio 1 Ticket rein - mit 30 Minuten Reaktionszeit? -> Frage an den Ersteller des Tickets raussenden und Ticket auf "on hold" setzen, so dass keine Zeit gemessen wird.
und genau das kannst du halt in meinem Bereich nicht gebrauchen. Du brauchst da Leute die auf grob umrissene Anforderungen das richtige tun und mitdenken. Wenn ich das kleinteilig definieren muss kann ich es auch gleich selbst machen. Da bin ich am Ende schneller.
Das Reaktionszeit spielchen sollte man aber mit mir nicht versuchen zu spielen... wenn ich merke dass das gemacht wird kann ich es auch spielen und wenn ich mit alle 2h den Wecker stellen muss um eine Reaktion anzumahnen. Ach und ich erstelle Tickets dann natürlich auch zu jedweder noch abgedeckt Zeit usw usf. Ebenso habe ich kein Problem damit Tickets auch über ein Jahr nicht zu schließen wenn ich nicht zufrieden bin. Es gibt da sehr viele subtile Möglichkeiten um den Spieß umzudrehen. Und klar zuerst muss ich Staub fressen und Mehraufwand hinnehmen. Wenn aber wieder und wieder das Beschäftige den User Spiel gespielt wurde werde ich das nicht mehr akzeptieren und Validierungen usw auf Anbieterseite einfordern und wehe es funktioniert nicht wie beschrieben...
_killy_ schrieb:
Die Zufriedenheit der Anwender wird an einem extremen Tiefpunkt gehen - ist aber aus Management-Sicht absolut kein Problem.
Ja das sind am Ende die Leittragenden, aber ganz ehrlich? Am Ende sind die User auch nichts anderes als Munition um seine Interessen durchzusetzen. Pick dir die richtigen User raus halt ganz viel Händchen und Sie werden das Bild das du vermitteln willst in die Organisation tragen. Sprich nutze Guerilla Taktiken subversiver Elemente.
Wie gesagt am Anfang frisst man viel Scheiße aber wenn du deine Armee geformt hast kannst du deinen Ärger ziemlich einfach potenzieren.
_killy_ schrieb:
Meine Empfehlung an dich: bleib nicht der Verantwortliche für die Anwendung/Hardware/Dienst/... und der externe Dienstleister übernimmt die Arbeit. Du bekommst den Anschiss ... du sollst die Leute steuern und der ganze Frust deines Unternehmens wird bei dir abgeladen.
Wenn also irgendwas ausgelagert wird - dann seih bei diesem Bereich wirklich absolut nicht mehr involviert. Du wirst sonst zwischen den Fronten aufgerieben.
Schnittstellen Funktion. Wir sind da einfach im Boot und kommen nicht raus. Das einzige Mittel das ich da sehe ist absolute Transparenz. Jeder Fehler bzw Problem muss analysiert und ein Schuldiger gefunden UND benannt werden. Macht man sich damit Freunde? Nö, aber dafür wird man auch nicht bezahlt sondern dafür, dass das Zeug läuft und die Leute arbeiten können.
Und nein das Ergebnis steht noch nicht apriori fest. Management kann ja am Ende auch etwas zum besseren verändern. Nur wenn man Risiken sieht und die einfach ignoriert werden sich dann aber realisieren, dann muss jemand für die falsche Einschätzung bluten und das bin am Ende nicht ich bzw maximal blute ich mot aber der Verantwortliche muss definitiv mehr bluten als ich. Denn nur aus Schmerz lernen viele...
