Регламент работы DevOps / SRE

Цель регламента

Обеспечить предсказуемую поставку и эксплуатацию сервисов в пределах согласованных SLO, RPO и RTO.

Применение в Республике Беларусь

• Работа выполняется в пределах трудовой функции, полномочий, локальных правовых актов и договоренностей конкретной организации. Обязательства перед клиентом принимает только уполномоченное лицо.
• При обработке персональных данных применяются принципы Закона Республики Беларусь от 7 мая 2021 г. № 99-З: законная цель и основание, соразмерность состава данных, ограничение срока хранения, прозрачность и защита прав субъекта.
• До привлечения внешнего сервиса или подрядчика определяется роль организации и контрагента как оператора либо уполномоченного лица, перечень данных, операции, меры защиты, возврат и удаление данных.
• Трансграничная передача персональных данных и использование зарубежных SaaS согласуются с ответственным за внутренний контроль обработки персональных данных до загрузки реальных данных.
• Юридически значимые решения, согласования и документы оформляются в форме, предусмотренной договором и законодательством. Сообщение в чате или отметка в трекере не приравниваются автоматически к электронному документу с ЭЦП.
• Коммерческая тайна, сведения клиента, исходный код, учетные данные и внутренние документы передаются только лицам с рабочей необходимостью через одобренные компанией системы.
• При дистанционной или комбинированной работе соблюдаются условия трудового договора, локальный порядок взаимодействия, режим рабочего времени и требования по безопасному использованию предоставленного оборудования.
• Размещение систем и резервных копий, трансграничная передача, внешние облака и subprocessors согласуются до загрузки персональных данных или конфиденциальной информации.
• Технические и криптографические меры для систем с ограниченной информацией определяются по применимой классификации и внутренней модели угроз.

Что проверить до начала работы

• Названы заказчик результата, владелец решения, исполнители, согласующие лица и канал эскалации.
• Зафиксированы цель, ожидаемый результат, границы задачи, срок, приоритет, зависимости и критерии приемки.
• Определена классификация информации: публичная, внутренняя, конфиденциальная, коммерческая тайна или персональные данные.
• Подтверждено, что специалист имеет необходимые доступы и полномочия, а лишние права не выдаются.
• Понятно, где хранится актуальная версия результата и какие записи подтверждают выполненную работу.
• Есть service catalog с владельцами, классификацией данных, размещением, внешними зависимостями, RTO/RPO, SLO и контактами on-call.
• Определены approved regions/providers, правила администрирования, централизованный audit log и аварийный доступ.

Зона ответственности

• Инфраструктура, CI/CD, доступы, секреты, мониторинг, алерты, capacity, backup, on-call и incident response.
• Инженер надежности автоматизирует повторяемые операции и делает эксплуатационный риск измеримым.

Обязанности специалиста

• Управлять production-инфраструктурой через review и IaC.
• Обеспечивать неизменяемость, прослеживаемость и обратимость релизов.
• Строить алерты по пользовательскому влиянию и сопровождать их runbook.
• Проверять восстановление данных и сервисов практическими учениями.

Рабочий порядок

1. Инвентаризировать сервисы, зависимости, владельцев и доступы.
2. Настроить CI/CD с проверками supply chain и rollback.
3. Определить golden signals, SLI/SLO и actionable alerts.
4. Проверить capacity, backup, restore и failure scenarios.
5. Организовать on-call, incident command и postmortem actions.

Контрольные вопросы специалиста

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

1. Где физически и логически размещены данные, реплики, логи и резервные копии?
2. Какие поставщики и subprocessors имеют техническую возможность доступа?
3. Соответствуют ли права принципам least privilege, separation of duties и ограничению по времени?
4. Как создаются, ротируются, отзываются и аудируются секреты и ключи?
5. Содержат ли логи и traces персональные данные, токены или payload?
6. Проверено ли восстановление в пределах RTO/RPO на чистом окружении?
7. Как обнаруживается массовый экспорт, аномальная авторизация и изменение защиты?
8. Готовы ли rollback, capacity, health checks и наблюдаемость до деплоя?
9. Кто Incident Commander, кто принимает решение об уведомлении и где ведется timeline?

Персональные данные и безопасность

• Использовать корпоративные учетные записи, MFA, менеджер секретов и принцип минимально необходимых прав; не передавать пароли в чатах, документах и задачах.
• Не копировать рабочие материалы в личную почту, личные облака, публичные AI-сервисы или неутвержденные инструменты без письменного разрешения владельца информации.
• Не использовать реальные персональные данные в разработке, тестировании, демонстрациях и обучении, если цель может быть достигнута синтетическими или обезличенными данными.
• В логах, снимках экрана, отчетах и bug report скрывать токены, пароли, номера документов, платежные данные и иные избыточные идентификаторы.
• При ошибочной отправке, утрате доступа, подозрении на утечку или несанкционированную обработку немедленно прекратить распространение и уведомить руководителя и ответственного за персональные данные; внешние уведомления выполняют уполномоченные лица в установленные сроки.
• Доступы пересматриваются при смене роли, завершении проекта и увольнении; данные и носители возвращаются или удаляются по подтвержденной процедуре.
• Production-доступ предоставлять через именованные учетные записи, bastion/VPN и MFA; shared root-доступ запрещен, кроме контролируемой аварийной процедуры.
• Логи безопасности защищать от изменения, синхронизировать время и хранить по установленному сроку без избыточного содержимого.

Обязательные артефакты

• Service Catalog и IaC repository
• Delivery Pipeline и SBOM
• Dashboards, Alert Catalog и Runbooks
• SLO и Error Budget Policy
• Restore Test и Postmortem

Критерии качества

• Изменение инфраструктуры прослеживается и проходит review.
• Каждый page требует понятного действия.
• Восстановление подтверждено тестом, а не наличием backup.

Контрольные точки

• Перед релизом проверены rollback, миграции, capacity и наблюдаемость.
• Fast burn SLO вызывает согласованную реакцию.
• После инцидента preventive actions имеют владельцев и срок.

Антипаттерны

• Менять production вручную без фиксации.
• Алертить каждую техническую ошибку.
• Хранить секреты в репозитории или образе.
• Объяснять инцидент только ошибкой человека.

Рабочий ритм и периодический контроль

• По рабочим дням: обновить статус задач, зафиксировать блокеры и решения, требующие участия других ролей.
• Еженедельно: сверить приоритеты, риски, качество артефактов, просрочки и необходимость эскалации.
• Перед релизом или передачей результата: провести проверку по критериям приемки, безопасности, персональным данным и эксплуатационным рискам.
• После релиза: проверить фактический результат и зарегистрировать дефекты, отклонения, уроки и последующие действия.
• Ежеквартально: пересмотреть доступы, устаревшие документы, ручные операции, технический долг и соответствие регламенту.
• Ежемесячно: access review, vulnerability/patch review, backup status, certificate/secret expiry и SLO; не реже ежегодного плана — DR exercise.

Метрики контроля

Коммуникации и эскалация

• Критичный инцидент сразу получает Incident Commander и единый канал.
• Статус сообщает влияние, действия и следующее обновление.
• Риски надежности обсуждаются с продуктом через SLO и error budget.

Матрица обязательной эскалации

• Немедленно: утечка или подозрение на утечку данных, компрометация учетной записи, критическая уязвимость, недоступность ключевого сервиса или риск необратимой потери данных.
• В течение рабочего дня: нарушение договорного срока, блокирующее противоречие требований, несанкционированное изменение production, юридический или репутационный риск.
• До продолжения работы: отсутствует владелец решения, правовое основание обработки данных, согласованный критерий приемки либо полномочие на действие.
• Эскалация содержит факты, влияние, затронутые системы и данные, уже выполненные безопасные действия, варианты решения и время следующего обновления.
• Немедленно объявлять инцидент при компрометации ключа, несанкционированном production-доступе, потере backup, утечке данных или нарушении SLO с существенным влиянием.

Когда работа считается завершенной

• Результат проверен по всем критериям приемки, а непроверенные области и остаточные риски перечислены явно.
• Артефакты, решения, версии, ссылки и доказательства проверки сохранены в согласованном корпоративном источнике.
• Заинтересованные роли уведомлены об изменении, ограничениях, действиях после релиза и владельце дальнейшего сопровождения.
• Временные доступы, файлы, тестовые данные, feature flags и обходные решения удалены либо имеют владельца и срок закрытия.
• Результат принят владельцем решения или имеется письменное решение о принятии остаточного риска уполномоченным лицом.
• Инфраструктурное изменение завершено после IaC review, автоматизированных проверок, обновления CMDB/runbook, подтверждения backup/rollback и наблюдения стабильного окна после релиза.

Документирование и хранение записей

• Рабочие решения и согласования фиксируются в трекере, базе знаний, репозитории или системе электронного документооборота, принятой в компании.
• Срок хранения определяется номенклатурой дел, договором, целью обработки и требованиями законодательства; персональные данные не хранятся “на всякий случай”.
• Удаление или архивирование должно быть контролируемым: сохраняются необходимые версии, авторство, дата решения и связь с проектом или релизом.
• Экспорт данных и локальные копии допускаются только на срок рабочей необходимости и удаляются после подтвержденной загрузки результата в корпоративную систему.
• Хранить IaC, inventory, access review, change log, audit trail, SLO, runbooks, результаты restore/DR drills и postmortem.

Нормативная основа и официальные материалы

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

• Закон Республики Беларусь от 7 мая 2021 г. № 99-З «О защите персональных данных»

  Основания, принципы, права субъектов и обязанности при обработке персональных данных.

• Национальный центр защиты персональных данных Республики Беларусь

  Официальные разъяснения, рекомендации и актуальная практика по персональным данным.

• Рекомендации по обработке персональных данных в трудовой деятельности

  Практика работы с данными работников и соискателей.

• Рекомендации о взаимоотношениях операторов и уполномоченных лиц

  Распределение обязанностей при привлечении подрядчиков и облачных сервисов.

• Разъяснение об уведомлении о нарушениях систем защиты персональных данных

  Официальная памятка для реагирования на инциденты с персональными данными.

• Разъяснение о трансграничной передаче персональных данных

  Проверка условий передачи данных зарубежным получателям и сервисам.

• Закон Республики Беларусь от 28 декабря 2009 г. № 113-З «Об электронном документе и электронной цифровой подписи»

  Юридически значимый электронный документооборот и ЭЦП.

• Трудовой кодекс Республики Беларусь

  Трудовая функция, рабочее время, дистанционная работа и локальные правовые акты.

• Закон Республики Беларусь от 10 ноября 2008 г. № 455-З «Об информации, информатизации и защите информации»

  Общие требования к информации, информационным системам и защите информации.

• Закон Республики Беларусь от 5 января 2013 г. № 16-З «О коммерческой тайне»

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