Как-то, у нашей компании накопился ряд задач, связанных с администрированием наших серверов, и руководство приняло решение, что всё-таки нам нужен DevOps, который закроет наши вопросы и будет в долгую сопровождать нашу команду. Решились. Разместили на https://hh.ru/ вакансию. Нашли человека в городе М.. Руководству было важно, чтобы он был с того же города, где и компания. Но мы никак не могли предположить, что этот человек, который проработал с нами буквально 6 месяцев, чуть не потопил всю нашу компанию. Но, обо всём по порядку.

Хочется для начала, тем, кто несведущ, немного прояснить - что это за должность такая DevOps. Чем он занимается, и что обычно входит в его обязанности. ИИ нам скажет, что DevOps это:
DevOps-инженер — это специалист, который соединяет разработку (Dev) и эксплуатацию (Ops). Его задача — сделать так, чтобы программные продукты быстро, стабильно и безопасно попадали в продакшен и нормально там работали. DevOps отвечает за инфраструктуру.
Ключевая идея:
разработчики пишут код → DevOps автоматизирует его сборку, доставку, запуск и поддержку.
От себя же добавлю что у нас в России - из-за непонимания DevOps-культуры, эта должность имеет более широкое понимание. И охватывает, по сути, все, что связано с теми, кто работает непосредственно с серверами - это в какой-то степени царь и бог для серверов, которые есть у компании. Он знает все пароли, у него есть ключи от всех врат - при условии, если вы дали эти ключи. Это все нужно ему для выполнения своих обязанностей. Ведь не имея ключа или пароля - очень сложно настроить сервер или настроить микросервис, которому нужны правильные доступы .

Можно конечно ограничить политики для любого человека, но тогда нужен человек, кто настроит эти ограничения и будет понимать что делать - тогда это тоже будет считаться DevOps. Только выше. Вот в этом понимании я и хочу поделиться нашей дальнейшей историей.
Но в начале, немного вводных данных - что мы имели на тот момент. Два контура (изолированные среды): дев (где разрабатывают и тестируют) и прод (где работают реальные пользователи). Выделенные физические сервера. Один был размещен в ДатаЦентре, который располагался в Москве. Другой в Санкт - Петербурге. Система proxmox. И десятки виртуальных маши��, содержащие различные микросервисы. Облако Яндекс - для Бэкапов. И трафик обслуживающий, порою, несколько тысяч пользователей. Да, это не великая инфраструктура, но тем не менее административных задач хватало.
Итак, у нас возникла потребность - решить некоторые вопросы, а именно:
Настроить Zabbix (мониторинг работы аппаратных ресурсов, анализ трафика и т.д.). Хотя была настроена Grafana + Prometheus - но новый Тимлид решил, что лучше Zabbix
сделать CI/CD доставку приложений через git autorun
Так как на одном из физических серверов заканчивались аппаратные ресурсы, их нужно было расширить, но при этом попробовать оптимизировать расходы и выбрать хостера, который предложит более выгодную цену. То есть нужен был переезд с одного сервера на другой.
Много что еще по мелочи, но тут главное - понимание, что задач хватало и на перспективу.
Как проходил непосредственно отбор кандидата мне не известно, но в какой-то момент времени в нашей команде появился он, DevOps по имени С. Человек, действительно себя на словах показал хорошим спецом и показал хорошую осведомленность в том, как работают современные решения, рассчитанные на большое количество пользователей. Он с энтузиазмом взялся за работу и мало по мало начал закрывать наши задачи.
Все было хорошо, но с течением времени С. начал пропускать дейлики и митинги по разным причинам. Начал в долгую отвечать на рабочие вопросы и всячески показывать, что как будто бы ему не до нас. Решение каждой задачи приходилось фигурально «выбивать», и после настойчивых неоднократных просьб что-то решалось. В таком ритме работы, прошло несколько месяцев. Руководство осознало, что нашей команде с С. не по пути и приняло решение расторгнуть трудовые отношения.
Но как сделать это безопасно? Так, чтобы не пострадал наш механизм в случае, если сотрудник решит, что «разрыв» трудовых отношений произошел не по обоюдному согласию. Мало ли что человек может сделать, имея на руках чувствительные данные. И руководство предприняло ряд защитных мер, в день когда оно объявляло С. о принятом решении, оно поменяло все пароли и заблокировала все учетки связанные с С. Расторжение состоялось. Кажется все выдохнули. И тут спустя 5 дней после увольнения С. началось…
В момент когда у нас обычно был еженедельный рабочий созвон, клиенты стали жаловаться на недоступность сервисов. Сразу пришла мысль - что все таки С. оставил нам пасхалочку. Так и вышло. Был запущен скрипт на уничтожение всего, что есть на сервере путем чего-то подобного:
rm -rf /.
Но точно мы не знаем. Судя почти по всем логам, произошло какое-то адское событие ядра, потому что в лог файлах они не просто прервались, а туда null поинтеры залогировались в промежутке до рестарта.

Так как это достаточно долгий процесс, мы успели забрать логи с сервера и впоследствии выяснить что произошло:
Итак, последовательно:
С. за месяц до события Х. (Видимо что-то чувствовал) регистрирует нового пользователя «bin». Дает ему все самые суперские права. Делает это с польского ip адреса посредством vpn. Благо он это делает только на продовском сервере (не знаю почему, может потому что девопсы, как и большинство программистов по природе немного ленивы)
После увольнения, через несколько часов, он авторизуется и проверяет: сохранился ли у него доступ через этого пользователя.
Убедившись в этом, он регистрирует крон задачу на уничтожение всех файлов через 5 дней. Ровно в то время, когда у нас обычно рабочее совещание.
Потом, спустя некоторое время, от С. одному из сотрудников приходит сообщение «а вы чего сервер что ли положили, у вас ничего не работает». Далее он предложил за сумму в 1 лям все исправить.

Конечно, нам не удалось спасти наш прод сервер. Мы потеряли все. Смысла не было там дальше что-то искать.

Это история могла бы так печально закончится, но!
У нас до устройства на работу С. было Яндекс облако, и в одном из бакетов хранились архивы всех виртуальных машин. Да, их актуальность не была до 1 дня, но к счастью большинство сервисов работали уже долгое время, и давно не обновлялись. В отношении бэкапов базы данных. Да конечно же они делались. Но были С. так же уничтожены.
По счастливой случайности, у одного из сотрудников был сделан бэкап всей базы данных. Он его сделал до всей этой истории для каких то своих работ, и мы смогли успешно восстановиться. Да, это была не слишком актуальная база данных, так как пользователи активно юзали сервисы, но все же мы смогли договориться и объяснить причину пропажи данных нашим клиентам. Все обошлось малой кровью.
И, как говорится мораль сей басни такова: Она конечно не нова – случайных людей не допускайте к власти, Иначе беды ждут, напасти, И пожалеете вы вскоре, Когда от них хлебнете горя!
Конечно, по идее хорошо бы иметь:
RBAC (Role-Based Access Control) - Управление доступом по ролям. Чтобы доступ выдавался не человеку напрямую, а роли. Чтобы при увольнении было достаточно убрать роль.
IAM (Identity and Access Management) - Централизованное управление идентификацией и доступами. Кто ты. К чему у тебя есть доступ. П��и увольнении — одна кнопка disable
Zero Trust - Никому не доверяем по умолчанию. Даже своим. Доступ временный, а не вечный. Доступ к проду — через bastion / jump-host. Cron, systemd, root — под аудитом. Никто ничего физически не смог бы сделать незаметно.
Но негоже махать руками после драки. Да и кто это все будет настраивать - он же может и сделать обратное.
Тут выводы конечно сделать сложно, что может помочь избежать подобных ситуаций и какие дать советы. Главное, наверное, чтобы заинтересованное лицо всегда знало о подобных рисках. Быть готовым к подобным выкрутасам. Делать бэкапы всего и вся. Доверять, но проверять. Думать, что я буду делать, если человек окажется неадекват и будет держать за горло всю компанию, по сути, шантажируя ее. Будьте осторожны, учитесь на чужих ошибках и берегите себя.
Может кто-то уже сталкивался с чем то подобным и поделится своим опытом в комментариях.
Всем лучиков добра и ясной погоды!
Комментарии (10)

select26
16.12.2025 23:22И, как говорится мораль сей басни такова: Она конечно не нова – случайных людей не допускайте к власти, Иначе беды ждут, напасти,
Вывод совершенно не верный.
С вашим подходом и неслучайные люди все сломать могут.
Как выше уже отметили - системный подход, процедуры и резервные копии являются основой, а вовсе не подбор персонала.
Robastik
16.12.2025 23:22системный подход, процедуры и резервные копии
Как они заводятся независимо от персонала ?

riv9231
16.12.2025 23:22В отношении бэкапов базы данных. Да конечно же они делались. Но были С. так же уничтожены.
Я себе, так концептуально представляю решение этой проблемы: Должно быть два человека - один отвечает за администрирование серверов (или devops как здесь), второй занимается аудитом, организацией и контролем за документированием и бекапом.
Кроме того, я отказался от попыток делать реестры данных подлежащих бекапу, по тому что, по большому счету, не нужных данных не бывает. По этому был выработан подход тотального бекапа:
- всё находится в proxmox в виде виртуальных машин и контейнерах поверх локальных zfs и zvol на гипервизорах.
- Несколько раз в день данные бекапятся с помощью дифференциального бекапа на основе zfs send-receive
- скрипт бекапа автоматически ищет все виртуальные машины и все контейнеры, которые могут переезжать между гипервизорами, автоматически сопоставляет с подходящим бекапом-назначением и бепапит все харнилища каждой вм или контейнера в режиме pool, т.е. запускается с бекапных серверов.
- бекапные сервера имеют независимую авторизацию, на них нельзя зайти с учетками от любых других серверов. Скрипты с бекапного сервера могут выполнять задачи на остальных серверах, а в обратном направлении - нет.Скажете дорого? Но если учесть, что поддержание реестров в актуальном состоянии - это тоже работа требующая оплаты и дополнительный риск возникновения неактуальности этих реестров, увеличение сложности всей системы. Отказ от облаков для бекапа с опорой на zfs тоже в разы удешевляет бекап.
Я вижу только одну угрозу. Злоумышленник может настроить прозрачное шифрование, которое длительное время будет работать незаметно. Для этого и должен быть аудитор, который проверяет а что и как там настроено.

amnesiax
16.12.2025 23:22Ключевая идея:
разработчики пишут код → DevOps автоматизирует его сборку, доставку, запуск и поддержку.
DevOps → SRE (Critical Boundary)
This is a responsibility boundary, not a tooling boundary.
DevOps is accountable for delivery into production.
SRE is accountable for production behavior over time.DevOps asks: “Is it deployed correctly?”
SRE asks: “Does it continue to meet SLO under real failures?”
SRE owns SLOs, error budgets, incident response, postmortems and has authority to block releases.
От себя же добавлю что у нас в России - из-за непонимания DevOps-культуры, эта должность имеет более широкое понимание. И охватывает, по сути, все, что связано с теми, кто работает непосредственно с серверами - это в какой-то степени царь и бог для серверов, которые есть у компании
Это из-за низкого уровня компетенций в понимании смысла разделения ролей.
Как пример - буквально сегодня общался с одним маркетплейсом W****s - у них описание SRE-инженера включает в себя следующие роли ниже (ответственность):
- Firmware / BIOS / burn-in ->> Platform Hardware Engineer
- OS / Kernel / FS / Network ->> System Administrator
- Container platform / Application deployment ->> DevOPS
- Reliability / Incidents ->> SRE
Не понимают что,
1. Это принципиально разные роли, с разными требованиями к навыкам, психологическому профилю, уровню компетенций, практическому опыту работы, объемом ответственности перед бизнесом.
2. Из-за списка выше, разница, например, в оплате между Platform hardware Engineer и SRE (высшая степень ответвенности перед бизнесом) может доходить до 50%.
3. Непонимание пунктов 1 и 2 выше-это попытка нанять\заманить человека-паука, который через какое-то время либо выгорит и сбежит, либо просто сбежит.
Выше описанное касается и секьюрити вещей - не просто так придуман код-ревью\секьюрити чеки, продецуры ступенчатого контроля за доступами (апрувы).

Golex
16.12.2025 23:22Слышал давнюю историю, что пришел хороший админ, все настроил, все засекурил и .... пропал. Совсем. Кажется после зарплаты или там премии квартальной - то есть быстро. По месту жительства не нашли. Ну повзламывать пришлось админские пароли. А потом позвонили из дурки, удивились что работодатель не знал, что это их постоянный клиент. С белочкой - белой горячкой. Потом выяснилось что у него это был цикл: устроился на работу, получил денег, напился, попал в дурку с белочкой, уволили, повторить.
Очень давно это было. Тогда тоже не очень то внимательно с персоналом работали. А алкоголизм среди интеллектуалов - явление распространенное.
Да и ИТ саботаж не так уж и редко встречается, хоть и не в таких острых формах.
Зачем ваш С. к вам на работу то устраивался? В чем была причина конфликта? Налево работал? Судиться, конечно, не стали?

ky0
16.12.2025 23:22Вы, конечно же, обратились в полицию и инициировали расследование? А чо нет?
В целом, между строк можно прочитать пару тревожных флажочков (поправьте, если я ошибаюсь):
"Сперва купи картину, а затем рамку" - инфраструктуры, которые появляются раньше, чем нанимают людей, способных осознанно их спроектировать и развернуть, это 99% боль.
Хороший девопс-инженер, это человек, который знает не меньше, а больше среднего разработчика (условные 50% разработки + 100% админства). И получать должен соответствующе - иначе и будут приходить такие вот работнички. Из повествования ощущается, что этого даже близко не было.
"Тимлид решил переехать с Прома на Заббикс" - хотя эти системы концептуально предназначены для разного. Уровень понятен.
У меня бывали очень похожие места работы, где исторически сложилась кривая-косая инфраструктура, которую на заре создания компании развернул какой-нибудь техдир, руководитель разработки или ещё кто. Потом этот человек устаёт поддерживать наговняканное - и компания решает нанять админа (незадорого). Админ приходит, видит всё это, пытается внести рацпредложения и переделать по-нормальному, но "автор" ему не даёт - ведь это будет означать, что он наделал фигню и пошатнёт авторитет. Денег на приведение инфраструктуры в порядок не дают, задачи тухлые - вот и увольняешься через полгода.

Farakhm
16.12.2025 23:22Неправильно, когда за все отвечает один человек. Бэкапы не только для данных требуются.
Так-то С. вот злодеем оказался, а вдруг бы он в ДТП погиб?
imbasoft
RBAC, IAM и другие технологии не имеют смысла без отлаженных процессов безопасности. Это как с дверью, какой-бы замок не стоял, но если не будет человека, который поднимет тревогу в случае попытки взлома замок не спасёт.
Вообще любая ИБ начинается с одной простой вещи - с нормального резервирования данных. В большинстве организаций конфиденциальность информации значительно менее важная характеристика чем целостность. Поэтому если нет бэкапа, то остальным можно вообще не заниматься.
А так история весьма поучительна.