When it comes to documenting
the internal processes and procedures for
an organization, every company is going to
be a little bit different. There will obviously be very
different business objectives between organizations, so
the processes and procedures may be dramatically different
from one organization to another. Because of that, it's
incredibly important that you have
documentation on how you handle all of these
internal operating procedures within your organization. For example, when
a system goes down, there may be a specific
notification process. This may be an
electronic notification, or your processes may
require that you call someone directly to let them know. If there are
facilities issues, you need to know exactly
how to handle that. And so there should be a set
of processes and procedures for that as well. We can also create
processes and procedures for very specific tasks. For example, if we want to
do any software upgrades, there may be a
process that requires that we test the
software upgrades and go through a formal
change control process. It's important that all
of this documentation is available to
whoever might need it. That way, it doesn't matter what
happens in the organization. You know exactly
the process that will be followed to
resolve that issue. In the networking world,
a lot of our documentation is on the network. There are so many different
components to the network, and we're not usually
building it all at once. It's usually built over
a long period of time through multiple phases. Once it's built,
you may not even know exactly where the wires,
the fibers, and the cables might be going. It's all inside of the
walls and the ceiling, and it may take an
additional effort to be able to document
all of that information. We also tend to create different
types of documentation. There may be a set
of logical documents and a set of physical documents. And creating and maintaining
this documentation may be one of the best
pieces of information you have from a
networking perspective. Everyone will understand
the layout of the network, and it's nice to
have documentation that you can share
with a third party to perform whatever
task may be required. For network
documentation, we tend to use a standard
set of symbols that look very similar to these. If you're documenting
a router, it's usually a circular device with
arrows pointing in and out. Whereas a switch
may be a square with arrows pointing only one
direction or the other. Firewalls might look like an
actual firewall, and so on. This makes it easier when
working with third party documentation because you
can recognize exactly what icon is associated
with which components. We covered logical and
physical network diagrams a bit in section 1.5 under
network typologies. But let's quickly review
some of that information. When you're creating
logical network maps, you're building out
a broad perspective of the way the network
might be configured. You can usually create
this documentation with software such as Visio,
OmniGraffle, or third party websites. This is a high level
view, and it gives you a perspective of how the
network may be connected at a very broad level. It's not showing specific
components or exactly where wires may be going,
but you can understand by looking at
diagrams like this, exactly what sites
are connected and how they connect to each other. This is helpful if you're
working with a third party that needs a general understanding
of how the network is designed. If more details
are required, you can move from a
logical network map to more of a physical layout. Physical network maps will show
individual components inside of the network. It will identify specific
interfaces on devices. It may show IP addressing. And it gives you an
idea of exactly where wires and cables may be running
between different devices. Some physical network
maps will show the physical layout of the
rack that's in the data center. This way, you can
show this rack diagram to a third party who may have
never seen this rack before, and they'll know exactly which
component you're referencing. In the world of
information technology, nothing remains the same. There are constant changes
that are occurring. You may need to
upgrade software, make a firewall
change, or you may need to modify the
configuration of a switch. Any time a change is made
to any piece of hardware or any piece of software, there
is additional risk associated with that modification. You might be changing
a piece of software, but you've overlooked that
that particular change is going to break another
piece of that software. So a simple upgrade can turn
into a very significant change that can affect the
entire organization. This is why many organizations
will implement a formal change control process. You can't make any type
of change to any component unless it goes through
a formal committee. That particular
change is documented. You have a fallback plan if
that particular change doesn't work properly. And everyone knows that that
change is going to occur. In many organizations,
this change control process is a normal part of business. Everyone knows about the
change control process and nobody makes any
changes until it's gone through the formal committee. In some organizations,
though, change control is not part of the
corporate culture. And it may be difficult to
implement a formal change control process unless you
get the buy in from everybody in the organization. As network professionals,
we deal with a lot of different network cables. And it may not
surprise you to know there is a standard
for administering this on the ANSI/TIA/EIA 606. This is the
Administration Standard for the Telecommunications
Infrastructure of Commercial Buildings. This will provide
you with information on how to document the network. There'll be sample reports, how
you would draw out the network, and how work orders might look. You have, of course, many
different cables going many different places
on your network . And you need some way to
identify these cables. These might be in a pathway. They might be in a space. There's grounding cables
that you would use. And you need some way
to identify and label all of these different
cables that you might use. You would use
identifiers on the cables such as labels, some color
coding, and barcoding. That could help anybody who
happens to walk in the door understand everything they
need to know about your cable infrastructure. Here's an example of
a standard layout. You could decide
on different colors to use for different
tags for your labels. Some that might be
demarcation point cables. You have network connections
that might be green, and you might have station
termination colored as blue. You can also use a standard
port labeling format so that you could reference
an individual port that might be in a particular building. For example, a
port CB01-01A-D088 would be at CB01, which
is the abbreviation for the main facility. It would be a 01A, which
is floor one space A, and then the interface
itself would be data port 88. And by having that entire
label, you can reference that, hand it to a third party, and
they know exactly what port you're referencing. It's very easy these days
to also document and keep a database of all
of this information. So if anybody needs to
know exactly how many ports may be in a particular
building or particular floor, you can look that
information up very quickly. The same thing applies for the
servers that we might be using. There's a physical device
that's in the data center. And you need some way to tell
someone else exactly which component you're referencing. You can do that by
creating a unique system ID for every device. It may have an asset
tag associated with it. There might be a system
name and a serial number. And you want to make this
clearly visible on the devices. These servers have physical
tags associated with them, along with serial
numbers and information written on the
device themselves. So you can hand someone
else the documentation of exactly what you need to have
performed on that exact device, and this makes it very easy to
find this device in the rack. Here's a better look
at these servers. You can see there's barcodes
or asset tags on these device. There's labels that identify
the name of the device. And then there's an
extra tag associated with the device as another
piece of documentation that someone can reference
when they're looking for that individual server. Most organizations have
a number of WAN circuits that may be coming
into the building. So it's a good idea to also
label all of those circuits as well. WAN circuits can
operate normally, and then suddenly
not operate at all. Not because of something
that's inside of your building, but with something that
might be between your site and the other one, which you
obviously have no control over. Because of that, you'll
need to document exactly which of those WAN circuits
may be having a problem. You need to document the demarc
interface for that circuit, the associated CSU/DSU that's
connected to that demarc, and perhaps even
the router that's connected to the CSU/DSU. You want to know exactly
what circuit ID is associated with that way in connection,
the WAN provider and the phone number for their
help des, and then perhaps an internal
reference name that you can use when putting
internal reports together. If you have a
monitoring system, you may want to include
all of this information with the monitoring system. And if an error or
an alert is created, it will have all
of the details you need to be able to communicate
with the WAN provider. The patch panels that are
in our network closets have a number associated
with a port that's somewhere out on the floor. We want to somehow
associate and document those port numbers on the
patch panels themselves. You can see some documentation
on this patch panel. And from here, you know
exactly what port on the floor is associated with which
port on the patch panel. These numbers are
usually unique. They usually increment
in a particular area. And they may be
geographically descriptive. There may be an east
or west designation. In some IDFs or
MDFs, there may even be a blueprint of a floor that
documents exactly the numbers for every cube in every office. Another good piece of
ongoing documentation is a baseline of how the
network is operating. With this baseline,
we're able to understand the normal utilization
for the network, what the normal response times might
be, and what type of throughput we would see at certain
times of the day. From here, we can look
at what's happening now and compare it to what
happened in the past. We can plan when we're going
to hit certain thresholds based on the activity we've
seen in the past, and that might help with
our budgeting process. We may not want to increase
the overall bandwidth available on a
network connection and pay the extra money
until exactly the point it's needed by the organization. Here's some baselines that have
been created for a web server. You can see the amount
of accesses per day over the last day or so. Here's the Apache
accesses by week. And you can see the individual
days and exactly how many accesses have occurred. You can also see by
month and even by year. This might give
you an idea of what times of the year or
times of the month may be busier than
others, so that you can adjust the resources
required to provide services on your network. It's also useful to have
documentation of what devices you might have on your network. You need a record of
every single asset. So this would include the
routers, the switches, the cables, any fiber modules,
CSU/DSUs, and any other network equipment that you have
in your infrastructure. This is not only going
to help you understand what equipment you have and
where it may be located, but it will help your
accounting team understand how the depreciation of these
devices will be handled. Some organizations will even
add an asset tag to the device. So not only are you
keeping a database of where this device is, you
have a tag on the device that clearly identifies and
has a visible tracking number of exactly how
this is associated back to your database. The database itself is probably
going to be a formal inventory management software. This could include
not only the inventory of all of your
devices, but it might include helpdesk and reporting
functionality as well. And as the organization
gets larger, you can add all of the new
assets into the database and you'll know exactly where
this inventory happens to be.
