Портал внедрили за три недели, файлы перетащили за выходные, отчитались перед заказчиком. А через полгода начинаются вопросы: где актуальный договор с сетью, почему у стажёра открылась папка с зарплатами, отчего Диск тормозит и не вернуться ли на Google Диск. И самое неприятное — формально всё сделано правильно. Файлы перенесены, права выданы, синхронизация работает. Просто структуру сетевого файлового хранилища скопировали в облако как есть, а она к облаку не приспособлена.
Всем привет, меня зовут Сергей Прощаев и в этой статье расскажу про то, почему миграция файловой инфраструктуры в Битрикс24 Диск ломается не в момент переноса, а через два‑три квартала после него — и что с этим делать до, а не после.
Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС. Внедрением Битрикс24 я не занимаюсь — я обычно с другой стороны. Меня зовут, когда «файлы уже в портале, но что‑то пошло не так»: надо выгрузить дерево через REST, понять, кто кому что видит, и объяснить бизнесу, почему разгребание займёт не два дня.
Разберём шесть ошибок, которые не видно на сдаче проекта и которые обязательно всплывают к третьему кварталу эксплуатации. Каждая из них на этапе внедрения выглядит как разумное решение — в этом и проблема.
Ошибка 1. Скопировали дерево папок как есть
Симптом. На общем диске 30–40 папок первого уровня. Среди них «Разное», «Разное 2», «Общее», «Новая папка», «Архив», «Архив старый». Вложенность местами уходит на восемь уровней. Поиск по содержимому включён, но люди им не пользуются, потому что не знают, что искать.
Почему так делают. Потому что миграция звучит как задача копирования. Заказчик говорит «перенесите нашу шару в Битрикс24», интегратор понимает это буквально и переносит. Логика вроде бы честная: не мы придумывали структуру, не нам её ломать. Однажды мне попалось ТЗ с формулировкой «обеспечить идентичность файловой структуры до и после переноса». Идентичность обеспечили. Работать стало хуже.
Что ломается. Сетевая шара и Битрикс24 Диск устроены по‑разному. На шаре папка — единственный способ что‑то организовать, поэтому в неё зашиты одновременно и владелец, и права, и стадия жизненного цикла документа. В Битрикс24 для этого есть три типа хранилищ: Мой диск, диски групп и проектов, общий диск компании. Когда вы копируете дерево целиком в общий диск, вы схлопываете три измерения в одно — и теряете ровно тот выигрыш, ради которого переезжали.
Как правильно. При проектировании каждой папки верхнего уровня полезно ответить на три вопроса: кто владелец содержимого, кто должен читать, живёт ли документ внутри конкретного процесса. Ответы дают маршрут. Мой вариант, который я обычно использую — сначала нарисовать схему маршрутизации на одном листе и согласовать её с заказчиком, и только потом трогать файлы. Схема на рис. 2 — тот самый лист.
Из схемы стоит вынести вот что: тип хранилища определяется не тематикой документа, а тем, кто им владеет и внутри какого процесса он живёт. «Договоры» — это не папка. Это документы, часть которых относится к сделке, часть — к юротделу, а часть вообще шаблоны для всей компании. На шаре они лежали вместе, и это было нормально. В портале они должны разъехаться.
И ещё одно, что важно понимать до начала работ. После переноса файлов компания почти всегда начинает пользоваться остальными сервисами портала — задачами, CRM, документооборотом. Поэтому ошибки в организации Диска перестают быть локальными и довольно быстро вылезают в соседних модулях. Дальше это будет видно на нескольких примерах.
Ошибка 2. Личный диск стал рабочим хранилищем
Симптом. Менеджер увольняется, и вместе с ним из компании уходят подписанные сканы за полтора года. Или проще: человек в отпуске, а документ, который нужен прямо сейчас, лежит у него в «Моём диске».
Почему так делают. Мой диск — первое, что видит сотрудник. Туда автоматически попадают файлы, с которыми он работал: сохранил картинку из комментария, загрузил отчёт в задачу. Дальше срабатывает привычка: раз всё моё уже здесь, буду складывать сюда и остальное. Интегратор в этот момент занят настройкой CRM и на файлы не смотрит.
Что ломается. Личное хранилище по определению принадлежит пользователю, а не компании. Регламента передачи при увольнении нет, поиск по содержимому чужие файлы не покажет — он не выдаёт то, к чему у вас нет доступа. Помню, как однажды разбирали историю, где восстановление рабочих документов уволившегося сотрудника упёрлось в срок хранения корзины: часть файлов он успел удалить, а в облаке удалённое лежит 30 дней. Прошло сорок.
Как правильно. Проговорить с заказчиком границу на старте и закрепить её письменно: Мой диск — только черновики и то, что не имеет ценности для компании. Всё, что кто‑то может запросить в отсутствие автора, лежит на диске группы или общем. Проверять границу удобно инвентаризацией через REST: пройтись по хранилищам и посмотреть, где на личных дисках накопились объёмы, которых там быть не должно.
// (JavaScript, BX24 JS SDK, облачная версия) Инвентаризация хранилищ портала // Для краткости пример не показывает обработку постраничной выборки: // list-методы REST отдают по 50 объектов, дальше нужен параметр start. BX24.callMethod("disk.storage.getlist", {}, function (res) { if (res.error()) return console.error(res.error()); const storages = res.data(); // ENTITY_TYPE: user - Мой диск, group - диск группы, common - общий диск const personal = storages.filter(s => s.ENTITY_TYPE === "user"); personal.forEach(s => { BX24.callMethod("disk.storage.getchildren", { id: s.ID }, function (r) { const items = r.error() ? [] : r.data(); const folders = items.filter(i => i.TYPE === "folder"); // Личный диск с развитым деревом папок - кандидат на разбор if (folders.length > 3) { console.log(`Личный диск ${s.NAME}: ${folders.length} папок верхнего уровня`); } }); }); });
Ошибка 3. Права выдали по людям, а не по структуре
Симптом. Открываете настройки прав папки «Договоры» и видите список из 27 персональных записей. Половина людей уже не работает или перешла в другой отдел.
Почему так делают. Потому что на этапе внедрения так быстрее. Заказчик присылает список «кому нужен доступ», интегратор проставляет галочки по фамилиям, задача закрыта. Раздача по отделам требует, чтобы структура компании в портале была заполнена корректно, а она на старте почти никогда не заполнена.
Что ломается. Права по людям не переживают ни одного кадрового движения. Новый сотрудник в отделе доступ не получает, ушедший — не теряет. Через год матрицу прав невозможно не то что изменить, а просто прочитать. И это не только неудобство: аудит доступа в такой конфигурации физически невозможен.
Как правильно. Права назначаются на отделы и рабочие группы, а не на людей. Персональный доступ — исключение, у которого есть срок и причина. В API это один и тот же механизм: пара TASK_ID (уровень доступа) и ACCESS_CODE (кому). Разница только в том, что вы кладёте в ACCESS_CODE: U10 — конкретный пользователь, D5 — отдел, DR5 — отдел вместе с подчинёнными подразделениями, AU — все авторизованные. Коды отделов стоит проверять на конкретном портале, они различаются.
<?php // (PHP, коробочная версия, D7 API) Выдача прав на папку целому отделу $rightsManager = \Bitrix\Disk\Driver::getInstance()->getRightsManager(); $taskRead = $rightsManager->getTaskIdByName($rightsManager::TASK_READ); $folder = \Bitrix\Disk\Folder::loadById($folderId); if ($folder) { // append не проверяет существующие назначения: в рабочем коде // перед вызовом стоит сверяться с текущей матрицей, иначе права дублируются $rightsManager->append($folder->getRealObject(), [ [ 'ACCESS_CODE' => 'DR5', // отдел 5 и все подчинённые подразделения 'TASK_ID' => $taskRead, ], ]); }
Оговорюсь, чтобы не создавать ложного впечатления. Оргструктура — это не полноценная ролевая модель. Если в компании роли не совпадают с отделами, доступ приходится вести через рабочие группы, а они уже становятся отдельным уровнем абстракции со своим жизненным циклом. Отделы — хорошая база, но не универсальный ответ.
Отдельно замечу: в облаке ревизию прав через REST сделать сложнее, чем хотелось бы — метода, который вернёт полную матрицу доступа по папке, там нет. Проверку приходится строить на выгрузке дерева и сверке с проектной матрицей вручную. Некрасиво, но работает, и лучше делать это раз в квартал, чем не делать вообще.
Ошибка 4. На общий диск сложили всё, что «непонятно куда»
Симптом. В общем диске есть раздел с полным доступом для всех авторизованных пользователей, и в нём за полгода накопилось всё подряд: сканы паспортов, коммерческие предложения, файл со структурой окладов, выгрузка из 1С.
Почему так делают. Общий диск — путь наименьшего сопротивления. Когда на этапе переноса непонятно, чей документ, его кладут «пока в общее», чтобы разобраться потом. Потом не наступает. А право «полный доступ для всех» ставят, чтобы не ловить жалобы «у меня не открывается» в первую неделю после запуска.
Что ломается. Ничего — до тех пор, пока не ломается сразу и целиком. И тут стоит вспомнить хорошо задокументированный случай, который к Битрикс24 отношения не имеет, но объясняет механику лучше любого гипотетического примера.
В мае 2023 года Toyota сообщила, что данные примерно 2,15 млн пользователей её сервисов T‑Connect, G‑Link и G‑BOOK в Японии были доступны извне. Не из‑за взлома. Из‑за ошибки в конфигурации облачного окружения, при которой хранилище оказалось открыто на чтение вообще без пароля. Экспозиция длилась с ноября 2013 по апрель 2023 года — почти десять лет. Причиной компания назвала недостаточное распространение и соблюдение правил обращения с данными, а представитель отдельно признал, что механизмов, которые отслеживали бы факт публичности данных, попросту не было. Через две недели, уже в ходе сплошной проверки всех своих облачных сред, Toyota нашла второй такой же случай — ещё около 260 тысяч человек. После этого была запущена система непрерывного контроля конфигураций.
Этот кейс показателен именно из‑за срока. Десять лет никто не замечал, потому что настройка была сделана один раз и больше не проверялась. То же самое с папкой «Общее»: её открыли всем на второй неделе внедрения и с тех пор туда не заглядывали.
Как правильно. Общий диск по умолчанию доступен только на чтение, право на запись выдаётся точечно и на конкретный раздел. Раздела «Разное» не существует. Документ, для которого не нашлось владельца, не переносится вообще — он остаётся в архиве старой шары до тех пор, пока владелец не найдётся. И главное: проверка прав — это не задача внедрения, а регулярная процедура, которую нужно передать заказчику вместе с порталом.
Ошибка 5. Файлы прикрепляют в задачи и CRM копией, а не ссылкой
Симптом. Открываете сделку и видите примерно такое:
Сделка №4417 «Поставка, сеть Х» / вложения КП_итог.pdf 1,2 МБ 12.03 менеджер КП_итог_2.pdf 1,2 МБ 19.03 менеджер КП_итог_финал.pdf 1,3 МБ 02.04 РОП Диск / Продажи / КП / 2026 КП_сеть_Х.pdf 1,4 МБ версия 9, последняя правка 11.04, юрист
Актуальная версия — на Диске, и в сделке её нет. Менеджер об этом не знает и отправляет клиенту то, что видит в карточке.
Почему так делают. Кнопка «прикрепить файл» работает быстрее, чем «выбрать с Диска». Это чистая эргономика: пользователю проще перетащить документ с рабочего стола, чем искать его в дереве. Никакого злого умысла тут нет.
Что ломается. Копия отрывается от истории версий. Диск умеет хранить версии и показывать, кто и когда правил документ, но всё это работает только для файла, который живёт на Диске, а не для его дубля в комментарии к задаче. Плюс каждая копия занимает место на тарифе, а в облаке оно конечно.
Как правильно. Простое правило: файл живёт на Диске, во все остальные сущности идёт ссылка на него. Документ создаётся или загружается в папку через disk.folder.uploadfile, а в задачу или сделку прикрепляется уже существующий объект Диска. Если у клиента типовой документооборот, стоит настроить генератор документов CRM так, чтобы он сразу писал результат в нужную папку, а не плодил вложения в карточках.
Исключение из правила есть, и его надо проговаривать с юристами заказчика: там, где нужно зафиксировать состояние документа на момент согласования или подписания, копия становится осознанным решением, а не ошибкой. Живая ссылка на файл, который потом отредактируют, для таких процессов не годится.
Ошибка 6. Синхронизацию включили на всё дерево и на все машины
Симптом. У сотрудников на ноутбуках по 60–80 ГБ рабочих файлов, а в синхронизируемых папках накапливается вот это:
~/Bitrix24/Продажи/Договоры/ Договор_поставки_2026.docx Договор_поставки_2026 (конфликтующая копия, ПК Иванов).docx Договор_поставки_2026 (конфликтующая копия, ноутбук Иванов).docx
Никто эти копии не разрешает — их просто оставляют лежать рядом, на всякий случай.
Почему так делают. Это прямой перенос привычки с сетевой шары: раньше диск был подключён целиком, значит и здесь пусть будет целиком. Десктопное приложение честно синхронизирует всё, что ему дали.
Что ломается. Одновременное редактирование одного файла на двух машинах в офлайне даёт конфликтующие копии. Дальше начинается то же самое, от чего уезжали с шары, только теперь ещё и в облаке.
Как правильно. Синхронизировать только те папки, с которыми человек действительно работает офлайн. Для остального использовать подключение Диска как сетевого в проводнике — открыть и посмотреть можно, места на ноутбуке не занимает. Совместное редактирование — через онлайн‑редактор, если он поддерживается офисным пакетом заказчика: в коробочных инсталляциях набор доступных редакторов может отличаться. Я бы предпочёл зафиксировать это в регламенте одной строкой: если над файлом работают двое и больше, локальная синхронизация для него запрещена.
Как это делают команды, которые больше на эти грабли не наступают
К середине 2026 года практика команд, которые работают с крупными порталами, сводится к четырём вещам.
Первое — миграция никогда не идёт одним куском. Сначала инвентаризация, на которой отсекается всё, что не открывали три года. В моих проектах это стабильно от 40 до 60 процентов объёма, и заказчик обычно очень удивляется цифре. Второе — пилот на одном отделе, две‑три недели, до массового переноса. Пилот показывает сценарии, которых не было в проектной документации. Третье — у каждого раздела верхнего уровня есть живой владелец с именем и фамилией, а не «отдел». Четвёртое, и самое недооценённое, — ревизия прав раз в квартал как обязательная часть поддержки, а не как разовая настройка. Кейс Toyota выше — ровно про то, что бывает, когда этой процедуры нет.
Отдельно про новое. За 2026 год у платформы заметно подтянулась AI‑часть, и соблазн продать заказчику «умный поиск по документам» стал больше. Но поиск не покажет пользователю то, к чему у него нет прав, а модель, какой бы хорошей она ни была, не определит, какая из четырёх версий договора является канонической, — этой информации просто нет в данных. AI поверх неразобранной файловой свалки даёт неразобранную файловую свалку, только с чатом.
Из этой схемы стоит вынести распределение усилий: основная работа приходится на первые два шага, где ещё не перенесён ни один файл. Если проект стартует сразу с четвёртого — а стартует он так почти всегда, потому что заказчик платит за результат, а не за инвентаризацию, — через полгода вы вернётесь к шагу 1, только уже с порталом, в котором работают люди.
Когда эти рекомендации не подходят
Честно про границы, потому что универсальных решений тут нет.
Права на отделы и группы работают, если оргструктура в портале заполнена и поддерживается в актуальном состоянии. В компаниях с матричным управлением, где человек одновременно в продуктовой команде и в функциональном отделе, отделами обойтись не выйдет — придётся вести доступ по рабочим группам и следить за их составом отдельно.
Правило «файл на Диске, в задачу идёт ссылка» ломается на внешних подрядчиках. Если человек работает через экстранет, ссылка на внутренний Диск ему не откроется, и копия становится вынужденной. Для таких сценариев проще заранее выделить отдельную группу с внешними участниками.
Отказ от полной синхронизации не подходит там, где люди работают в полях без стабильного интернета — монтажники, выездные инженеры, сотрудники на удалённых площадках. Им локальная копия нужна, и вопрос решается не запретом, а разделением: одна папка синхронизируется целиком, остальное — нет.
И последнее. Всё описанное имеет смысл на портале от нескольких десятков человек. Для команды из восьми сотрудников матрица прав и квартальная ревизия — избыточная бюрократия.
Сводная таблица
Ошибка | Признак, по которому её видно | Что проверить в первую очередь |
|---|---|---|
Дерево скопировано как есть | Больше 15 папок первого уровня, есть «Разное» и «Архив» | Сколько разделов общего диска не открывали 90 дней |
Личный диск как рабочее хранилище | Развитая структура папок на «Моём диске» у рядовых сотрудников | Объём личных дисков топ-10 пользователей |
Права по людям | Персональные записи в правах вместо отделов и групп | Доля персональных прав в общем числе назначений |
Общий диск открыт всем | Раздел с полным доступом для всех авторизованных | Что реально лежит в таких разделах прямо сейчас |
Файлы копией, а не ссылкой | Дубли с суффиксами в задачах и карточках CRM | Расхождение файлов в сделках и в папке отдела |
Синхронизация на всё дерево | Конфликтующие копии, большой локальный объём | Список синхронизируемых папок у пяти сотрудников |
Чек‑лист перед сдачей файловой структуры заказчику
Для каждого раздела верхнего уровня определён тип хранилища и обоснован выбор.
В матрице прав нет персональных назначений без указанной причины и срока.
На общем диске нет разделов с правом записи для всех авторизованных.
У каждого раздела есть владелец с именем, а не «отдел маркетинга».
Правило «файл на Диске, в задачу идёт ссылка» зафиксировано письменно, исключения перечислены.
Список синхронизируемых локально папок ограничен и согласован.
Процедура ревизии прав включена в регламент поддержки с периодичностью.
Заказчик знает, что корзина хранит удалённое ограниченный срок, и это не бэкап.
Что на самом деле проверяет эта группа ошибок
Все шесть ошибок объединяет одно: ни одна из них не про Битрикс24. Это ошибки проектирования доступа и жизненного цикла данных, которые точно так же встречаются в S3, SharePoint и на любом корпоративном файловом хранилище. Инструмент только определяет, как быстро они всплывут.
Поэтому навык, который здесь проверяется, — это не знание интерфейса Диска и не умение нажимать нужные галочки. Это способность до переноса ответить на три вопроса про каждый документ: кто им владеет, кто должен его видеть и когда он перестанет быть нужным. Интегратор, который умеет задавать эти вопросы заказчику и выдерживать паузу, пока тот думает, стоит дороже интегратора, который переносит быстро.
Если хотите проверить себя не на моих формулировках, а на своих проектах — возьмите чек‑лист выше и пройдите по последнему порталу, который сдавали. Мой личный рекорд — четыре пункта из восьми на внедрении, которое считалось образцовым.
Разобраться с файловой структурой и правами проще до того, как ошибки накопятся и начнут мешать работе пользователей. На бесплатных демо-уроках можно посмотреть, как эти задачи решают на практике, познакомиться с преподавателями курса «Интегратор Битрикс24» и оценить формат обучения:
4 августа в 19:00. «Эффективная работа с диском Битрикс24». Записаться
10 августа в 19:00. «Настройка прав доступа в Битрикс24: от простого к сложному». Записаться
20 августа в 19:00. «Аналитика. Возможности BI-конструктора». Записаться
