Что входит в сопровождение собственных сервисов: регламент небольшой компании
Сопровождение собственных сервисов включает доступность, резервные копии, обновления, запас ресурсов и управление доступом. Договоритесь, кто выполняет каждую работу и чем подтверждает результат. Начните с короткого реестра систем и календаря: руководитель должен видеть выполненные проверки и открытые задачи, а другой специалист — суметь продолжить обслуживание.
Что собрать для первого регламента
- Список систем, версий, адресов и внешних зависимостей.
- Владельцы рабочих задач, технический исполнитель и запасной специалист.
- Состав данных каждой системы, места хранения копий и доступ компании к аварийным реквизитам.
Определите системы, работу и ответственных #
В торговой компании 22 сотрудника. Odoo Community хранит рабочие данные, Mattermost — обсуждения, Gitea — исходники сайта и внутренних изменений. Поддержка не заканчивается включённым сервером: сотрудники должны открывать вложения, а нужные подключения между системами — продолжать работать.
Рабочие действия. Для Odoo укажите нужные карточки и операции, для чата — сообщения и файлы, для Gitea — чтение и запись репозиториев.
Ответственность. Назначьте владельца результата со стороны компании и технического исполнителя. Запишите, что входит в обслуживание подрядчика и кто отвечает за внешние сервисы.
Подтверждение. Для копии нужны дата, состав, место и проверка восстановления. Для обновления — прежняя и новая версии, выполненные действия и способ возврата.
Регламент соединяет календарь работ с журналом результатов. Для небольшой компании достаточно коротких записей с ответственным и сроком. Дорогая система управления услугами не обязательна, если по журналу понятно, что сделано, что осталось и кто продолжит работу.
Согласуйте календарь обслуживания #
| Период | Действие | Подтверждение |
|---|---|---|
| Каждый рабочий день | Проверить доступность, копии и новые ошибки | Нет необработанного критичного сигнала; указана последняя копия |
| Каждую неделю | Посмотреть рост БД, файлов и свободного места | Запас ёмкости и задачи с датами |
| Каждый месяц | Оценить обновления и пересмотреть доступы | Список применённых и отложенных изменений с причинами |
| Каждый квартал | Пробно восстановить выбранную систему | Отчёт с входом, данными, файлами и фактическим временем |
| При кадровом изменении | Добавить или отозвать права | Доступ проверен обычной учётной записью |
| После инцидента | Разобрать причину и обновить регламент | Одна задача предотвращения повторения с владельцем |
Календарь в таблице — отправная точка для компании из примера. Меняйте частоту по допустимому простою и потере данных. Если за час появляются важные заказы, одной ночной копии может быть недостаточно; у редко меняющихся материалов требования будут другими.
Не назначайте одинаковое расписание только ради удобства. Для каждой операции укажите исполнителя, срок и подтверждение завершения. Если квартальная проверка охватывает лишь одну систему, остальные должны оставаться частью понятного общего плана восстановления, а не выпадать из обслуживания.
Сохраняйте полный комплект данных #
Согласованная копия содержит базу и файлы, которые соответствуют одному состоянию приложения. Если они сохранены в разное время, запись может ссылаться на отсутствующее вложение. Поэтому состав данных и способ их совместного сохранения нужно определить для каждой системы.
Mattermost. Сохраняйте базу, конфигурацию и пользовательские файлы. Для чистой согласованной копии предусмотрена остановка. Если файлы лежат в S3, отдельно определите защиту от удаления.
Gitea. В копию входят база, репозитории, вложения и конфигурация. При копировании работающей системы возможны несовпадения; восстановление требует отдельного порядка действий.
Odoo Community. Перечислите базу, хранилище файлов — filestore, дополнительные модули и настройки для своей установки. Перенос одной базы не подтверждает доступность вложений.
Не переносите возможности Enterprise в регламент Community без проверки редакции. Компания должна знать расположение копий, нужные версии и порядок доступа до аварии. Ключи и пароль резервного хранилища должны оставаться доступны назначенному сотруднику при недоступности подрядчика.
Проверяйте обновление до рабочей системы #
Перед обновлением запишите текущую и выбранную версии, затем изучите изменения между ними. Для перехода на новую основную версию отдельно проверьте преобразование базы и совместимость дополнительных модулей. Сначала восстановите комплект данных в отдельной учебной среде и обновите её.
Проверяйте обычные действия: в Odoo открыть и изменить учебную карточку, в Mattermost отправить сообщение с файлом, в Gitea скачать и записать тестовый репозиторий. Для Gitea эти операции называются clone и push. Запишите фактический результат каждой проверки.
Для рабочей системы согласуйте время, свежую копию и условие прекращения попытки. Возврат старого приложения после изменения базы может не сработать. Подготовьте восстановление совместимого комплекта версии и данных, затем убедитесь, что ответственный знает, где взять его.
После обновления проверьте вход обычного сотрудника, фоновые задания и файлы, затем сообщите владельцу результат. Разделяйте изменения системы, базы, приложения и расширений так, чтобы найти причину возможной ошибки. Несколько одновременных изменений усложняют разбор сбоя.
Как оформить и выполнить изменение
- Запишите систему, текущую и целевую версии, причину обновления и владельца результата.
- Укажите время свежей согласованной копии и ссылку на порядок возврата.
- Обновите учебную среду и проверьте выбранные рабочие действия. Сохраните результат.
- Согласуйте время с владельцами, выполните изменение и повторите проверку обычным аккаунтом.
- Получите подтверждение владельца. При возврате запишите причину и следующую задачу.
Следите за доступами, ресурсами и сбоями #
Выдавайте личные аккаунты с нужными ролями. Подрядчику назначьте отдельный доступ и срок пересмотра. При уходе сотрудника сначала передайте ответственность за данные, затем отзовите сессии и технические ключи. Удаление одного аккаунта не подтверждает отключение всех связанных подключений.
Проверяйте приложения отдельно и сохраняйте подтверждение передачи прав компании. Аварийные реквизиты должны быть доступны назначенному сотруднику, а не только исполнителю. В журнале оставляйте ссылки и владельцев; сами секреты храните в предназначенном для них хранилище.
Следите за свободным местом вместе со скоростью роста. База, файлы чата и репозитории меняются по-разному. Для расширения диска укажите срок и бюджет, чтобы руководство успело принять решение до остановки сервиса, а не после заполнения хранилища.
При сбое запишите симптом, начало, затронутые системы, выполненные действия и время следующего сообщения. Перезапуск может вернуть работу временно; повторяющаяся ошибка требует причины и задачи по исправлению. Контакты провайдера домена или хранилища должны находиться рядом с зависимым сервисом.
Что должно быть в ежемесячном отчёте #
Ежемесячный отчёт должен помогать принять решения. Вместо одного числа отработанных часов покажите состояние важных функций, копий, изменений, ресурсов и доступов. Отдельно укажите риски и отложенные работы, их последствия и срок решения.
Сделано. Перечислите подтверждённые результаты: восстановлен учебный файл, проверен вход после обновления, отозван ключ бывшего подрядчика. Приложите короткое подтверждение.
Требует решения. Укажите задачи, которым нужны покупка ресурсов, изменение процесса или согласование времени. Для каждой нужны последствия, ответственный и срок.
Можно передать. Другой специалист должен найти версии, адреса, контакты, состав копий и первое действие при сбое без обращения к памяти текущего администратора.
Проверьте передачу обслуживания практическим чтением регламента другим исполнителем. Обновляйте документ после переноса системы, крупного обновления или смены ответственности. Его ценность определяется тем, помогает ли он выполнить следующую работу и сохранить доступ компании к данным.
Когда регламент работает
- У каждой системы есть состав данных, владелец рабочих задач и технический исполнитель.
- Журнал содержит результаты проверок и открытые задачи с ответственными и сроками.
- Пробное восстановление проверяет пользовательские действия и фактическое время возвращения к работе.
- Компания сохраняет доступ к копиям и настройкам и может передать обслуживание другому специалисту.