Короткий ответ

Минимальный регламент IT-эксплуатации Contoso — один документ на 4–8 страниц, который можно дать новому админу в первый день. Четыре обязательных блока: обращения пользователей, изменения прод, резервное копирование и доступы. Остальное (DRP, KB, SLA, схема) — ссылками, не копипастом внутрь. Если документ не исполняется за неделю — он слишком толстый или лживый.

Владелец регламента — Иван Петров. Утверждает руководитель, иначе директор снова ломает очередь в личке.

Симптомы и как отличить

Типичная картина:

  • 12 PDF 2018 года, никто не знает какой боевой;
  • тикеты в одном месте, изменения в другом чате, backup «в голове»;
  • онбординг админа — экскурсия по серверной без правил;
  • аудит спрашивает «покажите эксплуатационную политику» — молчание.

Отличия: KB — как чинить; паспорт — узел; регламент — правила игры. Не смешивайте в один файл 20 паспортов.

Возможные причины

  1. Казалось, что при одном админе регламент не нужен.
  2. Писали «для галочки» и забыли.
  3. Конфликт с договором аутсорса: у них свой, у вас никакой.
  4. Страх зафиксировать SLA.
  5. Нет CMDB — некуда сослаться.
  6. Редко: юристы правят каждое слово месяцами, IT сдаётся.

Диагностика

Чеклист «документ можно назвать регламентом»:

  1. Куда пользователь пишет и что запрещено (личная личка).
  2. Как ставится P1–P4 и часы покрытия.
  3. Как оформляется изменение и rollback.
  4. Что обязаны копировать и кто смотрит fail.
  5. Как выдают и снимают доступы, кто в DA.
  6. Где CMDB/схемы/vault (пути, не пароли).
  7. Кто owner регламента и дата.

Если 4 из 7 нет — даже при наличии «Политики ИБ 40 стр.» эксплуатационного минимума нет.

Сверьте, что пути в документе открываются: \\FILE01\IT\CMDB, wiki, тикет-система. Мёртвая ссылка = дыра как отсутствие пункта.

Решение

§1. Назначение и область

Площадки HQ, домен contoso.example, Windows Server 2022 и Ubuntu 24.04 LTS в смешанной среде. Вне скоупа: разработка продукта, если она другим отделом.

§2. Обращения

  • Единственный вход: портал/почта it@contoso.example.
  • Личные мессенджеры — не очередь, исключение P1 с переносом в учёт. Детали: статья.
  • Приоритеты P1–P4: шкала.
  • Целевые сроки: SLA таблицей в приложении A (чтобы не разъехалось).

§3. Изменения

  • Классы standard/normal/emergency.
  • Окно: например вт–чт 21:00–23:00.
  • Без rollback plan normal не начинают: rollback.
  • Факт — в журнале.

§4. Backup и аварии

§5. Доступы и секреты

  • Именные учётки, запрет общих admin.
  • Реестр привилегий, квартальный аудит.
  • Offboarding в день отзыва.
  • Секреты только в менеджере паролей.
  • Ссылки: реестр, Excel, уволенные, аудит прав.

§6. CMDB и документация

  • Листы Hosts, Services, Network, Privileged, Licenses, Hardware.
  • Схема сети и паспорта P1.
  • KB: старт с 20 карточек.
  • Owner сервисов обязателен.

§7. Роли

РольКто (пример)Делает
Владелец регламентаИван Петровактуальность
Дежурныйпо графикуP1, журнал
Owner 1Сглавбухприоритет, приёмка restore
Подрядчикпо договорутолько через CHG/тикеты

Как внедрить за 10 дней, не за год

Дни 1–2: написать черновик с таблицами SLA/окон как есть честно. Дни 3–4: включить тикет-вход. Дни 5–6: запрет normal без CHG на DC/FW. Дни 7–8: таблица backup. Дни 9–10: реестр DA и правило offboarding. Остальное — очередь, но документ уже существует.

Как не раздвоить документ и не убить его объёмом

Запретите вторую «операционную политику» в договоре аутсорса без ссылки на этот файл. Если у подрядчика свой ITIL, приложением идёт ваш минимум: тикеты, CHG, backup, доступы. Иначе Contoso снова живёт в WhatsApp менеджера.

Раз в квартал Иван Петров ставит в календарь 30 минут: открыть регламент, кликнуть все внутренние ссылки, обновить таблицу SLA если сменилось дежурство, обновить owner. Это дешевле ежегодного «давайте напишем заново».

Онбординг админа: день 1 — этот файл + vault + CMDB. День 2 — паспорта DC/FILE01. День 3 — учебный тикет и учебный CHG на стенде. Без этого регламент — PDF для аудиторов.

Не вставляйте сюда полные тексты DRP и паспортов. Ссылки и пути. Сердцевина должна остаться читаемой за один кофе.

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

  • Новый сотрудник IT прочитал файл за 40 минут и знает, куда класть тикет и CHG.
  • Руководитель подписал.
  • Через 30 дней: есть тикеты, есть CHG, fail backup кому-то падает.
  • Ссылки открываются.
  • Директорский обход в личку уменьшился (не обязательно до нуля).

Повторный аудит через квартал смотрит исполнение, не наличие PDF.

Если не помогло

  • Никто не читает: оставьте 2 страницы ядра, остальное только ссылки.
  • Аутсорс игнорирует: доступ VPN только при работе по вашим тикетам.
  • Юристы раздувают: разделите «юридическая политика ИБ» и «регламент эксплуатации IT». Второй пишете вы.

Профилактика

  • Обзор раз в год или при смене Ивана Петрова.
  • Любой новый процесс — сначала абзац в этом файле, потом толстая вики.
  • Онбординг/оффбординг админа ссылается на регламент.
  • Не плодите второй «настоящий» документ в чате.

FAQ

Это ITIL?

Нет, это четыре гигиенических контура. Совместимо с ITIL, не требует CAB из 12 человек.

Нужно ли вшивать тексты всех 24 статей раздела?

Нет. Этот файл — указатель и обязательные таблицы. Иначе устареет в день публикации.

Где хранить?

Там же, откуда откроется при мёртвом AD: облако вне домена + копия на шаре. Как DRP.

Кто имеет право менять регламент?

Owner через CHG (да, изменение регламента — тоже изменение). Не правки «на коленке» без даты.

Что если филиал живёт по-другому?

Приложение B «площадка WH1», отличия явно. Не делайте вид что HQ=везде.

Минимальный регламент и ISO-сертификация?

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