On-premise: Shtab на своих серверах, в вашем контуре

On-premise (от английского «на своих помещениях») — это способ развернуть Shtab не в общем облаке провайдера, а на серверах самой компании, внутри её закрытого контура. Система стоит в вашей инфраструктуре, данные лежат в вашем периметре и наружу не уходят. Это противоположность привычной облачной модели, где сервис работает на стороне поставщика, а вы подключаетесь к нему через браузер.

Shtab — российская платформа для совместной работы: задачи и канбан-доски, планирование сроков, база знаний, цели по методикам OKR и MBO, учёт времени и финансы. Платформа числится в реестре отечественного ПО и работает в двух вариантах — в облаке и на серверах клиента. Вариант для закрытого контура — это тариф «Корпорация»: полный контроль над данными, установка On-premise, соответствие требованиям регуляторов и бессрочная лицензия. Разворачивает систему в вашей инфраструктуре команда Shtab и сопровождает внедрение — это не тот случай, когда админ ставит дистрибутив в одиночку по инструкции. Этот раздел — про сам режим on-premise: зачем держать систему в своём контуре, чем он отличается от облака и кому нужен. Про перенос работы с зарубежных инструментов рассказывает отдельный сценарий импортозамещения.

У части компаний есть жёсткое правило: данные не должны покидать контур организации. Проектная информация, переписка по задачам, документы, персональные данные сотрудников, коммерческая тайна — всё это служба безопасности не готова отдавать на серверы стороннего провайдера, тем более за пределы страны. И вот руководитель проектного офиса хочет нормальную систему управления вместо таблиц и почты, а получает отказ от ИБ: «в облако нельзя». Зарубежные сервисы отпадают сразу — данные за рубежом, вендор может отключить доступ, оплата затруднена. Российские облачные трекеры ближе, но упираются в то же самое: информация физически лежит не у вас, а у поставщика, и это не проходит согласование.

В итоге компания либо остаётся на табличках и почте, потому что «нормальное всё равно не согласуют», либо тратит месяцы на поиск системы, которую можно поставить в собственный контур. А когда такая система находится, всплывает вторая сложность: развернуть её своими силами — отдельный проект. Нужно понять требования к инфраструктуре, установить, настроить, разграничить доступ, перенести работу команд. Системный администратор, у которого и без того полно задач, тянуть это в одиночку не хочет, и внедрение снова откладывается. Получается замкнутый круг: облако не согласуют, а on-premise страшно разворачивать. Работа при этом живёт в разрозненных файлах, где нет ни общей картины, ни контроля доступа, — ровно там, где рисков для данных больше всего.

Из чего складывается режим on-premise и что вы получаете, размещая Shtab в своём контуре:

• Развёртывание в вашей инфраструктуре — Shtab устанавливается на серверы компании, внутри её закрытого контура; данные не уходят на сторонние серверы, а остаются в периметре организации под её правилами.
• Тариф «Корпорация» как основа — вариант для установки в закрытый контур (On-premise): полный контроль над данными, соответствие требованиям регуляторов и бессрочная лицензия. Стоимость и условия обсуждаются с менеджером под ваш случай.
• Российская платформа из реестра — Shtab разрабатывается в России и числится в реестре отечественного ПО, что обычно и требуется службе безопасности и отделу закупок для допуска системы в контур.
• Гибкие права и роли — доступ настраивается под оргструктуру: собственные роли, ограничение модулей и действий, закрытые финансы и цели компании для лишних глаз. Как это устроено — в статье про настраиваемые права и роли.
• Высокий уровень безопасности и контроля — вариант рассчитан на организации с повышенными требованиями к ИБ: данные внутри периметра, доступ под контролем, картина «кто к чему допущен» — управляемая.
• Работа с большими объёмами данных — контур держит множество проектов, задач и пользователей одновременно, что важно для крупной организации с десятками команд.
• Весь инструментарий Shtab — задачи и канбан-доски, планирование сроков, база знаний, цели, учёт времени и финансы работают в контуре так же, как в облаке; режим меняет размещение, а не возможности.
• Сопровождение внедрения — развёртывание и настройку в вашей инфраструктуре проводит команда Shtab и помогает перенести работу; это не «поставь сам по инструкции», а внедрение с поддержкой.

• Прохождение требований ИБ — согласована ли служба безопасности с размещением: данные в контуре, условия хранения выполнены. Пока этот пункт не снят, система до внедрения не дойдёт.
• Данные в периметре — вся ли чувствительная информация размещена в закрытом контуре компании, а не осталась в облачных сервисах или разрозненных файлах «снаружи».
• Соответствие требованиям закупок — закрыт ли вопрос отечественного ПО и размещения данных: решение из реестра, установка в своём контуре, права под оргструктуру.
• Управляемость доступа — настроены ли роли под структуру организации и понятно ли, кто к чему допущен; для on-premise это не удобство, а часть требований безопасности.
• Охват контура — сколько подразделений реально перешло в единую систему внутри периметра, а не осталось каждое в своих таблицах и почте.
• Работа в одной системе — ведут ли команды проекты и задачи в Shtab, а не по привычке в файлах на общих дисках; собрана ли работа в один управляемый контур.

• Сначала честно ответьте, нужен ли вам закрытый контур. Если жёсткого запрета на облако нет, облачный Shtab дешевле, быстрее в запуске и функционально не беднее — on-premise берут ради размещения данных, а не ради галочки.
• Соберите требования ИБ, закупок и ИТ до первого разговора с менеджером. Чем точнее сформулировано, что нельзя выносить за периметр, тем предметнее пройдёт обсуждение развёртывания.
• Не пытайтесь развернуть систему силами одного администратора. On-premise разворачивает команда Shtab с сопровождением — так внедрение не вязнет между делами перегруженного айтишника.
• Разграничьте доступ через роли до того, как заведёте чувствительные проекты. В контуре важно не только где лежат данные, но и кто внутри к ним допущен, — проще задать правила сразу, чем потом закрывать открытое всем.
• Запускайтесь не всей организацией разом, а с одного подразделения: отладьте роли и процесс на пилоте, затем тиражируйте по шаблону. Сотни пользователей одним днём — верный способ вернуть людей к таблицам.
• Не путайте два проекта: размещение системы в своём контуре (этот раздел) и перенос работы с зарубежных инструментов — импортозамещение — решаются по отдельности, хотя часто идут вместе.

• Берут on-premise «на всякий случай». Разворачивают систему в контуре без реального запрета на облако — дороже и дольше там, где хватило бы облачного тарифа. Починка: проверить, есть ли настоящее требование держать данные в периметре.
• Выбирают систему без службы ИБ. Подбирают трекер по удобству интерфейса, а потом он не проходит согласование по размещению данных. Починка: собрать требования безопасности и закупок до выбора.
• Пытаются развернуть в одиночку. Установку и настройку в контуре вешают на одного перегруженного администратора — и внедрение застревает. Починка: разворачивать с сопровождением команды Shtab, вести переход как проект.
• Забывают про права внутри контура. Считают, что раз данные в периметре, то доступ уже безопасен, и открывают всё всем. Починка: настроить роли под оргструктуру, закрыть финансы и цели компании на ограниченный круг.
• Путают размещение и миграцию. Смешивают «поставить в свой контур» и «перенести с Jira» в один ком и тонут в объёме. Починка: развести режим on-premise и импортозамещение на два этапа.
• Запускают всё разом. Разворачивают на всю организацию одним днём, люди не успевают перестроиться и возвращаются к файлам. Починка: пилот на одном подразделении, потом тиражирование.

Режим on-premise выбирают по-разному, в зависимости от того, откуда идёт требование. Там, где на первом плане служба безопасности и хранение чувствительных данных, разговор начинается с размещения и модели доступа: настройка ролей опирается на статью про права и роли, а условия установки в закрытый контур обсуждаются с менеджером на странице тарифов. Организациям госсектора и банкам важнее всего соответствие требованиям регуляторов и хранение данных в периметре — для них on-premise не опция, а условие допуска. Крупному бизнесу с десятками команд наравне с безопасностью нужен масштаб: единый контур на множество проектов и пользователей, права под оргструктуру. Важно не путать два соседних вопроса: этот раздел — про сам режим размещения в своём контуре, а перенос работы с зарубежных инструментов разбирает сценарий импортозамещения; часто их делают вместе, но это разные проекты. Процесс закупки и внедрения для крупной организации со стороны ИБ и закупок описан отдельно, в сценарии для корпораций. А чтобы выстроить работу в самой системе после развёртывания, опирайтесь на разделы управления проектами, для PMO и для руководителя.

Раздел для организаций, где данные о проектах, задачах и людях нельзя размещать во внешнем облаке — по требованиям безопасности, регуляторов или внутренней политики. Полезен службам информационной безопасности, которые не согласуют хранение чувствительной информации на чужих серверах; ИТ-директорам и системным администраторам, которым поручили развернуть систему управления в собственном контуре; отделам закупок, сверяющим решение с требованиями к отечественному ПО и размещению данных; руководству компаний, где контроль над данными — обязательное условие, а не пожелание. Особенно актуально для банков и страховых, госсектора, промышленности, оборонных и проектных структур, а также для крупного бизнеса, работающего с персональными данными и коммерческой тайной. Если компания спокойно работает в облаке и ограничений на размещение данных нет — on-premise разворачивать незачем: облачный Shtab дешевле и быстрее в запуске, а набор функций тот же. Сценарий имеет смысл ровно тогда, когда данные обязаны оставаться внутри периметра.