Журнал изменений сайта: кто, что и когда правил в админке

Знакомая история: во вторник на сайте всё работало, в четверг перестала отправляться форма заявки. Кто-то что-то менял, но кто и что — неизвестно. Начинается расследование методом опроса: «Я ничего не трогал», «Я только текст поправил», «Мне подрядчик сказал галочку снять». В итоге день уходит на то, чтобы найти изменение, которое сделали за минуту.

Или другая ситуация: заявок стало меньше вдвое, и надо понять, с какого момента. Заглянули в статистику — падение началось три недели назад. Что произошло три недели назад? Никто не помнит.

Обе проблемы решаются одним и тем же — журналом изменений. Это возможность посмотреть, кто, что и когда правил на сайте. Разберём, зачем он нужен, что именно должно в нём фиксироваться и что делать, если такой возможности сейчас нет.

Зачем это владельцу сайта

Быстро находить причину поломки. Большинство неполадок на живом сайте вызваны не сбоями сервера, а человеческими действиями: изменили настройку, удалили блок, поправили шаблон, обновили модуль. Если видно, что вчера в 16:40 менялся шаблон карточки товара, а сегодня карточки не открываются, — расследование занимает минуту вместо дня.

Сопоставлять изменения с обращениями. Заявок стало больше или меньше — первый вопрос всегда «что мы поменяли». Без журнала это гадание. С журналом — открыли, посмотрели даты и сопоставили с графиком в Яндекс.Метрике.

Понимать, кто чем занимается. Если сайт ведут несколько человек или подключён подрядчик, полезно видеть объём и характер работы. Не для контроля ради контроля, а чтобы понимать, что происходит.

Восстанавливать удалённое. Многие системы хранят предыдущие версии текста. Сотрудник переписал страницу и испортил — можно вернуть.

Разбираться при смене подрядчика. Когда приходит новая команда, журнал показывает, что делали до неё. Это экономит недели на изучение сайта.

Дисциплинировать. Само знание того, что действия фиксируются, заметно снижает количество «я просто посмотреть зашёл».

Что должно фиксироваться

Минимальный полезный набор.

Кто. Учётная запись, под которой сделано действие. Отсюда важное следствие: у каждого сотрудника должна быть своя запись. Если все работают под общим администратором, журнал бесполезен — он покажет, что «администратор» что-то сделал.

Когда. Точные дата и время.

Что за объект. Какая страница, какой товар, какой раздел, какая настройка.

Какое действие. Создание, изменение, удаление, публикация, снятие с публикации.

Что именно изменилось. Идеально — старое и новое значение. Это самое ценное и самое редкое.

Дополнительно полезно фиксировать: входы в админку (в том числе неудачные попытки), изменения прав пользователей, обновления системы и модулей, изменения настроек, действия с файлами.

Что в системах управления есть по умолчанию

Разные системы дают разный объём.

В ХостСМС ведётся журнал действий пользователей в панели управления: видно, кто из сотрудников заходил и какие операции выполнял с элементами, разделами и настройками. Кроме того, существует система резервных копий, которая позволяет вернуться к состоянию на определённую дату, — это выручает, когда изменение оказалось разрушительным и точечно откатить его невозможно. Отдельно ведутся журналы входов, что помогает при разборе подозрительной активности.

В 1С-Битрикс есть журнал событий, где фиксируются входы, изменения и ошибки, а также встроенное хранение предыдущих версий содержимого.

В Вордпресс базово почти ничего не фиксируется, и журнал обычно добавляют отдельным расширением. Это стоит учитывать: сайт на этой системе без специальной настройки не хранит истории действий вообще.

Общий вывод: посмотрите, что есть у вас, прежде чем что-то докупать. Часто нужное уже включено, просто никто не знает, где смотреть.

Чего журнал не покрывает

Важно понимать границы. Журнал в панели управления фиксирует действия внутри панели. Он не покажет:

Правки файлов напрямую на сервере. Если программист подключился и поправил шаблон, минуя админку, в журнале этого не будет. Для таких случаев нужна либо система контроля версий, либо хотя бы правило, что все правки идут через понятный процесс.

Изменения на стороне сервера. Обновили версию программного обеспечения, поменяли настройки, изменили правила перенаправления — это фиксируется в логах сервера, а не в журнале сайта.

Изменения в сторонних сервисах. Кто-то поправил цель в Яндекс.Метрике, изменил рекламную кампанию, отредактировал карточку в Яндекс Бизнесе — это отдельные системы со своими историями.

Изменения в базе данных напрямую. Массовые операции через прямой доступ обычно не отражаются.

Поэтому полная картина складывается из нескольких источников, и полезно понимать, где что искать.

Практика: как организовать работу

Отдельная учётная запись каждому. Это основа. Без неё всё остальное не имеет смысла. Уволился сотрудник — запись отключается, и заодно видно, что он делал последним.

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

Отдельные записи для подрядчиков. Не давайте подрядчику ту же учётную запись, что у вас. Отдельная запись — видно, что делал именно он, и по завершении работ её можно отключить одним движением.

Правило комментировать изменения. Если система позволяет оставлять пометку к правке — пользуйтесь. «Обновил цены по прайсу от такого-то числа» через полгода объяснит всё.

Внешний список крупных изменений. Отдельная простая таблица, где фиксируются значимые события: обновили систему, поменяли структуру каталога, запустили новый раздел, сменили хостинг, подключили новый счётчик. Дата, что сделали, кто. Пять строк в месяц. Эта таблица бесценна при разборе того, почему изменился поток обращений, потому что журнал системы её не заменит — он слишком подробный, и крупные события в нём тонут.

Резервная копия перед серьёзными работами. Журнал говорит, что случилось. Резервная копия позволяет это отменить. Нужны обе вещи.

Регулярный просмотр. Раз в месяц заглядывать в журнал — полезная привычка. Часто обнаруживаются вещи, о которых не знали: непонятные входы, действия уволившегося сотрудника, активность подрядчика, которого давно не оплачивали.

Как использовать журнал при разборе проблем

Практическая последовательность, когда что-то сломалось или упали обращения.

Шаг первый: определите дату. По статистике в Яндекс.Метрике или по жалобам. Точность до дня обычно достаточна.

Шаг второй: посмотрите журнал за этот день и за день до. Обычно виновник виден сразу.

Шаг третий: если в журнале пусто — смотрите за пределы сайта. Обновление на сервере, смена настроек хостинга, изменения в рекламе, действия с карточками на картах, работы у провайдера.

Шаг четвёртый: проверьте, не совпало ли с внешним событием. Иногда падение обращений не связано с сайтом вообще: сезон, конкурент запустил рекламу, закончился бюджет.

Шаг пятый: зафиксируйте вывод. Запишите в тот самый внешний список, что произошло и чем закончилось. Через год эта запись сэкономит вам день.

Как это связано с продвижением 3 в 1

Связь прямее, чем кажется, и касается всех трёх каналов.

Поиск. Работа над поисковым каналом — это последовательность изменений: переписали страницу, изменили структуру, добавили раздел, поправили заголовки, ускорили загрузку. Оценивать результат можно только сопоставляя изменения с обращениями. Без журнала и списка событий невозможно понять, что сработало, а что нет, — а значит невозможно повторить успех и избежать повторения ошибки. Отдельная типичная беда: страницу, которая давала обращения, переписал новый сотрудник «для красоты», убрав из неё конкретику — цены, сроки, факты. Обращения упали, но связь никто не заметил, потому что не было видно, что страницу вообще трогали. Для нейропоиска это особенно чувствительно: он опирается на конкретные утверждения, и удаление цифр из текста напрямую выбивает страницу из генеративных ответов.

Яндекс.Справочник. Карточка в Яндекс Бизнесе тоже имеет свою историю изменений, и её тоже стоит фиксировать во внешнем списке. Классический случай: обращения с карт упали, и никто не может понять почему, а оказывается — месяц назад кто-то поправил категорию или убрал часть услуг. Правило то же: доступ к карточке должен быть у ограниченного круга людей, и изменения должны записываться.

2ГИС. Аналогично. Плюс здесь бывают изменения не по вашей вине: данные обновляются на основании внешних источников, карточку могут объединить или изменить. Регулярная проверка и фиксация состояния помогают заметить это вовремя.

Практический вывод: единый список изменений должен охватывать все три канала. Одна таблица, где записаны и правки сайта, и изменения карточек, и работы по рекламе. Тогда при любом колебании потока обращений вы за минуту видите, что могло на это повлиять.

Реальные случаи, где журнал решил вопрос

Несколько типичных ситуаций из практики — чтобы было понятно, о чём речь.

Пропали товары из каталога. Магазин обнаружил, что часть позиций не отображается. Подозревали сбой выгрузки. Журнал показал, что накануне сотрудник массово снял с публикации раздел, перепутав галочки при групповой операции. Восстановление заняло десять минут вместо предполагаемого разбора выгрузки на несколько дней.

Перестала приходить почта с формы. Форма отправлялась, сообщение об успехе показывалось, а письма не доходили. В журнале видно, что за неделю до этого меняли настройки отправки почты — подрядчик подключал рассылку и заодно переписал адрес получателя. Без журнала на такую причину выходят обычно случайно и через месяц.

Упали обращения после «косметических правок». Новый сотрудник переписал три страницы услуг, сделав тексты «более современными»: убрал таблицы с ценами и заменил конкретные сроки на «в кратчайшие сроки». Обращения с этих страниц упали втрое. Журнал показал даты правок, и связь стала очевидной — тексты вернули.

Непонятные входы в панель управления. При очередном просмотре журнала обнаружились входы под учётной записью сотрудника, который уволился три месяца назад. Запись отключили, пароли сменили. Никакого ущерба не было, но могло быть.

Спор с подрядчиком об объёме работ. Журнал показал, что именно и когда делалось. Разговор закончился быстро и без эмоций.

Общее во всех случаях: без журнала каждая из этих ситуаций разбиралась бы днями и с большой долей догадок.

Что делать, если журнала нет

Проверьте, точно ли нет. Часто он есть, просто спрятан в разделе, куда никто не заглядывает.

Заведите отдельные учётные записи прямо сейчас. Это первое и самое важное действие, и оно ничего не стоит.

Начните вести внешний список изменений. Обычная таблица. Начать можно сегодня, и через три месяца она уже будет полезна.

Настройте резервное копирование. Если нет возможности видеть, что изменилось, должна быть возможность вернуть как было.

Обсудите с подрядчиком. Если сайт ведёт сторонняя компания, попросите вести журнал работ. Нормальный подрядчик и так его ведёт и покажет по первой просьбе.

Рассмотрите добавление журнала. Если система его не поддерживает, это обычно решается настройкой или расширением, и стоит недорого по сравнению с одним днём разбирательств.

Итог

Журнал изменений — не бюрократия, а инструмент, который окупается в первый же раз, когда что-то ломается или падают обращения. Он превращает вопрос «что случилось» из детективной истории в двухминутную проверку.

Минимум, который стоит обеспечить: у каждого своя учётная запись, права выданы по необходимости, включён встроенный журнал системы, настроены резервные копии, и ведётся простой внешний список крупных изменений по сайту, карточкам и рекламе. Этого достаточно, чтобы в любой момент понимать, что происходило с вашим сайтом.

Специалисты компании «Сайты Профессионально» готовы бесплатно посмотреть, как устроено ведение вашего сайта: кто имеет доступ, фиксируются ли изменения, настроены ли резервные копии, есть ли риск потерять работающие страницы из-за неаккуратной правки. По итогам вы получите понятные рекомендации по наведению порядка. Обращайтесь — разберём вашу ситуацию.