| Freitag, 15. Juli 2005 um 00:00 Uhr |
|
Why a network documentation? by Aleksandar Čupić
1 Current status
In many companies the IT documentation with IT structures, IT processes and IT rules still respite a shadowy existence. The available documents very often correspond to no standards. The questions towards a documentation directive or other reliable guidelines for the documentation are not, or only inaccurately answered. It doesn’t matter whether it is just a reorganization or waiting for a certification for an approved standard (ISO). Today every company needs an understandable documentation of the IT processes and the IT systems.
System administrators and developers mostly neglect the documentation because they believe; other tasks would have a higher priority. However, a not inessential point also might be that often the knowledge is absent how to take action and to create such a document. The managements also often do not consist on an orderly documentation because it costs time and with it money. In practice the terms IT documentation and IT analysis are mostly connected to taking stock and at best the visualization of the available hardware and software. If a malfunction or an emergency occur, or an important IT employee leaves the company, the situation can become very critical. It can be also be used for a new construction of the overall systems as well as some of the subsystems, as for example an upgrade or a loss. It simplifies definitively training of new employees, but also the passing on to possible Outsourcer.
2 Reasons for a network documentation
Network documentation is no aggregation of reference manuals, regulations or training material. It should reflect the technical actual state of the company’s network at the time of the production (active and passive components, measuring protocols, wiring diagrams etc.). With this, technical information network problems can be repaired and IT-Support could be performed faster and much more efficient. With these detailed knowledge of the network infrastructure, it is possible to recognize weak spots and potential bottlenecks on time, deduce the strategically measures for the improvement of the stability of the network and therefore to increase the network security as well.
2.1 The network documentation:
Thus it contains all important information about the complete IT infrastructure. This has to be clear shown in tables, documents and graphics to allow the quick access. Besides, it should not be overall, but any hardware and components should be listed.
Besides, it may not be neglected that in addition, the information of the technical network documentation finds also use in other departments. These data can flow in onto the production of controlling- or quality management reports, data protection reports or as a preparatory work for ISO certifications.
2.2 Some areas of application of the technical network documentations in short:
3 Production and contents
3.1 In general
How quite on top mentioned, the documentation should not be all-embracing. However, there are different points, although they have nothing to do directly with the network itself, they are important and with regard to the total overview of the company they should flow in:
3.2 Charts and plans
As the first step one should apply a ground plan of the building. In this ground plan one can number consecutively the rooms and determine the unambiguously location of every IT component.
Then one should graphically represent the network in the so-called network architecture. With computer name and IP addresses, the static addresses if provided and if not only a DHCP server is used. Further charts can follow, a chart for WAN or LAN as well as for infrastructure and network jacks.
3.3 Hardware
The used description for the infrastructure should include: data cable, Switch/hubs, routers, firewalls, patch cables management, Wireless Access points and antenna. To keep a better overview it helps to write down the serial numbers and to create an internal initials system: Example would be for the router R1, R2..., Rx.
We divide the computers in the network into two groups: Workstations and servers. All the serial numbers, hardware equipments, software, computer name and the users should appear.
One should proceed with all peripheral devices. So Print Server, printer, copier, USB hubs, local printers, keyboards, mice, Monitors are to be recorded etc.
3.3.1 Infrastructure
Following questions could be helpful to create this part of the documentation:
Which printers or other peripheral devices exist? Are they local or global connected? Which are parts of the network? How are they installed? Who is responsible for the supply of consumer goods? Are there spare devices for the most important printers and routers, and who installs them?
3.4 Administrative
Now you created some kind of an inventory, so, why not make use of it. Best would be to visualize the logical structures of all servers. A logical and physical structure of the Active Directory and a logical structure of the DHCP should follow. Which addresses are used, which subnet, domains and gateways? How is the file system structured and how are the rights distributed to the different users and groups?
If one has this so far, one can bring the computers in connection to users and their passwords. Furthermore the best to include here would be all the configuration of the groups, login Scripts and Policies and the used protocols..
One can register the configuration settings of the single components in a data sheet. To this category belong, e.g., tasks of a server (Print server, file server, fax server, domain controller) or the dial-up data of the DSL router on the Internet. In addition, the listing of support information, as for example contact with the manufacturer or the data of the stack support should not be underestimated. In a so-called user's documentation, data of the users are recorded, thus, e.g., the full name, login, group affiliation, e-mail address and account policy.
3.5 Software
At this place of the document the big advantage shows up again of creating an inventory with shortcuts. Thus it is easy to produce a connection between the user, the used computer and the software installed on it. Thus here are described the installed operating system (Win, LINUX, MacOS etc.), the application package. Company-in-house application package, driver, used CRM software and databases with their structure are also mapped here. A software matrix gives one an overview about which software is installed on which component. It is the basis for the checking of licenses.
A standard software list can be very helpful at bigger companies. They contain those software products which must be installed basically on every client.
3.6 Internet
The Network in a company does not limit itself to the intranet any more. This indicates that the Internet and the access to it in addition likewise need to take place in the network documentation.
It starts with to list the Internet service provider (ISP) with the access data. Is a backup ISP available this one should also be listed at the same place. Depending on whether a DHCP or static addresses is used the configuration should be displayed here as well. Also the associated devices should appear in the list. The used technologies (DSL, ISDN etc.) to enter the Internet, their configuration and a description how they are installed, also find their space here. Is there an existing WLAN, it takes place here as well, with their configuration, number, user's rights and passwords. With a possible Remote Control the same.
From further interest are the used browser and mail program and their configuration. Is a mail server available? May the accounts be also used privately? Where and how the mails are saved? Which access rights and account policy (from the outside), exist? How do the mail addresses look like? Which protocols are used? These are the other questions whose answers should appear in the documentation.
3.7 Security
The safety regulations are another point that should appear in the network documentation. At this point the rights of the users and administrators should flow in. Authorizations to the single network folders, as well as juridical and industrial regulations likewise belong in. The questions what is logged and how they are saved and stored as well as the observance of the data privacy are likewise to be taken into consideration.
3.7.1 Energy failure
Another big position is the energy backup. The following questions should be answered. How are the network and their computer saved from energy fluctuations and energy failure? Are UPSs used for it? If, has every computer/ server an own one. If, how these are configured and are they monitored by the UPS own software? For how long can the energy input be held straight? Is there a maintenance schedule for these devices and who is responsible for it? Are there other safety measures for an energy loss (e.g. generators)?
3.7.2 Securing of the infrastructure
With the description to the physical safety measures, concerning the server space and the other infrastructure one should explain the regulations. Thereby should be listed in detail the safety measures, access data and the persons who are responsible and have access.
3.7.3 Anti
If one speaks of security, one will have difficulties to forget about the whole Antis. Like Anti Virus, Anti Spam, Anti Spyware etc. Taken into consideration should become that the attacks are not only come from the outside (internet), security could be compromised from inside (employees) as well.
In any case all computers/ servers who are protected should be listed, thus also their configuration, update procedure (are they updated per machine or centrally) and whether it is a hardware or software solution.
3.7.4 Backup
Should it have come, nevertheless, despite of all precautions, to a data loss, one needs a backup to restore the system and the data. For it one needs archiving procedures that describes how to do the backup and the recovery of the internal data.
And again the used software and hardware should be listed. How it is configured and what kind of backup procedure have been used. Whether the backups are done automatically on all machines or every single workstation has their own, are likewise important. Of course the information about encoded and by password protected backups should be found as well. The responsible persons with their contact addresses are also of interest. A so-called Disaster recovery, which should explain how to react if an error in the hardware occurs or the forces of nature strike (e.g., water), one may also not forget.
3.8 Action instructions
For all recurrently processes, action instructions should be are written as a Step-by-Step instruction. These contain the necessary information for a trouble-free execution of the processes.
Examples of standard procedures are:
4 Closing marks
As one is able to see a network document is not even created like that. If one does not exist, it should be well considered, if one should not be created. Because a lot of time is needed one can maybe persuade a responsible person to purchase a professional tool for the production of the documentation. If this is no option one must do it on his own. Better to create a short one in the beginning that could develop over the time, than none.
What should be at least documented?
Shortly:
5 Sources
Computernetzwerke; Andrew S. Tanenbaum; Prentice Hall/ Pearson Studium 2003, 4 Auflage Informatik-Handbuch; Rechenberg und Pomberger (Hrsg.), Hanser 2002, 3 Auflage The Encyclopedia of Networking; Werner Feibel; Sybex Inc., 1997, Second Edition Encyclopedia of Networking and Telecommunications; Tom Sheldon; McGraw Hill , 2001, Third Edition Netzwerke, Kompendium; Burkhard Müller; Markt + Technik Verlag 2003, 1 Auflage PC-Netzwerke; Axel Schemberger, Martin Linten; Galileo Press GmbH 2004, 2 Auflage
WizFlow Flowcharter – User’s Guide – 2003 Pacestar Software DATAASSIST E.K. Netzwerkdokumentation mit NetDoc.ppt 2005
http://www.networknotepad.com http://www.hkielhorn.de NetDocu 3.3™ 2004 http://www.bildungsinitiative-networking.de/index.shtml ; cisco-systems; 2004 http://www.ipswitch.com/Products/WhatsUp ! ; 2003 http://wiki.opennet-initiative.de/wiki/Hauptseite http://www.bitsic.de – Beratung für IT – Sicherheit; 2004 http://blogs.ittoolbox.com/networking/documentation - NetworkDNA; 2004
|