За бюрократию, или почему документировать все-таки надо
Intro
Подавляющее большинство ИТ-специалистов-Made-In-Russia категорически не признает важность ведения документации. Это менталитет, это привычки, это воспитание. Это борьба с системой, берущая начало со школьной скамьи, когда будущему ИТ-специалисту учительница разрисовывала дневник красной ручкой за его неаккуратное ведение, а родители давали по шее за разгильдяйство. После школы будущий ИТ-специалист пристраивался в институт, и борьба с системой продолжалась: конспекты не писались, семинары не стенографировались, а лабораторные работы вообще выполнялись на черновиках, которые попросту выбрасывались. А перед экзаменом начинался штурм ботаников с целью отксерить/переписать заветный материал, ведущий к «удовл.» в зачетной книжке. В общем-то это культура. Национальная традиция, если хотите.
В один прекрасный день такой культурный и традиционный выпускник придет работать ИТ-специалистом на какое-нибудь предприятие. Может быть даже на ваше. Со всеми своими неисправленными изъянами и непрофессиональными привычками. В том числе в вопросах ведения документации. Т.е. вести ее он не будет. А строить ИТ-инфраструктуру будет обязательно. Причем не всегда профессионально и не всегда предельно просто и прозрачно даже для его коллег. И в один прекрасный день возникнет ситуация, когда ИТ-специалист уйдет, на его место придет другой, но эффективно работать у вас не сможет еще довольно долго, т.к. будет силиться понять направление мысли своего предшественника и расшифровать алгоритмы, по которым строились действующие сервисы и системы.
Печальная перспектива, правда? Но это если вы – владелец бизнеса, или хотя бы лицо, заинтересованное в эффективных бизнес-процессах на предприятии. Если же вы – ИТ-специалист, то для вас перспектива еще печальнее. Зачастую будет быстрее и проще все переделать «под себя», нежели разбираться, как и что работало раньше.
Но мы допустим, что вы – тот самый ИТ-специалист, который довольно успешно работает, развивает ИТ-составляющую предприятия и… ничего не документирует. А еще мы допустим, что вы работаете в «динамично развивающейся компании» (sic!), в которой постоянно растут требования к ИТ, растет количество пользователей, и это в условиях роста аппетитов ПО к аппаратному обеспечению. Т.е. сидеть на месте вам не приходится, вы постоянно чем-то заняты. И вот число пользователей в вашей компании выросло настолько, что вы уже не в состоянии заниматься чем-то кроме техподдержки. И тогда вы берете в компанию второго ИТ-специалиста. Которого надо обучать, показывать устройство ваших ИТ-систем и вообще вводить в курс дела. И вот тут даже вы пожалеете о том, что были небрежны в вопросах документирования…
Доводы «за»
Аксиома №1. Документация необходима бизнесу.
В качественной документации описывается, для чего и как все делается. Регламентированные процедуры и контрольные списки исключают человеческий фактор из числа вероятных причин появления проблем. Письменные инструкции не дают произвести впечатление, что вы все придумываете на ходу. Документация позволяет компании конструктивно менять методы работы. В конце концов, ее могут потребовать аудиторы или инвесторы, и вам будет что им показать.
Если для каждого действия написана процедура, то нет необходимости в высококвалифицированном и высокооплачиваемом персонале; достаточно рядового специалиста, способного понимать язык ИТ и выполнять предписания. Иногда достаточно навыков даже рядового пользователя. Если на предприятии ИТ-специалист только один, то он может смело идти в отпуск или брать больничный, не переживая, что без него все бизнес-процессы остановятся.
Аксиома №2. Документация необходима ИТ-специалистам.
Давайте вообразим, что в компании есть сетевой инженер и специалисты службы технической поддержки. Сетевой инженер вносит изменения в конфигурацию маршрутизатора в головном офисе. В службу технической поддержки обращается сотрудник филиала, который утверждает, что некий сервер server1 стал недоступен. Сотрудник службы технической поддержки может лишь провести диагностику, подтвердить и зарегистрировать проблему, и эскалировать ее решение на уровень выше (к примеру, тому же сетевому инженеру, но не сразу, т.к. явных предпосылок передавать инцидент именно ему пока нет). Пока завершатся процессы диагностики и эскалации, пройдет уйма времени, которое может быть засчитано простоем в работе. Это чревато санкциями.
С другой стороны, сетевой инженер мог внести информацию об изменениях в журнал регистрации изменений. Специалист службы технической поддержки увидел бы изменения и передал информацию о необходимости корректировки конфигурации сетевому инженеру. Таким образом из процесса управления инцидентами было бы исключено лишнее звено, а время решения проблемы сократилось.
А если бы сетевой инженер воспользовался типовой процедурой для внесения изменения в конфигурацию (ознакомился со списком зависящих от конфигурации маршрутизатора сервисов и пользователей), то он бы и вовсе не допустил такой ошибки, и инцидент бы не возник.
Таким образом документация сокращает время реакции на инциденты и их локализацию.
ИТ-специалист должен создавать вокруг себя определенный порядок, способствующий эффективной и плодотворной работе. Например, очень важно совместно с отделом кадров регламентировать процедуру найма новых сотрудников, гарантирующую, что новые рабочие станции и ПО будут своевременно приобретены и подготовлены, а учетные записи созданы до того, как новобранец приступит к работе. Такая процедура должна быть четко описана, внесена в правила внутреннего распорядка и заверена приказом.
К выходу сотрудника его рабочее место должно быть оснащено не только компьютером и телефонным аппаратом: также необходимо подготовить экземпляр правил использования ресурсов корпоративной ИТ-инфраструктуры и инструкций по эксплуатации ИТ-систем (например, использование корпоративной почты из дома, регламента хранения рабочих данных и т. д.). Это сразу же снимет большую часть вопросов у нового сотрудника и сэкономит вам кучу времени.
Другой момент: к вам обратился пользователь с просьбой установить на его компьютер важное приложение «World of Warcraft». Если у вас нет четко определенного и утвержденного генеральным директором перечня допустимого ПО, то нет и оснований ему в этом отказать. А с перечнем вы – хозяин ситуации. Причем, можно отказать без риска испортить с коллегой отношения: дескать, «я бы и рад, да не положено, извините».
Аксиома №3. Ведение документации – востребованный навык.
Надо признать, что в нашей стране развитие бизнеса в целом и отрасли ИТ в частности основывается на опыте более продвинутых западных коллег. Западные отраслевые стандарты, выраженные в методологиях ITIL, MOF и CobiT, четко определяют документирование как один из ключевых процессов управления ИТ. Рост ИТ-специалиста проходит по стандартной схеме «от меньшего к большему». Иными словами, от ООО «Рога и Копыта» до ОАО «Газпром». ИТ-специалист, не владеющий ключевыми навыками, шансов устроиться на престижную и высокооплачиваемую работу в крупную компанию практически не имеет. Так что учиться, учиться и еще раз учиться.
Перечень документации из серии Must Have
Итак, какого рода документацию вести необходимо?
- Техническую. Это карта серверов, схемы подключения коммутационного оборудования, конфигурации сервисов и ПО, описание и схема подключения оргтехники, структура сети, используемых протоколов, описание и алгоритмы работы телефонии, график и схема резервного копирования. Сюда же можно отнести типовые процедуры (например, подготовка новой рабочей станции к эксплуатации) и контрольные списки.
- Организационную. Это регламент использования ресурсов корпоративной сети, перечень разрешенного ПО, SLA, процедуры приема и увольнения сотрудников.
- Справочную. Это справочники (телефоны, реквизиты поставщиков оборудования, ПО, телекоммуникационных услуг), журналы учета изменений, резервного копирования, процедуры заказа и приемки оборудования, перечень используемых расходных материалов и т. д.
- Сопроводительную. Инструкции для сотрудников и ИТ-персонала.
Где и как вести документацию
Одним из лучших способов хранения и управления документацией общепризнанно является применение CMDB (Configuration Management Database). Разработанный в качестве компонента процесса Управления конфигурациями ITIL, это гибкий и мощный репозиторий информации о компонентах информационных систем. «Лучшая практика», так сказать. Другая сторона медали – коммерческие CMDB достаточно дороги и для бюджетов малого и среднего бизнеса часто неподъемны.
Если денег на CMDB нет, то при определении базы хранения и методов управления документацией важно учесть 2 качественные характеристики: интерактивность и доступность. С документацией чаще всего работает не один человек, а коллектив, поэтому лучше использовать привычно сочетающиеся с совместной работой инструменты: wiki, web-платформы (например, Microsoft SharePoint или его бесплатные реализации), CMS. Такие системы позволят наглядно структурировать документацию, четко прослеживать взаимосвязи, отслеживать версионность и обеспечить максимальную доступность. В любом случае, понимание приходит с опытом. Главное начать, а уж наиболее удобный способ выработается сам собой.
Outro
Документирование – один из ключевых процессов в управлении ИТ. Качество и актуальность документации к информационным системам позволяет оценить уровень зрелости ИТ на предприятии. ИТ-специалист, обладающий навыками качественного документирования ИТ-систем, высоко ценится руководством и востребован на рынке труда.
И напоследок представьте себе сценарий: устроившись на новое место работы, вы оставили на старом исчерпывающую информацию об устройстве ИТ-инфраструктуры. Туда устроился новый ИТ-специалист. Что он про вас подумает? Помянет добрым словом, и не раз. А это хорошая, светлая карма.