Zum Inhalt springen

DocInfra

Mitglieder
  • Gesamte Inhalte

    1.799
  • Benutzer seit

  • Letzter Besuch

Alle Inhalte von DocInfra

  1. Für eine KLR kann das aber schon zu grob sein. Gerade bei Inhouse IT und der verursachergerechten Berechnung der IT-Kosten an andere Abteilungen kann die möglichst genaue (minutengenau ist übertrieben, es muss schon in einem sinnvollen Verhältnis stehen) sehr viel Sinn machen. Zeiteinheiten von 0,25 bis 0,5 Stunden sind sinnvoll. Auch das Buchen auf unterschiedliche Themengebiete macht Sinn. Wenn ich sehe das meine Leute viel Zeit mit Orga und Zeiten buchen beschäftigt sind, dann kann ich da gegensteuern. Alles eine Frage des IT-Controllings.
  2. Der Überschreibschutzzeitraum beginnt mit Abschluss der Sicherung. Wenn die Sicherung um 20 Uhr beginnt und um 23 Uhr endet, dann ist das Band erst am nächsten Tag um 23 Uhr wieder frei. Also wird er an das Band anhängen, immer und immer wieder, da immer eine Sitzung vorhanden ist, die noch schreibgewchützt ist. Wenn er nicht anhängen darf, wird er warten.
  3. In dem Alter, IT-Mädchen für alles... da sind 42,5k schon okay. Versuch mal 48,5k und dNn werdet ihr euch wahrscheinlich in der Mitte treffen.
  4. Wenn die private Nutzung des Internets und E-Mail nicht ausdrücklich untersagt wurde, dann nicht. Gibt es diverse Urteile zu. Der Fall ist IMHO eindeutig. Aber wir sind hier auch nicht bei der Rechtsberatung. Ich kann aber auch nicht verstehen, dass der TE nicht einfach mal den Mund aufmacht und seinen Chef anspricht. Nur sprechenden Menschen kann geholfen wir? Hier posten löst sein Problem in keinster Weise. EDIT: Ganz interessant: Offenbar dürfen Arbeitgeber doch auf Postfächer zugreifen, siehe Urteil des Landesarbeitsgerichtes Berlin-Brandenburg Az.: 4 Sa 2132/10, auch dann, wenn die private Nutzung erlaubt ist. Wie gesagt: Ist keine Rechtsberatung.
  5. Völlig korrekt. Aber ich glaube das schwebt dem TE offenbar weniger vor... Und deswegen bleibe ich dabei: Du kannst in die Breite gehen, dann bleibst du aber zwangsläufig an der Themenoberfläche, oder du gehst in die Tiefe. Wenn er sich z.B. auf Datacenter Infrastructure spezialisieren will, dann kommt er an den Themen Virtualisierung, Automatisierung, Netzwerk nicht vorbei. Und das wird zwangsläufig auch so Dinge wie Python, Perl, C, Java umfassen (wenn in diesem Fall auch eher oberflächlich und auf sein Gebiet angepasst).
  6. Vergiss das. Entweder du gehst in die Breite und bleibst thematisch an der Oberfläche, oder du gehst in die Tiefe. Alles andere ist unrealistisch und auf Dauer nicht machbar.
  7. Exchange Autodiscovery lässt grüßen. Kam mit SP1 und lässt sich AFAIK nur umgehen. indem man ein Attribut mittels adsiedit entfernt.
  8. ... wem der Schuh passt... Da sind wir wieder beim Thema Business IT-Alignment und der Abstimmung der Unternehmens- und IT-Strategie. Für mich klingt das nach einem ziemlich strategielosen Laden. Gut, kommt immer mal wieder vor. Aber auch hier: Strategien kann man nicht per apt-get nachinstallieren. Und auch hier zeigt mir die Praxis: Kellerkinder und Nerds lösen organisatorische Probleme gerne mit technischen Lösungen. Und Strategien... das ist doch die Timeline, wann das nächste Release von $SOFTWAREPRODUKTDEINERWAHL veröffentlich wird, oder? IT muss sich professionalisierne. Das geht natürlich nur in Unternehmen, die verstanden haben, dass IT einen Mehrwert bieten kann und IT professionell betrieben werden muss um langfristig am Markt erfolgreich zu sein.
  9. Ein Grund mehr, warum "Kellerkinder" und "Nerd-T-Shirt-Träger" in der IT am aussterben sind. Softskills und Kommunikationsverhalten kann man nicht per apt-get nachinstallieren.
  10. Wahrscheinlich würde man, wenn man sich den Einführungsprozess beineuch ansehen würde, die ganzen klassischen Fehler finden, die man bei so einer Einführung machen kann. In erster Linie müssen die Mitarbeiter verstehen warum eine Lösung eingeführt wird. Wenn es Probleme gibt, dann muss man die Akzeptanzprobleme lösen. Das ist eher ein organisatorisches und kommunikates, weniger ein technisches Technisches. Mitunter einer der Gründe warum viele IT-Abteilungen daran scheitern.
  11. OT: Technik ist commodity und für mich Schall und Rauch. Ich bin in erster Linie User.
  12. Bin ich eigentlich der Einzige, der oben Werbung der SGD eingeblendet bekommt? Besonders interessant: Ausbildung zum psychologischen Berater. Vielleicht wäre das ja hier für den einen oder anderen etwas. )
  13. Es ist eine Standardklausel. Reicht dir die Aussage nicht?
  14. Das ist eine Standardklausel um zu verhindern, dass Mitarbeiter sich hinter ihrer Stellenbeschreibung verstecken und nur die dort spezifizierten Tätigkeiten übernehmen. Wenn du nicht ausgelastet bist, dann halte ich es für absolut legitim dir weitere Aufgaben zu geben, für die du offenbar qualifiziert bist. Ob du nun Lust dazu hast oder nicht, steht dabei nicht zur Debatte. Die Arbeitswelt ist kein Ponyhof...
  15. "Speichernetze" aus dem dPunkt Verlag.
  16. Dafür gibt es aber erstaunlich viele kleine Firmen, die von Storage so gar keinen Plan haben. Dafür muss man wohl nur mal Google befragen. Und wer den OpenFiler ausknipst und sich dann wundert warum der ESXi hängt, der wird wohl als erstes Google befragen. Das ist kein Zeichen von Knowhow oder davon, dass man Verstanden hat. Das hab ich damit auch nicht gemeint. Aber ein bisschen mit OpenFiler rumzocken reicht nicht mal für eine Juniorstelle. Falsch. Zum Laufen bekommt man es im Zweifel mittels Trial & Error. Verstanden hast du es, wenn du es einem Deppen erklären kannst. Ach, die anderen Bücher sind weniger technisch? Der Deepdive ist die passende Ergänzung zu den anderen Büchern. Deswegen sagte ich auch, dass er in deiner Aufzählung fehlte. VCAP Study Guides bringen einen nicht wirklich weiter, wenn man die Basics nicht verstanden hat. Hast du nicht gerade geschrieben "Erst laufen, dann rennen"?? Knowhow in den genannten Bereichen baust du nicht durch "rumspielen" oder gar Versuche in Produktionsumgebungen auf. Trainings, Selbststudium, geleitete Praxiserfahrung durch erfahrene Kollegen. Alles andere führt im besten Fall zu schmerzhaften Praxiserfahrungen, im schlimmsten Fall zu Datenverlust in Kundenumgebungen und Downtime. Aber gut, das Thema ist hier wohl ziemlich überflüssig. Bei Interesse mag der Interessierte ja einen eigenen Thread dazu eröffnen.
  17. Rumspielen mit zwei ESXern ist das Eine. Verstehen, wie das Ding funktioniert, und das auf eine produktive Umgebung übertragen ist das Andere. Genau so verhält es sich mit Storage. Mit OpenFiler und iSCSI rumzocken ist eine Sache, eine Fabric mit mehreren hundert Ports, Zoning etc. administrieren die andere Sache. Noch weiter geht es, wenn es um Troubleshooting oder Design geht. Stellen im Bereich Virtualisierung sind recht oft zu finden, im Storagebereich wird zwar gesucht, aber so gut wie keine Einsteigerstellen. Einige der oben genannten Bücher hab ich auch. Was fehlt ist der Clustering Deepdive von Epping und Denneman. Das Mastering VMware vSphere von Lowe ist großartig.
  18. Schwer... Literatur und Testmöglichkeiten gibt es, aber Praxiserfahrung ist dann doch etwas anderes.
  19. Ich bin auch deutlich über 8 Jahre bei meiner aktuellen Company, damit hat das nichts zu tun. Da ich aber selber ein wenig in dem Umfeld Storage und Virtualisierung unterwegs bin weiß ich, wie schwer es ist gute Leute zu finden und das nicht jeder, der sich damit beschäftigt, auch wirklich Ahnung von der Sache hat. Das mit dem Bonus als Ansporn Dienstleistungs- und Projektberichte abzuliefern ist natürlich ein feiner Zug. Das solche Mittel notwendig sind zeigt aber, dass es Verbesserungen im Prozessbereich gibt, bzw. offenbar nicht jeder vollständig verstanden hat, dass die Scheine und Berichte die Abrechnungsgrundlage darstellen und damit Geld wert sind.
  20. Die Frage ist: In welcher Tiefe. Normaler kann man mit Knowhow in den Bereichen Storage/ Backup und Virtualisierung gutes Geld verdienen. Wieviele hängt vom konkreten Knowhow und dem Arbeitgeber ab. Wie ist das denn zu verstehen. Das klingt jetzt nicht danach, dass ihr eine wahnsinnige Auslastung habt.
  21. Wie kommst du auf ITIL? Hab ich das erwähnt? Changemanagement erfordert kein ITIL, ITIL schlägt vor, wie man sowas abbilden kann. Das von mir Gesagte gilt auch für kleine Läden und es funktioniert auch in kleinen Läden. Ich habe genug Beispiele in der Praxis erlebt. Zudem liest sich das Umfeld des TE nicht gerade nach "kleinem Laden". Es geht auch gar nicht darum, dass der TE nicht in der Position ist etwas zu entscheiden. Wenn ich seinen Ausführungen folge, dann sehe ich nur jemanden seinem Frust auf einen IT-Dienstleister abwälzen, ohne (möglicherweise) vor der eigenen Tür zu kehren. Wenn seine GF pennt, Anforderungen von oben durchgedrückt werden, die falschen Leute sich abstimmen und die IT einfach nur ihren Job macht und den kleinen Dienstweg ("Hey Joe" ist Fluch und Segen) ausschließt, warum sind die Admins dann stur? Hier liegen in meinen Augen massive Organisationsprobleme vor. Da muss man mal dran arbeiten. Aber das funktioniert nur mit Rückendeckung der GF, immerhin sind das strategische Entscheidungen. Ansätze der Lean IT könnten hier hilfreich sein. Grundlegend muss es aber ein sauberes Requirements Engineering geben, in das alle betroffenen Parteien eingebunden sind. Und sowas funktioniert sogar in einem 2-Mann Unternehmen...
  22. "Jeder" ist nicht die Definition eines Stakeholders. Wer ist für das Produkt verantwortlich? Sicherlich kann ein Stakeholder auch eine Gruppe sein, aber "jeder" ist es wohl kaum Die IT oder der Dienstleister, mit dem ihr Daten austauscht? Fehler erkannt, oder? Organisationsversagen. Such die Schuld nicht bei der IT, wenn ihr nicht daran denkt sie einzubinden. Lad sie ein, wenn sie nicht daran teilnehmen hast du einen Grund über sie zu schimpfen und evtl. kommen dann da auch mal mehr Ressourcen für die IT bei rum. Also ist 22/tcp outbound für andere Dienst geöffnet? SFTP und FTP nutzen aber unterschiedliche Ports. Wenn ihr nicht daran gedacht habt, dann ist das primär erstmal euer Problem und nicht das der IT. Also waren die Entwickler und die IT nicht dabei als entschieden wurde, auf SFTP zu gehen? Dann wurde nicht geprüft ob der Port zur Verfügung steht? Also ich sehe hier Fehler auf vielen Seiten, auch bei dir. Aus deinen Erzählungen sehe ich erstmal kein Verschulden bei der IT. Ist aber auch schwer zu beurteilen, da du hier sicherlich nicht wirklich objektiv bist. Klassisches Organisationsversagen. Eskalier das bei den Stakeholdern und schau was passiert. Aber ich rate euch dringend (wobei das nur auf Basis deiner Berichte ist) an euren Prozessen zu arbeiten und das sich jeder mal vor seiner eigenen Tür kehren sollte. Sowas lässt sich nur durch entsprechende Zuständigkeiten und Prozesse lösen. Wichtig ist es die Stakeholder im Boot zu haben. Wenn ein Projekt nicht die entsprechende Unterstützung genießt, dann fährt sowas auch mal vor die Wand. Es gehört aber auch zum guten Ton mit allen Beteiligten zu sprechen und sie mit ins Boot zu holen. Wenn das nicht klappt, dann kann ich den Leuten auch keinen Vorwurf machen. Wenn die IT mit im Boot war, das alles abgestimmt war und sie es nicht umsetzt, dann muss man schauen wie es weitergeht. Hier ist dann auch zu klären ob es einen Servicekatalog gibt und ob das was ihr wollt dort enthalten ist und von euch gebucht wurde.
  23. Wer sind hier die Stakeholder? Sagt wer? War die IT mit dabei? Wusste die von den Anforderungen? Warum hast du das nicht getestet als du erfahren hast, dass es SFTP werden wird? Völlig korrekt. Für sowas gibt es ein Changemanagement und IT-Prozesse. Es muss irgenndwann und irgendwo eine Entscheidung getroffen worden sein, dass 22/tcp outbound geschlossen ist und geschlossen bleibt. Wahrscheintlich im IT-Sicherheitskonzept. Möglicherweise willst du auch einen IT-Service nutzen (22/tcp outbound) der nicht vorhanden ist (und deswegen ist der Port zu) oder von deinem Arbeitgeber nicht gebucht wurde (das lässt sich durch Einwurf kleiner Münzen lösen). Willkommen in der Welt der IT-Dienstleistung. Ich sehe hier keine "sturen Admins". Nach der Informationslage sehe ich eher eine Anforderung die mit den falschen Leuten, bzw. nicht mit allen betroffenen Leuten, abgestimmt wurde. In meinen Augen schön selber in den Fuß geschossen. Sollte die Anforderung (22/tcp outbound) an den IT-Dienstleister kommuniziert worden, und auch von denen mit abgenickt worden sein, dann kram einfach das Protokoll raus, geh damit zu der Person, die das im Namen des IT-Dienstleisters abgenickt hat, und fordere das ein.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...