DevOps-инженер ≠ админ ≠ техподдержка. Что пойдет не так, если все смешать в одну кучу
В компаниях до сих пор любят нанимать «универсального бойца»: пусть один человек и сервера настроит, и пользователю принтер подключит, и деплой запустит. В резюме пишут «DevOps», а по факту — сисадмин, которому периодически скидывают тикеты от менеджеров. Иногда он действительно выкатывает релизы. Иногда настраивает домен. Иногда чинит «1С». Даже может взбодрить кофемашину, потому что других технарей нет.
На бумаге это вроде как эффективно. Но как только начинается рост, нагрузки или любая нестандартная ситуация — все сыпется. Потому что DevOps — это не техподдержка, сисадмин — не автоматизатор, а первая линия техподдержки — не спасатель инфраструктуры. Это три разных человека. И три разных мира.
DevOps-инженер — это не человек, который и в прод зайдет, и драйвера поставит. Это инженер, который отвечает за то, чтобы изменения внедрялись быстро и безопасно. У него не спрашивают, где кабель от роутера — у него спрашивают, почему сборка сломалась или как ускорить внедрение. Если обновления задерживаются, выкладываются вручную и каждый раз с риском — это не DevOps. Это костыль с табличкой в оргструктуре. Настоящий инженер по внедрению не ловит ошибки вручную — он устраивает систему так, чтобы они не попадали в работу вообще.
Сисадмин, в отличие от DevOps-инженера, не занимается продом. Он занимается внутренним миром: сервера, сети, рабочие станции, почтовые клиенты, VPN, доступы, резервные копии. Его задача — чтобы у всех все работало. Он не пишет пайплайны, он не следит за тестами. Но если у вас отвалилась сеть или почта не приходит — вы идете именно к нему. Это человек, который знает, где стоит роутер, как заехать в BIOS и что делать, если MFP сканирует только в PDF.
Техподдержка — это вообще отдельная история. Это фронт-офис для всей этой инженерной кухни. Это люди, которые первыми слышат фразу «у меня не работает». Им не надо лезть в консоль. Им нужно быстро зафиксировать, что сломалось, понять, решается ли это на месте, и, если нет — эскалировать дальше. Это не младшие админы. Это не «девочки на ресепшене». Это сервис. И если его нет — все зависает. Потому что тикеты валяются по чатам, инженер отвлекается на каждую ерунду, никто не ведет логи, никто не отчитывается по SLA.
Проблемы начинаются, когда эти роли не разграничены. DevOps занимается обновлением Zoom на всех ноутбуках. Сисадмин пытается деплоить релиз. А техподдержка вообще не понимает, кто за что отвечает, и просто пересылает тикеты в никуда. В итоге и релизы срываются, и инфраструктура трещит, и пользователи в офисе сидят без интернета. Безопасность никто не проверяет. Бэкапы никто не тестирует. Мониторинга нет.
Когда мы входим в проект, первым делом мы смотрим: кто и за что у вас отвечает? Кто выкатывает код? Кто следит за продом? Кто админит офисную сеть? Кто принимает инциденты от пользователей? Если все это делает один человек — мы сразу видим, где узкое место. Если два, и они друг друга дублируют — значит, кто-то точно не справляется.
Потом мы разделяем зоны ответственности. Объясняем бизнесу, где заканчивается работа инженера по внедрению, и начинается зона системного администратора. Помогаем понять, когда стоит настраивать автоматизацию, а где достаточно понятных инструкций и регламента.
Системная работа начинается с системного подхода. И самое базовое — это не путать людей, которые делают инфраструктуру устойчивой, с теми, кто ее просто чинит.
Если хотите, чтобы ваша инфраструктура росла вместе с продуктом, а не тормозила его — сначала разберитесь с ролями. А мы поможем это правильно оформить, внедрить и поддерживать.
Отправить заявку
Оставьте заявку, и мы свяжемся с вами в течение суток
