Завершился мой эксперимент с испытаниями программы “Совершенство” (о программе на моем сайте в профиле), о чем я расскажу в будущих статьях и сейчас я активно начал вливаться обратно в рабочий процесс (кстати, ищу работу: интересный проект и команду для буста, о моих ролях в бизнесе также на моем сайте, а резюме в профиле на HH), но теперь я решил изменить рабочий подход, и стараться регулярно рассказывать о самых интересных кейсах своей рабочей практики (в пределах рабочего дня или нескольких) 🙂

Активно совмещая множество под-ролей в рамках ProductOwner-а я поддерживаю хорошие рабочие отношения с прошлыми работодателями и часто беру подработки в свободное от основной работы время.

Исполняя сегодня роли DevOps-ера и разработчика, а именно — докеризуя набор кастомных проектов (ERP/CRM/CMS/интеграционные решения) одного из любимых клиентов и подготавливая сервера к новым релизам ПО (вследствие контейнеризации и внедрении новых фич) — столкнулся со следующим кейсом.

На первый взгляд ничего необычного: несколько серверов с Ubuntu Jammy (22.04) на которых годами без сбоев работает кастомное ПО и руками ничего не обновляется (нет надобности в обновлении пакетов). Быстро прохожу локальное тестирование новых проектов поэтапной контейнеризации и начинаю готовить сервера к новым релизам (установку и настройку ПО).

Тут получаю дефолтную ошибку при попытке обновления apt: `Could not get lock /var/lib/apt/lists/lock. It is held by process XXX`. Изучаю: процесс не новый, “висит” давно.

Можно было решить проблему по старинке, не проводя детальных “разборов”, но в этот раз я решил поступить иначе 🙂

Оказалось, с последнего даунтайма (аж с 2025 года) на серверах висели “зависшие” процессы apt-get -qq -y update которые инициировались инструментом  unattended-upgrades (автообновление критически важных (в основном уязвимостей в области ИБ) частей ОС).

Systemd-таймер (apt-daily.timer) каждый день пытался запустить обновление пакетов от unattended-upgrades, но из-за этих “спящих” процессов (и соответствующей блокировки .../apt/lists/lock) ему приходилось “по-тихому” уходить день за днем... (логи конечно же были в соответствующем `.../unattended-upgrades/unattended-upgrades.log` но не были добавлены в список “метрик для проверки”, отчего на них никто не обращал внимания весь год обслуживания).

Так продолжалось целый год... 🙂 С одной стороны ничего критичного: сервера и ПО работают стабильно, клиенты довольны и пользуются своим софтом, но на это можно посмотреть и иначе: целый год системные пакеты не получают критически важных обновлений в области безопасности (ибо политика unattended-upgrades по дефолту для этих версий Ubuntu подразумевает только обновления из security-веток) только потому, что логи unattended-upgrades не считаются какой-то “важной” метрикой.

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

Какой вывод я сделал для себя?

Если в проекте нет активного разделения зон ответственности на: - работу кастомного софта (разработчики/DevOps); - работу инфраструктуры самих серверов (ОС/зависимые пакеты/etc) (сис. админы/DevOps);, то не стоит пренебрегать добавлением в мониторинг системных утилит. Конечно не стоит следить и за всем подряд, но расширять кругозор и выходить за пределы прямой зоны ответственности (web-проект = web-связка ПО, за остальным пусть следит компания обслуживающая сервер) иногда оказывается очень полезным 🙂

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

А я сам лишний раз убедился в том, что не хочу работать по принципу жесткого разделения ответственности, а-ля: “вот за ЭТО я отвечаю, а вот дальше пускай работает как хочет”.

А что интересного сегодня у Вас?  Делитесь в комментариях! ➕