Windows и Linux в одной компании: единый контур администрирования

Типичная картина среднего бизнеса: Active Directory и файловые шары на Windows, сайт и API на Linux, 1С на отдельной виртуалке, почта в облаке. Windows «ведёт» один подрядчик, Linux — другой, сеть когда-то настроил третий. Пока всё работает, кажется, что так и должно быть. Пока не падает что-то между системами.

«Сайт не открывается» — звонят вебщикам. Те отвечают: «у нас контейнер живой, смотрите DNS и файрвол». DNS — у Windows-команды. Файрвол — «это не мы». Через два часа директор всё ещё не понимает, к кому звонить, а клиенты уже пишут в поддержку.

Проблема не в том, что у вас и Windows, и Linux. Гибрид — норма для компаний от нескольких десятков сотрудников. Проблема в том, что ими управляют как двумя несвязанными мирами: разные договоры, разные заявки, разный мониторинг, разная документация. На стыках рождается простой, который формально «ничья зона».

Как выглядит разрыв на практике

Первый сценарий — инцидент «между зонами». API на Linux перестал отдавать данные в 1С на Windows. Каждый подрядчик чинит «своё» и клянётся, что у него всё зелёное. Нет общей схемы зависимостей, нет единого окна эскалации. Время реакции уходит на переговоры, а не на диагностику. Бизнес видит только одно: заказы или документы не двигаются.

Второй — патчи и окна обслуживания. Windows обновляют в одно воскресенье, Linux — в другое, без общего плана. После апдейта AD ломается LDAP-авторизация веб приложения. Обе стороны правы по контракту — и сервис всё равно лежит. В отчётах два «успешных» изменения, в жизни — один сорванный понедельник.

Третий — уход одного из подрядчиков. Половина инфраструктуры «осиротела»: доступы в голове у человека, который уже не отвечает на письма. Документации нет, мониторинг разный, бэкапы проверяли «когда-то». Новый исполнитель тратит недели на раскопки вместо развития.

Четвёртый — отчётность для руководства. Вместо одного понятного статуса IT приходят три письма с разной терминологией. Директор не видит сквозной картины рисков и не может принять решение о бюджете.

Где обычно ошибаются

Самая частая ошибка — считать, что два узких специалиста всегда дешевле одного контура ответственности. На бумаге ставка часа ниже. В сумме вы платите за простои на стыках, дублирование заявок и отсутствие сквозного владельца P1.

Вторая ошибка — мониторинг «по платформам». Windows в одной системе, Linux в другой, облако в третьей. Красивые дашборды есть. Единого сигнала «бизнес сервис недоступен» — нет. Клиент узнаёт раньше дежурного.

Третья — надеяться, что схема сети «у сисадмина в голове». Пока человек на месте, кажется нормально. В отпуск или после увольнения выясняется, что никто не знает, какой VLAN отвечает за обмен с 1С и кто имеет право менять правила файрвола.

Что значит единый контур

Единый контур — это не «один человек знает всё на свете». Это договорённости и инструменты, при которых смешанная среда ведётся как одна система: одна очередь инцидентов, одна карта серверов и зависимостей, один план патчей, один мониторинг критичных бизнес сервисов, понятные зоны ответственности без фразы «это не наша часть».

Практичный старт — лёгкая CMDB: таблица хостов, ОС, роли (контроллер домена, файлы, веб, БД, VPN, почтовый контур), владельцы процессов, целевые время восстановления и допустимая потеря данных. Без этой таблицы любой «междузонный» инцидент снова превращается в пинг понг.

Дальше — единый мониторинг не всех метрик подряд, а сервисов, которые кормят деньги: 1С, сайт, приём заявок, почта, AD, VPN. Диск, CPU, службы Windows и systemd-юниты Linux смотрят как симптомы одного контура. Алерт должен попадать в один канал с нумерацией и эскалацией.

Патчи и изменения планируют общим календарём. Если обновление Domain Controller затрагивает LDAP для Linux-приложений — это один change с проверкой цепочки, а не два независимых «успешных» заявки.

Документация доступов — живой артефакт: кто админ AD, кто root на веб хостах, где бэкапы, куда смотреть логи, как выглядит процедура восстановления. Это скучно писать и критично в два часа ночи.

Как действовать, если сейчас два подрядчика

Не обязательно рвать контракты завтра. Сначала зафиксируйте критичные цепочки: «заявка с сайта → CRM → 1С», «сотрудник → AD → файлы», «удалёнка → VPN → внутренние сервисы». Для каждой цепочки назначьте одного ответственного за эскалацию — даже если руками чинят разные люди.

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

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

• кто берёт P1, если сбой на стыке Windows и Linux;
• есть ли единый канал алертов и сквозная нумерация инцидентов;
• обновляют ли обе платформы по одному плану изменений;
• можно ли восстановить среду без человека, который «всё помнит»;
• как выглядит отчёт для бизнеса: сервисы и риски, а не список серверов.

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

Что проверить за две недели

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

Параллельно соберите одну страницу зависимостей: какие бизнес сервисы на каких хостах и через какие протоколы ходят друг к другу. Даже черновик в таблице уже снижает время диагностики. Добавьте контакты эскалации и каналы алертов — без этого карта мёртвая.

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

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

Итог

Windows и Linux в одной компании — не повод плодить два IT мира. Разрыв на стыках дороже, чем кажется: он проявляется не в счётах подрядчиков, а в часах простоя, пока все формально «не в своей зоне».

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

Соберите карту ролей и зависимостей, сведите мониторинг и эскалацию, договоритесь о общем плане изменений. Лучше сделать это до следующего «сайт живой, а заказы не идут», чем объяснять клиентам, почему два подрядчика зелёные, а вы — нет.