Documentation - saving time or wasting time?
The art of organizing working time (time-management) has recently become increasingly popular, and if previously it was mainly related to managers at various levels, now the accumulated knowledge is beginning to be applied in other areas of the company.
Introduction
Every employee periodically feels the interest of management in order to find out what this person does during working hours. Of course, the authorities want to hear that time is spent on the good of the company. Especially, this is relevant for system administrators of companies whose leaders adhere to the position that IT department employees are “resting” most of the time. Often, precisely because of this common opinion, system administrators are almost in real time set tasks one after another. However, unfortunately, not many people know that staying up late at work or staying on weekends is not the only way to avoid cluttering up with tasks to such an extent that it starts to seem as if they will never run out.
The art of organizing working time is still a wonder for many employees and not necessarily just IT departments. It is usually considered that this task is solved by managers, but this is not the case. No one bothers even an ordinary system administrator, whose department has only one person, to learn how to spend time wisely. The organization of the working time of a sysadmin differs from the situation with managers due to differences in their spheres of activity. In the future, we will try to understand the essence of the differences and how to approach time management from the IT department. And to begin, perhaps, it is necessary with the documentation.
Documentation.
I want to immediately make a reservation that this article does not pursue the goal of uncovering all the issues of creating and maintaining technical documentation that may be required by the system administrator. Here I will only try to outline the circle of those documents that somehow have to be written by any employee of the IT department, if his tasks include documenting.
')
When buying any software or technical product, the user expects to receive along with him a package of documentation that will tell you how to use the newly acquired tool. Of course, I do not want to say that in the modern world, if you allow buying a server operating system, then you will definitely get along with the distribution kit a whole book “to the load”. Of course not. Book publishing not for nothing they eat their bread by releasing a bunch of wonderful materials that help newcomers and professionals learn to use the designs of various companies. In this case, I’ll rather talk about the in-built help help, which can bring in the minimum necessary clarity in the operation process, as well as documents attached to the “package” along with the disks.
This is if affect software products. Cases with purchases of "iron" in fact do not differ much from this, but the set of documentation, as a rule, is still wider. And it’s not so important that you bought a VCR, a stereo system or a SUN server - you will receive the minimum required set of documents. Moreover, we can safely say that the richer the set of documentation received, the more conscientiously the manufacturer treats his work. I think everyone faced situations at work when you receive the ordered equipment without any serious package of documents. If this is a server or workstations ordered in the configuration of your choice, this is not yet so critical. And if it is, for example, a mini-PBX, then the situation becomes downright unpleasant. In most cases, after some dialogue with the seller, it is still possible to obtain any accompanying documentation from him. And if not, then you may have to contact directly the manufacturer or the largest dealer.
The accompanying documentation is important for everyone, from the director of the company and the accounting department, to those who are to use the equipment (or software). It is necessary for a general idea of ​​what you have acquired, as well as for the banal accounting of the available enterprise.
With this, everything seems to be more or less clear. But what about what the company already has at the time of your arrival? It is good if the company is medium in size and it does not have dozens of servers and an extremely extensive infrastructure. And if there is? And what's more, not described in any documents? This can be a real nightmare for a new employee entering into their duties. After all, it is not easy to understand what is happening on the company's servers and what works for them. Much more needs to be done. Namely:
understand the structure of the local network;
understand the structure of the telephone network (Yes, yes, I know that most of the system administrators prefer not to indulge in telephony. However, as practice shows, to this day, many IT department employees have to not only know the structure of this whole "farm", but also take direct part in its refinement or even development.);
minimum need to know the capabilities of the existing power grid;
make a complete picture of the company's server park;
Understand the software running on the company's servers, about the schemes for solving various issues, backup systems and everything else that can be safely attributed to a huge front of work with new (for this employee) servers;
to make at least a complete picture of workstations;
know the full set of software adopted by the company's standards for employees (if there is one, and if not, then it can be developed, but more on that later);
find out the structure of interaction between an IT department employee and users, suppliers accepted within the company;
find out the scheme of purchasing new equipment, its ordering scheme;
have an idea about the office equipment owned by the company;
other items (of which there may be a great many).
This is just the main part of what the new employee has to grasp. And in situations where there is no one to give him up to date as much detail as possible, this can be a real headache. Even in cases of an increase in the staff of the IT department, it may take days and weeks to become fully acquainted. Meanwhile, users work, servers require the care they need, and there may be quite a few projects in the plans that also need the direct attention and participation of an employee.
Looks pretty sad. And the main reason for this is the lack of technical documentation, where all aspects of the work of the enterprise’s network infrastructure would be brought in in time. You can reflect on the topic for a long time, why every time he comes to a new place of work, the system administrator faces the above difficulties. This may be the inertia and negligence of previous employees (“I know how it works, and even the flood after me.”), And perhaps the banal ignorance of managers about the need for documentation to be held by the IT department. And what is not required is not done. This rule is extremely common with system administrators and not only regarding documentation. I think everyone has ever heard of a person who was not concerned with the development and commissioning of a backup system of all files vital for the company's work. In the same way, everyone knows what this leads to. Believe me, the lack of documentation sooner or later can lead to no less sad result.
What is technical documentation.
So, we have already talked about why we need technical documentation. Now let's understand what it is. If the answer to this question is addressed to the now so popular Wikipedia (wikipedia), then we get the following very specific answer: "Technical documentation - a set of documents used in the design (engineering), creation (manufacturing) and use (operation) of any technical objects: buildings, structures, industrial goods, software and hardware. ”In other words, a fairly wide range of documents relates to technical documentation.
Of course, not all of the above in the definition we are interested. The greatest attention should be paid to the item "software and hardware." That is actually what every system administrator works with.
For the creation and maintenance of technical documentation "according to the rules", there is a whole set of different state-accepted standards (GOST). Not always strict adherence to these standards adds information to the documents created and even more rarely is actually required. In any case, as long as we are talking about the documentation created for internal corporate use. Well, in fact, will you write such a complex document that complies with all the necessary requirements of the standard, if you just need to create a list of the most frequently used software by users. Moreover, many GOSTs are already “one hundred years old at lunchtime” and half the documents you may want to create a standard simply do not exist.
Compliance with all rules and regulations is necessary in cases where a package of technical documentation is prepared for an external user. For example, if you are going to sell (as an option, resell) the network infrastructure of your company when you change office. Here ESKD (Unified Structure of Design Documentation) and ESPD (Unified Program Documentation System), as well as other standards adopted in such cases, will come to your aid. But this is a separate long conversation and for the time being we will keep silent about it.
When to start keeping records.
A reasonable question that arises after all that we have learned above - when should we begin to keep records on the accountable “economy”. The correct answers would be - right away. That is, exactly from the moment the infrastructure of the future company began to be laid. There are no tens of meters of incomprehensible network, telephone and other cables. There is no confusion. Moreover, the proper planning of the future network of the company with the necessary plans, charts and descriptions, is already a huge reserve for a very weighty and extremely detailed package of technical documents.
However, as practice shows, these or other reasons always impede the proper conduct of business from the very beginning. The simplest thing that can come to mind is that a company enters a new office with an already existing network, for which there are simply no documents and schemes. Fortunately, in the last couple of years, there has been a picture of significant changes in the management approach to infrastructure in general and IT departments in particular. More and more often, before moving to a new office, repairs are being made in it, and a plan for the necessary communications with planning the location of the server room and network equipment is laid at the stage of the discussion of the possibility of moving. Of course, this greatly simplifies the work on the preparation of documentation in the future, since it solves a whole bunch of problems at once. Not to mention the disappearance of problems with non-working network outlets, wire breaks and so on. With this, too, every system administrator has to face more than once during his profile activities.
If these conditions are not fulfilled and you are the “owner” of the unknown network structure, you probably have already spent a lot of time trying to figure it out and understand “why this wire sticks out of the wall and where it leads”. I hope with the patch panels you have full order. Now is the time to set aside one or two working days for yourself to document all this. I hope you do not need to explain that you first need it yourself? It will not be too pleasant to remember your “inclinations” with unknown wires, when (or if) such a need will arise in the future.
This is the answer to the question “When to start creating documentation?”. If you don’t have one yet, start right today. After all, this is only the beginning of your work on writing a full-fledged package of documents on everything you work with. As you know, Homeland begins with a picture in the letter, and technical documentation of the system administrator from the network structure diagram.
Types of technical documentation.
As mentioned above, the network layout represents the greatest initial interest for the system administrator in the technical documentation, but this is not limited to this interest.
A short list of documents worth starting to create immediately after (or during) the network description:
description of the scheme of access to the Internet and intranet;
server description;
description of the backup system;
description of the company's anti-virus protection scheme;
a description of the standards used by software users;
other items already mentioned in the introduction.
Briefly consider this entire short (compared with the full) list of documents.
Description of servers.
Understanding each time (or remembering if you have a lot of them) that is on a particular server is not an enjoyable task. Especially if this particular server has been operating normally for a year and a half and does not require attention. At the same time, the creation of a file with a description of the operating system, running services, hardware component, functional significance and other "little things" does not require significant resources. After all, you are already working with these machines and you know what each of them is for. Collecting information is a matter of technique. You will only have to document all this and put it aside until the following changes, after which you must immediately make the necessary amendments. This will help maintain the relevance of the document and avoid headaches in the future.
Description of the backup scheme.
Strictly speaking, having described the correct backup scheme and adding to it a rationale for why this is important, you can safely go to the manual and ask for budget funds for a new technique. But for us it is important for another reason, which is known to everyone - the network without backup, this is a time bomb, which sooner or later will jerk so that no one leaves without "gifts." I hope you are not one of those lovers of luck who are postponing the solution of such an important task.
Description of the scheme of access to the Internet and intranet network.
The level of development of telecommunication companies has now reached the level when all sorts of competitive offers just flooded the market. This gives user companies a wide choice in the way and quantity of consumption of Internet access services. Taking advantage of this situation, many managers who are serious about uninterrupted access to the Internet and understand its importance have long ago (or have plans for the near future) to decide on a backup channel from one of the providers in the area. What is useful scheme with two providers have already been discussed more than once. If you already have two channels for accessing the Internet, then all you need to do is document this scheme. And if not, then what is not a reason to portray her and go with her to the leadership. How is this useful? Yes, at least by the fact that you yourself in the process of drafting the document create in your head a clear idea of ​​how this is done and can apply this skill at any time. Helpful? Still would.
In addition, it will not be superfluous to describe the scheme of access to the Internet and for users of the company. Traffic, of course, cheaper cheaper, but the practice of restricting access used is used more and more often. Moreover, if earlier most of the system administrators (or manuals) used a resource restriction scheme, now the most popular is the restriction on the amount of downloaded content. If you are still restricting users to the list of forbidden to visit resources, this is a good reason to switch to traffic restrictions. (Just kidding of course. This is a private matter of each system administrator and his management.)
Description of the company's anti-virus protection scheme.
What is important system of protection against viruses, every system administrator knows. And those who have already fought at least once with epidemics that occur even in a seemingly protected network, have long ago drawn up a complete protection scheme and led anti-virus protection on all workstations and servers to a “common denominator”. It sounds rather strange, but nevertheless, the fact is that in networks where antiviruses are installed, but there is no general protection scheme, sooner or later, a viral epidemic will definitely occur. In everything there must be order and the most transparent representation of the implementation. This also applies to protection against viruses.
Description of the standards used by software users.
Most medium and large companies have already adopted corporate standards for software used by users in their daily work. However strange it may sound, this is not documented everywhere. As a result, it is impossible to familiarize the user and introduce responsibility for compliance with what is not on paper. Where there are no rules, there can be no execution. , . , , « ». , . , , , , . (, .)
Conclusion
, , , . , , . , , «- ». , .
, . , , , … . Why not?
akeeper .
« ».
Introduction
Every employee periodically feels the interest of management in order to find out what this person does during working hours. Of course, the authorities want to hear that time is spent on the good of the company. Especially, this is relevant for system administrators of companies whose leaders adhere to the position that IT department employees are “resting” most of the time. Often, precisely because of this common opinion, system administrators are almost in real time set tasks one after another. However, unfortunately, not many people know that staying up late at work or staying on weekends is not the only way to avoid cluttering up with tasks to such an extent that it starts to seem as if they will never run out.
The art of organizing working time is still a wonder for many employees and not necessarily just IT departments. It is usually considered that this task is solved by managers, but this is not the case. No one bothers even an ordinary system administrator, whose department has only one person, to learn how to spend time wisely. The organization of the working time of a sysadmin differs from the situation with managers due to differences in their spheres of activity. In the future, we will try to understand the essence of the differences and how to approach time management from the IT department. And to begin, perhaps, it is necessary with the documentation.
Documentation.
I want to immediately make a reservation that this article does not pursue the goal of uncovering all the issues of creating and maintaining technical documentation that may be required by the system administrator. Here I will only try to outline the circle of those documents that somehow have to be written by any employee of the IT department, if his tasks include documenting.
')
When buying any software or technical product, the user expects to receive along with him a package of documentation that will tell you how to use the newly acquired tool. Of course, I do not want to say that in the modern world, if you allow buying a server operating system, then you will definitely get along with the distribution kit a whole book “to the load”. Of course not. Book publishing not for nothing they eat their bread by releasing a bunch of wonderful materials that help newcomers and professionals learn to use the designs of various companies. In this case, I’ll rather talk about the in-built help help, which can bring in the minimum necessary clarity in the operation process, as well as documents attached to the “package” along with the disks.
This is if affect software products. Cases with purchases of "iron" in fact do not differ much from this, but the set of documentation, as a rule, is still wider. And it’s not so important that you bought a VCR, a stereo system or a SUN server - you will receive the minimum required set of documents. Moreover, we can safely say that the richer the set of documentation received, the more conscientiously the manufacturer treats his work. I think everyone faced situations at work when you receive the ordered equipment without any serious package of documents. If this is a server or workstations ordered in the configuration of your choice, this is not yet so critical. And if it is, for example, a mini-PBX, then the situation becomes downright unpleasant. In most cases, after some dialogue with the seller, it is still possible to obtain any accompanying documentation from him. And if not, then you may have to contact directly the manufacturer or the largest dealer.
The accompanying documentation is important for everyone, from the director of the company and the accounting department, to those who are to use the equipment (or software). It is necessary for a general idea of ​​what you have acquired, as well as for the banal accounting of the available enterprise.
With this, everything seems to be more or less clear. But what about what the company already has at the time of your arrival? It is good if the company is medium in size and it does not have dozens of servers and an extremely extensive infrastructure. And if there is? And what's more, not described in any documents? This can be a real nightmare for a new employee entering into their duties. After all, it is not easy to understand what is happening on the company's servers and what works for them. Much more needs to be done. Namely:
understand the structure of the local network;
understand the structure of the telephone network (Yes, yes, I know that most of the system administrators prefer not to indulge in telephony. However, as practice shows, to this day, many IT department employees have to not only know the structure of this whole "farm", but also take direct part in its refinement or even development.);
minimum need to know the capabilities of the existing power grid;
make a complete picture of the company's server park;
Understand the software running on the company's servers, about the schemes for solving various issues, backup systems and everything else that can be safely attributed to a huge front of work with new (for this employee) servers;
to make at least a complete picture of workstations;
know the full set of software adopted by the company's standards for employees (if there is one, and if not, then it can be developed, but more on that later);
find out the structure of interaction between an IT department employee and users, suppliers accepted within the company;
find out the scheme of purchasing new equipment, its ordering scheme;
have an idea about the office equipment owned by the company;
other items (of which there may be a great many).
This is just the main part of what the new employee has to grasp. And in situations where there is no one to give him up to date as much detail as possible, this can be a real headache. Even in cases of an increase in the staff of the IT department, it may take days and weeks to become fully acquainted. Meanwhile, users work, servers require the care they need, and there may be quite a few projects in the plans that also need the direct attention and participation of an employee.
Looks pretty sad. And the main reason for this is the lack of technical documentation, where all aspects of the work of the enterprise’s network infrastructure would be brought in in time. You can reflect on the topic for a long time, why every time he comes to a new place of work, the system administrator faces the above difficulties. This may be the inertia and negligence of previous employees (“I know how it works, and even the flood after me.”), And perhaps the banal ignorance of managers about the need for documentation to be held by the IT department. And what is not required is not done. This rule is extremely common with system administrators and not only regarding documentation. I think everyone has ever heard of a person who was not concerned with the development and commissioning of a backup system of all files vital for the company's work. In the same way, everyone knows what this leads to. Believe me, the lack of documentation sooner or later can lead to no less sad result.
What is technical documentation.
So, we have already talked about why we need technical documentation. Now let's understand what it is. If the answer to this question is addressed to the now so popular Wikipedia (wikipedia), then we get the following very specific answer: "Technical documentation - a set of documents used in the design (engineering), creation (manufacturing) and use (operation) of any technical objects: buildings, structures, industrial goods, software and hardware. ”In other words, a fairly wide range of documents relates to technical documentation.
Of course, not all of the above in the definition we are interested. The greatest attention should be paid to the item "software and hardware." That is actually what every system administrator works with.
For the creation and maintenance of technical documentation "according to the rules", there is a whole set of different state-accepted standards (GOST). Not always strict adherence to these standards adds information to the documents created and even more rarely is actually required. In any case, as long as we are talking about the documentation created for internal corporate use. Well, in fact, will you write such a complex document that complies with all the necessary requirements of the standard, if you just need to create a list of the most frequently used software by users. Moreover, many GOSTs are already “one hundred years old at lunchtime” and half the documents you may want to create a standard simply do not exist.
Compliance with all rules and regulations is necessary in cases where a package of technical documentation is prepared for an external user. For example, if you are going to sell (as an option, resell) the network infrastructure of your company when you change office. Here ESKD (Unified Structure of Design Documentation) and ESPD (Unified Program Documentation System), as well as other standards adopted in such cases, will come to your aid. But this is a separate long conversation and for the time being we will keep silent about it.
When to start keeping records.
A reasonable question that arises after all that we have learned above - when should we begin to keep records on the accountable “economy”. The correct answers would be - right away. That is, exactly from the moment the infrastructure of the future company began to be laid. There are no tens of meters of incomprehensible network, telephone and other cables. There is no confusion. Moreover, the proper planning of the future network of the company with the necessary plans, charts and descriptions, is already a huge reserve for a very weighty and extremely detailed package of technical documents.
However, as practice shows, these or other reasons always impede the proper conduct of business from the very beginning. The simplest thing that can come to mind is that a company enters a new office with an already existing network, for which there are simply no documents and schemes. Fortunately, in the last couple of years, there has been a picture of significant changes in the management approach to infrastructure in general and IT departments in particular. More and more often, before moving to a new office, repairs are being made in it, and a plan for the necessary communications with planning the location of the server room and network equipment is laid at the stage of the discussion of the possibility of moving. Of course, this greatly simplifies the work on the preparation of documentation in the future, since it solves a whole bunch of problems at once. Not to mention the disappearance of problems with non-working network outlets, wire breaks and so on. With this, too, every system administrator has to face more than once during his profile activities.
If these conditions are not fulfilled and you are the “owner” of the unknown network structure, you probably have already spent a lot of time trying to figure it out and understand “why this wire sticks out of the wall and where it leads”. I hope with the patch panels you have full order. Now is the time to set aside one or two working days for yourself to document all this. I hope you do not need to explain that you first need it yourself? It will not be too pleasant to remember your “inclinations” with unknown wires, when (or if) such a need will arise in the future.
This is the answer to the question “When to start creating documentation?”. If you don’t have one yet, start right today. After all, this is only the beginning of your work on writing a full-fledged package of documents on everything you work with. As you know, Homeland begins with a picture in the letter, and technical documentation of the system administrator from the network structure diagram.
Types of technical documentation.
As mentioned above, the network layout represents the greatest initial interest for the system administrator in the technical documentation, but this is not limited to this interest.
A short list of documents worth starting to create immediately after (or during) the network description:
description of the scheme of access to the Internet and intranet;
server description;
description of the backup system;
description of the company's anti-virus protection scheme;
a description of the standards used by software users;
other items already mentioned in the introduction.
Briefly consider this entire short (compared with the full) list of documents.
Description of servers.
Understanding each time (or remembering if you have a lot of them) that is on a particular server is not an enjoyable task. Especially if this particular server has been operating normally for a year and a half and does not require attention. At the same time, the creation of a file with a description of the operating system, running services, hardware component, functional significance and other "little things" does not require significant resources. After all, you are already working with these machines and you know what each of them is for. Collecting information is a matter of technique. You will only have to document all this and put it aside until the following changes, after which you must immediately make the necessary amendments. This will help maintain the relevance of the document and avoid headaches in the future.
Description of the backup scheme.
Strictly speaking, having described the correct backup scheme and adding to it a rationale for why this is important, you can safely go to the manual and ask for budget funds for a new technique. But for us it is important for another reason, which is known to everyone - the network without backup, this is a time bomb, which sooner or later will jerk so that no one leaves without "gifts." I hope you are not one of those lovers of luck who are postponing the solution of such an important task.
Description of the scheme of access to the Internet and intranet network.
The level of development of telecommunication companies has now reached the level when all sorts of competitive offers just flooded the market. This gives user companies a wide choice in the way and quantity of consumption of Internet access services. Taking advantage of this situation, many managers who are serious about uninterrupted access to the Internet and understand its importance have long ago (or have plans for the near future) to decide on a backup channel from one of the providers in the area. What is useful scheme with two providers have already been discussed more than once. If you already have two channels for accessing the Internet, then all you need to do is document this scheme. And if not, then what is not a reason to portray her and go with her to the leadership. How is this useful? Yes, at least by the fact that you yourself in the process of drafting the document create in your head a clear idea of ​​how this is done and can apply this skill at any time. Helpful? Still would.
In addition, it will not be superfluous to describe the scheme of access to the Internet and for users of the company. Traffic, of course, cheaper cheaper, but the practice of restricting access used is used more and more often. Moreover, if earlier most of the system administrators (or manuals) used a resource restriction scheme, now the most popular is the restriction on the amount of downloaded content. If you are still restricting users to the list of forbidden to visit resources, this is a good reason to switch to traffic restrictions. (Just kidding of course. This is a private matter of each system administrator and his management.)
Description of the company's anti-virus protection scheme.
What is important system of protection against viruses, every system administrator knows. And those who have already fought at least once with epidemics that occur even in a seemingly protected network, have long ago drawn up a complete protection scheme and led anti-virus protection on all workstations and servers to a “common denominator”. It sounds rather strange, but nevertheless, the fact is that in networks where antiviruses are installed, but there is no general protection scheme, sooner or later, a viral epidemic will definitely occur. In everything there must be order and the most transparent representation of the implementation. This also applies to protection against viruses.
Description of the standards used by software users.
Most medium and large companies have already adopted corporate standards for software used by users in their daily work. However strange it may sound, this is not documented everywhere. As a result, it is impossible to familiarize the user and introduce responsibility for compliance with what is not on paper. Where there are no rules, there can be no execution. , . , , « ». , . , , , , . (, .)
Conclusion
, , , . , , . , , «- ». , .
, . , , , … . Why not?
akeeper .
« ».
Source: https://habr.com/ru/post/8822/
All Articles