Записки системного администратора. Сервер и сеть, база данных, виртуализация, резервные копии, мониторинг и аварии — что ломается на самом деле и как это чинят ночью. Реальные случаи с числами и командами, разбор ошибок и грабель. Полезно админам, эникеям и всем, кто держит ИТ-хозяйство компании.
СводкаГлавные показатели канала за выбранный период. Изменение — к такому же отрезку перед периодом, если за него есть статистика. Наведите на диаграмму плитки, чтобы увидеть число в каждой точке периода.
Главные числа
ПодписчикиСколько подписчиков у канала сейчас. Волна — число подписчиков в каждой точке периода. Изменение — к началу периода.50,0 %+0 за период
ПросмотрыСколько сейчас просмотров у постов, вышедших за период. Это не просмотры за день: сколько посмотрели вчера, MAX не сообщает.25▲ 8,7 %было 23
РеакцииСколько реакций у постов, вышедших за период.0было 0
УпоминанияСколько раз канал упомянули другие каналы: ссылки и репосты, без рекламных постов. Чем крупнее круг, тем больше упоминаний в этой точке периода.61▼ 19,7 %было 76по подписке
РепостыСколько раз другие каналы сделали репост постов этого канала (без рекламных постов). Репосты входят и в число упоминаний.28▲ 12,0 %было 25после входа
Средний охват постаСколько просмотров в среднем набирает один пост. Считаем по постам старше двух суток: у свежих просмотры ещё растут. Точки, где есть свежие посты, — пунктиром и полыми кружками: охват всех постов на сейчас, он ещё вырастет.4▼ 45,2 %было 8
ERRКакая доля подписчиков видит средний пост: средний охват ÷ подписчики × 100 %. Линия — ERR в каждой точке периода, пунктир — ERR прошлого такого же периода. Точки с постами моложе двух суток — полые кружки на пунктирном конце линии.84,0 %▼ 69,3 п. п.пунктир — было 153,3 %
Вовлечённость ERКак часто читатели реагируют на посты: реакции ÷ просмотры × 100 %. Засечка на полосе — прошлый период.—реакций на 100 просмотров
Постов в деньСколько публикаций в среднем выходит за день. Клетка — точка периода: чем темнее, тем больше постов в день.1,0▲ 133,4 %было 0,4
Доля рекламыКакая доля публикаций за период похожа на рекламу: маркировка erid, рекламные ссылки и другие признаки. Шкала — рекламная нагрузка по порогам индекса качества: до 10 % — низкая, до 25 % — умеренная, до 50 % — высокая, дальше — очень высокая. Рост доли отмечается красным.5,7 %▲ 3,5 п. п.
ДинамикаСверху — число подписчиков на конец каждой точки периода, снизу — прирост за точку: зелёный — подписчиков стало больше, красный — меньше. Над графиком прироста — самый большой прирост и самая большая убыль. Сколько подписалось и отписалось по отдельности, MAX не сообщает.
Рост аудитории
0подписчиков за период
Число подписчиков за период не менялось
Оценка каналаОценка канала от 0 до 100 из пяти частей: аудитория, честность роста, рекламная нагрузка, доверие и достоверность расчёта. Полоса — сколько баллов часть набрала из своего максимума. Индекс пересчитывается каждую ночь; каналы сравниваются с похожими — той же категории и размера.
Индекс качества пока не рассчитан. Он появляется у каналов от 500 подписчиков, которые публикуют посты хотя бы раз в неделю, после недели наблюдения.
ОхватыСколько сейчас просмотров у постов, вышедших в каждой точке периода (а не просмотры за день). Подписан рекорд; точка с сегодняшним днём бледнее — день ещё идёт. Средний охват поста — по постам старше двух суток.
Просмотры и охват
25просмотров за период▲ 8,7 %
Средний охват поста — 4 просмотров (посты старше двух суток).
ВовлечённостьER — реакции, делённые на просмотры, в процентах — у постов каждой точки периода. Пунктир — ER за весь период. Изменение — в процентных пунктах к прошлому такому же периоду.
Вовлечённость подписчиков
—ER = реакции ÷ просмотры
За период у постов нет прочитанных реакций.
ЦитируемостьИндекс цитируемости (ИЦ) — насколько часто и какими каналами упоминают этот канал за последние 30 дней, без рекламных постов. Уровень — место среди похожих каналов. Линия — ИЦ в каждой точке периода (в неделе и месяце — средний за её дни).
Индекс цитируемости пока не рассчитан: он появится после ночного расчёта, когда канал упомянут другие каналы.
РитмСколько постов в среднем выходит в каждый час каждого дня недели, время московское: чем темнее клетка, тем больше публикаций. «Лучшее время» — часы, в которые у постов старше двух суток самый высокий средний охват.
Когда и сколько публикует
ПнВтСрЧтПтСбВс
036912151821
Лучшее время:09:0018:00часы, в которые у постов самый высокий средний охват
ФорматыИз чего состоит лента. У каждого поста один формат — по старшинству: репост, видео, фото, ссылка, текст. Полоса и проценты — доля постов формата; справа — средний охват одного поста формата (по постам старше двух суток), полоска — сравнение с самым просматриваемым форматом.
ПубликацииКаждая точка — пост за период: по горизонтали — дата выхода, по вертикали — просмотры, размер точки — реакции, цвет — формат. Так видно хиты, провалы и то, как меняется охват. У крупных каналов показаны 100 самых просматриваемых постов и равномерная выборка остальных — не больше 1 500 точек.
Каждый пост — точка
Выше — больше просмотров, крупнее — больше реакций. Нажмите на точку, чтобы открыть пост.
ВидеоФотоДругоеразмер — реакцииПриближение — кнопками «+» и «−», щипком или Ctrl + колесо мыши; приближенный график сдвигается перетаскиванием
СводкаИтоги выбранного периода: сколько вышло публикаций, сколько у них сейчас просмотров и реакций и средний охват поста. Просмотры — текущие у постов, вышедших в эти дни, а не просмотры за день. Изменение — к такому же отрезку перед периодом, если за него есть статистика.
Итоги периода
Нажмите на показатель — ниже он появится по точкам периода
Просмотрысегодня — день ещё идётТочки с постами моложе двух суток — бледные с пунктиром: их просмотры ещё растут.
РекламаКакая доля публикаций за период похожа на рекламу: маркировка erid, рекламные ссылки и другие признаки. Детектор осторожный, поэтому настоящая доля обычно выше. Шкала — рекламная нагрузка по порогам индекса качества. Ниже — средний охват рекламного и обычного поста и кого рекламирует канал (сайты, на которые ведут ссылки из рекламы).
Что работаетПосты периода с наибольшим числом просмотров. Полоса — просмотры относительно первого места. Превью — картинка поста, у поста без картинки — аватар канала. Просмотры — сколько у поста сейчас.
РитмСколько постов вышло в каждый день периода (бледные столбики) и среднее за 7 дней (линия): видно, разгоняется канал или затихает. Сегодняшний день ещё идёт, поэтому среднее для него считается по вчерашний день.
Публикации по дням
Бледные столбики — дни, линия — среднее за 7 дней: видно, разгоняется канал или затихает
Публикации за деньСреднее за 7 дней
Данные обновлены в 23:57 по Москве. Просмотры — текущие у постов, вышедших в эти дни; средний охват — по постам старше двух суток.
Как считается индекс качества
Скрипт руками отрабатывает идеально, из cron — тишина. Причина почти всегда одна: окружение.
Cron запускает задание с минимальным набором переменных. Нет вашего PATH, нет переменных из профиля, нет виртуального окружения Python, домашний каталог может быть другим. Скрипт, который зовёт mysqldump без полного пути, из cron просто не находит его.
Что делать. Указывать полные пути ко всем командам. Явно задавать переменные внутри скрипта, а не надеяться на профиль. Или в первой строке задания указать окружение через env.
Второе по частоте — вывод. Cron отправляет его почтой, а почта не настроена, поэтому ошибки исчезают бесследно. Всегда добавляйте перенаправление: >> /var/log/имя.log 2>&1. Тогда причина сохранится.
Третье — проценты. В строке задания знак процента имеет специальное значение и обрезает команду. В date +%Y его нужно экранировать обратным слэшем.
Проверить, что cron вообще пытался запустить задание, можно в системном журнале: journalctl -u cron или grep CRON /var/log/syslog.
И совет: для чего-то важнее уборки мусора лучше systemd-таймер — у него есть логи, статус и зависимости.
Классика: systemctl start падает с невнятным «job failed», и дальше начинается гадание.
Порядок, который экономит время.
Первое: systemctl status имя -l --no-pager. Смотрим не на красную строчку, а на последние строки вывода — там обычно настоящая причина.
Второе: journalctl -u имя -n 100 --no-pager. Тут полный лог запуска. Если сервис перезапускается по кругу, добавьте -f и смотрите вживую.
Третье, если в логе пусто: запустите то, что написано в ExecStart, руками от того же пользователя. Половина проблем — права на файл, отсутствующий каталог или переменная окружения, которой в systemd нет, а в вашей сессии есть.
Что чаще всего оказывается причиной. Относительные пути: systemd стартует из корня, а не из каталога программы. Отсутствие WorkingDirectory. Пользователь без прав на лог-файл. Зависимость от сети — сервис поднялся раньше, чем появился адрес, лечится After=network-online.target вместе с Wants.
И полезная мелочь: systemd-analyze verify /etc/systemd/system/имя.service проверяет юнит на ошибки, не запуская его.
Какая была самая нелепая причина, из-за которой у вас не стартовал сервис?
Диск занят на 60 процентов, а система пишет «No space left on device». Первая мысль — сошла с ума. На самом деле кончились не байты, а inode.
Каждый файл, каким бы маленьким он ни был, занимает одну запись в таблице inode. Их количество задаётся при создании файловой системы и не меняется. Миллион крошечных файлов — миллион inode при копеечном объёме.
Проверяется командой df -i. Если в колонке использования стоит 100 процентов — диагноз готов.
Кто обычно виноват: почтовые очереди, кэш веб-приложений, сессии PHP, забытые задания в /var/spool, каталог с миллионом мелких логов.
Искать так: du --inodes -x -d 3 /var | sort -n | tail — покажет каталоги-рекордсмены по числу файлов, а не по размеру.
Лечение — вычистить мусор и починить то, что его плодит. Если это штатная нагрузка, файловую систему придётся пересоздавать с другим соотношением, потому что увеличить число inode на живой ext4 нельзя.
И в мониторинг обязательно добавьте проверку inode отдельно от места: они кончаются внезапно и без предупреждения.
Передача дел — момент, когда становится видно качество всей предыдущей работы. Что должно уйти вместе с доступом.
Карта: какие машины, какие роли, какие адреса, что от чего зависит. Схема на одном листе полезнее двадцати страниц текста.
Доступы: где хранятся, как получить, кто владелец у провайдера, регистратора, в облаке. Отдельно — что нужно поменять после передачи.
Расписания: что запускается по cron и таймерам, что делает, куда пишет.
Копии: где лежат, как восстановить, когда проверялись в последний раз.
Известные особенности: почему здесь выключено автообновление, почему этот сервис нельзя перезапускать днём, какой скрипт держит костыль и зачем.
Контакты: провайдеры, подрядчики, номера договоров, сроки продления.
И живая передача: пусть новый человек при вас развернёт копию, перезапустит сервис и пройдёт по инструкции восстановления. Всё, что он спросит вслух, надо дописать в документ.
Хороший признак: после передачи вам не звонят через неделю с вопросом «а где».
Вам передавали хозяйство или доставалось в наследство без документов?
Базовая настройка, которая экономит недели потом. Список короткий, но его редко выполняют целиком.
Учётные записи и доступ: вход по ключам, root без прямого входа, fail2ban.
Время: chrony и правильный часовой пояс на всех машинах одинаковый.
Логи: постоянный журнал на диске, ротация, отправка на центральный сервер, если он есть.
Мониторинг: место, inode, память, нагрузка, доступность сервиса, срок сертификатов. И проверка, что уведомления доходят до живого человека.
Резервные копии: настроены, автоматизированы, проверены восстановлением хотя бы раз.
Обновления безопасности: автоматические.
Фаервол: по умолчанию всё закрыто, открыто только нужное.
Документация: адреса, роли, кто владелец, как восстанавливать.
И то, что забывают чаще всего: swap или его осознанное отсутствие, лимиты дескрипторов и понятное имя хоста. Сервер с именем localhost в мониторинге через год станет загадкой.
Полчаса на старте — против суток разбора в аварии.
Пока всё работает, кажется излишеством. Ситуации, в которых это спасает, выглядят так.
Внешний источник исчез. Пакет удалили из репозитория, образ переименовали, версия отозвана. Ваша сборка, которая год работала, перестаёт собираться в самый неподходящий момент.
Пропал интернет или его ограничили. Развернуть новый сервер становится невозможно.
Скорость. Установка из локального зеркала идёт в разы быстрее и не зависит от чужого канала.
Контроль. Вы точно знаете, какие версии используются, и можете проверить их до того, как они попадут в прод.
Минимальный вариант, который окупается сразу: локальное кэширующее зеркало пакетов и реестр образов. Ставится за день, работает годами.
Отдельно про фиксацию версий: latest в образе означает, что завтра у вас может собраться что-то другое. В проде теги должны быть конкретными, а обновление — осознанным действием.
И храните у себя не только пакеты, но и инсталляторы драйверов, прошивки и лицензионные ключи. Искать их в аварии — отдельный вид страдания.
Самая частая дыра в компаниях — не взлом, а забытые доступы. Список того, что нужно закрыть.
Доменная учётная запись и почта. Не удалять сразу, а блокировать и перенаправлять почту руководителю: удаление ломает связи и историю.
VPN и удалённый доступ. Отдельно от домена, часто это второй список.
Ключи SSH. Проверьте authorized_keys на всех серверах: ключ живёт независимо от учётной записи.
Общие пароли. Если пароль от роутера, панели хостинга или сервисного аккаунта знал уволившийся — меняем.
Сторонние сервисы. Хостинг, регистратор доменов, облако, платёжные системы, рассылки, мессенджеры, репозитории кода. Это то, что обычно всплывает позже всего.
Личный телефон в двухфакторной аутентификации сервисных аккаунтов — проверьте отдельно.
Физические ключи и пропуска.
Организационная часть: список должен существовать заранее, а не составляться в день увольнения. Заведите таблицу «сервис — кто владелец — как отзывать» и обновляйте её при подключении нового сервиса, а не потом.
У вас есть такой чек-лист или каждый раз по памяти?
