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

Наверное самое нелюбимое для любого админа занятие, это работать с документами, а особенно их писать. Аргументов, которые мы находим «в свое оправдание» много, попробую выделить основные:

– На это нет времени;

– Не сейчас;

– Я и так все знаю/помню;

– Все есть в гугле;

– Это лишняя бюрократия;

А теперь попробуем разобрать эти причины, и их влияние на разных этапах развития карьеры среднестатистического сис-админа, от «тыжпрограмиста» в маленькой компании во времена студенчества до админства довольно таки большой инфраструктуры в компании с ITIL-ом, безопасностью, аудитами, и проджект-менеджментом.

Что есть эта документация? Для маленькой инфраструктуры при внедрении чего-то нового это может быть просто лист блокнота, в котором можно нарисовать простую схемку, на каких серверах/компах все крутится. Где система берет данные, куда их отправляет. Ковыряя для этой системы дырки в фаерволах/брендмауэрах ( у вас же есть фаерволы? ), дописываем на эту схемку порты/протоколы. Настраивая права ( у вас же не все работает под «Admin»? :)) дописываем в схемку имена учеток и их права. Натыкаясь на грабли по ходу , играясь с настройками – скриним подошедшие параметры и складываем данные в файлики, черкая при этоми имена файликов в свой блокнот под схемкой.  Закончив настройку, по дороге за кофе, сканируем лист блокнота и сохраняем в папку со скринами.

Что в итоге? Времени потратили не так то и много (!аргумент «нет времени»). Спустя пару тройку лет стабильной работы системы, когда уже таких систем внедрено много, все этапы настройки забудутся (!аргумент «Все знаю/помню») . Все это можно загуглить, но гугл не знает, какие параметры из сотни которые вы пробовали 2 года назад вам подошли (!аргумент «все есть в гугле»). И когда наступит время потраблшутить/потюнить/модернизировать систему, скан блокнота и скрины ой как помогут.

Бонус – забота «от подрастающего поколениия». Когда вы набрались опыта, и переходите на следующий этап, на ваше меcто приходит очередной «студент». При первой проблеме, он ходит по офису ворча: «что за ..удак тут все настраивал, ничего не понятно… кто так строит». И тут происходит самое страшное… Кто-то из офиса дает студенту ваш номер телефона. Опытные ребята уже начали улыбаться, вспоминая эти звонки… И студенту пофиг на то, что уже ночь, и вы на даче с друзьями жарите шашлыки или с семьей в Турции в роуминге.  Но все может быть иначе. При проблеме, «студент» отправляется курить папочку со скринами, схемку и т.д. (если вы ее оставили) и 90% вопросов к вам снимается.  Студент ходит по офису гордый собой («Я все починил») и рассказывает что «папередник» – красавчик.  На первом месте работе я-бы такой папочке очень обрадовался. Оставить такую папочку, как «подвесить» кофе в любимой кофейне. Запускаем цепочку добра, и оно к нам вернется.

Для инфраструктур побольше, рисуем схемы красивее (Visio).  Кроме тех документации по системам, начинаем описывать свои процессы.

Пример: Представим процесс патч-менеджмент (вы же ставите патчи ? ).  Инфраструктура не маленькая, ручками лень да и скучно… Автоматизируем. Курим мануалы, ставим, тестим. День «Х» время «Ч»… на ночь зашедулен патч всего и сразу…  А на утро, чувство эйфории обламывает «бухгалтер», у которой пропал несохраненный вордовский документ с очень важным и срочным отчетом… Тут, я думаю тоже кто-то улыбнулся.   Делаем описание процесса: «Перед запуском апдейтов, разослать всем мейл с предупреждением сохранить все важное».

Подходя к работе в крупной компании с блекджеком и… ITILом, Security, аудитами и проектами, у вас уже есть привычка описывать системы и процессы. И это вам здорово экономит время на общение с этими же аудитами/безопасниками. Вместо долгих объяснений отсылаем мейл с нужным файликом, и все. Учитывая что написать доку (или камент по ходу конфига)  нужно один раз, а аудиты/вопросы безопасников идут постоянно, время потраченное на написание доки окупиться (!аргумент «нет времени»). Вершина мастерства – ведение собственного портала с документацией (например на Docuwiki).

Но что-же делать когда жмут  сроки внедрения проектов? Только разговаривать с PM-ом. В сроки на задачу вкладывать время на документирование. Во первых, легче записать когда делаешь, чем потом вспоминать «а что ж  я тут делал»( !аргумент «не сейчас»). Во вторых, успешность проекта это не только внедрение. Система должна стабильно работать и приносить владельцу выгоду. Как разобрались выше, наличие доки способствует стабильной работе ( быстрее траблшутинг, нет проблем если поменялся админ..). Если этого не понимает РМ – поймет спонсор проекта.

Ну и в финале помним, что большие компании, особенно международные, стараются работать по стандартам. И тут наличие документации уже превращается из лишней бюрократии в обязательное требование ( !аргумент «лишняя бюрократия»). Но на пути в эту “большую компанию” Вы уже привыкли, что дока это необходимость, и это требование не вызывает у вас неприятных чувств.

Вывод:

Работа в ИТ это на 90% танцы с бубном на поле с граблями. Какие-то обошли. На некоторые больно наступили.  Рисуйте карту расположения своих граблей ( или грабель? ).  Форму и уровень детализации этой  карты выбирайте сами.