Документация – экономия времени или его бесполезная трата?

[itsmonline]

Алексей Коршунов

Искусство составления и использования документации – неотъемлемая часть работы хорошего IT-специалиста. Грамотно составленный документ способен помочь избежать огромной потери времени и лишних трудозатрат. До сих пор многие предпочитали игнорировать эту часть работы, но всё когда-то меняется.

Каждый сотрудник периодически испытывает на себе интерес руководства с целью выяснения, чем занимается он в рабочее время. Разумеется, начальству хочется слышать, что время тратится на благо компании. Особенно это актуально для системных администраторов компаний, руководители которых придерживаются позиции, будто сотрудники IT-отделов большую часть времени «отдыхают». Зачастую именно из-за такого расхожего мнения, системным администраторам едва ли не в режиме реального времени ставят задачи одну за другой. Однако оставаться на работе допоздна или засиживаться в выходные – это не единственный способ уберечься от загромождения задачами до такой степени, что начинает казаться, будто они никогда не закончатся.

Искусство организации рабочего времени всё ещё в диковинку для многих сотрудников, и не обязательно только IT-отделов. Обычно считается, что эта задача решается руководителями, но это не так. Никто не мешает обычному системному администратору, отдел которого насчитывает всего одну персону, научиться тратить время с умом. Организация рабочего времени сисадмина отличается от ситуации с менеджерами ввиду различий в их сферах деятельности. Организация рабочего времени сисадмина отличается от ситуации с менеджерами в виду различий в их сферах деятельности. Умение составлять и использовать документацию является важнейшим шагом к экономии рабочего времени.

Документация

Я хочу сразу оговориться, что данная статья не преследует собой цель раскрыть все вопросы создания и ведения технической документации, которая может потребоваться системному администратору. Здесь я лишь попытаюсь очертить круг тех документов, которые так или иначе приходится писать любому работнику IT-отдела, если в его задачи входит документирование.

Покупая какой-либо программный или технический продукт, пользователь рассчитывает получить вместе с ним пакет документации, который расскажет, как именно использовать новообретённое средство. Разумеется, я не хочу сказать, что в современном мире, если вы, допустим, покупаете серверную операционную систему, то совершенно обязательно получите вместе с дистрибутивом ещё и целую книгу «в нагрузку». Конечно, нет. Книгопечатные издания не даром едят свой хлеб, выпуская массу замечательных материалов, помогающих новичкам и профессионалам учиться использовать разработки различных компаний. В данном случае я скорее говорю о встроенных help-справках, которые могут внести минимально необходимую ясность в процесс эксплуатации, а также о вложенных в «пакет» вместе с дисками документах. Это если затрагивать программные продукты.

Случаи с покупками «железа» по сути мало чем от этого отличаются, но набор документации, как правило, всё-таки более широк. Причем не так уж важно, купили вы видеомагнитофон, музыкальный центр или сервер компании SUN – минимально необходимый набор документов вы получите. Причем можно смело сказать, что чем богаче набор полученной документации, тем более добросовестно относится производитель к своей работе. Думаю, каждый сталкивался с ситуациями на работе, когда вы получаете заказанное оборудование без сколько бы то ни было серьёзного пакета документов. Если это сервер или рабочие станции, заказанные в выбранной вами же конфигурации, это ещё не так критично. А если это, например, мини-АТС, то ситуация становится прямо-таки мало приятной. В большинстве случаев после некоторого диалога с продавцом всё же удаётся добиться от него какой-либо сопроводительной документации. А если нет, то, возможно, придётся обратиться напрямую к производителю или наиболее крупному дилеру.

Сопроводительная документация важна для всех, начиная от директора компании и бухгалтерии, заканчивая теми, кому предстоит использовать оборудование (или программные средства). Она нужна для общего представления того, что вы приобрели, а также для банального учёта имеющегося в распоряжении предприятия.

С этим вроде бы всё более или менее понятно. Но как же быть с тем, что уже имеет компания на момент вашего прихода? Хорошо, если компания средних размеров и у неё нет десятков серверов и крайне разветвлённой инфраструктуры. А если есть? И более того, не описана ни в каких документах? Это может стать настоящим кошмаром для вступающего в свои обязанности нового сотрудника. Ведь предстоит не просто понять, что происходит на серверах компании и что на них работает. Предстоит сделать значительно больше.

А именно:

- вникнуть в структуру локальной сети;
- понять структуру телефонной сети (да-да, я знаю, что большая часть системных администраторов предпочитает не заниматься телефонией. Однако, как показывает практика, по сию пору многим сотрудникам IT-отделов приходится не только знать устройство всего этого «хозяйства», но и принимать непосредственное участие в её доработке или даже разработке);
- минимально необходимо знать возможности существующей электросети;
- составить полное представление о серверном парке компании;
- разобраться в программном обеспечении, функционирующем на серверах компании, о схемах решений тех или иных вопросов, системах резервного копирования и обо всём остальном, что смело можно отнести к огромному фронту работ с новыми (для данного сотрудника) серверами;
- составить не менее полное представление о рабочих станциях;
- знать полный набор программного обеспечения, принятого стандартами компании для сотрудников (если таковой имеется, а если нет, то, может быть, и разработать его, но об этом позже);
- узнать принятую внутри компании структуру взаимодействия работника IT-отдела с пользователями, поставщиками;
- узнать схему закупки нового оборудования, схему его заказа;
- иметь представление об оргтехнике, находящейся в ведении компании;
- прочие пункты (коих может быть великое множество).

Это лишь основная часть того, во что предстоит вникнуть новому сотруднику. И в ситуациях, когда ввести его в курс дел максимально подробно некому, это может стать настоящей головной болью. Даже в случаях увеличения штата IT-отдела на полное ознакомление могут уйти дни и недели. Между тем пользователи работают, сервера требуют необходимого им ухода, а в планах может находиться немало проектов, также нуждающихся в непосредственном внимании и участии сотрудника.

Выглядит довольно грустно. И главная причина этого – отсутствие технической документации, куда своевременно были бы занесены все аспекты работы сетевой инфраструктуры предприятия. Можно долго размышлять на тему, почему каждый раз, приходя на новое место работы, системный администратор сталкивается с вышеобозначенными трудностями. Это может быть инертность и халатность предыдущих сотрудников («Я знаю, как это работает, а после меня хоть потоп».), а может быть и банальное незнание руководителей о необходимости ведения документации отделом IT. А что не требуется, то не делается. Это правило крайне распространено у системных администраторов, и не только касательно документации. Думаю, каждый хоть раз слышал о человеке, не озаботившемся разработкой и введением в эксплуатацию системы резервного копирования всех жизненно важных для работы компании файлов. Точно так же каждый знает, к чему это приводит. Поверьте, отсутствие документации рано или поздно может привести к не менее печальному результату.

Что такое техническая документация

Итак, мы уже поговорили о том, для чего нужна техническая документация. Теперь давайте поймём, что же это такое. Если за ответом на этот вопрос обратиться к ныне столь популярной википедии (wikipedia – ru.wikipedia.org.), то мы получим следующий вполне конкретный ответ: «Техническая документация – набор документов, используемых при проектировании (конструировании), создании (изготовлении) и использовании (эксплуатации) каких-либо технических объектов: зданий, сооружений, промышленных товаров, программного и аппаратного обеспечения.» Другими словами, к технической документации относится довольно обширный круг документов.

Разумеется, не всё из перечисленного в определении нас интересует. Наибольшее внимание стоит уделить пункту «программное и аппаратное обеспечение». То есть собственно то, с чем работает каждый системный администратор.

Для создания и ведения технической документации «по правилам» существует целый набор принятых на государственном уровне стандартов (ГОСТ). Не всегда чёткое следование этим стандартам добавляет информативности к создаваемым документам и уж тем более не всегда требуется. Во всяком случае до тех пор, пока мы говорим о документации, создаваемой для внутрикорпоративного использования. Ну в самом деле, станете ли вы писать настолько сложный документ, соблюдающий все необходимые требования стандарта, если вам просто-напросто необходимо создать перечень наиболее часто используемого пользователями программного обеспечения. Тем более что многим ГОСТам уже «сто лет в обед» и на половину документов, которые вы, возможно, захотите создать, стандарта просто не существует.

Соблюдение всех норм и правил необходимо в тех случаях, когда пакет технической документации готовится для внешнего пользователя. Например, если вы планируете продать (как вариант, перепродать) сетевую инфраструктуру вашей компании при смене офиса. Здесь вам на помощь как раз придут ЕСКД (Единая структура конструкторской документации) и ЕСПД (Единая система программной документации), а также прочие стандарты, принятые в таких случаях. Но это отдельный длинный разговор, и пока что мы об этом умолчим.

Когда начинать вести документацию

Резонный вопрос, возникающий после всего, что мы узнали выше, – когда же надо начинать вести документацию на подотчётное «хозяйство». Правильным ответом было бы – сразу. То есть ровно с того момента, как начала закладываться инфраструктура будущей компании. Пока ещё нет десятков метров непонятных сетевых, телефонных и прочих кабелей. Пока нет неразберихи. Тем более что правильное планирование будущей сети компании с необходимыми планами, схемами и описаниями – это уже огромный задел для весьма увесистого и крайне подробного пакета технических документов.

Однако, как показывает практика, те или иные причины всегда препятствуют правильному ведению дел с самого начала. Самое простое, что может прийти на ум, – компания въезжает в новый офис с уже существующей сетью, на которую попросту нет документов и схемы. К счастью, в последние пару лет наблюдается картина значительных изменений в подходе руководства к инфраструктуре вообще и ITотделам в частности. Всё чаще и чаще перед переездом в новый офис в нём делается ремонт, а план необходимых коммуникаций с планированием расположения серверной комнаты и сетевого оборудования закладывается на стадии ещё только обсуждения возможности переезда. Безусловно, это сильно упрощает работу по составлению документации в будущем, так как разом решает целую кучу проблем. Не говоря уже об исчезновении проблем с нерабочими сетевыми розетками, обрывами проводов и так далее. С этим тоже каждому системному администратору приходится сталкиваться и не раз за время своей профильной деятельности.

Если же эти условия не выполняются и вы являетесь «хозяином» неизвестной структуры сети, то, наверное, уже потратили уйму времени на то, чтобы в ней разобраться и понять, «почему этот провод торчит из стены и куда он ведёт». Надеюсь и с патч-панелями у вас полный порядок. Теперь самое время выделить себе один-два рабочих дня на то, чтобы всё это задокументировать. Надеюсь, не надо объяснять, что это в первую очередь нужно вам самим? Не слишком приятно будет вспоминать ваши «поползновения» с неизвестными проводами, когда (или если) такая необходимость возникнет в будущем.

Это и является ответом на вопрос «Когда начинать создавать документацию?». Если у вас её ещё нет – начните прямо сегодня. Ведь это только начало вашей работы по написанию полноценного пакета документов на всё, с чем вы работаете. Как известно, Родина начинается с картинки в букваре, а техническая документация системного администратора со схемы структуры сети.

Типы технической документации

Как уже было сказано выше, наибольший первоначальный интерес для системного администратора в технической документации представляет схема сети, но этим интерес не ограничивается.

Краткий перечень документов, который стоит начать создавать сразу же после (или во время) описания сети:

- описание схемы доступа в Интернет и интранет сети;
- описание серверов;
- описание системы резервного копирования;
- описание схемы антивирусной защиты компании;
- описание стандартов используемого пользователями программного обеспечения;
- прочие пункты, уже упомянутые в введении.

Кратко рассмотрим весь этот короткий (по сравнению с полным) список документов.

Описание схемы доступа в Интернет и интранет сети

Уровень развития телекоммуникационных компаний сейчас достиг того, что всевозможные конкуренто-способные предложения просто-таки наводнили рынок. Это даёт компаниям-пользователям широкий выбор в способе и количестве потребления услуг доступа в Интернет. Пользуясь этой ситуацией, многие руководители, серьёзно относящиеся к бесперебойному доступу в Интернет и понимающие его важность, уже давно приняли (или имеют это в планах на ближайшее будущее) решение о резервном канале от одного из присутствующих в районе провайдеров. Чем полезна схема с двумя провайдерами уже обсуждалось не раз. Если у вас уже есть два канала для доступа в Интернет, то от вас требуется всего лишь документирование этой схемы. А если нет, то чем не повод её изобразить и пойти с ней к руководству. Чем это полезно? Да хотя бы тем, что вы сами в процессе составления документа создаёте у себя в голове чёткое представление о том, как это делается, и сможете применить этот навык в любое время. Полезно? Ещё бы.

Кроме того, не лишним будет описать схему доступа в Интернет и для пользователей компании. Трафик, конечно, дешевеет изрядно, но практика ограничения используемого доступа применяется всё чаще. Причем если раньше большая часть системных администраторов (или руководства) использовали схему ограничения по ресурсам, то сейчас наиболее популярным становится ограничение по объёму скачиваемого контента. Если вы всё ещё ограничиваете пользователей по списку запрещённых к посещению ресурсов, это хороший повод перейти на ограничение по трафику.

Описание серверов

Разбираться каждый раз (или вспоминать, если у вас их множество), что находится на том или ином сервере, – это занятие не из приятных. Особенно если именно этот сервер уже полтора года работает в штатном режиме и внимания не требует. В то же время создание файла с описанием операционной системы, работающих сервисов, аппаратной составляющей, функциональной значимостью и прочими «мелочами» не требует значительных ресурсов. Ведь вы уже работаете с этими машинами и знаете для чего каждый из них. Сбор сведений – дело техники. Вам останется лишь задокументировать всё это и отложить в сторону до следующих изменений, после которых надо сразу же обязательно вносить поправки. Это позволит поддерживать актуальность документа и избежать головной боли в дальнейшем.

Описание схемы резервного копирования

Строго говоря, описав правильную схему резервного копирования и добавив к ней обоснование, почему это важно, можно смело идти к руководству и объяснить необходимость выделить бюджетные средства на новую технику. Но для нас это важно по другой причине, которая всем известна: сеть без резервного копирования – это бомба замедленного действия, которая рано или поздно рванет так, что никто не уйдёт без «подарков». Надеюсь, вы не из тех любителей испытывать удачу, которые откладывают решение такой важной задачи.

Описание схемы антивирусной защиты компании

Чем важна система защиты от вирусов, знает каждый системный администратор. А те, кто уже хотя бы раз боролись с эпидемиями, возникающими даже в казалось бы защищённой сети, уже давно составили схему целостной защиты и привели антивирусную защиту на всех рабочих станциях и серверах к «общему знаменателю». Довольно странно звучит, но тем не менее факт – в сетях, где антивирусы установлены, но общей схемы защиты нет, рано или поздно обязательно возникнет вирусная эпидемия. Во всём должен быть порядок и максимально прозрачное представление реализации. Это касается и защиты от вирусов.

Описание стандартов используемого сотрудниками программного обеспечения

В большинстве средних и крупных компаний уже приняты корпоративные стандарты на программное обеспечение, используемое пользователями в повседневной работе.

Однако, как бы странно это ни звучало, не везде это задокументировано.

Как следствие, с тем, чего нет на бумаге, нельзя ознакомить пользователя и ввести ответственность за соблюдение. Где нет правил, там не может быть их исполнения.

Поэтому оформление корпоративного стандарта в едином документе и ознакомление с ним пользователя во избежание эксцессов в будущем – это хорошая практика. Разумеется, это не означает сто процентной гарантии, что на компьютере того или иного пользователя не появится «почтовый клиент некорпоративного стандарта».

Уровень компьютерной грамотности пользователей растёт, а установка новой программы не является проблемой даже для неопытного пользователя.

Разумеется, такие задачи чаще всего решаются на уровне операционной системы, но, как показывает практика, административные меры самые действенные. (Особенно если за нарушение корпоративного стандарта штрафуют.)

Заключение

Разумеется, перечислены далеко не все документы, которые стоило бы начать вести каждому системному администратору, который серьёзно и основательно подходит к своей работе. Мне известно, что многие люди, работающие по этой специальности, мягко говоря, недолюбливают написание технической документации. Однако даже они рано или поздно начинают жаловаться на то, что «такой-растакой предшественник не оставил после себя ничего».

Может быть, стоит с себя начать и ввести практику ведения документации, если таковая ещё не была принята в вашей компании.

Написание документации полезно во всех смыслах. Начиная от образовательных, заканчивая тем, что после проделывания всей той работы, которая кратко была перечислена выше, можно смело идти... за премией.

А почему нет?

www.samag.ru