Привет, я Антон Майко. Это Root Profi.
Я системный инженер / DevOps. Занимаюсь Linux-инфраструктурой, мониторингом, резервным копированием, автоматизацией и сопровождением серверов.
Этот канал — про практичный подход к инфраструктуре без лишнего шума.
Буду писать о том, с чем регулярно сталкиваюсь в работе и что считаю важным для нормальной эксплуатации:
- Linux-серверы и диагностика;
- Zabbix, Grafana и мониторинг;
- backup и проверка восстановления;
- документация и порядок в инфраструктуре;
- автоматизация без overengineering;
- безопасность и аккуратное сопровождение;
- open source-инструменты, которые стоит изучить или проверить руками.
Свою работу я стараюсь строить так, чтобы инфраструктура работала надёжно и предсказуемо.
Мне ближе работа на упреждение: заранее увидеть риск, настроить мониторинг, проверить backup, задокументировать важное, убрать хаос в настройках.
Конечно, чинить тоже приходится. В эксплуатации от этого никуда не деться. Но если всё время только тушить пожары, значит где-то не хватает порядка, наблюдаемости или профилактики.
Мне близок простой подход: сначала понять, что реально происходит, потом чинить, автоматизировать и улучшать.
Без магии DevOps, без “серебряных пуль” и без обещаний настроить всё идеально одной командой.
Если коротко, канал для тех, кто хочет, чтобы серверы, мониторинг, backup и документация были не хаотичным набором настроек, а рабочей системой.
Иногда здесь будут короткие инженерные заметки. Иногда — разборы типовых ошибок. Иногда — первые выводы по новым Linux/open source-инструментам, которые я изучаю или проверяю.
Если у вас в инфраструктуре уже есть Zabbix, Grafana, backup и серверы, но при сбоях всё равно приходится разбираться с нуля — возможно, здесь будет полезно.
А если нужна помощь с аудитом, мониторингом, резервным копированием или наведением порядка в Linux-инфраструктуре — можно написать мне: @avmayko
Я системный инженер / DevOps. Занимаюсь Linux-инфраструктурой, мониторингом, резервным копированием, автоматизацией и сопровождением серверов.
Этот канал — про практичный подход к инфраструктуре без лишнего шума.
Буду писать о том, с чем регулярно сталкиваюсь в работе и что считаю важным для нормальной эксплуатации:
- Linux-серверы и диагностика;
- Zabbix, Grafana и мониторинг;
- backup и проверка восстановления;
- документация и порядок в инфраструктуре;
- автоматизация без overengineering;
- безопасность и аккуратное сопровождение;
- open source-инструменты, которые стоит изучить или проверить руками.
Свою работу я стараюсь строить так, чтобы инфраструктура работала надёжно и предсказуемо.
Мне ближе работа на упреждение: заранее увидеть риск, настроить мониторинг, проверить backup, задокументировать важное, убрать хаос в настройках.
Конечно, чинить тоже приходится. В эксплуатации от этого никуда не деться. Но если всё время только тушить пожары, значит где-то не хватает порядка, наблюдаемости или профилактики.
Мне близок простой подход: сначала понять, что реально происходит, потом чинить, автоматизировать и улучшать.
Без магии DevOps, без “серебряных пуль” и без обещаний настроить всё идеально одной командой.
Если коротко, канал для тех, кто хочет, чтобы серверы, мониторинг, backup и документация были не хаотичным набором настроек, а рабочей системой.
Иногда здесь будут короткие инженерные заметки. Иногда — разборы типовых ошибок. Иногда — первые выводы по новым Linux/open source-инструментам, которые я изучаю или проверяю.
Если у вас в инфраструктуре уже есть Zabbix, Grafana, backup и серверы, но при сбоях всё равно приходится разбираться с нуля — возможно, здесь будет полезно.
А если нужна помощь с аудитом, мониторингом, резервным копированием или наведением порядка в Linux-инфраструктуре — можно написать мне: @avmayko
👍1
Root Profi | Инфраструктура без шума pinned «Привет, я Антон Майко. Это Root Profi. Я системный инженер / DevOps. Занимаюсь Linux-инфраструктурой, мониторингом, резервным копированием, автоматизацией и сопровождением серверов. Этот канал — про практичный подход к инфраструктуре без лишнего шума. Буду…»
На практике мониторинг часто выглядит так: Zabbix установлен, Grafana открывается, алерты куда-то приходят.
Но при реальной проблеме всё равно начинается ручной разбор: что упало, где смотреть, кто должен реагировать и почему это не было видно заранее.
Для меня это признак, что мониторинг есть формально, но как рабочий инструмент он пока слабый.
Вот три вещи, с которых я бы начал проверку.
1. Алертов много, но реакции на них почти нет
Если уведомления приходят постоянно, люди быстро учатся их не замечать.
Обычно так бывает, когда в мониторинг попало всё подряд: мелкие предупреждения, старые тестовые триггеры, неактуальные пороги, события без понятного действия.
Плохой мониторинг шумит. Хороший мониторинг помогает понять:
- насколько проблема важна;
- где она находится;
- кто должен реагировать;
- что будет, если ничего не сделать.
2. Графики есть, но выводов по ним нет
Красивый дашборд сам по себе не спасает от простоя.
Если по графикам непонятно, что ухудшается, где узкое место и влияет ли это на пользователей, то это скорее витрина, чем инструмент эксплуатации.
График CPU полезен не потому, что он красивый. Он полезен, если помогает вовремя понять: серверу не хватает ресурса, процесс ведёт себя странно или нагрузка растёт по тренду.
3. Мониторится сервер, но не мониторится смысл сервиса
CPU, RAM, диск и ping — это база. Но бизнесу важно не только “сервер жив”. Важно, работает ли то, ради чего этот сервер нужен.
Например:
- открывается ли сайт;
- отвечает ли база данных;
- не заканчивается ли место под бэкапы;
- не истекает ли сертификат;
- выполняются ли важные фоновые задачи;
- есть ли признаки, что сервис начал деградировать до жалоб пользователей.
Если мониторинг не отвечает на такие вопросы, он может пропустить реальную проблему.
Мой вывод простой: мониторинг должен помогать принимать решения, а не просто собирать метрики.
Если Zabbix или Grafana уже есть, но при сбоях всё равно приходится “копать с нуля”, я бы начинал не с нового инструмента, а с короткого аудита текущей схемы: что контролируется, какие алерты настроены и где остаются слепые зоны.
Но при реальной проблеме всё равно начинается ручной разбор: что упало, где смотреть, кто должен реагировать и почему это не было видно заранее.
Для меня это признак, что мониторинг есть формально, но как рабочий инструмент он пока слабый.
Вот три вещи, с которых я бы начал проверку.
1. Алертов много, но реакции на них почти нет
Если уведомления приходят постоянно, люди быстро учатся их не замечать.
Обычно так бывает, когда в мониторинг попало всё подряд: мелкие предупреждения, старые тестовые триггеры, неактуальные пороги, события без понятного действия.
Плохой мониторинг шумит. Хороший мониторинг помогает понять:
- насколько проблема важна;
- где она находится;
- кто должен реагировать;
- что будет, если ничего не сделать.
2. Графики есть, но выводов по ним нет
Красивый дашборд сам по себе не спасает от простоя.
Если по графикам непонятно, что ухудшается, где узкое место и влияет ли это на пользователей, то это скорее витрина, чем инструмент эксплуатации.
График CPU полезен не потому, что он красивый. Он полезен, если помогает вовремя понять: серверу не хватает ресурса, процесс ведёт себя странно или нагрузка растёт по тренду.
3. Мониторится сервер, но не мониторится смысл сервиса
CPU, RAM, диск и ping — это база. Но бизнесу важно не только “сервер жив”. Важно, работает ли то, ради чего этот сервер нужен.
Например:
- открывается ли сайт;
- отвечает ли база данных;
- не заканчивается ли место под бэкапы;
- не истекает ли сертификат;
- выполняются ли важные фоновые задачи;
- есть ли признаки, что сервис начал деградировать до жалоб пользователей.
Если мониторинг не отвечает на такие вопросы, он может пропустить реальную проблему.
Мой вывод простой: мониторинг должен помогать принимать решения, а не просто собирать метрики.
Если Zabbix или Grafana уже есть, но при сбоях всё равно приходится “копать с нуля”, я бы начинал не с нового инструмента, а с короткого аудита текущей схемы: что контролируется, какие алерты настроены и где остаются слепые зоны.
Бэкап без проверки восстановления — это надежда, а не защита
В резервном копировании есть неприятный момент: сам факт наличия backup ещё не означает, что данные получится восстановить.
Файл с копией может лежать на диске. Задача в cron может выполняться без ошибок. В панели может быть зелёный статус. Но при реальной аварии выясняется, что восстановление никто давно не проверял.
Для меня рабочий backup — это не только “копия создаётся”. Это минимум несколько вещей.
1. Понятно, что именно копируется
Часто копируют только файлы сайта или только базу данных, а важные конфиги, compose-файлы, ключевые настройки сервиса, расписания задач и инструкции остаются на самом сервере.
Пока сервер жив — это незаметно. После сбоя начинается ручной сбор инфраструктуры по памяти.
2. Есть откуда восстанавливаться
Backup должен лежать не только на том сервере, где он создается.
Если копии хранятся только вместе с рабочими данными, один сбой диска, ошибка администратора или шифровальщик могут забрать и систему, и “защиту”.
3. Восстановление проверялось руками
Самая важная проверка — не “создался ли архив”, а “получилось ли из него поднять рабочие данные”.
Хотя бы периодически стоит проверять восстановление на тестовой машине или отдельном каталоге: база открывается, сервис стартует, конфиги на месте, данные не повреждены.
4. Известно, сколько времени займёт возврат к работе
Для бизнеса важно не только наличие копии, но и время восстановления.
Одно дело — вернуть один файл за 10 минут. Другое — восстанавливать сервер, базу, конфиги и зависимости полдня, параллельно отвечая на вопросы пользователей.
Мой вывод простой: backup нужно оценивать не по факту создания копии, а по способности восстановить работу.
Если резервное копирование уже настроено, но вы давно не проверяли восстановление, я бы начинал с короткого аудита: что копируется, где хранится, как проверяется и сколько реально займёт возврат к рабочему состоянию.
#backup
В резервном копировании есть неприятный момент: сам факт наличия backup ещё не означает, что данные получится восстановить.
Файл с копией может лежать на диске. Задача в cron может выполняться без ошибок. В панели может быть зелёный статус. Но при реальной аварии выясняется, что восстановление никто давно не проверял.
Для меня рабочий backup — это не только “копия создаётся”. Это минимум несколько вещей.
1. Понятно, что именно копируется
Часто копируют только файлы сайта или только базу данных, а важные конфиги, compose-файлы, ключевые настройки сервиса, расписания задач и инструкции остаются на самом сервере.
Пока сервер жив — это незаметно. После сбоя начинается ручной сбор инфраструктуры по памяти.
2. Есть откуда восстанавливаться
Backup должен лежать не только на том сервере, где он создается.
Если копии хранятся только вместе с рабочими данными, один сбой диска, ошибка администратора или шифровальщик могут забрать и систему, и “защиту”.
3. Восстановление проверялось руками
Самая важная проверка — не “создался ли архив”, а “получилось ли из него поднять рабочие данные”.
Хотя бы периодически стоит проверять восстановление на тестовой машине или отдельном каталоге: база открывается, сервис стартует, конфиги на месте, данные не повреждены.
4. Известно, сколько времени займёт возврат к работе
Для бизнеса важно не только наличие копии, но и время восстановления.
Одно дело — вернуть один файл за 10 минут. Другое — восстанавливать сервер, базу, конфиги и зависимости полдня, параллельно отвечая на вопросы пользователей.
Мой вывод простой: backup нужно оценивать не по факту создания копии, а по способности восстановить работу.
Если резервное копирование уже настроено, но вы давно не проверяли восстановление, я бы начинал с короткого аудита: что копируется, где хранится, как проверяется и сколько реально займёт возврат к рабочему состоянию.
#backup
Команды, с которых я начинаю диагностику Linux-сервера
Когда сервер "тормозит", "что-то отвалилось" или "всё работало, а теперь нет", самая опасная реакция - сразу перезапускать сервисы и менять настройки наугад.
Я обычно начинаю не с исправлений, а с короткого первичного осмотра. Задача простая: понять, где проблема - ресурсы, диск, сеть, сервис, логи или недавние изменения.
Вот базовый набор команд, который часто помогает быстро собрать картину.
1. Что с нагрузкой и процессами
Смотрю load average, CPU, память и процессы, которые реально забирают ресурсы. Важно не просто увидеть “нагрузка высокая”, а понять: это один процесс, много процессов, ожидание диска или нормальный пик.
2. Что с памятью и swap
Если память закончилась и сервер активно ушёл в swap, симптомы могут выглядеть как “всё медленно”, хотя причина не в приложении, а в нехватке RAM или утечке памяти.
3. Что с дисками
Проверяю не только свободное место, но и inode. Иногда место ещё есть, а новые файлы не создаются, потому что закончились inode. Для серверов с большим количеством мелких файлов это вполне реальный сценарий.
4. Что пишет systemd и конкретный сервис
Если сервис упал, сначала смотрю его состояние и последние записи в журнале. Ошибка в логах часто быстрее любых догадок: не хватает прав, не открылся порт, сломался конфиг, нет доступа к базе, закончился диск.
5. Что происходило в системе недавно
Здесь ищу общие предупреждения, ошибки ядра/systemd, перезагрузки, входы пользователей. Иногда причина не в “мистике”, а в обновлении, ручном изменении или перезапуске, о котором забыли.
6. Слушает ли сервис нужный порт
Если сайт или API не открывается, нужно понять: сервис вообще слушает порт, слушает только
7. Есть ли базовая сеть
Так можно быстро разделить проблемы: нет сети вообще, нет маршрута, не работает DNS или проблема уже выше - в приложении, firewall, proxy или внешнем сервисе.
Мой вывод простой: хорошая диагностика начинается не с “перезапустить и посмотреть”, а с фиксации фактов.
Для меня минимальный порядок такой:
Это не заменяет полноценный разбор, но помогает не тратить время вслепую и не маскировать проблему случайным рестартом.
Если сервер регулярно требует “ручного шаманства”, я бы начинал с короткого аудита: что именно ломается, какие есть логи, что мониторится, какие сервисы критичны и есть ли понятный план действий при сбое.
#linux
Когда сервер "тормозит", "что-то отвалилось" или "всё работало, а теперь нет", самая опасная реакция - сразу перезапускать сервисы и менять настройки наугад.
Я обычно начинаю не с исправлений, а с короткого первичного осмотра. Задача простая: понять, где проблема - ресурсы, диск, сеть, сервис, логи или недавние изменения.
Вот базовый набор команд, который часто помогает быстро собрать картину.
1. Что с нагрузкой и процессами
uptime
top
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head
Смотрю load average, CPU, память и процессы, которые реально забирают ресурсы. Важно не просто увидеть “нагрузка высокая”, а понять: это один процесс, много процессов, ожидание диска или нормальный пик.
2. Что с памятью и swap
free -h
swapon --show
Если память закончилась и сервер активно ушёл в swap, симптомы могут выглядеть как “всё медленно”, хотя причина не в приложении, а в нехватке RAM или утечке памяти.
3. Что с дисками
df -h
df -i
lsblk
Проверяю не только свободное место, но и inode. Иногда место ещё есть, а новые файлы не создаются, потому что закончились inode. Для серверов с большим количеством мелких файлов это вполне реальный сценарий.
4. Что пишет systemd и конкретный сервис
systemctl --failed
systemctl status <service>
journalctl -u <service> -n 100 --no-pager
Если сервис упал, сначала смотрю его состояние и последние записи в журнале. Ошибка в логах часто быстрее любых догадок: не хватает прав, не открылся порт, сломался конфиг, нет доступа к базе, закончился диск.
5. Что происходило в системе недавно
journalctl -p warning..alert -n 100 --no-pager
last -a | head
Здесь ищу общие предупреждения, ошибки ядра/systemd, перезагрузки, входы пользователей. Иногда причина не в “мистике”, а в обновлении, ручном изменении или перезапуске, о котором забыли.
6. Слушает ли сервис нужный порт
ss -tulpn
Если сайт или API не открывается, нужно понять: сервис вообще слушает порт, слушает только
127.0.0.1, не занял ли порт другой процесс, не поменялся ли bind address.7. Есть ли базовая сеть
ip addr
ip route
ping -c 3 8.8.8.8
ping -c 3 example.org
Так можно быстро разделить проблемы: нет сети вообще, нет маршрута, не работает DNS или проблема уже выше - в приложении, firewall, proxy или внешнем сервисе.
Мой вывод простой: хорошая диагностика начинается не с “перезапустить и посмотреть”, а с фиксации фактов.
Для меня минимальный порядок такой:
нагрузка -> память -> диск -> сервис -> логи -> порты -> сеть -> недавние изменения
Это не заменяет полноценный разбор, но помогает не тратить время вслепую и не маскировать проблему случайным рестартом.
Если сервер регулярно требует “ручного шаманства”, я бы начинал с короткого аудита: что именно ломается, какие есть логи, что мониторится, какие сервисы критичны и есть ли понятный план действий при сбое.
#linux
Channel name was changed to «Root Profi | Инфраструктура без шума»
Какие данные нельзя отправлять в нейросеть
AI хорошо помогает инженеру: можно попросить объяснить ошибку, накидать черновик документации, проверить идею скрипта или разобрать лог.
Но есть простое правило: если данные нельзя спокойно показать постороннему человеку, их нельзя просто так отправлять во внешний AI-сервис.
Я бы точно не отправлял в нейросеть в исходном виде:
1. Пароли, токены и ключи
API-токены, SSH-ключи, cookies,
2. Реальные IP, домены и внутренние имена
Иногда один лог раскрывает больше, чем кажется: адреса серверов, имена хостов, структуру сети, названия клиентов, внутренние сервисы.
Лучше заменить их на безопасные примеры:
3. Персональные и клиентские данные
ФИО, телефоны, email, номера договоров, заявки, переписка, дампы таблиц с пользователями - это не материал для внешнего AI без отдельной подготовки и понимания ответственности.
4. Полные конфиги без чистки
В конфиге может быть не только настройка, но и секрет, внутренний адрес, путь, имя проекта, комментарий с лишней информацией. Перед отправкой конфиг надо читать глазами.
5. Логи целиком
Логи полезны для анализа, но в них часто попадают токены, cookie, URL с параметрами, user id, внутренние пути и куски запросов.
Безопаснее отправлять не весь лог, а вырезанный фрагмент с заменёнными чувствительными данными.
Для себя я формулирую так: AI можно использовать как младшего помощника, но не как закрытый сейф.
Нормальный подход:
- сначала понять, что именно нужно спросить;
- убрать секреты и персональные данные;
- заменить реальные адреса и имена на примеры;
- оставить только тот фрагмент, который нужен для задачи;
- результат всё равно проверить самому.
AI ускоряет работу, но ответственность за данные остаётся на человеке.
#AI
AI хорошо помогает инженеру: можно попросить объяснить ошибку, накидать черновик документации, проверить идею скрипта или разобрать лог.
Но есть простое правило: если данные нельзя спокойно показать постороннему человеку, их нельзя просто так отправлять во внешний AI-сервис.
Я бы точно не отправлял в нейросеть в исходном виде:
1. Пароли, токены и ключи
API-токены, SSH-ключи, cookies,
.env, пароли от баз, доступы к панелям, backup-ключи - всё это сначала надо убрать. Даже если кажется, что “это только для анализа”.2. Реальные IP, домены и внутренние имена
Иногда один лог раскрывает больше, чем кажется: адреса серверов, имена хостов, структуру сети, названия клиентов, внутренние сервисы.
Лучше заменить их на безопасные примеры:
192.0.2.10
example.org
server-1
client-app
3. Персональные и клиентские данные
ФИО, телефоны, email, номера договоров, заявки, переписка, дампы таблиц с пользователями - это не материал для внешнего AI без отдельной подготовки и понимания ответственности.
4. Полные конфиги без чистки
В конфиге может быть не только настройка, но и секрет, внутренний адрес, путь, имя проекта, комментарий с лишней информацией. Перед отправкой конфиг надо читать глазами.
5. Логи целиком
Логи полезны для анализа, но в них часто попадают токены, cookie, URL с параметрами, user id, внутренние пути и куски запросов.
Безопаснее отправлять не весь лог, а вырезанный фрагмент с заменёнными чувствительными данными.
Для себя я формулирую так: AI можно использовать как младшего помощника, но не как закрытый сейф.
Нормальный подход:
- сначала понять, что именно нужно спросить;
- убрать секреты и персональные данные;
- заменить реальные адреса и имена на примеры;
- оставить только тот фрагмент, который нужен для задачи;
- результат всё равно проверить самому.
AI ускоряет работу, но ответственность за данные остаётся на человеке.
#AI
Что стоит бэкапить кроме файлов
Когда говорят про резервное копирование, часто думают только о пользовательских файлах: документы, картинки, выгрузки, база данных, каталог сайта.
Это важная часть backup, но не вся картина.
На практике после сбоя часто выясняется, что сами данные есть, а быстро восстановить сервис всё равно сложно. Потому что рядом с данными потерялись настройки, инструкции, расписания задач или понимание, как всё было собрано.
Вот что я бы проверял отдельно.
1. Конфиги сервисов
Для Linux-сервера это часто важнее, чем кажется:
Не обязательно слепо архивировать весь
2. Compose-файлы, unit-файлы и скрипты запуска
Если сервис поднимается через Docker Compose, systemd unit, bash-скрипт или Ansible, нужно сохранять не только данные контейнера, но и способ запуска.
Иначе после аварии начинается восстановление по памяти:
3. Базы данных и порядок их восстановления
Файл базы или дамп - это хорошо. Но важно понимать:
- чем сделан dump;
- какая версия СУБД нужна;
- есть ли отдельные пользователи и права;
- нужно ли останавливать приложение перед восстановлением;
- проверялось ли чтение дампа.
Backup базы без понятного restore-порядка часто превращается в набор файлов, которые страшно трогать в момент аварии.
4. Расписания задач
Cron, systemd timers, backup-задачи, очистка временных файлов, обновление сертификатов, служебные проверки - всё это тоже часть работающей системы.
Минимум стоит знать:
Если расписания не сохранить, после восстановления сервис может запуститься, но важные фоновые процессы не вернутся.
5. Секреты и доступы - отдельно и аккуратно
Пароли, токены, ключи и
Тут нужен отдельный подход:
- понимать, какие секреты реально нужны для восстановления;
- хранить их отдельно от публичного Git;
- шифровать backup, если внутри есть чувствительные данные;
- знать, кто имеет доступ к расшифровке;
- проверять, что секреты не утекли в репозиторий или логи.
Секреты нужны для восстановления, но именно с ними чаще всего появляются риски.
6. Документация по восстановлению
Самый недооценённый элемент backup - короткая инструкция.
Не огромный регламент на 40 страниц, а понятный минимум:
Если восстановление держится только в голове одного человека, это тоже риск.
Мой вывод простой: backup должен отвечать не только на вопрос “где лежат файлы?”, а на вопрос “сможем ли мы вернуть сервис в работу?”.
Для этого вместе с данными нужны конфиги, сценарий запуска, дампы баз, расписания, аккуратная работа с секретами и хотя бы короткая инструкция по восстановлению.
Если резервное копирование уже настроено, полезно один раз пройтись по составу backup и проверить: что будет потеряно, если сервер исчезнет целиком, а восстанавливаться придётся на новой машине.
#backup
Когда говорят про резервное копирование, часто думают только о пользовательских файлах: документы, картинки, выгрузки, база данных, каталог сайта.
Это важная часть backup, но не вся картина.
На практике после сбоя часто выясняется, что сами данные есть, а быстро восстановить сервис всё равно сложно. Потому что рядом с данными потерялись настройки, инструкции, расписания задач или понимание, как всё было собрано.
Вот что я бы проверял отдельно.
1. Конфиги сервисов
Для Linux-сервера это часто важнее, чем кажется:
/etc/nginx/
/etc/angie/
/etc/systemd/system/
/etc/postgresql/
/etc/mysql/
/etc/ssh/
Не обязательно слепо архивировать весь
/etc, но критичные конфиги должны быть либо в backup, либо в Git, либо в понятной системе управления конфигурациями.2. Compose-файлы, unit-файлы и скрипты запуска
Если сервис поднимается через Docker Compose, systemd unit, bash-скрипт или Ansible, нужно сохранять не только данные контейнера, но и способ запуска.
Иначе после аварии начинается восстановление по памяти:
какой был docker-compose.yml
какие переменные окружения нужны
какие volume подключались
какой порт был наружу
какой сервис должен стартовать первым
3. Базы данных и порядок их восстановления
Файл базы или дамп - это хорошо. Но важно понимать:
- чем сделан dump;
- какая версия СУБД нужна;
- есть ли отдельные пользователи и права;
- нужно ли останавливать приложение перед восстановлением;
- проверялось ли чтение дампа.
Backup базы без понятного restore-порядка часто превращается в набор файлов, которые страшно трогать в момент аварии.
4. Расписания задач
Cron, systemd timers, backup-задачи, очистка временных файлов, обновление сертификатов, служебные проверки - всё это тоже часть работающей системы.
Минимум стоит знать:
crontab -l
systemctl list-timers
Если расписания не сохранить, после восстановления сервис может запуститься, но важные фоновые процессы не вернутся.
5. Секреты и доступы - отдельно и аккуратно
Пароли, токены, ключи и
.env-файлы нельзя просто складывать в обычный backup бездумно.Тут нужен отдельный подход:
- понимать, какие секреты реально нужны для восстановления;
- хранить их отдельно от публичного Git;
- шифровать backup, если внутри есть чувствительные данные;
- знать, кто имеет доступ к расшифровке;
- проверять, что секреты не утекли в репозиторий или логи.
Секреты нужны для восстановления, но именно с ними чаще всего появляются риски.
6. Документация по восстановлению
Самый недооценённый элемент backup - короткая инструкция.
Не огромный регламент на 40 страниц, а понятный минимум:
где лежит backup
как проверить целостность
как восстановить данные
какие сервисы остановить
какие команды выполнить
как понять, что всё поднялось
Если восстановление держится только в голове одного человека, это тоже риск.
Мой вывод простой: backup должен отвечать не только на вопрос “где лежат файлы?”, а на вопрос “сможем ли мы вернуть сервис в работу?”.
Для этого вместе с данными нужны конфиги, сценарий запуска, дампы баз, расписания, аккуратная работа с секретами и хотя бы короткая инструкция по восстановлению.
Если резервное копирование уже настроено, полезно один раз пройтись по составу backup и проверить: что будет потеряно, если сервер исчезнет целиком, а восстанавливаться придётся на новой машине.
#backup
Иногда кластер виртуализации выглядит хуже, чем он реально сломан.
Разбирал кейс по zVirt/oVirt HCI: после переезда оборудования в панели управления часть хостов ушла в
Но факты показали другое:
- Hosted Engine был жив;
- Gluster peers были
- bricks были online;
- heal pending и split-brain были по нулям;
- management и storage-сети отвечали.
А вот локальный self-FQDN хоста резолвился не в management IPv4, а в
Главный вывод:
В HCI-кластере перед резкими действиями я бы сначала проверял:
1. Где сейчас Hosted Engine.
2. Жив ли Gluster на самом деле.
3. Что показывает self-FQDN каждого хоста.
4. Не смешались ли management и storage-имена.
5. Не пропали ли локальные FQDN-записи после обновления платформы.
6. Не пытаемся ли мы лечить storage, когда проблема в identity/DNS/NSS.
Что точно не стоит делать первым: ребутать HCI-ноду, нажимать force-действия в UI или запускать Gluster heal full без доказательств.
Более подробный разбор с логикой диагностики и ограничениями можно прочитать на сайте:
https://rootprofi.ru/blog/zvirt-hci-dns-identity-incident/
#виртуализация
Разбирал кейс по zVirt/oVirt HCI: после переезда оборудования в панели управления часть хостов ушла в
NonResponsive / Connecting. Первая страшная мысль - storage, quorum, Gluster, сейчас всё посыпется.Но факты показали другое:
- Hosted Engine был жив;
- Gluster peers были
Connected;- bricks были online;
- heal pending и split-brain были по нулям;
- management и storage-сети отвечали.
А вот локальный self-FQDN хоста резолвился не в management IPv4, а в
fe80::... link-local IPv6. В связке с потерянными записями /etc/hosts и myhostname в NSS это било по host identity и management-plane. Вероятная причина потери записей - обновление zVirt на новый релиз, после которого локальный список имён на нодах стоит перепроверять отдельно.Главный вывод:
NonResponsive в UI - это симптом, а не диагноз.В HCI-кластере перед резкими действиями я бы сначала проверял:
1. Где сейчас Hosted Engine.
2. Жив ли Gluster на самом деле.
3. Что показывает self-FQDN каждого хоста.
4. Не смешались ли management и storage-имена.
5. Не пропали ли локальные FQDN-записи после обновления платформы.
6. Не пытаемся ли мы лечить storage, когда проблема в identity/DNS/NSS.
Что точно не стоит делать первым: ребутать HCI-ноду, нажимать force-действия в UI или запускать Gluster heal full без доказательств.
Более подробный разбор с логикой диагностики и ограничениями можно прочитать на сайте:
https://rootprofi.ru/blog/zvirt-hci-dns-identity-incident/
#виртуализация
Почему инфраструктура не должна жить только в голове админа
Есть опасная, но очень привычная ситуация: серверы работают, сервисы открываются, backup вроде настроен, а большая часть знаний держится в голове одного человека.
Пока этот человек рядом, всё выглядит нормально. Но стоит ему уйти в отпуск, заболеть, сменить работу или просто быть недоступным в момент аварии, инфраструктура резко становится чёрным ящиком.
Минимум, который я бы фиксировал:
1. Что где запущено
- какие серверы есть;
- какие сервисы на них работают;
- какие порты и домены используются;
- где production, где тестовый контур;
- что зависит от чего.
2. Как сервис стартует
Docker Compose, systemd unit, Ansible, cron, ручной скрипт - способ запуска должен быть записан и лежать не только на сервере.
3. Где backup и как из него восстановиться
Важно знать не только “backup есть”, но и где он лежит, что туда попадает, как проверить свежесть и как восстановить на новой машине.
4. Доступы и секреты
Пароли и ключи нельзя бросать в обычный документ. Но должен быть понятный процесс: где они хранятся, кто имеет доступ, как действовать в аварийной ситуации.
5. Runbook на частые аварии
Сайт не открывается, закончилось место, база не стартует, сертификат не обновился, backup не прошёл. Для таких случаев нужны короткие инструкции, а не воспоминания в переписке.
Хорошая документация не заменяет инженера. Она снижает зависимость от памяти и делает инфраструктуру сопровождаемой.
Мой практический критерий простой: если завтра сервер надо восстановить или передать другому инженеру, хватит ли текущих записей, чтобы не гадать по истории команд?
#документация
Есть опасная, но очень привычная ситуация: серверы работают, сервисы открываются, backup вроде настроен, а большая часть знаний держится в голове одного человека.
Пока этот человек рядом, всё выглядит нормально. Но стоит ему уйти в отпуск, заболеть, сменить работу или просто быть недоступным в момент аварии, инфраструктура резко становится чёрным ящиком.
Минимум, который я бы фиксировал:
1. Что где запущено
- какие серверы есть;
- какие сервисы на них работают;
- какие порты и домены используются;
- где production, где тестовый контур;
- что зависит от чего.
2. Как сервис стартует
Docker Compose, systemd unit, Ansible, cron, ручной скрипт - способ запуска должен быть записан и лежать не только на сервере.
3. Где backup и как из него восстановиться
Важно знать не только “backup есть”, но и где он лежит, что туда попадает, как проверить свежесть и как восстановить на новой машине.
4. Доступы и секреты
Пароли и ключи нельзя бросать в обычный документ. Но должен быть понятный процесс: где они хранятся, кто имеет доступ, как действовать в аварийной ситуации.
5. Runbook на частые аварии
Сайт не открывается, закончилось место, база не стартует, сертификат не обновился, backup не прошёл. Для таких случаев нужны короткие инструкции, а не воспоминания в переписке.
Хорошая документация не заменяет инженера. Она снижает зависимость от памяти и делает инфраструктуру сопровождаемой.
Мой практический критерий простой: если завтра сервер надо восстановить или передать другому инженеру, хватит ли текущих записей, чтобы не гадать по истории команд?
#документация
Uptime Kuma: простая внешняя проверка сервисов
Есть базовый вопрос, который полезно отделять от полноценного мониторинга: видит ли внешний пользователь, что сервис жив?
Для этого не всегда нужно сразу строить большую систему с метриками, агентами и сложными дашбордами. Иногда первым шагом достаточно простой внешней проверки.
Uptime Kuma как раз из таких open source-инструментов: self-hosted панель, которая умеет периодически проверять доступность сервисов и уведомлять, если что-то перестало отвечать.
Что можно проверять таким подходом:
- открывается ли сайт по HTTP/HTTPS;
- отвечает ли нужный TCP-порт;
- жив ли endpoint приложения;
- не истёк ли сертификат;
- не выглядит ли сервис недоступным извне.
Где это полезно:
- небольшой сайт или личный сервис;
- внешний контроль production из отдельной точки;
- простая проверка “клиенты видят сервис или нет”;
- первый слой мониторинга до внедрения более тяжёлой системы.
Но важно не путать availability check с полноценным мониторингом.
Внешняя проверка может сказать: “сервис не отвечает”. Но она не всегда объяснит, почему: база, диск, очередь, сеть, задержка или ошибка приложения.
Поэтому я бы смотрел на Uptime Kuma как на простой внешний сигнал, а не как на замену Zabbix, Prometheus или нормальной диагностики внутри сервера.
Практичный вывод: если у сервиса сейчас вообще нет внешней проверки, лучше начать с простого “оно доступно снаружи?” и понятных уведомлений. А дальше уже решать, где нужны метрики, логи и глубокий мониторинг.
#uptimekuma
Есть базовый вопрос, который полезно отделять от полноценного мониторинга: видит ли внешний пользователь, что сервис жив?
Для этого не всегда нужно сразу строить большую систему с метриками, агентами и сложными дашбордами. Иногда первым шагом достаточно простой внешней проверки.
Uptime Kuma как раз из таких open source-инструментов: self-hosted панель, которая умеет периодически проверять доступность сервисов и уведомлять, если что-то перестало отвечать.
Что можно проверять таким подходом:
- открывается ли сайт по HTTP/HTTPS;
- отвечает ли нужный TCP-порт;
- жив ли endpoint приложения;
- не истёк ли сертификат;
- не выглядит ли сервис недоступным извне.
Где это полезно:
- небольшой сайт или личный сервис;
- внешний контроль production из отдельной точки;
- простая проверка “клиенты видят сервис или нет”;
- первый слой мониторинга до внедрения более тяжёлой системы.
Но важно не путать availability check с полноценным мониторингом.
Внешняя проверка может сказать: “сервис не отвечает”. Но она не всегда объяснит, почему: база, диск, очередь, сеть, задержка или ошибка приложения.
Поэтому я бы смотрел на Uptime Kuma как на простой внешний сигнал, а не как на замену Zabbix, Prometheus или нормальной диагностики внутри сервера.
Практичный вывод: если у сервиса сейчас вообще нет внешней проверки, лучше начать с простого “оно доступно снаружи?” и понятных уведомлений. А дальше уже решать, где нужны метрики, логи и глубокий мониторинг.
#uptimekuma