@SZ

Здарова всем администраторам. Не знаю, куда деть мою тему, поэтому решил создать в разделе "Компьютерные сети".

Недавно работал системным администратором в одном госучреждении. У меня было два начальника, один куратор нашего отдела, непосредственно связанный с директором, а другой - собственно начальник ИТ-отдела. У нас была сеть на 300 рабочих мест, около пяти серверов различного назначения. Основным начальником был куратор. Второй начальник вообще почти на работу не ходил, и его не спешили увольнять. У него отец раньше здесь работал, связи остались. Блатной короче. Поэтому основное общение у нас было с куратором.

Первоначально, я как туда попал, работа была довольно интересной: я на своем рабочем месте ставил кучу виртуалок, много чего изучал книг по линуксу, читал кучу доков по сетевому оборудованию. Мы перевели сервера с ломаных виндовых на новые линуксовые от Red Hat. Дальше ещё было куча планов.

Работа у нас велась через написание документов по ГОСТ 34. Куратор отдела говорил, что де через эти документы директор нашему отделу выделяет деньги. Уверен, что это было правдой. Ну я и писал. Тем более знать эти стандарты я считал полезным. Обновление серверов было выделено в отдельный проект; по нему составлялось техзадание, потом техпроект. И все это писал на 80% я один.

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

И вот техпроект "побольше" как он просил готов. Началось обновление серверов. Пришел мой второй начальник, а я ему "де помогал". Дальше по плану приемочные испытания. К слову, приемная комиссия мои доки, которые я вылизывал месяцами не прочитала. Главный конструктор (вроде такая должность была) спросил, все ли работает, расписался на этой кипе бумаги и ушел.

И кажется бумажный ад закончился. Можно дальше утыкнуться в свои виртуалки и читать-изучать (литературы тонны). Но нет. Дальше пошло "руководство администратора". Естественно, писал его я. Даже те сервера, которые сам не ставил. Ну и написал это руководство по РД из ГОСТ 34. По сути это вылилось в практически описание алгоритма, последовательность действий, как воссоздать проделанную работу. Ну хорошо, будущий нуб не запутается если что. Но нет. Опять носил ему по пять раз, переделывал, перепечатывал. Важный момент, настройку нового дорогого межсетевого экрана начальник-куратор взял на себя. Но описание своих действий мне не дал, и в руководство это не попало.

Кароче работа перестала мне приносить удовольствие и, главное, опыт. Я за те месяцы, что я потратил на бумагу, мог бы тоже изучать новый межсетевой экран. Да ещё работа с пользователями, которые, если у них почтовый клиент забился в хлам от писем, звонят и спрашивают, "чего почта не работает". Я уже тогда хотел стать программером. И как выпал удачный момент, свалил в Java-разрабочтики. Да зп у меня сейчас в два раза больше.

Начальник как узнал, что я нашел себе новое место, сильно ругался. Говорил, что я "его подвожу", что нужно ещё кучу сделать. Короче оставил меня на полставки. Буду писать ему доки.

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

А кто что думает по этому поводу. Как кто относиться к написанию собственных руководств администратора (пользователя)? Но самое главное, если они очень уж нужны, как это правильно делать?

0

@Maks

Когда я пришел работать на нынешнее место работы, никакой документации от предыдущего администратора не осталось, кроме паролей от серверов, cisco и прочих девайсов.
Сперва сделал инвентаризацию железа (посредством Everest) и принтеров.
Далее составил журнал структуры кабельной сети (чтобы знать в какую розетку rj-45 какой ПК подключен, какие номера телефонов на каких портах висят). Сейчас даже самому намного легче в случае модернизации/расширении сети заниматься. Далее составил регламент установки и настройки SQL-серверов, чтобы в дальнейшем не тратить время на вспоминание деталей и того: "А как я тогда делал?" Все свои дейтсвия стараюсь регламентировать, опять же, для себя.
Из технической документации по факту:
1. Журнал структуры кабельный сетей: ЛВС, телефония, видеонаблюдение (делал в MS Visio);
2. Регламенты по установке и настройке серверов;
3. Список оборудования и его конфигурация;
4. Гарантийные талоны на технику, документы на лицензии + копии соответствующих счетов к ним;
5. Список поставщиков с их контактными данными.

2

Dmitry

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

1

@SZ

Ясно. Спасибо, коллеги. Я понял. Основной тезис - писать для себя. Чтобы было удобно в первую очередь мне самому как администратору, сотруднику своего отдела, им пользоваться.

0

@Maks

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

Dmitry,
Я отвечаю по-другому:

- "Если не знаете, идите учитесь.
Моя задача обеспечить Вас исправным компьютером и пакетом необходимого, для Вашей работы, программного обеспечения. На крайний случай есть интернет."

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

0