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 рамок.

COO и System Administrator: разделение ролей

COO и System Administrator — обе работают с IT-средой компании. Но они работают на разных уровнях ответственности. Без чёткого разделения либо COO втягивается в технические заявки и теряет стратегический фокус, либо Sysadmin остаётся без управления и IT превращается в реактивную функцию.

Короткая формулировка:

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

В чём это проявляется:

Когда это важно понимать:

• Когда возникает стратегический IT-вопрос (новый сервис, изменение стека, серьёзный инфобез-инцидент) — решает COO, не Sysadmin
• Когда нужно решить инцидент или обработать заявку — это зона Sysadmin под управлением COO
• COO отвечает перед CVD за итог (IT не блокирует работу); Sysadmin отвечает перед COO за исполнение
• Эскалации к CEO по IT-вопросам идут через COO, не напрямую от Sysadmin

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

Бесперебойно работающая 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 — инцидент в чистом виде.

Run / Change / Disrupt

Run (поддержание потока)

То, что системный администратор делает каждую неделю и каждый месяц, чтобы IT-инфраструктура работала:

• Обработка заявок и инцидентов по SLA: классификация по приоритетам, исполнение, закрытие, фиксация в реестре
• Жизненный цикл аккаунтов: выдача в день онбординга, изменения по запросу, отзыв в день оффбординга — нулевая терпимость к задержкам по оффбордингу
• Координация с HR Manager по онбордингам/оффбордингам: получение данных по новым сотрудникам (Start Date, роль, юрисдикция), подтверждение IT-готовности, уведомление об оффбордингах
• Подготовка минимальной корзины к выходу нового сотрудника: рабочая станция, Google Workspace, Slack, Notion, Email, VPN — собрано и проверено к day 1; повторная проверка в день 7
• Поддержание реестра инфраструктуры в Notion: статусы аккаунтов, устройств, лицензий — обновляется по факту изменений
• Контроль продления лицензий: превентивно за 30+ дней до истечения, координация с COO по бюджетным аспектам, согласование с GM/Accountant по платежной стороне
• Базовая инфобез-гигиена: контроль MFA, политики паролей, корректности прав доступа, превентивная работа по обнаружению аномалий
• Координация вендоров и подрядчиков: SaaS-провайдеры, локальные подрядчики по железу, провайдеры связи — точечная коммуникация по активным задачам
• Резервное копирование критических данных: проверка работы бэкапов, тестовые восстановления при необходимости

Change (улучшение того, как роль работает)

То, что системный администратор делает на горизонте квартала, чтобы IT-инфраструктура становилась лучше:

• Анализ паттернов в инцидентах: какие категории доминируют, где системные проблемы, что требует превентивной меры
• Эволюция чек-листов и регламентов: онбординг IT-чек-лист, оффбординг IT-чек-лист, чек-лист продления лицензий, регламент инфобез-инцидентов
• Аудит реестра инфраструктуры: проверка полноты, корректировка пробелов, систематизация устаревших записей
• Развитие пула вендоров: оценка качества работы текущих, привлечение новых при необходимости, расставание со слабыми
• Систематизация IT-прецедентов: какие нестандартные ситуации возникали, какие решения сработали, что добавить в чек-лист
• Подготовка инфраструктуры под новые потребности компании: расширение IT-стека по запросу COO, новые SaaS, новые роли, новые юрисдикции
• Эволюция инфобез-гигиены по факту реальных рисков: что усилить, какие новые контроли ввести
• Обратная связь COO по сигналам системного характера: что в IT-стратегии нужно корректировать (стек, политика инфобеза, бюджет)

Disrupt (переизобретение роли)

То, что меняет саму конфигурацию роли в системе:

• AI-усиление IT: автоматическая обработка типовых заявок (выдача стандартных доступов, типовые настройки, рутинные операции с аккаунтами), AI-первая линия для сотрудников с эскалацией к админу при нестандартных кейсах
• Превентивный мониторинг IT-инцидентов: AI-анализ логов и аномалий с предупреждениями до возникновения видимого инцидента, переход от реактивной модели к проактивной
• Автоматизация реестра инфраструктуры: статусы аккаунтов, устройств, лицензий обновляются автоматически по событиям в подключенных системах, sysadmin становится валидатором, не сборщиком
• Self-service для типовых заявок: внутренний портал, через который сотрудники запрашивают и получают типовые ресурсы (доступы, ПО) без прямого контакта с админом
• Расширение модели на международные юрисдикции: единая IT-инфраструктура с локальными адаптациями (compliance, юрисдикционные требования к данным) при международном расширении компании
• Сокращение размера IT-функции за счёт AI: меньше людей при той же или большей пропускной способности и качестве

Метрики

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

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

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

🟢 Full Zone of Genius (зона полной автономии)

Решения, которые системный администратор принимает сам, без согласования с кем-либо. Это широкая зона в операционном IT, ограниченная границей с IT-стратегией (COO), стратегией компании (CEO), бюджетными решениями (COO + GM) и продуктовой разработкой (CVD-команды).

• Тактическое исполнение IT-операций. Как структурирован процесс выдачи доступов, как организован чек-лист онбординга/оффбординга, как ведётся обработка типовой заявки. Sysadmin решает сам в рамках утверждённой COO IT-стратегии.
• Тактическая обработка инцидентов в рамках SLA. Какой инцидент считать высокого приоритета, как структурирован разбор причин, какие шаги для устранения. Sysadmin исполняет по SLA.
• Координация вендоров и подрядчиков внутри согласованного пула. Кому из вендоров поручить конкретную задачу, как структурирована коммуникация, как контролируется качество. Sysadmin ведёт сам в рамках согласованного с COO пула.
• Структура и содержание реестра инфраструктуры. Какие поля вести, какие категории, как структурированы записи, в каком темпе обновлять. Sysadmin решает сам.
• Тактическая работа с базовой инфобез-гигиеной. Какие правила MFA применить, какая политика паролей, как структурированы права доступа в стандартных конфигурациях. Sysadmin исполняет в рамках COO-политики.
• Резервное копирование и восстановление критических данных. Какие данные бэкапить, в каком темпе, как тестировать восстановление. Sysadmin решает сам в рамках COO-стратегии.
• Структура и формат IT-отчётности для COO. Как представлен срез для COO, какие разрезы, в каком темпе. Sysadmin решает сам, COO получает результат.
• Тактическая работа с lifecycle устройств. Когда списать устройство, когда заменить, как организован парк. Sysadmin решает сам в рамках утверждённого бюджета.

Принцип: всё, что касается как IT-инфраструктура работает внутри согласованной COO стратегии — это зелёная песочница системного администратора. Зрелость роли измеряется тем, насколько COO может опереться на IT-инфраструктуру без вмешательства в каждую ситуацию, и тем, насколько CVD-команды не помнят о существовании IT-функции (всё просто работает).

🟡 Decisions Requiring Collaboration (коллегиальные решения)

Решения, которые системный администратор принимает в коллаборации с другими ролями. Здесь критично понимать с кем и как принимается решение.

• Изменения в IT-стеке (новый SaaS, замена существующего сервиса, существенная реструктуризация инфраструктуры) → с COO. Как: sysadmin формулирует операционное предложение и обоснование, COO согласует с CEO в стратегических случаях, вместе утверждают.
• Бюджетные решения по IT (закупка устройств, лицензии существенного объёма, внешние услуги) → с COO и GM. Как: sysadmin формулирует потребность, COO валидирует на стратегическое соответствие, GM проверяет финансовую модель, утверждение через регламент платежей.
• Реакция на серьёзные инфобез-инциденты (утечка данных, компрометация аккаунтов, атака на инфраструктуру) → с COO и при стратегическом масштабе CEO через COO. Как: sysadmin фиксирует инцидент и готовит варианты реакции, COO принимает решение, при стратегическом масштабе эскалирует к CEO.
• Координация онбординга с HR Manager → с HR Manager под управлением GM. Как: HR Manager передаёт данные о новом сотруднике (Start Date, роль, юрисдикция), sysadmin готовит IT-доступы, COO обеспечивает PMO-инфраструктуру для производственных ролей.
• Координация оффбординга с HR Manager → с HR Manager под управлением GM. Как: HR Manager уведомляет о дате оффбординга, sysadmin отзывает доступы в день оффбординга, фиксирует возврат устройства.
• Привлечение нового вендора или подрядчика → с COO. Как: sysadmin формулирует потребность и обоснование, COO утверждает в рамках бюджета.
• Изменения в инфобез-политике (новые правила MFA, новая политика паролей, новые ограничения доступа) → с COO. Как: sysadmin формулирует предложение по обратной связи с операционки, COO согласует с CEO в стратегических случаях, sysadmin внедряет.
• Поддержка нестандартных IT-запросов от CVD-команд (специфические инструменты, нестандартные доступы) → с COO. Как: sysadmin фиксирует запрос, валидирует с COO на стратегическое соответствие и инфобез-риски, при согласии исполняет.

🔴 Decisions That Should Never Be Made (зона запрета)

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

• IT-стратегия компании (выбор стека на годы, архитектура корпоративных систем). Это зона COO и CEO. Sysadmin исполняет утверждённую стратегию, не определяет её.
• Инфобез-политика высокого уровня (общие принципы защиты данных, compliance-стратегия, реакция на репутационные риски). Это зона COO и CEO. Sysadmin исполняет базовую гигиену внутри политики.
• Бюджет IT на год. Это зона COO и GM. Sysadmin исполняет утверждённый бюджет в операционных решениях.
• Разработка продукта и кастомизация для клиентов. Это зона CVD-команд (Anahid, Ilm) и AIA/FDE. Sysadmin держит общую IT-инфраструктуру компании, но не выбирает технологии для клиентских проектов и не работает с продуктом.
• Стратегические решения о направлении развития компании (выход на новые рынки, запуск новых продуктовых линий, M&A с IT-последствиями). Это зона CEO и Diwan. Sysadmin участвует в IT-стороне после принятия решения.
• Кадровые решения по сотрудникам (кроме вендоров и внешних подрядчиков). Это зона руководителей сотрудников + HR Manager под GM. Sysadmin исполняет IT-сторону кадровых событий, не участвует в кадровых решениях.
• Финансовая сторона IT-операций (платежи вендорам, оформление лицензионных контрактов с финансовой стороны, налоговые аспекты). Это зона GM/Accountant. Sysadmin поставляет операционные данные.
• Прямая работа с клиентом по конкретному проекту или аккаунту. Это зона CVD. Sysadmin не общается с ЛПР клиента и не работает с клиентскими IT-системами.
• Работа с продакшн-инфраструктурой клиентских проектов. Это зона AIA/FDE/PM в рамках конкретного проекта. Sysadmin отвечает за корпоративную IT-среду, не за production у клиентов.
• Маркетинговая стратегия и бренд. Это зона CMO. Sysadmin не участвует.
• Эскалация к CEO напрямую, минуя COO. COO — главный потребитель и руководитель sysadmin. Прямая эскалация к CEO допустима только в исключительных ситуациях (критический инфобез-инцидент с немедленным репутационным риском), согласованных с COO.

Принцип: красная песочница системного администратора — это граница со стратегическим IT-контуром (COO, CEO, IT-стратегия и инфобез-политика высокого уровня), граница с продуктовым контуром (CVD-команды, разработка для клиентов), граница с финансовым контуром (GM/Accountant, бюджет и платежи), граница с кадровым контуром (HR Manager, кадровые решения), граница со стратегией компании (CEO, Diwan, направление развития). Sysadmin исполняет операционный IT-контур корпоративной инфраструктуры; всё, что вне этой зоны — не его.

Цикл 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 по инцидентам, регламент работы с вендорами]