КомпанияУслугиОбучениеСервисы

Документирование ИТ-инфраструктуры организации

Версия для печати

Михаил Острогорский, 2007

Предпосылки

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

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

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

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

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

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

В живой организации ИТ-инфраструктура претерпевает изменения постоянно, из-за этого она всегда до некоторой степени рассогласована. Не правда ли, знакомая картина: пока ИТ-специалисты заняты стратегическим проектом по замене группы локальных систем общей ERP-системой или по внедрению интеграционной шины, функциональные подразделения — маркетинг, продажи, логистика и др. — отчаявшись дождаться «светлого будущего», автоматизируют себя сами в меру сил и возможностей. Сколько не публикуй статей об вреде так называемой лоскутной автоматизации, она неизбывна, поскольку задачи, требующие срочного решения, не иссякают. Корпоративная ИТ-инфраструктура растет, не как небоскреб, по проекту, как империя: сначала новые территории занимают, потом ассимилируют, включают в общую жизнь. Что лучше, переделывать (а в крайнем случае заменять) уже созданные кем-то локальные решения, или интегрировать их в общую среду? Наверно на этот счет есть разные мнения, но если предполагается интеграция, то ее возможность должна быть обеспечена соблюдением определенных корпоративных стандартов. Они же базируются на технической документации, и во многом устроены, как техническая документация.

Каким бы ни было техническое устройство ИТ-инфраструктуры, ею связаны между собой живые люди. Для того чтобы они могли работать с ней, им необходима техническая информация. Собирать, систематизировать, излагать и доставлять ее по адресу — функция документирования в ИТ-департаменте.

Кому и зачем это нужно

Заказчиком такой работы обычно выступает ИТ-подразделение крупного или среднего предприятия. В зависимости от целей и охвата она может быть непосредственно инициирована ИТ-директором или менеджером, ответственным за какой-то участок, например за определенную автоматизированную систему. Цели, преследуемые при документировании ИТ-инфраструктуры, как правило, таковы:

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

Какая документация получается в результате

Предметы документирования и документация на них

Предметы документирования и состав комплекта эксплуатационной документации (ЭД) на каждый из них приведены в табл. 1. В таблице перечислены не все возможные документы, и даже не все обязательные, а наиболее важные содержательно.

Таблица 1. Предметы документирования и комплекты ЭД

Предмет

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

программный продукт

·         паспорт

·         общее описание

·         руководство системного администратора

·         руководство пользователя

·         руководство программиста

·         формуляр

средства вычислительной техники

·         паспорт

·         руководство по эксплуатации

·         формуляр

сервис

·         регламент использования

·         формуляр

автоматизированная система

·         паспорт

·         ведомость эксплуатационных документов

·         общее описание системы

·         описания бизнес-процессов

·         технологические инструкции

·         руководство пользователя

·         электронная справка

·         эксплуатационная документация на программные и аппаратные компоненты системы

·         формуляр

ИТ-инфраструктура в целом

·         каталог технической документации

·         отчеты о состоянии и динамике ИТ-активов

·         карта информатизации

·         стандарты организации в сфере ИТ

·         ИТ-стратегия

Программный продукт

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

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

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

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

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

Средства вычислительной техники

Под средствами вычислительной техники (СВТ) мы в данном случае понимаем различные устройства: серверы, компьютеры на рабочих местах пользователей, сетевые и периферийные устройства. Их документирование выполняется с двоякой целью:

  • инвентаризация, оценка текущего состояния парка СВТ, прогнозирование потребности в пополнении ЗИП и ремонте;
  • дальнейшее описание развертывания сервисов и автоматизированных систем, выявление зависимости их работоспособности от состояния конкретных устройств.

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

Формуляр устройства фиксирует цели его использования в организации, физическое расположение и параметры конфигурации. Также в формуляре могут проставляться отметки о ходе эксплуатации: дата ввода в эксплуатацию, сведения о сбоях, ремонтах, сроках профилактического технического обслуживания. Все формуляры вместе взятые служат исходным материалом для инвентаризации СВТ.

Сервис

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

Формуляр сервиса фиксирует цели его использования в организации, содержит сведения и его развертывании и параметрах конфигурации. Также в формуляре могут проставляться отметки о ходе эксплуатации сервиса: дата ввода в эксплуатацию, сведения о сбоях, переустановке, изменениях конфигурации.

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

Регламент использования сервиса определяет принятые в организации правила, по которым осуществляется предоставление доступа к этому сервису и работа с ним.

Автоматизированная система

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

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

Документация, адресуемая непосредственно пользователям системы, включает в себя три уровня:

  • описания процессов;
  • технологические инструкции;
  • руководство пользователя.

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

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

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

Описание процесса содержит ссылки на технологические инструкции, технологические инструкции содержат ссылки на руководство пользователя. Чтобы этими ссылками было удобно пользоваться, описания процессов, описания операций и описания пользовательских задач сводятся вместе в гипертекстовой электронной справке. Ее можно разместить на корпоративном портале и предоставить к ней доступ сотрудникам организации. Вместе с тем, отдельные описания процессов, технологические инструкции и руководства можно хранить в формате PDF или Microsoft Word, выводить на печать, включать в официальный документооборот предприятия, проставлять на них утверждающие подписи, в общем, обращаться с ними как с традиционными документами.

Конфигурационная база данных как основа для документирования ИТ-инфраструктуры

Документы, описывающие различные компоненты ИТ-инфраструктуры, во многих случаях прямо или косвенно ссылаются друг на друга. Кроме того, они в значительной степени основаны на одной и той же информации, которая в зависимости от аудитории и задач каждого документа по-разному структурируется и подается с разной степенью подробности. Например, в формуляре сервера последний рассматривается сам по себе, а в документации на автоматизированную систему как часть ее комплекса технических средств. В руководстве пользователя программный продукт рассматривается сам по себе, а в формуляре сервера упоминается, поскольку он установлен с целью создания в сети сервиса на основе этого программного продукта. При такой насыщенности явными и неявными связями разработка и сопровождение каждого документа в отдельности становится чрезвычайно трудоемкой задачей, поскольку изменения, произошедшие с одним из компонентов, нередко требуют отражения в нескольких документах, в том числе, входящих в сферы ответственности разных людей. Если вести эту работу вручную, то исправленные версии документов ощутимо запаздывать и содержать расхождения между собой. Для автоматизации документирования ИТ-инфраструктуры применяется конфигурационная база данных, которая позволяет вводить, хранить и модифицировать данные о каждом компоненте ИТ-инфраструктуры и его взаимосвязях с другими компонентами. Документы при этом рассматриваются как отчеты, формируемые на основе конфигурационной базы. После внесения изменений в конфигурационную базу данных их можно сформировать автоматически по предусмотренным для них шаблонам. Компания PhiloSoft Technical Communication предлагает основанный на XML язык для описания ИТ-инфраструктуры и ее компонентов. Используя этот язык, можно вести конфигурационную базу данных в формате XML. Также мы предоставляем инструментарий для оформления информации из конфигурационной базы данных в виде документов, описанных выше.

© «Философт», 2008–2017

+7 (499) 500-44-77

mail@philosoft.ru

SpyLOG