Консалтинг: Організація документації на сайт / довкілля для клієнтів? [зачинено]

З часом я взявся за консалтингові та контрактні інженерні роботи для різних клієнтів. Зовсім недавно клієнти просять певну документацію.

• Які статичні IP-адреси я можу використовувати для нового годинника мережі, який ми встановлюємо?
• Як встановити виключення у веб-фільтр? Генеральний директор більше не може потрапити на веб-сайт НАП !!
• Нам потрібно вимкнути сервер Linux для запланованого відключення електроенергії. Яка команда знову?

Це малі підприємства і зазвичай не мають спеціалізованого технічного персоналу. Всередині однієї компанії Wiki / Confluence / Sharepoint тощо мають сенс як центральне сховище документації та інформації про навколишнє середовище, але я намагаюся знайти послідовний метод для передачі цієї інформації дискретним клієнтам.

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

• Важливі IP-адреси, область застосування DHCP тощо.
• Діаграма мережі (за потреби).
• Адміністративні імена користувачів та паролі та URL-адреси управління.
• Ліцензійні ключі програмного забезпечення.
• Інформація про контракти та гарантійну інформацію.
• Контакти та інструкції щодо підтримки постачальника.

Я знаю, що тут є інші консультанти. Будь-які пропозиції чи поради щодо збереження документації у кількох середовищах у зручному для клієнта форматі? Як ти це робиш?

Я є партнером у послугах, що займаються укладанням контрактів / консультацій з трьома особами з червня 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 партнерам для довідки (і особисто я вважав, що це безцінне). Ситуація ніколи не склалася, але я знаю, що ми будемо раді надати Клієнту доступ до журналів будь-якої кореспонденції до / від своїх співробітників, якщо вони коли-небудь запитують. Оснащення внутрішньої комунікації між партнерами було б складніше, тому що ми можемо посилатися на декілька клієнтів в одному повідомленні. (Напевно, ми повинні бути кращими з цього приводу, але цього не робили.)

Паролі - це основна "бородавка" у нашому процесі. Ми використовуємо індивідуальні сховища "Безпечний пароль" (з унікальними комбінаціями) для кожного Замовника, щоб дозволити спільний доступ до безпечного файлу з Клієнтом. Ми зберігаємо головні паролі для всіх безпечних файлів в іншому безпечному файлі з комбінацією, відомою лише партнерам. Ця частина справді потребує певної роботи. Я думаю, що ми хотіли б, щоб кожен Замовник розміщував сховище даних на сайті, використовуючи реальну програму для зберігання паролів для користувачів (з аудиторським слід тощо), але ми ідемо цю ідею на пляжі вже майже 10 років. .

Наші записи відстеження часу детально деталізовані та надаються Клієнтам у будь-якому електронному форматі (який до цього часу були текстом та PDF у форматі ASCII). Клієнти отримують час початку / зупинки для кожної події, що підлягає оплаті, та детальний опис виконаної роботи. Ми вважаємо ці службові записки дуже цінними внутрішньо, оскільки вони дозволяють нам бути в курсі того, що відбувається на сторінках клієнтів партнерів. У випадку випуску ці записи дають нам знання, що базуються на всіх попередніх питаннях та рішеннях, з якими ми стикалися протягом багатьох років. Мені не соромно сказати, що я вирішив проблеми для одного Клієнта, знайшовши замітки, які я забув писати для іншого Клієнта за роки до цього.

Швидке та обережне відсторонення: виготовлення документації: На моїй "старій роботі" (працюючи на когось ще років тому) компанія почала судовий позов проти неплатників. Ми опинилися у справі зустрічного позову від неплатного Клієнта. Наші внутрішні записи та електронна пошта стосуються того, що Замовника було винесено в суд і було звільнено до суду. Цей досвід навчив мене багато чого про те, щоб не зберігати нічого у фіксованому носії, яке не хочеться оприлюднювати.

Я написав кілька електронних листів із деякими (ерм) виборами слів та фраз про них, про мої розчарування у цього Замовника та з іншими «інженерами» в моїй компанії. Те, що я переглянув ці речі у відкритому суді, мені зовсім не сподобався.

Коли ми розпочали наш діючий бізнес, партнери погодилися, що всі фіксовані записи (електронна пошта, текстові повідомлення, голосова пошта, файли у сховищі SVN, робочі записи у відстежувачі часу тощо) будуть весь час вважатися "орієнтованими на клієнта" - навіть якщо вони ніколи не мали наміру опинитися в руках Клієнтів. Це було важко зробити і вимагає багато дисципліни, але я думаю, що воно того варте. Ми, звичайно, хочемо запропонувати своїм клієнтам атмосферу професіоналізму, і жити саме так. Я, безумовно, ніколи не збентежусь, як знову в тій залі суду.

Для основної інформації, як ви описуєте (за винятком діаграми мережі), ми використовуємо одну робочу книгу Excel і зберігаємо її в мережевій папці з назвою клієнтів. Хоча я можу зрозуміти, чому людям не подобається такий підхід, я вважаю, що він чудово працює, оскільки це єдиний довідковий документ, який я можу взяти з собою на сайт, електронну пошту та швидко оновити.

Моя найбільша скарга була б відсутністю контролю версій, але я ще не знайшов нічого, що добре працює, не роблячи важкої роботи.

Щоб протистояти вашому "Я знімаю процес, який є більш портативним, безпечним та елегантним, ніж проста електронна таблиця":

Більш портативний: Що може бути більш портативним, ніж електронна таблиця на 500 кілобайт? Мені буде страшно використовувати що-небудь хмарне чи веб-базування, оскільки підключення до Інтернету не може бути гарантоване.

Безпечно: Цей вам я дам, і я теж хотів би вирішити питання, як зробити наше рішення більш безпечним.

Елегантний: Ми витратили час на створення приємного шаблону для нашої робочої книги. Як я кажу, це багатосторінкова робоча книжка, а не просто величезна сторінка розкиданої інформації. Я думаю, що більшість ІТ-документацій добре вписується в табличну форму, а електронна таблиця зберігає це дуже акуратно та просто.

Хоча у мене є багато проблем із тим, як ми записуємо та зберігаємо документацію щодо складання, я справді не можу знайти вина у міцній, добре сформованій електронній таблиці. Я також додам, що ми працюємо з деякими великими компаніями ІТ-служб, і вони працюють приблизно так само. Знову ж таки, це геніально - я заходжу на сайт, запитую документацію та отримую єдину акуратну електронну таблицю, яку я можу використовувати протягом тривалості.

Великою перевагою цього боязкого в'яжучого є:

• Нетехнічні клієнти можуть це зрозуміти, тримати його на сайті та зберігати в безпеці, як вони звикли і вже роблять всі види інших важливих документів.
• Ваші клієнти можуть з легкістю здати його у випадку, якщо вони найнять вам заміну, професіональну справу та щось, що дало б вам швидкий початок та довідку, коли ви посадили їх як клієнтів.
• Простий журнал технічного обслуговування на початку з основними моментами кожного відвідування сайту - щось відчутне.
• Біндер також містить CD / DVD та сертифікати з ліцензійними кодами та ключами активації, якщо BSA або інший постачальник відвідує.

Незалежно від того, якою цифровою системою ви користуєтесь, насправді вже не має значення, якщо ви дисциплінуєте себе оновлювати палітурку, коли ви робите щось вартісне.

І палітурка, звичайно, для вас абсолютно марна, якщо ви віддаляєте майже всю свою підтримку віддалено.

Я був великим прихильником використання вікі, тому що він легко підтримується, гіперпосилання на МОП та інтерфейси управління, легко відслідковуються вхід на робочий стіл та SSH. Вільна форма відповідає більшості інформації, яку я хотів би мати:

• опис сайту: "мережевий принтер (OKI 1234 MFP) - це той, який знаходиться поруч з робочим столом Джона, струменевий принтер HP модель 0123 сидить у Бобсі, в офісі начальника" значно спрощує відповідь на телефонний дзвінок: "у нас є закінчилося чорнило, який картридж нам потрібно замовити ще раз? ".

• сторінка для кожного пристрою, в ідеалі із зображенням, типом та конфігурацією, цільовим призначенням тощо.

• Існує кілька пристойних експортних модулів для Вікі для створення твердої копії або цифрових документів для передачі та включення до цього страшного палітурки

Я погоджуюсь, що «Dan on Excel» є хорошим, портативним рішенням, і я думаю, що він робить його відмінним випадком, за винятком частини безпеки, де я думаю, що турботи дещо неправильні:

Яким би методом ви не хотіли б поширювати, захищене рішення може бути охоплено (наприклад, зашифрований електронний лист, захищене спільне зберігання тощо). Те саме стосується контролю версій (наприклад, Shadow copy, svn тощо).

Однак, лише за допомогою конструктивної критики та з усією повагою додам, що головним недоліком спільної електронної таблиці Excel є обмеження у її конкурентності. Щодня у вас є два адміністратори чи більше, вони виявлять, що королівський біль повинен бути змушений вибирати між собою лише один, який зможе відкрити аркуш для редагування, або зберегти кілька копій, які потім потребують об'єднання (які дані на сьогоднішній день, а що ні?). І це справді біль.

Краще рішення - використовувати Excel (або все, що завгодно) в якості основи до невеликої бази даних за вибором, будь то Access (тільки для вирішення портативності), MS SQL, MariaDB або все, що вам захочеться.

Я виступаю за це як рішення, яке не просто придатне для передачі інформації іншій стороні (= Excel), але яке також підходить для підтримання зусиль, що тривають у документації.

Моя думка коротко, що навіть з кількома адміністраторами (не кажучи вже про більші магазини), відділ, що покладається на Excel для зберігання даних документації, є відділом із розповсюдженою документацією. Ніколи ще не бачив винятку, якщо тільки один адміністратор.

Але відділ, що використовує накопичувач, керований базами даних, має можливість зберігати чітку, сучасну документацію. Тоді це лише питання зусиль. Excel - це працездатний db-frontend із плюсами та мінусами, але далеко не єдиний варіант.

Це може бути не зовсім те, що ви шукаєте, але ось що я роблю.

Я використовую Microsoft Office, щоб створити всі документи для кожного свого клієнта. Я використовую Excel (інформація про ip-адресу, картографування портів комутації, макет стійки), Word (інформація про конфігурацію, рахунки-фактури, шаблони SOW) та Visio (діаграми). Я створюю ієрархію папок з батьківською папкою на ім'я Консалтинг та дочірньою папкою для кожного клієнта. Коли я створюю або оновлюю клієнтські документи, я синхронізую їх зі своїм iPhone (використовуючи Documents To Go ), USB-накопичувач та акаунт DropBox (використовуючи двофакторну автентифікацію). Таким чином я маю доступ до всієї документації (так чи інакше) куди завгодно і де завгодно.

Я також використовую додаток для управління проектами / звітності / виставлення рахунків / відстеження часу під назвою OfficeTime . Там є додаток iPhone та додаток для Windows, тому я маю доступ до інформації про проект, виставлення рахунків, годин тощо тощо на своєму iPhone, коли я перебуваю на сайті та синхронізуюсь із робочим столом, коли я повертаюся додому.

Хоча це не ідеальне рішення, але варто поглянути на Device42 .

Ось що можна зробити: IP-адреси та пристрої можуть бути пов’язані з клієнтами. Ви можете мати групи VRF для перекриття діапазонів IP для різних клієнтів.

У ньому немає чіткого дозволу на IP-адреси / пристрої (просто глобальний доступ на основі ролей), тому ви не можете дозволити кінцевим клієнтам прямий доступ. Але ви можете створювати звіти для клієнтів, використовуючи інформацію про пристрій та IP, та надсилати їх кінцевому клієнту, коли це потрібно.

Це принаймні дасть вам інтерфейс для організації всієї інформації в центральному сховищі. Ви можете зберігати інформацію про об’єкти, інформацію про IP, інформацію про контракти та паролі.

Крім того, він надає більшу інформацію в дзвінках API REST, але не впевнений, чи зможете ви надати щось для кожного клієнта.