Was muss eine gute Doku enthalten, und was nicht?

[Maniska]

Da mich diese Frag schon seit einiger Zeit umtreibt und nun inspiriert vom Thema Wissensteilung mal die Frage an euch wie ihr dokumentiert.

Mir geht es auch nicht unbedingt um konkrete Tools/Softwarelösungen, sondern um den generellen Aufbau einer System- Infrastrukturdoku, wie (und ob) Entwickler dokumentieren.. da bin ich raus

• WAS dokumentiert ihr?
• WIE TIEF/OBERFLÄCHLICH macht ihr das?
• WIE dokumentiert ihr das? Schemapläne? Auf dem Fileserver? Wikisoftware...

Wie komme ich zu den Fragen?
Aktuell gibt es hier keine Dokumentation die diesen Namen auch verdient, es gibt einige Dokumente, aber das sind immer Inseln die in verscheiden Stadien von "(nicht nicht) Fertig" bis "Veraltet" rumgammeln. Teils vom Dienstleister, teils selbst geschrieben... Das normale Chaos eben.

Wenn ich nur hergehe und z.B. überlege was ich bräuchte um mich in einem fremden Netzwerk zurechtzufinden (Zugänge vorrausgesetzt) welche Dokumente müssen sein, was ist nice to have, was überflüssig, komme ich beim Thema "Netzwerk" auf: IP-Adressliste mit VLAN Zuordnungen (VLAN Daten, Drucker, VOIP, Maschinen...) und die als .txt abgelegte gültige Config der Switche (natürlich kann ich mir auch einfach die running Config anschauen, aber ob die running auch die gespeicherte ist, oder sein sollte? Bei Firewallregeln z.B bin ich zwiegespalten, da ändert sich doch ggf. schneller mal was, und ob das überhaupt sinnig ist.

Müssen z.B. GPOs noch einmal dokumentiert (gesichert ja, aber dokumentiert?) werden oder ist die GPO selbsterklärend?

Müssen Serviceaccounts noch extra dokumentiert sein, oder reicht es wenn bei der jeweiligen Doku zu Service XY steht welcher Account dafür verwendet wurde und beim Serviceaccount in der Kennwortdatenbank gepflegt ist wo er eingetragen wurde (LDAP-User z.B.)

Wie viel Doku ist notwendig, was ist "zu viel"?

 

[Schengel]

Ich, Sysadmin in einem großen Unternehmen mit kleiner IT (3 MA)

• WAS dokumentiert ihr?
  • Hauptsächlich Dinge, die nicht im alltäglichen Geschäft aufkommen, Installations - und Konfigurationsanweisungen für neue Programme, Fehlerbehebungen
  • Die komplette Netzwerkstruktur ist dokumentiert und auf einem Fileserver abgelegt
• WIE TIEF/OBERFLÄCHLICH macht ihr das?
  • Wir gehen immer davon aus, dass die Dokumentationen später von einem neuen MA (Azubi unter anderem auch) gelesen und verstanden werden soll. 
• WIE dokumentiert ihr das? Schemapläne? Auf dem Fileserver? Wikisoftware...
  • Tatsächlich über einen öffentlichen Ornder im Outlook, wo Nachrichten bereitgestellt werden. Das ist unser "FAQ"

 

Also an sich bin ich tatsächlich der Meinung, dass es "zu viel" Doku eigentlich garnicht gibt. Klar, man kann irgendwann die Übersicht verlieren - aber je mehr dokumentiert ist, desto effektiver können die Kollegen und ich bei Krankheit oder Urlaub arbeiten. 

Bearbeitet 30. Juni 2020 von Schengel
fatfinger

[Albi]

vor 21 Minuten schrieb Schengel:

dass es "zu viel" Doku eigentlich garnicht gibt.

OOOOOH doch xD Mit ein Grund warum ich einen Job gekündigt habe, weil es mir auf die Nerven ging das alles in so unnötig tiefem Detailgrad dokumentiert werden sollte. Zum einen war es echt schwer war wirklich das in der Doku zu finden was für einen relevant ist, zum anderen es unnötig viel Zeit gekostet hat, wenn sich Dinge in 3 Sätzen verständlich Zusammenfassen lassen und dann unnötig auf ne Halbe Seite aufgeblasen werden.

Gerade bei Admin Tätigkeiten will ich die Schritte wie ich etwas mache, schnell und einfach entdecken, wenn ich dann noch genauer wissen will, warum und weshalb darf das gerne getrennt irgendwo stehen.

[charmanta]

Oha ... bei uns ein Riesenriesenthema.

Erstmal: kaum ein SE/Techniker mag Doku schreiben. Stelle ich seit der Arche immer wieder fest

Dann hat praktisch jeder andere Ansprüche. Externe Mitarbeiter wollen nicht nur Fakten, sondern komplette Prozeduren.

Wenn ich aber zb für eine Solaris Maschine bis ins Detail aufschreiben muss wie man an den Serviceprozessor kommt und welche Kommandos der überhaupt kann dann schreib ich nen Roman. Da landen dann doch eher nur die Credentials und Besonderheiten in der Doku.

Vorsicht auf jeden Fall: Wenn Ihr Accounts und Kennworte in einer Doku hinterlegt dann ist hier datenschutzrechtlich echt einiges zu bedenken, grade wenn auch Externe Zugriff haben .... das "angemessene Datenschutzniveau" ist hier nach meiner Erfahrung eher selten eingehalten

Ansonsten Wikipedia und auf alle Fälle auch Verlinkung zu Dokumenten auf dem Server

[Schengel]

vor 14 Minuten schrieb Albi:

OOOOOH doch xD Mit ein Grund warum ich einen Job gekündigt habe, weil es mir auf die Nerven ging das alles in so unnötig tiefem Detailgrad dokumentiert werden sollte. Zum einen war es echt schwer war wirklich das in der Doku zu finden was für einen relevant ist, zum anderen es unnötig viel Zeit gekostet hat, wenn sich Dinge in 3 Sätzen verständlich Zusammenfassen lassen und dann unnötig auf ne Halbe Seite aufgeblasen werden.

Gerade bei Admin Tätigkeiten will ich die Schritte wie ich etwas mache, schnell und einfach entdecken, wenn ich dann noch genauer wissen will, warum und weshalb darf das gerne getrennt irgendwo stehen.

Klar! Geb ich dir voll und ganz Recht wenn es um den Punkt geht, dass alles in einem unnötig tiefem Detailgrad dokumentiert werden soll. Würde mich auch total abnerven. Wir dokumentieren zwar viel, aber nicht lange. Die meisten Dokus umfassen eine Seite, wo kurz und knackig steht, was ich wie zutun habe. Nur sehr aufwendige Dinge sind lange dokumentiert, da muss man teilweise aber auch jeden Schritt einzeln durchgehen um nichts falsch zu machen.

[Thanks-and-Goodbye]

Wir bauen hier grad eine Menge neu auf, deshalb können wir uns austoben wie wir wollen.

Doku: alles kommt ins Confluence, aber eher nach dem Prinzip KISS (keep it short and simple). Benutzernamen stehen im Confluence, die dazugehörigen Kennwörter sind nur im Keepass hinterlegt.

[Schengel]

vor 2 Minuten schrieb Chief Wiggum:

eher nach dem Prinzip KISS (keep it short and simple). Benutzernamen stehen im Confluence, die dazugehörigen Kennwörter sind nur im Keepass hinterlegt.

Same over here, ohne Confluence, dafür mit Outlook und ganz vielen PDF-Dateien.

[allesweg]

firmenintern öffentlich soweit möglich, toolunabhängig, mit Verknüpfungen untereinander, durchsuchbar.

Keine Sammlung von Einzeldokumenten in Format xy auf dem Filer, wobei Freeware-Designtool nur auf xp lief...

Ein Wiki mit Grafiken, im Browser dargestellten Tabellen, ... so stelle ich mir gute Dokumentation vor.

Outlook dient der Kommunikation, nicht zur Datenhaltung.

[Rabber]

In jedem Fall merke ich immer wieder, dass gute Dokus eine Kunst für sich sind. Während der eine Kollege es schafft, alles Wesentliche in wenigen Sätzen unterzubringen, braucht der nächste Kollege das Vielfache an Sätzen, ergänzt noch zahlreiche Screenshots oder Tabellen und nachher ist trotzdem keiner schlauer, wenn sie das Mammut an Doku erlegt haben.

[charmanta]

Confluence ist bei uns tot .... Community Version hatte mehr kompletten Datenverlust ( schleichender Datenbankfehler ) ....

Wir sind nun auf Dokuwiki umgestiegen

[Maniska]

Das ist mir jetzt alles noch ein bisschen zu allgemein, auf "So viel wie nötig, so wenig wie möglich" bin ich schon selbst gekommen

vor 37 Minuten schrieb Schengel:

• WAS dokumentiert ihr?
  • Hauptsächlich Dinge, die nicht im alltäglichen Geschäft aufkommen

Das wäre...?

Ich meine, wie oft müssen Sachen vorkommen damit man sie als "Tagesgeschäft" bezeichnen würde (wäre "Drucker auf dem Printserver einrichten Tagesgeschäft, oder kommt das doch so selten vor dass man es dokumentieren sollte oder "weiß man ja eh wie das geht"), gibt es ggf Dinge zu beachten, wie werden Drucker ggf gemapt, muss da noch was gemacht werden. Oder muss ich den Prozess "Backup" dokumentieren? Ist ja Tagesgeschäft, aber der Azubi wird das ohne Doku nicht hinbekommen.

Zitat

• WIE TIEF/OBERFLÄCHLICH macht ihr das?
  • Wir gehen immer davon aus, dass die Dokumentationen später von einem neuen MA (Azubi unter anderem auch) gelesen und verstanden werden soll. 

Das sind aber unterschiedliche Ansprüche, für einen ungelernten (Azubi) muss ich anders dokumentieren wie für eine Fachkraft. Bei letzterer kann ich davon ausgehen dass ich keine Basics erklären muss, vgl. charmants Beispiel mit dem Solaris Serviceprozessor. Von einer Fachkraft kann ich erwarten, dass sie prinzipiell weiß wie man da hinkommt (oder sich den Weg ergoogeln kann), bei einem Azubi nicht.

Zitat

• WIE dokumentiert ihr das? Schemapläne? Auf dem Fileserver? Wikisoftware...
  • Tatsächlich über einen öffentlichen Ornder im Outlook, wo Nachrichten bereitgestellt werden. Das ist unser "FAQ"

Und wie pflegt ihr das wenn es pdf Dateien sind? Die Officedokumente müssen ja auch irgendwo rumfahren und ich kann mir nicht vorstellen, dann jemand der nur eine kleine Änderung gemacht hat eine pdf erneuert (als wieder bearbeitbar macht, die Änderung einträgt und erneut speichert).

Zitat

Also an sich bin ich tatsächlich der Meinung, dass es "zu viel" Doku eigentlich garnicht gibt.

Ich glaub das ist Ansichtssache, je mehr dokumentiert ist, desto eher muss man bei einer keinen Änderung zig Dokumente anfassen.

Andererseits gibt es komplette Blöcke, die sich bei anständiger Benennung durchaus selbst dokumentieren, wo man somit kein extra Dokument benötigt.

vor 12 Minuten schrieb Albi:

Gerade bei Admin Tätigkeiten will ich die Schritte wie ich etwas mache, schnell und einfach entdecken, wenn ich dann noch genauer wissen will, warum und weshalb darf das gerne getrennt irgendwo stehen.

Also quasi 2 Dokumente? Einmal Konfighandbuch und einmal Admin- oder Benutzerhandbuch, zusätzlich ggf. noch ein Notfallhandbuch in dem die wichtigsten Schritte für Fall ABC stehen? Wobei man davon ausgehen kann,  dass im Notfall kein Azubi oder "Fachfremder" Hand anlegt und die Doku entsprechend knapp gefasst ist.

vor 7 Minuten schrieb charmanta:

Vorsicht auf jeden Fall: Wenn Ihr Accounts und Kennworte in einer Doku hinterlegt dann ist hier datenschutzrechtlich echt einiges zu bedenken, grade wenn auch Externe Zugriff haben .... das "angemessene Datenschutzniveau" ist hier nach meiner Erfahrung eher selten eingehalten

Datenschutz wie Personenbezogene Daten oder eigentlich Datensicherheit? Kann ich mit der Nennung eines Serviceaccounts (und ggf dessen Zugangsdaten) gegen den Datenschutz verstoßen? Der User "Server.LDAP" mit den Kennwort "iorRuf57tw$eXo!sij%w+epri23#4r59" dürfte relativ wenig schützenswerte Daten hergeben, oder?

Zitat

Wir dokumentieren zwar viel, aber nicht lange. Die meisten Dokus umfassen eine Seite, wo kurz und knackig steht, was ich wie zutun habe. Nur sehr aufwendige Dinge sind lange dokumentiert, da muss man teilweise aber auch jeden Schritt einzeln durchgehen um nichts falsch zu machen.

Bedeutet die Konfiguration von Systemen ist nicht (ausführlich) dokumentiert? Bei euch ist die Doku eher ein "Alltagshandbuch"? Wenn ich jetzt wissen will wie etwas eingerichtet wurde muss ich also direkt ins laufende System greifen?

Ok,  dann mal konkrete Fragen:

Hat jemand seine AD Infrastruktur dokumentiert, oder ist das AD selbst Doku genug? Was ist mit dem Exchange? Spezielle Einstellungen, alles oder nichts? SQL Server? vSphere? Schnittstellen zwischen Systemen (wer schiebt wann wo Daten hin, wann laufen wo welche Jobs, wo kloppen sich ggf. CronJobs und Backup...)

[charmanta]

vor 10 Minuten schrieb Maniska:

Kann ich mit der Nennung eines Serviceaccounts (und ggf dessen Zugangsdaten) gegen den Datenschutz verstoßen?

hier nur gegen Vertraulichkeit. Aber zb bei einer Liste von Administratoren, Auszügen der Userdatei etc bist Du sofort im Thema

[Schengel]

vor 21 Minuten schrieb Maniska:

Das wäre...?

Ich meine, wie oft müssen Sachen vorkommen damit man sie als "Tagesgeschäft" bezeichnen würde (wäre "Drucker auf dem Printserver einrichten Tagesgeschäft, oder kommt das doch so selten vor dass man es dokumentieren sollte oder "weiß man ja eh wie das geht"), gibt es ggf Dinge zu beachten, wie werden Drucker ggf gemapt, muss da noch was gemacht werden. Oder muss ich den Prozess "Backup" dokumentieren? Ist ja Tagesgeschäft, aber der Azubi wird das ohne Doku nicht

Klar - wer definiert "Tagesgeschäft". Bestes Beispiel: Ein neuer Laptop wird über unser Softwareverteilungssystem eingerichtet. Da wir aber jetzt auf Windows 10 umgestellt haben werden dort einige Dinge anders gemacht als die Jahre davor unter Windows 7. Wir müssen aber nicht jeden Tag einen Laptop neu aufsetzen, das ist dann schon eher ein Ding was in die Schublade "schreibs in die FAQs, wenn wir's nochmal brauchen gucken wir halt da rein" fällt. Drucker auf dem Druckserver hinzufügen dagegen ist nicht dokumentiert, das ist dann eher so ein Ding "das weiß man ja eh, wenn ein neuer Azubi fragt erklärt man es ihm ein Mal". Fragwürdig - auch irgendwie schwer zu erklären - aber ich glaube das ist überall irgendwie anders gehandhabt. 

vor 21 Minuten schrieb Maniska:

Das sind aber unterschiedliche Ansprüche, für einen ungelernten (Azubi) muss ich anders dokumentieren wie für eine Fachkraft. Bei letzterer kann ich davon ausgehen dass ich keine Basics erklären muss, vgl. charmants Beispiel mit dem Solaris Serviceprozessor. Von einer Fachkraft kann ich erwarten, dass sie prinzipiell weiß wie man da hinkommt (oder sich den Weg ergoogeln kann), bei einem Azubi nicht.

Naja - eine Fachkraft versteht aber auch die Dokumentation, die ein ungelernter Azubi versteht. Hier werden dann aber auch die Aufgaben anders verteilt. Nach Beispiel von Charmanta, der ungelernte Azubi wird anfangs nichts mit dem Solaris Serviceprozessor zutun haben, sondern die Basics lernen. Nach und nach lernt der Azubi mehr und wird auch an die komplexeren Dinge herangeführt, irgendwann versteht er auch die "komplexeren" Dokumentationen.

vor 21 Minuten schrieb Maniska:

Und wie pflegt ihr das wenn es pdf Dateien sind? Die Officedokumente müssen ja auch irgendwo rumfahren und ich kann mir nicht vorstellen, dann jemand der nur eine kleine Änderung gemacht hat eine pdf erneuert (als wieder bearbeitbar macht, die Änderung einträgt und erneut speichert).

Dinge, die sich nicht absehbar ändern, werden als PDF gespeichert. Sollte es sich ändern haben wir die .docx Dateien dazu auch noch rumfliegen, ändern die und konvertieren die wieder um. Im Outlook wird das nicht mit den PDF-Dateien gehandhabt, sondern im öffentlichen ordner werden Beiträge erstellt, welcher von jedem ersichtlich bearbeitet werden kann.

 

Hoffe das das irgendwie verständlich ist, aber ich glaube dieses Thema ist so breit gefächert, dass man garnicht wirklich rechtfertigen kann wie man was warum dokumentiert, da läufts warscheinlich mehr nach never change a running system - hat immer so geklappt, wird auch in Zukunft klappen.  Als ich hier hin kam war das schon so und das wird auch noch so bleiben bis ich wieder gehe, denke ich. Weil es einfach klappt. Die sinnvollste Lösung führen wir definitiv nicht, da werden sich einige warscheinlich an den Kopf fassen und fragen, ob es denn noch umständlicher geht. Aber naja.  

Bearbeitet 30. Juni 2020 von Schengel
fatfinger

[allesweg]

Auch Tagesgeschäft muss dokumentiert sein. Wie soll man nachweisen, dass der Ablauf korrekt ist? Wie läuft eine Einarbeitung?

 

[Maniska]

vor 10 Minuten schrieb allesweg:

Auch Tagesgeschäft muss dokumentiert sein. Wie soll man nachweisen, dass der Ablauf korrekt ist? Wie läuft eine Einarbeitung?

Ich bin der Meinung dass, gerade Tagesgeschäft dokumentiert gehört, und dazu gehört nicht mal unbedingt der Ablauf von "wie lege ich eine neuen User an" oder "wie werden Berechtigungen auf dem Filesystem geändert", sondern auch und vor allem der dazugehörige Prozess "WER muss mir die Info geben?" bzw "wer ist überhaupt berechtigt mir diese Info/diesen Auftrag zu geben?".

vor einer Stunde schrieb charmanta:

hier nur gegen Vertraulichkeit. Aber zb bei einer Liste von Administratoren, Auszügen der Userdatei etc bist Du sofort im Thema

Was ist hier besser, bzw wie schaffe ich den Spagat? Geht das überhaupt?

vor 52 Minuten schrieb Schengel:

Drucker auf dem Druckserver hinzufügen dagegen ist nicht dokumentiert, das ist dann eher so ein Ding "das weiß man ja eh, wenn ein neuer Azubi fragt erklärt man es ihm ein Mal". Fragwürdig - auch irgendwie schwer zu erklären - aber ich glaube das ist überall irgendwie anders gehandhabt. 

Dann komme ich als Fachkraft und kann zwar den Drucker auf dem Druckserver einrichten (wenn ich ihn denn finde -> dokumentierte Namensgebung, IP-Liste, Zugriffsrechte...). Und dann? Wie werden bei euch die Drucker verbunden? Loginskript? GPO? Händisch mappen von Printserver? Voodoo?

Zitat

Naja - eine Fachkraft versteht aber auch die Dokumentation, die ein ungelernter Azubi versteht.

Aber welche Ansprüche kann ich an eine Fachkraft stellen? Ein Exchange-Guru braucht wenig Doku was Exchange angeht, nur habeich den in einem KMU nicht unbedingt zur Hand. Also muss ich für 0815 Fachkraft (frisch ausgelernter Azubi?) dokumentieren. Was benötigt der, um sich an einem fremden System recht zügig zurechtzufinden? Klar, er kann sich die einzelnen Konfigurationen ansehen, aber wenn die Sendeconnectoren kryptisch benannt sind oder es zig verschiedene gibt die aktiv/inaktiv sind.. was davon kann weg? Try and Error ist da blöd

Zitat

Hoffe das das irgendwie verständlich ist, aber ich glaube dieses Thema ist so breit gefächert, dass man garnicht wirklich rechtfertigen kann wie man was warum dokumentiert, da läufts warscheinlich mehr nach never change a running system - hat immer so geklappt, wird auch in Zukunft klappen.  Als ich hier hin kam war das schon so und das wird auch noch so bleiben bis ich wieder gehe, denke ich. Weil es einfach klappt. Die sinnvollste Lösung führen wir definitiv nicht, da werden sich einige warscheinlich an den Kopf fassen und fragen, ob es denn noch umständlicher geht. Aber naja.  

Meine Idee war, hier in diesem Thread Anregungen zu sammeln, was man in welcher Ausführlichkeit dokumentieren sollte/muss und was aus welchen Gründen nicht. Irgendwie geht das gerade in einen andere Richtung

[TooMuchCoffeeMan]

 

vor 3 Stunden schrieb Maniska:

Wie viel Doku ist notwendig, was ist "zu viel"?

[...]

Das kommt darauf an was mit der Dokumentation bezweckt werden soll.

Geht es um das Anlernen neuer Mitarbeiter? Dann ist wahrscheinlich eine Wissensdatenbank, vielleicht in Form von Confluence oder einem Wiki die beste Möglichkeit. Wie tiefgehend die Dokumentation sein muss, hängt davon ab was den neuen Mitarbeitern beigebracht werden soll. Zumindest aber würde ich eine Dokumentation gängiger Prozesse erwarten. Wenn es Vorgaben bzgl. der Konfiguration gibt, sollten diese ebenfalls entsprechend dokumentiert sein. Wie man z.B. einen Benutzer in einer Windows Domäne anlegt, einen Port in der Firewall öffnet oder wie man mit einer IDE umgeht würde ich nicht dokumentieren. Derartiges Wissen setze ich entweder als gegeben voraus oder es muss über Schulungen vermittelt werden.

Müssen Auflagen einer Zertifizierung (z.B. ISO 27001) erfüllt werden? Wenn ja, folgt man dem Buchstaben der entsprechenden Vorlage und erstellt mindestens die Dokumente die gefordert sind. Bei der Tiefe der Dokumente würde ich mich an der Unternehmensgröße und dem vorhandenen Risiko orientieren.

Soll Wissen für alltägliche Problemlösungen dokumentiert werden um die Effizienz zu erhöhen? Auch hier bietet sich eine Wissensdatenbank, am besten in Verbindung mit einem Ticketmanagementsystem (Jira etc.) an.

Soll die Infrastruktur dargestellt werden? Hier eignet sich vermutlich am Besten ein Asset Management System, das up-to-date gehalten wird. Vielleicht in Kombination mit einem VM System wie Nexpose, das die IP Adressen und sonstige Daten der Assets über automatisierte Scans aktualisiert. Über Drilldowns könnte man die Informationen dann so detailliert darstellen wie benötigt.

vor 3 Stunden schrieb Maniska:

Müssen z.B. GPOs noch einmal dokumentiert (gesichert ja, aber dokumentiert?) werden oder ist die GPO selbsterklärend?

Das Minimum ist hier für mich ehrlich gesagt ein Berechtigungskonzept. Die GPO ist am Ende nur die technische Umsetzung und muss meines Erachtens nach nicht dokumentiert sondern nur gesichert werden. Was über die GPO umgesetzt wird, sollte allerdings in einem möglichst ausführlichen Berechtigungskonzept aufgeführt werden. Da würden sich dann z.B. auch Service Accounts drin wieder finden. Zudem sollte der Funktionstrennung Rechnung getragen werden.

Im Rahmen von ISO 27001 Audits waren die besten Lösungen die ich bisher gesehen habe diejenigen, bei denen Dokumentationen in einem DMS zentral gemanaged wurden. Dokumentationen sollten lebende Dokumente sein und Änderungen müssen über eine Historie (Wer, Wann, Was, Warum) nachvollziehbar sein. Denkbar ist hier auch ein Pyramidensystem bei dem verschiedene Detailierungsgrade absteigend sortiert sind. Standard Operating Procedures (SOPs) sollten hier die Arbeitsgrundlage für die Mitarbeiter bilden, während Leitlinien die Spitze der Pyramide darstellen.

Bei Softwareentwicklung habe ich im Rahmen eines PS880 Audits gute Lösungen durch Kombinationen von Jira und Confluence gesehen. Jira für die Dokumentation von User Stories und das Abbilden der Features. Das Ganze dann verknüpft mit einer Confluence Wissensdatenbank die das Feature vertiefend beschreibt und eine Historisierung ermöglicht. Gleichzeitig kann ich über die Tickets nachweisen wann welche Features in welchem Umfang in meine Software übergegangen sind. Außerdem kann ich Tests und Abnahmen dokumentieren und nachweisen.

Beim Thema Dokumentation könnte ich wahrscheinlich noch viele weitere Beispiele aus meinem Arbeitsalltag bringen, da das Prüfen von Dokumentationen zu meinen Tätigkeiten gehört. Es ist jedoch dabei immer wichtig sich die Frage nach den Vorgaben bzw. dem Zweck zu stellen. Und damit komme ich wieder auf meine anfängliche Aussage zurück: Es kommt drauf an.

[Maniska]

vor 6 Minuten schrieb TooMuchCoffeeMan:

Das kommt darauf an was mit der Dokumentation bezweckt werden soll.

Gehen wir davon aus, dass ein Admin die Firma verlassen wollen würde, das Wissen, das aktuell nur im Kopf vorhanden ist zu Papier bringen will, als Tools Office und Boardmittel und als Ablage ein Fileserver zur Verfügung steht.

 

vor 9 Minuten schrieb TooMuchCoffeeMan:

Das Minimum ist hier für mich ehrlich gesagt ein Berechtigungskonzept. Die GPO ist am Ende nur die technische Umsetzung und muss meines Erachtens nach nicht dokumentiert sondern nur gesichert werden. Was über die GPO umgesetzt wird, sollte allerdings in einem möglichst ausführlichen Berechtigungskonzept aufgeführt werden. Da würden sich dann z.B. auch Service Accounts drin wieder finden. Zudem sollte der Funktionstrennung Rechnung getragen werden.

Berechtigungskonzept ist vorhanden und dokumentiert, sowohl grundlegendes Konzept zur Benennung der Objekte als auch auch die Verwendung der Gruppen. Was mich jetzt irritiert, warum verwendest du GPO  (Gruppenrichtlinienobjekte) und Berechtigungskonzept "im selben Satz"? Eine GPO hat mit Berechtigungsgruppen ja erstmal nicht zwingend was zu tun sondern wirkt auf die OU, erst mal unabhängig von AD-Gruppen. Oder versteh ich dich hier falsch?

[Rabber]

Für uns ist Dokumentation in erster Linie dazu gedacht, dass Kollege A Kollege B vertreten kann. Im Urlaub, bei Krankheit o. Ä. Die Zielgruppe ist somit grundsätzlich fachkundig (auf das Handwerk IT bezogen) aber nicht fachkundig bezüglich des konkreten Projekts.

Von daher genügen bei uns stichpunktartige Auflistungen. Wo finde ich welches Programm, in welcher Tabelle stehen welche Daten, in welcher Konfigurationsdatei stehen welche Optionen, wer ist Anwender, wer ist Entwickler und wo finde ich die source files sowie den Produktionsbuild.

Dadurch, dass wir ein typisches KMU sind, ist das ausreichend. Und leider aufwändig und schwierig genug. Es einzuführen genauso wie einigermaßen aktuell zu halten. Das klappt bei einigen Kollegen super, bei anderen mittelmäßig und bei anderen gar nicht. Trotz zahlloser Besprechungen, Ermahnungen, Rundschreiben, Arbeitsanweisungen, usw.🤔

[TooMuchCoffeeMan]

vor 21 Minuten schrieb Maniska:

Gehen wir davon aus, dass ein Admin die Firma verlassen wollen würde, das Wissen, das aktuell nur im Kopf vorhanden ist zu Papier bringen will, als Tools Office und Boardmittel und als Ablage ein Fileserver zur Verfügung steht.

Ok, verstehe. Das ist natürlich der kleinste gemeinsame Nenner

In dem Beispiel gehe ich mal davon aus, dass es außer dem Berechtigungskonzept (s.u.) nichts gibt. Das Wissen in seinem Kopf kann er natürlich nicht vollständig dokumentieren, aber ich denke du meinst Wissen in Bezug auf die IT Infrastruktur eures Unternehmens. Dann würde ich (auf der grünen Wiese) erwarten, dass er u.a. erstellt / hat:

- Eine Assetliste mit Desktops, Laptops, Druckern und anderen Enduser Geräten in Excel anfertigt. Inklusive Besitzern und Seriennummern.

- Eine Assetliste mit Servern in Excel. Inklusive Applikationen die darauf laufen und deren entsprechende Application Owner.

- Eine Übersicht über euer Netzwerk. VLANs, Router, Switches, vielleicht eine kleine Zeichnung zum Thema DMZ und was sich darin befindet. Dazu eine Übersicht in Excel welche IP Adresskreise genutzt werden und von welchen Geräten (Server, Desktops, Drucker, Kameras etc.)

- Eine Übersicht der genutzten Applikationen sowohl auf Desktop Ebene. Gibt es vielleicht ein System zum Rollout?

- Übersicht der gekauften und genutzten Lizenzen in Excel.

- Übersicht speziell angelegter administrativer Accounts oder Service Accounts.

- Übersicht speziell erstellter Software und Schnittstellen (Stichwort Frickelbude).

- Übersicht aller bereits erstellter Dokumentationen, Arbeitsanweisungen, Richtlinien usw. und deren ungefährer Inhalt Zusammengefasst in einem knackigen Satz.

- Übersicht genutzter externer Dienstleister und deren Kontakte, Ansprechpartner.

- Übersicht geschlossener und laufender Verträge.

- Übersicht über geltende SLA.

- ...

 

vor 21 Minuten schrieb Maniska:

Berechtigungskonzept ist vorhanden und dokumentiert, sowohl grundlegendes Konzept zur Benennung der Objekte als auch auch die Verwendung der Gruppen. Was mich jetzt irritiert, warum verwendest du GPO  (Gruppenrichtlinienobjekte) und Berechtigungskonzept "im selben Satz"? Eine GPO hat mit Berechtigungsgruppen ja erstmal nicht zwingend was zu tun sondern wirkt auf die OU, erst mal unabhängig von AD-Gruppen. Oder versteh ich dich hier falsch?

Ich denke ich habe mich nicht gut genug ausgedrückt. Was ich meine ist, dass es dokumentierte Vorgaben geben muss, die dann technisch umgesetzt werden. Zum Beispiel die grundsätzliche Vorgabe welche Berechtigungsgruppen es geben soll und worauf diese Zugriff haben etc. Das kann man über das Berechtigungskonzept abbilden. Die Vorgaben für die GPO würde ich dann wohl eher in einer Richtlinie zum Umgang mit Hard- und Software oder einer Security Policy erwarten. Wie auch immer man es schneiden will, die technische Umsetzung muss den schriftlichen Vorgaben entsprechen.

Bearbeitet 30. Juni 2020 von TooMuchCoffeeMan