Я являюсь партнером в контрактной / консалтинговой службе из трех человек с июня 2004 года. Каждый из нас в основном работает со своими «учетными записями», однако нам необходимо поддерживать документацию друг для друга, чтобы обеспечить «отказоустойчивость» между партнерами. У большинства наших клиентов есть какой-то внутренний ИТ-персонал, многие из которых выполняют определенное ежедневное обслуживание, и нам также необходимо эффективно передавать им документацию.
У моих двух партнеров есть преимущество (если можно так назвать) того, что они работали под моим руководством в другой фирме, и, в результате, они оба были знакомы с моим самоуверенным поведением. Строгая согласованность (где, очевидно, могут быть вещи) между конфигурациями Клиентов является находкой. Очевидно, что продукты меняются, поэтому мы советуем обсудить новые продукты / версии и т. Д. И принять решение о согласованной стратегии конфигурации перед развертыванием. Это не масштабируется для большой компании, но, честно говоря, я вижу это скорее как особенность, а не как ошибку. (Я не стану разглагольствовать о более крупных компаниях с управляемыми услугами с их «инженерами» и ужасными тенденциями для одноразовых, недооцененных «решений» и несогласованности между клиентами ...> улыбка <)
Я яростно против "страшного переплета". Я никогда не видел, чтобы физическая документация постоянно обновлялась . Я думаю, что тратить деньги клиента на то, чтобы тратить время на создание физических копий документации. Я бы предпочел потратить время на разработку документации по «живым» данным из запущенных конфигураций.
Как пример, я абсолютно не буду поддерживать таблицы с информацией об IP-адресах. Для этого и нужны DHCP и DNS (подробности см. Ниже). Если эти вещи не работают, то у нас есть серьезные проблемы.
У нас были клиенты, которые просили что-то вроде «сделать документ, который показывает всю нашу конфигурацию групповой политики», и я закопался и отказался это делать. Мое повторяющееся встречное предложение (которое до сих пор работало) состояло в том, чтобы представить Заказчику административные инструменты, которые могут предоставить им «самообслуживание» или использовать программное обеспечение для создания «живой» дружественной для клиента документации по требованию.
Мы очень стараемся быть аккуратными в изложении вещей на простом английском языке. Нетехнический ИТ-контакт может, например, проверить членство компьютера в группе Active Directory и увидеть такие вещи, как «Программное обеспечение - Установить Microsoft Office 2010 Pro» и «Групповая политика - Автоматический вход в компьютер с киоска доставки». Не требуется никакой документации, чтобы объяснить, что означают эти вещи.
Вот некоторые «живые» данные, которые мы используем:
Все IP-адреса хранятся на DHCP-серверах - это относится и к устройствам со статической адресацией (как отмечается в комментариях). MAC-адреса и IP-адреса могут быть легко запрошены с помощью сценариев или вручную, и, по определению, данные должны быть актуальными, если они используются в производстве.
Все получает имя и запись PTR в DNS. Большинство хостов также получают запись HINFO. Вещи, которые нуждаются в подробном описании, получают запись TXT.
Обильное и подробное использование полей «Заметки» везде, где это возможно - Active Directory, описания компьютеров, описания общих папок и т. Д. Мы также многословны и понятны с такими вещами, как имена групп безопасности.
Комментарии / замечания в конфигурациях сетевого оборудования (например, комментарии к ACL, описаниям портов, расположению SNMP / контактной информации).
Я довольно негативно отношусь к идее хранения информации в свободной форме в таких вещах, как текстовые файлы, вики и т. Д. Структура обеспечивает хороший поиск. Всякий раз, когда я могу заставить работать механизм структурированного хранилища (даже если это означает, что мне нужно написать программное обеспечение для его запроса), я предпочитаю его. Комментарии, которые я могу анализировать по файлам конфигурации, базам данных и т. Д., Всегда меня удивляют, когда они сталкиваются с документами, сгенерированными вручную, которые почти сразу устаревают.
Когда нам нужно хранить информацию «свободной формы», мы используем собственный SVN-репозиторий. Он содержит все различные фрагменты статической документации, которую мы создали за многие годы и поданной Заказчиком. Мы используем SVN для этого с 2004 года, и он очень хорошо работал как инструмент для совместной работы. Мы создаем схемы баз данных, сценарии sysadmin, резервные копии объектов групповой политики и т. Д. Я пытаюсь проверить все, что могу, в управлении версиями.
Очень легко найти мою кассу с помощью инструментов индексации на основе файловой системы. Я знаю, что у каждого из нас есть по крайней мере одна полная копия хранилища, доступная нам локально в любое время. Мы также сделали хранилище доступным через аутентифицированный WebDAV по SSL на случай, если нам абсолютно необходимо получить доступ к хранящимся там данным и иметь доступ только через браузер.
Нас никогда не просили сделать это, но мы были бы рады создать учетную запись на сервере SVN, чтобы позволить Клиенту извлекать информацию и взаимодействовать со своими собственными файлами (если у них есть внутренний ресурс, который так склонен) ). Мы используем стандартизированный формат для хранения всей статической документации Заказчика (документация по лицензии на программное обеспечение, записи о закупках и т. Д.), Которая довольно понятна.
Наряду с SVN-репозиторием мы также самостоятельно размещаем нашу электронную почту. Вся входящая / исходящая электронная почта была заархивирована, так как домен компании начал получать электронную почту. Это доступно как журналы BSMTP партнерам для справки (и, лично я нашел, что это неоценимо). Ситуация никогда не возникала, но, я знаю, мы были бы рады предоставить Заказчику доступ к журналам любой корреспонденции их сотрудникам, если они когда-либо спросят. Обеспечение внутренней коммуникации между партнерами было бы более трудным, потому что мы могли бы ссылаться на нескольких клиентов в одном сообщении. (Вероятно, мы должны быть лучше об этом, но мы не были.)
Пароли являются основной «бородавкой» в нашем процессе. Мы используем отдельные репозитории «Safe Password» (с уникальными комбинациями) для каждого Клиента, чтобы разрешить обмен безопасным файлом с Клиентом. Мы храним мастер-пароли для всех безопасных файлов в другом безопасном файле, комбинация которого известна только партнерам. Эта часть действительно нуждается в некоторой работе. Я думаю, что мы хотели бы, чтобы каждый Заказчик размещал хранилище учетных данных на месте, используя реальное многопользовательское приложение для хранения паролей (с контрольным журналом и т. Д.), Но мы разворачивали эту идею почти 10 лет назад ,
Наши записи учета рабочего времени тщательно детализированы и предоставляются Заказчикам в любом электронном формате, который они хотят (который до этого момента был в формате ASCII и в формате PDF). Клиенты получают время начала / окончания каждого оплачиваемого события и подробное описание выполненной работы. Мы считаем эти сервисные замечания очень ценными для внутреннего использования, поскольку они позволяют нам быть в курсе того, что происходит на сайтах клиентов партнеров. В случае возникновения проблем эти записи дают нам основанные на знаниях все предыдущие проблемы и решения, с которыми мы столкнулись за эти годы. Мне не стыдно сказать, что я решил проблемы для одного клиента, найдя заметки, которые я забыл написать для другого клиента много лет назад.
Быстрое и предупреждающее замечание по поводу: производства документации: На моей «старой работе» (работавшей на кого-то еще несколько лет назад) компания подала в суд на неоплачиваемого Клиента. В итоге мы оказались в бизнес-положении по встречному иску от неоплачиваемого Клиента. Наши внутренние записи и электронная почта о том, что Клиент был вызван в суд и предъявлен в суде. Этот опыт научил меня много о чем не хранить в неподвижной среде , что вы не хотите быть обнародованы.
Я написал несколько писем с некоторыми (ERM) выбор слов и фраз в них о своих разочарованиях с этим Клиентом и с некоторыми другими «инженеров» в моей компании. Мне вообще не нравилось подвергаться перекрестному допросу об этих вещах в открытом суде.
Когда мы начинали наш текущий бизнес, партнеры согласились, что все фиксированные записи (электронная почта, текстовые сообщения, голосовая почта, файлы в репозитории SVN, рабочие записи в трекере времени и т. Д.) Будут постоянно рассматриваться как «ориентированные на клиента» - даже если они никогда не предназначались для того, чтобы оказаться в руках Клиентов. Это было трудно сделать и требует большой дисциплины, но я думаю, что оно того стоит. Мы, безусловно, хотим создать атмосферу профессионализма для наших клиентов, и жить так - это способ сделать это. Я, конечно, никогда не буду смущен, как я снова был в этом зале суда.