​​Лог включен, но мало помогает

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

И, к сожалению, подобные отзывы не единичны. Многие считают, что лог должен… А вот что он должен?

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

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

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

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

Еще одна классическая ошибка – смотрим не туда. Чаще всего это связано с тем, что «ошибка» в понимании пользователя не является ошибкой для сервиса и соответственно вы не увидите никакой записи об ошибке в таком случае.

Характерный пример – это состояния HTTP, многие из которых воспринимаются клиентом именно как ошибки. Но для самой системы это вполне допустимые и документированные состояния, которые являются частью штатного рабочего процесса.

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

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

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

Это позволяет быстро и эффективно выявить ситуации, когда мы обращаемся не туда или не так. Например, как это часто бывает, ваши запросы блокируются брандмауэром, а вы пытаетесь безрезультатно терзать веб-сервер.

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

А еще – логи нужно уметь читать. Мы сейчас не будем брать во внимание крайний случай, когда квалификации явно недостаточно и все написанное в логе является «китайской грамотой».

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

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

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

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

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

Поэтому просто включить лог – это мало, нужно понимать что именно вы хотите в нем увидеть и почему именно в нем.

​​Используем спецсимвол ! в командной строке Linux

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

Поэтому попробуем заполнить этот пробел. Восклицательный знак используется для повторения команд и аргументов команд. В самом простейшем виде наберите:

!!

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

sudo !!

Немного сложнее, если команду надо было выполнить от другого пользователя, например, postgres:

su -c “!!” postgres

Также с помощью восклицательного знака легко повторить команду из истории, выполните

 history

Посмотрите номер нужной команды и введите:

 !38

Что заново выполнит команду из истории под номером 38.

Также мы можем повторить выполнение команды со всеми аргументами, допустим мы выполнили:

cat /home/andrey/123.txt /home/ivan/321.txt

Для ее повторения достаточно выполнить:

 !cat

или вообще

 !с

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

Мы можем не только повторить, но и добавить аргументы, например:

!cat /home/andrey/456.txt

Что будет эквивалентно

cat /home/andrey/123.txt /home/ivan/321.txt /home/andrey/456.txt

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

Для первого и последнего используйте !^ и !$

Так после выполнения последней команды мы можем указать:

 cat !^ !$

Что приведет к выполнению:

 cat /home/andrey/123.txt /home/andrey/456.txt

Либо можем указать аргументы явно, для последней команды можем использовать !:2 – второй аргумент, или указать команду явно, тогда будет использован указанный аргумент последнего запуска команды:

cat !cat:2

Будет аналогичен:

cat /home/andrey/456.txt

Обратите внимание, что к аргументам также относятся и ключи, поэтому если после запуска

cat -n /home/andrey/456.txt

Вы введете:

cat -n !^

То будет выполнен:

cat -n -n

без аргументов.

​​Полезная для начинающих утилита с неприличным именем

Работая в консоли Linux, начинающие делают ошибки, это нормально. Гораздо хуже, когда ее не удается быстро исправить или поиск информации затруднен.

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

Утилита разработана на Python и для ее установки выполните:

sudo apt install python3-dev python3-pip python3-setuptools
pip install thefuck -–user

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

После чего в файл .bashrc внести строку:

eval $(thefuck --alias fuck)

Которая добавит для команды алиас fuck, если вам ближе родная речь, то можете написать:

eval $(thefuck --alias blya)

Затем перечитайте значения из файла или перезапустите сеанс:

source .bashrc

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

fuck

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

Чтобы избежать постоянного вызова утилиты можно запустить ее в режиме повторения:

fuck -r

Теперь она будет последовательно обрабатывать все полученные ошибки до получения результата, либо пока вы не прервете ее действия.

Если вы хотите применять исправления автоматически, то вызовите утилиту с ключом:

fuck -y

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

Больше об утилите можно узнать на официальной странице Git: https://github.com/nvbn/thefuck

​​Настраиваем Visual Studio Code для удаленной работы через SSH

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

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

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

Поэтому гораздо удобнее использовать для этого специальные среды разработки, например, VS Code, тем более что он прекрасно умеет работать через SSH.

https://interface31.ru/tech_it/2024/05/nastraivaem-visual-studio-code-dlya-udalennoy-raboty-cherez-ssh.html

​​Система автономного обновления Linux

Многие пользователи и администраторы настольных систем на базе Linux заметили, что теперь обновления системы происходит при перезагрузке, совсем как в Windows.

Теперь мало просто запустить обновление, нужно еще обязательно перезагрузить систему и дождаться их установки. Кто-то воспринял данные новшества положительно, но многим это не понравилось, поэтому в данном материале мы постараемся подробно рассмотреть этот вопрос.

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

Впервые проблема с обновлениями была сформулирована разработчиками Fedora еще в 2009 году. Тогда основной претензией было то, что обновления поставляются хаотично, не тестируются в комплексе и непонятны пользователям.

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

Вторая проблема – это возможная работа пользователя в процессе обновления, Linux умеет заменять файлы уже запущенных приложений, но не все приложения умеют корректно обрабатывать такую ситуацию.

Тот же Firefox обнаружив обновление файлов программы попросит вас перезапустить браузер, но иные программы могут завершиться с ошибкой, зависнуть, вызвать темный экран и т.д. и т.п.

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

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

Чтобы решить все эти проблемы была разработана система автономного обновления, которая состоит из двух основных компонентов: пакетного менеджера и специальной службы systemd.

Теперь пакетный менеджер только скачивает обновления и уведомляет systemd об их наличии.

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

Также на пользователя не вываливается вся куча обновлений, а разбивается на метапакеты: обновление системы (23 пакета), обновление KDE (15 пакетов), обновление Firefox, LibreOffice и т.д., что делает процесс более понятным для пользователя.

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

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

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

При загрузке в нормальном режиме пользователь получит сообщение либо об успешном обновлении системы, либо об ошибке.

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

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

С технической стороны это делает систему более надежной и практически на 100% гарантирует ее загрузку в графическом режиме (за исключением действительно серьезных проблем).

​​Специальные символы-операторы командной строки Linux

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

Начнем с символа & - амперсанд. Этот оператор заставляет команду работать в фоновом режиме. Т.е. если вы знаете, что команда выполняется какое-то продолжительное время, просто отправьте ее в фон следующим образом:

command &

Но будет ошибкой использовать ее для объединения команд, чаще всего ошибаются похожим образом:

apt update -y & apt full-upgrade -y

К удивлению запустившего, первая команда запустится в фоне, а вторая одновременно с ней, но интерактивно. Понятно, что требуемая задача выполнена не будет.

Для объединения команд используется оператор && - логическое И. Несмотря на всю схожесть с прошлым оператором ее смысл совсем иной. В конструкции:

command _1 && command _2

Вторая команда выполниться только при успешном выполнении первой, т.е. если она вернула код выхода 0.

Поэтому правильная команда для обновления системы будет выглядеть так:

apt update -y && apt full-upgrade -y && apt autoremove -y

Также все знают оператор | - пайп или труба. Он позволяет передать поток вывода одной команды в поток входа другой.

А вот если мы поставим подряд две трубы - || - то получим оператор логическое ИЛИ, в конструкции:

command _1 || command _2

Вторая команда будет выполнена только тогда, если первая вернет код ошибки.

В более сложных конструкциях можно использовать И – ИЛИ:

command _1 && command _2 || command _3

Если первая команда завершилась успешно, то будет выполнена команда 2, иначе – команда 3.

​​PortQry v 2.0 – консольный сканер портов для Windows

Инструментов для диагностики сети хватает, но лишних среди них не бывает, поэтому сегодня хотим рассказать о консольном сетевом сканере от Microsoft - PortQry v 2.0, получить его можно на официальной странице: https://www.microsoft.com/en-us/download/details.aspx?id=17148

Использовать ее довольно просто, нам потребуется указать несколько параметров:

-n – точка назначения – имя или адрес сетевого узла
-p – протокол, доступны значения: tcp, udp, both, по умолчанию tcp.
-e – порт назначения
-o – перечень портов через запятую
-r - диапазон портов через двоеточие

Например:

PortQry.exe -n 192.168.100.125 -p udp -e 1194

или

PortQry.exe -n 192.168.100.125 -o 80, 443

В зависимости от результата вы получите одно из значений:

Listening – если порт открыт и ответ от него получен

Not Listening – если на целевом узле не запущен процесс обслуживающий порт и система сообщает ICMP «Destination Unreachable - Port Unreachable» или получен TCP-пакет с флагом Reset.

Filtered – если система не направила никакого ответа или запрос был отфильтрован брандмауэром.

Но это далеко не все, иначе данный инструмент просто ничем не выбивался из категории себе подобных.

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

Таким образом, чтобы определить, действительно ли порт открыт или фильтруется PortQry использует расширенные проверки для ряда протоколов, в их число входят: LDAP, RPC, SMTP/POP3/IMAP4, SNMP, FTP/TFTP, NetBIOS, MS SQL, L2TP и ряд других.

На картинке внизу показан запрос к порту MS SQL, утилита первоначально проверила порт и выдала предварительную оценку: LISTENING or FILTERED.

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

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

PortQry.exe -n 192.168.100.125 -sp 25 -e 25

Кроме того, у утилиты существует локальный режим, в котором она работает с сетевыми процессами хоста, в этом варианте интересными могут быть ключи:

-local – показывает информацию обо всех активных портах и соединениях локального узла
-wport – мониторит сетевую активность указанного порта
- wpid – мониторит сетевую активность процесса с указанным PID

Данные возможность удобно использовать с записью в лог файл:

PortQry.exe -wport 3389 -wt 5 -l rdplog.txt

Где ключ -wt задает частоту опроса в секундах, доступные значение 1-1200, по умолчанию 60 сек, а ключ -l указывает файл журнала, при указании относительного пути журнал создается в директории с утилитой.

Размер заметки не позволяет перечислить все возможности, поэтому дадим ссылку на страничку официальной документации: https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/networking/portqry-command-line-port-scanner-v2

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

​​Как узнать какие пакеты установлены из определенного репозитория

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

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

Чтобы получить интересующую нас информацию прежде всего выведем список подключенных репозиториев командой:

apt policy 

В ее выводе нас прежде всего будет интересовать опция «источник (origin)», которая выводится после ключа o=.

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

apt list ~Onginx

В данном случае указываем наименование источника сразу после ключа ~O, без пробела. Обратите внимание, что данная команда выводит все пакеты, содержащиеся в репозитории, установленные пакеты при этом помечены отдельно как [установлен].

Если репозиторий небольшой, то этого достаточно. Вы можете быстро понять, что из него уже установлено, что вы можете установить и нужно ли это вам вообще в текущий момент времени.

В противном случае нужно будет добавить дополнительные отборы, например, добавим фильтр по только установленным пакетам:

apt list ?and\(~i\,~Oprox\)

Здесь мы соединили через логическое И два условия: пакет установлен ~i и пакет принадлежит определенному источнику ~O, также не забывайте использовать обратный слеш для экранирования служебных символов.

Также обратите внимание, что имя источника не обязательно указывать полностью, так как это регулярное выражение. Так для репозитория o=Proxmox мы использовали просто ~Oprox.

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

Статус [установлен, автоматически] обозначает что мы не выбирали этот пакет для установки, и он был получен автоматически, по зависимостям. Для больших репозиториев таких пакетов может оказаться сильно много, и они серьезно ухудшают восприятие. Поэтом добавим еще одно условие:

apt list ?and\(~i\,\!~M\,~Oprox\)

Где параметр !~M обозначает «кроме установленных автоматически». Теперь вывод команды покажет только пакеты, которые были установлены вручную из указанного репозитория.

Данные конструкции можно использовать не только с командой apt list, но и с любыми другими командами apt, например для установки или удаления пакетов. А больше информации вы можете получить при помощи:

man apt-patterns

Ну или обратившись к подобной информации в сети интернет.

​​Узкий профиль или болото?

В комментариях недавно всплыл вопрос эксплуатации откровенно старых систем. Мол все что вы пишете – хорошо, но попробуйте это применить на … (можете вписать любой устаревший софт).

На аргументы, что данный софт уже много лет как снят с поддержки применяется контраргумент, что мол много таких систем, где все это живо до сих пор и жить будет еще долго.

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

Далее от его лица, моя только литературная обработка.

Довольно давно, еще в начале десятых я попал на одно торгово-производственное предприятие. Им нужен был программист для 1С с навыками этой самой 1С администрирования. Компания только-только перешла на «восьмерку», и старый программист не тянул.

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

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

Стек технологий у меня оставался стабильным, точнее стабильно древним: FoxPro, Visual Basic 6, Windows, COM и 1С на обычных формах. Новая 1С, которая 8.3 и на управляемых формах как-то не зашла (там сильно переучиваться надо было) и стояла только в бухгалтерии, благо дорабатывать ее было не нужно.

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

Первый звоночек прозвучал в короновирус, когда мы серьезно просели по выручке и несколько месяцев получали голый оклад. Стало, мягко говоря, тяжело, тем более что накоплений особо не было (все ушло на стройку), а кредиты сами себя не заплатят.
Когда жизнь снова стала входить в привычное русло меня пригласили на один проект хорошие знакомые. Они как раз мигрировали подобную внутреннюю систему с FoxPro на новую 1С и им нужен был человек разбирающийся в FoxPro.

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

Также посмотрел я и на «новую» 1С, которая оказалось может и умеет гораздо большее, чем я мог себе представить.

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

Но если придется менять работу, то максимум я могу претендовать на позицию «джуна», но «джун» возрастом под 40 лет – это не то, что способно заинтересовать работодателя.

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

Но что делать как-то в голову не приходило. Да, надо было учить, но когда?

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

По приезду состоялся разговор, мол, а если тебе завтра кирпич на голову упадет? Я сказал, что тоже об этом думал и «покаялся», рассказал дяде про халтурку и то, как там было все устроено.

После чего дядя сказал, мол, а чего ты раньше молчал? Давай думай, предлагай, нужно двигаться вперед. Надо учиться – отправим, но мы не должны отставать от технологий.

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

Очередная раздача слонов.

Условия, как всегда, самые демократичные - кто первый встал, того и тапки.

Но Минздрав предупреждает - перед тем как бежать вбивать данный промокод теряя тапки стоит поинтересоваться стоимостью продления.

😎 БезопасноеХранилищеДанных в 1С такое безопасное...

Все знают про то, что не стоит верить написанному на заборе. Как оказалось написанному в 1С тоже.

Сегодня потребовалось узнать пароль от FTP сохраненный в 1С. Как оказалось - нет ничего проще, он открытым текстом лежит в регистре Безопасное Хранилище Данных.

Готовая обработка здесь: https://infostart.ru/public/1155324/

Хотя она за 5 минут пишется на коленке.

Это мы к чему? Да к тому, что любой, кто имеет доступ к базе и владеет программированием под 1С быстро и непринужденно вытащит ВСЕ сохраненные в базе пароли.

​​Узкий профиль или болото? Часть 2.

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

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

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

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

Обмен происходил штатными средствами 1С через РИБ, т.е. с задержкой в 15-20 минут. Но перед этим данные еще должны были попасть в 1С из нашей внутренней программы, которая взаимодействовала с 1С через COM и там тоже была задержка в 5-10 минут, в зависимости от объемов данных.

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

А теперь представьте, клиент неправильно посчитал плитку, бригада на объекте, нужно срочно еще ящик-другой. Бригадир берет кусок плитки и едет сразу на склад. Находят нужную партию и дальше начинаются качели длинной в полчаса.

Со звонками, мол Маша, позвони ему и скажи пусть отгрузит, у меня лимит есть, мне сегодня этот объект закончить надо, там клей уже разведен… и т.д. и т.п.

А кладовщик: как накладная придет – так отгружу, извини, я материально ответственное лицо.

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

Но справились и когда мы это внедрили даже в зачаточном состоянии, то получили эффект разорвавшейся бомбы. Все сразу начали спрашивать: а что, так можно было, и почему вы раньше так не сделали?

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

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

К виртуализации у меня долгое время было отношение как к чему-то не для простых смертных. Ну да, работая в основном на Server 2003 / 2008 было немудрено.

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

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

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

Но посмотрев на виртуалки и контейнеры в деле я стал понемногу внедрять виртуализацию у себя по принципу «один сервис – одна виртуалка». Процесс тоже был довольно непрост. Зато теперь можно гибко управлять всей инфраструктурой не боясь, что обновление сервиса А завалит сервисы Б, В, Г, Д и далее по алфавиту.

Кроме того, появилась возможность разделить роли между сотрудниками. Этот отвечает за почту, этот за сайт, а этот за базы данных. У каждого свои виртуалки, свой объем работ и свой уровень ответственности.

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