2. Документировать все, что можно. Здесь вздорность видно даже невооруженным глазом. Внимательный читатель должен и сам заметить, что такая постановка задачи есть следствие из только что обсужденного заблуждения. Ибо, когда возникает проблема документации? Только тогда, когда сисадмин выполнил нештатную модификацию. И только в этом случае он должен задокументировать ее, так как все ординарные действия уже описаны в руководствах, сопровождающих ИС и ее компоненты.

Более того, если задуматься, то процедура документирования, как сугубо ручной процесс, в корне противоречит принципам эксплуатации автоматизированных систем. Вопрос нужно ставить так, что ИС должны обладать свойствами самодокументирования. Например, из предыдущего тезиса – «проверка свободного дискового пространства», если такой параметр протоколируется, чем данные отчеты не документация? Ведь можно рассматривать некий мониторинг, а можно и задокументировать моментальное значение выбранного параметра.

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

3. Общаться как можно больше. Это самый смешной раздел! В глазах всех пользователей сисадмин, в лучшем случае, «домовой из аппаратной». В глазах сисадмина пользователи, в лучшем случае, назойливые источники проблем. Рассказывать пользователям о структуре системы или небезопасно, если они въедливые, или бесполезно во всех остальных случаях. Вообще глупо это делать заранее. У нормального сисадмина должно хватать время только на ответы, а никак не на инициативные лекции. В анализе рассматриваемого тезиса возникает сильное ощущение, что авторы спутали пользователей и заказчиков. Причем это не описка, это системная ошибка, так как, оказывается, у данной идеи есть еще и подпункты, детализирующее это заблуждение. Рассмотрим их в том же порядке.

3.1. Рассказывайте пользователям, что вы собираетесь делать. Если выполняется плановая операция, то надо не рассказывать, а предупреждать, иначе выполняется операция по запросу пользователя и в рамках штатных обязанностей сисадмина, и, значит, опять же не о чем рассказывать. Да и что может быть вздорнее, чем болтливый и «липучий» сисадмин? Ну разве что генерал, бегущий вприпрыжку в мирное время!