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

Зачем эта роль

Системный администратор существует, потому что у компании есть IT-инфраструктура, на которой стоит вся ежедневная работа команды и клиентов: рабочие станции, корпоративные аккаунты (Google Workspace, Notion, Slack, VPN, специализированные SaaS), сетевая среда, доступы и права, парк лицензий, инфобез на уровне базовой гигиены. Без системного администратора этот контур разваливается на куски: новый сотрудник ждёт доступы по неделе, ушедший сотрудник остаётся с действующими правами, инвентаризация инфраструктуры расползается, инциденты превращаются в блокеры для CVD-команд, а COO вынужден сам решать каждую IT-ситуацию.

Системный администратор закрывает технико-административный контур, на котором стоит вся операционная производственная среда COO в части IT. COO держит производственную операционку компании целиком; системный администратор — её технический фундамент: ведёт IT-инфраструктуру, держит реестр аккаунтов, лицензий и доступов, обрабатывает заявки и инциденты, обеспечивает базовый уровень информационной безопасности.

Качество роли измеряется не количеством закрытых тикетов, а отсутствием эпизодов, когда работа CVD-команд и операционных функций тормозится из-за IT. Лучший системный администратор — тот, чья работа не видна: всё работает, и поэтому никто о нём не вспоминает.

Системный администратор — Administrator в логике PAEI. Сильная сторона — точность, дисциплина, систематизация работы с конфигурациями и реестрами, способность доводить инциденты до закрытия без оставленных хвостов. Слабая сторона (то, что НЕ должно быть в его зоне) — IT-стратегия (выбор стека, архитектура корпоративных систем, политика инфобеза высокого уровня — это COO + CEO), разработка продукта и кастомизация (это команды Anahid и Ilm под CVD), решения по бюджету IT (это COO + GM). Системный администратор удерживает IT-инфраструктуру компании в работающем состоянии, но не двигает IT-архитектуру.

Что входит в работу системного администратора

Системный администратор ведёт четыре связанные функциональные зоны IT-инфраструктуры:

Аккаунты и доступы — управление корпоративными аккаунтами (Google Workspace, Notion, Slack, VPN, специализированные SaaS) на всём жизненном цикле сотрудника: выдача в день выхода, изменения по запросу, отзыв в день оффбординга. Ведение реестра прав доступа — кто к чему имеет доступ, в каком объёме. Базовая инфобез-гигиена в части аккаунтов: MFA, политика паролей, корректное распределение ролей.
Устройства и рабочие станции — выдача рабочих ноутбуков, базовая настройка под корпоративные стандарты, ремонт и замена при необходимости, ведение инвентаря устройств с привязкой к сотрудникам. При оффбординге — корректный возврат устройства, очистка корпоративных данных.
Заявки и инциденты — приём, классификация, исполнение и закрытие IT-заявок и инцидентов от сотрудников. SLA по приоритетам. Эскалация в COO при серьёзных инфобез-инцидентах или нестандартных кейсах. Анализ паттернов для превентивной работы.
Реестр и лицензии — актуальный реестр инфраструктуры (аккаунты, устройства, лицензии, инфобез-политики), своевременное продление лицензий, координация с вендорами SaaS, провайдерами связи, локальными подрядчиками по железу. Подготовка данных по IT-расходам для GM-домена.

Все четыре зоны связаны через общий принцип «IT-инфраструктура невидима для CVD-команд и операционных функций»: всё работает, и никто не тратит время на то, чтобы оно работало. Стратегические IT-решения (выбор стека, архитектура корпоративных систем, инфобез-политика высокого уровня, бюджет IT) — выше уровня системного администратора; они в зоне COO. Sysadmin исполняет операционный IT-контур внутри согласованных COO рамок.

Продукт должности

Бесперебойно работающая IT-инфраструктура NOTA — корпоративные аккаунты, доступы и устройства, готовые к работе в день выхода сотрудника, стабильно функционирующие Google Workspace, Slack, Notion и VPN, защищённая и резервируемая корпоративная информация. Заявки сотрудников и инциденты решаются в согласованном SLA и не доходят до COO как блокеры. Качество измеряется отсутствием эпизодов, когда работа CVD-команд и операционных функций тормозится из-за IT.

Главный потребитель и его требования

Главный потребитель: COO (получает работающий IT-фундамент как готовую инфраструктуру для своего производственно-операционного контура).

COO получает от системного администратора не «решённые тикеты», а реальную способность компании работать без IT-простоев и операционных IT-рисков, без эскалаций, требующих ручного вмешательства COO. Конкретные требования:

К дню выхода сотрудника всё готово. Минимальная корзина (рабочая станция, Google Workspace, Slack, Notion, Email, VPN) — присутствует и работает в первый день нового сотрудника без авралов и догонянок. Контрольная точка — день 7: к этому моменту вся минимальная корзина должна быть проверена в реальной работе сотрудника. Если первый день испорчен IT-неготовностью — страдает онбординг как целое.
Инциденты обрабатываются по SLA. Каждый IT-инцидент имеет понятный приоритет и срок реакции/решения. Сотрудник, оставшийся без работающего инструмента, не должен «ждать пока админ освободится». Серьёзный инцидент, блокирующий работу CVD-команды — всегда красный флаг.
Реестр инфраструктуры актуален в любой момент. COO в любой момент должен иметь возможность увидеть: список аккаунтов по сотрудникам и системам, права доступа, активные лицензии и их сроки, инвентарь устройств, статус инфобез-политик. Не «соберу за неделю», а «доступно сейчас».
Базовая инфобез-гигиена соблюдена. Политика паролей и MFA включена везде, где это применимо; отзыв доступов в день оффбординга — нулевая терпимость к задержкам; критические данные имеют резервные копии; критические инфобез-инциденты немедленно эскалируются. Любое нарушение базовой гигиены — всегда инцидент.
Эскалации к COO минимальны. Типовые ситуации (стандартный онбординг/оффбординг, плановое обновление, рутинная коммуникация с вендором, типовой инцидент) системный администратор закрывает самостоятельно. COO подключается только при нестандартных кейсах — серьёзный инцидент инфобеза, нестандартный спор с вендором, изменение в IT-стратегии, бюджетное решение.
Подрядчики и вендоры ведутся самостоятельно. Вендоры SaaS, локальные подрядчики по железу, провайдеры связи — системный администратор ведёт их сам по согласованным с COO рамкам. COO не должен быть точкой коммуникации с каждым вендором.

Вторичный потребитель: CVD-команды (Anahid, Ilm, продакшн) — получают невидимую IT-инфраструктуру, на которой можно сосредоточенно работать с клиентами. Если CVD-команда тормозится из-за IT — это всегда красный флаг для роли, даже если формальные SLA соблюдены. Это именно та плоскость, где «не количество закрытых тикетов, а отсутствие эпизодов» становится буквально измеримым: каждый случай простоя CVD-команды из-за IT — инцидент в чистом виде.

Метрики

Системный администратор измеряется композитом из 3 метрик, покрывающих две ноги EEQ (Effectiveness / Quality) и ориентированных на восприятие со стороны COO как главного потребителя.

Логика композита: одна метрика — итоговый замер реакции на непредвиденное (скорость разрешения инцидентов по SLA), отражающий главное обещание роли «CVD-команды и операционка не тормозятся из-за IT». Вторая — отдельный замер критической точки (готовность IT-среды к выходу нового сотрудника), потому что онбординг — это не «инцидент», а плановое событие с известной датой, и срыв здесь специфически болезненный — страдает онбординг как целое. Третья — качество картины, на которой стоит вся остальная работа (полнота реестра инфраструктуры): без актуального реестра нельзя ни корректно отозвать доступы при оффбординге, ни запланировать продление лицензий, ни ответить на инфобез-вопрос. Метрики дополняют друг друга: если скорость и онбординг в зелёном, но реестр в красном — значит «текущие операции закрываем, но в реестре бардак»; рано или поздно это всплывёт как утечка через незакрытый доступ или просроченная лицензия. Серьёзный инцидент инфобеза перевешивает любые зелёные метрики — он всегда красный квартал.

Полный список метрик с определениями и порогами — в свойстве Metrics ниже.

Цикл PDCA

Системный администратор управляет двумя вложенными циклами с разной частотой. Внешний цикл — управление IT-инфраструктурой компании на горизонте года; внутренний — управление каждым IT-событием (заявка, инцидент, ритуал) по мере его появления.

Цикл управления IT-событием (короткий, по факту события)

Plan — приём события: классификация (заявка / инцидент с приоритетом / ритуал — онбординг/оффбординг/продление / нестандартный кейс), проверка комплектности данных, оценка срочности, проверка соответствия согласованным правилам.
Do — обработка события: исполнение IT-операции (выдача доступов / отзыв / закупка лицензии / решение инцидента), коммуникация с сотрудником и вендором, при нестандартной ситуации или серьёзном инфобез-инциденте — эскалация к COO.
Check — закрытие события: сверка результата с ожидаемым, фиксация даты завершения, обновление реестра, при отклонении от SLA — фиксация в метрике скорости разрешения; при онбординге — фиксация в метрике готовности на день 1 и проверка на день 7.
Act — корректировка процесса: если событие системное и повторяется — доработка чек-листа или регламента; при повторяющихся инцидентах одного типа — поднятие вопроса о превентивной мере на квартальный чек-ин с COO.

Цикл управления IT-инфраструктурой (длинный, годовой/квартальный)

Plan — годовой/квартальный план: согласованный с COO календарь продления лицензий, плановые ритуалы, бюджет на IT-инфраструктуру, приоритеты на квартал по развитию (новые сервисы, обновление стека, инфобез-улучшения, аудит реестра).
Do — ведение IT-инфраструктуры: операционная работа по календарным ритуалам, обработка заявок и инцидентов, поддержка реестра доступов и лицензий, превентивная работа по инфобезу, ведение вендоров.
Check — квартальный замер метрик домена; квартальный чек-ин с COO с разбором IT-картины, паттернов инцидентов и системных рисков.
Act — корректировка системы: эволюция чек-листов и регламентов, обновление пула вендоров, развитие IT-инфраструктуры под новые потребности компании, корректировка инфобез-политик.

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

Связанные документы

[добавятся по мере появления регламентов: реестр доступов и лицензий, чек-листы IT-онбординга/оффбординга, инфобез-политика, SLA по инцидентам, регламент работы с вендорами]