Цель и область применения

Цель

Область применения

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

Основные принципы

Централизация ответственности

• Системный администратор — единственный сотрудник, имеющий право вносить изменения в инфраструктуру, конфигурацию серверов, сервисов, деплой-скрипты и т. п.
• Разработчики, QA и другие специалисты не осуществляют действия с сервером напрямую, если иное не согласовано руководством и самим администратором.

Безопасность и стабильность

• Все изменения в инфраструктуре должны соответствовать принципам безопасной разработки (Secure SDLC), политики резервирования и восстановлений.
• Любые обновления, перезапуски сервисов и изменения конфигураций проводятся с учётом минимизации простоев и рисков для работы приложения.

• Любые задачи и запросы к системному администратору фиксируются в корпоративной системе управления задачами.
• Должны быть чётко указаны цель, сроки, приоритет, а также потенциальное влияние на систему.

Роли и зоны ответственности

Системный администратор

• Отвечает за работоспособность, безопасность и масштабируемость серверной инфраструктуры.
• Проводит аудит, настройку и мониторинг систем, управляет деплой-процессами, отвечает за бэкапы и аварийное восстановление.
• При необходимости взаимодействует с провайдером хостинга, внешними сервисами (например, CDN), а также с командой разработчиков.

Разработчики

• Формируют задачи на внесение изменений в серверную часть (например, установка нового ПО, обновление окружения, создание дополнительных виртуальных машин) и согласовывают их с системным администратором.
• Уточняют у системного администратора технические нюансы (доступы, окружения, конфигурационные файлы) при настройке приложений.
• Не вносят изменения в конфигурацию серверов самостоятельно (если на то нет прямого разрешения DevOps).

Менеджер проекта

• Формирует задачи с учётом приоритетов и контролирует сроки совместно с системным администратором.
• Согласовывает с заказчиком/руководителем любые серьёзные изменения, влияющие на стабильность или архитектуру проекта (например, перенос сайта на другой сервер).
• В случае срочных запросов (аварий, критических уязвимостей) уведомляет системного администратора и координирует дальнейшие действия.

QA-специалисты

• Сообщают о выявленных проблемах, связанных с серверами или окружением (недоступен сервис, некорректные ответы и т. д.).
• Работают совместно с администратором при тестировании релизов, требующих изменений в инфраструктуре.

Руководитель

• Утверждает план работ и при необходимости перераспределяет ресурсы.
• Разрешает привлечение внешних специалистов (например, аутсорс-инженеров) в случае необходимости, по согласованию с системным администратором.
• Следит за тем, чтобы данный регламент соблюдался всеми участниками процесса.

Процесс постановки и выполнения задач

Создание и приоритизация задач

Постановка задачи

• Любая задача, требующая вмешательства в инфраструктуру (установка ПО, настройка окружения, диагностика ошибок) создаётся в корпоративной системе управления задачами.
• Описание задачи должно включать:
  • Цель/описание проблемы.
  • Желаемый результат.
  • Приоритет (срочно, планово, аварийно).
  • Сроки выполнения (deadline).

Анализ задачи

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

Согласование

• Если задача крупная или влияет на критически важный функционал, необходимо согласовать её с руководителем и/или менеджером проекта.
• В случае, когда требуется временный простой системы (например, при переезде на новый сервер), согласовывается время запланированного «окна» с командой и заказчиком.

Выполнение и мониторинг

Подготовка

• Системный администратор подготавливает окружение, резервные копии и план аварийного восстановления (backout plan), если изменения критичны.
• Для изменений, касающихся продакшена, рекомендуется предварительно проверить их на тестовом стенде (staging environment) или в изолированной среде.

Внесение изменений

• Администратор осуществляет настройки на сервере, обновляет конфигурационные файлы, деплой-скрипты, организует мониторинг и логирование.
• При сложных изменениях, требующих сотрудничества с разработчиками (например, переход на новую версию PHP, обновление Docker-образов), работы координируются в совместной задаче или подзадачах.

Тестирование

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

Документирование

• Все изменения, связанные с инфраструктурой, фиксируются в задаче в виде комментариев или в отдельном репозитории настроек (например, Ansible, Terraform и т. д.).
• Важно сохранить информацию о версиях ПО, настройках и прочих ключевых параметрах, чтобы при необходимости можно было быстро разобраться в истории изменений.

Завершение задачи

Подтверждение результата

• Задача переводится в статус «Проверка» (или аналогичный), после чего менеджер или автор задачи подтверждает, что всё работает корректно.
• Если требуется дополнительное время на тестирование, оно закладывается в план проекта.

Закрытие

• Задача закрывается, когда результат удовлетворяет всем требованиям.
• При необходимости формируется краткий отчёт (время, сложность, инструменты, ключевые выводы).

Отладка критических ошибок и аварий

Аварийные ситуации (инциденты)

• При обнаружении критических ошибок (сайт не работает, сервер недоступен, утечка данных и т. п.) системный администратор приоритетно занимается устранением проблемы.
• Менеджер проекта (или другое ответственное лицо) оповещает заинтересованных лиц (клиента, руководство) о статусе.
• Все действия, предпринимаемые при инцидентах, должны быть зафиксированы в системе управления задачами.

Уведомление и эскалация

• Если проблема требует участия сторонних сервисов (хостинг-провайдер, CDN, регистратор домена), системный администратор связывается с технической поддержкой и ведёт переписку до её решения.
• В случае, если ситуация выходит за рамки компетенций одного администратора, привлекается дополнительный эксперт (внутренний или внешний), по согласованию с руководителем.

Анализ инцидента (Post-mortem)

Особые случаи

Нестандартные запросы

• Любые нетривиальные запросы (например, смена провайдера хостинга, внедрение новых DevOps-инструментов) требуют дополнительного согласования с руководителем.
• Ресурсы, бюджеты и сроки таких работ планируются заранее.

Оперативный доступ

• При необходимости дать разработчикам или QA прямой доступ к серверу (ssh, sftp), подобное согласование проводится только через системного администратора и руководителя.
• Уровень прав доступа всегда определяется принципом минимально необходимого (least privilege).

Аутсорс и внешние специалисты

Контроль и актуализация документа

Контроль соблюдения

• Ответственность за соблюдение данного регламента несёт руководитель IT-отдела (или CTO), а также сам системный администратор в части правильного исполнения процедур.
• Систематические нарушения или игнорирование регламента могут приводить к дестабилизации инфраструктуры и подлежат разбору на уровне руководства.

Актуализация

• Регламент пересматривается по мере необходимости (например, при изменении внутренних процессов, обновлении инструментов), но не реже одного раза в год.
• Все сотрудники информируются о внесённых изменениях.