Как-то, у нашей компании накопился ряд задач, связанных с администрированием наших серверов, и руководство приняло решение, что всё-таки нам нужен 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 — под аудитом. Никто ничего физически не смог бы сделать незаметно.
Но негоже махать руками после драки. Да и кто это все будет настраивать - он же может и сделать обратное.
Тут выводы конечно сделать сложно, что может помочь избежать подобных ситуаций и какие дать советы. Главное, наверное, чтобы заинтересованное лицо всегда знало о подобных рисках. Быть готовым к подобным выкрутасам. Делать бэкапы всего и вся. Доверять, но проверять. Думать, что я буду делать, если человек окажется неадекват и будет держать за горло всю компанию, по сути, шантажируя ее. Будьте осторожны, учитесь на чужих ошибках и берегите себя.
Может кто-то уже сталкивался с чем то подобным и поделится своим опытом в комментариях.
Всем лучиков добра и ясной погоды!
Комментарии (28)
select26
16.12.2025 23:22И, как говорится мораль сей басни такова: Она конечно не нова – случайных людей не допускайте к власти, Иначе беды ждут, напасти,
Вывод совершенно не верный.
С вашим подходом и неслучайные люди все сломать могут.
Как выше уже отметили - системный подход, процедуры и резервные копии являются основой, а вовсе не подбор персонала.
Robastik
16.12.2025 23:22системный подход, процедуры и резервные копии
Как они заводятся независимо от персонала ?
select26
16.12.2025 23:22Я писал совершенно о другом: даже с самыми отличными людьми без системного подхода они не появятся.
В этом смысл. Вся индустрия построена на попытках создать технологии и подходы, где результат как можно меньше зависит от квалификации исполнителя. Каноничный пример: PCI DSS, или MISRA C.
d71
16.12.2025 23:22Т.е. Злодей спланировал заработать на диверсии - предпринял и настроил заранее средства злодеяний. А за это никак нельзя привлечь через суд?
sergey2212 Автор
16.12.2025 23:22Да руководство собрало, как по мне, железобетонные доказательства причастности С. к данному инцеденту. На руках были логи которые четко свидетельствовали о вышеописанных манипуляциях. Обратилось в полицию. Полиция не захотела этим заниматься и дали ответ вроде "Нет состава преступления". Дальше уже никто не стал заниматься этим.
andreynekrasov
16.12.2025 23:22Полиция не захотела этим заниматься и дали ответ вроде "Нет состава преступления".
У полиции разве есть опция "выбора"? А если через 112 заявление сделать? Таких мудаков-"девопсов" 100% нужно наказывать.
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Слышал давнюю историю, что пришел хороший админ, все настроил, все засекурил и .... пропал. Совсем. Кажется после зарплаты или там премии квартальной - то есть быстро. По месту жительства не нашли. Ну повзламывать пришлось админские пароли. А потом позвонили из дурки, удивились что работодатель не знал, что это их постоянный клиент. С белочкой - белой горячкой. Потом выяснилось что у него это был цикл: устроился на работу, получил денег, напился, попал в дурку с белочкой, уволили, повторить.
Очень давно это было. Тогда тоже не очень то внимательно с персоналом работали. А алкоголизм среди интеллектуалов - явление распространенное.
Да и ИТ саботаж не так уж и редко встречается, хоть и не в таких острых формах.
Зачем ваш С. к вам на работу то устраивался? В чем была причина конфликта? Налево работал? Судиться, конечно, не стали?
sergey2212 Автор
16.12.2025 23:22Насчет целей устройства С. на работу не знаю. Конфликтов по сути никогда не было, все было в рамках приличия. Просто поняли что с человеком сложно решать вопросы и решили попращаться. Спокойно без всяких разбирательств. В полне допускаю мысль что работал еще где то так как с доступностью были проблемы, может еще чем то занимался своим.
Насчет судиться, ответил чуть выше.
ky0
16.12.2025 23:22Вы, конечно же, обратились в полицию и инициировали расследование? А чо нет?
В целом, между строк можно прочитать пару тревожных флажочков (поправьте, если я ошибаюсь):
"Сперва купи картину, а затем рамку" - инфраструктуры, которые появляются раньше, чем нанимают людей, способных осознанно их спроектировать и развернуть, это 99% боль.
Хороший девопс-инженер, это человек, который знает не меньше, а больше среднего разработчика (условные 50% разработки + 100% админства). И получать должен соответствующе - иначе и будут приходить такие вот работнички. Из повествования ощущается, что этого даже близко не было.
"Тимлид решил переехать с Прома на Заббикс" - хотя эти системы концептуально предназначены для разного. Уровень понятен.
У меня бывали очень похожие места работы, где исторически сложилась кривая-косая инфраструктура, которую на заре создания компании развернул какой-нибудь техдир, руководитель разработки или ещё кто. Потом этот человек устаёт поддерживать наговняканное - и компания решает нанять админа (незадорого). Админ приходит, видит всё это, пытается внести рацпредложения и переделать по-нормальному, но "автор" ему не даёт - ведь это будет означать, что он наделал фигню и пошатнёт авторитет. Денег на приведение инфраструктуры в порядок не дают, задачи тухлые - вот и увольняешься через полгода.
sergey2212 Автор
16.12.2025 23:22Насчет полиции ответил выше коментатору.
А в целом, судя из вашего коментария, наверное, имеете ввиду что проблема не в человеке, а в системе. Хороший DevOps стоит дорого и вообще наверняка компания сама виновата.
Но суть ведь статьи не об этом. Заголовок статьи говорит о том что нужно знать о рисках работы в нашей сфере. И просьба здесь поставить себя на место "клиента" и подумать как нужно защищаться от подобного воздействия. Есть даже термин "Insider threat" и проблема на самом деле не нова. И в качестве исходящих представьте что контора реально классная и идеальная и ЗП хорошая но человек по сути своей разрушитель - выше есть коментарии о подобных личностяхky0
16.12.2025 23:22Чтобы выстроить систему, в которой такой разрушитель не приведёт к существенным последствиям - нужны вложения и персонал. Вложения без эффекта, который можно поместить в циферки на презентации топ-менеджменту, мелко-средний бизнес делать не любит, кадры, которые получше, отчалили за последние три года. Крупняк, у кого с этим более-менее - слился с Левиафаном и деградирует по той же траектории.
Я на собеседованиях уже давно стараюсь спрашивать потенциальных работодателей, какой даунтайм в год они считают допустимым и сколько стоит минута его превышения. Там, где такими вещами не заморачиваются - гарантированное болото.
Farakhm
16.12.2025 23:22Неправильно, когда за все отвечает один человек. Бэкапы не только для данных требуются.
Так-то С. вот злодеем оказался, а вдруг бы он в ДТП погиб?
sergey2212 Автор
16.12.2025 23:22В данной ситуации за все один человек не отвечал но у него были доступы ко всему. Его же уволили то без проблем, компания продолжала жить и продолжает.
MEGA_Nexus
16.12.2025 23:22И, как говорится мораль сей басни такова: Она конечно не нова – случайных людей не допускайте к власти, Иначе беды ждут, напасти, И пожалеете вы вскоре, Когда от них хлебнете горя!
Так оно не поможет. Проблема в том, что вы МЕЛКАЯ контора, где работает очень мало людей, поэтому у вас нет разделения обязанностей, так как каждый сотрудник вынужден совмещать у себя несколько ролей. По этой же причине у вас нет ни второго DevOps, чтобы исключить bus factor; ни политик безопасности, ни регламентов приёма\увольнения сотрудников и прочего. Вы микроконтора, поэтому вы будете наступать на эти грабли постоянно и вариантов это избежать нет.
Вот когда вы станете больше в размерах, тогда у вас появится несколько DevOps специалистов, позже появятся безопасники. Затем отдельные специалисты по бэкапам, которые будут заниматься только бэкапами. А если станете совсем большими и крутыми, то появится отдел аудита и комплаенса, который будет вам паяльники в одно место вставлять, за то, что провели работы без тикета, либо неправильно этот тикет оформили. Вот тогда наступит полный контроль и безопасность, но взамен вы получите бюрократию и корпоративные войны между отделами в дополнение к политическим интригам внутри компании. Так что всё не так однозначно.
sergey2212 Автор
16.12.2025 23:22Вот здесь 100% соглашусь! Вы абсолютно правы. Это рабочий метод. Бюрократия это уже побочный эффект - но меньшее зло.
duronus
16.12.2025 23:22Я как примерно похожий devOPS могу точно утверждать, что человек который вот такое замутил не просто так все это сделал, скарее всего его сначала задолбали, а потом когдаон пришел попросить прибавки ЗП его цинично послали со словами ты тут никто или похожее. Ну вот он и показал кто он. А то такие микро ИП очень любят говорить, что зп зависит от отвественности, а вот поднимать зп они почему то забывают, а отвественность поднимают очень быстро. P.s.: Меня обычно с зп не обижали, но знаю был одной канторе где сделал бы так же, да только лень был ибо знал, что без меня они утонут сами по себе, что в общем то и случилось через пару лет
sergey2212 Автор
16.12.2025 23:22Ну у вас и фантазия (в хорошем смысле слова). Да это частый сценарий развития событий что вы описали. У вас наверное был похожий опыт работы.
Честно вам скажу как сторонний наблюдатель - контора была в рамках приличия. Люди адекватные хорошие на редкость.
На сторону зла встать легче а вот на стороне "клиента" как бы вы поступили?
0mogol0
16.12.2025 23:22Конечно, по идее хорошо бы иметь:
и вот мне интересно, как бы это всё помогло, если у товарища всё равно все ключи есть. Ну то есть да, вы его уволили, заблокировали его учётку в один клик. Но он до этого успел создать учётки, которые не входят в эти группы.
Джамп-хост - не позволит войти и запустить задачу, но никак не помешает запуститься запланированной задаче (принцип мёртвой руки).
Ну то есть надо иметь как минимум резерв специалистов, которые после расставания смогут провести аудит безопасности, ну или как минимум сделать бэкап всех систем.
В теории могло бы помочь ленточное хранилище, но опять же при наличии злой воли - можно старые ленты затереть, или настроить так, чтобы ничего важного не копировалось.
В общем - если на какой-то позиции есть один человек, значит тут у вас SPoF. И не очень важно сознательно он решит вам навредить, или просто его машина сбила.
sergey2212 Автор
16.12.2025 23:22Ну как вариант если бы были изначально применены настройки безопасности и при регистрации нового пользователя, изменении файла cron, добавлении нового ssh ключа и подобные вещи отображались через некий телграм бот в группе где несколько человек из компании подписано. Тогда хотя бы это было сложно сделать незаметно и народ бы встрепенулся а зачем кто то делает вот это.
В первом коментарии @imbasoft специалист по ИБ, дал хороший ответ по этому вопросу.
SignFinder
16.12.2025 23:22Наверно мне первый раз захотелось поставить минус статье тут, но кармы нет.
За кликбейтный заголовок, за демонизацию термина devops и применение его к позиции и обязанностям системного администратора, о котором и идет речь этой статье. Ну и за то, что ничего не написали ни про фейлы менеджмента, ни про фейлы HR, которые также могли быть одной из причин результата, описанного здесь.
andreynekrasov
16.12.2025 23:22"В отношении бэкапов базы данных. Да конечно же они делались. Но были С. так же уничтожены."
Вот это странно. У нас например можно записать на бакап данные, но стереть оттуда ничего удаленно нельзя. А доступы вы по идее поменяли везде перед его увольнением и доступ был на какой то один продуктовый сервер (я так из статьи понял). Вряд ли у вас всё на одном серваке жило/живёт.
imbasoft
RBAC, IAM и другие технологии не имеют смысла без отлаженных процессов безопасности. Это как с дверью, какой-бы замок не стоял, но если не будет человека, который поднимет тревогу в случае попытки взлома замок не спасёт.
Вообще любая ИБ начинается с одной простой вещи - с нормального резервирования данных. В большинстве организаций конфиденциальность информации значительно менее важная характеристика чем целостность. Поэтому если нет бэкапа, то остальным можно вообще не заниматься.
А так история весьма поучительна.
Quicklys2022
Абсолютно согласен не имеет смысла. Как верно указал amnesiax - это от непонимания и следования моднявым штуковинам. не понимая саму суть. Им сначала нормального Системного администратора раз нет службы ИБ - именно его, того кто по ~~феншую~~ тфу ISO премудростям построит всю систему, который знает как резервирование сделать и всех других помирить и рассадить по клеткам. Но их осталось мало, так как всем нужны Архитекторы, Девопсы, Сетевые инженеры, и т.д. решать одну самую нужную задачу сейчас и пусть каждый ставит свой костыль - потому они вымирают как вид. Вот эта фраза уже ужас - "По счастливой случайности, у одного из сотрудников был сделан бэкап всей базы данных." Это говорит о том - что у них все плохо изначально ну совсем. И Dev-Ops не спасет, систему нужно менять ))