Явки, пароли, утюги на подоконнике

Проблема документирования, точнее недостаточного документирования – это классика жанра. Даже если документацию начинают вести, то рано или поздно на нее забивают, мол и так все помним, и так все знаем.

Но давно известно, что «тупой карандаш лучше острой памяти», потому как человек имеет свойство забывать, пропадать с радаров и, в конце концов, может даже попасть под автобус.

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

ОК, железку выключили, забрали. Хорошо, что сразу не стали ничего переустанавливать, есть у нас опыт, такая железка должна пару дней отлежаться.

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

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

Другой случай, звонит коллега и спрашивает, мол ты не в курсе где у нас FTP для 1С-ки? Так ты же ее ставил, не мы. Ну так найти не могу, она в каком-то контейнере, на каком-то гипервизоре, их 11 штук, руками перебирать что ли?

Ну тут только руками. Хотя и мы сами часто инспектируя доступные ресурсы не раз и не два задавались вопросом: а что именно делает этот сервер (виртуалка, VPS) и т.д., что именно тут развернуто и могу ли я… Или лучше не надо…

На самом деле это серьезная проблема, которая нуждается в отдельном внимании. Своего рода складской учет в IT. Что где лежит, зачем и почему.

Чтобы, глядя на сервер или виртуалку вы могли быстро ответить: что именно здесь работает, с какими настройками и зачем.

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

В идеале было бы неплохо завести документацию, хотя бы на уровне Excel: на каком физическом узле что стоит, где он физически находится, какие виртуалки подняты, какие роди выполняют.

Поменяли назначение ролей – изменили документацию. И очень хорошо, если вы ее дополните физическими схемами расположения оборудования и схемой разводки портов на патч-панели.

Иначе можно долго и увлекательно играть в квест: а давай выдернем этот патч-корд и посмотрим кто отвалится.

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

Как раз похожими развлечениями мы занимаемся почти месяц у одного из заказчиков, который выкупил из франшизы несколько торговых точек и теперь наводит там порядок.

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

Маркируем устройства, кабели, соединения, порты. И заносим все это в таблицу, чтобы завтра можно было посреди ночи встать и сказать в какой порт коммутатора присоединен телевизор в торговом зале.

Что касается нас, то мы всю такую документацию храним в Joplin, интегрируя туда схемы их draw io, которыми можем всегда поделиться с заказчиком или просто изучить их на объекте.

А также не пренебрегаем возможностями комментировать непосредственно в самом ПО, в том же Proxmox всегда можно написать подробный комментарий к каждой виртуалке.

Что думаете по этому поводу вы? Какие подходы используете?