Как и обещал, излагаю свое предложение по организации эксплуатационной документации в части описания конфигурации, которое, на мой взгляд, позволяет сохранить необходимо высокий уровень детализации описания и, в то же время, сделать эту документацию удобной для поддержания в актуальном состоянии. Суть подхода очень проста: разделить на модули и в рамках каждого изменении выпускать новые версии затронутых изменением модулей.
В презентации также содержится предложение по переходу на этот "революционный подход" со стандартного, соответствующего несколько подустаревшим и тяжелыми для использования на практике ГОСТами и СТР-К, заключающееся в организации надлежащего документирования изменений, в рамках которого старые эксплуатационные документы когда-нибудь будут заменены новыми, состоящими из взаимосвязанных модулей.
В презентации также содержится предложение по переходу на этот "революционный подход" со стандартного, соответствующего несколько подустаревшим и тяжелыми для использования на практике ГОСТами и СТР-К, заключающееся в организации надлежащего документирования изменений, в рамках которого старые эксплуатационные документы когда-нибудь будут заменены новыми, состоящими из взаимосвязанных модулей.
4 comments:
Т.е. на каждую СХД по паспорту? А сеть как выделять в отдельный паспорт?
Надо смотреть по ситуации. Вообще, модули, функции и вообще ООП придумали для снижения необходимости копи-пейста. Так и здесь - то же самое, при условии неоспаривания необходимости эксплуатационной документации. Предлагается ее организовать в виде взаимосвязанных модулей, причем, при делении учесть необходимость максимально оптимального (наименее трудоемкого) апдейта эксплуатационной документации.
Понятно, что ТПс пишется на Информационную систему, но ИС может быть что угодно, поэтому деление на ИС лучше выполнить не из каких-то истетическо-перфекционистких ощущений, а с целью оптимизации операционной поддержки этой документации, в частности - отражения изменений.
Теперь по вопросам? Что ты понимаешь под СХД? Вся СХД ЦОД? Один дисковый массив с мозгами? Одна дисковая полка? Один диск? Я бы сделал одни ТПс на всю СХД ЦОД. Соответственно, во всех ТПс на ИС, размещенной на этой СХД писал бы логические параметры ИС, а касательно физики - давал бы сслку на ТПс СХД.
Про сеть. В части СКС я бы предлагал брать здание/офис, ЛВС - аналогично. Можно написать ТПс и на кампус, если коммутации между объектами внутри кампуса много.
Вопрос детализации я описывал здесь - это, так сказать, глубина изложения, а здесь я предлагаю подход к определению ширины изложения.
А не проще отменить вообще все описание инфраструктуры и ссылаться на ассеты в CMDB? А там уже заполнять карточки в рамках операционной деятельности
Первое. Никто не запрещает, чтобы ТПс был электронным, в т.ч. и в виде связанных КЭ, но все равно должна быть возможность вывода ТПс в том или ином виде на бумагу, так как:
- каким-нибудь аудиторам захочется увидеть документы,
- не всегда есть возможность сидеть и ознакамливаться с CMDB в онлайне - полезно это куда-то вывести.
В свое время я разработал ТПс в виде связанных таблиц Excel (читай - "таблиц СУБД") - почти CMDB.
Второе. Мы сейчас немного в стороне, так как говорим о представлении данных, а пост, главным образом, - об организации данных.
Третье. Я полностью поддерживаю электронный документооборот, чтобы Изменения ходили в виде предопределенных форм и согласовывались электронно.
Post a Comment